Технологія програмування в історичному аспекті

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ

Основні поняття і означення

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

Програма (program, routine) – впорядкована послідовність команд (інструкцій) комп’ютера для розв’язання задачі.

Програмне забезпечення (software) – сукупність програм обробки даних та необхідних для їх експлуатації документів.

Задача (problem, task) – проблема, яку необхідно розв’язати.

Додаток (application) – програмна реалізація розв’язку задачі на комп’ютері.

Термін «задача» в програмуванні означає одиницю роботи обчислювальної системи, яка вимагає обчислювальних ресурсів (процесорного часу, пам’яті).

Процес створення програм можна представити як послідовність наступних дій:

1) постановка задачі;

2) алгоритмізація розв’язку задачі;

3) програмування.

Постановка задачі (problem definition) – це точне формулювання розв’язку задачі на комп’ютері з описом вхідної та вихідної інформації.

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

Програмування (programming) – теоретична і практична діяльність, пов’язана зі створенням програм.

По відношенню до ПЗ користувачі ПК діляться на наступні групи:

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

2) прикладні програмісти. Виконують розробку і відладку програм для розв’язання різних прикладних задач;

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

4) адміністратори мережі. Відповідають за роботу обчислювальних мереж;

5) адміністратори баз даних. Забезпечують організаційну підтримку баз даних.

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

Основні характеристики програм:

1) алгоритмічна складність;

2) склад функцій оброки інформації;

3) об’єм файлів, які використовуються програмою;

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

Показники якості програми:

1) мобільність – незалежність від технічного комплексу системи обробки даних, ОС, мережених можливостей, специфіки предметної області задачі і т.д.;

2) надійність – стійкість, точність виконання передбачених функцій обробки, можливість діагностики помилок, які виникають в роботі програми;

3) ефективність, як з точки зору вимог користувача, так і з використання обчислювальних ресурсів;

4) врахування людського фактора – дружній інтерфейс, контекстно-залежна підказка, хороша документація;

5) модифікованість – здатність до внесення змін, наприклад, розширення функцій обробки, перехід на іншу базу обробки і т.п.;

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

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

Утилітарні програми («програми для себе») призначені для задоволення потреб їх розробників. Частіше всього такі програми виконують роль додатків для відладки, які є програмами для розв’язування задач, не призначених для широкого розповсюдження.

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

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

· freeware – безкоштовні програми, вільно розповсюджуються, підтримуються самим користувачем, який може вносити в них необхідні зміни;

· shareware некомерційні (умовно-безкоштовні) програми, які можуть використовуватись, як правило, безкоштовно.

Ряд виробників використовують ОЕМ-програми (Original Equipment Manufacturer), тобто вбудовані програми, які встановлюються на комп’ютер або постачаються разом з комп’ютерами.

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

Класифікація програмного забезпечення

Можна виділити три класи ПЗ:

1) системне;

2) пакети прикладних програм (прикладне ПЗ);

3) інструментарій технології програмування (інструментальні засоби для розробки ПЗ).

Системне ПЗ направлене:

· на створення операційного середовища функціонування інших програм;

· забезпечення надійної та ефективної роботи самого комп’ютера і обчислювальної мережі;

· проведення діагностики і профілактики апаратури комп’ютера і обчислювальних мереж;

· виконання допоміжних технологічних процесів (копіювання, архівація, відновлення файлів програм і БД і т.п.).

Системне ПЗ (System Software) – сукупність програм і програмних комплексів для забезпечення роботи комп’ютера і обчислювальних мереж.

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

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

Пакети прикладних програм

Класифікація пакетів прикладних програм (ППП)

Рис. 1.8. класифікація пакетів прикладних програм

 

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

· ППП автоматизованого бухгалтерського обліку;

· ППП фінансової діяльності;

· ППП управління персоналом;

· ППП управління виробництвом;

· банківські інформаційні системи і т.п.

Основні тенденції розвитку:

· створення програмних комплексів у вигляді автоматизованих робочих місць (АРМ) управлінського персоналу;

· створення інтегрованих систем управління предметної області на базі обчислювальних мереж, які об’єднують АРМ;

· організація даних великих інформаційних систем у вигляді розподіленої БД у мережі ЕОМ;

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

ППП автоматизованого проектування призначені для підтримки роботи конструкторів і технологів, пов’язаних з розробкою креслень, схем, графічним моделюванням і конструюванням. Особливими рисами цього класу ППП є великі вимоги до апаратного забезпечення, наявність бібліотек вбудованих функцій, об’єктів, інтерфейсів з графічними системами та БД (AutoCAD).

До ППП загального призначення належать:

