Стандарты и методологии, регламентирующие жизненный цикл ИС

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Стандарты и методики

ГОСТ 34

ГОСТ Р ИСО/МЭК 12207-99 «Процессы ЖЦ программных средств»

ГОСТ Р ИСО/МЭК 15288-2005 «Системная инженерия. Процессы ЖЦ систем»

Oracle CDM (Custom Development Method)

RUP (Rational Unified Process)

MSF (Microsoft Solutions Framework)

Методика планирования бизнес-систем BSP компании IBM.

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

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

· получение поддержки руководства предприятия

· подготовка к анализу

· проведение стартового совещания.

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

На этапе 5 выявляются основные классы данных (логически связанные категории данных)

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

· матрица “руководители - процессы”, демонстрирующая основные обязанности руководителей, степень их вовлечености в основные бизнес-процессы предприятия;

· матрица “информационные системы - руководители”, показывающая какими системами (существующими или планируемыми) пользуются руководители;

· матрица “информационные системы - процессы”, демонстрирующая как системы соотносятся с бизнес-процессами предприятия;

· матрица “информационные системы - файлы данных”, показывающая, какие файлы данных и какими системами используются.

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

· уточнение матриц

· определение и оценка необходимой руководству информации

· определение приоритетов потребностей

· определение текущих задач

· привлечение на свою сторону руководства.

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

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

· проблемы, связанные с существующими информационными системами;

· проблемы, связанные с будущими системами.

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

На следующем (девятом) этапе традиционными методами осуществляется проектирование архитектуры информационной системы. Десятый этап определяет приоритеты в реализации и намечает последовательность ее этапов. Этап 11 определяет планирование модификаций информационной системы в связи с постоянным процессом появления новых требований к такой системе. Наконец, этапы 12 и 13 заключаются в выработке рекомендаций и планов и формировании отчетности по проведенным работам.

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

15. Стандарт на процессы и организацию жизненного цикла программных средств ГОСТ Р ИСО/МЭК 12207-2010.

Утвержден:Федеральное агентство по техническому регулированию и метрологии, 30.11.2010

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

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».

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

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

Модель ЖЦ ПО включает в себя:

Стадии;

Результаты выполнения работ на каждой стадии;

Ключевые события — точки завершения работ и принятия решений.

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

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

16. Стандарт на процессы и организацию жизненного цикла систем ГОСТ Р ИСО/МЭК 12207-2005. Стадии жизненного цикла ИС.

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

процессы соглашения — два процесса;

процессы организационного обеспечения проекта — пять процессов;

процессы проекта — семь процессов;

технические процессы — одиннадцать процессов;

процессы реализации программных средств — семь процессов;

процессы поддержки программных средств — восемь процессов;

процессы повторного применения программных средств — три процесса.

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

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)