7. Жизненный цикл проекта. Стадии жизненного цикла проекта.

8. Модель «Code & Fix».(Проб и ошибок).

Являлась первой моделью разработки ПО.

Описать правила этого метода просто:

• получаем начальное понимание потребностей заказчика;

• начинаем программировать;

• когда что-то будет готово, показываем «это» заказчику;

• получив отзывы, исправляем наш код;

• повторяем цикл до полного удовлетворения заказчика (или пока у него не кончатся деньги, терпение…)

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

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

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

9. Модель водопада. Стадии, преимущества, недостатки.

Waterfall, или каскадная модель

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

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

Преимущества каскадной модели

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

Тем не менее, каскадная модель всё ещё актуальна для крупных проектов и организаций. И вот почему:

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

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

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

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

Недостатки каскадной модели

В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:

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

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

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

Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только в трёх случаях:

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

2. При наличии в штате руководителей соответствующей квалификации.

3. При исполнении проекта, не имеющего конкуренции на рынке.

https://geekbrains.ru/posts/waterfall

https://makhmetov.ru/articles/agile.html#id6

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

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