Загальні підходи до визначення вимог

 

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

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

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

У ряді публікацій формування вимог до ПС розглядається як певна лілова гра, під час якої виявляються інтереси зацікавлених у розробці ПС осіб, правила реалі­зації цих інтересів у конкретному продукті. При цьому висловлюються різного роду претензії й обмеження на властивості і способи забезпечення вимог для отри­мання кінцевого програмного продукту. Отже, зрозуміло що нема формалізованих методів збирання й опису вимог, а також відсутнє загальноприйняте визначення самого поняття вимога. Наведемо тлумачення цього слова з джерел [1-3].

Вимоги це твердження про функції й обмеження системи.

Вимоги - це властивості, які повинен мати продукт, щоб являти бути собою цінним для свого користувачів.

Вимоги - це специфікація того, що і як повинно бути реалізовано.

Відповідно до міжнародного глосарію з термінології комп'ютерної науки ви­мога містить у собі опис:

1) умов або можливостей, необхідних користувачеві для вирішення поставле­них проблем або для досягнення цілей;

2) функцій і обмежень, які повинна мати система або системні компоненти, щоб виконати контракт замовника на розробку;

3) положень і регламенту, встановлених використаними стандартами і відображених у специфікаціях або інших формальних документах на систему;

4) умов, можливостей і обмежень середовища, необхідних для проектування і виконання системи.

Розглянемо основні типи вимог.

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

Вимоги до ПЗ містять у собі системні, функціональні і не функціональні вимо­ги.

Вимоги користувачів (user requirements) задаються умовами досягнення цілей і задач, віддзеркалюють вимоги споживачів до спектра розв'язуваних майбутньою системою задач. Вони подаються як текстовий опис або сценарії, прецеденти, таблиці «подія-відгук» тощо.

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

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

Функціональні вимоги - це перелік функцій або сервісів, які повинна надавати система, а також обмежень на дані і поводження системи при їхньому виконанні. Специфікація функціональних вимог (software requirements specification) - опис фу­нкцій та їхніх властивостей, які не містять у собі протиріч і виключень.

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

- конфіденційність, безпека і захист даних;

- відмово стійкість;

- одночасність доступу користувачів до системи;

- час чекання відповіді при звертанні до системи (продуктивність);

- склад виконуваних функцій системи (запуск, швидкість реакції й ін.);

- положення стандартів з виконання сформульованих вимог.

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

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

До вихідного продукту пред'являються не функціональні вимоги до:

- застосування (якість інтерфейсу, продукту й ін.);

- продуктивності (пропускна здатність, час реакції й ін.);

- надійності виконання (без помилок і відмов);

- зовнішніх інтерфейсів, за якими виконується взаємодія з іншими компонен­тами або підсистемами.

Опис усіх видів вимог проводиться з урахуванням стандартів, наприклад, стандарту з якості ISO/IEC ДСТУ 9126 і стандартизованого понятійного і термінологічного довідника, що містить у собі загальноприйняті терміни щодо структури ПрО і призначення функцій системи. Специфікація вимог відображає принципи взаємодії проектованої системи з іншими середовищами, платформами і загальносистемним забезпеченням (БД, СКБД, мережі та ін.).

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

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

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

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

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

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

- функціонального змісту послуг;

- регламенту операційного обслуговування системи тощо. В обговоренні вимог до системи беруть участь:

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

- оператори, що обслуговують систему;

- аналітики і розробники майбутньої системи.

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

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

- різні типи умов, що відповідають різним рівням деталізації проекту і потре­бують застосування методів керування ними;

- постійно змінювані або уточнюванні, залежно від унікальних властивостей або значень;

- складні за формою і змістом, тяжкі для узгодження їх із замовником. Розробники вимог повинні мати відповідні знання в даній предметній області

і вміти здійснювати:

аналіз проблем, задач предметної області, а також потреб замовника і корис­тувачів системи,

- виявлення функцій системи, що мають бути реалізовані в проекті,

- внесення змін в окремі елементи вимог у процесі їх виконання.

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

Помилки через нечіткі або неоднозначні формулювання вимог можуть призвести до того, що виготовлена система не буде задовольняти замовника. Тому на етапах розробки вимоги повинні постійно уточнюватися і знову затверджуватися замовником. В окремих випадках внесені зміни у вимоги можуть обумовити необхідність перепроектування окремих частини або всієї системи в цілому. Відповідно до статистики, частка помилок у постановці вимог і у визначенні задач системи пе­ревищує частку помилок, що допускається під час кодування системи. Це обумов­люється суб'єктивним характером процесу формулювання вимог і відсутністю спо­собів їхньої формалізації. У США, наприклад, щорічно витрачається до 82 млрд. дол. на проекти, визнані після реалізації такими, що не відповідають вимогам замовників.

