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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

Лекция 11