allgosts.ru35.080 Программное обеспечение35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

ГОСТ Р 57098-2016 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса

Обозначение:
ГОСТ Р 57098-2016
Наименование:
Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса
Статус:
Заменен
Дата введения:
01.11.2017
Дата отмены:
30.01.2024
Заменен на:
ГОСТ Р 57098-2023
Код ОКС:
35.080

Текст ГОСТ Р 57098-2016 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса


ГОСТ Р 57098-2016/
ISO/IEC TR 24774:2010



НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ


СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ


Управление жизненным циклом. Руководство для описания процесса


Systems software and engineering. Life cycle management. Guidelines for process description

ОКС 35.080

Дата введения 2017-11-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 сентября 2016 г. N 1187-ст

4 Настоящий стандарт идентичен международному документу ISO/IEC TR 24774:2010* "Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса" (ISO/IEC TR 24774:2010 "Systems and software engineering. Life cycle management. Guidelines for process description", IDT)

________________

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

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

Введение

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

Международные стандарты разработаны в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2.

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

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

- тип 1, когда необходимая поддержка не может быть получена для публикации международного стандарта, несмотря на повторные усилия;

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

- тип 3, когда ИСО/МЭК СТК 1 собрал необходимые данные, какие обычно требуются для издания международного стандарта (например, "по состоянию дел").

Технические отчеты типов 1 и 2 являются объектом анализа для рассмотрения в течение трех лет после публикации и решения на предмет, могут ли они быть преобразованы в международные стандарты. Технические отчеты типа 3 не обязательно подлежат рассмотрению, если данные, которые их сопровождают, больше не являются достоверными или полезными.

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

ИСО/МЭК 24774, который является техническим отчетом типа [1], [2], [3], подготовлен ИСО/МЭК СТК 1 "Информационные технологии", подкомитетом 7 "Системная и программная инженерия".

Этот второй выпуск отменяет и заменяет первый выпуск (ИСО/МЭК 24774:2007), который был пересмотрен.

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

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

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

Международные стандарты по вопросам жизненного цикла систем и программных средств рассматриваются в рамках ИСО/МЭК СТК 1/SC 7/WG 7. Существующие стандарты в этой области - ИСО/МЭК 12207:2008 и ИСО/МЭК 15288:2008. Информационные объекты, связанные с определениями процесса, даны в ИСО/МЭК 15289:2006. Другие международные стандарты, такие как ИСО/МЭК 15939:2007 и ИСО/МЭК 16085:2006, предлагают характеристику одного из процессов жизненного цикла, детализируя элементы процесса и налагая определенные требования на выполнение процесса. Детализация проводится с использованием аппарата действий. Для организации или проекта при иллюстрации примеров добавлены другие детали (критерии входа/выхода, действующие стороны, артефакты).

_______________

Заменен на ИСО/МЭК/ИИЭР 15288:2015.

Заменен на ИСО/МЭК/ИИЭР 15289:2011.

Оценка возможностей процесса осуществляется в рамках ИСО/МЭК СТК 1/SC 7/WG 10. Существующий международный стандарт в этой области - ИСО/МЭК 15504-2:2003. Этот стандарт формирует требования для оценки возможностей процессов, определенных во внешних моделях процесса; процессы могут быть оценены, если есть их описание в терминах названия, цели и результатов и описание удовлетворяет критериям "эталонной модели процесса" по ИСО/МЭК 15504-2:2003. В дополнение к элементам, описанным в настоящем стандарте (техническом отчете), ИСО/МЭК 15504 определяет и использует элемент показателя оценки. Показатель оценки является источником объективных данных, используемых для поддержания суждения эксперта в оценке элементов процесса. В примерах рассмотрены рабочие продукты, практики и ресурсы.

ИСО/МЭК СТК 1/SC 7/WG 19 охватывает области открытой распределенной обработки и языков моделирования. Международные стандарты, разрабатываемые в этой рабочей группе, предлагают нотации, которые могли бы быть полезными в детальном описании процесса в других целях.

