---

Затвердив:

Взаємини з постачальниками Моніторинг і вимірювання

Контроль інспекгувального та випробувального устатковання Внутрішні аудити

Органіграми та посадові інструкції Навчання

Програма якості у вигляді блок-схеми

QSP - 001

QSP - 005

QSP-010

QSP - 020

QSP-050

QSP - 055

SOP - 300

SOP - 600

SOP-610

SOP-675

SOP - 800

SOP-810

П

ДСТУ ISO 10005:2007

римітка. О Виготовлення О Інспектування та випробовування V ЗберіганняА.2.4 Приклад 4: Програма якості у текстовій формі (щодо розробляння програмного забезпечення, для стоякового дисплея)

1. СФЕРА ЗАСТОСУВАННЯ

Програма якості призначена визначити методи управління якістю, застосовувані до контракту між підпри­ємством і її клієнтом щодо системи розподілювання предметів одягу.

1. Поширення

Ця програма якості застосовна до розробляння та постачання підсистем розподілювання, керування по­ступками та маркетингу. Системи керування фінансами становлять предмет контракту із субпідрядником, і тому програма якості стосується винятково аспектів управління субконтрактами цієї частини проекту.

2. Винятки

Робота з розробляння, яку виконує субпідрядник, охоплена замовленням на закупівлю і не деталізована в цій програмі.

2. ЦІЛІ У СФЕРІ ЯКОСТІ

Клієнт не висловив жодних конкретних вимог щодо кількісно зазначених цілей у сфері якості. Унаслідок цьо­го потрібно застосовувати внутрішній стандарт підприємства на випуск версії програмного забезпечення без жодних відомих дефектів категорії А, без жодних відомих дефектів категорії В і з дефектами категорії С лише за згоди клієнта. Дефект означено як поведінку системи, що свідчить про невідповідність порівняно з узгод­женими вимогами.

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

З ВІДПОВІДАЛЬНІСТЬ

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

Керівник з питань якості є відповідальним за аудити проекту і за подальші будь-які коригувальні дії, ви­значені за їхніми результатами. Керівник з питань якості має затверджувати будь-який потрібний відхил від сис­теми управління якістю перед тим, як відхил матиме місце.

4. ДОКУМЕНТАЦІЯ

Деякі документи, використовувані в цьому проекті, мають посилання, які не відповідають останнім вимо­гам системи управління якістю. Наявні посилання залишаються чинними. Щодо іншого, то система управлін­ня якістю є застосовною.

4. ПРОТОКОЛИ

Досьє проекту і пов’язані з ним протоколи мають зберігати принаймні упродовж трьох років після закінчення гарантійного періоду. їх розташування на цей час потрібно узгодити з клієнтом. Згідно з політикою підприєм­ства, клієнт може переглядати будь-які протоколи, пов'язані з контрактом, у будь-який прийнятний час. Резервні копії комп’ютерних файлів до контракту потрібно робити принаймні щотижня.

4. РЕСУРСИ

Клієнт постачає зразок OCR-форм (не менше 2000) для використовування у випробовуванні пристрою чи­тання документів, який постачають як частину системи. Субпідрядник повинен отримати і ввести в експлуа­тацію пристрій читання документів як частину свого постачання системи управління фінансами.

Усі члени групи розробників повинні бути працівниками підприємства. Керівник відділу кадрів повинен за­безпечити наявність персоналу належної кваліфікації, щоб задовольнити потреби проекту. Керівником проек­ту є пан Дж. Сміт.

4. ВХІДНІ ДАНІ ПРОЕКТУ

Початковими даними є специфікація вимог KLOB-D-001, розроблена консультантами клієнта. Підприємство має давати вибіркові маркетингові документи і річні звіти для ознайомлення.

4. ЗВ’ЯЗКИ ІЗ ЗАМОВНИКОМ

Будь-які запити стосовно специфікації клієнт має подавати керівникові проекту на передбачених проектом нарадах. Прийняті рішення є остаточними. Клієнт не має технічних можливостей щодо програмного забезпе­чення, тому технічні запити має бути адресовано через керівника проекту або його представника. Протоколи проектних нарад складатиме керівник проекту. Так само, інформація від замовника (запити, скарги, зауваги) має надходити через керівника проекту.

