5.2.2 Краткое содержание процессов жизненного цикла

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

Для помощи в одновременном использовании и настоящего стандарта соответствующие процессы раздела 6 имеют одинаковые обозначения подразделов.

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

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

Таким образом, процессы соглашения, приведенные в настоящем стандарте, ориентированы на программные средства процессами соглашения из .

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

Процессы организационного обеспечения проекта включают в себя:

a) процесс менеджмента модели жизненного цикла;

B) процесс менеджмента инфраструктуры;

c) процесс менеджмента портфеля проектов;

d) процесс менеджмента людских ресурсов;

e) процесс менеджмента качества.

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

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

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

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

а) процесс планирования проекта;

b) процесс управления и оценки проекта.

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

a) процесс менеджмента решений;

b) процесс менеджмента рисков;

c) процесс менеджмента конфигурации;

d) процесс менеджмента информации;

е)процесс измерений.

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

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

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

Технические процессы состоят из следующих процессов:

a) определение требований правообладателей (специальный случай процесса определения требований правообладателей, приведенного в );

b) анализ системных требований (специальный случай процесса анализа требований);

C) проектирование архитектуры системы (специальный случай процесса проектирования архитектуры, приведенного в );

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

e) процесс комплексирования системы (специальный случай процесса комплексирования, приведенного в );

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

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

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

i) процесс функционирования программных средств (специальный случай процесса функционирования, приведенного в );

j) процесс сопровождения программных средств (специальный случай процесса сопровождения, приведенного в );

k) процесс изъятия из обращения программных средств (специальный случай процесса изъятия и списания, приведенного в ).

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

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

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

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

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

B) процесс проектирования архитектуры программных средств;

c) процесс детального проектирования программных средств;

d) процесс конструирования программных средств;

e) процесс комплексирования программных средств;

f) процесс квалификационного тестирования программных средств.

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

a) процесс менеджмента документации программных средств;

b) процесс менеджмента конфигурации программных средств;

c) процесс обеспечения гарантии качества программных средств;

d) процесс верификации программных средств;

e) процесс валидации программных средств;

f) процесс ревизии программных средств;

g) процесс аудита программных средств;

H) процесс решения проблем в программных средствах.

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

Процессами повторного применения программных средств являются:

a) процесс проектирования доменов;

b) процесс менеджмента повторного применения активов;

C) процесс менеджмента повторного применения программ.

Стандарт 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, будет увеличиваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В России в настоящее время используется стандарт ГОСТ Р ИСО/МЭК 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 , совершенствующийся - в таких организациях, помимо процессов и методов их оценки, имеются методы определения слабых мест, определены процедуры поиска и оценки новых методов и техник разработки, обучения персонала работе с ними и их включения в общий процесс организации в случае повышения эффективности производства).

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