• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

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

Базиси

Угоди

I Вступ

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

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

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

II Управління

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

4. Модель якості ISO-9126

Ця модель якості припускає, що є шість груп, що беруться до уваги при оцінці якості: функціональність, надійність, практичність, ефективність, ремонтопридатність, виносливість.

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

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

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

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

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

Виносливість означає, що система працюватиме на різних платформах.

5. Управління якістю

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

В управлінні якістю ми беремо до уваги два поняття: процесовий підхід і системний підхід. У процесовому підході розглядаються окремі кроки, аналізуються взаємозв'язки між процесами. У системному підході необхідне розуміння системи і всього виробництва. Необхідна якість програми забезпечується, якщо обидва підходи задоволено і вони доповнюють один одного. Тому ми повинні зосередитися на кроках, не забуваючи про системне бачення.

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

Співпраця також є чинником управління якістю. Близькі відносини з клієнтами і відповідне визначення потреб дуже важливі.

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

Гарантія якості програмного забезпечення - "плановий і систематичний набір необхідних дій для оцінки відповідності програми вимогам".

Гарантія якості програмного забезпечення (SQA, software quality assurance) визначає, чи задовольняють плани стандарти, чи слідують процедури планам, чи реалізовуються продукти згідно планам.

Перевірити все неможливо. Тому є особливо важливі ділянки, які визначаються і контролюються.

У SQA план всіх дій повинен бути встановлений. Він назваєтся "план гарантії якості програмного забезпечення".

Ризик втрати якості

Загальний критерій - ризик втрати якості. Чинниками, які можуть викликати втрату, є: інноваційний проект, його складність, нестача знань та досвіду персоналу, неформальні (створені спонтанно і непродумано) процедури, незрілість виробника.

Щоб мінімізувати ризик SQA, персонал повинен бути залучений у виробництво на найраніших стадіях. Він повинен перевірити вимоги користувача, плани, процедури і документи. Згода з існуючими процедурами повинна бути перевірена, оскільки ціна помилки, виявленої за пізно, може бути дуже великою.

Завдання гарантії якості програмного забезпечення

Завдання розглядаються на двох рівнях: на рівні компанії і проектному рівні. На рівні компанії це постійна підтримка системи, спостереження, стандартне визначення і схвалення виробництва.

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

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

Важливе завдання в SQA - підготовка, вміст і організація документації.

Збір, організація і використання вимірювань також є важливим завданням.

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

Є і інші завдання, які потрібно взяти до уваги:

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

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

Читайте також:

1. III. Контроль знань
2. III. КОНТРОЛЬ і УПРАВЛІННЯ РЕКЛАМУВАННЯМ
3. POS -Інтелект - відеоконтроль касових операцій
4. Акустичний контроль приміщень через засоби телефонного зв'язку
5. Аудит розрахунків з постачальниками і підрядниками
6. Аудит розрахунків з постачальниками і підрядниками
7. Банківський контроль та нагляд: форми та мета здійснення. Пруденційний нагляд: поняття, органи та мета проведення.
8. Біохімічний контроль за розвитком систем енергозабезпечення
9. Бюджетний контроль - це порівняння показників бюджету зі звітом за від­повідний період часу.
10. Бюджетний контроль на місцевому рівні
11. Валютний контроль

Переглядів: 1431