Преимущества каскадной модели

 

Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема. Ниже перечислены эти преимущества:

 

· модель хорошо известна потребителям, не имеющим отношения к разработке и экс­плуатации программ, и конечным пользователям (она часто используется другими организациями для отслеживания проектов, не связанных с разработкой ПО);

· она весьма доступна для понимания, так как преследуется простая цель — выпол­нить необходимые действия;

· она проста и удобна в применении, так как процесс разработки выполняется поэтапно;

· ее структурой может руководствоваться даже слабо подготовленный в техниче­ском плане или неопытный персонал;

· она отличается стабильностью требований;

· она представляет собой шаблон, в который можно поместить методы для выпол­нения анализа, проектирования, кодирования, тестирования и обеспечения;

· она хорошо срабатывает тогда, когда требования к качеству доминируют над тре­бованиями к затратам и графику выполнения проекта;

· она способствует осуществлению строгого контроля менеджмента проекта;

· при правильном использовании модели дефекты можно обнаружить на более ран­них этапах, когда их устранение еще не требует относительно больших затрат;

· она облегчает работу менеджеру проекта по составлению плана

· она позволяет участникам проекта, завершившим действия на выполняемой ими фазе, принять участие в реализации других проектов;

· она определяет процедуры по контролю за качеством. Каждые полученные дан­ные подвергаются обзору. Такая процедура используется командой разработчиков для определения качества системы;

· стадии модели довольно хорошо определены и понятны;

· ход выполнения проекта легко проследить с помощью использования временной шкалы (или диаграммы Гантта), поскольку момент завершения каждой фазы ис­пользуется в качестве стадии.

 

Недостатки каскадной модели

 

Но при использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующими недостатки:

 

· в основе модели лежит последовательная линейная структура, в результате чего каждая попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;

· она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;

· интеграция всех полученных результатов происходит внезапно в завершающей стадии работы модели. В результате такого единичного прохода через весь про­цесс, связанные с интегрированием проблемы, как правило, дают о себе знать слишком поздно. Следовательно, проявятся не обнаруженные ранее ошибки или конструктивные недостатки, повысить степень риска при небольшом задаче вре­мени на восстановление продукта;

· у клиента едва ли есть возможность ознакомиться с системой заранее, это проис­ходит лишь в самом конце жизненного цикла. Поскольку готовый продукт не дос­тупен вплоть до окончания процесса, пользователь принимает участие в процессе разработки только в самом начале — при сборе требований, и в конце — во время приемочных испытаний;

· пользователи не могут убедиться в качестве разработанного продукта до оконча­ния всего процесса разработки. Они не имеют возможности оценить качество, ес­ли нельзя увидеть готовый продукт разработки;

· у пользователя нет возможности постепенно привыкнуть к системе. Процесс обуче­ния происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;

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

· все требования должны быть известны в начале жизненного цикла, но клиенты редко могут сформулировать все четко заданные требования на этот момент раз­работки. Модель не рассчитана на динамические изменения в требованиях на про­тяжении всего жизненного цикла, так как получаемые данные "замораживаются". Использование модели может повлечь за собой значительные затраты, если тре­бования в недостаточной мере известны или подвержены динамическим измене­ниям во время протекания жизненного цикла;

· возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

· модель основана на документации, а значит, количество документов может быть избыточным;

· весь программный продукт разрабатывается за один раз. Нет возможности раз­бить систему на части. В результате взятых разработчиками обязательств разрабо­тать целую систему за один раз могут возникнуть проблемы с финансированием проекта. Происходит распределение больших денежных средств, а сама модель едва ли позволяет повторно распределить средства, не разрушив при этом проект в процессе его выполнения;