Как создается программное обеспечение? Чем в своей деятельности руководствуются специалисты? В этой сфере важны методологии разработки программного обеспечения. Некоторые из них мы рассмотрим в этой статье, подробно останавливаясь на задачах, этапах, важных принципах и отличиях данных методологий.
Что это?
Начнем статью с определения. Методология разработки программного обеспечения - это совокупность принципов, система идей, и средств, которые в конечном счете будут определять стиль разработки ПО. Иными словами, методология здесь - реализация какого-либо определенного стандарта.
Что важно отметить, стандарты здесь советуют, а не предписывают, как должно быть. Поэтому перед создателем ПО сохраняется свобода выбора, адаптации теории.
Конкретные продукты реализуются через методологию разработки программного обеспечения. Она будет определять, каким образом специалист станет выполнять свою работу. Сегодня подобных методологий множество - основные мы рассмотрим по ходу материала. Что же влияет на выбор из них одной-единственной? Выделяется размер команды, сложность и специфика определенного проекта, зрелость и стабильность процессов в компании-работодателе, личные предпочтения создателя ПО.
Таким образом, методологии - это ядро теории управления разработкой какого-либо программного обеспечения. Ранее в их отношении применялась классификация, разделяющая все методологии на два типа: итерационные и водопадные (исходя из применяемых моделей жизненного цикла). Сегодня используется современная общая классификация, разделяющаяся также на две группы: прогнозируемые и адаптивные. Познакомимся с ними подробнее.
Прогнозируемые методологии
Что относится к данным методологиям разработки программного обеспечения? Это те разновидности, которые ориентированы на детальное планирование будущего. Задачи и ресурсы известны на всем протяжении срока проекта. Отсюда рабочая команда будет с трудом реагировать на неожиданные изменения.
План составляется по составу необходимых работ, требованиям к ним. Отсюда изменение требований прямо приводит к изменению всего плана, дизайна проекта. Для прогнозируемых методологий типично создание специального комитета, управляющего изменениями, чтобы в проекте учитывались только важнейшие требования.
Адаптивные методологии
В чем особенность данных методологий разработки компьютерного программного обеспечения? Они уже нацелены на преодоление ожидаемого несовершенства, неполноты требований, на постоянное изменение последних. Соответственно, с изменением требований будет заменяться и команда разработчиков проекта.
Точный план по адаптивной методологии разрабатывается только на ближайшее время. Планы, относящиеся к более удаленным от реальности событиям, существуют в форме деклараций о целях работы, ее результатах и ожидаемых затратах.
Гибкие методологии
Гибкие методологии разработки программного обеспечения - англ. 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 выступает одной из разновидностей инкрементной модели. Компоненты или функции программы здесь параллельно разрабатываются несколькими командами профессионалов. В результате получается несколько мини-проектов. Время на создание каждого из них жестко ограничено. Все модули складываются в общий рабочий прототип. Система хороша тем, что помогает быстро представить заказчику для обозрения рабочий продукт, в который затем можно внести ряд изменений.
Процесс разработки программного обеспечения здесь включает в себя несколько этапов:
- Бизнес-моделирование. Это определение информационных потоков между спектром подразделений.
- Моделирование сведений. Данные, собранные на первом этапе, используются для определения сущностей, необходимых для циркуляции информации.
- Во время этой фазы информационные потоки связывают определенные объекты для достижения цели разработки.
- Сборка приложения. Тут используются средства автосборки для преобразования моделей проектирования в код.
- новых компонентов и интерфейсов.
Использовать такой программного обеспечения следует только в том случае, когда в команде есть высококвалифицированные и "узкие" специалисты. Бюджет проекта определенно большой: нужно оплатить работу профессионалов, стоимость готового инструментария автоматизированной сборки.
Модель выбирают при уверенном знании целевого бизнеса в тех случаях, когда нужно представить готовый продукт в короткие сроки - за 2-3 месяца.
Iterative Model
Следующий пример организации разработки программного обеспечения - это итерационная (или итеративная модель). Особенностью проекта является то, что для начала его реализации не нужна полная спецификация требований. Создание начинается с конструирования базы, которая должна стать основой для определения дальнейших требований.
Версия в данном случае может быть и вовсе неидеальной. Главное требование - чтобы она работала. Разработчик понимает и видит конечную цель работы. Он должен стремиться к тому, чтобы каждый шаг его деятельности был результативен, а каждая созданная версия - работоспособна.
Чем-то создание ПО здесь напоминает сотворение картины: сначала делается набросок, затем он заполняется цветами, добавляются детали, насыщенность, переходы оттенков, последние штрихи - и процесс завершен.
Чем-то напоминает инкрементную модель? Давайте рассмотрим разницу. По инкрементной методологии продукт составляется из частей, а функционал ПО складывается, что называется, по кусочкам. Но при этом каждая часть - уже целостный элемент. А "кусочки" в итерационной модели не обладают самостоятельностью.
Еще один яркий пример разработки программного обеспечения по данной методологии: аппаратура, распознающая голос. Все началось с подготовки научной базы. Затем была собрана необходимая документация. С каждой новой разработкой качество аппаратуры повышалось. Но идеального уровня она не достигла до сих пор. Следовательно, проект еще не завершен.
Применение итеративной модели оправдано в следующих случаях:
- Требования к конечной версии разработки понятны и четко определены.
- Проект очень масштабный.
- Основная задача заранее определена. Но ее детали допустимо совершенствовать, изменять в процессе работы.
Spiral Model
Спиральная модель во многом напоминает предыдущую. Однако акцент делается еще на одну задачу разработки программного обеспечения - оценку рисков. Более всего данная методология применима для решения критических бизнес-заданий, когда неуспешность проекта может серьезно повредить деятельности компании.
Спиральную модель широко применяют при выпуске новых линеек программного обеспечения, при необходимости проведения научных исследований проекта, практической апробации. Каждый из "витков спирали" проходит в четыре фазы:
- Планирование.
- Анализирование рисков.
- Конструирование.
- Оценка итогов. Если она положительная, то разработчик переходит к новому "витку" проекта.
Спиральную модель не стоит использовать для маленьких бюджетных проектов. Напротив, она более подходит для масштабных и дорогих. Отличный пример применения методологии - для разработки системы банковского документооборота. Здесь большое внимание уделяется не столько самому программированию, сколько анализу каждого уже произведенного "витка".
LD
Так называемая бережливая разработка ПО. Является одним из ответвлений гибкой методологии, которую мы разобрали выше. Главное достоинство LD: сохранение высокого морального и функционального состояния специалистов. В частности, это следующее:
- Поощрение каждого из работников за особо успешную деятельность.
- Текущие задачи проекта изменяются только в случае крайней необходимости или же по желанию заказчика.
- Строгое выполнение плана. Сверхработы здесь считаются признаком потери как времени, так и ресурсов.
- Внедрение в работу общей концепции деятельности: "Широко мыслить, быстро ошибаться, мало работать, стремительно обучаться".
XP
Весьма любопытный пример - методология так называемого экстремального программирования. Что тут скрывается? Это ведение разработки ПО в условиях постоянно изменяющихся требований к продукту. Направление методологии имеет следующие отличительные черты:
- "Игра в планирование". В начале работ представлен лишь приблизительный план. С каждым витком разработки его четкость увеличивается.
- Высокая частота релизов. Это значит, что новая версия будет иметь лишь небольшие отличия от предыдущей, но на ее выпуск затрачивается самый минимум времени.
- Контакт с клиентом. Для следующих данной методологии важно быстро удовлетворять все требования заказчика - оперативно реагировать на все его замечания и пожелания.
- Рефакторинг. Качество кода улучшается без уменьшения его функциональности.
- Стандартное выполнение кода. На лицо или следование общим правилам, или отсутствие разногласий в процессе разработки.
- Коллективная ответственность. Да, каждый из членов команды занят определенным участком работ. Но за общий результат ответственен уже весь коллектив.
FDD
И последняя методология в нашей статье. Она обеспечивает масштабируемость и повторяемость. Но при этом поощряется творческий подход, применение в работе инноваций. Основные принципы методологии следующие:
- Разработка каждого крупного проекта - это системная деятельность.
- Все процессы должны быть простыми и хорошо проработанными.
- Логичность и ценность каждого из процессов должна быть ясна и понятна любому из членов команды.
- Предпочтение - коротким циклам разработки ПО. Это позволяет снизить количество ошибок, вместе с тем увеличивая функциональность.
Ценность методологии и в том, что она четко регламентирует продолжительность процессов. При этом на организационные вопросы в каждом цикле не должно затрачиваться более 25 % времени. Остальные 75 % - сугубо на разработку, сборку, тестирование функционала.
На этом закончим знакомство с основными разработками программного обеспечения. Как вы убедились, особенности каждой из них позволяют выбрать подходящую методологию для успешной реализации самых разнотипных проектов.
Прежде, чем предложить обзор процесса разработки, сложившегося в результате накопления опыта за последние годы, я хотел бы сделать несколько общих пояснений, которые мне кажутся существенными.Я работаю в IT последние 15 лет, хотя программированием начал заниматься значительно раньше. Основное направление моей деятельности как системного архитектора была организация разработки программ, разработка концепций и верхнеуровневой архитектуры и контроль выполнения концепции на протяжении проекта. Кроме управления разработкой ПО и создания архитектуры, я время от времени занимаюсь решением сложных технических проблем и написанием некоторых критически важных участков кода, где необходимо не только знание самого языка и среды разработки, но и их внутренней организации, иногда преподносящей неприятные сюрпризы.
Проекты, над которыми я работаю, чаще всего связаны с разработкой заказного или инвестиционного программного обеспечения. Также мне приходилось работать с встроенным ПО и программами, ориентированными на выпуск «хитов» (что, с лёгкой руки Джоэля Спольски, я называю далее игровым ПО, хотя на самом деле некоторые игровые проекты ближе к инвестиционным).
Заказное программное обеспечение может быть предназначено для внутреннего или внешнего заказчика. Эксклюзивные права на разработанную систему получает заказчик, и работа над развитием системы в дальнейшем может быть передана другому исполнителю.
В отличие от заказного ПО, работа над инвестиционным программным обеспечением ведётся самим исполнителем на деньги внутреннего или внешнего инвестора. Как правило, права на код системы остаётся у исполнителя, что стимулирует непрерывную работу по улучшению своего продукта и последовательный выпуск версий с более развитой функциональностью.
Встроенное программное обеспечение поставляется вместе с аппаратной частью и, грубо говоря, не подлежит сопровождению, поскольку отзыв партии устройств производителем – дело очень затратное и потому исключительное.
Разработка игровых хитов также практически не содержит фазы сопровождения. Кроме того, пользователи игровых программ, даже столкнувшись с ошибкой в игре, очень редко загружают обновлённую версию. Поэтому разработка игр, как правило, имеет свою экономику и свой процесс разработки.
Нашими заказчиками являются органы власти, крупные государственные и коммерческие организации и, конечно, мы сами. Поэтому в смысле заказного ПО в нашем процессе часто присутствует некоторая разница между процессами разработки продуктов для внутреннего и для внешнего заказчиков. Некоторые нюансы я укажу в этой статье. Уровень формализации отношений с заказчиком у нас варьируется от проекта к проекту очень широко. В целом, чем больше бюджет проекта, тем выше формальность. Государственный заказчик или крупные коммерческие предприятия (особенно с государственным участием) обычно имеют законодательные ограничения на формирование, размещение заказа и приёмку результатов работ. Ещё одним ограничением крупных организаций является тот факт, что их персонал, являющийся источником требований и основным пользователем наших систем, имеет очень ограниченную доступность для исполнителей, хотя бы вследствие своей занятости. Однако для небольших организаций уровень формализации падает и иногда уходит в противоположную крайность, где возникает недостаточный уровень ответственности заказчика в рамках проекта.
Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .
В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.
Наш процесс представляет собой последовательность определённых этапов. Приведённая мной классификация ПО сделана только, чтобы показать возможную разницу в организации разработки различных программных средств. Делая обзор процесса разработки, я остановлюсь только на различиях именно самого процесса касаемо разных видов ПО. Однако надо помнить, что различия между процессами разработки разных видов ПО гораздо глубже, поэтому при планировании каждого этапа необходимо учитывать эти нюансы.
Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.
Процесс разработки заказного ПО
Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.Рисунок 1. Процесс разработки заказного программного обеспечения.
Работа над проектом начинается с подготовительного этапа. Цель этапа состоит в том, чтобы на основе предложений заказчика создать некоторую концепцию будущей системы и, отталкиваясь от этой концепции, провести оценку востребованности и реализуемости проекта. Если решение о привлечении исполнителя принимается заказчиком на конкурсной основе, то предварительный этап фактически является стадией подготовки потенциального исполнителя к конкурсу, включая формирование необходимой документации.
Не нужно тратить время и ресурсы на проект, чья концепция признаётся невостребованной или нереализуемой. Такой проект должен быть завершён. В ряде случаев требуется некоторая итеративная работа с заказчиком по коррекции концепции проекта, пока либо не будет достигнут приемлемый баланс требований заказчика и затрат исполнителя, либо не будет принято решение о сворачивании работ.
Проект, концепция которого выглядит приемлемой для реализации, выходит на этап разработки требований. На этом этапе исполнитель должен сформировать перечень всех явных и скрытых потребностей заказчика. Часто оказывается, что заказчик либо не определился со своими потребностями, либо его потребности вступают в противоречие между собой, с возможностями заказчика или с возможностями исполнителя. Целями этапа являются выявление всех скрытых потребностей, решение конфликтов требований, формирование целостного технического решения и анализ реализуемости подготовленного решения.
Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.
Если техническое решение найдено, исполнитель приступает к разработке архитектуры будущей системы. Цель этапа – определение верхнеуровневой логической и физической архитектуры, полностью покрывающей все требования заказчика. При разработке архитектуры проводится рецензирование и уточнение концепции, требований и предварительного технического решения, что даёт возможность предупредить наиболее опасные риски.
После завершения проектирования архитектуры необходимо снова провести ревизию основных параметров проекта и решить, в состоянии ли исполнитель завершить проект. Полезно на стадии разработки архитектуры отказаться от излишних и слишком громоздких функций. Оптимизация архитектурного решения часто помогает вписаться в приемлемые параметры проекта. В иных случаях требуется более радикальное сокращение функционала разрабатываемой системы. Однако даже остановка проекта на этой стадии, если она происходит по веским причинам, должна восприниматься как победа: продолжение работ в таком случае может привести только к ещё большим потерям.
Если баланс был найден, и удалось создать приемлемую архитектуру системы, исполнитель может переходить к реализации и поставке системы. Реализация может проходить в один или несколько этапов. Для небольших проектов одноэтапная поставка всего функционала системы может быть вполне приемлемой. Однако, чем больше проект, тем выше зависимости подсистем внутри создаваемой системы. В этих условиях следует делить реализацию на несколько этапов так, чтобы в конце каждого этапа команда разработчиков имела готовый к поставке продукт. При этом самый важный, фундаментальный функционал должен разрабатываться на ранних этапах, а надстройки, работающие поверх этих основных компонентов, следует реализовывать позднее. В таком случае наиболее опасные для системы ошибки будут исправлены на первых этапах, и риск того, что прикладная функциональность системы будет основана на нестабильной основе, будет значительно снижен.
После поставки полностью завершённой системы проект заказного ПО обычно переходит к этапу опытной эксплуатации. Цель этого этапа заключается в проверке качества работы разработанной системы в реальных условиях эксплуатации. Как правило, на этом этапе исполнитель совместно с заказчиком проводит измерение количественных метрик, позволяющих определить качество созданной системы. В первую очередь проверяются функциональные характеристики качества, затем – нефункциональные. При наличии несоответствий исполнитель корректирует код системы.
Полностью отлаженная и настроенная система вводится в промышленную эксплуатацию. Как правило, исполнитель должен сопровождать систему, по крайней мере, в течение срока гарантии. Выявляемые несоответствия должны исправляться. Пользователи и обслуживающий персонал заказчика должны получат оперативную консультативную поддержку.
Наконец, приходит момент, когда система перестаёт устраивать заказчика по какой-либо причине. Наступает этап вывода системы из эксплуатации. Впрочем, для заказного ПО этот этап не всегда актуален, поскольку заказчик может воспользоваться своими эксклюзивными правами на систему и отстранить исполнителя от дальнейших работ по сопровождению и развитию системы ещё до того, как она потеряет актуальность.
Любой проект в конечном счёте приходит к своему завершению. Этап прекращения проекта имеет целью анализ результатов, внесение изменений в процесс разработки на основе полученного опыта и пополнение базы знаний разработчиков новыми эффективными решениями и предостережениями, а также новыми готовыми компонентами, которые можно будет использовать в следующих проектах.
Осталось отметить ещё два этапа процесса разработки. Бывает, что обстоятельства не позволяют продолжать реализацию проекта, но результаты проделанной работы показывают, что у проекта может быть будущее. Закрывать такой проект преждевременно. Поэтому вместо полной остановки работ исполнитель может временно приостановить деятельность по проекту, зафиксировав достигнутые результаты. Как только обстоятельства позволят, проект можно буде возобновить, расконсервировав инфраструктуру, вернув в проект разработчиков и восстановив состояние проекта. Важно, однако, возобновлять работу с того этапа, на котором проект был прерван, повторно проведя ревизию достигнутых результатов.
Процесс разработки инвестиционного ПО
Процесс разработки инвестиционного ПО отличается тем, что параллельно может идти работа сразу над несколькими версиями продукта: пока первая версия сопровождается, вторая уже реализуется, а для третьей формулируются требования. Процесс показан на рисунке 2.
Рисунок 2. Процесс разработки инвестиционного программного обеспечения.
Как нетрудно заметить, при разработке инвестиционного ПО имеют место те же этапы, которые были рассмотрены выше для процесса разработки заказного программного обеспечения. Но отличие состоит в том, что этапы относятся не ко всему продукту, а к отдельной версии продукта. Исключение составляет этап прекращения проекта: проект не может завершиться, пока идёт работа хотя бы над одной версией продукта.
Обратите внимание на момент начала работ над следующей версией продукта. Этот момент настаёт, как только пройден этап создания архитектуры текущей разрабатываемой версии. До этого на этапах формирования требований и создания архитектуры, как правило, идёт обсуждение, какие функции следует реализовать в текущей версии, а какие перенести на будущее. И только тогда, когда требования к текущей версии сформулированы, рецензированы и подтверждены архитектурой системы, имеет смысл думать о следующей версии.
Кроме того, после разработки архитектуры, как правило, у аналитиков и архитекторов проекта появляется некоторая свобода действий, поскольку на этапах поставки основная нагрузка ложится на программистов. Эту свободу можно использовать для проработки концепции и требований для следующей версии.
В принципе, можно перенести начало работ над следующей версией на более поздний срок. Например, вполне допустимо сначала ввести текущую версию в опытную или даже промышленную эксплуатацию, и только после этого начать работу над следующей версией. Но нужно помнить, что такое решение неприменимо в случае высокой конкуренции: вас просто опередят и выдавят с рынка. Решение нужно принимать, исходя из всего комплекса обстоятельств, влияющих на ваш бизнес.
Говоря о процессе разработки инвестиционного ПО, нужно понимать, что работа над несколькими версиями имеет ряд явных и скрытых взаимозависимостей между параллельными ветками процесса.
Во-первых, исправления несоответствий, выявленных в ранней версии, должны вноситься и в версию, где они были обнаружены, и во все более поздние версии, включая разрабатываемые. Это касается не только кода программы, но и всех остальных артефактов проекта: технической и пользовательской документации, справочной системы, оценок и планов работ и т.п. Причём исправления должны вноситься немедленно, поскольку уменьшить стоимость исправлений вам не удастся, но, если не внести исправления сразу, их стоимость на более поздних стадиях может увеличиться в десятки и даже сотни раз.
Во-вторых, для параллельной работы над несколькими версиями нужна особая инфраструктура проекта, включая организацию контроля версий кода и документации, контроля заданий и несоответствий, утилит автоматической сборки и тестирования и т.п. Нельзя допустить, чтобы работа над одной версией продукта блокировала выполнение задач по другим версиям только из-за того, что инфраструктура проекта не позволяет запустить два процесса сборки одновременно для разных версий продукта.
Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.
В-третьих, в работе над несколькими версиями могут быть одновременно задействованы одни и те же участники. Имеется большой риск, что ключевой сотрудник может погрязнуть в работе над одной версией программы и допустить существенное превышение сроков по задачам, связанным с другой версией.
В-четвёртых, имеет место обратная ситуация, когда персонал, работающий над одной версией, ничего не знает о том, какие решения принимаются в рамках работ над другой версией. Частично проблема снимается, если исправления всей документации и кода будут немедленно распространяться на все более поздние версии, о чём я говорил выше. Но одними исправлениями дело не должно ограничиваться. Нужно, чтобы команда, работающая над одной версией, понимала, почему были приняты те или иные решения при работе над другой версией. Для этого нужна база знаний для разработчиков – специальная информационная система, в которой должны описываться все проблемы, с которыми столкнулись разработчики при работе над той или иной версией продукта, и способы решения этих проблем. База знаний должна рассылать всем участникам проекта уведомления о поступлении новых записей. Нельзя пускать на самотёк взаимодействие двух команд, работающих над разными версиями одного продукта.
Процесс разработки встроенного ПО
Как уже отмечалось выше, встроенное ПО отличается от заказного тем, что его крайне сложно сопровождать.Допустим, вы выпускаете программы для холодильников. После того, как ПО поставлено производителю, десятки тысяч устройств начинают расходиться по всему миру, и вы понятия не имеете, где они окажутся. И если один из холодильников выйдет из строя по вине вашего софта, то проще заплатить неустойку, чем возвращать холодильник на завод и проводить диагностику. Конечно, можно подготовить инженеров для дилерских центров, которые смогут провести диагностику на месте и заменить прошивку вашей системы, но это всё равно очень дорого.
Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.
Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.
Во-вторых, при поставке вы должны уделить особое внимание качеству программы, поскольку с момента внедрения её внутрь железного ящика менять её будет очень сложно. Особое внимание нужно уделить этапу опытной эксплуатации, когда программа внедряется в ограниченную партию устройств, и эти устройства проходят комплексные испытания в различных режимах эксплуатации. Вы должны собрать максимум информации о динамике поведения вашей системы, проанализировать эту информацию и доработать ПО.
В-третьих, когда устройство с вашим ПО ушло в серию, вы имеете очень мало возможностей для исправления ошибок. По факту, такие исправления возможны только в случае брака ПО, приводящего к неработоспособности всей партии устройств, из-за чего производитель будет вынужден отозвать эту партию, а вы получите большое чёрное пятно на свою репутацию.
Наконец, в-четвёртых, этапа вывода из эксплуатации у встроенного ПО нет. Программу просто выбрасывают вместе с устройством. Поэтому, как только для партии устройств, в которых работает ваше ПО, истекает гарантийный срок, можно переходить к закрытию проекта.
Процесс разработки встроенного ПО показан на рисунке 3.
Рисунок 3. Процесс разработки встроенного программного обеспечения.
Процесс разработки игр
Игровое программное обеспечение было выделено мной по причине специфики их производства и эксплуатации. Бизнес игрового ПО основан на выпуске хитов. Один успешный хит оплачивает расходы на создание нескольких игр, которые остаются незамеченными пользователями. Поэтому процесс разработки одной игры взаимосвязан с процессами разработки других игр.Ещё одним фактором, выделяющим производство игр, является тот факт, что игра интересна пользователю либо пока он не прошёл последний уровень, либо пока у него не произошла фатальная ошибка. Это значит, что вторую версию игры он не будет покупать или даже бесплатно загружать только ради исправлений нескольких ошибок.
Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.
Рисунок 4. Процесс разработки игрового программного обеспечения.
Нужно отметить следующие особенности процесса разработки игрового ПО.
Прежде всего, при производстве игр крайне важно качество концепции. Если концепция игры не позволяет создать хит, то дальнейшая работа бессмысленна. Ситуация, когда большинство проектов заканчиваются на подготовительном этапе, для разработки игрового ПО типична.
При разработке требований и архитектуры для игрового ПО часто повторно используются наработки, полученные при работе над предыдущими проектами. В этом плане также дополнительный вес получает этап прекращения проекта, когда все полезные наработки должны быть зафиксированы в базе знаний разработчиков.
Поставка игрового программного обеспечения происходит в рамках одного единственного этапа. Даже если сначала создаётся некое ядро, «движок» игровой системы, его работу невозможно проверить без реализации всего функционала системы.
Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.
Заключение
В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.Отмечу, что рассматриваемая здесь схема процесса является результатом обобщения моего личного опыта разработки различных программных средств. Как любое обобщение, моя схема является абстракцией. И, как любая абстракция, у неё есть свои границы применимости. Нельзя бездумно применять эту схему к конкретному проекту. Важно понимать, что каждый проект имеет свои нюансы, влияющие на организацию процесса разработки. И поэтому для каждого проекта приведённую здесь схему нужно адаптировать, а в ряде случаев потребуется разработать принципиально другой подход.
Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - , мелкий - .
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
2. «V-Model»
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии - мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.
Как пример опишем cуть одного инкремента. пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры - центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.
Когда использовать инкрементную модель?
- Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
- Требуется ранний вывод продукта на рынок.
- Есть несколько рисковых фич или целей.
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель - разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
- отчёт о проделанной работе с момента последнего Scrum’a;
- список задач, которые сотрудник должен выполнить до следующего собрания;
- затруднения, возникшие в ходе работы.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия - работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй - появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале - в мыслях, затем - на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Подытожим
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
О технологиях разработки:
.
.
.
.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите , пожалуйста.
В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия
- (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия
- (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия
Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия
Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия
Книги
- , Кон Майк. В книге "Пользовательские истории: гибкая разработка программного обеспечения" Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
- Пользовательские истории. Гибкая разработка программного обеспечения , Майк Кон. В книге`Пользовательские истории: гибкая разработка программного обеспечения` Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
Аннотация: Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии. Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.
Достоинством этой модели явилось ограничение возможности возвратов на произвольный шаг назад, например, от тестирования – к анализу, от разработки – к работе над требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг, например, от тестирования к кодированию , от ПО эта модель активно критиковалась, практически, каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что она не отражает особенностей разработки ПО . Недостатками водопадной модели являются:
- отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки;
- требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно полностью завершить разработку требований, дизайн системы и т.д. – все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии;
- интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно;
- пользователи и заказчик не могут ознакомиться с вариантами системы во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком;
- модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив "по ходу дела".
Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в оффшорных проектах 1От английского offshore – вне берега, в расширенном толковании – вне одной страны. с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF .
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной.
Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО , на следующем определяются системные требования , потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения.
Каждый виток имеет следующую структуру (секторы):
- определение целей, ограничений и альтернатив проекта;
- оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта;
- разработка и тестирование – здесь возможна водопадная модель или использование иных моделей и методов разработки ПО;
- планирование следующих итераций – анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно.
Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение.
Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели.
Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору – спираль, – и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО .