<<
>>

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

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

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

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

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

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

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

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

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

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

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

Возврат на более ранние стадии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да­леко не каждую информационную систему можно разделить на несколько слабо связанных подсистем.

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

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

ПРИМЕЧАНИЕ------------------------------------------------------------------------------

Помимо рассмотренных существует еще один серьезный недостаток, присущий ка­скадной модели разработки, на который также следует обратить внимание.

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

<< | >>
Источник: Избачков Ю. С., Петров В. Н.. Информационные системы. 2006

Еще по теме Недостатки каскадной модели:

  1. Статья 680. Сроки выявления недостатков и предъявление требований в связи с недостатками проданного товара
  2. § 18 Прекращение обязательств. – Исполнение. – Место и время исполнения. – Срок. – Обязанность очистки или ответственность за недостатки вещи. – Иск об уравнении недостатков.
  3. Модель личности журналиста: профессиональные, социально-гражданские, нравственные, психологические и социально-демографические характеристики. Модификация общей модели для разных специализаций (репортер, аналитик, расследователь, публицист, ведущий-модератор и т.п.).
  4. 7.3. Недостатки группового интервью
  5. 7.3. НЕДОСТАТКИ ГРУППОВОГО ИНТЕРВЬЮ
  6. НАШИ НЕДОСТАТКИ
  7. 2.4.3. Преимущества и недостатки
  8. Воспользуйтесь своими недостатками
  9. Недостатки работы
  10. Статья 885. Устранение недостатков за счет заказчика