Законодательная база Российской Федерации

"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ. ГОСТ Р ИСО/МЭК 12207-2010" (утв. Приказом Ростехрегулирования от 30.11.2010 N 631-ст)

7.1.1 Процесс реализации

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

7.1.1.1 Цель

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

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

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

7.1.1.2 Выходы

В результате успешного осуществления процесса реализации программных средств:

a) определяется стратегия реализации;

b) определяются ограничения по технологии реализации проекта;

c) изготавливается программная составная часть;

d) программная составная часть упаковывается и хранится в соответствии с соглашением о ее поставке.

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

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

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

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

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

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

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

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

7.1.1.3 Виды деятельности и задачи

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

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

Данный вид деятельности состоит из решения следующих задач:

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

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

7.1.1.3.1.2 Исполнитель должен:

a) документировать результаты в соответствии с процессом менеджмента программной документации (см. 7.2.1);

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

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

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

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

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

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

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

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

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

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

7.1.2.1 Цель

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

7.1.2.2 Выходы

В результате успешного осуществления процесса анализа требований к программным средствам:

a) определяются требования к программным элементам системы и их интерфейсам;

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

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

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

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

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

g) оцениваются изменения в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям;

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

7.1.2.3 Виды деятельности и задачи

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

7.1.2.3.1 Анализ требований к программным средствам

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

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

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

b) внешние интерфейсы к программной составной части;

c) квалификационные требования;

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

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

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

g) описание данных и требования к базам данных;

h) инсталляция и требования к приемке поставляемого программного продукта в местах функционирования и сопровождения;

i) требования к документации пользователя;

j) операции пользователя и требования к их выполнению;

k) пользовательские требования к сопровождению.

Примечание 1 - [8] может быть руководством по спецификации характеристик качества.

Примечание 2 - Следует определить приоритет выполнения требований к программным средствам.

Примечание 3 - Рекомендации для получения желаемого уровня удобства применения можно найти в [25], если приспособленность к применению является важным требованием. Вид процесса, который сосредоточивается на вопросах приспособленности к применению, приведен в приложении Е.

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

a) прослеживаемость к системным требованиям и к системному проекту;

b) внешняя согласованность с системными требованиями;

с) внутренняя согласованность;

d) тестируемость;

е) осуществимость программного проекта;

f) осуществимость функционирования и сопровождения.

7.1.2.3.1.3 Исполнитель должен проводить ревизии в соответствии с 7.2.6.

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

7.1.3 Процесс проектирования архитектуры программных средств

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

7.1.3.1 Цель

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

7.1.3.2 Выходы

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

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

b) определяются внутренние и внешние интерфейсы каждой программной составной части;

c) устанавливаются согласованность и прослеживаемость между требованиями к программным средствам и программным проектом.

7.1.3.3 Виды деятельности и задачи

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

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

7.1.3.3.1 Проектирование архитектуры программных средств

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

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

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

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

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

7.1.3.3.1.4 Исполнитель должен разработать и документально оформить предварительные версии пользовательской документации.

7.1.3.3.1.5 Исполнитель должен определить и документировать требования к предварительному тестированию и график работ по комплексированию программных средств.

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

a) прослеживаемость к требованиям программной составной части;

b) внешняя согласованность с требованиями программной составной части;

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

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

e) осуществимость детального проектирования;

f) осуществимость функционирования и сопровождения.

Результаты оценок следует оформлять документально.

7.1.3.3.1.7 Исполнитель должен проводить ревизии в соответствии с 7.2.6.

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

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

7.1.4.1 Цель

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

7.1.4.2 Выходы

В результате успешного осуществления процесса детального проектирования программных средств:

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

b) определяются внешние интерфейсы каждого программного модуля и

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

7.1.4.3 Виды деятельности и задачи

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

7.1.4.3.1 Детальное проектирование программных средств

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

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

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

7.1.4.3.1.3 Исполнитель должен разработать и документально оформить детальный проект базы данных.

7.1.4.3.1.4 Исполнитель должен совершенствовать пользовательскую документацию по мере необходимости.

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

7.1.4.3.1.6 Исполнитель должен обновлять требования к тестированию и графики работ по комплексированию программных средств.

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

a) прослеживаемость к требованиям программной составной части;

b) внешняя согласованность с архитектурным проектом;

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

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

e) осуществимость тестирования;

f) осуществимость функционирования и сопровождения.

Результаты оценки должны быть документально оформлены.

7.1.4.3.1.8 Исполнитель должен проводить ревизии в соответствии с 7.2.6.

7.1.5 Процесс конструирования программных средств

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

7.1.5.1 Цель

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

7.1.5.2 Выходы

В результате успешного осуществления процесса конструирования программных средств:

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

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

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

d) завершается верификация программных блоков относительно требований и проекта.

7.1.5.3 Виды деятельности и задачи

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

7.1.5.3.1 Конструирование программных средств

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

7.1.5.3.1.1 Исполнитель должен разработать и документально оформить:

a) каждый программный блок и базу данных;

b) процедуры тестирования и данные для тестирования каждого программного блока и базы данных.

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

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

7.1.5.3.1.4 Исполнитель должен совершенствовать требования к тестированию и графики работ по комплексированию программных средств.

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

a) прослеживаемость к требованиям и проекту программных элементов;

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

c) внутреннюю согласованность между требованиями к блокам;

d) тестовое покрытие блоков;

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

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

g) осуществимость функционирования и сопровождения.

Результаты оценки должны быть документально оформлены.

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

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

7.1.6.1 Цель

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

7.1.6.2 Выходы

В результате успешного осуществления процесса комплексирования программных средств:

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

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

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

d) программные составные части, определенные стратегией комплексирования, изготавливаются;

е) регистрируются результаты комплексного тестирования;

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

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

7.1.6.3 Виды деятельности и задачи

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

7.1.6.3.1 Комплексирование программных средств

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

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

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

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

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

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

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

a) прослеживаемость к системным требованиям;

b) внешнюю согласованность с системными требованиями;

c) внутреннюю согласованность;

d) тестовое покрытие требований к программной составной части;

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

f) соответствие ожидаемым результатам;

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

h) осуществимость функционирования и сопровождения.

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

Результаты оценки должны быть оформлены документально.

7.1.6.3.1.6 Исполнитель должен проводить ревизии в соответствии с 7.2.6.

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

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

7.1.7.1 Цель

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

7.1.7.2 Выходы

В результате успешного осуществления процесса квалификационного тестирования программных средств:

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

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

c) записываются результаты тестирования;

d) разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного средства при проведении изменений в программных составных частях.

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

7.1.7.3 Виды деятельности и задачи

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

7.1.7.3.1 Квалификационное тестирование программных средств

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

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

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

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

a) тестовое покрытие требований к программной составной части;

b) соответствие с ожидаемыми результатами;

c) осуществимость системного комплексирования и тестирования, если они проводятся;

d) осуществимость функционирования и сопровождения.

Результаты оценки должны быть документально оформлены.

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

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

Примечание - Процесс квалификационного тестирования программных средств может использоваться в процессе верификации программных средств (см. 7.2.4) или процессе валидации программных средств (см. 7.2.5).

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

7.2.1 Процесс менеджмента документации программных средств

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

7.2.1.1 Цель

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

Примечание - В [19] более детально излагается содержание информационных блоков (документации) в процессах жизненного цикла.

7.2.1.2 Выходы

В результате успешного осуществления процесса менеджмента документации программных средств:

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

b) определяются стандарты, которые применяются при разработке программной документации;

c) определяется документация, которая производится процессом или проектом;

d) указываются, рассматриваются и утверждаются содержание и цели всей документации;

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

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

7.2.1.3 Виды деятельности и задачи

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

7.2.1.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующей задачи:

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

a) заголовок или название;

b) цели и содержание;

c) круг пользователей, которым она предназначена;

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

e) графики создания промежуточных и окончательных версий.

7.2.1.3.2 Проектирование и разработка

Данный вид деятельности состоит из решения следующих задач:

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

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

7.2.1.3.2.2 Источники правомерность использования исходных данных для документов должны быть подтверждены. Могут применяться автоматизированные средства поддержки документирования.

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

7.2.1.3.3 Производство

Данный вид деятельности состоит из решения следующих задач:

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

7.2.1.3.3.2 В соответствии с процессом менеджмента конфигурации программных средств (см. 7.2.2) должны быть установлены необходимые средства управления.

7.2.1.3.4 Сопровождение

Данный вид деятельности состоит из решения следующих задач:

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

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

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

7.2.2.1 Цель

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

7.2.2.2 Выходы

В результате успешного осуществления процесса менеджмента конфигурации программных средств:

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

b) составные части, порождаемые процессом или проектом, идентифицируются, определяются и вводятся в базовую линию;

c) контролируются модификации и выпуски этих составных частей;

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

e) регистрируется и сообщается статус составных частей и модификаций;

f) гарантируются завершенность и согласованность составных частей;

g) контролируются хранение, обработка и поставка составных частей.

7.2.2.3 Виды деятельности и задачи

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

7.2.2.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующей задачи:

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

Примечание - План может быть частью плана менеджмента конфигурации системы.

7.2.2.3.2 Идентификация конфигурации

Данный вид деятельности состоит из решения следующей задачи:

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

7.2.2.3.3 Управление конфигурацией

Данный вид деятельности состоит из решения следующей задачи:

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

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

7.2.2.3.4 Отслеживание состояния конфигурации

Данный вид деятельности состоит из решения следующей задачи:

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

7.2.2.3.5 Оценка конфигурации

Данный вид деятельности состоит из решения следующей задачи:

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

7.2.2.3.6 Поставка и менеджмент выпуска

Данный вид деятельности состоит из решения следующей задачи:

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

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

7.2.3.1 Цель

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

7.2.3.2 Выходы

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

a) разрабатывается стратегия обеспечения гарантии качества;

b) создается и поддерживается свидетельство гарантии качества;

c) идентифицируются и регистрируются проблемы и (или) несоответствия с требованиями;

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

7.2.3.3 Виды деятельности и задачи

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

7.2.3.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

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

7.2.3.3.1.2 Процесс гарантии качества следует скоординировать со связными с ним процессами верификации программных средств (см. 7.2.4), валидации программных средств (см. 7.2.5), ревизии (см. 7.2.6) и аудита программных средств (см. 7.2.7).

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

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

b) процедуры пересмотра контракта и их координацию;

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

d) ресурсы, графики работ и ответственность за проведение действий по обеспечению гарантии качества;

e) выбранные действия и задачи из поддерживающих процессов, такие как верификация программных средств (см. 7.2.4), валидация программных средств (см. 7.2.5), ревизии программных средств (см. 7.2.6), аудит (см. 7.2.7) и решение проблем в программных средствах (см. 7.2.8).

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

7.2.3.3.1.5 Записи действий и задач гарантии качества должны быть доступны приобретающей стороне, как определено в контракте.

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

7.2.3.3.2 Гарантии на продукты

Данный вид деятельности состоит из решения следующих задач:

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

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

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

7.2.3.3.3 Гарантии процесса

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

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

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

7.2.3.3.4 Гарантии качества систем

Данный вид деятельности состоит из решения следующей задачи:

7.2.3.3.4.1 Дополнительные действия менеджмента качества могут быть обеспечены в соответствии с положениями [4].

7.2.4 Процесс верификации программных средств

7.2.4.1 Цель

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

7.2.4.2 Выходы

В результате успешного осуществления процесса верификации программных средств:

a) разрабатывается и осуществляется стратегия верификации;

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

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

d) определяются и регистрируются дефекты;

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

7.2.4.3 Виды деятельности и задачи

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

7.2.4.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

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

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

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

c) доступности фондов и ресурсов.

7.2.4.3.1.2 Если проектом предусматриваются работы по верификации, то должен быть установлен процесс верификации для проверки программного продукта.

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

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

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

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

7.2.4.3.2 Верификация

Данный вид деятельности состоит из решения следующих задач:

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

a) системные требования являются согласованными, выполнимыми и тестируемыми;

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

c) требования к программным средствам согласованы, выполнимы, проверяемы и точно отражают системные требования;

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

7.2.4.3.2.2 Верификация проекта

Проект должен быть верифицирован с учетом следующих критериев:

a) проект корректируется, согласуется с требованиями и обеспечивает прослеживаемость к ним;

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

c) выбранный проект может быть выведен из требований;

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

7.2.4.3.2.3 Верификация кода

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

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

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

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

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

7.2.4.3.2.4 Верификация комплексирования

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

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

b) технические и программные элементы, а также ручные операции системы комплексируются в систему;

c) задачи комплексирования выполняются в соответствии с планом комплексирования.

7.2.4.3.2.5 Верификация документации

Документация должна быть верифицирована с учетом перечисленных ниже критериев:

a) документация является адекватной, полной и согласованной;

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

c) менеджмент конфигурации документов следует установленным процедурам.

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

7.2.5.1 Цель

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

7.2.5.2 Выходы

В результате успешного осуществления процесса валидации программных средств:

a) разрабатывается и реализуется стратегия валидации;

b) определяются критерии валидации для всей требуемой рабочей продукции;

c) выполняются требуемые действия по валидации;

d) идентифицируются и регистрируются проблемы;

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

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

7.2.5.3 Виды деятельности и задачи

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

7.2.5.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

a) элементы, подвергаемые валидации;

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

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

d) процедуры передачи отчетов приобретающей стороне и другим сторонам.

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

7.2.5.3.2 Валидация

Данный вид деятельности состоит из решения следующих задач:

Примечание - Для валидации помимо тестирования могут использоваться другие средства, такие как анализ, моделирование, имитация и т.п.

