Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ , получаемые результаты, методы и средства, необходимые для выполнения работ , роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

В настоящее время известны и используются следующие модели жизненного цикла :

• Каскадная модель ( рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• ( рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
• Спиральная модель ( рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов ( макетирования ).

Рис. 2.1.

Рис. 2.2.

Рис. 2.3.

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

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

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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

Жизненный цикл ПО

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла программного обеспечения (ЖЦ ПО).

ЖЦ – это модель различных состояний программного изделия, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его выхода из употребления у всех пользователей.

ЖЦ баз данных пока стандартами не регламентирован – существующие стандарты относятся только к ЖЦ программных средств.

Стандарты ЖЦ ПС могут использоваться как директивные, руководящие или рекомендательные документы.

Наиболее полно ЖЦ, технология разработки и обеспечения качества ПС отражены в стандартах ISO (International Standards Organisation – Международная организация по стандартизации). Стандарт ISO 12207:1995 – «Процессы жизненного цикла программных средств» - наиболее полно отражает архитектуру, работы, организацию и управление ЖЦ ПС.

Используемые реально в фирмах модели ЖЦ ПС в последнее время изменяются относительно приведенных в стандартах в связи с внедрением и развитием объектно-ориентированного анализа и методов быстрой разработки ПП, CASE-систем и языков четвертого поколения. В новых моделях сокращаются работы по непосредственному созданию программных компонентов и детализируются работы по системному анализу и проектированию ПС и БД.

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

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

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

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

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO /IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO /IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы , обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

Разработка ПО включает в себя , как правило:

· анализ;

· проектирование;

· реализацию (программирование).

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

На эту фазу прихо­дятся, как правило, 50% стоимости ПИ и 32% трудозатрат.

Эксплуатация начинается тогда, когда изделие пере­дается пользователю, находится в действии и используется.

Включает в себя:

Работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей;

Обеспечение эксплуатационной документацией;

Проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения,

Модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.

Фазу сопровождения также называют фазой продолжаю­щейся разработки.

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

Практиками признано, что эта часть жизнен­ного цикла (ЖЦ) должна приниматься во внимание с момента начала разработки с целью совершенствования ПИ в соответ­ствии с потребностями пользователя.

Процесс сопровождения , продолжатся собственно параллельно эксплуатации ПИ.

Структура трудозатрат на различные виды деятельности по сопровождению такова, что на изменение функциональных возможностей ПИ уходит около 78% времени, а на выявление ошибок - 17%.

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

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

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

Каждый процесс характеризуется:

определенными задачами и методами их решения,

исходными данными, полученными на предыдущем этапе,

результатами.

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

Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. (Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи , включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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

Рис. 1. Каскадная схема разработки ПО

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

· Выявление причин, по которым необходимо изменять проект на поздних стадиях : проверка работоспособности и реализуемости проекта приложения на ранних стадиях, как правило, не выполняется.

· Неадекватное управление рисками : риски связанные с проектом, выявляются на поздних стадиях выполнения проекта.

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

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

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

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

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

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

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

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

Рис. 3. Спиральная модель ЖЦ

При создании ПО может быть использована «Модель переиспользования и реверсивной инженерии».

В ней основной вес проектных решений падает на проектирование. Целью данной модели является повторное использование (переиспользование) в текущих проектах хорошо проверенных на практике «старых» проектных решений, зафиксированных в библиотеках уже законченных проектов. В процессе анализа и предварительного проектирования намечаются планы работ, в которые включены, в том числе задачи проверки альтернативных проектных решений. Затем запускаются работы по созданию запланированных прототипов по каскадной схеме. В результате выбирается одно из альтернативных решений, разрабатываемых в параллельных витках для остаточного цикла разработки продукта. Возможен выбор смешанного варианта на основе объединения результатов нескольких витков.

В случае неудачи реализованной версии возможен откат по проекту (Reengineering).

Под моделью ЖЦ понимается структура, определяющая последовательностьвыполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ ПО.

Модель ЖЦ зависит от специфики ПО и специфики условий, в которых оно создается и функционирует.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любого конкретного ПО определяет характер процесса его создания.

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

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

В состав ЖЦ ПО обычно включаются следующие этапы:

1) формирование требований, предъявляемых к ПО;

2) проектирование структуры ПО;

3) реализация;

4) тестирование;

