Сравнительный анализ моделей жизненного цикла программного обеспечения. Шаги процесса программирования по Райли. Инкрементная модель ЖЦ

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

Рис.3.1. Каскадная стратегия

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

Достоинства модели:

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

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

Недостатки модели:

Реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;

Основана на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;

Основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.

3.3. Инкрементная стратегия

Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта.

Рис.3.2. Инкрементная стратегия

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

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

Отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

Отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;

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

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

3.4. Спиральная стратегия

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Рис. 3.3. Спиральная стратегия

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

Достоинства модели:

Позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;

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

Обеспечивает большую гибкость в управлении проектом;

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

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

Уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

Увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

3.5. Сравнительный анализ моделей

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

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

Таблица 3.1. Сравнение моделей жизненного цикла

В табл. 3.1 не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.

При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно следует понимать:

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

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

- версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

- развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.

В соответствии с приведенной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче версия или очередь системы. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения следует рассматривать ревизии и модификации. Как было отмечено выше, частая передача ревизий и модификаций конечным пользователям (особенно занятым другими производственными делами) нежелательна. Согласно смена версий информационных систем на железнодорожном транспорте должна выполняться не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц.

3.6. Методологии, поддерживающие спиральную модель

В настоящее время имеется несколько методологий 1 разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

3. Дайте краткую характеристику методологий и .

Глава 2. Спецификация программного продукта

Выбор жизненного цикла программного продукта

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

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

Модели жизненного цикла ПП

1. Водопадная (каскадная, последовательная) модель.

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

• Формирование требований;
• Проектирование;
• Реализация;
• Тестирование;
• Внедрение;
• Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

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

2. Итерационная модель.

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция - прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, - обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

3. V-образная модель.

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

4. Модель быстрого прототипирования.

Модель быстрого прототипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.

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

Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта база данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования.

Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой.

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

5. Спиральная модель.

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

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

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID.

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

Определение целей, альтернативных вариантов и ограничений.

Оценка альтернативных вариантов, идентификация и разрешение рисков.

Разработка продукта следующего уровня.

Планирование следующей фазы.

«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания. Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки спецификация требований (с указанием рисков и стоимости), готовится демо-версия ПО для анализа требований заказчиком.

Следующий цикл – разработка проекта – начинается с планирования разработки.

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

Следующий цикл – реализация ПО – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов.

Фаза разработки выполняется по каскадной модели с выходом – действующим вариантом (прототипом) продукта.

Отмечаются некоторые особенности спиральной модели:

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

Спиральная модель (по отношению к каскадной) имеет следующие преимущества:

• Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
• Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
• Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
• Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
• Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.

Основные недостатки спиральной модели связаны с ее сложностью:

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

Спиральную модель целесообразно применять при следующих условиях:

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

Процесс функционирования и сопровождения

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

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

● корректирующее (действия по обслуживанию) - выявление дефектов и ошибок, обнаруженных при работе;

● адаптивное - изменение ПО в ответ на изменения в вычислениях или в бизнес-среде;

● совершенствующее - развитие изделия путем добавления новых особенностей или улучшения его качества.

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

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

Жизненный цикл ПО определяет «что», но не «как» выполнять в процессе программной инженерии. Программная инженерия в значительной степени - социальное явление, определяемое внутренней организационной культурой предприятия. Предприятие может выбрать базовую модель жизненного цикла , но специфические особенности жизненного цикла и то, как работа будет сделана, уникальны для каждой организации и могут даже значительно отличаться от проекта к проекту. Программный продукт не изготавливается, он реализуется. Процесс создания и эксплуатации ПО - не эксперимент, который может быть повторен много раз с той же самой степенью успеха.

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

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

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

● Вид предметной области (необходимы различные процессы, чтобы совершенствовать бухгалтерский учет или систему контроля электростанции).

● Изменения деловой атмосферы (изменения внешнеполитических, экономических, социальных, технологических и конкурентных факторов).

● Внутренние деловые изменения (изменения в управлении, условиях работы, финансовое здоровье предприятия и т. д.).

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

При условии вышеупомянутого обсуждения подходы к жизненному циклу ПО могут быть грубо разделены на две главные категории:

● «водопад с обратной связью»;

● итеративный пошаговый.

1 Жизненный цикл «водопад с обратной связью»

Модель водопада - традиционный жизненный цикл, реализованный и популяризируемый в 1970-х годах. Об этой модели было сказано, что она успешно использовалась во многих больших проектах прошлого. Большинство этих проектов было связано с пакетными (то есть не диалоговыми) системами, реализованными на языке КОБОЛ. Сегодня жизненный цикл «водопад» используется менее часто.