7.2.5.3.2.1 Готовить выбранные требования к тестированию, тестовые примеры и спецификации для анализа результатов тестирования.

7.2.5.3.2.2 Гарантировать, что требования к тестированию, тестовые примеры и спецификации отражают частные требования для конкретного применения.

7.2.5.3.2.3 Провести проверки выполнения 7.2.5.3.2.1 и 7.2.5.3.2.2, включая:

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

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

c) тестирование того, что основные пользователи могут успешно решать намеченные задачи, используя данный программный продукт.

7.2.5.3.2.4 Подтвердить, что программный продукт удовлетворяет своему назначению.

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

7.2.6 Процесс ревизии программных средств

7.2.6.1 Цель

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

7.2.6.2 Выходы

В результате успешного осуществления процесса ревизии программных средств:

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

b) оцениваются состояние и результаты действий процесса посредством ревизии деятельности;

c) объявляются результаты ревизии всем участвующим сторонам;

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

e) идентифицируются и регистрируются риски и проблемы.

7.2.6.3 Виды деятельности и задачи

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

7.2.6.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

7.2.6.3.1.5 Результаты ревизии должны документироваться, включая оценку адекватности ревизии (например, принятие, непринятие или условное принятие результатов ревизии), и затем распространяться.

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

7.2.6.3.2 Ревизии менеджмента проекта

Данный вид деятельности состоит из решения следующей задачи:

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

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

b) поддержание глобального управления проектом посредством соответствующего распределения ресурсов;

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

d) оценку и руководство решением вопросов, связанных с риском, которые могут угрожать успеху проекта.

7.2.6.3.3 Технические ревизии

Данный вид деятельности состоит из решения следующей задачи:

7.2.6.3.3.1 Технические ревизии должны проводиться для оценки программных продуктов или услуг с позиции рассмотрения и представления свидетельств того, что:

а) они полностью укомплектованы;

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

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

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

e) они готовы к выполнению последующих запланированных работ;

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

7.2.7 Процесс аудита программных средств

7.2.7.1 Цель

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

7.2.7.2 Выходы

В результате успешного осуществления процесса аудита программных средств:

a) разрабатывается и осуществляется стратегия аудита;

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

c) аудиты проводятся соответствующими независимыми сторонами;

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

7.2.7.3 Виды деятельности и задачи

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

7.2.7.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

7.2.7.3.1.1 Аудиторские проверки должны проводиться в предварительно установленные контрольные сроки, указанные в плане (планах) проекта.

7.2.7.3.1.2 Аудиторский персонал не должен нести какой-либо прямой ответственности за проверяемые программные продукты и действия.

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

7.2.7.3.1.4 Участвующим сторонам необходимо согласовывать следующие вопросы по каждому аудиту: повестку дня; состав проверяемых программных продуктов (и результаты деятельности); область распространения и процедуры аудита; а также исходные и итоговые критерии проведения аудита.

7.2.7.3.1.5 Проблемы, выявленные при проведении аудитов, должны регистрироваться и, как установлено, должны предаваться процессу решения проблем в программных средствах (см. 7.2.8).

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

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

7.2.7.3.2 Аудит программных средств

Данный вид деятельности состоит из решения следующей задачи:

7.2.7.3.2.1 Аудиторские проверки программных средств должны проводиться для гарантии того, что:

a) когда кодирование выполнено, программные продукты (такие как программный элемент) отражают проектную документацию;

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

c) тестовые данные соответствуют спецификациям;

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

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

f) документация пользователя соответствует стандартам;

g) действия проведены в соответствии с утвержденными требованиями, планами и контрактом;

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

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

7.2.8.1 Цель

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

7.2.8.2 Выходы

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

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

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

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

d) выполняется решение проблем;

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

f) известно текущее состояние всех зафиксированных проблем.

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

7.2.8.3 Виды деятельности и задачи

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

7.2.8.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующей задачи:

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

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

- обо всех обнаруженных проблемах немедленно сообщается и они вводятся в процесс решения проблем,

- по этим проблемам инициируются необходимые действия,

- соответствующие стороны, как принято, информируются о существовании проблем,

- причины устанавливаются, анализируются и, если возможно, устраняются,

- решения и их распространение достигаются,

- состояние проблемы отслеживается и отражается в отчетах,

- отчеты о проблемах сопровождаются, как оговорено в контракте;

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

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

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

7.2.8.3.2 Решение проблем

Данный вид деятельности состоит из решения следующей задачи:

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

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

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

7.3.1.1 Цель

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

7.3.1.2 Выходы

