СТАНДАРТЫ В ОБЛАСТИ
АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ
КАЧЕСТВОМ И ОБЕСПЕЧЕНИЯ КАЧЕСТВА.

ПРЕДИСЛОВИЕ

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

ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК) по вопросам стандартизации в электротехнике.

Проекты международных стандартов, принятые техническими комитетами, рассылаются комитетам-членам для одобрения до утверждения их Советом ИСО в качестве международных стандартов. Для опубликования их в качестве международных стандартов требуется не менее 75 % голосов комитетов-членов, принявших участие в голосовании.

Международный стандарт ИСО 9000-3 подготовлен техническим комитетом ИСО/ТК 176 «Административное управление качеством и обеспечение качества».

Стандарт ИСО 9000 состоит из следующих частей (под общим заголовком «Стандарты в области административного управления качеством и обеспечения качества):

Часть 2: «Руководящие Указания по применению стандартов ИСО 9001, ИСО 9002 и ИСО 9003».

Часть 3: «Руководящие Указания по применению стандарта ИСО 9001 при разработке, поставке и обслуживании программного обеспечения».

Часть 1 должна заменить стандарт ИСО 9000:87.

Часть 2 должна быть опубликована.

Приложения А и В данной части стандарта ИСО 9000 приведены только для информации.

ВВЕДЕНИЕ

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

Требования к общей системе качества при двусторонней контрактной системе уже опубликованы в стандарте ИСО 9001-87 «Системы качества. Модель для обеспечения качества при проектировании и/или разработке, производстве, монтаже и обслуживании».

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

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

Контракты между двумя сторонами на разработку продукции программного обеспечения могут быть самыми разнообразными. Для некоторых двусторонних контрактов данный документ нельзя применять даже в «приспособленном» варианте. Поэтому очень важно установить адекватность применения данной части стандарта ИСО 9000 для конкретного контракта.

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

Примечания.

1. На английском языке использование мужского рода в этой части стандарта ИСО 9000 не исключает женского рода применительно к одушевленным лицам. Точно так же использование единственного числа не исключает множественного (и наоборот) там, где это диктуется смыслом.

2. Текст пунктов данной части стандарта, приведенный также в стандарте ИСО 9001, дается курсивом, если нет других указаний.

3. В данной части стандарта ИСО 9000 имеется ряд перечней. Ни один из них не является исчерпывающим; все приведены в качестве примеров.

СТАНДАРТЫ В ОБЛАСТИ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ
КАЧЕСТВОМ И ОБЕСПЕЧЕНИЯ КАЧЕСТВА

Часть 3: Руководящие указания по применению стандарта ИСО
9001 при разработке, поставке и обслуживании программного
обеспечения

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

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

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

Положения данной части стандарта ИСО 9000 применимы к контрактам на продукцию программного обеспечения, если:

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

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

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

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

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

ИСО 2382-1-64       Обработка данных. Словарь. Часть 01. Основные термины.

ИСО 8402-86          Качество. Словарь.

ИСО 9001-87          Системы качества. Модель для обеспечения качества при проектировании и/или разработке, производстве, монтаже и обслуживании.

ИСО 10011-1-90     Руководящие указания по проверке систем качества. Часть 1. Проверка

3 Определения

В настоящей части стандарта ИСО 9000 применяются определения, данные в стандарте ИСО 2362-1 и ИСО 8402, вместе со следующими определениями.

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

[ИСО 2382-1-84, 01.04.04]

Примечание 4. Программное обеспечение не зависит от носителя, на котором оно записано.

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

3.3 Элемент программного обеспечения - какая-либо идентифицируемая часть продукции программного обеспечения на промежуточном или конечном этапе разработки.

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

3.5 Фаза - определенная часть работы.

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

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

3.7 Аттестация (для программного обеспечения) - процесс оценки программного обеспечения в целях обеспечения соответствия установленным требованиям.

4 Система качества - структура

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

4.1.1 Ответственность руководства со стороны поставщика

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

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

[ИСО 9001-87, 4.1.1]

4.1.1.2 Организация

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

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

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

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

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

d) проверки выполнения решений;

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

[ИСО 9001-87, 4.1.2.1]

4.1.1.2.2 Средства проверки и персонал

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

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

[ИСО 9001-87, 4.1.2.2.]

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

Поставщик должен назначить представителя руководства, который независимо от других обязанностей должен иметь определенные полномочия и нести ответственность за выполнение и соблюдение требований стандарта [ИСО 9001]

[ИСО 9001-67, 4.1.2.3]

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

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

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

[ИСО 9001-87, 4.1.3]

4.1.2 Ответственность руководства со стороны покупателя

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

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

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

b) отвечать на вопросы поставщика;

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

d) заключать соглашения с поставщиком;

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

f)  определять критерии процедуры и приемки;

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

4.1.3 Совместный анализ

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

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

b) результаты контроля;

с) результаты приемочных испытаний.

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

4.2 Система качества

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

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

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

4.2.2 Документация системы качества

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

4.2.3 План качества

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

4.3 Внутренние проверки системы качества

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

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

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

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

[ИСО 9001-87, 4.17]

См. ИСО 10011-l

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

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

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

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

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

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

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

[ИСО 9001-87, 4.14]

5 Система качества - жизненный цикл

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

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

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

5.2 Анализ контракта

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

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

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

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

b) вероятные случайности или риск идентифицированы;

с) информация, являющаяся собственностью фирмы, достаточно защищена;

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

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

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

g) терминология согласована обеими сторонами;

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

Записи о результатах таких анализов контракта должны быть обеспечены.

5.2.2 Пункты контракта, касающиеся качества

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

а) критерии приемки;

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

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

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

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

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

g) требования, связанные с тиражированием (см. п. 5.9).