1. Системи управління базами даних (СУБД), забезпечують організацію та зберігання локальних БД на автономних комп’ютерах або центральне зберігання БД на файл-сервері і мережений доступ до них. Сучасні СУБД (наприклад, MS Access) містять елементи CASE-технології процесу проектування, а саме:

· візуалізована схема БД;

· реалізована автоматизована підтримка цілісності БД при різних видах обробки (включення, видалення, модифікація);

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

· створені шаблони (прототипи) структур БД, звітів, форм і т.д.

2. Сервери БД – це ПЗ, яке призначене для створення і використання при роботі в мережі інтегрованих БД в архітектурі «клієнт-сервер». Багатокористувацькі СУБД в мереженому варіанті обробки інформації зберігають дані на файл-сервері, спеціально виділеному комп’ютері, але сама обробка ведеться на робочих станціях. Сервери БД більшу частину обробки даних (зберігання, пошук, передача даних клієнту) виконують самостійно, одночасно забезпечують даними велику кількість користувачів мережі. Спільним для різних видів серверів БД є використання реляційної мови програмування SQL (Structured Query Language) для реалізації запитів до даних. Проблеми: забезпечення цілісності даних, тиражування даних по вузлах мережі і синхронне оновлення.

3. Генератори звітів (сервери звітів), забезпечують реалізацію запитів і формування звітів у друкованому чи екранному вигляді в умовах мережі з архітектурою «клієнт-сервер». Сервер звітів підключається до сервера БД.

4. Текстові процесори, призначені для роботи з текстовими документами. Розвитком даного напряму є видавницькі системи (Microsoft Word).

5. Табличні процесори, є зручним середовищем для обчислень кінцевим користувачем, мають засоби ділової графіки, засоби спеціалізованої обробки (Microsoft Excel).

6. Засоби створення презентаційної графіки – спеціальні програми, призначені для створення слайдів та їх проектування, підготовки слайд-фільмів (Microsoft PowerPoint).

7. Інтегровані пакети набір декількох програмних продуктів, які доповнюють один одного функціонально, підтримують одну технологію, реалізовані на одній операційній та обчислювальній платформі (Microsoft Office). Компоненти інтегрованих пакетів можуть працювати ізольовано один від одного, мають спільний інтерфейс, завдяки чому їх легше освоювати.

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

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

· органайзери (планувальники) – ПЗ для планування робочого часу, складання протоколу зустрічей, розкладів, ведення записів та телефонної книжки. У склад входять: калькулятор, записна книжка, годинник, календар і т.д.

· програми перекладачі, засоби перевірки орфографії, розпізнавання тексту {Lingvo};

· комунікаційні пакети, призначені для організації взаємодії користувачів з віддаленими абонентами чи інформаційними ресурсами мережі;

· браузери, засоби створення Web-сторінок;

· засоби електронної пошти.

Настільні видавницькі системи. Цей клас ПЗ включає програми (PageMaker, CorelDraw, PhotoShop for Windows і т.д.), які забезпечують інформаційну технологію комп’ютерної видавницької діяльності:

· форматування та редагування тестів;

· автоматичну розбивку тексту на сторінки;

· комп’ютерну верстку друкованої сторінки;

· монтування графіки;

· підготовка ілюстрацій і т.п.

Програмні засоби мультимедіа. Основнепризначення цих програмних засобів – створення та використання аудіо- та відеоінформації для розширення інформаційного простору користувача (бібліотеки звукових та відео записів).

Системи штучного інтелекту:

· програми оболонки для створення експертних систем шляхом наповнення баз знань і правил логічного виводу;

· готові експертні системи для прийняття рішень в рамках визначених предметних областях;

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

Приклади систем штучного інтелекту: FIDE, MYSIN, Guru та ін.

Контрольні запитання

1. Основні характеристики програм.

2. Класифікація програмного забезпечення.

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

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

5. Дайте означення та охарактеризуйте інструментарій технології програмування.

Оцінка вартості помилок

Недавно ряд компаній провели дослідження оцінки вартості помилок, що виникають на різних етапах створення програм. Кожна фірма діяла незалежно, але результати були приблизно однакові: якщо вартість зусиль, необхідних для знаходження і виправлення помилок на стадії написання коду, прийняти за одиницю, то вартість знаходження і виправлення помилок на стадії розробки вимог буде в 5–10 разів менша, а вартість знаходження і виправлення помилок на стадії супроводження – в 20 разів більша.

 

0,1–0,2 Час розробки вимог

0,5 Проектування

1 Кодування

2 Тестування компонент

5 Впровадження

20 Підтримка і обслуговування

 

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

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

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

1. Повторна специфікація.

2. Повторне проектування.

3. Повторне кодування.

4. Повторне тестування.

5. Заміна замовлення – сповістити клієнтам та операторам про необхідність замінити дефектну версію виправленою.

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

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

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

9. Виплати по гарантійним зобов’язанням.

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

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

12. Створення документації.

 

Управління вимогами

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

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

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

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

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

 

Функції

Використання функцій – зручний спосіб описання можливостей без зайвих подробиць.

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

Рекомендована кількість функцій, яка дає повне представлення про систему, яка розробляється, 25–99, однак бажано, щоб їх число не перевищувало 50.

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

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

Атрибут	Описання/приклади значень функції
Статус	· Припущена · Затверджувана · Включена
Пріоритет/корисність	· Критична · Важлива · Корисна
Трудоємність	· Низький рівень · Середній рівень · Високий рівень
Ризик	Ймовірність того, що функція викличе небажані наслідки, такі як збільшення розходів, відставання від графіка чи навіть закриття проекту. · Високий · Середній · Низький
Стабільність	Ймовірність того, що дана функція буде мінятися чи буде мінятися її розуміння командою · Висока · Середня · Низька
Цільова версія	Вказування версії продукту, в якій вперше з’явиться реалізація даної функції
Призначення	Інформація для розробників
Обґрунтування	Посилання на джерело функції

 

Методи виявлення вимог:

· інтерв’ювання та анкетування;

· наради, присвячені вимогам;

· мозковий штурм та відбір ідей;

· розкадровки;

· прецеденти;

· обігравання ролей;

· створення прототипів.

Інтерв’ювання та анкетування. Інтерв’ю допомагає зрозуміти проблему, не впливаючи на відповіді користувача. Нижче наведені приклади конкретно-вільних запитань:

· чому існує проблема?

· як вона розв’язується в даний момент?

· як замовник хотів би її розв’язувати?

· хто такі користувачі?

· які навики користувачів в комп’ютерній області?

Після цього інтерв’ювер перераховує основні пункти, щоб перевірити, чи все було правильно зрозуміло: «Отже, ви сказали мені …» (перечислюються описані замовником проблеми словами). «Які ще проблеми вам надокучають?»

Правила підготовки інтерв’ю:

1. Всі запитання повинні біти складені наперед.

2. Перед інтерв’ю потрібно познайомитись з інформацією про клієнта.

3. Коротко записуйте відповіді.

Наради. Добре проведена нарада по питанням вимог має багато переваг:

· допомагає створити команду, підпорядковану одній цілі – успіху даного проекту;

· всі зацікавлені особи отримують можливість висказати свою думку, ніхто не залишається в стороні;

· формує згоду між зацікавленими особами і командою розробників по поводу того, що повинен робити додаток;

· може висвітлити і розв’язати політичні питання, які впливають на успіх проекту;

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

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

Мозковий штурм. Всі основні учасники збираються в одній кімнаті, їм роздаються матеріали для заміток – не менше 25 листків формату від 7×12 до 12×17.

Правила проведення мозкового штурму:

1. Не допускається критика чи дебати.

2. Дайте свободу фантазії.

3. Генеруйте як більше ідей.

4. Перероблюйте і комбінуйте ідеї.

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

Ідеї обов’язково записують на папір по наступним причинам:

1. Зберігається авторське формулювання.

2. Існує гарантія, що вони не будуть втрачені.

3. Є перспектива розвитку ідеї в подальшому.

4. Забезпечується неперервний творчий процес – не потрібно чекати, поки секретар записує думку учасника.

Розкадровка. Ціль розкадровки у ранньому виявленні реакції типу «так, але…». Існує три типа розкадровок.

1. Пасивні. Користувачу викладають деяку історію з використанням малюнків, схем, картинок з екрана.

2. Активні. Користувачу показують «ще не створений фільм» з використанням анімації чи слайдів.

3. Інтерактивні. Користувач отримує реальний досвід взаємодії з системою (майже так, як і на практиці).

Використання прецедентів. Малюються схеми з факторами; в овалі пишеться вид дії.

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

Також дуже ефективним способом є створення сценаріїв на основі CRC-карточок. Карточки описують об’єкт, його поведінку і взаємодію з іншими об’єктами системи. Учасники ділять карточки між собою і використовують їх для ролевої гри, виконуючи дії згідно передписаному. Ефективний спосіб для виявлення проблем проектування системи.

Прототипи вимог. Прототип вимог до ПЗ – це часткова реалізація системи, створена для того, щоб допомогти розробникам, користувачам і клієнтам точніше визначити вимоги до системи. Цей метод також допомагає розв’язати проблему «так, але…».

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

 

Серія стандартів ISO 9000

 

Однією з найважливіших проблем забезпечення якості програмних засобів є формалізація характеристик якості і методологія їх оцінки. Для визначення адекватності якості функціонування, наявності технічних можливостей програмних засобів до взаємодії, вдосконалення і розвитку необхідно використовувати стандарти в області оцінки характеристик їх якості. Основою регламентування показників якості програмних засобів раніше був міжнародний стандарт ISO 9126:1991 «Інформаційна технологія. Оцінка програмного продукту. Характеристики якості і керівництво по їх використанню». Завершується розробка і формалізований останній проект який складається з чотирьох частин стандарту ISO 9126–1 – ISO 9126–4 для заміни невеликої редакції 1991 р. Проект складається з чотирьох частин під загальним заголовком «Інформаційна технологія – характеристики і метрики якості програмного забезпечення»: «Частина 1. Характеристики і субхарактеристики якості»; «Частина 2. Зовнішні метрики якості»; «Частина 3. Внутрішні метрики якості»; «Частина 4. Метрики якості у використанні».

Перша частина стандарту – ISO 9126–1 – розподіляє атрибути якості програмних засобів по шести характеристикам, які використовуються у інших частинах стандарту. Виходячи з принципіальних можливостей їх зміни всі характеристики можуть бути об’єднані в три групи, до яких застосовні різні категорії метрик:

· категорійним чи описовим (номінальним) метрикам найбільш адекватні функціональні можливості програмних засобів;

· кількісні метрики застосовні для вимірювання надійності та ефективності складних комплексів програм;

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

У частині стандарту ISO 9126–1 даються означення з уточненнями з іших його частин для кожної характеристики програмного засобу, а також для субхарактеристик якості.

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

Друга і третя частини стандарту – ISO 9126–2 та ISO 9126–3, присвячені формалізації відповідно зовнішніх та внутрішніх метрик характеристик якості складних програмних засобів. Всі таблиці містять уніфіковану рубрикацію, де відображені ім’я і призначення метрики; метод її використання; спосіб вимірювання, тип шкали метрики; тип вимірюваної величини; початкові дані для вимірювання та порівняння; а також етапи життєвого циклу програмного засобу (по ISO 12207), до яких може бути використана метрика.

Четверта частина стандарту ISO 9126–4 – призначена для покупців, поставщиків, розробників, користувачів та менеджерів якості програмних засобів. В ній обґрунтовуються і коментуються виділені показники сфери (контексту) використання програмних засобів і групи вибраних метрик для користувачів.

 

Вибір показників якості

 

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

Процеси вибору і встановлення метрик і шкал для описання характеристик якості програмних засобів можна розділити на два етапи:

· вибір та обґрунтування набору початкових даних, які відображають загальні особливості та етапи життєвого циклу проекту програмного засобу та його користувачів, кожен з яких впливає на певні характеристики якості комплексу програм;

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

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

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

 

Оцінка якості

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

· встановлення початкових вимог для оцінки – визначення цілей випробувань, ідентифікація типу метрик програмного засобу, виділення адекватних показників і необхідних значень атрибутів якості;

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

· планування і проектування процесів оцінки характеристик та атрибутів якості в життєвому циклі програмного засобу;

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

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

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

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

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

Оцінка захищеності програмних засобів включає визначення повноти використання методів і засобів захисту програмного засобу від потенційних загроз і досягнутою при цьому безпеки функціонування інформаційної системи. Найбільш широко і детально методологічні і системні задачі оцінки комплексного захисту інформаційних систем викладені в трьох частинах стандарту ISO 15408:1999-1 – ISO 15408:1999-3 «Методи і засоби забезпечення безпеки. Критерії оцінки безпеки інформаційних технологій».

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

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

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

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

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

 

Система управління якістю

 

Вибір характеристик та оцінка якості програмних засобів – лише одна із задач в області забезпечення якості продукції. Комплексне розв’язання задач забезпечення якості програмних засобів припускає розробку та впровадження тої чи іншої системи управління якістю. У світовій практиці найбільше поширення отримала система, основана на міжнародних стандартах серії ISO 9000, яка включає більше десятка документів, у тому числі стандарт, який регламентує забезпечення якості ПЗ (ISO 9000/3).

Визначення характеристик і субхарактеристик якості (ISO 9126-1):

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

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

Правильність (коректність) – здатність програмного засобу забезпечувати правильні чи припустимі результати для користувача результати і зовнішні ефекти.

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

Захищеність – здатність компонент програмного засобу захищати програми та інформацію від будь-яких негативних впливів.

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