"ГОСТ Р ИСО/МЭК 90003-2014. Национальный стандарт Российской Федерации. Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов"
(утв. и введен в действие Приказом Росстандарта от 23.10.2014 N 1405-ст)

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 "Системы менеджмента"

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 90003:2014 "Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов" (ISO/IEC 90003:2014 "Software engineering - Guidelines for the application of ISO 9001:2008 to computer software", IDT).

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

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

6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.

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

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

Разделы 4, 5 и 6 и составные части раздела 8 ИСО 9001:2008 применимы преимущественно на "глобальном" уровне в организации, хотя они могут иметь желательный результат и на "проектном/программном уровне". Каждый проект или разработка продукции может учитывать или ориентироваться на соответствующие элементы системы менеджмента качества организации для обеспечения соответствия требованиям, относящимся к реализуемому проекту/выпускаемой продукции.

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

Организации, внедрившие системы менеджмента качества для разработки, осуществления эксплуатации или сопровождения программных продуктов на основе положений настоящего стандарта, могут принимать решение об использовании процессов из ИСО/МЭК 12207 в целях обеспечения или дополнения модели процессного подхода ИСО 9001:2008. Соответствующие параграфы ИСО/МЭК 12207:2008 указаны в каждом разделе настоящего стандарта, однако они не заключают в себе требования в дополнение к тем требованиям, что имеются в ИСО 9001:2008. Дальнейшее руководство с указаниями по применению ИСО/МЭК 12207 содержится в ИСО/МЭК 24748-3. Что касается дополнительного руководства, ИСО/МЭК JTC 1/SC7 вырабатывает регулярные сообщения применительно к международным стандартам для разработки программных продуктов. В случаях когда эти сообщения (ссылки) относятся непосредственно к какому-либо пункту или подпункту ИСО 9001:2008, они помещаются после руководящих указаний для данного пункта или подпункта. В случае когда они применяются повсеместно в положениях пункта или подпункта, эти ссылки помещают в конце заключительной части пункта или подпункта.

В тех местах настоящего стандарта, где текст был приведен из ИСО 9001:2008, данный текст в целях облегчения его идентификации заключен в рамку.

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

В приложении A (справочном) представлена таблица с дополнительными указаниями по внедрению ИСО 9001:2008, имеющимися в международных стандартах, разработанных ИСО/МЭК JTC 1/SC7 и ИСО/ТК 176.

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

Настоящий стандарт применим к программным продуктам, которые:

- являются элементом коммерческого контракта, заключенного с другой организацией;

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

- используются для обеспечения реализации процессов организации;

- встроены в техническую продукцию/оборудование, и

- относятся к программным услугам.

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

В настоящем стандарте применены термины и определения, данные в ИСО 9000:2005 [1], и некоторые термины (включенные в настоящий стандарт для удобства пользования), данные в ИСО/МЭК 12207:2008 [7].

Однако в тех случаях, когда возникают противоречия в терминах и определениях, следует применять термины и определения, установленные в ИСО 9000:2005 [1].

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

3.1 деятельность (activity): Совокупность взаимосвязанных задач по реализации процесса.

[ИСО/МЭК 12207:2008, 4.3]

3.2 базовая линия (baseline): Официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации.

[ИСО/МЭК 12207:2008, 4.6]

3.3 элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяет функции конечного использования и может быть однозначно определен в данной эталонной точке.

[ИСО/МЭК 12207:2008, 4.7]

3.4 COTS (COTS Commercial-Off-The-Shelf) (предназначенный для продажи готовый продукт): Программный продукт, имеющийся в продаже, который может быть использован без выполнения действий, связанных с разработкой.

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

3.6 модель жизненного цикла (life cycle model): Структура, состоящая из процессов, работ и задач, относящихся к жизненному циклу программного продукта, который может быть разделен на этапы, и которая используется для лучшего взаимопонимания.

Примечание - Требования ИСО 9001:2008 [2] могли бы применяться к сопровождению, только если это обусловлено контрактными требованиями, после приемки продукта потребителем. Однако, как правило, эти требования не применяются к деятельности по сопровождению.

[ИСО/МЭК 12207:2008, 4.17]

3.7 измерять (measure): Проводить измерение.

[ИСО/МЭК 15939:2007, 2.16]

3.8 мера измерения (measure): Переменная, которой присваивается значение, полученное в результате проведения измерения.

[ИСО/МЭК 15939:2007, 2.15]

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

[ИСО/МЭК 15939:2007, 2.17]

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

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

[ИСО 9000:2008, 3.4.1]

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

3.12 выпуск (release): Конкретная версия элемента конфигурации, которая доступна для реализации конкретной цели.

[ИСО/МЭК 12207:2008, 4.35]

3.13 тиражирование (replication): Копирование программного продукта с одного носителя на другой.

3.14 программный элемент (software item): Идентифицируемый компонент программного продукта.

3.15 программный продукт (software product): Набор машинных программ, процедур и возможно связанных с ними документации и данных.

Примечания

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

2 Отличается от определения ИСО 9000.

3 В настоящем стандарте термины "software" и "software product" являются синонимами.

[ИСО/МЭК 12207:2008, 4.4.2]

Для 4.1 a) и b) ИСО 9001:2008 относительно организационных процессов предлагается руководство согласно приведенному ниже тексту (см. 5.4.2 и 7.4.1 для дополнительного руководства по аутсорсингу).

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

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

b) Последовательность и взаимодействие процессов

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

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

2) при планировании качества и разработки, основанном на модели жизненного цикла.

Примечание - Для получения дополнительной информации см. следующее:

- ИСО/МЭК 12207:2008 [7] (процессы жизненного цикла программных продуктов), который определяет набор процессов жизненного цикла продукции и который можно использовать в качестве образца;

- ИСО/МЭК/ТО 24748-1 [23] и ИСО/МЭК/ТО 24748-3, [24], которые дают руководство в отношении того, каким образом использовать процессы из ИСО/МЭК 12207 применительно к различным жизненным циклам.

Документы для осуществления результативного планирования, эксплуатации и управления процессами для программных продуктов [4.2.1 d) ИСО 9001:2008] могут охватывать следующее:

1) описания процессов, например процессов, идентифицированных в ходе внедрения 4.1;

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

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

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

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

Примечание - Для получения дополнительной информации по идентификации документации как элемента управления конфигурацией (см. 7.5.3).

Примечание - Для получения дополнительной информации по идентификации документации как элемента управления конфигурацией (см. 7.5.3).

4.2.4.1 Свидетельство соответствия требованиям

Свидетельство соответствия требованиям может включать:

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

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

c) заявки на проведение изменений;

d) документы, снабженные комментариями;

e) отчеты по аудитам и оценкам соответствия, и

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

4.2.4.2 Свидетельство результативного функционирования

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

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

b) оценками, например, масштаб проекта и объем работ (персонал, затраты, график работ);

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

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

e) протоколами совещаний, и

f) записями, связанными с выпусками программных продуктов.

4.2.4.3 Сохранение и удаление

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

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

Примечание - Для дополнительного общего руководства, относящегося к 4.2 ИСО 9001:2008 [2], см. 6.3.6 (процесс менеджмента информации) и 7.2.1 (процесс менеджмента документации программных продуктов) ИСО/МЭК 12207:2008 [7].

Примечания

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

2 Информация по качественным характеристикам, их составляющим и свойствам программных продуктов, подходящая для установления целей в области качества, определена в ИСО/МЭК 25010 [26]. Серия стандартов ИСО/МЭК 25000 помогает в определении требований к качеству и в управлении целями в области качества программных продуктов.

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

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

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

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

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

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

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

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

g) идентификацию любого многократного или повторного использования программного продукта (см. также 7.5.4).

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

Планирование качества программных продуктов на уровне проекта/продукта рассматривается в 7.1.

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

Для 5.6.2 c) ИСО 9001:2008 [2] предлагается руководство согласно следующему:

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

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

Примечание - Для получения дополнительной информации см. 6.2.4 (процесс менеджмента человеческих ресурсов) ИСО/МЭК 12207:2008 [7].

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

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

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

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

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

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

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

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

c) менеджмент знаний, внутрисетевые (локальная интрасеть) и внешнесетевые (экстрасеть) ресурсы;

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

e) справочные меню и средства сопровождения;

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

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

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

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

Примечание - Для получения дополнительной информации см. следующее:

- 6.2.2 (процесс создания инфраструктуры) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 25001 (заказ) [25] и ИСО/МЭК 25040 [28] (оценка программного продукта);

- ИСО/МЭК 14102:2008 [8].

Необходимо планировать и осуществлять процессы, действия и задачи, используя модели жизненного цикла, отвечающие специфике проекта, связанного с выпуском программного продукта, рассматривая его масштаб, сложность, безопасность, риски и обеспечение сохранности. ИСО 9001:2008 [2] предназначен для применения независимо от того, какие модели жизненного цикла используются, и не ставит перед собой цель по указанию какой-либо конкретной модели или последовательности процессов.

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

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

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

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

Примечания

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

2 ИСО/МЭК 12207:2008 [7] содержит положения по планированию качества и разработки как отдельного вида деятельности по планированию, приводящего к созданию плана/планов по управлению проектом. В приложении B представлена таблица соответствия для демонстрации того, как согласуются положения, изложенные в 7.1.1 и 7.1.3, с соответствующими положениями в 6.1.2.3.4.5, 7.1.1.3.1.4 и 7.2.3.3.1.3 ИСО/МЭК 12207:2008 [7].

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

a) включение или ссылка на планы для разработки (см. 7.3.1);

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

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

[ИСО 9001:2008, 1.2];

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

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

f) критерии для запуска и завершения каждой проектной стадии;

g) типы анализа и другие действия по верификации и валидации, которые планируется осуществлять (см. 7.3.4, 7.3.5 и 7.3.6);

h) запланированные для проведения процедуры по управлению конфигурацией (см. 7.5.3);

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

j) лицо/лица, ответственные за одобрение выходных данных процессов для последующего использования;

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

l) записи, которые надлежит вести и поддерживать (см. 4.2.4);

m) управление изменениями, например, касающимися ресурсов, сроков реализации и контрактов.

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

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

Примечание - Для дополнительного руководства общего характера, относящегося к 7.1 ИСО 9001:2008 [2], см. следующее:

- 6.3.1 (процесс планирования проекта), и 7.2 (вспомогательные процессы для жизненного цикла программных продуктов) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 25010:2011 [26];

- ИСО/МЭК 25001:2007 [25];

- ИСО/МЭК 16326:2009 [19].

7.2.1.1 Требования, относящиеся к потребителям [7.2.1 a) и b) ИСО 9001:2008] [2].

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

Конкретные действия могут включать:

a) учреждение для разработки требований следующего:

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

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

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

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

c) получение одобрения потребителем требований;

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

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

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

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

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

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

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

7.2.1.2 Дополнительные требования, определенные организацией [7.2.1 d) ИСО 9001:2008] [2]

Примечания

1 Для получения дополнительной информации по 7.2.1.1 см. следующее:

- 6.4.2 (процесс анализа требований к системе), 6.4.3 (процесс разработки архитектуры системы) и 7.1.2 (анализ требований к программным продуктам) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 29148:2011 [31];

- ИСО/МЭК 25010:2011 [26];

- ИСО/МЭК 15026-3:2011 [11].

2 Для получения дополнительной информации по 7.2.1.2 см. ИСО/МЭК 25051:2006 [29].

7.2.2.1 Вопросы, рассматриваемые организацией

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

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

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

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

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

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

f) требования по тиражированию и распространению;

g) вопросы, касающиеся потребителя:

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

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

h) вопросы, касающиеся менеджмента:

1) должно рассматриваться управление рисками (см. также 7.2.2.2);

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

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

4) требования к инсталляции, сопровождению и организационно-техническому обеспечению;

5) своевременное наличие технических, человеческих и финансовых ресурсов;

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

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

2) охрана эталонного экземпляра (мастер-копии) продукта и прав потребителя на доступ или верификацию данного экземпляра;

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

4) определение гарантийных сроков;

5) обязательства/наказания, связанные с нарушением контрактных требований.

7.2.2.2 Риски

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

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

b) возможности и опыт организации или ее поставщиков;

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

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

e) значительный территориальный разброс организации, ее потребителей, пользователей и поставщиков;

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

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

h) низкая точность, правильность и стабильность определения требований потребителей и внешних интерфейсов.

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

7.2.2.3 Представитель потребителя

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

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

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

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

Примечание - Для получения дополнительной информации в отношении анализа требований см. 6.1.2 (процесс поставок), 6.1.2.3.4.14 (верификация) и 7.2.6 (процесс анализа) ИСО/МЭК:2008 [7]. Для получения дополнительной информации по требованиям и инжинирингу по выявлению, анализу верификации и валидации требований потребителей см. ИСО/МЭК 29148 [31]. Для получения дополнительной информации по менеджменту рисков см. 6.3.4 (менеджмент рисков) ИСО/МЭК 12207:2008 [7] и ИСО/МЭК 16085:2006 [18]. Для получения дополнительной информации по анализу требований к качеству, используя качественные характеристики, см. ИСО/МЭК 25010:2011 [26].

7.2.3.1 Общие требования

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

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

7.2.3.2 Связь с потребителями на стадии разработки

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

a) информацию о продукте, включающую:

1) планы по разработке,

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

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

4) результаты приемо-сдаточных испытаний/тестирования;

b) запросы и исследования, контракты и исправления/поправки, включая:

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

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

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

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

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

7.2.3.3 Связь с потребителями на стадии эксплуатации и сопровождения продукции

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

a) информацию о продукте, включая:

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

2) описания выпусков новых и обновленных версий, и

3) веб-сайты, содержащие информацию о продукции;

b) запросы и исследования, контракты и исправления/поправки, включая

1) состояние дел и продвижение действий, связанных с доставкой и/или сопровождением продукции или услуг, и

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

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

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

2) состояние дел и прогресс в работе по обращению с жалобами потребителей, и

3) обследования, пользовательские группы, конференции.

Примечание - Для дополнительной информации см. следующее:

- 7.2.6 (процесс анализа программных продуктов), 6.1.2 (процесс поставок), 6.4.9.3.4 (поддержка потребителей) и F.3 (процесс менеджмента изменений контракта) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 14764:2006 [10] (сопровождение программных продуктов).

7.3.1.1 Планирование проектирования и разработки

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

Примечания

1 ИСО/МЭК 12207:2008 [7] содержит положения по планированию качества и планированию разработки как единой деятельности по планированию, приводящей к созданию плана/планов по менеджменту проекта. В приложении B представлена таблица соответствия, чтобы показать, как положения в 7.1.1 и 7.3.1 согласуются с соответствующими положениями 6.1.2.3.4.5, 7.1.1.3.1.4 и 7.2.3.3.1.3 ИСО/МЭК 12207:2008 [7].

2 Некоторые подпункты в следующем перечне были включены в перечень по планированию качества в 7.1.2. Они выделены квадратными скобками.

При планировании проектирования и разработки следует рассматривать следующие вопросы, насколько это применимо:

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

1) действия, подлежащие выполнению,

2) требуемые входные данные для каждого действия,

3) требуемые выходные данные каждого действия,

