Система стандартизації, метрології та сертифікації на державному підприємстві "Сумистандартметрологія"

56

Размещено на http://www.allbest.ru/

1. МІЖНАРОДНІ СТАНДАРТИ ТА ЦИКЛИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

Велика частина стандартів створювалася як набір критеріїв для відбору постачальників програмного забезпечення для Міністерства оборони США, і це завдання вони вирішують досить успішно.

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

1.1 Процеси життєвого циклу програмної системи

Процеси життєвого циклу програмної системи.

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

ISSN 1028-9763. Математичні машини і системи, 2009, №3 Програми для обчислювальних машин зазвичай є компонентами програмно-апаратних комплексів або технічних систем. Програми та дані в системах і обчислювальних комплексах є найбільш гнучкими компонентами і схильні до змін протягом всього їх ЖЦ.

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

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

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

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

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

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

q визначення вимог;

q аналіз і проектування;

q розробка;

q випробування системи;

q тестування;

q виробництво;

q розповсюдження та продаж;

q експлуатація;

q супровід і моніторинг;

q зняття з експлуатації (утилізація).

1.2 Міжнародні стандарти та процеси життєвого циклу програмної системи

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

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

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

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

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

q ISO/IEC 12207:2008 System and software engineering - Software life cycle processes [2]. Розробка систем і програмного забезпечення - Процеси життєвого циклу програмного забезпечення. Стандарт визначає загальну структуру життєвого циклу ПЗ у вигляді трирівневої моделі, елементами якої є процеси, види діяльності, завдання. Процеси об'єднані в чотири групи: основні процеси, підтримують процеси, організаційні процеси, адаптація. Процеси складаються з окремих видів діяльності. Наприклад, процес розробки ПЗ включає такі види діяльності, як аналіз системних вимог, проектування програмно- апаратної частини системи в цілому, аналіз вимог до ПЗ, проектування архітектури ПЗ, кодування, тестування і т.д. Кожен вид діяльності спрямований на вирішення однієї або кількох завдань. Наприклад, такий вид діяльності, як розгортання процесу розробки, має вирішити наступні завдання: визначення структури життєвого циклу ПЗ, визначення моделі власне фази розробки ПЗ, вибір використовуваних стандартів, формування набору нормативно -методичних документів, визначення середовища розробки, функціонування та т.д.

q ISO/IEC 15288:2008 System and software engineering - System life cycle processes [3]. Розробка систем і програмного забезпечення - Процеси життєвого циклу систем. Стандарт націлений на розгляд програмно- апаратної системи в цілому. Пропонує схожу схему визначення структури життєвого циклу ПЗ у вигляді набору груп процесів, де кожен процес описується набором результатів, і кожен результат досягається за допомогою набору різних видів діяльності. Ефективність розробки ПЗ в цілому залежить від точності і коректності формулювання вимог до програмного продукту. Правила роботи з вимогами до ПО і більш загальними системними вимогами до програмно- апаратної системі в цілому визначаються наступними двома стандартами IEEE:

q IEEE 830-1998 Recommended practice for software requirements specifications [4]. Описує структуру документів для фіксації вимог до ПЗ, визначає характеристики, якими повинен володіти правильно складений набір вимог (коректність, однозначність, повнота, несуперечність, впорядкованість і т.д.).

q IEEE 1233-1998 Guide for developing system requirements specifications [5]. Описує правила побудови вимог для програмно -апаратних систем в цілому, визначає необхідні властивості й атрибути набору вимог. Розробка вимог включає визначення, організацію, уявлення і модифікацію вимог. Одним з найважливіших етапів в розробці програмного забезпечення є процес проектування архітектури ПЗ. Архітектура визначає більшість характеристик якості ПЗ в цілому і служить основним засобом спілкування між розробниками, а також між розробниками і всіма іншими особами, зацікавленими в даному ПЗ. Ряд стандартів регламентують опис архітектури, яке, в свою чергу, є основною складовою проектної документації на програмне забезпечення.

q IEEE 1016-1998 Recommended Practice for Software Design Descriptions [6]. Стандарт робить акцент на принципах побудови архітектури, а не на наборі структур, які лежать в її основі.

