I Вступ

1. Цілі. Коротко описує цілі ПУКПЗ (чому і для кого розробляється)

2. Границі. Коротко описує елемент конфігурації, його дії, організацію і життєвий цикл.

3. Посилання. Містить список всіх документів, з вказівкою їх назви, автора, дати, номера і т.д.

II Управління

Розділ описує організацію УКПЗ, дії і посади.

1. Організація. Цей підрозділ описує посади, які впливають на УКПЗ. Так само описуються менеджери за проектом, програмісти, персонал оцінки гарантії якості, відділи перегляду, ревізії і затвердження, їх взаємовідношення і зв'язки.

2. Розподіл відповідальності в УКПЗ. Описує функції, покладені на конкретні посади, наприклад, визначення інтерфейсу компонентів, зберігання, контроль змін, визначення стану. Привласнюються відповідальності за перегляд, схвалення і затвердження.

3. Управління зовнішнім інтерфейсом. Обговорюються процедури управління взаємодією зовнішньої апаратури і ПЗ.

4. Реалізація ПУКПЗ. Ключовими елементами ПУКПЗ є готовність системи УКПЗ, відділ перегляду, версії продукту і т.д.

5. Застосовані рекомендації, стратегії і процедури. Визначаються застосовні стратегії і дається їх інтерпретація.

III Визначення конфігурації

Угоди

Приймається угода про використання імен і міток.

Базиси

Для кожного базису визначається наступне:

• ідентифікатор,

• зміст. Наприклад, ПЗ, інструменти, тестування, звіти про несумісність, визначення проблем,

• інтерфейси продукції,

• перегляд і ухвалення,

• спільна робота розробника і користувача в конкретном базисі.

IV Управління конфігурацією

1. Управління кодом і документом. Описує процедури управління бібліотекою коду і документації: бібліотека розробки ПЗ, головна бібліотека (базисів) і архіви.

2. Управління носіями. Описує які носії і коли використовуватимуться для зберігання інтерфейсів компонентів. Угода про привласнення міток, способи і місця зберігання інтерфейсів користувача і їх повторне використання.

3. Управління змінами

• рівень затвердження змін. Визначає рівень повноважень для затвердження базисів (бібліотекар, менеджер проекту).

• процедура змін. Описує процес внесень змін.

• відділ перегляду (рада, комітет правління). Описує членів відділу перегляду, рівень повноважень, делегування нижньому рівню прав.

V Реєстрація статусу конфігурації

Визначає спосіб зберігання і обробки інформації про інтерфейс компонентів, звіти про їх стан.

VI Інструменти, техніка і методи в УКПЗ

Описує інструменти і методи, використані в УКПЗ.

VII Контроль постачальника

Описує завдання зовнішніх постачальників.

VIII Запис і зберігання документів

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

8. Короткий звіт

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

Кожен продукт повинен мати свою конфігурацію. Це критично важливо для фінальної версії продукту, її ефективності і підтримки.

XIV. Якість програмного забезпечення

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

1. Якість програмного забезпечення.

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

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

На жаль, об'єктивні вимірювання дуже важко зробити і навіть неможливо. Оцінити якість програми дуже важко, оскільки кількість і складність вимірювань можуть бути великими, програмне забезпечення має багатофункціональні властивості, а варіанти поведінки непередбачувані.

Критерії повинні бути визначені перед тим, як програма буде зроблена. Багато чинників не підлягають вимірюванню. Програмні продукти складно оцінити, оскільки важко ввести параметри вимірювання.

Програми можуть використовуватися в різних умовах і масштабі. Вимірювання, взяті в одному масштабі, можуть не відповідати їм в іншому. Також вони можуть бути дорогими, дуже тривалими або просто неможливими.

Важко об'єднати проведені вимірювання в одне ціле. Тому дуже велику роль відіграють спрощуючі методи. Ці методи вводять нові алгоритми, формули, обмеження і евристику.

2. TQM – управління за якістю

Поняття TQM було введене японцем Eiji Toyode для японської автомобільної промисловості в 1950. Первинна ідея полягала в тому, що задоволення клієнта - найголовніше, оскільки клієнт впливає на дохід підприємства.

TQM був остаточно сформульований американцями (W.Q. Deming, P. Crosby, J.M. Juran, A.V. Feigenbaum), японцями (E. Toyoda, М. Imai, K. Ishikawa), і британцем J. Oakland.

Кожен з вище названих авторів визначив власні принципи TQM. Всі вони слідують принципу Toyoda: "Якість - найголовніше для клієнта. Пам'ятаєте, що саме завдяки клієнтам компанія працює ". Тому виробник поганої продукції буде вигнаний з ринку.

3. Якість в ISO

Якість - термін, який залежить від середовища, культури і сприйняття групи. Якість розуміється дуже суб'єктивним чином. Тому складно дати чітке визначення якості.

Стандарти ISO - 9000 намагаються визначити термін "якість" і інші пов'язані з ним терміни. Стандарт визначає важливі поняття.

Список найголовніших понять:

Якість – всі характеристики і властивості, які визначають, на скільки продукт задовольняє призначені для користувача потреби.

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

Управління якістю – всі функції, які дають оцінку якості.

Стандарти якості – всі директиви і дії, зроблені для того, щоб забезпечити якість продукту; формальний опис, даний менеджерами системи якості.

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

Стандарти і система якості

Стандарти - загальні правила якості, яким продукт повинен відповідати. Компанія робить ці наміри формальними.

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

Система якості - структура з розподіленою відповідальністю, використанням ресурсів для задоволення вимог якості, зразком якості; документованими процедурами для задоволення якості.

Якість програмного забезпечення

Якість - загальне поняття. Тому визначення повинне бути детальнішим. Ми представляємо два визначення якості програмного забезпечення.

Згідно стандарту ISO-9000-3:

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

Згідно стандарту IEEE-610-12:

Якість програмного забезпечення - ступінь відповідності програмного забезпечення необхідному набору характеристик.