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

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

• Waterfall - традиционный подход.
• RUP (Rational Unified Process) - рациональный.
• Agile - общая методология гибкой разработки.
• Crystal Clear - подход с уравниванием разработчиков в коллективе.
• Spiral - спиральный метод.
• DSDM (Dynamic Systems Development Model) - динамическая модель.
• FDD (Feature Driven Development) - методология, рассматривающая будущие изменения.
• JAD (Joint Application Development) - ориентированный на пользователя подход.
• RAD (Rapid Application Development) - модель быстрой разработки.
• Scrum - концепция работы в условиях сорванных сроков и идеологического кризиса.
• XP (Extreme Programming) - экстремальная разработка в динамической среде.
• LD (Lean Development) - метод, предполагающий бережное отношение ко всем участникам процесса.

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

Waterfall

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

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

RUP

RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

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

Agile

Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

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

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

Crystal Clear

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

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

Spiral

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

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

DSDM

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

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

FDD

FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

• Разработка каждого крупного проекта должна иметь системность.
• Процессы должны быть простыми и проработанными.
• Ценность и логичность процесса должна быть ясна каждому члену команды.
• Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD

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

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

RAD

RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

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

Scrum

Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

XP

Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

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

LD

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

• Поощрении сотрудников за успешную работу.
• Изменении текущих задач только по мере необходимости или по запросу заказчика.
• Строгом выполнении плана: всё, что сверх - считается потерями времени и ресурсов.
• Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

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

Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - рентгеновский микротомограф , мелкий - автообновление службы Windows на AWS .

Когда использовать каскадную методологию?

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

2. «V-Model»

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

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

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

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

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется RAD-модель?

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

5. «Agile Model» (гибкая методология разработки)

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

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

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

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

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

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

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

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

Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.

С. Архипенков

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

Наиболее распространенные современные модели процесса разработки ПО представлены на Рисунке 3.

Рисунок 3 Различные модели процесса разработки ПО и их распределение по "весу"

ГОСТы

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

SW-CMM

В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Данная модель определяет пять уровней зрелости процесса разработки ПО.

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

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Унифицированный процесс (Rational Unified Process, RUP) был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

MSF

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

PSP/TSP

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [ , ]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:

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

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:

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

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

Agile

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

Выбор модели процесса

Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).

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

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

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа "Карго" - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения ("муштру") и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи "USA". Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов "Манифеста гибкой разработки ПО" проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и "гибких" до тяжелых (СММ-5) за последние 20 лет [ , ]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что:

• У каждого проекта должна быть своя модель процесса разработки.
• У каждой модели - свое время.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с "Законом 4-х П" (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта "отдохни.ру". И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Рисунок 4. "Закон 4-х П". Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала

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

Что надо делать для успеха программного проекта

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

Чтобы программный проект стал успешным, необходимо:

1. Четко ставить цели.
2. Определять способ достижения целей.
3. Контролировать и управлять реализацией.
4. Анализировать угрозы и противодействовать им.
5. Создавать команду.

1. Ставим цели

   1.1. Концепция определяет ясные недвусмысленные цели.
   1.2. Все члены команды считают концепцию реалистичной.
   1.3. У проекта имеется обоснование экономической эффективности.
   1.4. Разработан прототип пользовательского интерфейса.
   1.5. Разработана спецификация целевых функций программного продукта.
   1.6. С конечными пользователями продукта налажена двухсторонняя связь

2. Определяем способ достижения целей

   2.1. Имеется детальный письменный план разработки продукта.
   2.2. В список задач проекта включены "второстепенные" задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).
   2.3. После каждой фазы проекта обновляется расписание и бюджет.
   2.4. Архитектура и проектные решения документированы.
   2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.
   2.6. Определен план многоэтапной поставки продукта.
   2.7. В плане учтены обучение, выходные, отпуска, больничные.
   2.8. План проекта и расписание одобрен всеми участниками команды.

3. Контролируем и управляем реализацией

   3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.
   3.2. У проекта есть менеджер, причем только один!
   3.3. В плане проекта определены "бинарные" контрольные точки.
   3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.
   3.5. Между руководством и разработчиками установлены доверительные отношения.
   3.6. Установлена процедура управления изменениями в проекте.
   3.7. Определены лица, ответственные за решение о принятии изменений в проекте.
   3.8. План, расписание и статусная информация по проекту доступна каждому участнику.
   3.9. Код системы проходит автоматическое рецензирование.
   3.10. Применяется система управления дефектами.

4. Анализируем угрозы

   4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.
   4.2. Руководитель проекта отслеживает возникновение новых рисков.
   4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.

