agosty.ru03. УСЛУГИ. ОРГАНИЗАЦИЯ ФИРМ, УПРАВЛЕНИЕ И КАЧЕСТВО. АДМИНИСТРАЦИЯ. ТРАНСПОРТ. СОЦИОЛОГИЯ.03.120. Качество

ГОСТ Р ИСО/МЭК 90003-2014 Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов

Обозначение:
ГОСТ Р ИСО/МЭК 90003-2014
Наименование:
Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов
Статус:
Действует
Дата введения:
01.01.2016
Дата отмены:
-
Заменен на:
-
Код ОКС:
03.120.10, 35.080

Текст ГОСТ Р ИСО/МЭК 90003-2014 Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов


ГОСТ Р ИСО/МЭК 90003-2014


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

РАЗРАБОТКА ПРОГРАММНЫХ ПРОДУКТОВ

Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов

Software engineering. Guidelines for the application of ISO 9001:2008 to computer software

ОКС 03.120.10

Дата введения 2016-01-01

Предисловие

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 г.

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

Введение

Настоящий стандарт является руководящим указанием для организаций по применению ИСО 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, данный текст в целях облегчения его идентификации заключен в рамку.

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

1.1 Общие положения

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

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

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

Примечания

1 В настоящем стандарте термин "продукция" применим только:

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

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

2 Законодательные и другие обязательные требования могут быть выражены как правовые требования.

[ИСО 9001:2008 Системы менеджмента качества. Требования] [2]

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

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

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

1.2 Применение

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

2 Нормативные ссылки

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

ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь.

[ИСО 9001:2008] [2]



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

В настоящем стандарте применены термины и определения, данные в ИСО 9000.

В тексте настоящего стандарта термин "продукция" может означать также "услуга".

[ИСО 9001:2008] [2]

В настоящем стандарте применены термины и определения, данные в ИСО 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 Система менеджмента качества

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

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

Организация должна:

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

c) возможность обеспечения необходимого управления посредством применения требований 7.4.

[ИСО 9001:2008] [2]

Для 4.1 а) и 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 Требования к документации

4.2.1 Общие положения

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

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

b) руководство по качеству;

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

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

Примечания

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

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

a) от размера организации и вида деятельности;

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

c) от компетентности персонала.

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

4.2.2 Руководство по качеству

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

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

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

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

[ИСО 9001:2008] [2]

4.2.3 Управление документацией

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

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

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

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

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

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

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

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

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

[ИСО 9001:2008] [2]

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

4.2.4 Управление записями

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

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

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

[ИСО 9001:2008] [2]

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].

5 Ответственность руководства

5.1 Обязательства руководства

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

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

b) разработки политики в области качества;

c) обеспечения разработки целей в области качества;

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

e) обеспечения необходимыми ресурсами.

[ИСО 9001:2008] [2]


5.2 Ориентация на потребителя

Высшее руководство должно обеспечивать определение и выполнение требований потребителей для повышения их удовлетворенности (7.2.1 и 8.2.1).

[ИСО 9001:2008] [2]


5.3 Политика в области качества

Высшее руководство должно обеспечивать, чтобы политика в области качества:

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

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

c) создавала основы для постановки и анализа целей в области качества;

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

e) анализировалась на постоянную пригодность.

[ИСО 9001:2008] [2]


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

5.4.1 Цели в области качества

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

[ИСО 9001:2008] [2]

Примечания

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

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

5.4.2 Планирование создания и развития системы менеджмента качества

Высшее руководство должно обеспечивать:

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

b) сохранение целостности системы менеджмента качества при планировании и внедрении в нее изменений.

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

5.5 Ответственность, полномочия и обмен информацией

5.5.1 Ответственность и полномочия

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

[ИСО 9001:2008] [2]

5.5.2 Представитель руководства

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

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

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

c) на содействие распространению понимания требований потребителей по всей организации.

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

[ИСО 9001:2008] [2]

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

5.5.3 Внутренний обмен информацией

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

[ИСО 9001:2008] [2]



5.6 Анализ со стороны руководства

5.6.1 Общие положения

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

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

[ИСО 9001:2008] [2]

5.6.2 Входные данные для анализа

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

a) результаты аудитов (проверок);

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