Жизненный цикл «водопад с обратной связью» может быть представлен так, как изображено на рис. 1.3. Это линейная последовательность стадий, из которых предыдущая стадия должна быть закончена прежде, чем может начаться следующая.

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

Такой возврат может (хотя это бывает редко) продолжаться до начальной стадии - анализа требований.

Рисунок 1.3. Жизненный цикл «водопад с обратной связью»

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

Преимущества водопада с обратной связью:

1 Предписывает дисциплинированный подход к разработке ПО. Определяет ясные вехи в стадиях ЖЦ, облегчая, таким образом, руководство проектом.

2 Производит полную документацию для системы.

3 Требует завершения проектной документации перед переходом на следующие стадии.

4 Требует тщательного планирования проекта.

Недостатки водопада с обратной связью:

1 Критерии завершения анализа требований и проектирования системы часто не определены. Сложно определить, когда останавливаться. Опасность превышения крайних сроков.

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

3 Нет никаких возможностей для абстракции и декомпозиции в предметной области, чтобы справиться с проблемой сложности системы.

4 Документация может давать ложное представление относительно прогресса в проектировании. Имеется риск бюрократизировать работу.

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

6 Планирование проекта проводится на ранних этапах ЖЦ, когда имеется ограниченное понимание проекта. Риск неверной оценки требуемых ресурсов.

Ранее говорилось о том, что сложную программную систему построить «простыми» методами невозможно. Ее разработка с неизбежностью будет тоже сложной деятельностью.

Разработка ПО имеет следующие специфические особенности:

неформальный характер требований к ПО и формализованный основной объект разработки – программы;

творческий характер разработки;

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

при своем использовании (эксплуатации) ПО не расходуется и не изнашивается;

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

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

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

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

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

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

системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения;

качество ПО должно быть высоким;

разработка ПО должна быть осуществлена в рамках выделенного бюджета;

системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющемся ПО;

системы должны быть легко сопровождаемыми и масштабируемыми

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

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

Основным понятием программной инженерии является понятие жизненного цикла ПО .

Жизненный цикл (ЖЦ ) ПО (softwarelifecycle) – этот период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

С точки зрения статической структуры ЖЦ является совокупностью процессов ЖЦ.

Процесс ЖЦ – набор взаимосвязанных действий, преобразующих некоторые входные данные и ресурсы в выходные.

Каждый процесс характеризуется задачами, методами их решения, действующими лицами, результатами. Процессы ЖЦ протекают параллельно. Каждый процесс разделен на набор действий, каждое действие – на набор задач. Каждый процесс, действие или задача инициируется и выполняется по мере необходимости, причем не существует заранее определенных последовательностей выполнения:

