ГОСТ Р 56923-2016/ISO/IEC TR 24748-3:2011. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

4.4 Понятия процессов

 

4.4.1 Общее

4.4.1.1 Введение

Применение ИСО/МЭК 12207 предполагает владение понятиями процесса.

Примечание - Понятие процесса введено в ИСО/МЭК 15288 (подраздел 5.3). Дополнительное обсуждение находится в ИСО/МЭК 24748-1 (подраздел 3.3).

 

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

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

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

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

Примечания

1 Понятия процесса введены в ИСО/МЭК 15288 (подраздел 5.3), ИСО/МЭК 12207 (подпункты 5.1.9 и 5.1.10) и ИСО/МЭК 24748-1 (подраздел 3.3).

2 Критерии для процессов обсуждены в ИСО/МЭК 12207 (подпункт 5.1.8), а декомпозиция процессов обсуждена в ИСО/МЭК 15288 (подпункт 5.1.11).

3 ИСО/МЭК 24774 обеспечивает руководящие принципы для описания процессов.

 

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

 

 

Рисунок 4 - Пример входов и выходов процесса

 

4.4.1.2 Входы

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

a) информация, такая, например, как требования, интерфейс или определения архитектуры;

b) данные, такие, например, как измерения и отчеты испытаний;

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

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

4.4.1.3 Выходы

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

4.4.1.4 Управление

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

a) проектное соглашение;

b) интерфейсы с процессами, использованные на других системах, за которые проект ответственен (см. 4.6.2);

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

d) внутренние типовые методы организации или части организации, ответственной по проекту.

4.4.1.5 Обеспечивающие механизмы

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

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

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

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

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

4.4.2 Принципы процесса

4.4.2.1 Введение

ИСО/МЭК 12207 устанавливает архитектуру высшего уровня для жизненного цикла программных средств от концепции до изъятия и списания. Архитектура построена с множеством процессов и взаимосвязей в среде этих процессов. Процессы основаны на двух изначальных принципах: модульности и ответственности.

4.4.2.2 Модульность

Процессы являются модульными. В рамках модульности процессы:

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

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

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

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

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

 

b) каждый процесс привязывается к архитектуре;

c) если процесс A привлечен процессом B и только B, то A принадлежит B;

d) если функция привлечена более чем одним процессом, то функция становится процессом сама по себе;

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

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

4.4.2.3 Ответственность

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

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

Примечания

1 ИСО/МЭК 24748-1 (подпункт 3.3.2) предоставляет больше информации об ответственности процесса.

2 Организации и стороны обсуждены в 4.5.

 

4.4.3 Категории процесса по ИСО/МЭК 12207

4.4.3.1 Общее

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

Группы процесса в контексте системы:

- процессы соглашения;

- процессы организационного обеспечения проекта;

- процессы проекта;

- технические процессы.

Группы специальных процессов программных средств:

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

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

- процессы повторного использования программных средств.

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

Примечание - Категории процесса жизненного цикла объединены в ИСО/МЭК 12207 (подпункт 5.2.1). Суть процессов представлена в подпункте 5.2.2. Всесторонние обсуждения даны в разделах 6 и 7.

 

4.4.3.2 Категории процесса в контексте системы

Процессы в контексте системы представлены на рисунке 5.

 

Процессы в контексте системы

 

 

Рисунок 5 - Процессы в контексте системы

 

Примечание - Суть процессов контекста системы представлена в ИСО/МЭК 12207 (подпункт 5.2.2.1). Всестороннее обсуждение дано в разделе 6.

 

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

 

 

Рисунок 6 - Роль процессов в контексте системы

 

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

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

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

 

 

Рисунок 7 - Использование процессов соглашения

 

4.4.3.3 Категории специальных процессов программных средств

Специальные процессы программных средств представлены на рисунке 8.

Примечание - Суть специальных процессов программных средств представлена в ИСО/МЭК 12207 (подпункт 5.2.2.2). Всестороннее обсуждение представлено в разделе 7.

 

Специальные процессы программных средств

 

 

Рисунок 8 - Специальные процессы программных средств

 

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

 

 

Рисунок 9 - Роль специальных процессов программных средств

 

4.4.4 Рекурсивное/итеративное применение процессов

4.4.4.1 Общее

Две формы применения процесса являются существенными и полезными для выполнения требований ИСО/МЭК 12207 - это рекурсивное и итеративное применение.

4.4.4.2 Рекурсивное применение процессов

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

 

 

Рисунок 10 - Рекурсивное применение процессов

 

4.4.4.3 Итеративное применение процессов

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

 

 

Рисунок 11 - Итеративное применение процессов

 

4.4.4.4 Методы и инструментарии

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

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

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

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

c) должны быть учтены требования к обучению для применения метода или инструментария. Учету подлежат как начальное, так и последующее время обучения, если пользователь не использовал инструментарии в срок;

d) должны быть учтены обеспечивающие системы, а также административные аспекты инструментариев.