4) верификацию, требуемую для результата/выхода каждого действия [согласно 7.1.2 g) - см. также 7.3.5];

5) действия по управлению и поддержке, которые должны выполняться,

6) требуемое обучение/подготовка для соответствующих групп работников [согласно 7.1.2 k)];

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

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

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

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

f) график мероприятий, устанавливающий:

1) стадии реализуемого проекта [см. также 7.1.2 j)];

2) схему распределения работ;

3) соответствующие ресурсы и временные сроки;

4) соответствующие структуры зависимости и подчиненности;

5) стратегические ориентиры;

6) действия по верификации и валидации [согласно п. 7.1.2 g)];

g) идентификация:

1) стандартов, правил, практик и соглашений, методологии, модели жизненного цикла, законодательных и других обязательных требований [согласно 7.1.2 d) и e)],

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

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

4) практик по управлению конфигурацией [согласно 7.1.2 h)],

5) способа управления несоответствующей программной продукцией,

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

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

8) методов контроля для защиты от вирусов,

9) средств защиты от несанкционированного доступа к данным;

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

i) управление документированием, включая архивирование и распространение документов/записей.

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

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

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

7.3.1.2 Анализ, верификация и валидация

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

7.3.1.3 Должностные обязанности и полномочия

Не предлагается отдельных руководящих указаний.

7.3.1.4 Интерфейсы

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

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

Примечания

1 Для получения дополнительной информации по планированию проектирования и разработки см. 6.3.1 (процесс планирования проекта) ИСО/МЭК 12207:2008 [7].

2 Для получения дополнительной информации по менеджменту проекта, связанному с программными средствами, см. 6.1 (процесс планирования проекта) ИСО/МЭК 16326:2009 [19].

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

Для руководства по 7.3.2 a), b) и d) см. 7.2.1 ИСО 9001:2008 [2].

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

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

a) неопределенности и противоречий;

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

c) нереалистичных требований/спецификаций в отношении характеристик работы;

d) требований, которые не могут быть верифицированы или валидированы;

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

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

g) отсутствия решений по проектированию и разработке в документе, содержащем требования, и

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

Примечание - Для дополнительной информации см. ИСО/МЭК 25010:2011 [26] для требований к качеству программных продуктов как характеристикам качества программных продуктов.

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

a) спецификации по проектированию, разработке и тестированию;

b) модели данных;

c) символический или исходный программный код;

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

e) разработанный продукт; и

f) формализованные методы.

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

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

Должна проводиться валидация инструментальных средств для их намеченного целевого использования (см. 7.3.6 и 7.6).

Примечание - Для получения дополнительной информации см. 7.1.3 - 7.1.5 (процесс разработки архитектуры программных продуктов, детализированный процесс разработки программных продуктов, процесс строительства программных продуктов) ИСО/МЭК 12207:2008 [7].

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

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

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

Примечания

1 В ИСО/МЭК 12207:2008 [7] управление проектом и технические анализы трактуются как отдельные виды деятельности. В приложении B приводится таблица соответствия для демонстрации того, как соответствующие позиции в приводимом по тексту перечне выполняются в 7.2.6 ИСО/МЭК 12207:2008 [7].

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

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

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

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

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

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

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

g) критерии успешного выполнения анализа;

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

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

2 Для дополнительной информации см. следующее:

- 7.1.2.3.1.2, 7.1.3.3.1.6 и 7.1.4.3.1.7 (требования и оценивание проектов) и 7.2.6.3.3 (технические анализы) ИСО/МЭК 12207:2008 [7].

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

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

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

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

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

Примечание - Для дополнительной информации см. 6.4 (разработка) и 7.2.4 (верификация) ИСО/МЭК 12207:2008 [7].

7.3.6.1 Валидация

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

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

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

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

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

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

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

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

7.3.6.2 Тестирование

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

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

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

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

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

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

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

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

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

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

