- •5 Программная инженерия
- •5.1 Проблемы разработки по
- •5.2 Жизненный цикл по
- •5.2.1. Основные процессы жц по
- •5.2.2 Вспомогательные процессы жц по
- •5.2.3 Организационные процессы жц по
- •5.3 Модели жизненного цикла по
- •Контрольные вопросы
- •6 Стадии разработки ппп
- •6.1 Виды работ и трудоемкости
- •6.2 Формирование требований к ппп
- •6.3 Проектирование
- •6.4 Программирование
- •6.5 Тестирование
- •6.5.1 Определение и принципы тестирования
- •6.5.2 Методы тестирования
- •6.5.3 Этапы тестирования
- •6.6 Документирование ппп
- •6.7 Эксплуатация и сопровождение ппп
- •Контрольные вопросы
- •7 Качество ппп
- •7.1 Характеристики качества программного изделия
- •7.2 Основные понятия и показатели надежности программных средств
- •7.3 Дефекты программных изделий
- •7.4 Концепция качества Six Sigma
- •7.5 Стандарты iso 9000
- •Контрольные вопросы
- •8 Оценка затрат на разработку ппп
- •8.1 Экономическая эффективность пи
- •8.2 Исследование затрат на разработку ппп
- •8.3 Составляющие затрат на эксплуатацию, влияющие на процесс разработки ппп
- •8.4 Составляющие затрат на сопровождение, влияющие на процесс разработки ппп
- •Контрольные вопросы
5 Программная инженерия
5.1 Проблемы разработки по
Тенденции развития ПО, диктуемые потребностями общества в информационном обеспечении всех сторон человеческой деятельности, ведут к непрерывному росту сложности пакетов прикладных программ, баз данных и знаний, информационных систем. Масштабы таких функционально-законченных прикладных программных комплексов достигают сотен тысяч и миллионов строк текста, а объемы баз данных измеряются уже терабайтами (1 Тбайт = 1012 байт). Трудоемкость создания таких программных средств измеряется сотнями и тысячами человеко-лет. С другой стороны, динамика общественных процессов требует значительного ускорения разработки программных средств, снижения трудоемкости и обеспечения возможности их совершенствования в процессе эксплуатации.
В 1995 г. компания Standish Group проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделала следующие выводы.
Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме, качество получаемого программного обеспечения не устраивало потребителей; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%.
В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28%, соответственно).
В числе причин возможных неудач фигурируют:
-
нечеткая и неполная формулировка требований к ПО;
-
недостаточное вовлечение пользователей в работу над проектом;
-
отсутствие необходимых ресурсов;
-
неудовлетворительное планирование;
-
частое изменение требований и спецификаций;
-
новизна используемой технологии для организации;
-
отсутствие грамотного управления проектом;
-
недостаточная поддержка со стороны высшего руководства.
Эдвард Йордан, один из ведущих мировых специалистов в области программной инженерии, анализируя причины неудач, отмечал, что множество проектов выполнялось в экстремальных условиях. Для таких проектов он даже предложил название «death march», буквально – «смертельный марш»1. Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50%. По отношению к проектам создания ПО это означает наличие, как минимум, одного из следующих ограничений:
-
план проекта сжат более чем наполовину по сравнению с нормальным расчетным планом, т. е. работа, требующая в нормальных условиях 12 календарных месяцев, должна быть выполнена за 6 месяцев или менее. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;
-
количество разработчиков уменьшено более чем наполовину, в сравнении с действительно необходимым для данного проекта, - как правило, по причине сокращения штатов компании в результате кризиса, реорганизации, реинжиниринга и т.д.;
-
бюджет и связанные с ним ресурсы урезаны наполовину, что влечет за собой уменьшение числа нанимаемых разработчиков или привлечение малооплачиваемых неопытных молодых разработчиков;
-
требования к функциям, возможностям, производительности и другим техническим характеристикам проекта вдвое превышают значения, которые они могли бы иметь в нормальных условиях.
Такие проекты порождаются самыми различными причинами, например:
-
высокой конкуренцией, вызванной появлением новых компаний на рынке или новых технологий;
-
воздействием неожиданных правительственных решений;
-
политическими «играми» высшего руководства;
-
наивным оптимизмом и менталитетом первопроходцев у неопытных разработчиков.
Такие «смертельные марши» предъявляют особые требования к используемым методологиям, технологиям и средствам разработки ПО, независимо от того, объективные или субъективные причины лежат в их основе.
Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering).
В процессе становления и развития программной инженерии можно выделить два этапа:
70-е и 80-е гг. – систематизация и стандартизация процессов создания ПО (на основе структурного подхода); в 1975 г. в США появилось первое издание, посвященное программной инженерии, – IEEE Transactions on Software Engineering;
90-е гг. – начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать, стандартизировать и совершенствовать, т.е. созданию ПО должно предшествовать создание методологии разработки ПО как совокупности взаимоувязанных стадий, этапов, операций, образующих технологический процесс разработки ПО.1
Освоение и правильное применение методов и средств создания ПО позволят повысить качество ППП, обеспечить управляемость процесса проектирования ППП и увеличить срок их жизни. К необходимости разработки четкой методологии (с последующей стандартизацией) приводит и все возрастающая сложность пакетов прикладных программ, создаваемых для различных областей человеческой деятельности.
Современные крупные проекты ППП и ИС характеризуют, как правило, следующие особенности:
-
сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
-
наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным);
-
отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
-
необходимость интеграции существующих и вновь разрабатываемых приложений;
-
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
-
значительная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ЭИС [3].
Как уже отмечалось ранее, сложность программных систем является самым существенным и неотъемлемым их свойством. Благодаря уникальности и несхожести своих составных частей программные системы принципиально отличаются от технических систем (например, компьютеров), в которых преобладают повторяющиеся элементы.
Сами компьютеры сложнее, чем большинство продуктов человеческой деятельности. Количество их возможных состояний очень велико, поэтому их так трудно понимать, описывать и тестировать. У программных же систем количество возможных состояний на порядок величин превышает количество состояний компьютеров. Поэтому попытки описать программные объекты, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Математика и физика за три столетия достигли больших успехов, создавая упрощенные модели сложных физических явлений, получая из этих моделей свойства и проверяя их опытным путем. Это удавалось благодаря тому, что сложность, игнорировавшаяся в моделях, не была существенным свойством явлений. Такой подход не работает, когда сложность является сущностью. Сложность вызывает трудности понимания всех возможных состояний программ, что, в конечном счете, приводит к снижению их надежности.