117

5 Программная инженерия

5.1 Проблемы разработки по

Тенденции развития ПО, диктуемые потребностями общества в информационном обеспечении всех сторон человеческой деятельности, ведут к непрерывному росту сложности пакетов прикладных программ, баз данных и знаний, информационных систем. Масштабы таких функционально-законченных прикладных программных комплексов достигают сотен тысяч и миллионов строк текста, а объемы баз данных измеряются уже терабайтами (1 Тбайт = 10¹² байт). Трудоемкость создания таких программных средств измеряется сотнями и тысячами человеко-лет. С другой стороны, динамика общественных процессов требует значительного ускорения разработки программных средств, снижения трудоемкости и обеспечения возможности их совершенствования в процессе эксплуатации.

В 1995 г. компания Standish Group проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделала следующие выводы.

Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме, качество получаемого программного обеспечения не устраивало потребителей; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такие проекты порождаются самыми различными причинами, например:

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

• воздействием неожиданных правительственных решений;

• политическими «играми» высшего руководства;

• наивным оптимизмом и менталитетом первопроходцев у неопытных разработчиков.

Такие «смертельные марши» предъявляют особые требования к используемым методологиям, технологиям и средствам разработки ПО, независимо от того, объективные или субъективные причины лежат в их основе.

Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering).

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

70-е и 80-е гг. – систематизация и стандартизация процессов создания ПО (на основе структурного подхода); в 1975 г. в США появилось первое издание, посвященное программной инженерии, – IEEE Transactions on Software Engineering;

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

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

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

Современные крупные проекты ППП и ИС характеризуют, как правило, следующие особенности:

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

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

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

• необходимость интеграции существующих и вновь разрабатываемых приложений;

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

• значительная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ЭИС [3].

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

Сами компьютеры сложнее, чем большинство продуктов человеческой деятельности. Количество их возможных состояний очень велико, поэтому их так трудно понимать, описывать и тестировать. У программных же систем количество возможных состояний на порядок величин превышает количество состояний компьютеров. Поэтому попытки описать программные объекты, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Математика и физика за три столетия достигли больших успехов, создавая упрощенные модели сложных физических явлений, получая из этих моделей свойства и проверяя их опытным путем. Это удавалось благодаря тому, что сложность, игнорировавшаяся в моделях, не была существенным свойством явлений. Такой подход не работает, когда сложность является сущностью. Сложность вызывает трудности понимания всех возможных состояний программ, что, в конечном счете, приводит к снижению их надежности.