5) ввод в действие;

6) эксплуатация и сопровождение;

7) снятие с эксплуатации.

На каждом этапе могут выполняться несколько процессов, оп­ределенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу.

К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ .

1) Каскадная модель (1970-1980 гг.) предполагает переход на следующий этап после полного завершения работ предыдущего этапа.

2) Поэтапная модель с промежуточным контролем (1980-1985 гг.) — итерационная модель разработки ПО с циклами обратной связи между этапами.

3) Спиральная модель (1986-1990 гг.) делает упор на начальные этапы ЖЦ (анализ требований, проектирование спецификаций, предварительное и детальное проектирование).

Основные характеристики каскадного способа :

Разбиение всей разработки на этапы;

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

Возможность планировать сроки завершения всех работ исоответствующие затраты;

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

Исходными для каждого этапа являются документы и решения, полученные на предыдущем этапе.

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

Рис. 4.1. Каскадная модель разработки программного обеспечения

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

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

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

Поэтому реально каскадная модель создания ПО имеет вид, показанный на рис. 4.2.

Рис. 4.2. Модель с промежуточным контролем

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 4.3), делающая упор на начальные этапы ЖЦ: анализ требований, определение спецификаций и проектирование (предварительное и детальное) .

Рис. 4.3. Спиральная модель жизненного цикла

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

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

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

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

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

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

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

Другими недостатками спиральной модели являются:

Трудоемкость внесения изменений;

Большой объем документации по проекту, затрудняющий программирование;

Сложность переноса на другие платформы.

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

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

3.2. Каскадная стратегия

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

Рис.3.1. Каскадная стратегия

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

Достоинства модели:

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

Выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).

Недостатки модели:

Реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;

Основана на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;

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

3.3. Инкрементная стратегия

Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта.

Рис.3.2. Инкрементная стратегия

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

Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка версиями ведется в силу разного рода причин:

Отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

Отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;

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

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

3.4. Спиральная стратегия

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Рис. 3.3. Спиральная стратегия

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

Достоинства модели:

Позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;

Допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;

Обеспечивает большую гибкость в управлении проектом;

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

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

Уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

Увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

3.5. Сравнительный анализ моделей

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

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

Таблица 3.1. Сравнение моделей жизненного цикла

Характеристика проекта	Модель (стратегия)
Новизна разработки и обеспеченность ресурсами	Типовой. Хорошо проработаны технология и методы решения задачи		Нетиповой (новаторский). Нетрадиционный для разработчика
	Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки	Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Малые и средние проекты	Средние и крупные проекты	Любые проекты
Сроки выполнения проекта	До года	До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия и есть итоговый результат проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями (версиями)	Нет	Да	Да
Распространение промежуточного ПО	Нет	Может быть	Да

В табл. 3.1 не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.

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

- ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

- модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ), а также изменения, связанные с устранением ошибок, усовершенствованием;

- версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

- развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.

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

3.6. Методологии, поддерживающие спиральную модель

В настоящее время имеется несколько методологий 1 разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

3. Дайте краткую характеристику методологий и .

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

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

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

Что может быть проще? Даже если у Вас очень маленький проект, Вы все равно проходите эти базовые шаги, хотя бы даже проделывая некоторые из них в голове. К примеру, если у Вас 40-часовой (на одну рабочую неделю) проект разработки или улучшения документа, может показаться что Вы сразу же бросаетесь в фазу "Реализация". Но так ли это? Наиболее вероятно, что Вы получили какого-либо рода поручение с требованиями или пожеланиями, которые придется осмыслить (Анализ) и трансформировать в замысел будущего содержания (Проектирование). Затем вы воплощаете замысел (Реализация), проверяете результат (Тестирование) и передаете для использования (Внедрение).

Водопадная (каскадная) схема включает несколько важных операций, применимых ко всем проектам:

* составление плана действий по разработке системы;

* планирование работ, связанных с каждым действием;

* применение операции отслеживания хода выполнения действий с контрольными этапами.

Графическая иллюстрация “водопадной модели” проектного цикла

Рисунок.3 Водопадная модель жизненного цикла проекта

