Основные достоинства каскадной модели

Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошозарекомендовала себя при выполнении различного рода инженерных разработоки получила широкое распространение. Рассмотрим основные достоинствамодели «водопад»:

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

• выполняемые в логичной последовательности этапы работ позволяют планироватьсроки завершения и соответствующие затраты.

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

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

Перечень недостатков каскадной модели при ее использовании для разработкиинформационных систем достаточно обширен. Вначале просто перечислим их, а затемрассмотрим основные из них более подробно:

· существенная задержка получения результатов;

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

· сложность распараллеливания работ по проекту;

· чрезмерная информационная перенасыщенность каждого из этапов;

· сложность управления проектом;

· высокий уровень риска и ненадежность инвестиций.

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

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

Сложность параллельного ведения работ. Отмеченные выше проблемы возникаютвследствие того, что работа над проектом строится в виде цепочки последовательныхшагов. Причем даже в том случае, когда разработку некоторых частей проекта(подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливаниеработ весьма затруднительно. Сложности параллельного веденияработ связаны с необходимостью постоянного согласования различных частейпроекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще итщательнее должна выполняться синхронизация, тем сильнее зависимы друг отдруга группы разработчиков. Поэтому преимущества параллельного ведения работпросто теряются.Отсутствие параллелизма негативно сказывается и на организации работы всегоколлектива разработчиков. Работа одних групп сдерживается другими. Покапроизводится анализ предметной области, проектировщики, разработчики и те,кто занимается тестированием и администрированием, почти не имеют работы.Кроме того, при последовательной разработке крайне сложно внести измененияв проект после завершения этапа и передаче проекта на следующую стадию.Так, например, если после передачи проекта на следующий этап группаразработчиков нашла более эффективное решение, оно не может быть использовано.Это связано с тем, что более раннее решение уже, возможно, реализовано исвязано с другими частями проекта. Поэтому исключается (или, по крайней мере,существенно затрудняется) доработка проекта после его передачи на следующийэтап.

Информационная перенасыщенность. Проблема информационной перенасыщенностивозникает вследствие сильной зависимости между различными группамиразработчиков. Данная проблема заключается в том, что при внесенииизменений в одну из частей проекта необходимо оповещать всех разработчиков,которые использовали или могли использовать эту часть в своей работе.Когда система состоит из большого количества взаимосвязанных подсистем,то синхронизация внутренней документации становится важной самостоятельнойзадачей.Причем синхронизация документации на каждую часть системы — это не болеечем процесс оповещения групп разработчиков. Самим же разработчикам необходимоознакомиться с изменениями и оценить, не сказались ли эти измененияна уже полученных результатах. Все это может потребовать проведения повторноготестирования и даже внесения изменений в уже готовые части проекта.Причем эти изменения, в свою очередь, должны быть отражены во внутреннейдокументации и быть разосланы другим группам разработчиков. Как следствие,объем документации по мере разработки проекта растет очень быстро, так чтотребуется все больше времени для составления документации и ознакомленияс ней.Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимостьв изучении старой информации. Это связано с тем, что вполне вероятнаситуация, когда в процессе выполнения разработки изменяется состав группыразработчиков (этот процесс носит название ротации кадров). Новым разработчикамнеобходима информация о том, что было сделано до них. Причем чемсложнее проект, тем больше времени требуется, чтобы ввести нового разработчикав курс дела. Сложность управления проектом при использовании каскадной схемы в основномобусловлена строгой последовательностью стадий разработки и наличием сложныхвзаимосвязей между различными частями проекта.Последовательность разработки проекта приводит к тому, что одни группы разработчиковдолжны ожидать результатов работы других команд. Поэтому требуетсяадминистративное вмешательство для того, чтобы согласовать сроки работы и составпередаваемой документации.В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущимэтапам выполнения проекта. Это приводит к дополнительным сложностямв управлении проектом. Разработчики, допустившие просчет или ошибку,вынуждены прервать текущую работу (над новым проектом) и заняться исправлениемошибок. Следствием этого обычно является срыв сроков выполнения какисправляемого, так и нового проектов. Требовать же от команды разработчиковожидания окончания следующей стадии разработки нерационально, так как приводитк существенным потерям рабочего времени.Упростить взаимодействие между группами разработчиков и уменьшить информационнуюперенасыщенность документации можно, уменьшая количество связеймежду отдельными частями проекта. Однако это обычно весьма непросто. Далеконе каждую информационную систему можно разделить на несколько слабосвязанных подсистем. Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждогоиз этапов разработки и тем сложнее взаимосвязи между отдельными частямипроекта, количество которых также увеличивается. Причем результаты разработкиможно реально увидеть и оценить лишь на этапе тестирования, то есть послезавершения анализа, проектирования и разработки — этапов, выполнение которыхтребует значительного времени и средств. Как уже было отмечено выше, запоздалаяоценка создает значительные проблемы при выявлении ошибок анализаи проектирования — требуется возврат проекта на предыдущие стадии и повторениепроцесса разработки.Однако возврат на предыдущие стадии может быть связан не только с ошибками,но и с изменениями, произошедшими за время выполнения разработки в предметнойобласти или в требованиях заказчика. Причем возврат проекта вследствие этихпричин на доработку не гарантирует, что предметная область снова не изменитсяк тому моменту, когда будет готова следующая версия проекта. Фактически этоозначает, что существует вероятность того, что процесс разработки «зациклится»и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постояннорасти, а сроки сдачи готового продукта — постоянно откладываться.Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскаднойсхеме, имеют повышенный уровень риска.