Обратная связь в Модели Водопада

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

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

Таким образом, можно сделать вывод, что модель Водопада Плоха для проектирования пользовательского интерфейса! Хотя модель водопада полезна для некоторых видов разработки программного обеспечения, она очень плохо подходит для проектирования пользовательского интерфейса.

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

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