МЕЖДУНАРОДНЫЙ СТАНДАРТ | ИСО 9000-3 |
Первое издание
1991-06-01
СТАНДАРТЫВ ОБЛАСТИ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ КАЧЕСТВОМ И ОБЕСПЕЧЕНИЯКАЧЕСТВА.
Часть 3. Руководящие указанияпо применению стандарта ИСО 9001 при разработке, поставке иобслуживании программного обеспечения
Номер ссылки
ИСО 9000-3-91
ПРЕДИСЛОВИЕ
Международная организация постандартизации (ИСО) является всемирной федерацией национальныхорганизаций по стандартизации (комитетов-членов ИСО). Разработкумеждународных стандартов осуществляют технические комитеты ИСО.Каждый комитет-член, заинтересованный в предмете, рассмотрениемкоторого занимается технический комитет, имеет право бытьпредставленным в этом комитете. Правительственные инеправительственные международные организации, связанные с ИСО, такжепринимают участие в этой работе.
ИСО тесно сотрудничает сМеждународной электротехнической комиссией (МЭК) по вопросамстандартизации в электротехнике.
Проекты международныхстандартов, принятые техническими комитетами, рассылаютсякомитетам-членам для одобрения до утверждения их Советом ИСО вкачестве международных стандартов. Для опубликования их в качествемеждународных стандартов требуется не менее 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 имеется ряд перечней. Ни один изних не является исчерпывающим; все приведены в качестве примеров.
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 Тиражирование