4. ПРОЕКТУВАННЯ ТА РОЗРОБЛЯННЯ

Графік проекту подаватимуть, використовуючи затверджений засіб календарного планування. Критичними датами є приймальні випробування з боку замовника (наприкінці жовтня) і розгортання системи (до квітня на­ступного року).

Усі стандарти підприємства, подані в Настанові щодо розробляння програмного забезпечення, повинні бути застосовані. Критичне аналізування та затвердження потрібно здійснювати так, як подано в Настанові щодо якості підприємства.

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

Порядок випробовування потрібно зробити таким, як подано в Настанові щодо якості підприємства. Ви­пробовування на збирання даних документа вимагатиме зчитувача документів. Остаточні випробування підсис­теми маркетингу потребуватимуть стоякового дисплейного пристрою, щоб перевірити реакцію замовника. Сис­тема розподілювання в цілому підлягає випробовуванню на підприємстві перед відвантаженням і в момент приймання замовником на своїй території.

4. ЗАКУПІВЛЯ

Усе устатковання має закупити клієнт (комп’ютери через субпідрядника, інші елементи безпосередньо). Будь-які інші закупівлі потрібно зробити згідно з методиками підприємства.

4. МОНТУВАННЯ ТА ВВЕДЕННЯ В ЕКСПЛУАТАЦІЮ

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

4. СПЕЦІАЛЬНІ ПРОЦЕСИ

У цьому проекті немає спеціальних процесів.

4. КЕРУВАННЯ КОНФІГУРАЦІЄЮ

Ідентифікатори документів повинні відповідати версії Настанови щодо якості, що існує на момент започат- кування проекту, за винятком тих документів, які вже ідентифіковано раніше.

Потрібно використовувати наявні затверджені підприємством засоби керування конфігурацією.

4. ВЛАСНІСТЬ ЗАМОВНИКА

Будь-яке устатковання, що належить клієнту, потрібно ідентифікувати належним чином, доки воно перебу­ватиме в розпорядженні підприємства чи її субпідрядників.

Власність замовника будь-якого виду треба зареєструвати в журналі проекту.

4. ПОВОДЖЕННЯ З ПРОДУКЦІЄЮ

Програмне забезпечення передаватимуть на компакт-дисках (CD-ROM). Усі компакт-диски перевірятимуть на наявність вірусів.

4. НЕВІДПОВІДНОСТІ

Жодне програмне забезпечення не потрібно передавати з відомими невідповідностями, крім незначних, без письмово оформленої поступки з боку клієнта. Процес відповідатиме поданому в Настанові щодо якості і Настанові щодо розробляння програмного забезпечення підприємства.

4. МОНІТОРИНГ І ВИМІРЮВАННЯ

Хід виконання проекту щотижнево протоколюватимуть у табелях обліку часу та реєструватимуть у графі­ку проекту. Потрібно підготувати звіт і оприлюднити його на нараді щодо ходу виконання за участі клієнта. Треба запрошувати субпідрядника на окремі засідання. Керівник групи програмування повинен вести протоколи з будь-яких проблем стосовно програмного забезпечення, визначених під час тестування другого та третього рівнів. Проблеми потрібно поділити за категоріями, залежно від їх походження: специфікація вимог (не досяг­нуто чи неправильно), проектування (не досягнуто чи неправильно), кодування (не досягнуто, неправильна логіка, інтерфейсна помилка, помилка опрацювання даних).

4. ВНУТРІШНІ АУДИТИ

Аудит запроваджування програми якості та її результативності потрібно проводити наприкінці стадії про­ектування.

Програму якості розробив керівник проекту в рамках започаткованого клієнтом проекту розподілу, її за­стосовують до всієї роботи, виконуваної за контрактом.

Автор: Дата

Керівник з питань якості: Дата

№ документа: KLOB-QP-001 Версія 1

ДОДАТОК В
(довідковий)
ВІДПОВІДНІСТЬ МІЖ ISO 10005:2005 ТА ISO 9001:2000

Таблиця В.1 — Відповідність між ISO 10005:2005 та ISO 9001:2000

Кінець таблиці В.1