Руководящие принципы в настоящем стандарте (техническом отчете) - это те, которые применяются в ИСО/МЭК СТК 1/SC 7. Они гармонизируют с принципами, используемыми в ИСО/ТК 176 (комитет, ответственный за ИСО 9001). Руководящие принципы могут быть применены к любой модели процесса, разрабатываемого в любых целях. Руководящие принципы сделаны публично доступными на уровне стандарта (технического отчета) с намерением установить однородное описание процессов через все модели процесса ото всех источников для любых целей.

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

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

1 Область применения

Настоящий стандарт является руководством для описания процессов с помощью определения описывающих элементов и правила для их формулировки. Настоящий стандарт характеризует следующие элементы описания процесса:

- название;

- цель;

- выход (выходные результаты);

- действия;

- задачи;

- информационные объекты.

Кроме того, описываются представления процесса.

Стандарт не описывает, как процессы формируются или каким-либо образом объединяются в большие структуры или архитектуры.

2 Термины и определения

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

2.1 действие (activity): Множество связанных задач процесса [ИСО/МЭК 15288:2008].

2.2 информационный объект (information object): Отдельно идентифицируемая содержательная часть информации, которая произведена и сохранена для использования человеком в течение жизненного цикла системы или программных средств [ИСО/МЭК 15289:2006].

2.3 жизненный цикл (life cycle): Развитие системы, продукции, услуги, проекта или другого изобретения от замысла до списания [ИСО/МЭК 15288:2008].

2.4 модель жизненного цикла (life cycle model): Структурная основа процессов и действий, относящихся к жизненному циклу, которая также служит в качестве общей ссылки для установления связей и взаимопонимания [ИСО/МЭК 15288:2008].

2.5 процесс (process): Совокупность взаимосвязанных или взаимодействующих видов действия, преобразующих входы в выходы [ИСО 9000:2005].

_______________

Заменен на ИСО 9000:2015.

2.6 цель процесса (process purpose): Устремления высокого уровня в выполнении процесса и вероятные выходы (выходные результаты) эффективной реализации процесса.

Примечание - Необходимо, чтобы реализация процесса обеспечивала ощутимую пользу заинтересованным сторонам [ИСО/МЭК 12207:2008].

2.7 выход, результат процесса (process outcome): Наблюдаемый результат успешного достижения цели процесса [ИСО/МЭК/ИИЭР 12207:2008].

2.8 продукт, продукция (product): Результат процесса [ИСО 9000:2005].

2.9 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей [ИСО/МЭК 15288:2008].

2.10 задача (task): Требование, рекомендация или разрешенное действие, предназначенные для содействия достижению одного или более выходов процесса [ИСО/МЭК 15288:2008].

2.11 представление (view): Представление целой системы, исходя из перспектив связанного множества интересов [ИСО/МЭК 42010:2007, ИИЭР 1471-2000].

_______________

Заменен на ИСО/МЭК/ИИЭР 42010:2011.

Примечание - В стандартах, развиваемых в ИСО/МЭК JTC 1/SC 7, "система" (система процессов), упомянутая в определении, является множеством процессов жизненного цикла систем и программных средств, описанных в ИСО/МЭК 15288 и ИСО/МЭК 12207.

2.12 точка зрения (viewpoint): Спецификация соглашений для конструирования и использования представления [ИСО/МЭК 42010:2007, ИИЭР 1471-2000].

Примечания

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

2 Для детального объяснения представления и точки зрения, а также того, как они могут быть определены и использованы [ИСО/МЭК 42010:2007].

3 Характеристика элементов

3.1 Введение

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

Описываются следующие элементы процесса:

- название - описывает достижение процесса;

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

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

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

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

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

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

