Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГЛАВА_4.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
1.4 Mб
Скачать

ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА

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

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

ПП.

В начале 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 (Институт программной инженерии).

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