Преимущества водопадной (каскадной) модели.

Каскадная модель имеет преимущества, если ее использовать в проекте, для которого она достаточно приемлема.

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

b. Она упорядоченно справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы.

c. Она доступна для понимания, так как преследуется простая цель - выполнить необходимые действия.

d. Она проста и удобна в применении, так как процесс разработки выполняется поэтапно.

e. Она отличается стабильностью требований.

f. Она представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и обеспечения.

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

h. Она определяет процедуры по контролю за качеством. Каждые полученные данные подвергаются обзору. Такая процедура используется командой разработчиков для определения качества системы.

i. Ход выполнения проекта легко проследить с помощью использования временной шкалы (диаграммы Ганта), поскольку момент завершения каждой фазы используется в качестве стадии.

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

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

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

b. У клиента не всегда есть возможность ознакомиться с системой заранее, это происходит лишь в самом конце жизненного цикла.

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

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

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

f. Все требования должны быть известны в начале жизненного цикла, но клиенты не всегда могут сформулировать все четко заданные требования на этот момент разработки.

В то время, как "водопад" универсален и может применяться в любом проекте, другие модели жизненного цикла могут оказаться более результативными и эффективными в зависимости от характеристик проекта. Например, если Вы устанавливаете пакет программного обеспечения, Вы пропускаете фазы проектирования и реализации. Подобным же образом, если Вы занимаетесь опытно-конструкторскими разработками, Вы можете использовать специфическую модель жизненного цикла R&D проекта, учитывающую, что проделанная работа или часть ее может пойти в мусорную корзину. Другие важные модели жизненного цикла могут использоваться для ускорения проектов определенного вида. Проекты в области информационных технологий, к примеру, часто используют итеративную либо быструю (Agile development) разработку.

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

Итеративный подход (англ. iteration -- повторение) -- выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование -- Реализация -- Проверка -- Оценка (англ. plan-do-check-act cycle).

Преимущества итеративного подхода:

1. снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

3. акцент усилий на наиболее важные и критичные направления проекта;

4. непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

5. раннее обнаружение конфликтов между требованиями, моделями и 6.реализацией проекта;

8. эффективное использование накопленного опыта;

9. реальная оценка текущего состояния проекта и, как следствие, большая 10.уверенность заказчиков и непосредственных участников в его успешном завершении.

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

Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. “Разрыв” в квалификации специалистов разных областей знаний.

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

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

оценка и разрешение рисков,

определение целей,

разработка и тестирование,

планирование.

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты.

Преимущества спиральной модели:

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

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

b Обеспечивается определение непреодолимых рисков без особых затрат.

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

d Она обеспечивает разбиение большого потенциального объема работы по разработке продукта на небольшие части.

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

f Реализовано преимущество инкрементной модели, а именно выпуск инкрементов, сокращение графика посредством перекрывания инкрементов и неизменяемость ресурсов при постепенном росте системы.

Недостатки спиральной модели:

При использовании спиральной модели относительно проекта, для которого она не подходит в достаточной мере, проявляются следующие недостатки:

a Спираль может продолжаться до бесконечности.

b Большое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной и внешней документации.

c Использование модели может стать дорогостоящим, так как время, затраченное на планирование, повторное определение целей, анализа рисков и прототипирование, может быть чрезмерным.

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

Эта модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результаты финальной итерации содержит всю требуемую функциональность продукта.

Преимущества инкрементной модели.

Применяя инкрементную модель при разработке проекта, для которого она подходит в достаточной мере, можно убедиться в следующих ее преимуществах:

a Не требуется заранее тратить средства на разработку всего проекта.

b В результате выполнения каждого инкремента получается функциональный продукт.

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

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

e В процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента, последовательно работала одна и та же команда.

f В конце каждой инкрементной поставки существует возможность пересмотреть риски, связанного с затратами и соблюдением установленного графика.

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

h Риск распределяется на несколько меньших по размеру инкрементов, и не сосредоточен в одном большом проекте разработки.

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

При использовании этой модели относительно проекта, для которого она подходит не в достаточной мере, проявляются следующие недостатки:

a В модели не предусмотрены итерации в рамках каждого инкремента.

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

c Заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены.