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

Міністерство освіти і науки України

Дніпропетровський технікум зварювання та електроніки ім.Е.О.Патона

 

 

 

 

 

Реферат

з предмету:

“Проектний практикум”

на тему:

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

 

 

Виконала:

 студентка гр.ПЗ-09-1/9

Набока В. О.

Викладач:

Саприкіна І. Г.

 

 

 

 

Зміст

 

Вступ

1 Культура і етика програмної  інженерії (Software Engineering Culture and Ethics)

2 Значення і вартість  якості (Value and Costs of Quality)

3 Моделі і характеристики  якості (Models and Quality Characteristics)

4 Підвищення якості (Quality Improvement)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Вступ

Згода, досягнута за вимогами до якості (в оригіналі - quality requirements), нарівні з чітким доведенням до інженерів того, що становить якість <одержуваного продукту>, вимагають обговорення і формального визначення багатьох аспектів якості.

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

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

 

1 Культура і  етика програмної інженерії (Software Engineering Culture and Ethics)

 

Очікується, що інженери з  програмного забезпечення сприймають питання якості програмного забезпечення як частину своєї <професійної> культури. SWEBOK дає посилання на джерела, що описують здорову культуру програмної інженерії.

Етичні аспекти можуть відігравати значну роль у забезпеченні якості програмного забезпечення, культурі та ставленні інженерів <до своєї  роботи>. IEEE Computer Society і ACM розробили кодекс етики ("моральний кодекс" - code of ethics) і професійної практики, заснований на восьми принципах, що допомагають інженерам зміцнити їх відношення до якості і незалежність <у вирішенні питань забезпечення гідної якості створюваних програмних продуктів> в їх повсякденному роботі.

 

2 Значення і  вартість якості (Value and Costs of Quality)

Поняття "якість", насправді, не настільки очевидно і просто, як це може здатися на перший погляд. Для будь-якого інженерного продукту існує безліч <інтерпретацій> якості, в залежності від конкретної "системи  координат" (в оригіналі - "перспективи"). Безліч цих точок зору необхідно  обговорити і визначити на етапі  вироблення вимог до програмного  продукту. Характеристики якості можуть вимагатися в тій чи іншій мірі, можуть бути відсутніми або можуть задавати певні вимоги, все це може бути результатом певного компромісу (що цілком перегукується з розумінням "прийнятної якості", як менш жорсткою точки зору на забезпечення якості, як досягнення досконалості).

Вартість якості (cost of quality) може бути диференційована на вартість попередження <дефектів> (prevention cost), вартість оцінки (appraisal cost), вартість внутрішніх (internal failure cost), а також зовнішніх збоїв (external failure cost).

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

 

3 Моделі і характеристики  якості (Models and Quality Characteristics)

У різних джерелах (таксономія і моделях) термінологія характеристик  якості програмного забезпечення відрізняється. Кожна модель включає різне число  рівнів ієрархії і загальне число <"розпізнаних"> характеристик якості. Різні автори створили різні моделі якості зі своїм  набором характеристик і атрибутів (зокрема, Баррі Боем, автор спіральної моделі життєвого циклу розробки програмного забезпечення, яка розглядається в окремій додатковій чолі). Ці моделі можуть бути корисні для обговорення, планування, (адаптації) і оцінки якості програмних продуктів. ISO / IEC визначає три пов'язаних моделі якості програмного забезпечення (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality Model) - внутрішня якість, зовнішнє якість і якість в процесі експлуатації, а також набір відповідних робіт з оцінки якості програмного забезпечення (ISO14598-98 Software Product Evaluation).

Управління якістю (software quality management) і якість процесів програмної інженерії (software engineering process quality) мають безпосереднє відношення до якості створюваного програмного продукту.

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

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

 

4 Підвищення якості (Quality Improvement)

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

До програмної інженерії  застосовні теорії і концепції, що лежать в основі вдосконалення якості. Наприклад, запобігання та рання діагностика  помилок, постійне вдосконалення (continuous improvement) і увага до вимог замовника (customer focus), складові принцип "building in quality". Ці концепції грунтуються на роботах експертів з якості, які прийшли до думки, що якість продукту безпосередньо пов'язане з якістю використовуваних для його створення процесів.

Такі підходи, як TQM (Total Quality Management - загальне управління якістю) PDCA (Plan, Do, Check, Act - Планування, Дія, Перевірка, Реакція / Коригування), є інструментами досягнення завдань, пов'язаних з якістю. Підтримка менеджменту допомагає у виконанні процесів, оцінці продуктів і отриманню всіх необхідних даних. Крім цього, розробляється програма вдосконалення (improvement program, зазвичай є цільовою і охоплює роботу підрозділу або організації, в цілому) детально ідентифікує всі дії і проекти з поліпшення <окремих аспектів діяльності> в рамках певного періоду часу, за який такі проекти можна здійснити з успішним рішенням відповідних завдань. При цьому, підтримка менеджменту означає, що всі проекти з поліпшення володіють достатніми ресурсами для досягненням поставлених цілей. Підтримка менеджменту тісно пов'язана з реалізацією активної взаємодії в колективі, і повинна попереджати виникнення потенційних проблем (і пасивного або навіть активної протидії реалізації програми вдосконалення або окремих її проектів). Формування робочих груп, підтримка менеджерів середньої ланки і виділені ресурси на рівні проекту - ці питання обговорюються в галузі знань "Процес програмної інженерії".

 

 

 

 

 

 

 

 

 

 

 

Список використананої  літератури:

1 Орлик C.,Булуй Ю. Введення у програмну інженерію і управління життєвим цикломПО:[електроннийресурс] >sorlik/swebok/3software_engineering.pdf - доступ вільний

2 Мацяшек Л. Аналіз вимог, і проектування систем. Розробка інформаційних систем з допомогоюUML. – М.: Вільямс, 2002