Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации . Этот цикл - процесс построения и развития ПО.

Стандарты жизненного цикла ПО

· ГОСТ 34.601-90

· ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

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

1. Обследование объекта и обоснование необходимости создания АС

2. Формирование требований пользователя к АС

3. Оформление отчета о выполнении работ и заявки на разработку АС

Разработка концепции АС

1. Изучение объекта

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

3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

4. Оформление отчета о проделанной работе

Техническое задание

1. Разработка и утверждение технического задания на создание АС

Эскизный проект

1. Разработка предварительных проектных решений по системе и ее частям

Технический проект

1. Разработка проектных решений по системе и ее частям

2. Разработка документации на АС и ее части

3. Разработка и оформление документации на поставку комплектующих изделий

4. Разработка заданий на проектирование в смежных частях проекта

Рабочая документация

1. Разработка рабочей документации на АС и ее части

2. Разработка и адаптация программ

Ввод в действие

1. Подготовка объекта автоматизации

2. Подготовка персонала

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

4. Строительно-монтажные работы

5. Пусконаладочные работы

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

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

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

8. Сопровождение АС.

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

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

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

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

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

В России в настоящее время используется стандарт ГОСТ Р ИСО/МЭК 12207-2010 Процессы жизненного цикла программных средств(ISO/IEC 12207:2008 System and software engineering - Software life cycle processes)

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

Общая структура – см. самостоятельно!

Особенности:

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

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

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

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

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

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

МОДЕЛЬ SEI SW-CMM

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

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

СММ – стандарт де-факто.

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

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

СММ определяет 5 уровней технологической зрелости компании:

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

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

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

4. Уровень 4 , управляемый - в этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством);

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

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

1) Позволяет реализовать любую модель ЖЦ - это возможно, т.к. стандарт предлагает способ определения последовательности выполнения процессов и задач, при котором один процесс может вызывать другой процесс или его части.

2) Обеспечивает максимальную степень адаптивности – множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами ИС. Адаптация сводится к исключению процессов, видов деятельности и задач, которые не применяются в конкретном проекте.

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

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

5) Ценность стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.д. , дающие всесторонний охват проектных решений.

6) Хотя стандарт не предписывает использовать конкретную модель ЖЦ или метод разработки, он определяет, что стороны участники проекта несут ответственность за следующие моменты:

выбор модели ЖЦ для разрабатываемого проекта;

адаптация процессов и задач стандарта к выбранной модели;

выбор и применение методов разработки ПО;

выполнение действий и задач, подходящих для данного проекта ПО.

Стандарты комплекса гост 34.

Задумывался как всеобъемлющий комплекс взаимоувязанных межотраслевых документов.

Объекты стандартизации : автоматизированные системы различных видов и все виды их компонентов.

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

Согласно ГОСТу разработка автоматизированной системы разбивается на следующие этапы и стадии:

1 этап формирования требований к АС :

Стадия а: обследование объекта и обоснование необходимости разработки автоматизированной системы;

Стадия б: формирование требований заказчика к автоматизированной системе;

Стадия в: разработка отчета о проделанной работе и подготовка заявки на разработку технического задания.

2 этап разработки концепции :

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

б: проведение необходимых НИР;

в: разработка вариантов концепции АС, удовлетворяющей требованиям заказчика;

г: разработка отчета о проделанной работе.

3 этап разработки и утверждения технического задания на создание АС .

4 этап разработки эскизного проекта АС :

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

б: разработка документации.

5 этап разработки технического проекта :

а: разработка проектных решений по всей системе и по её частям;

б: разработка документации на автоматизированную систему и подсистемы, входящие в её состав;

в: разработка и оформление документации на поставку изделий для комплектования АС или разработка и оформление технических требований на разработку этих изделий.

6 этап разработки технической документации :

а: разработка рабочей документации на систему её части;

б: разработка или адаптация ПО.

7 этап ввода разработанной системы в действие :

а: подготовка объекта автоматизации к внедрению АС;

б: подготовка персонала;

в: комплектации АС программными и техническими средствами;

г: монтажные работы;

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

е: предварительные испытания;

ж: опытная эксплуатация;

з: приемочные испытания.

8 этап сопровождения :

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

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

Стандарт ISO/IEC 12207-95 определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ (жизненного цикла).

Особенности стандарта

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО; Он определяет, что стороны-участники использования стандарта ответственны=

