Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Групи SQA

Завдання SQA можуть бути розбиті на наступні групи:

· атестація системи перед постачанням

· стандартне примушення в зборі даних і їх зберіганні

· перегляд і атестація документації

· розробка системної архітектури і стандартів програмування

· перегляд проекту з точки зору його завершеності

· тестування нової зміненої системи

· розвиток стандартів менеджменту

· навчання

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

6. Стандарти якості

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

Мал. 14.7.1. Стандарти якості.

Стандарт IEEE-730 було удосконалено і уточнено стандартом IEEE-983.

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

Модель якості програмного забезпечення зображена на малюнку 14.7.2.

Мал. 14.7.2. Модель якості програмного забезпечення.

7. Незрілість і зрілість виробництва

Незрілість визначається наступними чинниками:

· імпровізація у виробничому процесі,

· процес вказаний, але специфікація не використовується,

· не дотримання бюджету і графіку,

· недостатня функціональність,

· низька якість продукції,

· немає об'єктивних критеріїв.

Зрілість виробництва визначається наступними чинниками:

· здатність використовувати сучасне програмне забезпечення (здатність всієї організації, а не окремого співробітника),

· процес визначений, відомий і вдосконалений,

· робота планується і контролюється,

· розподілені ролі і відповідальність,

· існує об'єктивна, якісна і кількісна оцінка.

CMM – модель технологічної зрілості організації

Робота по вимірюванню можливостей виробників програмного забезпечення була ініційована в Департаменті Оборони США в сімдесятих роках. Інститут Розробки Програмного Забезпечення ввів модель технологічної зрілості організації - CMM (Capability Maturity Model).

Модель технологічної зрілості організації стала дуже популярною. Модель припускає, що вищого рівня культури процесу можливо досягти, тільки тоді, якщо зрозуміти відповідні чинники. Вона використовує поняття глобального управління якістю (TQM, Total Quality Management). Є п'ять рівнів технологічної зрілості організації:

Мал. 14.8.1. Модель технологічної зрілості організації

У моделі технологічної зрілості організації розрізняють 5 наступних рівнів:

1. початковий рівень – 1 (хаотичний процес),

2. ітеративний рівень – 2 (індивідуальний процес),

3. визначений рівень – 3 (постанова обробки процесів),

4. рівень управління – 4 (процес + зворотний зв'язок для процесу),

5. рівень оптимізації – 5 (процес + зворотний зв'язок для вдосконалення процесу).

Процеси класифікуються, грунтуючись на детальній анкеті, що завершується інтерв'ю і зборами матеріалів. Кожен рівень характеризується ключовою областю процесу (KPA, Process Key Area).

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

Важлива причина, яка робить модель технологічної зрілості організації популярною - рівень номер 3, який дозволяє укладати контракти з Департаментом Захисту США. Практика показує, що дістатися до рівня 3 для багатьох компаній просто неможливо. До рівня номер 5 належать тільки декілька компаній: IBM, яка виробляє програмне забезпечення для НАСА і Motorola.

8. План гарантії якості ПЗ (SQAP)

План гарантії якості ПЗ (SQAP, Software Quality Assurance Plan) повинен змінюватися протягом життєвого циклу програми. Першу версію потрібно завершити до кінця формулювання призначених для користувача вимог.

ПГЯПЗ повинен визначити і описати всі дії, пов'язані з якістю ПЗ. Відповідні секції повинні посилатися на певні фази життєвого циклу ПЗ.

Надані стандарти взяті з ANSI/IEEE Std 730-1989 IEEE Стандарт для плану гарантії якості ПЗ.

Інші стандарти - з ANSI/IEEE Std 983-1989 IEEE Стандарт для плану гарантії якості ПЗ.

Контекст і вміст плану гарантії якості ПЗ залежать від розміру проекту.

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

Стиль, відповідальність, секції ПГЯПЗ

ПГЯПЗ повинен бути зрозумілий, поверхневий, несуперечливий і змінюваний. Він повинен бути підготовлений офісом оцінки якості, розглянутий і схвалений контролюючим органом. ПГЯПЗ - це документ. Він може розповсюджуватися і в електронній формі. Повинен мати наступні чотири розділи:

1. ПГЯПЗ вимог користувача і аналізу.

2. ПГЯПЗ архітектури проекту.

3. ПГЯПЗ дизайну і розробки.

4. ПГЯПЗ створення, тестування і інсталяції.

ПГЯПЗ повинен бути створений для подальшої фази, після завершення попередньої.

Зміст ПГЯПЗ

Номери послідовності не можна змінювати. Якщо в секції немає інформації, потрібно зробити позначку "не застосовно". Весь допоміжний матеріал потрібно надати в доповненнях. Покажчики 3-15 визначаються як технічні покажчики.

Мета

Секція повинна бути описана стисло: завдання ПГЯПЗ, тип читача, тема програмних продуктів ПГЯПЗ, використання, що передбачується, фаза життєвого циклу ПЗ.

Управління

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

Організація

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

Завдання

Секція описує завдання ПГЯПЗ.

Відповідальність

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

Документація

Визначає всі документи в кожній конкретній фазі. Секція повинна визначити, як перевірятиметься відповідність документів із стандартами.

Стандарти, домовленості, метрика

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

Огляди і перевірка

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

Тести

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

Повідомлення про проблеми і їх запобігання

Описуються процедури помилкового визначення і попереджувальних дій. Може визначатися метрика для удосконалення ПЗ.

Контроль над кодом

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

Контроль носіїв інформації

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

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

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

Збір, підтримка і зберігання документації

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

Організаційна інформація

a - підсумок (максимум - 200 слів)

b - зміст

c - стан документації

d - зміни, починаючи з останньої версії

Тіло документа

1. Цілі

2. Посилання

3. Управління

4. Документація

5. Стандарти

a. документація

b. дизайн

c. контроль

d. коментування

e. стандарти і практика тестування

f. застосовні метрики гарантії якості ПЗ

g. моніторинг згідно з ПГЯПЗ

6. Перегляди

7. Тестування

8. Повідомлення про проблеми і їх запобігання

9. Інструменти

10. Контроль над кодом

11. Контроль носіїв інформації

12. Контроль постачальників

13. Збір, підтримка і зберігання документації

14. Навчання

15. Управління ризиком

16. Огляд частини проекту, що залишилася

Програма А: Словник термінів і акронімів.

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

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

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

XV. Управління проектом програмного забезпечення

1. Завдання управління проектом

Необхідна умова успіху проекту - відповідне управління проектом.

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

· визначення операцій проекту,

· визначення вартості проекту,

· планування і складання графіка,

· моніторинг і управління реалізацією проекту,

· вибір і оцінювання персоналу,

· презентація і доставка звітів старшим за посадою.

Методи управління підприємства по розробці ПЗ не відрізняються від методів управління інших підприємств. Але розробка ПЗ виразніша.

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

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

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

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

2. Працівники виробництва програмного забезпечення

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

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

<== попередня сторінка	\|	наступна сторінка ==>
VII Контроль постачальника	\|	Характеристика хорошого розробника програмного забезпечення

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.007 сек.