c) функционирование процессов и соответствие продукции;

d) статус предупреждающих и корректирующих действий;

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

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

g) рекомендации по улучшению.

[ИСО 9001:2008] [2]

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

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

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

5.6.3 Выходные данные анализа

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

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

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

c) к потребности в ресурсах.

[ИСО 9001:2008] [2]



6 Менеджмент ресурсов

6.1 Обеспечение ресурсами

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

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

b) для повышения удовлетворенности потребителей путем выполнения их требований.

[ИСО 9001:2008] [2]



6.2. Человеческие ресурсы

6.2.1 Общие положения

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

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

[ИСО 9001:2008] [2]

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

6.2.2 Компетентность, подготовка и осведомленность

Организация должна:

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

6.3 Инфраструктура

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.4 Производственная среда

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

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

[ИСО 9001:2008] [2]


7 Процессы жизненного цикла продукции

7.1 Планирование процессов жизненного цикла продукции

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

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

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

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

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

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

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

Примечания

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

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

[ИСО 9001:2008] [2]

7.1.1 Жизненный цикл программных продуктов

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

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

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

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

7.1.2 Планирование качества

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

Примечания

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

2 ИСО/МЭК 12207:2008 [7] содержит положения по планированию качества и разработки как отдельного вида деятельности по планированию, приводящего к созданию плана/планов по управлению проектом. В приложении В представлена таблица соответствия для демонстрации того, как согласуются положения, изложенные в 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) потребности в обучении и профессиональной подготовке для использования инструментальных средств, методик и программ, и составление графиков мероприятий по обучению до того, как возникнет необходимость в использовании требуемых навыков;

I) записи, которые надлежит вести и поддерживать (см. 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 Процессы, связанные с потребителями

7.2.1 Определение требований, относящихся к продукции

Организация должна определить:

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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 Анализ требований, относящихся к продукции

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

a) определение требований к продукции;

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

c) способность организации выполнять определенные требования.

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

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

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

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

[ИСО 9001:2008] [2]

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 Связь с потребителями

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

a) информации о продукции;

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

c) обратной связи от потребителей, включая жалобы потребителей.

[ИСО 9001:2008] [2]

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 Проектирование и разработка

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

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

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

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

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

Примечания

1 ИСО/МЭК 12207:2008 [7] содержит положения по планированию качества и планированию разработки как единой деятельности по планированию, приводящей к созданию плана/планов по менеджменту проекта. В приложении В представлена таблица соответствия, чтобы показать как положения в 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) и е)],

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 Входные данные для проектирования и разработки

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

Входные данные должны включать в себя:

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

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

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

d) другие требования, важные для проектирования и разработки.

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.3 Выходные данные проектирования и разработки

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

Выходные данные проектирования и разработки должны:

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

7.3.4 Анализ проекта и разработки

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

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

b) выявления любых проблем и внесения предложений по необходимым действиям.

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

[ИСО 9001:2008] [2]

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

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

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

Примечания

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

7.3.5 Верификация проекта и разработки

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

7.3.6 Валидация проекта и разработки

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

[ИСО 9001:2008] [2]

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.3.7 Управление изменениями проекта и разработки

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

[ИСО 9001:2008] [2]

В контексте разработки программных продуктов управление изменениями проекта и разработки обычно рассматривается как элемент управления конфигурацией (см. 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 Закупки

7.4.1 Процесс закупок

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

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

[ИСО 9001:2008] [2]

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].

7.4.2 Информация по закупкам

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

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

b) к квалификации персонала;

c) к системе менеджмента качества.

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

7.4.3 Верификация закупленной продукции

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

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

[ИСО 9001:2008] [2]

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

В случаях, когда разработка программного продукта осуществляется субподрядчиками или же когда производится закупка связанных с разработкой технических и программных средств, организации может понадобиться определить методы, посредством которых будут достигаться задачи, связанные с верификацией, валидацией и приемкой работы, выполняемой субподрядчиками. В случаях, когда программные средства, разрабатываемые субподрядчиками, необходимо интегрировать с программными средствами, разрабатываемыми самой организацией, может также возникнуть необходимость определения методов и инструментальных средств, используемых в процессе разработки. Может возникуть необходимость в проведении инспекционном контроля либо самой организацией или возможно потребителем. Могут быть применимыми общие подходы, касающиеся тестирования (см. 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 Производство и обслуживание

7.5.1 Управление производством и обслуживанием

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

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

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

c) применение подходящего оборудования;

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

