Документ входные данные проектирования изделия. Процессы жизненного цикла продукции
7.3.1 Планирование проектирования и разработки
Руководство ТюмГУ планирует и управляет проектированием и разработкой в соответствии с процедурами «Подготовка учебного процесса» ОП 01.02, «Обеспечение учебно-методическим обеспечением» ПП 01.03.
При оценке потенциала рассматриваются составляющие системы образования, имеющие количественную характеристику:
Кадровый состав;
Материально-техническая база;
Информационная база;
Научно-методическое обеспечение;
Финансовые ресурсы;
Управление системой и ее отдельными элементами.
В ТюмГУ обычно осуществляется проектирование и разработка следующих документов:
4. Учет стратегического и среднесрочного плана развития ТюмГУ.
Разработка новых циклов дисциплин и корректировка действующих обеспечивается выполнением следующих задач:
1. Проектирование курса. Определение результатов обучения.
2. Самоанализ ППС и построение собственной системы педагогической деятельности.
3. Аттестация и технология самообследования университета.
Планирование проектирования и разработки осуществляется на основе календарного плана , содержащегося в Системе программных мероприятий на учебный год. График работ разбивается на этапы проведения работ, каждый из которых детализируется на отдельные задачи.
В графике работ устанавливаются стадии проверки, доработки и согласования документации, этапы верификации и валидации, разделение ответственности и полномочий в области проектирования и разработки между участниками работ.
Руководитель конкретной работы анализирует техническое задание и определяет состав исполнителей по проектированию и разработке (в т. ч. с привлечением сторонних специалистов).
Разработка и проектирование выполняется ТюмГУ самостоятельно или с привлечением сторонних организаций и/или специалистов.
Процедура мониторинга качества научной и учебно-методической литературы складывается из анализа результатов деятельности следующих структурных подразделений:
ЦИТ – организация и поддержка электронной среды университета;
ИБЦ – использование (комплектование, выдача) учебно-методической и научной литературы ;
Издательство – издание учебно-методической и научной литературы;
Факультеты и кафедры – создание и подготовка к опубликованию научной и учебно-методической литературы.
Технические задания для соисполнителей разрабатываются ответственным исполнителем с участием, при необходимости, привлекаемых организаций и/или специалистов. Содержание технического задания определяется ТюмГУ. Техническое задание утверждает ректор.
Договор (контракт) с соисполнителем согласовывают следующие лица (в порядке получения виз):
· Соисполнитель;
· Руководитель структурного подразделения;
· Представитель руководства по качеству;
· Ректор и/или проректор.
Входные данные, относящиеся к требованиям учебного процесса в ТюмГУ, включают:
1. Требования к учебно-организационной документации;
2. Требования к информационному и учебно-методическому обеспечению;
3. Требования к ППС, административно-управленческому и учебно-вспомогательному персоналу;
4. Требования к материально-техническому оснащению;
5. Требования к уровню подготовки абитуриентов;
6. Информацию из стратегического и среднесрочного плана развития ТюмГУ.
7.3.3 Выходные данные проектирования и разработки
Выходными данными по проектированию и разработке являются:
Образовательные программы;
Учебно-методические пособия;
Словари.
Для всякого проектирования и разработки выходные данные должны:
· соответствовать входным требованиям к проектированию и разработке;
· обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
· определять характеристики результатов проектирования и разработки, существенные для безопасного и правильного их использования.
Комплектность документации по проектированию и разработке определяется техническим заданием. Как правило, комплект документов включает в себя версию на бумажном носителе и электронную версию на CD-ROM.
Ответственным за подготовку документов является ответственный исполнитель.
Копии разработанной документации по проектированию и разработке и их электронные версии хранятся у ответственного исполнителя с последующей передачей в архив.
Учет документации ведет ответственный исполнитель в соответствии с перечнем документации, оговоренным в графике работ. Записи, фиксирующие учет разработанной документации, отражаются в периодических отчетах о проделанной работе.
Выходные данные организационно-методической работы:
§ подготовленные методические разработки,
§ составленные учебно-методические комплексы дисциплин,
§ система расчетов учебной нагрузки,
§ расписание экзаменов,
§ организация системы делопроизводства,
§ составление планов кафедр,
§ подготовка кафедры к самоаттестации и аккредитации.
7.3.4 Анализ проекта и разработки
В процессе проектирования и разработки осуществляется систематический анализ для установления соответствия требований к результатам проектирования и разработки, то есть анализируется качество разработки (п. п. 3.1.1, 3.8.7 ГОСТ Р ИСО 9000 – 2001).
В ТюмГУ используется многоуровневая система анализа качества проектирования и разработки, которая предусматривает выполнение анализа на соответствующих стадиях проектирования и разработки в соответствии с запланированными мероприятиями. Система анализа включает следующие последовательные процедуры:
· внутренний анализ, осуществляемый ТюмГУ в процессе подготовки предварительной и окончательной версий документов проектирования и разработки;
· внутренний анализ, осуществляемый ТюмГУ в процессе доработки (корректировки) документации по замечаниям и/или предложениям Потребителя;
· внешний анализ органами госэкспертизы (при необходимости);
· внешний анализ, осуществляемый Потребителем.
Система анализа проектирования и разработки действует в отношении предварительной и окончательной версий документации. Система сдачи-приемки включает мероприятия по анализу проектирования и разработки на различных уровнях.
Число уровней анализа зависит от условий проектирования и разработки и может варьироваться.
I уровень анализа
Ответственный исполнитель осуществляет анализ и приемку работ по проектированию и разработке в соответствии с техническим заданием от штатных сотрудников ТюмГУ.
В случае наличия замечаний у ответственного исполнителя по представленной документации штатные сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа и приемки работ является подпись ответственного исполнителя.
II уровень анализа
Ответственный исполнитель работ по договору (контракту) совместно со штатными сотрудниками ТюмГУ осуществляют анализ документации и приемку работ в соответствии с техническим заданием от субподрядных организаций.
Подтверждением проведенного анализа является визирование ответственным исполнителем работ по договору (контракту) акта сдачи-приемки работ от субподрядных организаций.
III уровень анализа
Ответственный исполнитель работ в соответствии с условиями технического задания осуществляет анализ и приемку работ по отдельным разделам документации от привлекаемых специалистов.
В случае наличия замечаний у ответственного исполнителя по представленной документации привлеченные сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа является визирование ответственным исполнителем акта сдачи-приемки работ от субподрядных организаций.
IV уровень анализа
Анализ с привлечением сторонних организаций и/или специалистов. Решение о привлечении для анализа сторонних организаций и/или специалистов принимает Представитель руководства по качеству.
Подтверждением проведенного анализа является визирование ответственным исполнителем работ по договору (контракту) акта сдачи-приемки работ с привлеченными для анализа сторонними организациями и/или специалистами.
V уровень анализа
Анализ со стороны Потребителя.
В случае наличия замечаний при таком анализе по представленной документации сотрудники дорабатывают документацию в рабочем порядке.
Подтверждением проведенного анализа является подпись акта сдачи-приемки работ со стороны Потребителя.
Материалы по анализу проекта и разработки хранятся в подразделении-разработчике и/или у ответственного исполнителя работ в течение 3-х лет.
7.3.5 Верификация проекта и разработки
Верификация осуществляется в соответствии с запланированными мероприятиями, чтобы удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям. Деятельность по подтверждению выполнения установленных требований осуществляется в соответствии с запланированными мероприятиями (п. 7.3.1). Предусмотрены следующие этапы верификации для различных вариантов проектирования и разработки:
Ответственным исполнителем;
Специально назначенным сотрудником;
При нормоконтроле.
Отметкой о проведении верификации является подпись соответствующего исполнителя в предусмотренных для этого местах (на разрабатываемых документах, в акте и др.). Записи результатов верификации и всех необходимых действий поддерживаются в рабочем состоянии.
7.3.6 Валидация проекта и разработки
Деятельность по валидации осуществляется в соответствии с запланированными мероприятиями (п. 7.3.1). Предусмотрены следующие этапы валидации для различных вариантов проектирования и разработки:
Заведующим кафедрой;
Деканом или начальником института;
Проректором;
Представителем руководства по качеству;
Ректором.
Отметкой о проведении валидации является подпись соответствующего исполнителя в предусмотренном для этого местах (на разрабатываемых документах, в акте и др.).
В предусмотренных случаях валидация осуществляется Потребителем и/или сторонними организациями.
7.3.7 Управление изменениями проекта и разработки
Изменения разработанной документации могут происходить:
· при обнаружении ошибок;
· при совершенствовании разработанной документации;
· при изменении требований Потребителей.
Изменения разработанной документации могут осуществляться на любой стадии выполнения работ.
Тексты изменений разрабатывает инициатор изменения в соответствии с принятым порядком разработки и утверждения. Внесение изменений в разработанную документацию осуществляется специалистами, выполняющими или выполнившими соответствующую работу, под контролем ответственного специалиста (форма извещения об изменении приведена в приложении к процедуре 01.04.02/ПП 01.04 «Управление документацией и записями»).
Изменения, вносимые в разработанную документацию, анализируются с точки зрения их влияния на другую разработанную документацию по проекту, верифицируются, подвергаются валидации и согласованию в том же порядке, что и разрабатываемая документация (п. п. 7.3.3 – 7.3.6 Руководства по качеству).
Изъятая документация хранится в течение 3-х лет.
"ГОСТ Р 57189-2016/ISO/TS 9002:2016. Национальный стандарт Российской Федерации. Системы менеджмента качества. Руководство по применению ИСО 9001:2015 (ISO/TS 9002:2016, IDT)" (утв. Приказом Росстандарта от 25.10.2016 N 1499-ст)
8.3.3 Входные данные для проектирования и разработки
Определение входных данных для конкретного проекта проектирования и разработки является одним из видов деятельности, которая должна быть включена в план проектирования и разработки. Эти входные данные должны быть однозначными, полными и согласующимися с требованиями, которые определяют характеристики продукции или услуги. Они должны включать:
a) функциональные и эксплуатационные требования, определенные потребителями, потребностями рынка или организацией;
b) информацию из предыдущей аналогичной деятельности по проектированию и разработке (которая может улучшить результативность и позволить организации развивать хорошие практики или избегать ошибок);
c) законодательные и нормативные правовые требования, которые относятся непосредственно к продукции или услуге (например, правила техники безопасности, законы о пищевой гигиене) или к производству этой продукции или услуги (например, практики в рамках процесса производства, транспортировка или другие техники поставки);
d) добровольные стандарты или практические правила, которые организация приняла (например, отраслевые кодексы, санитарные нормы и нормы безопасности);
e) потенциальные последствия неудач в связи с характером продукции и услуг; такие неудачи могут находиться в диапазоне от потенциально фатальных (например, плохое планирование безопасности дорожного движения при случае может приводить к авариям) до факторов, которые приводят к потере удовлетворенности потребителей (например, нестойкие чернила на ткани ведут к потере цвета или окрашиванию).
Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (4.2.4). Входные данные должны включать в себя:
a) функциональные и эксплуатационные требования;
b) соответствующие законодательные и другие обязательные требования;
c) там, где это возможно, информацию, взятую из предыдущих аналогичных проектов;
d) другие требования, важные для проектирования и разработки.
Входные данные должны анализироваться на достаточность. Требования должны быть полными, недвусмысленными и непротиворечивыми.
Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, подходящей для проведения верификации относительно входных требований к проектированию и разработке, а также должны быть официально одобрены до их последующего использования.
Выходные данные проектирования и разработки должны:
a) соответствовать входным требованиям к проектированию и разработке;
b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
d) определять характеристики продукции, существенные для ее безопасного и правильного использования.
Примечание - Информация по производству и обслуживанию может включать в себя подробные данные о сохранении продукции.
Анализ проекта и разработки
На соответствующих стадиях должен проводиться систематический анализ проекта и разработки в соответствии с запланированными мероприятиями (7.3.1) в целях:
a) оценивания способности результатов проектирования и разработки удовлетворять требованиям;
b) выявления любых проблем и внесения предложений по необходимым действиям.
В состав участников такого анализа должны включаться представители подразделений, имеющих отношение к анализируемой(ым) стадии(ям) проектирования и разработки. Записи результатов анализа и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Верификация проекта и разработки
Верификация должна осуществляться в соответствии с запланированными мероприятиями (7.3.1) с целью удостовериться, что выходные данные проектирования и разработки соответствуют входным требованиям. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Валидация проекта и разработки
Валидация проекта и разработки должна осуществляться в соответствии с запланированными мероприятиями (7.3.1) с целью удостовериться, что полученная в результате продукция соответствует требованиям к установленному или предполагаемому использованию, если оно известно. Где это практически возможно, валидация должна быть завершена до поставки или применения продукции. Записи результатов валидации и всех необходимых действий должны поддерживаться в рабочем состоянии (4.2.4).
Входные данные для проектирования и разработки
Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (4.2.4). Эти данные должны включать:
a) функциональные и эксплуатационные требования;
b) соответствующие законодательные и обязательные требования;
c) там, где это целесообразно, информацию, взятую из предыдущих аналогичных проектов;
d) другие требования, важные для проектирования и разработки. Эти входные данные должны анализироваться на адекватность. Требования должны быть полными, недвусмысленными и непротиворечивыми.
Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, позволяющей провести верификацию относительно входных требований к проектированию и разработке, а также должны быть утверждены до их выпуска.
Выходные данные проектирования и разработки должны:
a) отвечать входным требованиям к проектированию и разработке;
b) обеспечивать соответствующей информацией по закупкам, производству и обслуживанию;
d) определять характеристики продукции, существенные для ее безопасного и правильного использования.
История работ в области качества в России.
Говоря о передовом опыте в области управления качеством, нельзя не вспомнить об отечественной практике совершенствования качества.
Какие концепции повышения качества существовали в нашей стране?
1. Концепция БИП (Бездефектного Изготовления Продукции) В основу этой системы был положен механизм активизации участников производственного процесса, стимулирующий их к выявлению и устранению не дефектов продукции, а их причин. После повторного предъявления продукции рабочий лишался премии.
2. Концепция КАНАРСПИ (Качество, Надежность, Ресурс с Первых Изделий) Была внедрена на Горьковском авиационном заводе. Признанная лучшей в стране, система базировалась на следующих принципах:
· универсальность (возможность использования в других отраслях промышленности)
· комплексное обеспечение качества продукции
· проведение исследований, направленных на повышение качества продукции и развитие опытно-конструкторских служб предприятия
· организация всестороннего учета качества выпускаемой продукции
· концентрация внимания на качестве продукции на стадии ее разработки
· привлечение к совершенствованию продукции потребителей
1. Концепция НОРМ В середине 1960-х гг. на Ярославском моторном заводе «Автодизель» была внедрена система НОРМ, в которой за критерий качества был принят один из важнейших технических параметров - ресурс до первого капитального ремонта. Особое внимание уделялось разработке конструкции и технологии, обеспечивающих повышение технического уровня и качества двигателя. В системе НОРМ были использованы и развиты основные элементы Саратовской и Горьковской систем управления качеством выпускаемой продукции.
2. Концепция КСУКП (Комплексная система управления качеством продукции)
В первой половине 1970-х гг. в результате совместного научно-производственного эксперимента предприятий Львовской области, ВНИИ стандартизации Госстандарта СССР и научно-производственного объединения «Система» была разработана и прошла апробацию комплексная система управления качеством продукции.
Главная цель системы заключалась в обеспечении высоких и устойчивых темпов роста качества продукции, выпускаемой предприятием, за счет:
· создания и освоения новых высококачественных видов продукции;
· своевременной постановки на производство новой продукции;
· снятия с производства морально устаревшей продукции;
· улучшения показателей качества выпускаемой продукции путем ее совершенствования и модернизации.
В чем заключалась специфика Российского опыта управления качеством?
Специфика управления качеством в России заключалась в том, что эффективные системы управления качеством создавались на предприятиях военно-промышленного комплекса (ВПК). Именно в ВПК были распространены методы обеспечения качества на стадиях исследования и проектирования новой продукции, статистический контроль качества с применением контрольных карт, специальные стандарты. В недрах ВПК родились КСУКП (комплексные системы управления качеством продукции, в том числе автоматизированные).
СМК: Управление несоответствующей продукцией.
Методика управления несоответствующей продукцией.
1) определяем продукцию, включаемую в область применения СМК,2) определяем, что такое соответствующая продукция,3) определяем, какие механизмы управления применимы к какой продукции (можно в виде таблицы),4) подробно описываем эти механизмы в применении к конкретной продукции: кто за что отвечает, какими полномочиями обладает, что делает.
Пока продукция у нас.
Что мы можем сделать для обеспечения соответствия продукции, когда обнаружено несоответствие?
Первое очевидно: исправить. т.е. в терминах ISO 9000 осуществить коррекцию. Но это не всегда возможно.
Тогда второе: оценить, насколько несоответствие препятствует преднамеренному использованию продукции, и, если приемлемо, то разрешить отклонение. Если возможно, то разрешение на отклонение запрашивается еще и у потребителя, согласен ли он. Заказчик, проанализировав, какие именно функции будут отсутствовать, может счесть это вполне приемлемым и дать разрешение.
Если ни первое, ни второе невозможно, то остается третий вариант: изменить первоначальное применение или вообще отказаться от применения продукции.
Очевидно, что процедуру управления несоответствующей продукцией невозможно полноценно разработать, если
не определена сама продукция, качеством которой управляем в рамках СМК,
не определено, что такое соответствующая продукция, ибо это равносильно тому, что не определена несоответствующая продукция.
Из опыта аудирования: если я из руководства по качеству не могу понять, какая конкретно продукция включена в область применения СМК, то я могу даже не смотреть процедуру управления несоответствующей продукцией, заранее гарантируя, что она формальна.
Механизмы управления в каждом из трех случаев:
Изменить продукцию (коррекция)
указать способ идентификации несоответствующей продукции и ответственного за эту идентификацию,
указать ответственного за предотвращение выпуска и поставки идентифицированной несоответствующей продукции и его полномочия,
указать ответственного за коррекцию,
установить процедуру повторного контроля и ответственного за ее выполнение,
установить, в какой форме делается запись о характере несоответствия и решении о коррекции.
Изменить требования
указать уполномоченного на дачу разрешения на отклонение и его полномочия, а также установить процедуру такого разрешения, включая установление лица, уполномоченного потребителем давать разрешение на отклонение,
установить, в какой форме делается запись о характере несоответствия и разрешении на отклонение.
Изменить применение
установить ответственного за предотвращение первоначального применения потребителем несоответствующей продукции и его полномочия, а также процедуру такого предотвращения,
установить, в какой форме делается запись о характере несоответствия и действиях по предотвращению первоначального применения.
Продукция у потребителя.
Очевидно, что в данной ситуации ни один из описанных выше механизмов не применим: продукция вышла из-под нашего контроля. Все, что мы можем в данном случае, это предпринять действия, снижающие негативные последствия или риск таких последствий для потребителя. В качестве примера тут можно привести всем известные компании по отзыву автомобилей.
7.3.1 Общие методические указания
Высшему руководству следует удостовериться, что организация определила, внедрила и поддерживает в рабочем состоянии необходимые процессы проектирования и разработки для результативного и эффективного реагирования на потребности и ожидания своих потребителей и других заинтересованных сторон.
При проектировании и разработке продукции или процессов руководству необходимо обеспечить, чтобы организация не только была способна учитывать свою основную деятельность и свои функции, но и все факторы, содействующие тому, чтобы характеристики продукции и процессов отвечали ожиданиям потребителей и других заинтересованных сторон. Например, организация должна принимать во внимание жизненный цикл продукции, охрану труда, возможность проведения испытаний, пригодность, простоту в использовании, надежность, долговечность, эргономику, внешнюю среду, утилизацию продукции, а также определенные риски.
Руководство также несет ответственность за принятие мер по идентификации и уменьшению потенциального риска для пользователей продукции и процессов организации. Следует проводить оценивание рисков, чтобы оценить возможность их появления и последствия вероятных отказов или недостатков продукции или процессов. Результаты оценки надо использовать для определения и осуществления предупреждающих действий с целью уменьшения идентифицированных рисков. Примеры средств оценивания рисков проектирования и разработки включают:
Анализ причин и последствий отказов проекта;
- анализ дерева отказов;
- прогноз безотказности;
- диаграммы зависимости;
- методы классификации;
- методы моделирования.
7.3 Проектирование и разработка7.3.1 Планирование проектирования и разработки Организация должна планировать и управлять проектированием и разработкой продукции. В ходе планирования проектирования и разработки организация должна устанавливать:
Организация должна управлять взаимодействием различных групп, занятых проектированием и разработкой, с целью обеспечения эффективной связи и четкого распределения ответственности. Планирование выхода должно актуализироваться, если это целесообразно, по мере развития проектирования и разработки. |
7.3.2 Входные и выходные данные для проектирования и разработки
Организации необходимо определить входные данные для процесса, влияющие на проектирование и разработку продукции и содействующие результативной и эффективной работе процесса с целью удовлетворения потребностей и ожиданий потребителей, а также других заинтересованных сторон. Эти внешние потребности и ожидания в сочетании с внутренними запросами организации должны быть пригодными для перевода во входные требования к процессам проектирования и разработки.
Примерами являются:
а) внешние входные данные, такие, как:
Потребности и ожидания потребителей или рынка;
- потребности и ожидания других заинтересованных сторон;
- вклад поставщиков;
- входные данные пользователя, направленные на создание стабильного проекта и разработки;
- изменения в соответствующие законодательные и регламентирующие требования;
- международные или национальные стандарты;
- промышленные кодексы установившейся практики;b) внутренние входные данные, такие, как:
Политика и цели;
- потребности и ожидания работников организации, включая лиц, получающих выходные данные процессов;
- технологические разработки;
- требования к компетентности проектировщиков и разработчиков;
- обратная информация о прошлом опыте;
- записи и данные о существующих процессах и продукции;
- выходы других процессов;с) входные данные, определяющие те характеристики процессов или продукции, которые являются критическими для их безопасности, правильного функционирования и обслуживания, такие, как данные о:
Работе, монтаже и применении;
- хранении, погрузочно-разгрузочных работах и поставке;
- физических параметрах и внешней среде;
- требованиях к утилизации продукции.
Существенное значение могут иметь входные данные, связанные с продукцией, которые основаны на оценке потребностей и ожиданий конечных пользователей, а также непосредственных потребителей. Эти входные данные необходимо сформулировать так, чтобы продукцию можно было результативно и эффективно верифицировать и утвердить.
Выходные данные включают информацию, позволяющую провести верификацию и валидацию в сравнении с запланированными требованиями. Примеры выхода проектирования и разработки включают:
Данные, подтверждающие сравнение входов для процесса с выходами процесса;
- спецификации на продукцию, в том числе критерии приемки;
- спецификации на процесс;
- спецификации на материалы;
- спецификации на испытания;
- требования к подготовке кадров;
- информацию о пользователе и потребителе;
- требования к закупкам;
- протоколы проверки соответствия техническим условиям.
Выходы проектирования и разработки следует проанализировать по отношению к входам с целью обеспечения объективного свидетельства того, что выходы результативно и эффективно отвечают требованиям к процессу и продукции.
ИСО 9001:2000. Системы менеджмента качества. Требования 7.3.2 Входные данные для проектирования и разработкиВходные данные, относящиеся к требованиям на продукцию, должны быть определены, а записи должны поддерживаться в рабочем состоянии. Эти данные должны включать:
Эти входные данные должны анализироваться на адекватность. Требования должны быть полными, недвусмысленными и непротиворечивыми. 7.3.3 Выходные данные проектирования и разработкиВыходные данные проектирования и разработки должны быть представлены в форме, позволяющей провести верификацию относительно входных требований к проектированию и разработке, а также должны быть утверждены до их выпуска. Выходные данные проектирования и разработки должны:
|
7.3.3 Анализ проекта и разработки
Высшему руководству необходимо обеспечить, чтобы соответствующие работники были назначены для управления и проведения систематического анализа, чтобы установить достижение целей в области проектирования и разработки.
Такие анализы могут проводиться в выбранных точках процесса проектирования и разработки, а также после его завершения.
Объектами таких анализов являются:
Адекватность входов для выполнения заданий по проектированию и разработке;
- ход запланированного процесса проектирования и разработки;
- соответствие целям верификации и валидации;
- оценка потенциальных рисков или причин отказов при использовании продукции;
- данные жизненного цикла, касающиеся характеристик продукции;
- управление изменениями и их последствия в ходе проектирования и разработки;
- определение и корректировка проблем;
- возможности для улучшения процесса проектирования и разработки;
- потенциальное воздействие продукции на окружающую среду.
На подходящих стадиях организации следует также проводить анализы выходов проектирования и разработки и процессов для удовлетворения потребностей и ожиданий потребителей, а также работников организации, получающих выходные данные процесса. Надо также уделять внимание потребностям и ожиданиям других заинтересованных сторон.
Примерами деятельности по верификации выходов процесса проектирования и разработки являются:
Сравнения требований к входу по отношению к выходу процесса;
- применение сравнительных методов, таких, как альтернативные расчеты при проектировании и разработке;
- оценка по отношению к аналогам;
- проверка, моделирование и испытания с целью контроля соответствия конкретным требованиям к входным данным;
- оценка уроков, извлеченных из прошлого опыта, таких, как несоответствия и недостатки процесса.
Валидация выходов процессов проектирования и разработки важна для успешного их получения и использования потребителями, поставщиками, работниками организации и другими заинтересованными сторонами.
Участие сторон позволяет фактическим пользователям оценивать выходы с помощью таких средств, как:
Валидация технического дизайна до конструирования, монтажа или применения;
- валидация выходов программного средства до монтажа или использования;
- валидация услуг до широкого их введения.
Может потребоваться частичная валидация выходных данных проектирования и разработки с целью обеспечения уверенности в их будущем применении.
В ходе верификации и валидации необходимо собрать достаточно данных, позволяющих проанализировать методы проектирования и разработки, а также принятые решения. Анализ методов включает:
Улучшение процессов и продукции;
- выходные данные по применимости;
- адекватность записей процесса и анализа;
- деятельность по исследованию отказов;
- будущие потребности процесса проектирования и разработки.
ИСО 9001:2000. Системы менеджмента качества. Требования 7.3.4 Анализ проекта и разработкиНа подходящих стадиях должен проводиться систематический анализ проекта и разработки в соответствии с плановыми мероприятиями с целью:
В состав участников такого анализа должны включаться представители подразделений, имеющих отношение к анализируемой(ым) стадии(ям) проектирования и разработки. Записи результатов анализа и всех необходимых действий должны поддерживаться в рабочем состоянии. 7.3.5 Верификация проекта и разработкиВерификация должна осуществляться в соответствии с плановыми мероприятиями, с тем чтобы удостовериться, что выходные данные проектирования и разработки отвечают требованиям к входным данным проектирования и разработки. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии. 7.3.6 Валидация проекта и разработкиВалидация проекта и разработки должна осуществляться в соответствии с плановыми мероприятиями, с тем чтобы удостовериться, что полученная в результате продукция способна отвечать требованиям к установленному применению или предполагаемому использованию там, где это известно. Где это практически целесообразно, валидация должна быть завершена до поставки или реализации продукции. Записи результатов валидации и всех необходимых действий должны поддерживаться в рабочем состоянии. 7.3.7 Управление изменениями проекта и разработкиИзменения проекта и разработки должны быть идентифицированы, а записи должны поддерживаться в рабочем состоянии. Изменения должны быть проанализированы, верифицированы и утверждены, если это целесообразно, а также одобрены до внесения. Анализ изменений проекта и разработки должен включать оценку влияния изменений на составные части и поставленную продукцию. Записи результатов анализа изменений и любых необходимых действий должны поддерживаться в рабочем состоянии. |