Итеративный подход

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

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

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

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

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

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

Что такое формализм в проекте?

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

Почему так важна степень формализма как характеристика методологии?

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

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

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

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

В настоящее время в России действуют старые ГОСТы 19-й и 34-й серий и более новый ГОСТ Р ИСО МЭК 122207. ГОСТы 19-й и 34-й серий жестко ориентированы на каскадный подход к разработке ПО. Разработка в соответствии с этими ГОСТами проводится по этапам, каждый из которых предполагает выполнение строго определенных работ, и завершается выпуском достаточно большого числа весьма формализованных и обширных документов. Таким образом, сразу строгое следование этим стандартам не только приводит к каскадному подходу, но и обеспечивает очень высокую степень формализованности разработки.