Содержание
Каскадная модель
Каскадная или поэтапная разработка (в некоторых источниках её называют «водопадной моделью») — процесс создания программного обеспечения представляет собой поток, последовательно проходящий фазы анализа, проектирования, реализации, тестирования, интеграции и поддержки. Так обычно строится работа над крупными проектами с длительным сроком внедрения.
Каскадная модель («Водопад»)
— высокий уровень формализации процессов;
— большое количество документации;
— жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Минусы
• Watrefall проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация
• Очень не гибкая методологии
• Может создать ошибочное впечатление о работе над проектом (например фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта)
• У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы
• У Пользователя нет возможности привыкать к продукту постепенно
• Все требования должны быть известны в начале жизненного цикла проекта
• Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков
• Отсутствует возможность учесть переделку, весь проект делается за один раз
Плюсы
• Высокая прозрачность разработки и фаз проекта
• Чёткая последовательность
• Стабильность требований
• Строгий контроль менеджмента проекта
• Облегчает работу по составлению плана проекта и сбора команды проекта
• Хорошо определяет процедуру по контроля качества
Каскадная модель с промежуточным контролем («Водоворот»)
В этой модели предусмотрен промежуточный контроль за счет обратных связей. Но это достоинство порождает и недостатки. Затраты на реализацию проекта при таком подходе возрастают практически в 10 раз. Эта модель, как вы уже поняли, является незначительной модификацией предыдущей и относится к первой группе.
При реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могут быть изменения требований, смена подрядчиков, изменения политик разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.).
Итеративная модель
Итеративная или инкрементная (эволюционная) модель приращения продукта позволяет параллельно выполнять ряд задач с непрерывным анализом результатов и корректировкой предыдущих этапов работы. Это более «скоростная» разработка для большого штата квалифицированных программистов.
Итеративные или инкрементальные модели (известно несколько таких моделей) предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части.
Каскадная модель с возможностью возвращения на предшествующий шаг при необходимости пересмотреть его результаты, становится итеративной.
Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат.
Вместе с гибкостью и возможностью быстро реагировать на изменения, итеративные модели привносят дополнительные сложности в управление проектом и отслеживание его хода. При использовании итеративного подхода значительно сложнее становится адекватно оценить текущее состояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки и ресурсы, необходимые для обеспечения определенного качества результата.
Спиральная модель жизненного цикла программного обеспечения
Спиральная методика характеризуется прохождением проектом повторяющегося цикла в каждой фазе развития: планирование — реализация — проверка — оценка (англ. plan-do-check-act cycle). Так обычно создаются проекты, с окончательно не сформированным видением результата, либо требующие ультрасрочного внедрения по этапам.
Данная модель прекрасно сочетает в себе постадийное прототипирование и проектирование. И из восходящей и нисходящей концепций в эту модель было взято все лучшее.
Преимущества модели:
1. Результат достигается в кратчайшие сроки.
2. Конкурентоспособность достаточно высокая.
3. При изменении требований, не придется начинать все с «нуля».
Но у этой модели есть один существенный недостаток: невозможность регламентирования стадий выполнения.
V модель
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования и предполагает регулярное тестирование продукта во время разработки.
V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:
• Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски.
• Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.
• Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.
• Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком.
Модель Хаоса
Вкратце Стратегия хаоса — это стратегия разработки программного обеспечения основанная на модели хаоса. Главное правило — это,всегда решать наиболее важную задачу первой.
Рекомедую ознакомится с методологиями разработки ПО и с фундаментальной теорией тестирования.
Оригинал статьи.