Вхідні дані, що стосуються вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (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).
Закупівлі
Процес закупівель
Організація має забезпечувати відповідність закупленої продукції встановленим вимогам до закупівель. Тип та ступінь управління, що застосовуються до постачальника та закупленої продукції, повинні залежати від її впливу на наступні стадії життєвого циклупродукції чи готову продукцію.
Організація повинна оцінювати та вибирати постачальників на основі їх здатності постачати продукцію відповідно до вимог організації. Повинні бути розроблені критерії відбору, оцінки та повторної оцінки. Записи результатів оцінювання та будь-яких необхідних дій, що випливають з оцінки, повинні підтримуватись у робочому стані (4.2.4).
Інформація із закупівель
Інформація щодо закупівель повинна описувати замовлену продукцію, включаючи, де це необхідно, вимоги:
a) до офіційного схвалення продукції, процедур, процесів та обладнання;
b) до кваліфікації персоналу;
c) до системи управління якістю.
Організація повинна забезпечувати достатність встановлених вимог до закупівель до повідомлення постачальнику.
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 ДСТУ ISO 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 Посібники з якості ).
Вилучена документація зберігається протягом трьох років.
7.3.1. Планування проектування та розробки
Організація повинна планувати та керувати проектуванням та розробкою продукції.
У ході планування проектування та розробки організація повинна встановлювати:
а) стадії проектування та розробки;
б) проведення аналізу, верифікацію та валідацію, що відповідають кожній стадії проектування та розробки;
в) відповідальність та повноваження у галузі проектування та розробки.
Організація повинна керувати взаємодією різних груп, зайнятих проектуванням та розробкою, з метою забезпечення ефективного зв'язку та чіткого розподілу відповідальності.
Результати планування повинні актуалізуватися, якщо це необхідно, під час проектування та розробки.
7.3.2. Вхідні дані для проектування та розробки
Вхідні дані, що стосуються вимог до продукції, мають бути визначені, а записи мають підтримуватись у робочому стані (п. 4.2.4).
Вхідні дані повинні включати:
а) функціональні та експлуатаційні вимоги;
б) відповідні законодавчі та інші обов'язкові вимоги;
в) там, де це можливо, інформацію, взяту з попередніх аналогічних проектів;
г) інші вимоги, важливі для проектування та розробки. Вхідні дані мають аналізуватись на достатність. Вимоги мають бути повними, недвозначними та несуперечливими.
(Змінена редакція. Зм. № 1).
7.3.3. Вихідні дані проектування та розробки
Вихідні дані проектування та розробки мають бути подані у формі, що дозволяє провести верифікацію щодо вхідних вимог до проектування та розробки, а також мають бути офіційно схвалені до їхнього подальшого використання.
Вихідні дані проектування та розробки повинні:
а) відповідати вхідним вимогам до проектування та розробки;
б) забезпечувати відповідною інформацією щодо закупівель, виробництва та обслуговування;
г) визначати характеристики продукції, суттєві для її безпечного та правильного використання.
(Змінена редакція. Зм. № 1).
7.3.4. Аналіз проекту та розробки
На відповідних стадіях повинен проводитись систематичний аналіз проекту та розробки відповідно до запланованих заходів (п. 7.3.1) з метою:
а) оцінювання можливості результатів проектування та розробки задовольняти вимогам;
б) виявлення будь-яких проблем та внесення пропозицій щодо необхідних дій. До складу учасників такого аналізу повинні включатися представники підрозділів, що мають відношення до аналізованої стадії проектування та розробки. Записи результатів аналізу та всіх необхідних дій мають підтримуватись у робочому стані (п. 4.2.4).
(Змінена редакція. Зм. № 1).
7.3.5. Верифікація проекту та розробки
Верифікація повинна здійснюватися відповідно до запланованих заходів (п. 7.3.1), щоб переконатися, що вихідні дані проектування та розробки відповідають вхідним вимогам. Записи результатів верифікації та всіх необхідних дій мають підтримуватись у робочому стані (п. 4.2.4).
7.3.6. Валідація проекту та розробки
Валідація проекту та розробки повинна здійснюватися відповідно до запланованих заходів (п. 7.3.1), щоб переконатися, що отримана в результаті продукція відповідає вимогам до встановленого або передбачуваного використання, якщо воно відоме. Де це практично можливо і доцільно, валідація має бути завершена до постачання чи застосування продукції. Записи результатів валідації та всіх необхідних дій мають підтримуватись у робочому стані (п. 4.2.4).
(Змінена редакція. Зм. № 1).
7.3.7. Управління змінами проекту та розробки
Зміни проекту та розробки мають бути ідентифіковані, а записи мають підтримуватись у робочому стані. Зміни мають бути проаналізовані, верифіковані та валідовані відповідним чином, а також схвалені до внесення. Аналіз змін проекту та розробки повинен включати оцінку впливу змін на складові та вже поставлену продукцію.
Записи результатів аналізу змін та будь-яких необхідних дій мають підтримуватись у робочому стані (п. 4.2.4).
(Змінена редакція. Зм. № 1).
Вхідні дані для проектування та розробки
Вхідні дані, що стосуються вимог продукції, повинні бути визначені, а записи повинні підтримуватися в робочому стані (4.2.4). Ці дані повинні включати:
a) функціональні та експлуатаційні вимоги;
b) відповідні законодавчі та обов'язкові вимоги;
c) там, де це є доцільним, інформацію, взяту з попередніх аналогічних проектів;
d) інші вимоги, важливі для проектування та розробки. Ці вхідні дані мають аналізуватись на адекватність. Вимоги мають бути повними, недвозначними та несуперечливими.
Вихідні дані проектування та розробки
Вихідні дані проектування та розробки мають бути подані у формі, що дозволяє провести верифікацію щодо вхідних вимог до проектування та розробки, а також мають бути затверджені до їх випуску.
Вихідні дані проектування та розробки повинні:
a) відповідати вхідним вимогам до проектування та розробки;
b) забезпечувати відповідною інформацією щодо закупівель, виробництва та обслуговування;
d) визначати характеристики продукції, суттєві для її безпечного та правильного використання.
Історія робіт у галузі якості в Росії.
Говорячи про передовий досвід у галузі управління якістю, не можна не згадати про вітчизняну практику вдосконалення якості.
Які концепції підвищення якості існували у нашій країні?
1. Концепція БІП(Безефектне Виготовлення Продукції) В основу цієї системи було покладено механізм активізації учасників виробничого процесу, що стимулює їх до виявлення та усунення не дефектів продукції, а їх причин. Після повторного пред'явлення продукції робітник втрачав премію.
2. Концепція КАНАРСПІ(Якість, Надійність, Ресурс з Перших Виробів) Була впроваджена на Горьківському авіаційному заводі. Визнана найкращою в країні система базувалася на наступних принципах:
· Універсальність (можливість використання в інших галузях промисловості)
· Комплексне забезпечення якості продукції
· Проведення досліджень, спрямованих на підвищення якості продукції та розвиток дослідно-конструкторських служб підприємства
· Організація всебічного обліку якості продукції, що випускається
· Концентрація уваги на якості продукції на стадії її розробки
· Залучення до вдосконалення продукції споживачів
1. Концепція НОРМУ 1960-х гг. на Ярославському моторному заводі «Автодизель» було впроваджено систему НОРМ, у якій за критерій якості було прийнято одне з найважливіших технічних параметрів- ресурс до першого капітального ремонту. Особлива увага приділялася розробці конструкції та технології, що забезпечують підвищення технічного рівня та якості двигуна. У системі НОРМ були використані та розвинені основні елементи Саратовської та Горьківської систем управління якістю продукції, що випускається.
2. Концепція КСУКП(Комплексна система управління якістю продукції)
У першій половині 1970-х років. в результаті спільного науково-виробничого експерименту підприємств Львівської області, ВНДІ стандартизації Держстандарту СРСР та науково-виробничого об'єднання «Система» було розроблено та пройшла апробацію комплексна система управління якістю продукції.
Головна мета системи полягала у забезпеченні високих та стійких темпів зростання якості продукції, що випускається підприємством, за рахунок:
· Створення та освоєння нових високоякісних видів продукції;
· Своєчасної постановки на виробництво нової продукції;
· Зняття з виробництва морально застарілої продукції;
· Поліпшення показників якості продукції, що випускається шляхом її вдосконалення та модернізації.
У чому полягала специфіка Російського досвідууправління якістю?
Специфіка управління якістю у Росії полягала в тому, що ефективні системиуправління якістю створювалися на підприємствах військово-промислового комплексу (ВПК). Саме у ВПК були поширені методи забезпечення якості на стадіях дослідження та проектування нової продукції, статистичний контроль якості із застосуванням контрольних карток, спеціальні стандарти. У надрах ВПК народилися КСУКП ( комплексні системиуправління якістю продукції, у тому числі автоматизовані).
СМЯ: Управління невідповідною продукцією.
Методика керування невідповідною продукцією.
1) визначаємо продукцію, що включається в область застосування СМЯ,2) визначаємо, що таке відповідна продукція,3) визначаємо, які механізми управління застосовні до якої продукції (можна у вигляді таблиці),4) докладно описуємо ці механізми у застосуванні до конкретної продукції: хто за що відповідає, які повноваження має, що робить.
Поки що продукція у нас.
Що ми можемо зробити для забезпечення відповідності продукції, коли виявлено невідповідність?
Перше очевидно: виправити. тобто. у термінах ISO 9000 здійснити корекцію. Але це не завжди можливе.
Тоді друге: оцінити, наскільки невідповідність перешкоджає навмисному використанню продукції, і якщо прийнятно, то дозволити відхилення. Якщо можливо, то дозвіл на відхилення запитується ще й у споживача, чи він згоден. Замовник, проаналізувавши, які саме функції будуть відсутні, може вважати це цілком прийнятним і дозволити.
Якщо ні перше, ні друге неможливо, залишається третій варіант: змінити початкове застосування чи взагалі відмовитися від застосування продукції.
Очевидно, що процедуру управління невідповідною продукцією неможливо повноцінно розробити, якщо
не визначено саму продукцію, якістю якої керуємо в рамках СМЯ,
не визначено, що таке відповідна продукція, оскільки це рівнозначно тому, що не визначено невідповідну продукцію.
З досвіду аудіювання: якщо я з посібника з якості не можу зрозуміти, яка конкретно продукція включена в область застосування СМЯ, то я можу навіть не дивитися процедуру управління невідповідною продукцією, заздалегідь гарантуючи, що вона формальна.
Механізми управління у кожному із трьох випадків:
Змінити продукцію (корекція)
вказати спосіб ідентифікації невідповідної продукції та відповідального за цю ідентифікацію,
вказати відповідального за запобігання випуску та поставці ідентифікованої невідповідної продукції та її повноваження,
вказати відповідального за корекцію,
встановити процедуру повторного контролю та відповідального за її виконання,
встановити, в якій формі робиться запис про характер невідповідності та рішення про корекцію.
Змінити вимоги
вказати уповноваженого на надання дозволу на відхилення та його повноваження, а також встановити процедуру такого дозволу, включаючи встановлення особи, уповноваженої споживачем надавати дозвіл на відхилення,
встановити, в якій формі робиться запис про характер невідповідності та дозвіл на відхилення.
Змінити застосування
встановити відповідального за запобігання первісному застосуванню споживачем невідповідної продукції та його повноваження, а також процедуру такого запобігання,
встановити, в якій формі робиться запис про характер невідповідності та дії щодо запобігання початковому застосуванню.
Продукція споживача.
Очевидно, що в цій ситуації жоден із описаних вище механізмів не застосовується: продукція вийшла з-під нашого контролю. Все, що ми можемо в даному випадку, це зробити дії, що знижують негативні наслідки чи ризик таких наслідків споживача. Як приклад тут можна навести всім відомі компанії з відкликання автомобілів.
Вхідні дані повинні бути ідентифіковані для того, щоб забезпечити базис для формулювання вимог, що використовуються для верифікації та затвердження вихідних даних. Вхідні дані можуть бути зовнішніми та внутрішніми.
Для того, щоб забезпечити задоволення потреб та очікувань усіх зацікавлених сторін щодо процесу та/або послуги, процесу або системи, вхідні дані для проектування та/або розробки повинні бути точними та повними. Дозвіл двозначних або суперечливих вхідних даних слід проводити із залученням схильних до впливу зовнішніх і внутрішніх сторін.
Зовнішні вхідні дані можуть включати потреби та очікування замовника чи ринку, специфікації заінтересованої сторони, контрактні вимоги, нормативні вимоги, міжнародні чи національні стандарти, галузеві норми та правила.
Внутрішні вхідні дані можуть включати політики, стандарти та специфікації, вимоги до кваліфікації, документацію та дані на існуючі продукти та/або послуги та вихідні дані від інших процесів.
У разі проектування та/або розробки програмного забезпечення або послуг, вхідні дані, що випливають із вимог кінцевого користувача (також як вимог прямого замовника), можуть бути особливо важливими. Такі вхідні дані повинні бути сформульовані таким чином, щоб вони могли бути ефективно проконтрольовані під час наступної верифікації та затвердження. Такі вхідні дані повинні бути сформульовані таким чином, щоб вони могли бути ефектно проконтрольовані під час наступної верифікації та затвердження.
Вхідні дані можуть також виникати на етапі розробки в процесі діяльності, які навіть не оцінені. Також вхідні дані повинні бути предметом оцінки наступних ревю та діяльностей з верифікації та затвердження.
Інші вхідні дані ідентифікують характеристики проектування та/або розробки, які є критичними з точки зору безпеки та правильного функціонування продукту та/або послуги або ідентифікують процеси, такі як робочі операції, зберігання, звернення, експлуатацію та вимоги до розміщення.
Типові приклади діяльності, пов'язані з розробкою, включають:
змінені матеріали,
змінені компоненти продукту,
нові технології надання послуг,
результати аналізів ринку.
Вхідні дані, що є критичними для продукту та/або послуги або для процесу, повинні бути ідентифіковані для того, щоб призначити відповідні відповідальності та ресурси.
|
ISO 9001:2000 - Системи менеджменту якості - Вимоги 7.3.2 Вхідні дані для проектування та розробки. Вимоги до продукту та/або послуги повинні бути визначені та зареєстровані (див.5.6.7). Ці вимоги повинні включати: вимоги до виконання від замовника чи ринку; застосовувані нормативні та законодавчі вимоги; вимоги до навколишньому середовищі вимоги, які з попередніх подібних проектів; будь-які інші вимоги, суттєві для проектування та розробки. Ці вхідні дані повинні бути піддані ревю на адекватність або суперечливості щодо вимог, які мають бути виконані. |
