Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
КЛ_ЭПИ.doc
Скачиваний:
1
Добавлен:
01.03.2025
Размер:
2 Mб
Скачать
  1. Организация разработки программного проекта.

    1. Кризис программирования и способ выхода из него

Программы не появляются сами по себе, даже основываясь на самых лучших методологиях и образцах. Программа — это результат деятельности людей, и от того, как организован труд этих людей, в огромной степени зависит качество разрабатываемого ПП.

В начале 1970-х годов в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный ПП не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполнявшиеся в последние годы ведущими зарубежными аналитиками, дают не слишком обнадеживающие результаты. Например, в 1995 г. компания Standish Group проанализировала работу 364 американских корпораций, а также итоги выполнения более 23 тыс. проектов, связанных с разработкой ПП, и сделала следующие выводы:

  • только 16,2 % проектов завершились в срок, не превысили запланированный бюджет и обеспечили реализацию всех требуемых функций и возможностей;

  • 52,7 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;

  • 31,1 % проектов были аннулированы до завершения.

Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет в среднем оказался превышен на 89 %, а срок выполнения — на 122 %.

В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26, 46 и 28 % соответственно).

В числе причин возможных неудач фигурируют:

  • нечеткая и неполная формулировка требований к ПП;

  • недостаточное вовлечение пользователей в работу над проектом;

  • отсутствие необходимых ресурсов;

  • неудовлетворительное планирование;

  • частое изменение требований и спецификаций;

  • новизна используемой технологии для организации;

  • отсутствие грамотного управления проектом;

  • недостаточная поддержка со стороны высшего руководства.

В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что большое число проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Иордана, одного из ведущих мировых специалистов в области программной инженерии, утвердилось выражение «death march» — буквально «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50 %. По отношению к проектам создания ПП это означает наличие, как минимум, одного из следующих ограничений:

  • план проекта сжат более чем на половину по сравнению с нормальным расчетным планом, т.е. работа, требующая в нормальных условиях 12 мес, должна быть выполнена за 6 мес или менее. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;

  • число разработчиков уменьшено более чем на половину по сравнению с действительно необходимым для проекта данного масштаба, как правило, по причине сокращения штатов компании в результате кризиса, реорганизации и т.д.;

  • бюджет и связанные с ним ресурсы урезаны наполовину (результат сокращения компании и других противозатратных мер или конкурентной борьбы за выгодный контракт), что влечет за собой уменьшение числа нанимаемых разработчиков или привлечение малооплачиваемых неопытных молодых работников;

  • требования к функциям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях.

Потребность контролировать процесс разработки ПП, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 1970-х годов к необходимости перехода от кустарных к индустриальным способам создания ПП и появлению совокупности инженерных методов и средств создания ПП, объединенных общим названием «программная инженерия» (software engineering). Впервые этот термин прозвучал в качестве названия темы конференции, проводившейся под эгидой НАТО в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция по программной инженерии. Тогда же появилось первое издание, посвященное программной инженерии, — «IEEE. Transactions on Software Engineering» («IEEE. Труды по программной инженерии»).

В процессе становления и развития программной инженерии можно выделить два этапа:

  • 1970-е и 1980-е годы — систематизация и стандартизация процессов создания ПП (на основе структурного подхода);

  • 1990-е годы — начало перехода к сборочному, индустриальному способу создания ПП (на основе объектно-ориентированного подхода).

В основе программной инженерии лежит одна фундаментальная идея: проектирование ПП является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПП позволяют повысить его качество, обеспечивают управляемость процесса проектирования ПП и увеличивают срок его жизни.

При любых изменениях в процессе разработки ПП необходимо иметь критерии, позволяющие оценить эффект от проведенных изменений. Другими словами, необходимы методы, позволяющие измерять качество и эффективность работы организации. Под организацией понимается совокупность всех групп разработчиков проектов (каждый проект направлен на создание своего ПП) и администрации, связанных одним процессом.

В настоящее время существуют две общепринятые методики оценки состояния процесса разработки программного обеспечения: международный стандарт ISO 9001 и модель CMM-SEI — Capability Maturity Model (модель оценки зрелости технологических процессов в организации), разработанная в Software Engineering Institute (Институт программной инженерии).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]