В однородных информационных системах 1970-х и 1980-х годов прикладные ПП представляли собой единое целое. для разработки такого типа ПП применялась каскадная модель, или «водопад» (waterfall) (рис. 6.1).
Принципиальная особенность каскадного подхода: переход на следующий этап осуществляется только после того, как будет полностью завершена работа на текущем этапе, и возвратов на пройденные этапы не предусматривается. Каждый этап заканчивается получением некоторых результатов, которые служат исходными данными для следующего этапа. Требования к разрабатываемому ПП, определенные на этапе формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания. При этом основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемого ПП - производительности, объема занимаемой памяти и др.
Преимущества каскадного способа:
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с целью предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают сложные системы с большим числом задач вычислительного характера, системы реального времени и др.
Рисунок 6.1 – Каскадная модель
В то же время данный подход обладает рядом существенных недостатков, обусловленных прежде всего тем, что реальный процесс разработки ПП никогда полностью не укладывается в такую жесткую схему. Этот процесс носит, как правило, итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим этапами уточнении или пересмотре ранее принятых решений. В результате реальный процесс разработки принимает иной вид (рис. 6.2).
Рисунок 6.2 – Схема реального процесса разработки программного продукта
Изображенную на рис . 6.2 схему часто относят к отдельной так называемой модели с промежуточным контролем, в которой межстадийные корректировки обеспечивают большую надежность по сравнению с каскадной моделью, хотя и увеличивают весь период разработки.
Основными недостатками каскадного подхода являются существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.
Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается.
Это объясняется следующими причинами:
В рамках каскадного подхода требования к ПП фиксируются в виде технического задания на все время создания, а согласование получаемых результатов с пользователями производится только после завершения каждого этапа (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПП пользователи получают систему, не удовлетворяющую их потребностям. В результате приходится начинать новый проект, который может постигнуть та же участь.