5. Работаем над созданием команды

   5.1. Опыт команды достаточен для выполнения проекта.
   5.2. У команды достаточная компетенция в прикладной области.
   5.3. В проекте имеется технический лидер.
   5.4. Численность персонала достаточна.
   5.5. У команды имеется достаточная сплоченность.
   5.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

• 0 - даже не слышали об этом;
• 1 - слышали, но пока не применяем;
• 2 - применяется частично;
• 3 - применяется в полной мере.

Поправочные коэффициенты:

• для малых проектов (до 5 человек) - 1.5;
• для средних (от 5 до 20 человек) - 1.25.

Результат:

• <40 - завершение проекта сомнительно.
• 40-59 - средний результат. В ходе проекта следует ожидать серьезные проблемы.
• 60-79 - хороший результат. Проект, скорее всего, будет успешным.
• 80-89 - отличный результат. Вероятность успеха высока.
• >90 - великолепный результат. 100% шансов на успех.

Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать. Именно об этом пойдет речь в остальных лекциях.

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

Что это?

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

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

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

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

Прогнозируемые методологии

Что относится к данным методологиям разработки программного обеспечения? Это те разновидности, которые ориентированы на детальное планирование будущего. Задачи и ресурсы известны на всем протяжении срока проекта. Отсюда рабочая команда будет с трудом реагировать на неожиданные изменения.

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

Адаптивные методологии

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

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

Гибкие методологии

Гибкие методологии разработки программного обеспечения - англ. Agile software development. Отсюда второе название: agile-методы.

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

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

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

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

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

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

Agile Manifesto

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

Agile Manifesto был разработан и принят 1-13 февраля 2001 года в лыжном комплексе в горах Юты. Содержит в себя 4 главные идеи и 12 принципов командной работе без единого практического совета.

Представим основные идеи этой современной методологии разработки программного обеспечения:

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

Также в рамках Agile Manifesto были обозначены следующие принципы деятельности разработчиков:

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

Waterfall Model

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

Благодаря такой жесткости, по данной методологии довольно легко управлять проектом. Стоимость и сроки разработки заранее определены, отчего работы проходят быстро. Но важно помнить и такой аспект: каскадная модель дает отличный итог только в проектах с заранее четко заданными требованиями, методиками их реализации. Здесь у специалистов нет шанса "сдать назад", ведь тестирование начинается только после полного завершения этапа.

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

Специалисты советуют использовать методологию "водопад" в следующих случаях:

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

V-Model

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

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

Когда необходимо использовать данную методологию для разработок:

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

Incremental Model

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

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

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

Опишем случаи, когда использование Incremental Model будет обоснованным:

• Четко определенные и понятные требования к конечному продукту.
• Допускается доработка некоторых деталей с течением времени.
• Есть несколько рисковых целей.
• Необходим ранний вывод ПО на рынок.

RAD Model

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

Процесс разработки программного обеспечения здесь включает в себя несколько этапов:

1. Бизнес-моделирование. Это определение информационных потоков между спектром подразделений.
2. Моделирование сведений. Данные, собранные на первом этапе, используются для определения сущностей, необходимых для циркуляции информации.
3. Во время этой фазы информационные потоки связывают определенные объекты для достижения цели разработки.
4. Сборка приложения. Тут используются средства автосборки для преобразования моделей проектирования в код.
5. новых компонентов и интерфейсов.

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

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

Iterative Model

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

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

Чем-то создание ПО здесь напоминает сотворение картины: сначала делается набросок, затем он заполняется цветами, добавляются детали, насыщенность, переходы оттенков, последние штрихи - и процесс завершен.

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

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

Применение итеративной модели оправдано в следующих случаях:

• Требования к конечной версии разработки понятны и четко определены.
• Проект очень масштабный.
• Основная задача заранее определена. Но ее детали допустимо совершенствовать, изменять в процессе работы.

Spiral Model

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

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

• Планирование.
• Анализирование рисков.
• Конструирование.
• Оценка итогов. Если она положительная, то разработчик переходит к новому "витку" проекта.

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

LD

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

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

XP

Весьма любопытный пример - методология так называемого экстремального программирования. Что тут скрывается? Это ведение разработки ПО в условиях постоянно изменяющихся требований к продукту. Направление методологии имеет следующие отличительные черты:

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

FDD

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

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

Ценность методологии и в том, что она четко регламентирует продолжительность процессов. При этом на организационные вопросы в каждом цикле не должно затрачиваться более 25 % времени. Остальные 75 % - сугубо на разработку, сборку, тестирование функционала.

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

Аннотация: Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.

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

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

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

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

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