
- •Тема 2. Стандартизация проектирования информационных систем
- •2.1. Функциональные стандарты проектирования ис
- •2.1.1. Стандарты описания сервисов ис
- •2.1.2. Стандарты описания интерфейсов ис
- •Стандарты графического пользовательского интерфейса
- •Стандартизация эргономических принципов пользовательского интерфейса
- •2.1.3. Стандарты описания протоколов ис
- •2.2. Технологические стандарты проектирования ис
- •2.2.1. Модели жизненного цикла ис
- •2.2.1.1. Каскадная модель жизненного цикла ис
- •2.2.1.2. Каскадная модель с промежуточным контролем
- •2.2.1.3. Спиральная модель жизненного цикла ис
- •2.2.1.4. Итеративная (инкрементальная) модель жизненного цикла ис
- •2.2.1.5. Модель жизненного цикла «через тестирование»
- •2.2.2. Стандарты жизненного цикла ис
- •2.2.2.1. Международный стандарт проектирования iso/iec 12207
- •Содержание основных процессов жц по ис (iso/iec 12207)
- •2.2.2.2. Международный стандарт проектирования iso/iec 15288
- •2.2.2.3. Стандарт быстрой разработки приложений rad
- •2.2.2.4. Стандарт проектирования rup
2.2.1.1. Каскадная модель жизненного цикла ис
В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений применялась каскадная модель ЖЦ. Еео основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная модель ЖЦ ИС
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Несмотря на это многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. Основные причины, по которым каскадная модель сохраняет свою популярность, следующие:
1. Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.
2. Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта.
3. Проблемы внедрения при использовании итерационной модели. В некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение информационной системы для бизнеса возможно, но сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы «внедрять систему один раз».
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.