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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.2. Реальный процесс разработки по каскадной схеме

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

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

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

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

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

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

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

Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимость в изучении старой информации. Это связано с тем, что вполне веро­ятна ситуация, когда в процессе выполнения разработки изменяется состав групп: разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.

5. Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием слож­ных взаимосвязей между различными частями проекта.

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

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

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

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

Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими за время выполнения разработки в предмет­ной области или в требованиях заказчика. Причем возврат проекта вследствие этих причин на доработку не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится» и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта — постоянно откладываться.

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскад­ной схеме', имеют повышенный уровень риска. Этот вывод подтверждается прак­тикой: по сведениям консалтинговой компании The Standish Group, в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчи­вается неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладыва­ется и в срок, и в бюджет.

Поиск по сайту: