Введение. Жизненный цикл проекта по созданию (или интеграции) информационной системы на основании стандарта IEEE 1074

Жизненный цикл проекта по созданию (или интеграции) информационной системы на основании стандарта IEEE 1074

По прошествии нескольких десятилетий, индустрия создания промышленных систем пришла к выводу, что проекты по созданию информационных систем должны укладываться в некоторую дисциплину. Это привело в свою очередь к созданию такой дисциплины как инженерия информационных систем, которая ставит своей целью изучение проектов по созданию информационных систем и выработку стандартов и рекомендаций с целью повышения экономической эффективности различных видов деятельности связанных с созданием программного обеспечения. Примером организации, принимающей активное участие в становлении этой дисциплины является SEI (Software Engineering Institute) [24], которая разрабатывает группу стандартов CMM (Capability Maturity Model).

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

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

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

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

Существует ряд наиболее известных типов жизненного цикла:

• Кодирование – исправление ошибок (code and fix) – этот тип жизненного цикла является наиболее старым и представляет собой во многом хаотичный набор действий, приводящий к созданию желаемого ПО. При этом, в отсутствии чётко выделенных этапов и их артефактов, разработка почти сразу начинается с кодирования, возможно с минимальной прикидкой концепции. После чего, путём постоянного исправления, переделывания и доделывания, при удачном стечении обстоятельств получается готовое программное обеспечение. Недостатки такого подхода очевидны – отсутствует какая либо прогнозируемость результатов, всё зависит от удачного стечения обстоятельств и настроя разработчиков. Несмотря на свои очевидные недостатки, этот подход, тем не менее, имеет смысл применять для каких либо прикидок, быстрого создания прототипов, отработки технологических решений или в обучении программированию. На настоящий момент этот подход крайне не рекомендуется использовать при коммерческой разработке ПО (в рамках выполнения проекта) из за крайне высоких рисков. И всё таки, даже несмотря на это – этот подход во многом является прообразом современных гибких (Agile) методик, таких, например, как экстремальное программирование (eXtreme Programming).
• Водопадный (или каскадный) (waterfall) – это наиболее простая и понятная из формальных моделей жизненного цикла. Она характеризуется тем, что весь жизненный цикл ПО (начиная от замысла концепции и заканчивая выводом из эксплуатации), разбивается на чёткие этапы, результатом каждого из которых является чётко определённый набор артефактов, которые утверждаются, формально принимаются заказчиком и документируются. Только после этого возможен переход к следующему этапу жизненного цикла. Очевидным недостатком такого подхода, особенно в крупных и длительных проектах является повышенные риски, связанные с анализом требований, т.е. результат работы над проектом становиться известен только в конце разработки и сдачи системы, при этом если часть требований понята не верно или вообще упущено, известно об этом становится уже тогда, когда переделывать что либо является уже экономически неоправданным. И тем не менее, из-за своей простоты эта модель жизненного цикла является популярной, особенно в недлительных проектах.
• Водопадный с возвратом – это несколько модифицированная каскадная модель жизненного цикла, которая предполагает возможность возврата на один или более этапов назад по завершению (или непосредственно в процессе) любого этапа жизненного цикла. Например, в процессе разработки может выясниться неправильное истолкование какого либо требования к системе, тогда процесс возвращается до этапа анализа требований и все последующие этапы повторяются. Несмотря на то, что данный подход к организации жизненного цикла устраняет принципиальную проблему водопадной модели, а именно слишком позднее выявление ошибок, он вносит другую проблему – проект может завязнуть в возвратах и тем самым растянуться на слишком длительный срок, что ставит под угрозу вообще всю оправданности создания системы. Грубо говоря – такой проект может вообще не закончиться в разумные сроки (в литературе под максимальными разумными сроками проекта по созданию программной системы называют 2 – 4 года; проекты которые изначально в своих оценках превышают эти сроки скорее всего обречены на провал).
• Спиральный – подход предложенный Барри Боэмом в 1988 году в журнале IEEE Computer. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в неё так же включены анализ рисков, управление ими, а так же процессы поддержки и менеджмента. Модель отображает базовую концепцию, которая заключается в том, что каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. Недостатком такой модели является её относительная сложность и тяжеловесность. Поэтому, для небольших проектов её применение может оказаться неоправданной.
• Прототипирование – основным достоинством этого подхода является быстрое получение первых результатов конечным пользователем. Т.е., вместо большого и длительного цикла или этапа планирования, составления проектной документации и т.п. делается лишь минимум документации и делается прототип, который предъявляется заказчику. Заказчик может оценить правильность выбранного направления разработки и высказать свои замечания на достаточно раннем этапе проекта. Это позволяет относительно малозатратно корректировать направление развития проекта и снизить риски правильности определения требований. Однако этот подход так же не лишён недостатков. Так как система, фактически развивается циклически, но без определённого планирования циклов и итераций, система обрастает функциональностью всё больше и больше, что в конечном счёте приводит к сложности внесения дальнейших изменений и добавления функциональности. Более того, затраты на сопровождение такой системы могут быть очень большими. В результате, часто для продолжения дальнейшего развития систему приходиться переделывать с нуля.
• RAD – Rapid Application Development – этот под отличает то, что пользователь задействован на всех этапах жизненного цикла, т.е. не только на этапе сбора требований и сдачи, но и на этапах проектирования и разработки. Этой модели свойственен быстрый переход от этапа сбора требований к этапу проектирования и реализации. Результаты предоставляются пользователю в виде прототипов, которые последовательно приближаются к конечной цели реализации всей запланированной функциональности. Подход так де предполагает специальные средства для быстрой разработки приложений и создания прототипов (такие как среды разработки 4GL). (основными этапами этой модели являются: Этап планирования требований (Joint Resource Planning, JRP), пользовательское описание (Joint Application Design, JAD), фаза конструирования до полного завершения, переход на новую систему)
• Итеративный или инкрементный подход к организации жизненного цикла представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. Этот подход позволяет уменьшить затраты понесённые до момента достижения уровня исходной функциональности. Полный, заранее сформированный набор требований, разбивается на итерации и выполняется последовательно, постепенно реализую функциональность в полном объёме. Итеративный подход лежит в основе многих современных методологий, как например RUP или XP.

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