e) проведение мониторинга и измерений;

f) осуществление выпуска, поставки и действий после поставки продукции.

[ИСО 9001:2008] [2]

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 Тиражирование

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

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

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].

7.5.2 Валидация процессов производства и обслуживания

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

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

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

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

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

c) применение конкретных методов и процедур;

d) требования к записям (4.2.4);

e) повторную валидацию.

[ИСО 9001:2008] [2]

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

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

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

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

7.5.3 Идентификация и прослеживаемость

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

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

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

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

[ИСО 9001:2008] [2]

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].

7.5.4 Собственность потребителя

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

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

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

7.5.5 Сохранение соответствия продукции

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6 Управление оборудованием для мониторинга и измерений

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

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

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

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

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

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

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

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

8 Измерение, анализ и улучшение

8.1 Общие положения

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

a) демонстрации соответствия требованиям к продукции;

b) обеспечения соответствия системы менеджмента качества;

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

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

[ИСО 9001:2008]

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

Мониторинг, измерение, анализ и улучшение процессов должны быть идентифицированы в качестве элемента деятельности по планированию качества (см. 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].

8.2 Мониторинг и измерение

8.2.1 Удовлетворенность потребителей

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

8.2.2 Внутренние аудиты

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

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

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

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

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

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

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

Примечание - См. ИСО 19011 для руководства.

[ИСО 9001:2008] [2]

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

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

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

8.2.3 Мониторинг и измерение процессов

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

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

[ИСО 9001:2008] [2]

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

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].

8.2.4 Мониторинг и измерение продукции

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

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

Записи должны указывать лицо(а), санкционировавшее(ие) выпуск продукции (4.2.4).

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

8.3 Управление несоответствующей продукцией

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

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

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

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

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

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.4 Анализ данных

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

Анализ данных должен представлять информацию, относящуюся:

a) к удовлетворенности потребителей (8.2.1);

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

c) к характеристикам и тенденциям процессов и продукции, включая возможности проведения предупреждающих действий (8.2.3 и 8.2.4);

d) к поставщикам (7.4).

[ИСО 9001:2008] [2]

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

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

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

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

8.5 Улучшение

8.5.1 Постоянное улучшение

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

[ИСО 9001:2008] [2]

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

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

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

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

8.5.2 Корректирующие действия

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

Должна быть разработана документированная процедура для определения требований:

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

b) к установлению причин несоответствий;

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

d) к определению и осуществлению необходимых действий;

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

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

[ИСО 9001:2008] [2]

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

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

8.5.3 Предупреждающие действия

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

Должна быть разработана документированная процедура для определения требований:

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

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

c) к определению и осуществлению необходимых действий;

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

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

[ИСО 9001:2008] [2]

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

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

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

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

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


Краткие руководящие указания по применению ИСО 9001:2008, имеющиеся в стандартах ИСО/МЭК JTC 1/SC 7 и ИСО/ТК 176

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

Таблица А.1 Краткие руководящие указания по применению ИСО 9001:2008 [2], имеющиеся в стандартах ИСО/МЭК JTC 1/SC 7 и ИСО/ТК 176

ISO 9001:2008

ИСО/МЭК 12207:2008

Другие документы

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

Общие

24748-1 [23], 24748-3 [24]

4.2 Требования к документации

6.3.6, 7.2.1

5.4.1 Цели в области качества

15504 [12], [13], [14], [15], [16], 25010 [26]

6.2.1 Общие положения

6.2.4

6.3 Инфраструктура

6.2.2

25001 [25], 25040 [27],
25041 [28], 14102 [8]

7.1 Планирование процессов жизненного цикла продукции

6.1.2.3.4.5, 7.1.1.3.1.4, 7.2.3.3.1.3

16326 [19], 25001 [25], 25010 [26]

7.2.1 Определение требований, относящихся к продукции

6.4.2, 7.1.2

15026-3 [11], 25010 [26],
25051 [29]