q ISO/IEC 42010 IEEE Std 1471-2000 System and software engineering - Recommended practice for architectural description of software - intensive systems [7].

q Архітектура може мати кілька уявлень, що відбивають структуру ПО з різних точок зору. Стандарт рекомендує для кожного подання фіксувати відображені в ньому погляди та інтереси, причини, що обумовлюють необхідність такого розгляду системи, невідповідності між елементами одного подання або між різними уявленнями, а також різну службову інформацію. Поняття якісного ПО відповідає уявленню про те, що програма досить успішно справляється з усіма покладеними на неї завданнями і не приносить проблем ні кінцевим користувачам, ні службі підтримки, ні фахівцям з продажу. На створення якісного ПЗ істотний вплив робить якість технологічних процесів його розробки. Загальні принципи забезпечення якості процесів виробництва в усіх галузях економіки регулюються набором стандартів серії ISO 9000. Найбільш важливі стандарти для розробки ПЗ в цьому наборі наступні:ISO 9001:2000 Quality management systems - Requirements [8].

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

q ISO/IEC 90003:2004 Software engineering - Guidelines for the application of ISO 9001:2000 to computer software [9]. Розробка програмного забезпечення - Керівні положення щодо застосування стандарту ISO 9001:2000 до програмного забезпечення. Цей стандарт конкретизує положення ISO 9001 для розробки програмного забезпечення з упором на забезпечення якості при процесі проектування. Він також визначає деякий набір технік і процедур, які рекомендується застосовувати для контролю і забезпечення якості розроблюваних програм.

q ISO/IEC TR 90005:2008 Software engineering - Guidelines for the application of ISO 9001:2000 to system life cycle processes [10]. Розробка програмного забезпечення - Керівні положення щодо застосування стандарту ISO 9001:2000 до процесів життєвого циклу програмних систем. Цей стандарт конкретизує положення щодо застосування ISO 9001:2000 для придбання, поставки, розробки, застосування та супроводження програмних систем. Він не додає і не змінює вимоги ISO 9001:2000. ISO/IEC TR 90005:2008 використовує ISO/IEC 15288 як відправну точку для формування вимог забезпечення якості при проектуванні програмних систем.

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

q Стандарт ISO 9126 пропонує використовувати для опису якості ПЗ багаторівневу модель показників якості. На верхньому рівні виділено 6 основних характеристик якості ПЗ. Кожна характеристика описується за допомогою набору атрибутів, що дозволяють оцінити цю характеристику. Для кожного атрибута визначається набір метрик, що дозволяють оцінити цей атрибут. Для кожної метрики визначається набір оціночних елементів, що дозволяють оцінити цю метрику. Побудова моделі якості дозволяє системно описати вимоги до програмного забезпечення, визначаючи, які властивості ПО по даній характеристиці хочуть бачити зацікавлені сторони. Показники якості, закріплені в стандартах, не вичерпують повністю поняття якості ПЗ. Залежно від призначення програмного забезпечення перелік показників якості може бути розширений або звужений в рамках проекту з розробки конкретного ПЗ.

q ISO/IEC 9126-1:2001 Software engineering - Product quality - Part 1: Quality model [11]. Визначає набір характеристик і атрибутів якості програмного забезпечення.

q ISO/IEC 9126-2:2003 Software engineering - Product quality - Part 2: External metrics [12].

q ISO/IEC 9126-3:2003 Software engineering - Product quality - Part 3: Internal metrics [13].

q ISO/IEC 9126-4:2004 Software engineering - Product quality - Part 4: Quality in use metrics[14].

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

q ISO/IEC 25051:2006 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for quality of Commercial Off -The- Shelf (COTS) software product and instructions for testing [15]. Розробка програмного забезпечення - Оцінка і вимоги якості до програмного забезпечення - Вимоги для якості готового комерційного програмного продукту та інструкцій для випробування. Визначає вимоги якості до програмних продуктів і до документації з тестування. Регламентує зміст документації з тестування, яка повинна включати план тестування, опис використовуваних методів тестування, опис наборів тестів і результатів тестування. Цей стандарт в 2006 році прийшов на зміну ISO/IEC 12119:1994.

q IEEE 829-1998 Standard for Software Test Documentation [16]. Описує базовий набір документів для тестування програмного забезпечення. Стандарт також визначає форму і зміст тестових документів.

