История каскадной модели в проектировании информационных систем

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

Вывод по главе II

 

 

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

 

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная  модель (характерна для периода после 1986.г.).

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

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

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

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

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

Таким образом, в курсовой работе рассмотрена история каскадной модели в проектировании информационных систем. Определены понятия «информационная система», «каскадная модель»; рассмотрены основные процессы жизненного цикла информационных систем. Выявлены достоинства и недостатки использования каскадной модели в разработке информационных систем.

 

 

 

 

 

 

 

 

 

 

Список использованных источников

 

1. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем [Текст] / А. М. Вендров. – М.: Финансы и статистика, 2000. – 352 с.
2. Гагарина,  Л. Г. Основы технологии и разработки программных продуктов: учеб. [Текст] / Л. Г. Гагарина. – М: ФОРУМ – ИНФРА –2006. – 362 с.
3. Каскадная модель [Электронный ресурс] : [web-сайт]. -  Режим доступа : http://ru.wikipedia.org/. – 01.04.2012.
4. Канер, С. Тестирование программного обеспечения: пер. с англ. [Текст] / С. Канер, Д. Фолк, Е. Кен Нгуен.  – Киев: ДиаСофт, 2000. – 544 с.
5. Информатика: учеб. [Текст] / под ред. Макаровой Н. В. – М. : Финансы и статистика, 2005. – 480 с.
6. Информационная система [Электронный ресурс] : [web-сайт]. -  Режим доступа : http://ru.wikipedia.org/. - 24.05.12.
7. Петров, В. Н., Информационные системы: [Электронный ресурс] : [web-сайт]  / В. Н. Петров, Ю. С. Избачков. – учеб. для вузов, 2-е изд. – Сор. 1997-2012, изд. дом «Питер». - Режим доступа : http://www.iworld.ru/attachment.php?barcode=978546900641&at=exc&n=0
8. Семенов, М. И.  Архитектура компьютерных систем и сетей: уч. пос. [Текст] / М. И. Семенов, И. Т. Трубилин, В. И. Лойко,  Т. П. Барановская. – М Финансы и статистика, 2004. – 320 с.
9. Смирнова, Г. Н., Проектирование экономических информационных систем. – учеб. [Текст] / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. - М. : Финансы и статистика, 2001. –328 с.
10. Советов, Б. Я.  Информационные технологии [Текст] / Б. Я. Советов, В. В. Цеханковский. – М. : Высшая школа, 2003.
11. Соммервилл, И. Инженерия программного обеспечения [Текст] / И. Соммервилл. – М. : СПБ. : Киев: Изд. дом «Вильямс», 2002. – 624 с.
12. Фридман, А. Л. Основы объектно-ориентированной разработки программных систем [Текст] / А. Л. Фр<spa