Этот процесс продолжается до тех пор, пока продукт не будет соответствовать всем требованиям, предусмотренным на этапе планирования. В 1970 году Уинстон Уокер Ройс описал модель разработки, как поток последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Такая модель получила название каскадной модели разработки (Waterfall). Сделал он это, чтобы показать её недостатки по сравнению с итеративной разработкой. 1) Задержка получения результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ.
- При этом обязательно обнаруживаются ошибки, которые пробуют закрыть через драйвера (программный код).
- А также, в отличие от Six Sigma или Scrum, Waterfall не требует сертификации или специального обучения для менеджеров проектов или сотрудников.
- К тому же команды, использующие каскадную методологию, ориентированы на удовлетворение требований клиентов и повышение качества обслуживания, а не на создание возможностей для инноваций.
- Каждая итерация основана на PDCA-цикле Деминга (Plan-Do-Check-Act) и завершается демонстрацией потребителю полученного промежуточного продукта с целью скорейшего выявления потенциальных ошибок.
- Но заранее предугадать все проблемы невозможно из-за высокой неопределенности, поэтому многие решения будут ошибочными, а менять проект нельзя.
Несмотря на наличие очевидных плюсов многопроходной схемы, на практике преимущественно используется однопроходная модель, адаптированная как к разработке, так и кастомизации функционала КИС. Область применения итерационной схемы видится в доработке существующих функциональных возможностей КИС. То есть, еще раз, единственное отличие «водопада» от «гибких» подходов — заключается только в длине итерации.
Agile
Самим же разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения на уже полученных результатах. Все это может потребовать проведения повторного тестирования и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации И быть разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней. Напротив, в многопроходной схеме конечное содержание программного продукта определяется пользователем, но не разработчиком. Если многопроходная схема включает чётко выраженный уровень проекта, отвечающий за управление ресурсами, сроками, рисками и прочими стратами, говорят о спиралевидной модели внедрения КИС, в противном случае – итерационной.
Далеко не каждую информационную систему можно разделить на несколько слабо связанных подсистем. Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе выполнения разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них.
Инкрементная модель
Обе схемы базируются на принципах IID, наглядно продемонстрированных на рис.7. Разрешая минус итерационной модели, касающийся отсутствия понимания объёма проекта, в 1986 году Б. Бэмом была предложена спиралевидная модель внедрения КИС (рис. 5). Данная схема сочетает в себе принципы как последовательной, так и многопроходной моделей. Основной акцент спиралевидной модели сделан на обработке 10 наиболее распространённых, по мнению Б.
После завершения этапа разработки продукт должен пройти тщательное тестирование, чтобы убедиться в том, что он соответствует поставленным требованиям. На этапе приемочного тестирования необходимо, чтобы заказчик попытался применить продукт локально точно таким же образом, как он собирается использовать его после релиза. Когда будут исправлены основные ошибки, программное обеспечение можно внедрять. Для исправления незначительных ошибок может использоваться простая система отслеживания, что позволит исправлять любые недоработки уже на этапе сопровождения ПО. Как правило, мы отдаем предпочтение спиральной модели, которая включает в себя гибкие методологии разработки Agile.
Особенности Agile
Если команда разработчиков не слишком велика, а проекты – предсказуемы, то Waterfall может обеспечить их выполнение в заданных временных рамках. В статье мы посмотрели на 2 самые распространенные модели разработки ПО, а именно Каскадную и Итеративную. Множество фреймворков и методов разработки относятся к гибким методологиям, исходя из этой статьи. С тех пор она часто критикуется за отсутствие гибкости, сниженное качество, увеличенные сроки и стоимость разработки. На этом этапе выстраиваются связи между задачами, так как новую невозможно выполнить без завершения предыдущей. Задачи декомпозируют, и к каждой из них прописывают дату начала и завершения.
Например, разводка печатных плат и взаимодействие смонтированных на них компонент сначала проектируется и отлаживается в специальных эмуляторах. Изготовления печатной платы приходится ждать несколько недель, затем нужно собрать устройство и протестировать его. При этом обязательно обнаруживаются ошибки, которые пробуют закрыть через драйвера (программный код).
Методологии? Модели? Методы?
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. каскадная модель После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований.
Для итеративной модели не обязательно наличие на старте четко определенного технического задания и требований. Например, заказчик может определить только базовый набор основных функций, а в ходе последующих итераций дополнять их новыми. Отличие от инкрементной модели состоит в том, что в итерационной дорабатывается весь продукт, а не его отдельные блоки. Смысл в том, чтобы результатом каждого цикла была работающая, пусть и неидеальная, модель. Каскадная модель используется в сферах с уже устоявшимися и подробными требованиями к выпускаемым продуктам — например в медицинской или космической, где изменения происходят небыстро. В разработке ПО она применяется главным образом в небольших и четко определенных проектах.
Преимущества каскадной модели
Одним из важных плюсов при использовании Waterfall является стремление к конечному продукту, или конечному результату, с самого начала. Для небольших проектов, где намерения достаточно ясны, этот шаг делает команду осведомленной об общей цели с самого начала, из-за чего снижается шанс заблудиться в деталях по мере продвижения проекта вперед. Подход Waterfall очень методичен, поэтому он подчеркивает важность чистой передачи информации на каждом этапе. В процессе разработки программного обеспечения, на каждом новом шаге появляются новые люди.
Вы понимаете, что продукт стоит того, чтобы его доработать, предложить более широкой аудитории и начать на нем зарабатывать деньги. И уже на этом этапе целесообразно писать подробное ТЗ для разработчиков, чтобы они устранили выявленные баги, добавили полезные функции, адаптировали продукт к требованиям рынка. Это цикл последовательно сменяющих друг друга уровней этапов, идущих в определенной последовательности, которую нельзя менять. Каскадная модель позволяет строить относительно простые ПО, четкий список требований к которым можно сформулировать изначально.