На рисунке 1 изображено представление унифицированного языка моделирования (UML-представление), взятое из рисунка C.1 ИСО/МЭК 15288, изображающего отношения между элементами процесса так, как описано в настоящем стандарте.

Примечание - Представление процесса имеет те же самые составляющие сущности.

Приложение A содержит пример процесса, описанного с использованием руководящих принципов настоящего стандарта.

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


Рисунок 1 - UML-представление составляющих сущностей процесса

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

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

3.2 Элемент названия

Название описания процесса - это короткая именная группа, которая представляет описательное достижение процесса.

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

Примечания

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

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

3.3 Элемент цели

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

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

Если желательно дальнейшее объяснение цели процесса, оно должно быть помещено в справочные примечания.

3.4 Элемент выходов (выходных результатов)

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

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

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

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

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

d) Предложения по одному выходу (выходному результату) не следует, как правило, растягивать более чем на две строки текста, т.е. это приблизительно не более 20 слов.

e) Число выходов (выходных результатов) для процесса следует определять в пределах диапазона от 3 до 7.

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

g) Выход (выходной результат) должен выражать единственный результат. Следовательно, использования союзов "и" или "и/или" при соединении объектов следует избегать; такие сооружения лучше выражаются как многократные результаты.

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

Примечания

1 Уровни возможностей определены в ИСО/МЭК 15504-2:2003 как объекты в порядковом масштабе с шестью уровнями возможностей процесса; каждый уровень основывается на возможностях уровня ниже.

2 В некоторых случаях (например, когда цели процесса и требования установлены по другим стандартам, таким как ИСО/МЭК 20000) результаты процесса не могут охватывать все требования процесса и остаться на первом уровне. В этих случаях высокоуровневые результаты могут быть обозначены таким образом, чтобы возможно было идентифицировать и исключить или иначе учесть эти результаты в оценках процесса (например, размещением в отдельном списке или в примечаниях, или описанием в приложении).

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

j) В выходах (выходных результатах) следует избегать требований любого определенного метода, методик или инструментариев.

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

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

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

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

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

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

Примеры приложения этого руководства "до и после" показаны на рисунке 2.

Это описание процесса взято из Дополнения 1 к ИСО/МЭК 12207

Контроль поставщика

Цель:

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

Выходы:

- совместные действия клиента и поставщика должны быть выполнены, как то необходимо;

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

- работа поставщика должна быть проконтролирована на соответствие согласованным требованиям

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

Контроль поставщика

Цель:

Цель контроля поставщика состоит в том, чтобы поддерживать связь с поставщиком для сопровождения представления о продвижении, рисках и выполнении обязательств.

Выходы:

В результате успешной реализации этого процесса:

- выполняются совместные действия клиента и поставщика;

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

- работа поставщика проверяется на соответствие согласованным требованиям


Рисунок 2 - Пример применения руководящих принципов для того, чтобы проектировать выходы (выходные результаты)

3.5 Элемент действий

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

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

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

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

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

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

3.6 Элемент задачи

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

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

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

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

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

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

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

3.7 Элемент информационного объекта

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

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

Информационные объекты представляют собой подмножество рабочих продуктов (определенное в ИСО/МЭК 15504-1 и используемое для описания показателей оценки процесса). Рабочий продукт - это артефакт, связанный с выполнением процесса.

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

Описание информационного объекта состоит из названия и ряда характеристик.

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

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

Таблица 1 - ИСО/МЭК 15289 Родовые типы информационных объектов

Название информационного объекта

Характеристики информационного объекта

Описание

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

План

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

Процедура

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

Запись, регистрация

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

Отчет

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

Запрос

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

Спецификация

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

3.8 Использование примечаний

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

4 Использование представления процесса

4.1 Введение

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

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

4.2 Понятие представления процесса

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

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

4.3 Точка зрения на процесс

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

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

Точка зрения на процесс определяется с помощью:

