ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.11.2019
Просмотров: 365
Скачиваний: 1
До чого шукаю так славу я?
Відомо, в славі немає блаженства
Але хоче все душа моя
У всьому дійти до досконалості.
М.Ю. Лермонтов
Лекція 12.
ЗАБЕЗПЕЧЕННЯ ЯКОСТІ ПРОГРАМНОГО ЗАСОБУ
Загальний огляд. Реалізація призначеного для користувача інтерфейсу і забезпечення легкості застосування програмного засобу. Забезпечення ефективності програмного засобу. Забезпечення сопровождаемости і управління конфігурацією програмного засобу. Апаратно-операційні платформи і забезпечення мобільності програмного засобу.
12.1. Загальна характеристика процесу забезпечення якості програмного засобу.
Як вже наголошувалося в лекції 4, специфікація якості визначає основні орієнтири (цілі), які на всіх етапах розробки ПС так чи інакше впливають при ухваленні різних рішень на вибір відповідного варіанту. Проте кожен примітив якості має свої особливості такого впливу, тим самим, забезпечення його наявності в ПС може зажадати своїх підходів і методів розробки ПС або окремих його частин. Крім того, вже наголошувалася раніше суперечність критеріїв якості ПС, а також і примітивів якості, що виражають їх: хороше забезпечення одне якого-небудь примітиву якості ПС може істотно утруднити або зробити неможливим забезпечення деяких інших з цих примітивів. Тому істотна частина процесу забезпечення якості ПС складається з пошуку прийнятних компромісів. Ці компроміси частково повинні бути визначені вже в специфікації якості ПС: модель якості ПС повинна конкретизувати необхідний ступінь присутності в ПС кожного його примітиву якості і визначати пріоритети досягнення цих ступенів.
Забезпечення якості здійснюється в кожному технологічному процесі: ухвалені в нім рішення в тому або іншому ступені роблять вплив на якість ПС в цілому. Зокрема і тому, що значна частина примітивів якості зв'язана не стільки з властивостями програм, що входять в ПС, скільки з властивостями документації. Через відмічену суперечність примітивів якості вельми важливо дотримуватися вибраних пріоритетів в їх забезпеченні. При цьому слід дотримуватися двох загальних принципів:
-
спочатку необхідно забезпечити необхідну функціональність і надійність ПС, а потім вже доводити решту критеріїв якості до прийнятного рівня їх присутності в ПС;
-
немає ніякої необхідності і, можливо, навіть шкідливо добиватися більш високого рівня присутності в ПС якого-небудь примітиву якості, ніж той, який визначений в специфікації якості ПС.
Забезпечення функціональності і надійності ПС було розглянуте в попередній лекції. Нижче обговорюється забезпечення інших критеріїв якості ПС.
12.2. Забезпечення легкості застосування програмного засобу.
Легкість застосування, в значній мірі, визначається складом і якістю призначеної для користувача документації, а також деякими властивостями, що реалізовуються програмним шляхом.
З призначеною для користувача документацією пов'язані такі примітиви якості ПС, як П-документірованность і інформативність. Забезпеченням її якості займаються зазвичай технічні письменники. Це питання обговорюватиметься в наступній лекції. Тут лише слід відмітити, що там мова йтиме про автономну по відношенню до програм документацію. У зв'язку з цим слід звернути увагу на широко використовуваний в даний час підхід інформування користувача в інтерактивному режимі (в процесі застосування програм ПС). Таке інформування у багатьох випадках виявляється зручнішим для користувача, чим за допомогою автономної документації, оскільки дозволяє користувачеві без якого-небудь пошуку викликати необхідну інформацію за рахунок використання контексту її виклику. Такий підхід до інформування користувача є вельми перспективним.
Програмним шляхом реалізуються такі примітиви якості ПС як комунікабельність, стійкість і захищеність. Забезпечення стійкості і захищеності вже було розглянуте в попередній лекції. Комунікабельність забезпечується відповідною реалізацією обробки виняткових ситуацій і створенням відповідного призначеного для користувача інтерфейсу.
Збудження виняткової ситуації у багатьох випадках означає, що виникла необхідність інформувати користувача про хід виконання програми. При цьому видавана користувачеві інформація повинна бути простій для розуміння (див. лекцію 4). Проте виняткові ситуації виникають зазвичай на достатньо низькому рівні модульної структури програми, а створити зрозуміле для користувача повідомлення можна, як правило, на вищих рівнях цієї структури, де відомий контекст, в якому були активізовані дії, що привели до виникнення виняткової ситуації. Обробку виняткових ситуацій усередині модуля ми вже обговорювали в лекції 8. Для обробки виниклої виняткової ситуації в іншому модулі доводиться ухвалювати не прості рішення. Вживаний часто спосіб передачі інформації про виниклу виняткову ситуацію по ланцюжку звернень до програмних модулів (у зворотному напрямі) є ваговитим: він вимагає додаткових перевірок після повернення з модуля і часто ускладнює само звернення до цих модулів за рахунок завдання додаткових параметрів. Прийнятним рішенням є включення в операційне середовище виконання програм (у виконавчу підтримку) можливостей прямої передачі цій інформації обробникам виняткових ситуацій по динамічно формованій черзі таких обробників.
Призначений для користувача інтерфейс представляє засіб взаємодії користувача з ПС. При розробці призначеного для користувача інтерфейсу слід враховувати потреби, досвід і здібності користувача [12.1]. Тому потенційні користувачі повинні бути залучені в процес розробки такого інтерфейсу. Великий ефект тут дає його прототипирование. При цьому користувачі повинні дістати доступ до прототипів призначеного для користувача інтерфейсу, а їх оцінка різних можливостей використовуваного прототипу повинна істотно враховуватися при створенні остаточного варіанту призначеного для користувача інтерфейсу.
Через велику різноманітність користувачів і види ПС існує безліч різних стилів призначених для користувача інтерфейсів, при розробці яких можуть використовуватися різні принципи і підходи. Проте наступні найважливіші принципи слід дотримувати завжди [12.1]:
-
призначений для користувача інтерфейс повинен базуватися на термінах і поняттях, знайомих користувачеві;
-
призначений для користувача інтерфейс повинен бути одноманітним;
-
призначений для користувача інтерфейс повинен дозволяти користувачеві виправляти власні помилки;
-
призначений для користувача інтерфейс повинен дозволяти отримання користувачем довідкової інформації: як по його запиту, так і ПС, що генерується.
В даний час широко поширені командні і графічні призначені для користувача інтерфейси.
Командний призначений для користувача інтерфейс надає користувачеві можливість звертатися до ПС з деяким завданням (запитом), що представляється деяким текстом (командою) на спеціальній командній мові (мові завдань). Достоїнствами такого інтерфейсу є можливість його реалізації на дешевих алфавітно-цифрових терміналах і можливість мінімізації потрібного від користувача введення з клавіатури. Недоліками такого інтерфейсу є необхідність вивчення командної мови і достатньо велика вірогідність помилки користувача при завданні команди. У зв'язку з цим командний призначений для користувача інтерфейс зазвичай вибирають тільки досвідчені користувачі. Такий інтерфейс дозволяє їм здійснювати швидку взаємодію з комп'ютером і надає можливість об'єднувати команди в процедури і програми (див. наприклад, мова Shell операційної системи Unix [12.2]).
Графічний призначений для користувача інтерфейс надає користувачеві можливості:
-
звертатися до ПС шляхом вибору на екрані відповідного графічного або текстового об'єкту
-
отримувати від ПС інформацію на екрані у вигляді графічних і текстових об'єктів
-
здійснювати прямі маніпуляції з графічними і текстовими об'єктами, представленими на екрані.
Графічний призначений для користувача інтерфейс дозволяє
-
розміщувати на екрані безліч різних вікон, в які можна виводити інформацію незалежно;
-
використовувати графічні об'єкти, звані піктограмами (або іконами), для позначення різних інформаційних об'єктів або процесів;
-
використовувати екранний покажчик для вибору об'єктів (або їх елементів), розміщених на екрані; екранний покажчик управляється (переміщається) за допомогою клавіатури або миші.
Гідністю графічного призначеного для користувача інтерфейсу є можливість створення зручною і зрозумілою користувачеві моделі взаємодії з ПС (панель управління, робочий стіл і тому подібне) без необхідності вивчення якої-небудь спеціальної мови. Проте його розробка вимагає великих трудовитрат, порівнянних з трудовитратами по створення самого ПС. Крім того, виникає серйозна проблема по переносимості ПС на інші операційні системи, оскільки графічний інтерфейс істотно залежить від можливостей (графічної призначеної для користувача платформи), що надаються операційною системою для його створення.
Графічний призначений для користувача інтерфейс узагальнює такі види призначеного для користувача інтерфейсу, як інтерфейс типу меню і інтерфейс прямого маніпулювання.
12.3. Забезпечення ефективності програмного засобу.
Ефективність ПС забезпечується ухваленням відповідних рішень на різних етапах його розробки, починаючи з розробки його архітектури. Особливо сильно на ефективність ПС (особливо по пам'яті) впливає вибір структури і представлення даних. Але і вибір алгоритмів, використовуваних в тих або інших програмних модулях, а також особливості їх реалізації (включаючи вибір мови програмування) може істотно вплинути на ефективність ПС. При цьому постійно доводиться вирішувати протиріччя між временн0й ефективністю і ефективністю по пам'яті (ресурсам). Тому вельми важливо, щоб в специфікації якості були явно вказані пріоритети або кількісне співвідношення між показниками цих примітивів якості. Слід також мати на увазі, що різні програмні модулі по-різному впливають на ефективність ПС в цілому: одні модулі можуть сильно впливати на тимчасову ефективність і практично не впливати на ефективність по пам'яті, а інші можуть істотно впливати на загальну витрату пам'яті, не роблячи помітного впливу на час роботи ПС. Більш того, це вплив (перш за все, відносно тимчасової ефективності) заздалегідь (до закінчення реалізації ПС) далеко не завжди можна правильно оцінити.
З урахуванням сказаного, рекомендується дотримуватися наступних принципів для забезпечення ефективності ПС [12.3, 12.4]:
-
спочатку потрібно розробити надійне ПС, а потім вже займатися доведенням його ефективності до необхідного рівня відповідно до його специфікації якості;
-
для підвищення ефективності ПС, перш за все, потрібно використовувати оптимізуючий компілятор - це може забезпечити необхідну ефективність;
-
якщо ефективність ПС не задовольняє специфікації його якості, то знайдіть найкритичніші модулі з погляду необхідної ефективності ПС; ці модулі і спробуйте оптимізувати в першу чергу шляхом їх ручної переробки;
-
не слід займатися оптимізацією модуля, якщо цього не вимагається для досягнення необхідної ефективності ПС.
Для відшукання критичних модулів з погляду временнй ефективності ПС потрібно буде отримати розподіл по модулях часу роботи ПС шляхом відповідних вимірювань під час виконання ПС. Це може бути зроблено за допомогою динамічного аналізатора (спеціального програмного інструменту), який може визначити частоту звернення до кожного модуля в процесі застосування ПС.
12.4. Забезпечення сопровождаемости програмного засобу.
Забезпечення сопровождаемости ПС зводиться до забезпечення изучаемости ПС і до забезпечення тієї, що його модифікується.
Ізучаємость (підкритерій якості) ПС визначається складом і якістю документації по супроводу ПС і виражається через такі примітиви якості ПС як С-документірованность, інформативність, зрозумілість, структурованість і легкість для читання. Останні два примітиви якості і, в значній мірі, зрозумілість пов'язано з текстами програмних модулів. Питання про документацію по супроводу обговорюватиметься в наступній лекції. Тут ми лише зробимо деякі загальні рекомендації щодо текстів програм (модулів).
При остаточному оформленні тексту програмного модуля доцільно дотримуватися наступних рекомендацій, що визначають практично виправданий стиль програмування [12.3, 12.4]:
-
використовуйте в тексті модуля коментарі, прояснюючі і пояснюючі особливості ухвалюваних рішень; по-возможности, включайте коментарі (хоч би в короткій формі) на найранішій стадії розробки тексту модуля;
-
використовуйте осмислені (мнемонічні) і стійко помітні імена (оптимальна довжина імені 4-12 літер, цифри в кінці), не використовуйте схожі імена і ключові слова;
-
дотримуйтеся обережності у використанні констант (унікальна константа повинна мати єдине входження в текст модуля: при її оголошенні або, в крайньому випадку, при ініціалізації змінної як константа);
-
не бійтеся використовувати необов'язкові дужки вони обходяться дешевшим, ніж помилки;
-
розміщуйте не більше одного оператора в рядку; для прояснення структури модуля використовуйте додаткові пропуски (відступи) на початку кожного рядка; цим забезпечується легкість для читання тексту модуля;
-
уникайте трюків, тобто таких прийомів програмування, коли створюються фрагменти модуля, основний ефект яких не очевидний або прихований (завуальований), наприклад, побічні ефекти функцій.
Структурованість тексту модуля істотно спрощує його розуміння. Забезпечення цього примітиву якості детально обговорювалося в лекції 8. Легкість для читання тексту модуля може бути забезпечена автоматично шляхом застосування спеціального програмного інструменту форматера.
Та, що модифікується (підкритерій якості) ПС визначається, частково, деякими властивостями документації, і властивостями, що реалізовуються програмним шляхом, і виражається через такі примітиви якості ПС як розширюваність, модифікується, структурованість і модульність.
Розширюваність забезпечується можливостями автоматично настроюватися на умови застосування ПС за інформацією, що задається користувачем. До таких умов відносяться, перш за все, конфігурація комп'ютера, на якому застосовуватиметься ПС (зокрема, об'єм і структура його пам'яті), а також вимоги конкретного користувача до функціональних можливостей ПС (наприклад, вимоги, які визначають режим застосування ПС або конкретизують структуру інформаційного середовища). До цих можливостей можна віднести і можливість додавання до ПС визначених компонент. Для реалізації таких можливостей в ПС часто включається додаткова компоненту (підсистема), звана инсталятором. Інсталятор здійснює прийом від користувача необхідної інформації і настройку ПС за цією інформацією. Звичайне рішення про включення в ПС такий компоненти приймається в процесі розробки архітектури ПС.
Та, що модифікується (примітив якості) забезпечується такими властивостями документації і властивостями, що реалізовуються програмним шляхом, які полегшують внесення змін і доопрацювань в документацію і програми ПС ручним шляхом (можливо, з певною комп'ютерною підтримкою). У специфікації якості можуть бути вказані деякі пріоритетні напрями і особливості розвитку ПС. Ці вказівки повинні бути враховані при розробці архітектури ПС і модульної структури його програм. Загальна проблема супроводу ПС забезпечити, щоб всі його компоненти (на всіх рівнях уявлення) залишалися узгодженими в кожній новій версії ПС. Цей процес зазвичай називають управлінням конфігурацією (configuration management) .Чтобы допомогти управлінню конфігурацією, необхідно, щоб зв'язки і залежності між документами і їх частинами фіксувати в спеціальній документації по супроводу [12.5]. Ця проблема ускладнюється, якщо в процесі доопрацювання може знаходитися відразу декілька версій ПС (різною мірою завершеності). Тоді без комп'ютерної підтримки досить важко забезпечити узгодженість документів в різних конфігураціях. Тому в таких випадках в ПС включається додаткова компоненту (підсистема), звана конфігуратором. З такою компонентой зв'язують спеціальну базу даних (або спеціальний розділ в базі даних), в якій фіксуються зв'язки і залежності між документами і їх частинами для всіх версій ПС. Звичайне рішення про включення в ПС такий компоненти приймається в процесі розробки архітектури ПС. Для забезпечення цього примітиву якості в документацію по супроводу включають спеціальне керівництво, яке описує, які частини ПС є аппаратно- і програмно-залежними, і як можливий розвиток ПС врахований в його будові (конструкції).