q IEEE 829-2008 Standard for Software and System Test Documentation [17]. Стандарт застосовується до програмних систем.

q IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing [18]. Описує організацію модульного тестування.

Процесу оцінки характеристик якості готових програмних засобів та їх компонентів (програмних продуктів) на різних етапах життєвого циклу присвячений міжнародний стандарт ISO 14598, що складається з шести частин. Для кожної характеристики якості рекомендується формувати заходи і шкалу вимірювань з виділенням необхідних, допустимих і незадовільних значень. Реалізація процесів оцінки повинна корелювати з етапами життєвого циклу конкретного проекту програмного засобу відповідно до застосовуваної адаптованою версією стандарту ISO 12207.

q ISO/IEC 14598-1:1999 Information technology - Software product evaluation - Part1: General overview [19].

q ISO/IEC 14598-2:2000 Software engineering - Product evaluation - Part 2: Planning and management [20].

q ISO/IEC 14598-3:2000 Software engineering - Product evaluation - Part 3: Process for developers [21].

q ISO/IEC 14598-4:1999 Software engineering - Product evaluation - Part 4: Process for acquirers [22].

q ISO/IEC 14598-5:1998 Information technology - Software product evaluation - Part 5: Process for evaluators [23].

q ISO/IEC 14598-6:2001 Software engineering - Product evaluation - Part 6: Documentation of evaluation modules [24].

1.3 Стандартизація інженерії систем та програмних продуктів в Україні

Близько ста тисяч компаній світу працюють в галузі інженерії систем і програмних засобів [25, 26]. Стандартизацією діяльності користувачів і розробників інженерії систем і програмних засобів займається в світі близько 50 організацій [26].

В Україні для стандартизації інженерії систем і програмних засобів створено підкомітет "Інженерія програмування " (ПК- 7) Технічного комітету " Інформаційним технології" (ТК- 20). Базовою організацією ПК- 7 є Інститут пропрограмних систем Національної Академії Наук України (ІПС). В основу розвитку системи стандартизації інженерії програмного продукту покладено модельний підхід. В ІПС розроблені такі чотири групи моделей стандартизації програмування: конконцептуального, організаційно - орієнтовані, інструментально-орієнтовані, і моделі загальної орієнтації. Створені методики використання кожної групи моделей і методика їх комплексного використання.

Робота ПК - 7 орієнтована на результати міжнародної ІТ - стандартизації з урахуванням національної специфіки, в тому числі у розвитку програмної інженерії.

ПК - 7 заклав основи україномовної стандартної терміносистеми по програмної інженерії, у тому числі баз даних, якості програмного продукту і процесів програмування, оцінювання програмних засобів. Закладено основи сучасної системи стандартів документування комп'ютерних програм, ведеться розробка цієї системи впроваджена група стандартів з використання ІТ в інформаційній діяльності. Усього розроблено 60 нормативних документів [28-72]. Крім [35, 57, 58], національні стандарти гармонізовані з міжнародними стандартами КО.

1.3.1 Стандарти баз даних

До основоположних стандартів з розробки та функціонування баз даних відносяться стандарти [48-50], що визначають концепцію і термінологію для схем баз, еталонну модель керування даними, структуру систем словників інформаційних ресурсів. Стандарти [49, 50] є одночасно міждержавними.

Стандарт [48] встановлює рівень даних, засоби та інтерфейси інформаційної системи, словників інформаційних ресурсів, що використовуються для управління та документування інформаційних ресурсів предметних областей (ПрО). Словник інформаційних ресурсів як інфраструктура СУБД (систем управління базами даних) містить інформацію для одного або декількох застосувань.

Основні поняття і терміни концептуальних схем та інформаційних баз, що охоплюють розробку, опис та застосування концептуальних схем і інформаційних баз, маніпулювання даними, а також опис і реалізацію обробки даних, описані в [49]. У стандарті концептуальна схема розглядається як несуперечлива сукупність припущень, що виражають висловлювання, які стосуються ПрО. Положення стандарту можна використовувати для оцінки СУБД. Стандарт [50] встановлює еталонну модель управління даними. Еталонна модель визначає загальну термінологію і поняття, що відносяться до даних інформаційних систем. Такі поняття використовуються для визначення послуг, які надаються СУБД або системами словників даних.

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

1.3.2 Стандартизація якості програмних продуктів

Якість програмних засобів, процесів програмування і вимірювання програмних засобів стандартизовані в [56 - 67]. Зокрема встановлені: перелік показників якості, рівень оцінювання якості програмних засобів (до закінчення їх розробки, поза процесом використання, в процесі використання), а також розпочато перехід до кількісного методу оцінювання програмних засобів. Перелік з шести характеристик якості програмних засобів встановлено у стандарті [52] : функціональність, надійність, зручність використання, ефективність, сопроводімость, мобільність. Цим припинений хаос в розумінні того, що має лягти в основу визначення якості програмних засобів. Першими національними стандартами за якістю і випробуванням стали стандарти [52-55]. Введений в дію стандарт [63] встановив вимоги до виміру та оцінювання якості програмного продукту, зокрема вимоги до оцінювання програмного продукту окремо розробником, замовником, оцінювачем. У стандарті [62] оцінені дії і завдання, які вирішуються в процесі вимірювання, а в [65] Установлюються детальні процедури і принципи вимірювання та рейтингового оцінювання.

Стандарт [62] (в 9 - ти частинах) встановив підхід до оцінювання процесів життєвого циклу програмних засобів організацією або в інтересах організації для усвідомлення стану власних процесів в цілях їх вдосконалення, визначення відповідності власних процесів встановленим вимогам або класу вимог, визначення придатності процесів іншої організації для конкретного контракту або класу контрактів. Цей стандарт розглядають і як модель зрілості організації. Його розробці передував ряд моделей зрілості, тому в стандарті впорядковані аспекти діяльності при визначенні зрілості підприємств.

Стандарт [67] містить керівництво щодо виконання вимог до систем управління якістю, пов'язаних з програмним забезпеченням. Стандарти [62, 67] можна використовуватися при сертифікації систем якості, а решта - при сертифікації програмної продукції.

1.3.3 Стандартизація документування програм

Зараз функціонує вісім національних стандартів, що регламентують питання документування програм [51, 54, 57, 61, 63, 68-70]. Загальні питання документування програм розглянуті в [51]. У цьому стандарті процес документування віднесений до процесів підтримки життэвого циклу і визначений як фіксація інформації, створюваної в рамках життєвого циклу при виконанні переліку дій, пов'язаних з плануванням, проектуванням, розробкою, випуском, редагуванням, розповсюдженням і супроводом документів. Також встановлено перелік завдань, з яких складаються дії.

Стандарт [57] містить вимоги до документування випробувань. У інструкції з документування комп'ютерних програм [68] викладено новий профільний підхід, в основу якого покладено профіль документування - таблиці одиниць інформації, що описують зміст документів у процесах життєвого циклу програмного продукту.

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

У стандарті [69] визначено процес створення всіх видів документації користувача. Важливе місце займає план документування. Увага акцентована на документації користувача як паперової, так і електронної.

У стандарті [61] встановлено вимоги до опису продукту, документації користувача та інструкції для тестування, а в [63] визначені схема й змісту документації, необхідної для опису модуля оцінювання, використовуваного експертами з методології вимірювань.

У стандарті [71] визначено мінімальний набір понять і позначень для сприйняття людиною переходу станів програмного засобу, в [49] - вимоги до документування процесу супроводу програмного продукту, також передбачено створення інформації супроводу при її відсутності, як частина поліпшуючого супроводу.

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

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

Розрізняються поняття внутрішньої якості, пов'язаного з характеристиками ПЗ самого по собі, без урахування його поведінки; зовнішньої якості, що характеризує ПЗ із точки зору його поведінки; і якості ПЗ при використанні у різних контекстах - тої якості, що відчувається користувачами при конкретних сценаріях роботи ПЗ. Для всіх цих аспектів якості уведені метрики, що дозволяють оцінити їх. Крім того, для створення добротного ПЗ істотно якість технологічних процесів його розробки. Взаємини між цими аспектами якості за схемою, прийнятою ISO 9126, показане на (рис. 1).

Рисунок 1 -- Основні аспекти якості ПЗ за ISO 9126

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

q ISO 9000:2000 Quality management systems - Fundamentals and vocabulary. Системи керування якістю - Основи й словник. (Аналог - ДЕРЖСТАНДАРТ Р-2001).

q ISO 9001:2000 Quality management systems - Requirements. Models for quality assurance in design, development, production, installation, and servicing. Системи керування якістю - Вимоги. Моделі для забезпечення якості при проектуванні, розробці, комерціалізації, установці та обслуговуванні. Визначає загальні правила забезпечення якості результатів у всіх процесах життєвого циклу. (Аналог - ДЕРЖСТАНДАРТ Р-2001).

q Цей стандарт виділяє наступні процеси:

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

§ Управління ресурсами

§ Розвиток системи управління

§ Дослідження ринку

§ Проектування продуктів

§ Придбання

§ Виробництво

§ Надання послуг

§ Захист продуктів

§ Оцінка потреб замовників

§ Підтримка комунікацій із замовниками.

§ Підтримка внутрішніх комунікацій

§ Управління документацією

§ Ведення записів про діяльність.

§ Планування

§ Навчання персоналу

§ Внутрішні аудити

§ Оцінки управління

§ Моніторинг і виміри

§ Управління невідповідностями

§ Постійне вдосконалювання

§ Управління та розвиток системи в цілому.

q Для кожного процесу потрібно мати плани розвитку процесу, що складаються як мінімум з наступних розділів: Проектування процесу

§ Документування процесу

§ Реалізація процесу

§ Підтримка процесу

§ Моніторинг процесу

§ Управління процесом

§ Удосконалення процесу

q Крім підтримки й розвитку системи процесів, націлених на задоволення потреб замовників і користувачів, ISO 9001 вимагає:

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

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

§ Забезпечити використання якісних ресурсів, якісного (компетентного, професійного) персоналу, якісної інфраструктури і якісного оточення

§ Постійно контролювати дотримання вимог до якості на практиці, у всіх процесах проектування, виробництва, надання послуг і при придбаннях

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

Стандарти, що використовувалися раніше, ISO 9002:1994 Quality systems - Model for quality assurance in production, installation and servicing і ISO 9003:1994 Quality systems - Model for quality assurance in final inspection and test в 2000 році були замінені відповідними ним частинами ISO 9001.

q ISO 9004:2000 Quality management systems - Guidelines for performance improvements . Системи керування якістю. Посібник з поліпшення діяльності. (Аналог - ДЕРЖСТАНДАРТ Р-2001).

q ISO/IEC 90003:2004 Software engineering - Guidelines for the application of ISO 9001:2000 to computer software . Керівні положення щодо застосування стандарту ISO 9001 при розробці, поставці й обслуговуванні програмного забезпечення.

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

Стандарт ISO 9126 пропонує використовувати для опису внутрішнього та зовнішнього якості ПЗ багаторівневу модель. На верхньому рівні виділено 6 основних характеристик якості ПО. Кожна характеристика описується за допомогою кількох вхідних у неї атрибутів. Для кожного атрибута визначається набір метрик, що дозволяють його оцінити. Множина характеристик і атрибутів якості згідно ISO 9126 показана на (рис. 2).

Рисунок 2 -- Характеристики й атрибути якості ПЗ по ISO 9126

Нижче наведені визначення цих характеристик і атрибутів за стандартом ISO 9126:2001:

q Функціональність (functionality) - здатність ПЗ в певних умовах вирішувати задачі, потрібні користувачам. Визначає, що саме робить ПЗ, які задачі воно вирішує

§ Функціональна придатність (suitability). Здатність вирішувати потрібний набір задач

§ Точність (accuracy). Здатність видавати потрібні результати

§ Здатність до взаємодії (interoperability). Здатність взаємодіяти з потрібним набором інших систем

§ Відповідність стандартам і правилам (compliance). Відповідність ПЗ наявних індустріальних стандартах, нормативним і законодавчим актам, іншим регулюючим нормам

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

§ Надійність (reliability). Здатність ПЗ підтримувати визначену працездатність у заданих умовах

§ Зрілість, завершеність (maturity). Величина, зворотна частоті відмов ПЗ. Звичайно виміряється середнім часом роботи без збоїв і величиною, зворотною імовірності виникнення відмови за даний період часу

§ Стійкість до відмов (fault tolerance). Здатність підтримувати заданий рівень працездатності при відмовах і порушеннях правил взаємодії з оточенням

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

§ Відповідність стандартам надійності (reliability compliance). Цей атрибут доданий в 2001 році

q Зручність використання (usability) або практичність. Здатність ПЗ бути зручним у навчанні та використанні, а також привабливим для користувачів

§ Зрозумілість (understandability). Показник, зворотний до зусиль, які затрачаються користувачами на сприйняття основних понять ПЗ та усвідомлення їх застосовності для розв'язання своїх задач.

§ Зручність навчання (learnability). Показник, зворотний зусиллям, затрачуваним користувачами на навчання роботі з ПЗ.

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

§ Привабливість (attractiveness). Здатність ПЗ бути привабливим для користувачів. Цей атрибут доданий в 2001 році.

§ Відповідність стандартам зручності використання (usability compliance). Цей атрибут доданий в 2001 році.

q Продуктивність (efficiency) або ефективність. Здатність ПЗ при заданих умовах забезпечувати необхідну працездатність стосовно виділюваного для цього ресурсам. Можна визначити її і як відношення одержуваних за допомогою ПЗ результатів до затрачуваних на це ресурсів усіх типів.

§ Часова ефективність (time behaviour). Здатність ПЗ видавати очікувані результати, а також забезпечувати передачу необхідного об'єму даних за відведений час

§ Ефективність використання ресурсів (resource utilisation). Здатність вирішувати потрібні задачі з використанням визначених об'ємів ресурсів визначених видів. Маються на увазі такі ресурси, як оперативна й довгострокова пам'ять, мережні з'єднання, пристрої вводу та виводу та ін.

§ Відповідність стандартам продуктивності (efficiency compliance). Цей атрибут доданий в 2001 році

q Зручність супроводу (maintainability). Зручність проведення всіх видів діяльності, пов'язаних із супроводом програм

§ Аналізованість (analyzability) або зручність проведення аналізу. Зручність проведення аналізу помилок, дефектів і недоліків, а також зручність аналізу необхідності змін і їх можливих наслідків

§ Зручність внесення змін (changeability). Показник, зворотний трудозатратам на виконання необхідних змін

§ Стабільність (stability). Показник, зворотний ризику виникнення несподіваних ефектів при внесенні необхідних змін

§ Зручність перевірки (testability). Показник, зворотний трудозатратам на проведення тестування і інших видів перевірки того, що внесені зміни привели до потрібних результатів

§ Відповідність стандартам зручності супроводу (maintainability compliance). Цей атрибут доданий в 2001 році

q Переносимість (portability). Здатність ПЗ зберігати працездатність при перенесенні з одного оточення в інше, включаючи організаційні, апаратні й програмні аспекти оточення. Іноді ця характеристика називається у нашій літературі мобільністю. Однак термін "мобільність" варто зарезервувати для перекладу "mobility" - здатності ПЗ й комп'ютерної системи в цілому зберігати працездатність при її фізичному переміщенні в просторі.

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

§ Зручність установки (installability). Здатність ПЗ бути встановленим або розгорнутим у визначеному оточенні

§ Здатність до співіснування (coexistence). Здатність ПЗ співіснувати з іншими програмами у загальному оточенні, ділячи з ними ресурси

§ Зручність заміни (replaceability) іншого ПЗ даним. Можливість застосування даного ПЗ замість інших програмних систем для вирішення тих же задач у певному оточенні

§ Відповідність стандартам переносимості (portability compliance). Цей атрибут доданий в 2001 році

Перераховані атрибути належать до внутрішньої та зовнішньої якості ПЗ згідно ISO 9126. Для опису якості ПО при використанні стандарт ISO 9126-4 пропонує іншій, більш вузький набір характеристик:

q Ефективність (effectiveness). Здатність ПЗ надавати користувачам можливість вирішувати їхньої задачі з необхідною точністю при використанні в заданому контексті.

q Продуктивність (productivity). Здатність ПЗ надавати користувачам визначені результати в рамках очікуваних витрат ресурсів.

q Безпека (safety). Здатність ПЗ забезпечувати необхідно низький рівень ризику завдання втрат життю й здоров'ю людей, бізнесу, власності або навколишньому середовищу.

q Задоволення користувачів (satisfaction). Здатність ПЗ приносити задоволення користувачам при використанні в заданому контексті.

Крім перерахованих характеристик і атрибутів якості, стандарт ISO 9126:2001 визначає набори метрик для оцінки кожного атрибута. Наведемо наступні приклади таких метрик:

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

q Коректність реалізації функцій - правильність їх реалізації по відношенню до вимог. Використовується для виміру функціональної придатності.

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

q Відношення числа проведених тестів до загального їх числа. Використовується для визначення зрілості.

q Відношення числа доступних проектних документів до зазначеного в їх списку. Використовується для виміру зручності проведення аналізу.

q Наочність і повнота документації Використовується для оцінки зрозумілості.

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

q Що ПЗ має робити, наприклад:

§ дозволяти клієнтові оформити замовлення й забезпечити їхню доставку;

§ забезпечувати контроль якості будівництва й відслідковувати проблемні місця;

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

q Наскільки воно має бути надійним, наприклад:

§ працювати 7 днів у тиждень і 24 години на добу;

§ допускається непрацездатність протягом не більше 3 годин у рік;

§ ніякі уведені користувачами дані при відмові не повинні губитися.

q Наскільки ним має бути зручно користуватися, наприклад:

§ покупець повинен, знаючи назву товару й маючи середні навички роботи в Інтернет, знаходити потрібний йому товар за не більш ніж 2 хв.;

§ інженер за фахом "будівництво мостів" повинен протягом одного дня вміти розібратися в 80% функцій системи.

q Наскільки воно повинне бути ефективним, наприклад:

§ підтримувати обслуговування до 10000 запитів у секунду;

§ час відгуку на запит при максимальному завантаженні не повинне перевищувати 3 с;

§ час реакції на зміну параметрів процесу виробництва не повинне перевищувати 0.1 з;

§ на обробку одного запиту не повинне витрачатися більше 1 MB оперативної пам'яті.

q Наскільки зручним повинен бути його супровід, наприклад:

§ додавання в систему нового виду запитів не повинне вимагати більше 3 людино-днів;

§ додавання підтримки нового етапу процесу виробництва не повинне коштувати більше $20000.

q Наскільки воно повинне бути стерпне, наприклад:

§ ПЗ повинне працювати на операційних системах Linux, Windows XP і MacOS X;

§ ПЗ повинне працювати з документами у форматах MS Word і HTML;

§ ПЗ повинне зберігати файли звітів у форматах MS Word 20**, MS Excel 20**, HTML, RTF та у вигляді звичайного тексту;

§ ПЗ повинне сполучатися з існуючою системою запису даних про замовлення.

Наведені атрибути якості закріплені в стандартах, але це не означає, що вони цілком вичерпують поняття якості ПЗ. Так, у стандарті ISO 9126 відсутні характеристики, пов'язані з мобільністю ПЗ (mobility), тобто здатністю програми працювати при фізичних переміщеннях машини, на якій вона працює. Замість надійності багато дослідників воліють розглядати більш загальне поняття добротності (dependability), що описує здатність ПЗ підтримувати визначені показники якості за основними характеристиками ( функціональності, продуктивності, зручності використання) із заданими ймовірностями виходу за їх рамки та визначеним максимальним збитком від можливих порушень. Крім того, активно досліджуються поняття зручності використання, безпеці й захищеності ПЗ, - вони здаються більшості фахівців набагато більш складними, ніж це описується даним стандартом.

1.5 Методи контролю якості

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

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

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

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

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

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

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

q Методи й техніки визначення показників якості на основі симуляції роботи ПЗ за допомогою моделей різного роду. До цього виду належать перевірка на моделях (model checking), а також прототипування (макетування), використовуване для оцінки якості прийнятих рішень.

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

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

1.5.1 Тестування

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

Тестування - кінцева процедура. Набір ситуацій, у яких буде перевірятися тестоване ПЗ, завжди кінцевий. Більш того, він повинен бути настільки малий, щоб тестування можна було провести в рамках проекту розробки ПЗ, не занадто збільшуючи його бюджет і терміни. Це означає, що при тестуванні завжди перевіряється дуже невелика частка всіх можливих ситуацій. З цього приводу Дейкстра (Dijkstra) помітив, що тестування дозволяє точно визначити, що в програмі є помилка, але не дозволяє стверджувати, що там немає помилок.

Однак, тестування може використовуватися для досить упевненого винесення оцінок про якості ПЗ. Для цього необхідно мати критерії повноти тестування, що описують важливість різних ситуацій для оцінки якості, а також еквівалентності й залежності між ними. Цей критерій може стверджувати, що байдуже в який із ситуацій, A або B, перевіряти правильність роботи ПЗ, або, якщо програма правильно працює в ситуації A, то, швидше за все, у ситуації B усе теж буде правильно. Часто критерій повноти тестування задається за допомогою визначення еквівалентності ситуацій, що дає кінцевий набір класів ситуацій. У цьому випадку вважають, що байдуже, яку із ситуацій одного класу використовувати як тест. Такий критерій називають критерієм тестового покриття, а відсоток класів еквівалентності ситуацій, що трапились під час тестування, досягнутим тестовим покриттям.

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



Рисунок 3 -- Схема процесу тестування

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

Організація тестування ПО регулюється наступними стандартами:

q IEEE 829-1998 Standard for Software Test Documentation. Описує види документів, що слугують для підготовки тестів

q IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing. Описує організацію модульного тестування (див. нижче).

q ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 і ДЕРЖСТАНДАРТ Р-2000, також прийнятий IEEE під номером IEEE 1465-1998) Information Technology. Software packages - Quality requirements and testing. Описує вимоги до процедур тестування програмних систем.

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

На основі вихідних даних, використовуваних для побудови тестів, тестування поділяють на наступні види:

q Тестування чорної скриньки, націлене на перевірку вимог. Тести для нього й критерій повноти тестування будуються на основі вимог і обмежень, чітко зафіксованих у специфікаціях, стандартах, внутрішніх нормативних документах. Часто таке тестування називається тестуванням на відповідність (conformance testing). Частиною його є функціональне тестування - тести для нього, а також використовувані критерії повноти проведеного тестування визначають на основі вимог до функціональності. Ще одним прикладом тестування на відповідність є атестаційне або кваліфікаційне тестування, по результатам якого програмна система одержує (або не одержує) офіційний документ, що підтверджує її відповідність певним вимогам і стандартам

q Тестування білої скриньки, воно ж структурне тестування - тести створюються на основі знань про структуру самої системи та про те, як вона працює. Критерії повноти засновані на відсотку елементів коду, які відпрацювали в ході виконання тестів. Для оцінки ступеня відповідності вимогам можуть залучатися додаткові знання про зв'язок вимог з визначеними обмеженнями на значення внутрішніх дані системи (наприклад, на значення параметрів викликів, результатів і локальних змінних).

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

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

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

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

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

q Системне тестування (system testing) призначено для перевірки правильності роботи системи в цілому, її здатності правильно вирішувати поставлені користувачами задачі в різних ситуаціях. Системне тестування виконується через зовнішні інтерфейси ПЗ та тісно пов'язане з тестуванням користувацького інтерфейсу (або через користувацький інтерфейс), проведеним за допомогою імітації дій користувачів над елементами цього інтерфейсу. Окремими випадками цього виду тестування є тестування графічного користувацького інтерфейсу (Graphical User Interface, GUI) і користувацького інтерфейсу Web-додатків (WebUI).

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

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

1.5.2 Перевірка на моделях

Перевірка властивостей на моделях (model checking) - перевірка відповідності ПЗ вимогах за допомогою формалізації властивостей, що перевіряються, побудови формальних моделей контрольованого ПЗ (найчастіше в вигляді автоматів різних видів) і автоматичної перевірки виконання цих властивостей на побудованих моделях. Перевірка властивостей на моделях дозволяє перевіряти досить складні властивості автоматично, при мінімальній участі людини. Однак вона залишає відкритим питання про те, наскільки виявлені властивості моделі можна переносити на саме ПЗ. Схема процесу перевірки властивостей ПО на моделях (рис. 4).



Рисунок 4-- Схема процесу перевірки властивостей ПО на моделях

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

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