1. за выбор модели ЖЦ для проекта ПО,
2. за адаптацию процессов и задач стандарта к этой модели,
3. за выбор и применение методов разработки ПО,
4. за выполнение действий и задач, подходящих для проекта ПО;

Стандарт ISO/IEC 12207-95 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

Определения стандарта

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

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

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

Стандарт определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из:

1. · процессов,
2. · видов деятельности,
3. · задач

Стандарт не определяет метрики , по которым можно было бы отслеживать ход работ и их результативность. Самыми крупными элементами являются процессы жизненного цикла ПО . Всего выделено 18 процессов, которые объединены в 3 группы:

1. -основные процессы;
2. -поддерживающие процессы;
3. -организационные процессы;
4. -процесс адаптации.

Основные процессы ЖЦ

1) Процесс приобретения - его задача - определить действия предприятия-покупателя, которое приобретает автоматизированную систему, программный продукт или сервис ПО:

1. · инициация приобретения;
2. · подготовка запроса предложений;
3. · подготовка контракта;
4. · анализ поставщиков;
5. · получение ПО.

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

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

1. · развертывание процесса разработки;
2. · анализ системных требований;
3. · проектирование (программно-аппаратной) системы в целом;
4. · анализ требований к ПО;
5. · проектирование архитектуры ПО;
6. · детальное проектирование;
7. · кодирование;
8. · отладочное тестирование;
9. · интеграцию ПО;
10. · квалификационное тестирование ПО;
11. · системную интеграцию;
12. · квалификационное тестирование системы;
13. · развертывание (установку или инсталляцию) ПО.

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

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

5) Процесс поддержки ПО определяет действия персонала сопровождения, который обеспечивает:

1. · инсталляцию и удаление программного изделия на вычислительной системе;
2. · анализ возникающих проблем;
3. · внесение изменений;
4. · экспертизу и передачу измененного ПО;
5. · перенос ПО с одной платформы на другую;
6. · изъятие ПО из эксплуатации.

Аннотация: Логическое продолжение предыдущей лекции. Детально рассматривается проблема практического применения ГОСТ Р ИСО/МЭК 12207 в организациях и проектах. В связи с этим изучаются стандарты ГОСТ Р ИСО/МЭК 15271 и ГОСТ Р ИСО/МЭК 16326.

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

Неслучайно следом за ГОСТ Р ИСО/МЭК 12207 был разработан специально посвященный задаче его внедрения стандарт ГОСТ Р ИСО/МЭК 15271-02 (ГОСТ 15271, 2002), который называется "Руководство по применению ГОСТ Р ИСО/МЭК 12207". К его рассмотрению мы сейчас и перейдем.

Стандарт ГОСТ Р ИСО/МЭК 15271

Смысл стандарта раскрывается в его вводном разделе.

"1.2. Пользователи стандарта.

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

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

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

Стандарт ГОСТ Р ИСО/МЭК 15271 состоит из 8 разделов и 4 Приложений. Содержательные разделы называются так ( нумерация взята из текста):

• 4. Основные концепции развития ГОСТ Р ИСО/МЭК 12207.
• 5. Внедрение ГОСТ Р ИСО/МЭК 12207.
• 6. Применение в проектах.
• 7. Применение в организациях.
• 8. Прикладное применение модели жизненного цикла системы.

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

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

• a) разработка плана внедрения;
• b) практическое применение ГОСТ Р ИСО/МЭК 12207;
• c) проведение сопровождения пилотного проекта (ов);
• d) формализация метода внедрения;
• e) утверждение метода внедрения.

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

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

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

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

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

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

"6.1.3. Характеристики системы

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

Примерный перечень характеристик системного уровня (относящихся к программному средству и подлежащих учету) включает в себя:

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

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

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

Центральной частью совсем короткого раздела 7 "Применение в организациях" служит следующий текст.

"7.2. Возможности применения

Причины, по которым ГОСТ Р ИСО/МЭК 12207 внедряют в организации, могут быть следующими:

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

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

Наконец, раздел 8 "Прикладное применение модели жизненного цикла системы" содержит довольно туманные определения " модели жизненного цикла системы" и " модели жизненного цикла программного средства" и пытается установить соответствие между ними. Поскольку точные определения отсутствуют, судить о результатах невозможно.

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

Стандарт ГОСТ Р ИСО/МЭК 16326