7.2.2 Анализ требований, относящихся к продукции

6.1.2, 7.2.4.3.2, 7.2.6, 6.3.4

16085 [18], 29148 [31],
25010 [26]

7.2.3 Связь с потребителями

7.2.6, 6.1.2, 6.4.9.3.4

14764 [10]

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

6.1.2.3.4.5, 7.1.1.3.1.4, 7.2.3.3.1.3

7.3.1.4 Интерфейсы

6.3.1

16326 [19]

7.3.2 Входные данные для проектирования и разработки

25010 [26]

7.3.3 Выходные данные проектирования и разработки

7.1.3, 7.1.5

7.3.4 Анализ проекта и разработки

7.1.2.3.1.2, 7.1.3.3.1.6, 7.1.4.3.1.7, 7.2.6

7.3.5 Верификация проекта и разработки

6.4, 7.2.4

7.3.6 Валидация проекта и разработки

6.4, 7.2.5

25010 [26]

7.3.7 Управление изменениями проекта и разработки

5.5.2, 5.5.3, 6.1, 6.2, F.2.1, F.2.2

14759 [9], 19761 [20], 20926 [21], 20968 [22], 25051 [29], 26514 [30]

7.4.1 Процесс закупок

6.1.1

15504-3 [14]

7.4.2 Информация по закупкам

6.1.1.3

7.4.3 Верификация закупленной продукции

6.1.1.3.6

19761 [20], 20926 [21],
20968 [22], 25010 [26],
25040 [27], 25041 [28]

7.5.1 Управление производством и обслуживанием

6.4.7, 6.4.9.3.4, 6.4.10, 7.2.3.3.3, 7.2.8

7.5.3 Идентификация и прослеживаемость

6.6.3.5, 7.2.2

10007 [6]

7.5.5 Сохранение соответствия продукции

14764 [10], 25010 [26],
26514 [30]

8.1 Общие положения

6.2.1.3.3

9126-2 [3], 9126-3 [4], 15504-1 [12], 15939 [17], 25001 [25]

8.2.1 Удовлетворенность потребителей

9126-4 [5]

8.2.2 Внутренние аудиты

7.2.3, 7.2.7

8.2.3 Мониторинг и измерение процессов

6.2.1.3.2, 6.2.1.3.3

15504-1 [12], 15504-2 [13], 15939 [17]

8.2.4 Мониторинг и измерение продукции

6.4

25010 [26], 25040 [27], 25041 [28]

8.3 Управление несоответствующей продукцией

6.3.5, 7.2.2, 7.2.8

25051 [29]

8.4 Анализ данных

15939 [17], 19761 [20],
20926 [21], 20968 [22]

8.5.1 Постоянное улучшение

6.2.1.3.3

15504 [12], [13], [14], [15], [16]

8.5.2 Корректирующие действия

7.2.8

8.5.3 Предупреждающие действия

6.2.1.3.2

15504-2 [13]



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


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

ИСО/МЭК 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].

Таблица В.1 -Таблица соответствия между настоящим стандартом и ИСО/МЭК 12207

Настоящий стандарт

ИСО/МЭК 12207:2008

7.1.2 Планирование качества

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

7.1.1.3.1.4 Разработчик должен разрабатывать планы проведения работ в процессе разработки;

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

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

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

с) применяемая система менеджмента качества и/или идентификация конкретных процедур и инструкций, соответствующих применительно к области применения руководства по качеству и любым объявленным исключениям (см. 1.2 ИСО 9001:2008) [2];

Примечание - Специально не рассматривается, поскольку ИСО/МЭК 12207 применяется к уровню проектов. Однако взаимодействие с системой менеджмента качества организации отражено в 6.2.5 (процесс менеджмента качества);

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

Примечание - Отражено в 7.1.1.3.1.3 процесса разработки и в 7.2.1, процесс создания документации, который широко задействован в мероприятиях, связанных с разработкой;

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

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

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

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

Примечание - Отражено в 7.2.6, процесс анализа;

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

6.1.2.3.4.5 g) Обеспечение качества (см. 7.2.3);

6.1.2.3.4.5 h) Верификация (см. 7.2.4) и валидация (см. 7.2.5), включая подходы к взаимоотношению с верифицирующими и аттестующими организациями;

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

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