Примечание - Для получения дополнительной информации см. 6.4 (технические процессы) и 7.2.5 (валидация) ИСО/МЭК 12207:2008 [7]. Для получения дополнительной информации по верификации посредством оценки качества с использованием качественных характеристик и показателей см. ИСО/МЭК 25010 [26] и ИСО/МЭК 25000.

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

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

Примечания

1 Для получения дополнительной информации см. 6.4.10.3.2 и 6.4.10.3.3 (модификации), 6.3.6 и 7.2.1 (документация) и 6.3.5 и 7.2.7 (управление конфигурацией) ИСО/МЭК 12207:2008 [7].

2 Для дополнительного общего руководства, относящегося к 7.3 ИСО 9001:2008 [2], см. следующее:

- для руководства по любым имеющимся в продаже готовым программным продуктам (COTS) см. ИСО/МЭК 25051:2006 [29];

- для руководства по созданию документации для проектирования и разработки см. ИСО/МЭК 26514:2008 [30];

- для руководства по оценке методов измерения функциональных размеров см. ИСО/МЭК 19761:2011 [20], ИСО/МЭК 20926:2009 [21] и ИСО/МЭК 20968:2002 [22];

- для руководства по классификации прототипов и примерам использования см. ИСО/МЭК/ТО 14759:1999 [9];

- для процесса создания документации пользователя программного средства см. ИСО/МЭК 26514:2008 [30].

7.4.1.1 Закупленная продукция

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

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

a) имеющиеся в продаже готовые программные продукты (COTS) или условно бесплатное программное обеспечение;

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

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

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

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

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

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

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

i) обучающие курсы и материал.

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

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

7.4.1.2 Управление закупленным продуктом

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

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

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

В некоторых ситуациях в процессе взаимоотношений между организацией и поставщиком могут применяться все положения ИСО 9001:2008 [2]. Управление рисками зачастую имеет решающее значение на стадии разработки программных продуктов вследствие характера или специфики продукта.

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

Примечания

1 Для получения дополнительной информации см. 6.1.1 (процесс заказа) ИСО/МЭК 12207:2008 [7].

2 Для получения дополнительной информации, касающейся оценивания характеристик и пригодности процессов поставщика, см. ИСО/МЭК 15504-3 [14].

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

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

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

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

d) процедуры и/или рабочие инструкции, которых должен придерживаться поставщик;

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

f) описание целевой среды (например, оборудование, операционная система) и

g) требования к персоналу (например, предварительное обучение, знание продукции).

Аспекты, охваченные в 7.2.2, могут также быть применимыми и в отношении субподрядчиков.

Примечание - Для получения дополнительной информации см. 6.1.1.3.1 (подготовка закупки) и 6.1.1.3.2 (объявление о закупке) ИСО/МЭК 12207:2008 [7].

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

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

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

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

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

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

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

Примечания

1 Для получения дополнительной информации см. 6.1.1.3.6 (закупка - одобрение заказчиком) ИСО/МЭК 12207:2008 [7].

2 Для дополнительного общего руководства в отношении 7.4 ИСО 9001:2008 [2] см. следующее:

- ИСО/МЭК 25010:2011 [26] для руководства в отношении характеристик качества, необходимых для закупаемого программного продукта;

- ИСО/МЭК 25040 [27] и 25041 [28];

- ИСО/МЭК 19761:2011 [20], ИСО/МЭК 20926:2009 [21] и ИСО/МЭК 20968:2002 [22] для руководства по оценке методов измерения функциональных размеров.

7.5.1.1 Производство и обслуживание применительно к программному продукту

Как написано в руководящих указаниях для проектирования и разработки (см. 7.3), проект, связанный с разработкой программного продукта, должен быть организован в виде совокупности процессов, преобразующих требования в программный продукт. Требования по "управлению производством и обслуживанием", установленные в 7.5.1 ИСО 9001:2008 [2], применительно к программным продуктам соответствуют:

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

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

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