5.3 Техническое задание покупателя

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

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

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

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

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

5.3.2 Взаимное сотрудничество

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

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

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

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

d) запись и изучение результатов дискуссий обоими сторонами.

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

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

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

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

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

с) фазы разработки (по определению п. 5.4.2.1);

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

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

- план качества;

- план управления конфигурацией;

- план комплектации;

- план проведения испытаний.

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

План должен быть рассмотрен и утвержден до его реализации.

5.4.2 План разработки

5.4.2.1 Фазы

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

а) фаз разработки, которые должны быть выполнены;

b) необходимых затрат для каждой фазы;

с) требуемых результатов по каждой фазе;

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

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

5.4.2.2 Управление

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

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

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

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

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

5.4.2.3 Методы и средства разработки

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

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

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

с) управление конфигурацией.

5.4.3 Контроль за ходом выполнения работ

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

5.4.4 Затраты на реализации фаз разработки

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

5.4.5 Результаты выполнения фаз разработки

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

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

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

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

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

е) соответствовать действующим нормативным требованиям.

5.4.6 Проверка каждой фазы

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

а) осуществление анализов через установленные интервалы в ходе фаз разработки;

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

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

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

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

5.5 Планирование уровня качества

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

Поставщик должен подготовить план качества как часть работ по планированию разработки.

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

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

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

5.5.2 Содержание плана качества

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

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

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

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

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

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

- анализы и испытания;

- управление конфигурацией и контроль за изменениями;

- контроль дефектов и корректирующие воздействия.

5.6 Проектирование и реализация

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

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

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

5.6.2 Проектирование

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

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

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

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

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

5.6.3 Реализация

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

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

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

5.6.4 Анализ

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

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

5.7 Испытание и оценка качества

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

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

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

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

5.7.2 Планирование испытаний

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

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

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

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

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

d) критерии, по которым можно судить об окончании испытаний;

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

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

5.7.3 Испытания

Особое внимание необходимо обратить на следующие стороны испытаний:

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

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

с) области, которые подверглись какой-либо модификации, должны быть идентифицированы и повторно испытаны;

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

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

5.7.4 Оценка

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

5.7.5 Полевые испытания

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

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

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

с) восстановление операционной среды (после испытания).

5.8 Приемка

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

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

5.8.2 Планирование приемочных испытаний

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

а) временного графика работ;

b) методик оценки;

с) программной/аппаратной сред и ресурсов;

d) критерия приемки.

5.9 Тиражирование, поставка и монтаж

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

Тиражирование является этапом, предшествующим поставке.

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

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

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

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

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

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

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

5.9.2 Поставка

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

5.9.3 Монтаж

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

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

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

с) наличие обученного персонала;

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

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

f) формальную процедуру принятия монтажа после его завершения.

5.10 Обслуживание

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

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

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

а) решение проблем;

b) модификация интерфейса;

с) расширение функций или улучшение эксплуатационных характеристик.

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

а) программа(ы);

b) данные и их структура;

с) спецификация;

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

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

5.10.2 План технического обслуживания

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

а) область технического обслуживания;

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

с) организацию(и) обслуживания;

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

е) протоколы и отчеты по техническому обслуживанию.

5.10.3 Идентификация первоначального статуса продукции

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

5.10.4 Обеспечивающая организация

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

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

5.10.5 Виды деятельности по техническому обслуживанию

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

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

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

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

5.10.6 Протоколы и отчеты по техническому обслуживанию

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

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

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

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

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

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

d) результаты корректирующих действий;

е) статистические данные о случаях отказов и действиях, связанных с техническим обслуживанием.

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

5.10.7 Процедуры выпуска

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

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

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

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

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

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

6 Система качества - вспомогательные виды деятельности (не зависящие от фазы)

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

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

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

Система управления, конфигурацией должна:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

с) все интерфейсы с другими элементами программного обеспечения и с аппаратными средствами;

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

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

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

6.1.3.2 Контроль за изменениями

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

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

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

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

6.1.3.3 Отчет о статусе конфигурации

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

6.2 Контроль за документацией

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

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

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

b) утверждение и опубликование;

с) изменение, включая отмену и, если нужно, выпуск.

6.2.2 Типы документов

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

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

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

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

- информацию на входе в фазу разработки;

- ожидаемые результаты в конце фазы разработки;

- планы и результаты проверок и оценок;

- документацию для покупателя и пользователя;

- эксплуатационную документацию.

6.2.3 Утверждение и выпуск документов

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

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

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

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

6.2.4 Изменения в документах

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

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

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

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

[ИСО 9001:1987, 4.5.2]

6.3 Карточки учета показателей качества

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

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

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

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

[ИСО 9001:1967, 4.16]

6.4 Измерение

6.4.1 Измерение продукции

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

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

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

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

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

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

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

6.4.2 Измерение процесса

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

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

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

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

6.5 Правила, практические методы и накопленный опыт

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

Поставщик должен анализировать эти правила, методы и накопленный опыт и пересматривать их по мере необходимости.

6.6 Средства и технические приемы

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

6.7 Закупки

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

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

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

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

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

6.7.2 Оценка субподрядчиков

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

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

Подрядчик должен гарантировать эффективность мер по контролю за системой качества.

[ИСО 9001:87, 4.6.2]

6.7.3 Оценка закупленной продукции

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

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

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

6.8 Включенная продукция программного обеспечения

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

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

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

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

6.9 Подготовка кадров

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

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

Приложение А

(информативное)

Перекрестные ссылки между ИСО 9000-3 и ИСО 9001

Приложение В

(информативное)

Перекрестные ссылки между ИСО 9000-1 и ИСО 9000-3

СОДЕРЖАНИЕ