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

5.1.1 Отношения между программными продуктами и программными услугами

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

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

5.1.2 Отношения между системами и программными средствами

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

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

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

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

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

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

5.1.3 Организации и стороны

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

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

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

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

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

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

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

5.1.4 Внедрение на уровне организации и на уровне проекта

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

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

5.1.5 Адаптация

Основные действия, необходимые для адаптации настоящего стандарта, определены в приложении А.

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

5.1.6 Временные отношения между процессами

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

5.1.7 Оценивание по отношению к верификации и валидации

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

5.1.8 Критерии для процессов

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

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

Принцип ответственности: процесс передается под ответственность какой-либо организации или стороне в пределах жизненного цикла программного средства.

5.1.9 Описание процессов

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

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

- наименование - передает область применения процесса как целого;

- цель - описывает конечные цели выполнения процесса;

- выходы - представляют собой наблюдаемые результаты, ожидаемые при успешном выполнении процесса;

- деятельность - является перечнем действий, используемых для достижения выходов;

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

Дополнительные подробности относительно подобной формы описания процессов представлены в [27].

5.1.10 Общие характеристики процессов

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

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

5.1.11 Декомпозиция процессов

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

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

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

Дополнительный справочный материал представлен в виде необязательных примечаний или необязательных приложений.

5.1.12 Модели и стадии жизненного цикла

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

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

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

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

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

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

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

a) процессы соглашения - два процесса (см. 5.2.2.1.1 и 6.1);

b) процессы организационного обеспечения проекта - пять процессов (см. 5.2.2.1.2 и 6.2);

c) процессы проекта - семь процессов (см. 5.2.2.1.3 и 6.3);

d) технические процессы - одиннадцать процессов (см. 5.2.2.1.4 и 6.4);

e) процессы реализации программных средств - семь процессов (см. 5.2.2.2.1 и 7.1);

f) процессы поддержки программных средств - восемь процессов (см. 5.2.2.2.2 и 7.2);

g) процессы повторного применения программных средств - три процесса (см. 5.2.2.2.3 и 7.3).

Цели и результаты процессов жизненного цикла образуют эталонную модель процессов.

В настоящем стандарте принята следующая нумерация:

6.а и 7.а - указывают на группу процесса;

6.а.b и 7.а.b - указывают на процесс (или процесс более низкого уровня) в пределах этой группы;

6.а.b.1 и 7.а.b.1 - описывают цели процесса;

6.а.b.2 и 7.а.b.2 - описывают выходы процесса;

6.а.b.3.с и 7.а.b.3.с - перечисляют виды деятельности процесса и пункты;

6.a.b.3.c.d и 7.a.b.3.c.d - перечисляют задачи в пределах деятельности (с).

Группы процессов жизненного цикла представлены на рисунке 1.

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

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

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

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

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

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