Стадии и модели жизненного цикла информационной системы

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

ГОСТ ИСО/МЭК 12207—2010 не требует использования какой-либо конкретной модели жизненного цикла, но требуется, чтобы в каждом проекте определялась подходящая модель жизненного цикла. Это позволит установить зависимость от времени последовательности, необходимой для управления IT-проектами. В то же время стандарт не содержит требований для использования какой-либо заданной совокупности стадий. Стадии жизненного информационной системы подробно описаны ГОСТ Р ИСО/МЭК 15288-2005.

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

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

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

В качестве примера рассмотрим следующие шесть стадий жизненного цикла согласно ГОСТ Р ИСО/МЭК 15288-2005:

  • 1) замысла;
  • 2) разработки;
  • 3) производства;
  • 4) применения;
  • 5) поддержки применения;
  • 6) прекращения применения и списания.

Рассмотрим эти стадии подробнее.

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

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

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

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

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

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

Модели жизненного цикла информационной системы. Базовые модели жизненного цикла информационных систем подробно представлены в работе Д. Ф. Шаффера1. Сюда входят модели:

  • 1) каскадная модель;
  • 2) V-образная модель;
  • 3) эволюционного прототипирования;
  • 4) быстрой разработки приложений;
  • 5) инкрементная;
  • 6) спиральная.

Для каждой модели определена область применения, преимущества и недостатки.

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

Каскадная модель доступна для понимания, проста и удобна в применении, ход выполнения проекта удобно проследить с помощью временной шкалы.

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

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

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

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

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

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

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

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

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

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

Модель быстрой разработки приложений RAD (rapid application development). Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах: небольшой команде разработчиков, тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок (от 2 до 6 мес.), на итерационной модели разработки1.

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

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

Модель RAD может успешно применяться в конкретной ситуации в случае, если: требования хорошо известны; пользователь имеет возможность и желание принимать участие в процессе разработки на протяжении всего жизненного цикла; разработка должна быть выполнена в определенные, достаточно короткие сроки; система имеет небольшой размер; затраты и соблюдение графика не являются самым важным вопросом; имеется невысокая степень рисков; команда обладает достаточными знаниями предметной области и навыками в использовании CASE-средств разработки (CASE — Computer-Aided Software Engineering, набор инструментов и методов программной инженерии для проектирования ПО).

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

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

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

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

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

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

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

Спиральная модель впервые представлена доктором Б. Боэмом и опубликована в журнале «IEEE Computers» в 1988 г. В ней предполагалась относительно стандартная и упорядоченная последовательность стадий разработки, т.е. спиральная модель воплощает в себе преимущества каскадной модели, а также в ней предусмотрены анализ рисков, управление ими, процессы поддержки и менеджмента, использование прототипирования или быстрой разработки приложений посредством применения языков программирования и высокоуровневых средств разработки.

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

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

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

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

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

В настоящее время в литературных источниках приведены упрощенные варианты спиральной модели.

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >