Тема.  Основи якості програмного забезпечення

План

1. Аспекти визначення якості та її атрибути.

2. Кодекс етики програмної інженерії.

3. Значення і вартість якості.

 

1.   Аспекти визначення якості та її атрибути.

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

Область знань «Якість ПЗ (Software Quality)» складається з наступних розділів:

Ø   концепція якості ПЗ (Software Quality Concepts);

Ø   визначення та планування якості (Definition & Planning for Quality);

Ø   діяльності і техніки гарантії якості і V & V (Activities and Techniques for Software Quality • Assurance, Validation-V & Verification - V);

Ø   вимірювання в аналізі якості ПЗ (Measurement in Software Quality Analysis).

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

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

До характеристикам якості відносяться:

ü   Функціональність.

ü   Надійність.

ü   Зручності використання.

ü   Ефективність.

ü   Супроводжуєміст.

ü   Переносимість.

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

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

 

Планування якості включає:

Ø Визначення продукту в термінах заданих характеристик якості.

Ø Планування процесів для отримання необхідної якості.

Ø Вибір методів оцінки планованих характеристик та встановленню відповідності продукту сформульованим вимогам.

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

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

2. Задоволення потреб: якість, що визначається незалежно від будь-яких вимірних характеристик. Тобто, якість визначається як продукти чи послуги, що дають можливість задовольнити очікування клієнтів — явні чи ні.

Протягом багатьох років окремі автори й цілі організації визначали термін "якість" по—різному.

Уотс Хемпфрі (Watts Hamphrey, автор концепції моделі оцінки зрілості CMM, а також PSP і TSP — People Software Process і Team Software Process) описує якість як "досягнення відмінного рівня придатності до використання".

Уолтер Едвардс Демінг в "Out of the crisis: quality, productivity and competitive position ", говорить:

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

Одна із сильних сторін Демінга в тому, що якість має бути визначено з точки зору задоволеності клієнтів — що набагато ширше поняття, ніж "відповідність специфікації" визначення якості (наприклад, з точки зору "задоволення потреб клієнтів"). Демінг пропонує, що якість має бути визначено тільки з точки зору агента — судді якості.

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

Компанія IBM, у свою чергу, ввела в обіг фразу "якість, керована ринковими потребами " ("market-driven quality ").

Критерій Белдріджа (Baldrige) для організаційного якості (NIST — National Institute of Standards and Technology, "Baldrige National Quality Program") використовує схожу фразу — "якість, що задається споживачем" ("customer—driven quality").

Найчастіше, поняття якості використовується відповідно з визначенням системи менеджменту якості ISO 9001 як "ступінь відповідності властивих характеристик вимогам".

Фейгенбаум визначає, що ім'я та термін контролю якості, практично є синонімом через його глибокий вплив на концепцію тотального контролю якості (а також у зв'язку з його авторством концепції). У "Total quality control" Арманд Фейгенбаум Валле пояснює свій погляд на якість наступним текстом:

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

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

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

В " Jurans's Quality Control Handbook" Джозеф М. Джуран передбачає два значення для якості:

Слово якість має кілька значень. Два цих значення домінують у використанні цього слова: 1) Якість складається з тих властивостей продукту, які відповідають потребам клієнтів і тим самим забезпечують успіх продукту. 2) Якість складається через відсутність недоліків. Тим не менш, виходячи з цього найзручніше дати коротке визначення поняття якості, як "придатність для використання".

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

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

Якість ПЗ характеризується трьома головними аспектами:

•          якість програмного продукту;

•          якість процесів ЖЦ;

•          якість супроводу або впровадження (Мал. 1).

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

 

Мал. 1. Основні аспекти якості ПЗ

 

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

 

2.   Кодекс етики програмної інженерії

Своєю появою інженерія ПЗ зобов'язана діяльності потужних професійних об'єднань — The Assotiation for Computer Machmery (ACM) і Institute of Electrical and Electrorncs Engmeers Computer Sodety (IEEE Computer Sotiety). Спільними зусиллями цих двох об'єднань розроблений  кодекс етики програмної інженерії. Він фокусує мораль, правила і норми поведінки професіоналів, їх зобов'язання і відповідальність по відношенню до суспільства і один до іншого.

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

Ø   технічні вміння;

Ø   відповідальність перед користувачами;

Ø   вміння керувати і приводити до вдалого завершення великі програмні проекти.

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

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

У кодексі задекларовано вісім принципів, які стосуються відповідно:

1)       узгодження професійної діяльності з інтересами суспільства;

2)       взаємовідносини між клієнтом, роботодавцем і виконавцем розробки;

3)       досягнення відповідності якості продукту кращим професійним стандартам;

4)       дотримання чесності і незалежності при професійних оцінках;

5)       дотримання етичних норм у менеджменті і в супроводі розробок;

6)       підтримка становлення професії у відповідності з кодексом етики;

7)       дотримання етичних норм у взаєминах між колегами;

8)       удосконалення кваліфікації розробників.

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

 

3.   Значення і вартість якості

Поняття "якість", насправді, не настільки очевидно і просто, як це може здатися на перший погляд. Для будь-якого інженерного продукту існує безліч інтерпретацій якості, залежно від конкретної «системи координат». Безліч цих точок зору необхідно обговорити і визначити на етапі вироблення вимог до програмного продукту. Характеристики якості можуть вимагатися в тому або іншому ступені, можуть бути відсутніми або можуть ставити певні вимоги, все це може бути результатом певного компромісу. Вартість якості (cost of quality) може бути диференційована на:

ü   вартість попередження <дефектів> (prevention cost);

ü   вартість оцінки (appraisal cost);

ü   вартість внутрішніх збоїв (internal failure cost);

ü   вартість зовнішніх збоїв (external failure cost);

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

Іноді, замовники не замислюються про питання якості і пов'язаної з ними вартості. Чи є характеристики якості чисто декоративними або, все ж таки, це невід'ємна частина програмного забезпечення? Відповідь, ймовірно, знаходиться десь посередині, як майже завжди буває в таких випадках, і є предметом обговорення ступеня залучення замовника в процес прийняття рішень і повного розуміння замовником вартості та вигоди, пов'язаної з досягненням того чи іншого рівня якості. В ідеальному випадку, більшість такого роду рішень повинно прийматися процесі роботи з вимогами, однак ці питання можуть підніматися протягом усього життєвого циклу програмного забезпечення. Не існує якихось "стандартних" правил того, як саме необхідно приймати такі рішення. Однак, інженери повинні бути здатні представити різні альтернативи (у досягненні різного рівня якості) і їх вартість.

 

 

Питання для самоконтролю:

1. Описати область знань «якість програмного забезпечення», виділити її основні проблеми.

2. Надати визначення поняттю якості та її атрибутам.

3. Описати основні принципи кодексу етики в інженерії програмного забезпечення.

4. Парадигма «вбудови» якості в інженерії програмного забезпечення (QFD).

5. Сертифікація програмного забезпечення в Україні.

6. Значення і вартість якості.