Международный стандарт ISO/IEC 12207: 1995-08-01

О видах стандартов

После конференции АПО/ROUG97 (Таруса, июнь 1997), где автор сделал доклад "ISO/IEC 12207, ГОСТ34, Oracle CDM - процессы, результаты, соотнесение", обнаружилось, что: а) интерес к теме есть и у отдельных людей, и у коллективов, б) конструктивно говорить на эту тему можно только после выяснения и принятия говорящими более-менее одинакового понимания того, что такое стандарт и какие они бывают.

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

1. по предмету стандартизации: функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы) и стандарты на организацию Жизненного Цикла (ЖЦ) создания и использования Автоматизированных Систем (АС) и Программного Обеспечения (ПО);

2. по утверждающей организации: официальные международные стандарты, официальные национальные или национальные ведомственные (например, ГОСТы, ANSI, IDEF0/1), стандарты международных консорциумов и комитетов по стандартизации (OSF, OMG, ранее широко известный CODASYL), стандарты "де-факто" (таким долгое время был SQL или язык диаграмм SADT Д. Росса), фирменные стандарты (Microsoft ODBC, IBM SNA);

3. по методическому источнику: методические материалы фирм-разработчиков ПО, фирм-консультантов, научных центров, консорциумов по стандартизации (например, Oracle Method, Price Waterhouse SMM, SEI CMM); они могут называться по-разному - например, "Метод", "Методология", "Подход", "Модель".

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

· степени обязательности для организаций разного типа;

· конкретности и детализации содержащихся требований;

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

Рассматриваемые стандарты

Далее будем рассматривать следующие стандарты и методики, касающиеся ЖЦ АС и ПО:

1. Стандарты комплекса ГОСТ 34 на создание и развитие АС - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Кроме того, эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости. Насколько это так, а насколько ГОСТ 34 остается работающим с пользой - полезно разобраться.

2. Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.

3. Методика Oracle CDM (Custom Development Method) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, расчитанных на прямое использование в проектах АС с опорой на инструментарий Oracle.

Методика Oracle CDM

1) Возникла как развитие разработанной давно версии Oracle CASE-Method, известной по использованию Oracle CASE (ныне Designer/2000) и книгам Р. Баркера. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения (см. описание CDM) о простом приспособлении CDM к проектам, в которых используется другой инструментальный комплекс.

2) Общая структура.

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

2.2. Этапы:

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

· "Анализ" (формулирование детальных требований к прикладной системе);

· "Проектирование" (преобразование требований в детальные спецификации системы);

· "Реализация" (написание и тестирование приложений);

· "Внедрение" (установка новой прикладной системы, подготовка к началу эксплуатации);

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

2.3. Процессы:

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

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

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

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

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

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

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

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

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

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

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

2.4. Процессы состоят из последовательностей задач, задачи разных процессов взаимосвязаны явно указанными ссылками. CDM наиболее сильно связан с методикой "Oracle PJM" по организации управления проектом.

3) Особенности.

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

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

3.2. Все модели ЖЦ АС и ПП являются по сути каскадными; даже "облегченный подход", несмотря на понятную итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.

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

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

Международный стандарт ISO/IEC 12207: 1995-08-01

1) Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1"Информационные технологии, подкомитет SC7, проектирование программного обеспечения".

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важное ЗАМЕЧАНИЕ СТАНДАРТА: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: система - это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.

В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

2) Общая структура.

2.1. Процессы ЖЦ. По сравнению с CDM стандарт ISO состоит из гораздо более крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.

Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.). См. далее о "динамичности" стандарта.

2.1.1. Описаны 5 основных процессов ЖЦ ПО:

1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.

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

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

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

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

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

2.1.3. Описаны 4 организационных процесса: Процесс управления, Процесс создания инфраструктуры, Процесс усовершенствования, Процесс обучения.

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

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

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

3) Особенности.

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

Примеры:

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

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

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

Такой характер позволяет реализовывать любую модель ЖЦ.

ОПРЕДЕЛЕНИЕ СТАНДАРТА: Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

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

ЗАМЕЧАНИЕ СТАНДАРТА:Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.

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

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

· рассматривается область применения системы для определения требований системы;

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

· квалификация требований системы должна быть документирована.

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

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

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

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

д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;

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

ж) определение данных и требований базы данных;

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

и) документация пользователя;

к) работа пользователя и требования выполнения;

л) требования сервиса пользователя.

(Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ34 по видам обеспечения системы.)

ОПРЕДЕЛЕНИЕ СТАНДАРТА: Требование квалификации - набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.

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

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

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

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

3.6. Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД^**), но и не использовать БД вовсе.