Примечание - Отражено в 6.3.5, процесс управления конфигурацией, 7.2.2, процесс менеджмента конфигурации программных продуктов и сделана ссылка в 7.1.1.3.1.2 b) по применению;

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

Примечание - Мониторинг является частью 6.1.2.3.4.8 в процессе поставок и измерение является частью обеспечения соответствия продукции и процессов в 7.2.3.3.3.5;

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

Примечание - В случаях, когда выходные данные процессов являются документами, это охватывается в 7.2.1.3.2.3 в процессе создания документации;

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

6.1.2.3.4.5 о) Обучение персонала (см. 6.2.4);

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

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

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

Примечание - Отражено в 6.1.1.3.4.3 в качестве механизма управления изменениями между заказчиком и поставщиком.

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

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

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

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

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

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

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

6.1.2.3.4.5 о) Обучение персонала (см. 6.2.4);

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

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

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

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

Примечание - Этот термин из ИСО 9001:2008 [2] не используется в ИСО/МЭК 12207. Он эквивалентен всем действиям на стадии выпуска, поставки и после поставки, включая инсталляцию программного средства (см. 6.4.7), обеспечение приемки программных средств (см. 6.4.8), а также включая процессы эксплуатации (см. 6.4.9) и сопровождения (см. 6.4.10), также как и управление конфигурацией (см. 6.3.5 и 7.2.2). Это специальные требования подпунктов ИСО/МЭК 12207:2008 [7], а не деятельность по планированию;

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

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

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

6.1.2.3.4.5 i) Взаимоотношения с заказчиком, которые реализуются такими средствами, как совместные анализы (см. 7.2.6), аудиторские проверки (см. 7.2.7), неформальные совещания, предоставление отчетов, модификация и изменение, реализация, утверждение, приемка и доступ к рабочим объектам.

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

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

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

Примечание - Проблемы охватываются процессом по разрешению проблем (см. 7.2.8);

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

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

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

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

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

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

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

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

6.1.2.3.4.5 n) Средства для планирования, надзора и отчетности;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1.2.3.4.5 g) Обеспечение качества (см. 6.3);

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

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

Примечание - ИСО 9001:2008 [2] не требует процедур по анализу контрактов, но содержит в 7.2.2 а) требование, касающееся проведения анализа требований перед подписанием контракта.

7.2.3.3.1.3 с) Процедуры проведения анализов качества при выполнении договора и координации этих работ.

7.3.4 Анализ проекта и разработки

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

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

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

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

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

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

Также см. 7.2.6.3.1.3 согласно приведенному выше;

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

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

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

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

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

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

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

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

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

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

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

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

7.2.6.3.1.3 (окончание) ... и итоговые критерии при проведении анализа;

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

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

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

7.2.6.3.2 Анализы управления проектом;

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

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

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

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

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

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

7.2.6.3.3 Технические анализы. Это включает в себя следующие задачи:

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

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

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

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

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

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

Примечание - Это следует из Дополнения 1;


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


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


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

Таблица ДА.1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального, межгосударственного стандарта

ISO 9000:2005

IDT

ГОСТ ISO 9000-2011 "Системы менеджмента качества. Основные положения и словарь"

ISO 9001:2008

IDT

ГОСТ ISO 9001-2011 "Системы менеджмента качества. Требования"

ISO/IEC 12207:2008

IDT

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

ISO/IEC 15504-1:2004

IDT

ГОСТ Р ИСО/МЭК 15504-1-2009 "Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь"

ISO/IEC 15504-3:2004

IDT

ГОСТ Р ИСО/МЭК 15504-3-2009 "Информационная технология. Оценка процесса. Часть 3. Руководство по проведению оценки"

ISO/IEC 15026

IDT

ГОСТ Р ИСО/МЭК 15026-2002 "Информационная технология. Уровни целостности систем и программных средств"

ISO/IEC 14764

IDT

ГОСТ Р ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств"

ISO/IEC 16085:2006

IDT

ГОСТ Р ИСО/МЭК 16085-2007 "Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения"

ISO/IEC 25001:2007

-

*

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

ISO/IEC 25010:2011

IDT