7.5.1.2 Создание и выпуск

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

К созданию и выпуску применимы следующие положения:

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

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

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

7.5.1.3 Тиражирование

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

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

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

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

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

e) снабжение в целях обеспечения правильности и завершенности копий продукта.

7.5.1.4 Доставка

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

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

7.5.1.5 Инсталляция

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

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

b) следует определить потребность валидации и ее объем для каждой инсталляции;

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

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

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

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

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

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

i) следует обеспечить наличие подготовленного персонала;

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

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

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

7.5.1.6 Операции по эксплуатации

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

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

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

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

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

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

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

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

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

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

f) управление конфигурацией, тестирование и действия по обеспечению качества;

g) расписание запланированных выпусков;

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

i) записи и отчеты, связанные с деятельностью по сопровождению.

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

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

Примечание - Для получения дополнительной информации см. 6.4.7 (инсталляция программных средств), 6.4.9.3.4 (поддержка пользователей), 6.4.10 (процесс сопровождения), 7.2.3.3.3 (обеспечение процессов) и 7.2.8 (процесс разрешения проблем) ИСО/МЭК 12207:2008 [7].

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

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

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

Какие бы методы не использовались, они должны быть соразмерны рискам и последствиям, связанным с ошибками проектирования и разработки.

7.5.3.1 Общий обзор

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

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

7.5.3.2 Процесс управления конфигурацией

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

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

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

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

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

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

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

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

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

i) обеспечение управления выпуском и поставкой.

7.5.3.3 Прослеживаемость

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

Примечание - Для получения дополнительной информации см. следующее:

- ИСО 10007:2003 [6] (руководящие указания по управлению конфигурацией);

- 6.3.5 и 7.2.2 (процесс менеджмента конфигурации) ИСО/МЭК 12207:2008 [7].

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

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

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

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

d) эксплуатационные данные и данные испытаний;

e) интерфейсы или другие спецификации;

f) технические средства и

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

В любом соглашении по сопровождению следует уделять внимание

- требуемому лицензированию и обеспечению, включая последующие ревизии продукта, и

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

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

Методы для идентификации поставляемого потребителем продукта должны быть элементом управления конфигурацией для конкретного продукта (см. 7.5.3).

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

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

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

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

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

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

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

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

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

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

Примечание - Для получения дополнительных общих руководящих указаний по 7.5 ИСО 9001:2008 [2] см. следующее:

- ИСО/МЭК 25010:2011 [26];

- ИСО/МЭК 14764:2001 [10];

- ИСО/МЭК 26514:2008 [30].

Калибровка - это методика, которая часто воспринимается как напрямую неприменимая к программным средствам. Однако она может быть применима к техническим средствам и инструментам, используемым для тестирования и валидации программного средства. Следовательно, подпункты 7.6 a) - e) в ИСО 9001:2008 [2] могут быть применимы к оборудованию, используемому при тестировании программных средств.

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

Хотя "отрегулировано или повторно отрегулировано по мере необходимости" [7.6 b) ИСО 9001:2008] [2] неприменимо к программному обеспечению, может понадобиться периодически верифицировать, что программное обеспечение, используемое в измерительном оборудовании, не подверглось изменению вследствие своего нахождения в суровых условиях, связанных с воздействием внешней среды, таких как компьютерные вирусы или электромагнитные поля.

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

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

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

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

c) компьютерное оборудование, и

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

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

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

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

Примечание - Для получения дополнительной информации см. следующее:

- 6.2.1.3.3 (процесс по улучшению деятельности) и 6.3.7 (менеджмент процессов) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 15939:2007 [17];

- ИСО/МЭК 15504-1 [12];

- ИСО/МЭК/ТО 9126-2:2003 [3] и ИСО/МЭК/ТО 9126-3:2003 [4] (качество продуктов - внутренние и внешние показатели);

- ИСО/МЭК 25001:2007 [25].

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

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

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

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

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

