Ім'я файлу: ВИЗНАЧЕННЯ_ВИМОГ_ДО_ПРОГРАМНИХ_СИСТЕМ_Кожна_програмна_система.do
Розширення: docx
Розмір: 26кб.
Дата: 06.05.2021
скачати
Розширення: docx
Розмір: 26кб.
Дата: 06.05.2021
скачати
ВИЗНАЧЕННЯ ВИМОГ ДО ПРОГРАМНИХ СИСТЕМ Кожна програмна система – це перетворювач, функцією якого є визначене оброблення даних і вивід отриманих результатів. З метою побудови програмної системи до неї, насамперед, формулюються вимоги до умов виконання функції і обробки даних. Ці вимоги є предметом практичного контракту між замовником і розробником системи [1]. У загальному випадку під вимогами до ПС розуміють властивості, які повинна мати система для виконання запропонованих замовником функцій. Прикладами таких функцій можуть бути бізнес-функції, документообіг, керування даними і структурою інформації, що необхідна для прийняття системних рішень, та ін. У ядрі знань SWEBOK викладено основні концепції й особливості інженерії вимог, які подано на рис. 3.1. Розробка вимог
Розробка вимог
| Інженерія вимог | Аналіз вимог | Фіксація вимог | Трасування вимог | Керування вимогами |
| Модель процесів ЖЦ | Техніка обговорення | Специфікація вимог | Специфікація вимог | Керування змінами |
| Тривалість виконавців (акторів) | Визначення вимог | Систематизація вимог | Трасування вимог | Зв’язок з процесами |
| Керування вимогами на процесах ЖЦ | Аналіз вимог | Опис документу | Валідация вимог | Перевірка і верифікація |
| Покращення якості | Збір вимог | Узгодження документу | Прототипування | Оцінка якості |
Рис. 3.1. Основні розділи розробки вимог
Основні розділи розробки вимо
Найпоширеніший інструмент інженерії вимог – це UML, у якому вимоги визначаються й уточнюються через подання можливих варіантів використання ПС (use case), що трансформуються у проектні рішення і архітектуру системи. Розглянемо загальні й спеціалізовані (зокрема, об’єктно-орієнтовані) підходи до розробки вимог до системи у контексті розділів, поданих на рис. 3.1
Загальні підходи до визначення вимог
Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками. Замовник висловлює свої потреби і представляє погляди щодо автоматизації
функцій і задач системи, які далі набувають формулювання у вигляді різнопланових вимог до ПС, класифікація яких подається нижче. 3.1.1. Класифікація вимо
Дотепер ще відсутні загальноприйняті терміни, якими користуються спеціалісти для опису вимог замовника до ПС, а саме, функціональних, системних, технологічних. У різних тематичних джерелах наведені різні визначення поняття вимог, виходячи з особистих поглядів замовників на програмний продукт, який потрібно побудувати. У ряді публікацій формування вимог до ПС розглядається як певна ділова гра, під час якої виявляються інтереси зацікавлених у розробці ПС осіб, правила реалізації цих інтересів у конкретному продукті. При цьому висловлюються різного роду претензії й обмеження на властивості і способи забезпечення вимог для отримання кінцевого програмного продукту. Отже, зрозуміло що нема формалізованих методів збирання й опису вимог, а також відсутнє загальноприйняте визначення самого поняття вимога. Наведемо тлумачення цього слова з джерел [1–3]. Вимоги – це твердження про функції й обмеження системи. Вимоги – це властивості, які повинен мати продукт, щоб являти бути собою цінним для свого користувачів. Вимоги – це специфікація того, що і як повинно бути реалізовано. Відповідно до міжнародного глосарію з термінології комп’ютерної науки вимога містить у собі опис:
1) умов або можливостей, необхідних користувачеві для вирішення поставлених проблем або для досягнення цілей;
2) функцій і обмежень, які повинна мати система або системні компоненти, щоб виконати контракт замовника на розробку;
3) положень і регламенту, встановлених використаними стандартами і відображених у специфікаціях або інших формальних документах на систему;
4) умов, можливостей і обмежень середовища, необхідних для проектування і виконання системи
Розглянемо основні типи вимог. Вимоги до продукту охоплюють умови користувачів щодо зовнішнього поводження системи і погляди розробників на деякі параметри системи. Термін користувач стосується осіб, зацікавлених у створенні системи. Вимоги до ПЗ є такі: системні, функціональні і не функціональні вимоги. Вимоги користувачів (user requirements) задаються умовами досягнення цілей і задач, віддзеркалюють вимоги споживачів до спектра розв’язуваних майбутньою системою задач. Вони подаються як текстовий опис або сценарії, прецеденти, таблиці «подія-відгук» тощо. Системні вимоги (system requirements) визначають зовнішні умови виконання системних функцій і обмежень на створення продукту, а також вимоги до опису програмно-апаратних підсистем. Системні вимоги накладають обмеження на архітектуру системи, засоби її візуального подання і функціонування. Для опису системних вимог використовують спеціальні шаблони і форми, що допомагають уявити вхідні і вихідні дані й автоматизувати ці вимоги. Розділ 3 67 Вимоги до атрибутів якості (quality attributes) – це деякі обмеження на властивості функцій або системи, важливі для користувачів або розробників. Наприклад, переносність, цілісність, стійкість системи до збоїв. Функціональні вимоги – це перелік функцій або сервісів, які повинна надавати система, а також обмежень на дані і поводження системи при їхньому виконанні. Специфікація функціональних вимог (software requirements specification) – опис функцій та їхніх властивостей, які не містять у собі протиріч і виключень. Нефункціональні вимоги визначають умови виконання функцій (наприклад, захист інформації у БД, аутентифікація доступу до ПС тощо) у середовищі, що безпосередньо не пов'язані з функціями, а відбивають потреби користувачів щодо їх виконання. Ці вимоги характеризують принципи взаємодії із середовищами або іншими системами, а також визначають показники часу роботи, захисту даних і досягнення якості з урахуванням рекомендацій використовуваного стандарту. Вони можуть встановлюватися як числові значення (наприклад, час чекання відповіді, кількість клієнтів, що обслуговуються і ін.) у різних одиницях виміру, включаючи, наприклад, ймовірність (значення ймовірності безвідмовної роботи системи – показника її надійності). Для більшості сучасних ПС вимоги складаються з умов й обмежень типу: – конфіденційність, безпека і захист даних; – відмовостійкість; – одночасність доступу користувачів до системи; – час чекання відповіді при звертанні до системи (продуктивність); – склад виконуваних функцій системи (запуск, швидкість реакції й ін.); – положення стандартів з виконання сформульованих вимог. Дані вимоги визначаються і формалізуються аналітиками на процесі аналізу і проектування структури системи. Так, у випадку вимог з безпеки функціонування системи, в системі виділяються категорії користувачів, що мають право доступу до тих або інших функцій (програмних компонентів) або даних, та передбачаються додаткові функції системи з перевірки доступу (санкціонований доступ до них чи ні). Якщо потрібно обмежити доступ до конкретних даних (наприклад, до окремих записів, полів у таблиці), то в системі може передбачатися, наприклад, мандатний захист. Для захисту всієї системи від несанкціонованого доступу користувачі реєструються і проходять аутентифікацію для роботи із системою. Для відновлення і збереження резервних копій БД, архівів баз даних аналізуються можливості СУБД і способи забезпечення необхідного рівня безперебійної роботи системи, правил доступу авторизованих користувачів і заходів боротьби з різними загрозами, що надходять ззовні від користувачів, які не мають прав доступу до деяких або до всіх даних системи. До вихідного продукту пред'являються нефункціональні вимоги до: – застосування (якість інтерфейсу, продукту й ін.); – продуктивності (пропускна здатність, час реакції й ін.); – надійності виконання (без помилок і відмов); – зовнішніх інтерфейсів, за якими виконується взаємодія з іншими компонентами або підсистемами. Опис усіх видів вимог проводиться з урахуванням стандартів, наприклад, стандарту з якості ISO/IEC ДСТУ 9126 і стандартизованого понятійного і термінологічного довідника, що містить у собі загальноприйняті терміни щодо 68 Розділ 3 структури ПрО і призначення функцій системи. Специфікація вимог відображає принципи взаємодії проектованої системи з іншими середовищами, платформами і загальносистемним забезпеченням (БД, СКБД, мережі та ін.). Формування документа зі специфікаціями вимог завершується на процесі проектування архітектури, після чого він узгоджується з замовником системи і використовується як керування дій при виконанні задач розробки програмного продукту на процесах ЖЦ і отриманні готового продукту. При виявленні на них неузгоджених вимог, проводиться їхнє уточнення і, відповідно, вносяться зміни у деякі задачі процесу розроблення системи або характеристики продукт