Еще одна попытка формализовать процесс применения ГОСТ Р ИСО/МЭК 12207 была предпринята в стандарте ГОСТ Р ИСО/МЭК 16326 "Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом" (ГОСТ 16326, 2002). Он демонстрирует попытку объединить процессы жизненного цикла из ГОСТ Р ИСО/МЭК 12207 с процессами управления проектами из популярного методического справочника PMBOK 1PMBOK - Project Management Body of Knowledge (PMBOK, 2009) и стандарта ISO 10006 (русская версия стандарта содержится в (ГОСТ 10006, 2005)). Схематически это представлено на рис. 4.1 , приведенном в стандарте.

Рис. 4.1.

Круг пользователей стандарта довольно точно определен в разделе 1.1.

"1.1. Круг пользователей

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

• администраторов, ответственных за организацию и постоянное совершенствование процессов жизненного цикла программных средств по ГОСТ Р ИСО/МЭК 12207;
• администраторов, ответственных за применение процессов жизненного цикла программных средств по ГОСТ Р ИСО/МЭК/12207 на проектном уровне;
• организаций или лиц, являющихся субподрядчиками при реализации УПП (Управления Программным Проектом. - АБ ).

Приведены соображения для лиц:

• вовлеченных в программные проекты, но не являющихся АП (Администраторами Проектов. - АБ );
• являющихся администраторами непрограммных проектов, но связанных с АП программных средств".

Относительно короткий основной текст (раздел 6 "Руководство" занимает всего 9 страниц из общих 35) представляет собой последовательный комментарий к процессу 7.1 "Управление" из ГОСТ Р ИСО/МЭК 12207 с точки зрения PMBOK. Стиль комментария - неформальный, рассуждения большей частью носят рекомендательный характер. Комментарий не выходит за пределы обычного здравого смысла, и ничего нового не содержит. В общем, это полезное чтение для руководителей (в терминологии переводчиков - "администраторов") проектов, но не более того.

Приложение А представляет собой одну большую таблицу, демонстрирующую связи между основными процессами ГОСТ Р ИСО/МЭК 12207 и вызываемыми из них работами процесса "Управление". Все эти ссылки содержатся в теле стандарта ГОСТ Р ИСО/МЭК 12207; сведение их в одну таблицу никакой новой информации не добавляет.

Приложение В представляет собой точно такую же таблицу, связывающую области процессов и отдельные процессы из PMBOK с работами процесса "Управление" из ГОСТ Р ИСО/МЭК 12207.

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

Еще одна сводная таблица представлена в Приложении D. Здесь показаны связи между тремя источниками: ГОСТ Р ИСО/МЭК 12207, PMBOK и стандартом ISO 10006. Замечу сразу, что последний был переведен на русский язык только в 2005 г.; как следствие, терминология, использованная в Приложении D к стандарту ГОСТ Р ИСО/МЭК 16326 2002 г., отличается от более поздней. Как и в предыдущих случаях, смысл представления этих связей в компактной табличной форме неясен. Более того, суммарный объем Приложений А-D превышает объем основного раздела 6 "Руководство" больше чем в два раза.

На мой взгляд, ГОСТ Р ИСО/МЭК 16326-2002 по форме и назначению не отличается от ГОСТ Р ИСО/МЭК 15271-2002. И тот и другой страдают избытком правильных "в общем" и опирающихся только на здравый смысл рассуждений. Эти рассуждения очевидны для каждого, кто имеет практический опыт руководства проектом, и вряд ли выглядят обоснованными для тех, кто такого опыта не имеет. В отличие от ГОСТ Р ИСО/МЭК 15271-2002 стандарт ГОСТ Р ИСО/МЭК 16326-2002 более формален, но практический смысл предложенного формализма непонятен.

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

Помимо рассмотренных выше ГОСТ Р ИСО/МЭК 12207 вызвал к жизни еще ряд стандартов, которые детализируют приведенные в нем процессы жизненного цикла . К ним относятся, например, ГОСТ Р ИСО/МЭК 15910-2002 "Процесс создания документации пользователя программного средства" (ГОСТ 15910, 2002) и ГОСТ Р ИСО/МЭК 14764-2002 "Сопровождение программных средств" (ГОСТ 14764, 2002). Часть аналогичных стандартов ИСО еще не переведена на русский язык; вероятно, в дальнейшем число русскоязычных стандартов ГОСТ Р ИСО, непосредственно связанных с ГОСТ Р ИСО/МЭК 12207, будет увеличиваться.