10

До чого шукаю так славу я?

Відомо, в славі немає блаженства

Але хоче все душа моя

У всьому дійти до досконалості.

М.Ю. Лермонтов

Лекція 12. Забезпечення якості програмного засобу

Загальний огляд. Реалізація призначеного для користувача інтерфейсу і забезпечення легкості застосування програмного засобу. Забезпечення ефективності програмного засобу. Забезпечення сопровождаемости і управління конфігурацією програмного засобу. Апаратно-операційні платформи і забезпечення мобільності програмного засобу.

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

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

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

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

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

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

12.2. Забезпечення легкості застосування програмного засобу.

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

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

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

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

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

Через велику різноманітність користувачів і види ПС існує безліч різних стилів призначених для користувача інтерфейсів, при розробці яких можуть використовуватися різні принципи і підходи. Проте наступні найважливіші принципи слід дотримувати завжди [12.1]:

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

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

• призначений для користувача інтерфейс повинен дозволяти користувачеві виправляти власні помилки;

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

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

Командний призначений для користувача інтерфейс надає користувачеві можливість звертатися до ПС з деяким завданням (запитом), що представляється деяким текстом (командою) на спеціальній командній мові (мові завдань). Достоїнствами такого інтерфейсу є можливість його реалізації на дешевих алфавітно-цифрових терміналах і можливість мінімізації потрібного від користувача введення з клавіатури. Недоліками такого інтерфейсу є необхідність вивчення командної мови і достатньо велика вірогідність помилки користувача при завданні команди. У зв'язку з цим командний призначений для користувача інтерфейс зазвичай вибирають тільки досвідчені користувачі. Такий інтерфейс дозволяє їм здійснювати швидку взаємодію з комп'ютером і надає можливість об'єднувати команди в процедури і програми (див. наприклад, мова Shell операційної системи Unix [12.2]).

Графічний призначений для користувача інтерфейс надає користувачеві можливості:

• звертатися до ПС шляхом вибору на екрані відповідного графічного або текстового об'єкту

• отримувати від ПС інформацію на екрані у вигляді графічних і текстових об'єктів

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

Графічний призначений для користувача інтерфейс дозволяє

• розміщувати на екрані безліч різних вікон, в які можна виводити інформацію незалежно;

• використовувати графічні об'єкти, звані піктограмами (або іконами), для позначення різних інформаційних об'єктів або процесів;

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

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