В результате успешного осуществления процесса проектирования доменов:

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

b) определяются границы домена и его взаимосвязи с другими доменами;

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

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

e) специфицируются активы, относящиеся к домену;

f) соответствующие активы приобретаются или разрабатываются и поддерживаются в течение всего жизненного цикла;

g) модели и архитектуры домена поддерживаются в течении всего их жизненного цикла.

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

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

7.3.1.3 Виды деятельности и задачи

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

Примечание - Более детальное множество действий и задач, согласующихся с видами деятельности и задачами, приведенными ниже, представлено в [1].

7.3.1.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

7.3.1.3.1.1 Разработчик доменов должен создавать и выполнять план проектирования доменов.

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

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

7.3.1.3.2 Анализ доменов

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

7.3.1.3.2.5 Разработчик доменов должен классифицировать и документировать модели домена.

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

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

7.3.1.3.2.8 Разработчик доменов должен представлять модели домена менеджеру активов.

7.3.1.3.3 Проектирование доменов

Данный вид деятельности состоит из решения следующих задач:

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

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

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

7.3.1.3.3.4 Для каждого определенного актива спецификация должна оцениваться в соответствии с процедурами приемки и сертификации активов организации.

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

7.3.1.3.3.6 Разработчик доменов должен предоставлять архитектуру домена менеджеру активов.

7.3.1.3.4 Обеспечение активов

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

7.3.1.3.4.1 Разработчик доменов должен получать активы через приобретение или разработку.

7.3.1.3.4.2 Разработчик доменов должен документально оформлять и классифицировать активы.

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

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

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

7.3.1.3.5 Сопровождение активов

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

7.3.1.3.5.1 При анализе заявок на модификацию и выборе вариантов реализации активов разработчик доменов должен рассматривать:

a) соответствие с моделями и архитектурой домена;

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

c) воздействия на будущих пользователей активов;

d) воздействия на возможность повторного использования активов.

7.3.2 Процесс менеджмента повторного применения активов

7.3.2.1 Цель

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

7.3.2.2 Выходы

В результате успешного осуществления процесса менеджмента повторного применения активов:

a) документируется стратегия менеджмента активов;

b) формируется схема классификации активов;

c) определяются критерии приемки активов, сертификации и прекращения применения;

d) приводится в действие механизм хранения и поиска активов;

e) регистрируется использование активов;

f) контролируются изменения в активах;

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

7.3.2.3 Виды деятельности и задачи

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

7.3.2.3.1 Реализация процесса

Данный вид деятельности состоит из решения следующих задач:

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

7.3.2.3.1.2 Менеджер активов должен выполнять этот план.

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

7.3.2.3.2 Определение условий хранения и поиска активов

Данный вид деятельности состоит из решения следующих задач:

7.3.2.3.2.1 Менеджер активов должен осуществлять и поддерживать механизм хранения и поиска активов.

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

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

7.3.2.3.3 Менеджмент и управление активами

Для каждого актива данный вид деятельности состоит из решения следующих задач:

7.3.2.3.3.1 Каждый актив, принадлежащий менеджеру актива, должен быть оценен на основе критериев приемки и сертификации актива.

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

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

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

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

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

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

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

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

7.3.3 Процесс менеджмента повторного применения программ

7.3.3.1 Цель

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

7.3.3.2 Выходы

В результате успешного осуществления процесса менеджмента повторного применения программ:

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

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

c) оценивается возможность систематического повторного применения организацией;

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

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

f) реализуется стратегия повторного применения в организации;

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

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

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

7.3.3.3 Виды деятельности и задачи

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

7.3.3.3.1 Инициация

Данный вид деятельности состоит из решения следующих задач:

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

7.3.3.3.1.2 Должен быть назван спонсор повторного применения.

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

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

7.3.3.3.1.5 Должна быть установлена функция поддержки повторного применения программ.

7.3.3.3.2 Идентификация домена

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

7.3.3.3.3 Оценки повторного применения

Данный вид деятельности состоит из решения следующих задач:

7.3.3.3.3.1 Администратор повторного применения программ должен оценивать возможности систематического повторного применения в организации.

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

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

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

7.3.3.3.4 Планирование

Данный вид деятельности состоит из решения следующих задач:

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

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

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

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

7.3.3.3.5 Выполнение и управление

Данный вид деятельности состоит из решения следующих задач:

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

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

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

7.3.3.3.5.4 Администратор повторного применения программ должен периодически подтверждать финансовую поддержку менеджмента, поддержку и обязательства по программе повторного применения.

7.3.3.3.6 Ревизии и оценивание

Данный вид деятельности состоит из решения следующих задач:

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

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

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