ГОСТ Р ИСО/МЭК 25010-2015 "Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем программного обеспечения (SQuaRE). Модели качества систем и программных продуктов"

ISO/IEC 25040:2011

IDT

ГОСТ Р ИСО/МЭК 25040-2014 "Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем программного обеспечения (SQuaRE). Процесс оценки"

ISO/IEC 25041:2012

IDT

ГОСТ Р ИСО/МЭК 25041-2014 "Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретателей и независимых оценщиков"

ISO/IEC 25051:2006

IDT

ГОСТ Р ИСО/МЭК 25051-2017 "Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию"

ISO/IEC 26514:2008

-

*

ISO/IEC 29148:2011

-

*

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

Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

- IDT - идентичные стандарты.

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

[1]

ISO 9000:2005

Quality management systems - Fundamentals and vocabulary

[2]

ISO 9001:2008

Quality management systems - Requirements

[3]

ISO/IEC/TR 9126-2:2003

Software engineering - Product quality - Part 2: External metrics

[4]

ISO/IEC/TR 9126-3:2003

Software engineering - Product quality - Part 3: Internal metrics

[5]

ISO/IEC/TR 9126-4:2004

Software engineering - Product quality - Part 4: Quality in use metrics

[6]

ISO 10007:2003

Quality management systems - Guidelines for configuration management

[7]

ISO/IEC/IEEE 12207:2008

Systems and software engineering - Software life cycle processes

[8]

ISO/IEC 14102:2008

Information technology - Guideline for the evaluation and selection of CASE tools

[9]

ISO/IEC/TR 14759:1999

Software engineering - Mock up and prototype - A categorization of software mock up and prototype models and their use

[10]

ISO/IEC/IEEE 14764

Software Engineering - Software Life Cycle Processes - Maintenance, 2006

[11]

ISO/IEC 15026-3:2011

Systems and software engineering - Systems and software assurance - Part 3: System integrity levels

[12]

ISO/IEC 15504-1:2004

Information technology - Process assessment - Part 1: Concepts and vocabulary

[13]

ISO/IEC 15504-2:2003

Information technology - Process assessment - Part 2: Performing an assessment

[14]

ISO/IEC 15504-3:2004

Information technology - Process assessment - Part 3: Guidance on performing an assessment

[15]

ISO/IEC 15504-4:2004

Information technology - Process assessment - Part 4: Guidance on use for process improvement and process capability determination

[16]

ISO/IEC 15504-5:2012

Information technology - Process assessment - Part 5: An exemplar software life cycle process assessment model

[17]

ISO/IEC 15939:2007

Systems and software engineering - Measurement process

[18]

ISO/IEC/IEEE 16085

Systems and software engineering - Life cycle processes - Risk Man age, 2006

[19]

ISO/IEC/IEEE 16326:2009

Systems and software engineering - Life cycle processes - Project management

[20]

ISO/IEC 19761:2011

Software engineering - COSMIC: a functional size measurement method

[21]

ISO/IEC 20926:2009

Software and systems engineering - Software measurement - IFPUG functional size measurement method 2009

[22]

ISO/IEC 20968:2002

Software engineering - Mk II Function Point Analysis - Counting Practices Manual

[23]

ISO/IЕС/TR 24748-1:2010

Systems and software engineering - Life cycle management - Part 1: Guide for life cycle management

[24]

ISO/IEC/TR 24748-3:2011

Systems and software engineering - Life cycle management - Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes)

[25]

ISO/IEC 25001:2007

Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Planning and management

[26]

ISO/IEC 25010:2011

Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models

[27]

ISO/IEC 25040:2011

Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation process

[28]

ISO/IEC 25041:2012

Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation guide for developers, acquirers and independent evaluators

[29]

ISO/IEC 25051:2006

Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off-

The-Shelf (COTS) software product and instructions for testing

[30]

ISO/IEC 26514:2008

Systems and software engineering - Requirements for designers and developers of user documentation

[31]

ISO/IEC/IEEE 29148

Systems and software engineering - Life cycle processes - Requirements Eng. 2011

УДК 658.562.014:006.354

ОКС 03.120.10

Ключевые слова: программные продукты, система менеджмента качества, конфигурации

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

и сверен по:

М., , 2020