основные (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные (управление, создание инфраструктуры, усовершенствование, обучение).

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

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

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

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

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

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

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

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

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

каскадная (водопадная);

эволюционная;

основанная на формальных преобразованиях;

итерационные (пошаговая и спиральная).

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

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

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

Реализация или кодирование включает процессы создания текстов программ на языках программирования.

На этапе тестирования производится собственно тестирование, а также отладка и оценка качества ПО.

Ввод в действие – это развертывание ПО на целевой вычислительной системе, обучение пользователей и т.п.

Эксплуатация ПО – это использование ПО для решения практических задач на компьютере путем выполнения ее программ.

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

Достоинства: на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности стадии работ облегчают планирование сроков завершения всех работ и соответствующих затрат. Недостатки: позднее обнаружение проблем; выход из календарного графика, запаздывание с получением результатов; высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей; избыточность документации; неравномерная нагрузка членов группы, работающей над проектом в ходе ЖЦ.

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

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

Схема эволюционной модели ЖЦ

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

Особенности итерационных моделей :

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

модель напоминает несколько последовательных «каскадов»;

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

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

Рис. 3.1.3.-1 Схема пошаговой итерационной модели ЖЦ.

Особенности итерационной спиральной модели :

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

решение о начале новой итерации принимается на основе результатов предыдущей;

досрочное прекращение проекта в случае обнаружения его нецелесообразности.

Достоинства итерационных моделей:

полный учет требований заказчика, большее его участие в проекте;

раннее обнаружение проблем и их разрешение по мере возникновения, уменьшение рисков на каждой итерации.

Недостатки итерационных моделей: сложность планирования; плохая документированность создаваемого ПО.

Рис. 3.1.3.-2 Схема спиральной модели ЖЦ

Проблемой современной программной инженерии являются «тяжелые» процессы. Характеристики «тяжелого» процесса :

необходимость документировать каждое действие разработчиков;

множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере;

отсутствие гибкости;

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

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

Диалог «лицом к лицу» – самый эффективный способ обмена информацией.

Избыточная «тяжесть» технологии (дополнительные рабочие продукты, планы, диаграммы, документы) стоит дорого.

Более многочисленные команды требуют более «тяжелых» технологий.

Большая «тяжесть» процесса подходит для проектов с большей критичностью.

Возрастание обратной связи и коммуникации сокращает потребность в промежуточных продуктах.

Дисциплина, умение и понимание противостоят процессу, формальности и документированию.

Потеря эффективности в некритических видах деятельности вполне допустима.

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

потеря удобства;

потеря важных данных и/или рабочего времени;

потеря невозместимых средств, дорогостоящего оборудования;

потеря человеческой жизни.

Основные направления развития современной программной инженерии:

Управление требованиями

Управление конфигурацией и изменениями

Управление качеством ПО

Итерационная разработка ПО

Использование компонентной архитектуры (объектно-ориентированный подход)

Визуальное моделирование ПО

Индустрия ПО развивается стремительными темпами, однако ни для кого не секрет, что процесс разработки еще очень далек от совершенства и для него характерно множество внутренних проблем. По данным исследования Standish Group (www.standishgroup.com), менее третьей части программных проектов оказываются успешными, остальные - либо не вписываются в финансовые и временны2е рамки, либо заканчиваются полным провалом.

Работающий в одиночку герой-
программист - анахронизм.
Эдвард Йордон

В упомянутом исследовании утверждается, что наиболее успешны небольшие проекты, а риск провала тем выше, чем они значительнее. Это свидетельствует о том, что с ростом масштабов задачи менеджеры не справляются с управлением выделенными ресурсами.

Собственно, проблема роста сложности управления в зависимости от увеличения размера организации далеко не нова, однако в программировании она приобретает новые очертания: если для реализации проекта в срок недостаточно ресурсов, то простое их увеличение только усугубит проблему и срок выполнения будет отодвинут еще дальше (речь идет прежде всего о человеческих ресурсах, поскольку остальные в программировании гораздо менее существенны).

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

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

Модели на основе инженерного подхода

Модель «кодирование-устранение ошибок» . Она описывается следующим образом: 1) поставить задачу; 2) выполнять ее до успешного завершения либо отмены; 3) проверить результат; 4) повторить при необходимости с 1-го шага.

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

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

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания. В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рис. 1).

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

V-образная модель . Была предложена именно для того, чтобы устранить недостатки каскадной модели, а название - V-образная, или шарнирная - появилось из-за ее специфического графического представления (рис. 2).

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

Однако в целом V-образная модель является всего лишь модификацией каскадной и обладает многими ее недостатками. В частности, и та и другая слабо приспособлены к возможным изменениям требований заказчика. Если процесс разработки занимает продолжительное время (иногда до нескольких лет), то полученный в результате продукт может оказаться фактически ненужным заказчику, поскольку его потребности существенно изменились.

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

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

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

Модели, учитывающие специфику разработки ПО

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

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

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

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

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

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

Спиральная модель. Предложенная Барри Боэмом в 1988 г., она стала существенным прорывом в понимании природы разработки ПО, хотя, по большому счету, является объединением двух моделей: каскадной и на основе создания прототипов (рис. 3).

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

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

Современные модели

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

Объектно-ориентированная модель . Данная методология предполагает конструирование программного решения из готовых объектов, для которых определяются правила их взаимодействия, переводящие объекты из одного состояния в другое. Такая модель, предусматривающая полное соответствие процесса разработки положениям объектно-ориентированной методологии (объектно-ориентированный анализ, проектирование, программирование), эффективна в крупных проектах, а также там, где применяются так называемые средства быстрой разработки (RAD, Rapid Application Development), основанные на этих технологиях и содержащие готовые библиотеки классов.

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

Таким образом, объектно-ориентированная модель применяется преимущественно в очень крупных проектах, где уделяется должное внимание этапам анализа и проектирования, а также жестко контролируется соблюдение разработчиками установленных правил.

Итеративная модель . Впервые предложенная Филиппом Крачтеном в 1995 г., данная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рис. 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах.

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

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

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

Филипп Крачтен долгое время работает в фирме Rational Software, которая сейчас принадлежит IBM. Именно по этой причине итеративная модель стала основой RUP (Rational Unified Process) - одного из наиболее распространенных методов комплексного управления процессом разработки ПО. На ее же основе разработан главный конкурент RUP со стороны Microsoft - MSF (Microsoft Solutions Framework), а также аналогичный подход компании Borland - ALM (Application Lifecycle Management).

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

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

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

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

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