- заинтересованных сторон, пользователей стандарта (родовые заинтересованные стороны включают: авторов процесса, пользователей процесса, оценщиков процесса);

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

4.4 Представление процесса

Содержание получающихся представлений процесса должно включать:

- название представления процесса;

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

- выходы (выходные результаты) представления процесса;

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

Ясная, разграниченная (процессом) рассматриваемая система должна быть определена для любого множества представлений процесса. Это аналогично области применения модели процесса.

Пример представления процесса для специализации "инженерия" дан в приложении B.

Приложение A
(справочное)

Пример описания процесса

A.1 Введение

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

А.2 Процесс изъятия и списания

A.2.1 Цель

Цель процесса изъятия и списания состоит в том, чтобы завершить существование системы как сущности.

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

A.2.2 Выходы (выходные результаты)

В результате успешной реализации процесса изъятия и списания:

a) определяется стратегия изъятия и списания системы;

b) ограничения для изъятия и списания предоставляются как входы (исходные данные) к требованиям;

c) системные элементы или ненужные продукты разрушаются, сохраняются, повторно востребуются или перерабатываются;

d) окружающая среда возвращается к ее изначальному или согласованному состоянию;

e) становятся доступными записи по знаниям, разрешающим действия по изъятию и списанию, и анализу долгосрочных опасностей.

A.2.3 Действия и задачи

Относительно процесса изъятия и списания выполняйте в проекте следующие действия и задачи в соответствии с применяемой организацией политикой и процедурами:

a) Планируйте изъятие и списание. Эта деятельность состоит из следующих задач:

1) определяйте стратегию изъятия и списания для системы, включая каждый системный элемент и любые получающиеся ненужные продукты;

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

3) определяйте основные средства, места хранения, инспекционные критерии и периоды хранения, если система должна быть сохранена.

b) Выполняйте изъятие и списание. Эта деятельность состоит из следующих задач:

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

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

3) выводите штат операторов из системы и регистрируйте соответствующие знания по эксплуатации.

Примечание - Это проводится согласно соответствующим требованиям по безопасности, защищенности, обеспечению частной жизни и экологическим стандартам, директивам и законам;

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

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

6) руководите разрушением системы по мере необходимости, чтобы уменьшить затраты на выполнение работ или облегчить процесс изъятия.

c) Завершайте изъятие и списание. Эта деятельность состоит из следующих задач:

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

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

Приложение B
(справочное)

Пример представления процесса

B.1 Введение

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

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

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

B.2 Представление процесса для специализации "инженерия"

B.2.1 Цель

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

B.2.2 Выходы (выходные результаты):

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

b) определяются требования для достижения характеристик;

c) выбираются показатели для требований, связанных с желательными характеристиками;

d) разрабатываются и реализуются подходы для достижения желательных характеристик;

e) непрерывно контролируется степень выполнения требований (с помощью показателей) и доводится до заинтересованных сторон и руководства;

f) определяются, разрабатываются и поддерживаются артефакты для документирования и сообщения о степени достижений.

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

B.2.3 Процессы, действия и задачи

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

a) Процесс определения требований заинтересованных сторон (требований правообладателей) (6.4.1) предусматривает выбор и определение характеристик, включая характеристики качества и артефакты для документирования. Действия и документация полезны в определении и регистрации требований для специальных характеристик. Соответствующие действия и задачи включают (a) (1) и (2); (b) (2) и (4) и (c) (5).

Примечание - Для определения требований к качеству программных средств может оказаться полезным ИСО/МЭК 25030.

b) Процесс анализа требований (6.4.2) предусматривает выбор показателей для специальных требований. Соответствующие действия и задачи включают (a) (4) и (5).

Примечание - Для определения требований к качеству программных средств может оказаться полезным ИСО/МЭК 25030.

c) Процесс проектирования архитектуры (6.4.3) предусматривает создание критериев проекта для специальных характеристик и оценки альтернативных проектов по этим критериям. Соответствующие действия и задачи включают (b) (1) и (4).