Стандарт выделяет следующие категории процессов:

1. Процесс модели жизненного цикла разработки ПО. Этот процесс включает в себя действия направленные на рассмотрение потенциально возможных моделей жизненного цикла и выбор наилучшей из ник, которую следует применить в конкретном проекте.
2. Процессы менеджмента проекта (начало выполнения проекта, мониторинг управления проектом, управление качеством ПО)
3. Этапы предварительной разработки процесса (исследование концепции, распределение системы)
4. Процессы разработки (требования, разработки проекта, внедрение)
5. Процессы сопровождения (установка, эксплуатация и поддержка, сопровождение, вывод из эксплуатации)
6. Интегрированные процессы (аттестация и верификация, менеджмент конфигурации программных средств, разработки документации, обучение)

Существует стандарт ISO/IEC 12207 который определяет набор действий аналогичный стандарту IEEE 1074:

1. Анализ системных требований;
2. Проектирование архитектуры системы;
3. Анализ программных требований;
4. Разработка проекта программной архитектуры;
5. Рабочий план разработки ПО;
6. Кодирование ПО;
7. Интеграция ПО;
8. Тестирование ПО;
9. Интеграция системы;
10. Тестирование системы;
11. Установка ПО;
12. Тестирование и приёмка ПО.

Краткое описание фаз каскадной модели

• Исследование концепции – происходит исследование требований на системном уровне с целью определения возможности реализации концепции;
• Процесс системного распределения – может быть пропущен для систем по разработке исключительно ПО. Для систем, в которых необходима разработка как программного так и аппаратного обеспечения, требуемые функции применяются к ПО и оборудованию в соответствии с общей архитектурой системы;
• Процесс определения требований – определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы;
• Процесс разработки проекта – разрабатывается и формулируется лигически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
• Процесс реализации – в результате его выполнения эскизное описание ПО превращается в полноценный программный продукт. При этом создаётся исходный код, база данных и документация, которые лежат в основе физического преобразования проекта. Если программный продукт представляет собой приобретённый пакет прикладных программ, основными действиями по его реализации будут являться установка и тестирование пакета программ. Если программный продукт разрабатывается на заказ, основными действиями являются программирование и тестирование кода;
• Процесс установки – включает установку ПО, его проверку и официальную приёмку заказчиком для операционной среды;
• Процесс эксплуатации и поддержки – подразумевает запуск пользователем системы и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование или устранение ошибок;
• Процесс сопровождения – связан с разрешением программных ошибок, неисправностей, сбоев, модернизаций и внесением изменений, генерируемых процессом поддержки. Состоит из итераций разработки и предполагает обратную связь по предоставлению информации об аномалиях;
• Процесс вывода из эксплуатации – вывод существующей системы из её активного использования либо путём прекращения её работы, либо благодаря её замене новой системой или модернизированной версией существующей системы;
• Интегральные задачи – включают начало работы над проектом, мониторинг проекта и его управление, управление качеством, верификацию и аттестацию, менеджмент конфигурации, разработку документации и профессиональную подготовку на протяжении всего жизненного цикла.

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

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

• Ухудшению качественных показателей конечного продукта;
• Увеличению затрат;
• Смещению сроков;
• Полному провалу проекта.

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

• Внутренний, который находится в сфере влияния руководства проекта;
• Внешний, находящийся вне сферы влияния менеджмента.

Дата добавления: 2014-01-05