Примечание - Для получения дополнительной информации см. ИСО/МЭК/ТО 9126-4 [5] (качество продукта - показатели эксплуатационного качества).

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

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

Примечание - Для получения дополнительной информации см. 7.2.3 (процесс обеспечения качества) и 7.2.7 (процесс аудита) ИСО/МЭК 12207:2008 [7].

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

a) плановую и фактическую длительность процесса;

b) плановые и фактические затраты, связанные с реализацией мероприятий процесса, и

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

Примечания

1 Для получения дополнительной информации см. 6.2.1.3.2 (оценка процессов) и 6.2.1.3.3 (процесс по улучшению деятельности) ИСО/МЭК 12207:2008 [7].

2 Для руководства по проведению оценки процессов, связанных с программными средствами, см. ИСО/МЭК 15504-1 [12] и по выполнению оценки см. ИСО/МЭК 15504-2 [13]. См. также раздел 5 (процесс измерения программных средств) ИСО/МЭК 15939:2007 [17].

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

a) функциональность;

b) ремонтопригодность;

c) эффективность;

d) портативность;

e) практичность (удобство и простота использования);

f) надежность.

Примечание - Для получения дополнительной информации см. следующее:

- 6.4 (процесс разработки) ИСО/МЭК 12207:2008 [7], содержащий положения для оценивания программных продуктов в процессе их разработки и по завершении;

- ИСО/МЭК 25010:2011 [26];

- ИСО/МЭК 25040 [27] и ИСО/МЭК 25041 [28].

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

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

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

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

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

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

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

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

a) ремонта или доработки (т.е. приведение в надлежащее состояние) в целях соответствия установленному требованию;

b) приемки с ремонтом или без ремонта с отклонением;

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

d) отклонения.

Примечание - Для получения дополнительной информации см. следующее:

- 6.3.5 (процесс управления конфигурацией) и 7.2.8 (процесс по разрешению проблем) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 25051:2006 [29].

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

Примечание - Для получения дополнительной информации см. следующее:

- 4.4 (процесс измерения программных средств - результаты оценок) ИСО/МЭК 15939:2007 [17];

- ИСО/МЭК 19761:2011 [20], ИСО/МЭК 20926:2009 [21] и ИСО/МЭК 20968:2002 [22].

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

Примечание - Для получения дополнительной информации см. следующее:

- 6.2.1.3.3 (процесс, связанный с улучшением) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 15504 (все части) (оценка процессов, связанных с программными средствами).

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

Примечание - Для получения дополнительной информации см. 7.2.8 (процесс по разрешению проблем) ИСО/МЭК 12207:2008 [7].

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

Примечание - Для получения дополнительной информации, относящейся к 8.5 ИСО 9001:2008 [2] см. следующее:

- 6.2.1.3.3 (оценка процессов) ИСО/МЭК 12207:2008 [7];

- ИСО/МЭК 15504-2 [13].

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

ИСО/МЭК 12207:2008 [7] включает в себя положения по планированию качества и планированию разработки как отдельного вида деятельности по планированию, ведущего к созданию плана/планов по управлению проектом. Представленная в этом приложении таблица соответствия служит для демонстрации того, как обеспечивается выполнение положений, изложенных в 7.1.2, 7.3.1 и 7.3.4 настоящего стандарта, посредством соответствующих положений 6.1.2.3.4.5, 7.1.1.3.1.4 и 7.2.3.3.1.3 в ИСО/МЭК 12207:2008 [7] (и других подпунктов в соответствии с ссылками в примечаниях). В дополнение к этому настоящее приложение охватывает управление проектом и технические пересмотры из 7.2.6 ИСО/МЭК 12207:2008 [7], которые соответствуют анализам в ходе проектирования и разработки в 7.3.4 ИСО 9001:2008 [2].

--------------------------------

<*> Действует ГОСТ Р ИСО 9001-2015.