Стандарты CDM, ISO-12207, ГОСТ 34 и их характеристики

Методика Oracle CDM:

· Стандарт, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с реализацией на инструментальных средствах Oracle;

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

Процессы Oracle CDM:

· RD - Определение производственных требований,

· ES - Исследование существующих систем,

· TA - Определение технической архитектуры,

· DB - Проектирование и построение БД,

· MD - Проектирование и реализация модулей,

· CV - Конвертирование данных,

· DO - Документирование,

· TE - Тестирование,

· TR - Обучение,

· TS - Переход к новой системе,

· PS - Поддержка и сопровождение.

Степень адаптивности Oracle CDM:

· ограничивается тремя разновидностями каскадной модели ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle), "облегченный подход" (рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения).

Методика не предусматривает:

· включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным;

· удаление задачи (и порождаемых ею документов);

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

Степень обязательности Oracle CDM:

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

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

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

ISO 12207:

· определяет процессы ЖЦ. Состоит из крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п.

· каждый процесс разделен на набор действий, каждое действие - на набор задач.

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

· заранее определенных последовательностей нет

Равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь).

Содержание основных процессов ISO/IEC 12207:

· приобретение – определяет действия предприятия-покупателя, которое приобретает ИС, программный продукт или сервис ПО;

· поставка – определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО;

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

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

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

Степень адаптивности ISO 12207:

· степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте;

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

· позволяет реализовывать любую модель ЖЦ - один процесс при необходимости вызывает другой или его часть.

Степень обязательности ISO 12207:

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

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

· стандарт ориентирован на различные виды ПО и типы

· проектов ИС, куда ПО входит как часть; содержит предельно мало описаний, направленных на проектирование БД.

Стандарты комплекса ГОСТ 34:

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

· комплекс стандартов рассчитан на взаимодействие заказчика и разработчика.

Стадии и этапы ГОСТ 34:

· ФТ – Формирование требований к ИС;

o Обследование объекта и обоснование необходимости создания ИС;

o Формирование требований пользователя к ИС;

o Оформление отчета о выполненной работе и заявки на разработку ИС;

· РК – разработка концепции ИС;

o Изучение объекта;

o Проведение необходимых научно-исследовательских работ;

o Разработка вариантов концепции ИС, удовлетворяющей требованиям пользователя;

o Оформление отчета о выполненной работе;

· ТЗ – Техническое задание ИС;

o Разработка и утверждение технического задания на задание;

· ЭП – Эскизный проект;

o Разработка предварительных проектных решений по системе и ее компонентам;

o Разработка документации на ИС и ее части;

· ТП – Технический проект;

o Разработка проектных решений по системе и ее компонентам;

o Разработка документации на ИС и ее компоненты;

o Разработка и оформление документации на поставку изделий для комплектования ИС и/или технических требований (технических заданий) на их разработку;

o Разработка заданий на проектирование в смежных частях проекта объекта автоматизации;

· РД – Рабочая документация;

o Разработка рабочей документации на систему и ее компоненты;

o Разработка или адаптация программ;

· ВД – Ввод в действие;

o Подготовка объекта автоматизации к вводу ИС в действие;

o Подготовка персонала;

o Комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

o Строительно-монтажные работы;

o Пуско-наладочные работы;

o Проведение предварительных испытаний;

o Проведение опытной эксплуатации;

o Проведение приемочных испытаний;

· СП – Сопровождение ИС;

o Выполнение работ в соответствии с гарантийными обязательствами;

o Послегарантийное обслуживание.

Степень адаптивности ГОСТ 34 определяется возможностями:

· опускать стадию эскизного проектирования и объединять стадии "Технический проект" и "Рабочая документация";

· опускать этапы, объединять и опускать большинство документов и их разделов;

· вводить дополнительные документы, разделы документов и работы;

· гибко формировать ЖЦ динамически создавая т. н. ЧТЗ; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

Степень обязательности ГОСТ 34:

· прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС;

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

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

Назначение и содержание профилей стандартов

Вариант 1

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

Две группы профилей ИС:

· группа профилей, регламентирующих архитектуру и структуру ИС (макропроектирование);

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

Цели создания профилей:

· снижение трудоемкости, стоимости и длительности разработки проектов ИС;

· повышение качества разрабатываемых ИС;

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

· поддержка функциональной интеграции задач, ранее решавшихся раздельно;

· обеспечение переносимости прикладных программ и данных между разными аппаратно-программными платформами.

Профили ИС могут включать в себя:

· стандартизированные описания функций, выполняемых данной системой, и взаимодействия с внешней для нее средой (например, ОПЗ);

· стандартизированные интерфейсы между приложениями и средой ИС;

· профили отдельных функциональных компонентов (подсистем, модулей), входящих в систему.

Вариант 2

Профилем называется согласованная совокупность нескольких (или подмножество одного) нормативно-технических документов (стандартов и спецификаций), ориентированная на решение определенной задачи (реализацию заданной функции либо группы функций приложения или среды) [1]. Профиль представляет систему требований, направленных на обеспечение установленных свойств объекта (процесса) и выраженных на основе нормативно-технических документов (НТД) – юридических и (или) фактических стандартов. Он позволяет идентифицировать релевантные НТД, выделить в них необходимые составляющие, согласовать их содержание, а также адаптировать и конкретизировать его применительно к регламентируемой сущности и прикладной области.

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