Існуючі стандарти (ДСТУ 34.601-90 і ДСТУ 34.201-89) з розробки вимог до автоматизованої системи (АС) і відповідної документації фіксують результати створення програмного, технічного, організаційного та інших видів забезпечення автоматизованих систем на етапах ЖЦ.

Збирання вимог. Джерелами відомостей для збирання вимог є:

- мета і задачі проекту, що формулює замовник майбутньої системи, і які по­винні осмислюватися розробниками;

- колектив, який виконує реалізацію функцій системи.

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

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

Методи збирання вимог такі:

- інтерв'ю з виразниками інтересів замовника системи;

- вивчення прикладів можливих варіантів виконання функцій, ролей відпові­дальних осіб, які пропонують ці варіанти, або тих, що взаємодіють із системою при її функціонуванні;

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

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

Отримання зовнішніх і внутрішніх характеристик якості досягається спеціально розробленими методами з виконання процесів ЖЦ. Внутрішні характеристики, які досягаються в ході ЖЦ, позначаються на зовнішніх показниках і використовуються при оцінюванні робочих та кінцевих продуктів ПС.

Остаточно сформульовані вимоги - основа для підпису контракту між замов­ником і розробником системи.

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

Одна з головних проблем збирання вимог - їхня зміна. Вимоги створюються ітераційно, шляхом постійного спілкування представників замовників з аналітиками і розробниками майбутньої системи з метою виявлення необхідних потреб. Вимоги змінюються в міру уточнення функцій і задач, умов їхнього визначення на етапі укладання договору на створення системи і, зрештою, відповідають поглядам замо­вника на систему [4].

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

 

Рис. 3.3. Схема трасування вимог

 

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

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

- вимоги, що змінюються при їхньому формуванні;

- деякі деталі виконання функцій у робочому продукті системи, що не передбачалися, але з'явилися в зв'язку з практичною ситуацією, що виникла;

- зв'язки між різними моделями процесу проектування системи на ЖЦ і прийняті рішення про необхідність зміни вимог через виявлені недоліки в проміжному або робочому продукті;

- інформація про узгодження атрибутів вимог на різних рівнях даної схеми трасування та її матриць;

- системні вимоги, наприклад, до повторного використання готових компонентів;

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

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

- вибору елемента вимог з матриці, за яким буде відбуватися простежування на етапах ЖЦ;

- складання списку питань, за якими на кожному етапі ЖЦ перевіряються зв'язки при реалізації вимог, і, якщо змінюється будь яка ланка в ланцюжку вимог (рис.3.3), то може модифікуватися процедура розроблення цього елемента на наступному етапі ЖЦ;

- проведення моніторингу кожної вимоги на відповідність прийнятому пла­ну;

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

Умова прийняття рішення про можливі модифікації вимог і результатів про­міжного проектування - оновлена інформація про зв'язки між різними частинами системи і первісно заданими вимогами до них. Трасування забезпечує:

- введення складних зв'язків замість простих;

- використання різних шляхів трасування (між моделями або ієрархічними зв'язками);

- трасування об'єктів і зв'язків між ними.

Трасування може бути вибірковим для окремих об'єктів або зв'язаним з ін­шими об'єктами, а також з можливими переходами від однієї моделі проектування до іншої.

 

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

 

1.Наведіть класифікацію вимог.

2. Визначте призначення функціональних і не функціональних вимог.

3. Назвіть джерела для завдання вимог.

4. Наведіть задачі обстеження, аналізу і збирання вимог.

5. Визначте інженерію вимог і задачі трасування вимог.

6. Визначте суть об'єктно-орієнтованої інженерії вимог.

7. Назвіть ролі діючих осіб у формуванні вимог.

8. Назвіть види відношень об'єктів у моделі.

9. Охарактеризуйте сценарний підхід і підхід за прецедентами.

 

5. Методи програмування.

 

Ядро SWЕВОК містить у собі два близьких за змістом розділи, які пов'язані з побудовою ПЗ: проектування ПЗ і конструювання ПЗ. Розділ, що стосується програмування, в цьому ядрі відсутній, проте те він є необхідний, оскільки в сучас­ній практиці проектування і розроблення програмних продуктів (ПП) широко вико­ристовуються багато різних парадигм програмування (модульне, об'єктно-орієнтоване, компонентне, аспектне тощо), які мають бути певним чином система­тизовані.

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

Розрізняють прикладні і теоретичні методи, які з'явилися у різний час від моменту появи програмної інженерії і мають свою специфіку й сферу застосування. Наприклад, структурний метод виник багато років тому, він добре відпрацьований і вдосконалений для індустріального виготовлення ПП і навіть став Держстандартом у Великобританії. Широкого застосування набули методи модульного і компонент­ного програмування. Вони базуються на концепції повторного використання компонентів. Саме ці види програмування започаткували індустрію виготовлення ПП з готових компонентів, аналогічно до того, як в промисловості здійснювалося виготовлення виробів з готових деталей.

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

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

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