d) Процесс реализации (6.4.4) предусматривает регистрацию подтверждений того, что требования специализации удовлетворяются. Соответствующие действия и задачи включают (b) (2).

e) Процесс комплексирования (6.4.5) предусматривает планирование комплексирования, включая учет характеристик специализации и обеспечение того, что достижение характеристик верифицируется и регистрируется. Соответствующие действия и задачи включают (a) (1) и (b) (3) и (5).

f) Процесс верификации (6.4.6) предусматривает планирование и выполнение стратегии верификации с учетом свойства специализации. Отобранная стратегия верификации может ввести проектные ограничения, которые могут подействовать на свойства. Соответствующие действия и задачи включают (a) (1) и (3) и (b) (2), (3) и (4).

g) Процесс передачи (6.4.7) предусматривает инсталляцию системы в ее эксплуатационной среде. Поскольку некоторые свойства специализации влекут за собой компромиссы между ограничениями проекта и эксплуатационными ограничениями, внимание к инсталляции часто оказывается важным. Соответствующие действия и задачи включают (b) (2), (3), (5) и (6).

h) Процесс валидации (аттестации) (6.4.8) обеспечивает подтверждение того, что услуги, оказанные системой, удовлетворяют требованиям заинтересованных сторон, включая свойства специализации. Соответствующие действия и задачи включают (b) (3) и (5).

i) Процесс функционирования (6.4.9) рассматривает использование системы. Для подтверждения того, что требования специализации соответствующим образом достигнуты, применяется непрерывный контроль функционирования системы. Соответствующие действия и задачи включают (c) (2) и (d) (1) и (2).

j) Процесс обслуживания (сопровождения) (6.4.10) поддерживает возможности системы, включая свойства специализации. Соответствующие действия и задачи включают (b) (3), (4) и (8).

k) Процесс изъятия и списания (6.4.11) определяет завершение существования системы. Изначальная потребность ожидаемого изъятия и списания может включать ограничения на развитие системы. Фактически эти ограничения могут сами по себе стать объектом специализации. Соответствующие действия и задачи включают (a) (2) и (c) (2).

I) Процесс оценки и контроля проекта (6.3.2) предусматривает контроль степени выполнения требований (достижений) и сообщение результатов заинтересованным сторонам и руководству. Соответствующие действия и задачи включают (a) (8) и (9).

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

n) Процесс измерений (6.3.7) полностью предусматривает определение подхода, который связывает показатели с желательными характеристиками специализации.

Библиография

[1]

ISO 9000:2005 Quality management systems - Fundamentals and vocabulary

[2]

ISO/IEC 12207:2008 Systems and software engineering - Software life cycle processes

[3]

ISO/IEC 15288:2008 Systems and software engineering - System life cycle processes

[4]

ISO/IEC 15289:2006 Systems and software engineering - Content of systems and software life cycle process information products (Documentation)

[5]

ISO/IEC 15504-2:2003 Information technology - Process assessment - Part 2: Performing an assessment

[6]

ISO/IEC 15939:2007 Systems and software engineering - Measurement process

[7]

ISO/IEC 16085:2006 Systems and software engineering - Life cycle processes - Risk management

[8]

ISO/IEC 25030:2007 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements

[9]

ISO/IEC 42010:2007, IEEE Std 1471-2000 Systems and software engineering - Recommended practice for architectural description of software-intensive systems

_______________

Заменен на ISO 9000:2015.

Заменен на ISO/IEC/IEEE 15288:2015.

Заменен на ISO/IEC/IEEE 15289:2011.

Заменен на ISO/IEC/IEEE 42010:2011.

УДК 006.034:004.054:006.354

ОКС 35.080

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

Электронный текст документа

и сверен по:

, 2018

Превью ГОСТ Р 57098-2016 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса