К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Розділ 3. ВИЗНАЧЕННЯ ВИМОГ ДО ПРОГРАМНИХ СИСТЕМ Кожна програмна система – це перетворювач, функцією якого є визначене оброблення даних і вивід отриманих результатів. З метою побудови програмної системи до неї, насамперед, формулюються вимоги до умов виконання функції і обробки даних. Ці вимоги є предметом практичного контракту між замовником і розробником системи [1]. У загальному випадку під вимогами до ПС розуміють властивості, які повинна мати система для виконання запропонованих замовником функцій. Прикладами таких функцій можуть бути бізнес-функції, документообіг, керування даними і структурою інформації, що необхідна для прийняття системних рішень, та ін. У ядрі знань SWEBOK викладено основні концепції й особливості інженерії вимог, які подано на рис. 3.1. Розробка вимог Інженерія вимог Аналіз вимог Фіксація вимог Трасування вимог Керування вимогами Модель процесів ЖЦ Тривалість виконавців (акторів) Керування вимогами на процесах ЖЦ Покращення якості Техніка обговорення Визначення вимог Аналіз вимог Збір вимог Специфіка- ція вимог Системати- зація вимог Перегляд вимог Трасування вимог Керування змінами Зв’язок з процесами Перевірка і верифікація Оцінка якості Опис документу Узгодження документу Валідация вимог Прототи- пування Рис. 3.1. Основні розділи розробки вимог Найпоширеніший інструмент інженерії вимог – це UML, у якому вимоги визначаються й уточнюються через подання можливих варіантів використання ПС (use case), що трансформуються у проектні рішення і архітектуру системи. Розглянемо загальні й спеціалізовані (зокрема, об’єктно-орієнтовані) підходи до розробки вимог до системи у контексті розділів, поданих на рис. 3.1. 3.1. Загальні підходи до визначення вимог Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками. Замовник висловлює свої потреби і представляє погляди щодо автоматизації 66 Розділ 3 функцій і задач системи, які далі набувають формулювання у вигляді різнопланових вимог до ПС, класифікація яких подається нижче. 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 структури ПрО і призначення функцій системи. Специфікація вимог відображає принципи взаємодії проектованої системи з іншими середовищами, платформами і загальносистемним забезпеченням (БД, СКБД, мережі та ін.). Формування документа зі специфікаціями вимог завершується на процесі проектування архітектури, після чого він узгоджується з замовником системи і використовується як керування дій при виконанні задач розробки програмного продукту на процесах ЖЦ і отриманні готового продукту. При виявленні на них неузгоджених вимог, проводиться їхнє уточнення і, відповідно, вносяться зміни у деякі задачі процесу розроблення системи або характеристики продукту. 3.1.2. Аналіз і збирання вимог У сучасних технологіях процес ЖЦ, у якому фіксуються вимоги до розробки системи, є визначальним для задання функцій, термінів і вартості робіт, а також показників якості, які необхідно досягти в процесі розроблення. Виявлення вимог проводиться під час обговорення проекту, аналізу особливостей предметної області і визначення підходів до її проектування на процесах ЖЦ. Вимоги відбиваютьпотреби людей (замовників, користувачів, розробників), зацікавлених у створенні ПС. Замовник і розробник спільно обговорюють проблеми проекту, збирають вимоги, проводять їхній аналіз, перегляд і визначають необхідні обмеження. Обговорення проекту системи відбувається з метою вивчення думки і вироблення перших висновків щодо доцільності виконання проекту і прогнозування реальності його виконання в заданий термін і за кошти, що дає замовник. Природно, особа, яка замовила проект системи, бажає отримати від розробника набір необхідних послуг, за якими будуть звертатися різні категорії користувачів: оператори, менеджери, фахівці у ПрО. Розробники системи можуть оцінити можливість реалізації послуг у проекті системи, що замовляється, у заданий термін і бюджет. Серед розробників призначаються головний аналітик, відповідальний за вимоги до системи, і головний програміст, відповідальний за їхню реалізацію. Вони узгоджують вимоги і визначають сферу дії проекту на спільних переговорах із замовником з метою уточнення наступних питань: – спектра проблем ПрО, при вирішенні яких будуть визначатися послуги системи; – функціонального змісту послуг; – регламенту операційного обслуговування системи тощо. В обговоренні вимог до системи беруть участь: – представники замовника з декількох професійних груп; – оператори, що обслуговують систему; – аналітики і розробники майбутньої системи. Погоджена сфера дій у проекті дає можливість оцінити необхідні інвестиції в проект, заздалегідь визначити можливі ризики і здатності розробників щодо виконання проекту. Підсумком обговорення проекту може бути рішення про розгортання реалізаційних робіт на проекті або відмови від нього. Аналіз вимог починається після обговорення проблематики проекту. Серед обговорюваних вимог можуть виявитися: Розділ 3 69 – неочевидні або не однаково важливі, які були взяті з застарілих джерел і документів замовника; – різні типи умов, що відповідають різним рівням деталізації проекту і потребують застосування методів керування ними; – постійно змінювані або уточнювані, залежно від унікальних властивостей або значень; – складні за формою і змістом, тяжкі для узгодження їх із замовником. Розробники вимог повинні мати відповідні знання в даній предметній області і вміти здійснювати: – аналіз проблем, задач предметної області, а також потреб замовника і користувачів системи, – виявлення функцій системи, що мають бути реалізовані в проекті, – внесення змін в окремі елементи вимог у процесі їх виконання. У вимогах до ПС, крім проблем системи, формулюються реальні потреби замовника щодо функціональних, операційних і сервісних можливостей майбутньої системи. Результати дії дослідження й аналізу предметної області фіксуються в документі з опису вимог і в договорі між замовником і виконавцем проекту. Помилки через нечіткі або неоднозначні формулювання вимог можуть призвести до того, що виготовлена система не буде задовольняти замовника. Тому на процесах розробки вимоги повинні постійно уточнюватися і знову затверджуватися замовником. В окремих випадках внесені зміни у вимоги можуть обумовити необхідність перепроектування окремих частини або всієї системи в цілому. Відповідно до статистики, частка помилок у постановці вимог і у визначенні задач системи перевищує частку помилок, що допускається під час кодування системи. Це обумовлюється суб'єктивним характером процесу формулювання вимог і відсутністю способів їхньої формалізації. У США, наприклад, щорічно витрачається до 82 млрд.дол. на проекти, визнані після реалізації такими, що не відповідають вимогам замовників. Існуючі стандарти (ДСТУ 34.601–90 і ДСТУ 34.201–89) з розробки вимог до автоматизованої системи (АС) і відповідної документації фіксують результати створення програмного, технічного, організаційного та інших видів забезпечення автоматизованих систем на процесах ЖЦ. Збирання вимог.Джерелами відомостей для збирання вимог є: – мета і задачі проекту, що формулює замовник майбутньої системи, і які повинні осмислюватися розробниками; – колектив, який виконує реалізацію функцій системи. Вивчення і фіксація реалізованих функціональних можливостей у діючій системі є підґрунтям для накопичення досвіду для формулювання нових вимог до неї. При цьому необхідно відокремлювати нові вимоги до системи від старих вимог, щоб не повторити невдалі розв’язки щодо старої системи в новому її виконанні. Вимоги до системи формулюються замовником у термінах понять його предметної області з урахуванням відомих словників, стандартів, існуючих умов середовища функціонування майбутньої системи, а також трудових і фінансових ресурсів, виділених на розробку системи. Методи збирання вимог такі: – інтерв'ю з виразниками інтересів замовника системи; 70 Розділ 3 – вивчення прикладів можливих варіантів виконання функцій, ролей відповідальних осіб, які пропонують ці варіанти, або тих, що взаємодіють із системою при її функціонуванні; – спостереження за роботою діючої системи для відокремлення властивостей, що обумовлені кадровими аспектами. Зовнішні і внутрішні аспекти вимог пов’язують з характеристиками якості і відносяться до властивостей створюваного продукту, а саме, функцій системи, її призначення і виконання в заданому середовищі. На прикінці користувач очікує досягнення максимального ефекту від застосування вихідного продукту та орієнтується на його кінцеву експлуатаційну якість. Отримання зовнішніх і внутрішніх характеристикякості досягається спеціально розробленими методами з виконання процесів ЖЦ. Внутрішні характеристики, які досягаються в ході ЖЦ, позначаються на зовнішніх показниках і використовуються при оцінюванні робочих та кінцевих продуктів ПС. Остаточно сформульовані вимоги – основа для підпису контракту між замовником і розробником системи. 3.1.3 Інженерія вимог Інженерна дисципліна аналізу і документування вимог передбачає планування і перетворення запропонованих замовником вимог до системи на опис вимог до ПЗ, їх специфікацію і валідацію. Вона базується на моделях процесів розроблення вимог, діях акторів і керуванні поступовим перетворенням вимог до проектних рішень і опису компонентів у мові програмування. Модель процесу визначення вимог – це схема процесів ЖЦ, що виконуються від початку проекту і доти, поки не будуть визначені і погоджені вимоги. Керування вимогами до ПЗполягає в плануванні і контролі формування вимог, заданих на основі проектних рішень, у перетворенні їх на специфікації компонентів системи. Якість і процес поліпшення вимог – це методи досягнення і перевірки характеристик і атрибутів якості (надійність, реактивність та ін.), які повинна мати система і ПЗ, у процесах ЖЦ і під час закінчення розробки продукту. Керування вимогами до системи– це планування і керування формуванням вимог на всіх процесах ЖЦ, а саме, керування змінами вимог, відновлення їхнього джерела й уточнення вимог. Невід'ємна складова процесу керування – трасування вимог, що полягає у відстеженні правильності завдання і реалізації вимог до системи і ПЗ на процесах ЖЦ і зворотного процесу звіряння ПЗ із заданими вимогами. Основні задачі керування вимогами це: – розроблення атрибутів вимог, – керування варіантами вимог, – керування ризиками, що виникають при неточному визначенні вимог, – контроль статусу вимог, вимірювання зусиль при формуванні вимог; – реалізація вимог на процесах ЖЦ. Розроблення і керування вимогами зв'язана з іншими областями знань (рис. 3.2). Розділ 3 71 Рис. 3.2. Керування вимогами і зв'язок із задачами SWEBOK Планування робіт на проекті стосується питань організації інтеграції компонентів, керування ризиками, версіями системи, на які впливають задані вимоги та їхні зміни. 3.1.4. Фіксація вимог Початковий процес розроблення ПС – збирання вимог, який завершується формуванням списку вимог до системи, що називається у вітчизняній практиці технічним завданням. Фіксація вимог (Requirement Capturing) у технічному завданні обумовлена потребою замовника зафіксувати і одержати задані ним властивості у реалізованій системі. При цьому передбачається специфікація, верифікація і валідація вимог на правильність, відповідність і повноту. Специфікація вимог до ПЗ – це формалізований опис функціональних, нефункціональних і технічних вимог, вимог до характеристик якості, до структури ПЗ і принципів взаємодії з його компонентами. Приклад. Скласти вимоги до облікової і статистичної функцій ПЗ системи обробки даних. Згідно з стандартом ДСТУ 34.601–92 («Розробка АС») функціональні вимоги до ПЗ даної системи можливо представити так: – система повинна мати 12 функцій, з них 8 облікових та 4 статистичних; – кожна функція повинна бути ретельно реалізована, бути коректною і повинна давати точні результати; – дані для функцій подаються в табличному вигляді і зберігаються в БД СКБД Oracle, їхній обсяг – 10000 записів на рік; – дані повинні контролюватися і бути захищені від несанкціонованого доступу до БД тощо. Дані вимоги відносять до характеристик функціональності системи. Після її реалізації повинні бути перевірені функції на відповідність установленим вимогам, діючим нормам і стандартам. Оцінка функцій виконується після їхньої валідації, верифікації та реалізації. Як оцінки використовують метрики (коректність, точність, повнота тощо) для перевірки різних аспектів реалізації функцій. Ці метрики наведені у першій, а їхні формули – у другій колонках табл.3.1. У ці формули підставлені значення, яким надано кількісний опис у специфікації вимог. На основі отриманих метрик розв’язується задача правильної реалізації вимог до ПЗ або до всієї програмної системи. |