8.0 Водопад против циклического управления проектами (часть 1)

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

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

  • Разработка программного обеспечения – это художественное занятие; Практически сложно предвидеть все потребности (функциональные возможности).
  • Оценить время, необходимое для разработки функции, очень сложно.
  • На протяжении всего жизненного цикла проекта пользователи должны иметь возможность тестировать все промежуточные результаты.

Разработка программного обеспечения – это творческое занятие #

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

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

Настройка реализации #

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

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

  • Автомобиль должен вмещать четырех человек;
  • Автомобиль должен иметь рулевое колесо спереди с левой стороны от водителя; • Автомобиль должен иметь педаль тормоза, педаль газа и ручной тормоз.
  • Фары автомобиля должны быть белыми, а задние фонари – красными. (очевидно, реальный список был бы огромным)

Дизайн и моделирование #

Дизайнеры создают новый дизайн, используя ваш список в качестве руководства, который затем создается много месяцев спустя. Когда вы идете по улице, вы видите, что машина остановилась. Вы понимаете, что пропустили стоп-сигналы из своего списка! Вы быстро обращаетесь к инженеру производителя автомобилей, который чуть не лопнет в ответ на ваш звонок. Вы утверждаете, что это незначительная корректировка. Однако для автопроизводителей это катастрофа. Уже произведенные автомобили должны быть полностью разобраны, провода от педалей тормоза к задней части должны быть удлинены, задняя часть автомобиля должна быть полностью переработана, чтобы соответствовать стоп-сигналам, а уже изготовленные люки багажника должны быть списаны, и этот список можно продолжить.

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