Модель водопада была задокументирована в 1970 году доктором Уинстоном Ройсом в статье под названием «Управление разработкой больших программных систем». В основном излагаются его идеи по последовательному развитию. Его идея заключалась в том, что программное обеспечение может быть произведено аналогично автомобилю, где транспортное средство соединено в последовательную / линейную фазы.
Этот линейный подход на самом деле не учитывает изменения в программном обеспечении после его начала. Нет тесных отношений с конечным пользователем / клиентом, поэтому сложнее определить возможные проблемные области.
Стоит отметить, что некоторые этапы модели водопада допускают «всплеск», при котором в период разработки достаточно времени, чтобы вернуться назад и внести небольшие изменения. Ограничения по времени, объем работ и бюджеты не позволяют вносить значительные изменения с помощью этой модели.
Модель водопада устарела, так как время идет, программные парадигмы сами меняются. Объектно-ориентированное программирование популярно, тогда оно было едва живым. Благодаря использованию модели водопада становится очевидным, что недостатки были обнаружены, и это привело к альтернативным методологиям развития.
Хорошо, теперь альтернативы. Инкрементная модель описана Алистером Кокберном (2008) как стратегия поэтапного планирования и планирования, в которой различные части разрабатываются в разное время или с разной скоростью и интегрируются по завершении этой конкретной части.
В основном инкрементный выглядит примерно так:
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Количество преимуществ включает гибкость жизненного цикла и возможность изменений с самого начала.
Рабочее программное обеспечение или, скорее, части создаются быстро и на ранних этапах. Созданный код является более ранним для тестирования и управления из-за небольших итераций прогресса. Не все требования системы собраны заранее, просто набросок. Это позволяет быстро начать работу, однако в некоторых системах это может быть недостатком, поскольку такие вещи, как поддерживаемая архитектура системы, могут отсутствовать.
Итеративный , с другой стороны, позволяет переработать и переработать части системы, чтобы улучшить систему. Время отведено, чтобы учесть это. Итеративный не начинается с полной спецификации требований. Разработка осуществляется путем указания и реализации только части программного обеспечения. Программное обеспечение пересматривается с целью выявления дальнейших требований. Это скорее подход сверху вниз . Недостатки этой методологии - совместимость всех итераций. После утверждения каждой новой итерации разработчики могут использовать метод, известный как обратное проектирование, которое представляет собой процедуру систематического анализа и проверки, чтобы убедиться, что каждая новая итерация совместима с предыдущими. Основное преимущество постоянных итераций заключается в том, что клиент сохраняется в цикле и конечный продукт должен соответствовать требованиям.
Схема итерационного захода на посадку.
Другие методологии включают прототипирование. Эволюционный и Throwaway. Они также рассматриваются как более нисходящий подход. Оба процесса заимствованы из машиностроения. В машиностроении принято строить масштабные модели строящихся объектов. Построение моделей позволяет инженеру протестировать определенные аспекты проекта. Методология создания прототипов разработки программного обеспечения обеспечивает ту же идеологию. Прототипирование рассматривается не как отдельная, полная методология разработки, а скорее как подход к обработке отдельных частей более крупной, более традиционной методологии разработки.
Throwaway Prototyping - Throwaway Prototyping не сохраняет созданный прототип. В одноразовых прототипах нет никакого намерения превращать прототип в работающую систему. Вместо этого прототип разрабатывается быстро, чтобы продемонстрировать неясный аспект системы. Он также может быть разработан, чтобы помочь пользователям или клиентам выбирать между различными функциями или характеристиками интерфейса. После устранения любых проблем или неопределенностей прототип можно «выбросить», а изученные принципы использовать при проектировании и документировании фактического продукта.
Эволюционное прототипирование - В Эволюционном прототипировании вы начинаете с моделирования частей целевой системы, и если процесс прототипирования проходит успешно, вы развиваете остальную часть системы из этих частей. Одним из ключевых аспектов этого подхода является то, что прототип становится реальной производственной системой. Этот процесс позволяет успешно моделировать сложные части системы в прототипах и решать их на ранних этапах проекта.
Другие области, в которые следует обратить внимание, включают Agile-> SCRUM, экстремальное программирование, парное программирование и т. Д.
Пытался сделать это кратко, но люди пишут книги о таких вещах, и есть так много для обсуждения.
Может быть стоит взглянуть на:
Инкрементный и итеративный