К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Назва метрики Опис результату перевірки Повнота реалізації функції = 1 – N/M N – число нереалізованих (пропущених) функцій M – число функцій в описі вимог Коректність реалізації функцій = 1 – N/M N – число некоректно розроблених функцій M – число функцій в описі вимог Точність реалізації функцій = N/T N – число відхилених результатів виконання функцій T – час використання компонентів функції Ретельність реалізації функцій = N/M N – число функцій, для яких специфікації вимог були точно реалізовані, M – число функцій, для яких вимоги до точності були встановлені в специфікації вимог Здатність до обміну даних = N/R N – число даних, що беруть участь в обміні даних із БД, R – загальне число форматів даних, що беруть участь в обміні із БД Контроль доступу до даних у БД k = N/M N – число несанкціонованих операцій, M – число нелегальних операцій, наведених в описі вимог Точність обчислення даних k = N/M N – число елементів даних, для яких забезпечений рівень точності обчислень, M – число елементів даних, для яких у специфікації встановлений рівень точності обчислень Ступінь контролю доступу k = N/M N – число вимог до контролю доступу стосовно специфікації вимог, M – число вимог до контролю доступу, встановлених у специфікаціях вимог Функціональна відповідність = N/M N – число коректно розроблених компонентів, до яких пред'являються функціональна відповідність, M – загальне число компонентів, до яких установлені норми і правила відповідності Валідація вимог – це перевірка вимог для переконання, що вони визначають саме дану систему. Замовник проводить експертизу зафіксованого варіанта вимог для того, щоб розробник міг далі виконувати його проектування. Один з методів валідації – прототипування, тобто швидке відпрацювання окремих вимог на конкретному інструменті, аналіз масштабу виконання і зміни вимог, вимірювання функціональності і вартості системи, а також визначення зрілості процесів визначення вимог. Верифікація вимог– це процес перевірки правильності специфікації вимог на їхню відповідність стандартам і функціям системи. Внаслідок перевірки вимог створюється остаточний і погоджений документ, що встановлює повноту і коректність вимог до ПЗ, а також можливість продовжити його проектування. Розділ 3 73 3.1.5. Трасування вимог Одна з головних проблем збирання вимог – їхня зміна. Вимоги створюються ітераційно шляхом постійного спілкування представників замовників з аналітиками і розробниками майбутньої системи з метою виявлення необхідних потреб. Вимоги змінюються в міру уточнення функцій і задач, умов їхнього визначення на процесі укладання договору на створення системи і, зрештою, відповідають поглядам замовника на систему [4]. Одним з інструментів установлення залежності між сформульованими вимогами та їхніми змінами є трасування, тобто розвиток і обробка вимог із простежуванням ідентифікованих зв'язків, що повинні бути зафіксовані за двома напрямками – від потреб до робочих продуктів, і навпаки (рис. 3.3.). На процесі розроблення вплив змін у вимогах поширюється в першому напрямку, від потреб до робочих продуктів, а на процесі експлуатації – у зворотному напрямку. Під час цього виявляють причини виникнення різних неточностей, а потім виносять рішення про трасування в одному з наведених напрямків. Рис. 3.3. Схема трасування вимог Якщо після розроблення деякого робочого продукту виникає потреба в зміні окремих вимог або необхідність простежити за проходженням внесених вимог в одному з напрямків даної схеми трасування, то уточнюють зв'язки між окремими вимогами й елементами робочих продуктів. У випадку трасування вимог від продукту здійснюється рух у зворотному напрямкі, тобто рух до вимог шляхом з'ясування правильності написання рядків коду продукту і відповідності їх окремим атрибутам вимог. Трасування в обох напрямках допомагає знайти незаплановані, але реалізовані, деякі функції або фрагменти програм, які не відповідають вимогам, і, навпаки, виявити нереалізовані вимоги до функціональності. Взаємозв'язки і залежності між окремими вимогами можуть зберігатися в таблиці трасування і видалятися або модифікуватися за різних змін. Трасування базується на специфікаціях усіх зв'язків між елементами вимог або обмежується описами функцій, ситуацій, контексту і можливих рішень. Трасуванню піддаються: – вимоги, що змінюються при їхньому формуванні; – деякі деталі виконання функцій у робочому продукті системи, що не передбачалися, але з'явилися в зв'язку з практичною ситуацією, що виникла; – зв'язки між різними моделями процесу проектування системи на ЖЦ і прийняті рішення про необхідність зміни вимог через виявлені недоліки в проміжному або робочому продукті; – інформація про узгодження атрибутів вимог на різних рівнях даної схеми трасування та її матриць; – системні вимоги, наприклад, до повторного використання готових компонентів; 74 Розділ 3 – результати тестування, за якими можна визначити найбільш ймовірні частини коду, що вимагають зміни для виправлення виявлених дефектів. У матриці вимог у рядках указані вимоги користувача, а у стовпцях – функціональні вимоги, елемент проектування, варіант версії й ін. У цих стовпцях заповнюються дані про ступінь виконання системних вимог на кожному об'єкті створюваного продукту. Механізм посилань у таблиці дозволяє перевіряти зв'язки між об'єктами системи. Процедура трасування передбачає: – вибору елемента вимог з матриці, за яким буде відбуватися простежування на процесах ЖЦ; – складання списку питань, за якими на кожному процесі ЖЦ перевіряються зв'язки при реалізації вимог, і, якщо змінюється будь яка ланка в ланцюжку вимог (рис.3.3), то може модифікуватися процедура розроблення цього елемента на наступному процесі ЖЦ; – проведення моніторингу кожної вимоги на відповідність прийнятому плану; – уточнення ресурсів проекту при зміні вимоги або елемента проекту. Умова прийняття рішення про можливі модифікації вимог і результатів проміжного проектування – оновлена інформація про зв'язки між різними частинами системи і первісно заданими вимогами до них. Трасування забезпечує: – введення складних зв'язків замість простих; – використання різних шляхів трасування (між моделями або ієрархічними зв'язками); – трасування об'єктів і зв’язків між ними. Трасування може бути вибірковим для окремих об'єктів або зв'язаним з іншими об'єктами, а також з можливими переходами від однієї моделі проектування до іншої. 3.2. Об’єктно-орієнтована інженерія вимог В об’єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів. Наведені сценаріями або прецедентами вимоги до системи в UML послідовно трансформуються до інших сценаріїв, що наближають до логічної та виконуваної структури системи. Головні їх елементи – сценарії і актори, що задають дії щодо виконання сценаріїв системи. 3.2.1. Візуальний підхід Один з методів побудови моделі системи, логічної і фізичної моделей – це use case, що використовується для візуального зображення вимог у моделі системи, яка уточнюється і доповнюється новими сценаріями для одержання остаточних логічної і фізичної моделей системи. Термін сценарій позначає деякий варіант подання моделі виконання системи [1, 5, 6]. При застосуванні сценарного підходу загальна метасистеми декомпозується на окремі підцілі, для яких визначаються функціональні або нефункціональні вимоги і проектні рішення. Мета як джерело вимог до системи дає змогу виявити протиріччя й обмеження на функції й встановити залежності між ними, усунути конфлікти між цільовими функціями, а також об'єднати деякі з них між собою [11]. Розділ 3 75 Після виявлення цілей визначаються носії інтересів, яким відповідає кожна мета, і можливі варіанти задоволення складених цілей у видгляді сценаріїв роботи системи, що допомагають користувачу одержати уявлення про призначення і виконання функції системи. Це відповідає першій ітерації визначення вимог до системи. Далі виробляється послідовна декомпозиція складної проблеми до вигляду сукупності цілей, кожна з яких трансформується в сукупність можливих сценаріїв використання системи, а потім у сукупність взаємодіючих об'єктів. Тобто, маємо ланцюжок трансформацій: проблема ціль сценарій об'єкт, що характеризує ступінь концептуалізації аналізованої проблеми та її декомпозицію на сценарії з варіантів використання. Трансформація даного ланцюга виражається в термінах базових понять предметної області й активно використовується для подання і розвитку моделей системи. Кожен сценарій ініціює актор, що виступає в ролі користувача визначеної роботи в системі, що зображена цим сценарієм. Фіксацію ролей акторів можна розглядати як визначений крок при виявленні цілей системи і постановки задач, а також рішення, що буде виконувати система. Актор – це зовнішній чинник і його дії мають недетермінований характер. У його ролі може виступати і програмна система, якщо вона ініціює виконання деяких робіт, що задовольняють поставлені цілі системи. Ним може бути абстракція зовнішнього об'єкта, людина або зовнішня система. У моделі системи актор може бути поданий класом, а користувач – екземпляром класу, хоча це і не обов’язково. Якщо актор – це система, то він репрезентує її інтереси. При цьому одна особа може бути екземпляром декількох акторів. Якщо актор знаходиться поза системою, то він взаємодіє з нею через зовнішній сценарій, що ініціює послідовність операцій для виконання системи. Коли користувач як екземпляр актора ініціює певну подію для старту відповідного сценарію, то це приводить до виконання ряду дій у системі, що завершуються тоді, коли екземпляр сценарію перебуває в стані очікування чергової події або завершення сценарію. Екземпляр сценарію існує, поки він виконується і його можна вважати екземпляром класу, він має свій стан і у нього своє поводження. Взаємодія між актором і системою породжує новий сценарій або об'єкт, що змінює внутрішній стан системи. Якщо кілька сценаріїв системи мають однакове поводження, вони створюють клас сценаріїв. При внесенні змін відбувається повторне моделювання дій акторів і сценаріїв, які запускаються ними в дію. Сценарій ініціюється актором і кожний з них обслуговує відповідну сукупність сценаріїв. Для завдання моделі сценаріїв використовується графічна нотація UML з такими правилами: – актор позначається зображенням – іконка людини і можливо з назвою; – сценарій подається овалом, у середині якого назва зображення іконки; 76 Розділ 3 – актор зв'язується лінейкою з кожним овалом сценарію, що запускається ним в дію. Приклад діаграми сценаріїв для читача бібліотеки в ролі актора подано на рис. 3.4. Реєстрація читача Аналіз запиту на книгу Надання книги Запит на здачу книги Читач Рис. 3.4. Приклад діаграми сценаріїв для читача Актор починає заданий сценарій при звертанні до автоматизованої системи обслуговування бібліотеки. Усі сценарії, що містяться у системі, обведені рамкою, яка визначає межі системи, а актор знаходиться поза рамкою як зовнішній чинник системи. Відношення між сценаріями. Між сценаріями відношення задаються стрілками з указівкою назви типу відносин. Для сценаріїв можна задавати два типи відношення: 1) відношення «розширює » означають, що функція одного сценарію є доповненням до функції іншого і використовується при наявності декількох варіантів одного й того самого сценарію (рис. 3.5). Реєстрація книги Пошкодження книги Розширює Рис. 3.5. Приклад відношення «розширює» Інваріантна частина сценарію зображується у вигляді головного сценарію, а окремі варіанти – як розширення. При цьому головний сценарій є стійким, не змінюється при розширенні варіантів функцій і не залежить від них; Розділ 3 77 2) відношення «використовує» означають, що деякий сценарій використовується як розширення інших сценаріїв (рис. 3.6). На рис. 3.6 показано сценарій «ведення репозитарію » , що зв'язаний відносинами «використовує » з декількома сценаріями – розроблення інтерфейсу, опис компонента, створення схеми розгортання. Рис. 3.6. Приклад відносин «використовує» Інженерія вимог завершується побудовою моделі вимог, що містить у собі: 1) опис вимог і основних понять ПрО; 2) модель сценаріїв; 3) інтерфейси сценаріїв. Модель сценаріїв – це неформальний опис кожної з діаграм сценарію, що входять у нього і описується послідовністю таких елементів: – назва сценарію на діаграмі моделі вимог у вигляді посилання до іншого сценарію; – короткий зміст сценарію в неформальному зображенні; – список акторів, що будуть запускати в дію сценарії; – параметри взаємодії системи з акторами, їх заборонені дії і можливі наслідки; – передумови, що визначають початковий стан сценарію на момент його запуску і умови успішного виконання; – функції, що реалізуються при виконанні сценарію; – нестандартні ситуації, що можуть з'явитися при виконанні сценарію (наприклад, помилка в діях актора або системи). На наступних процесах ЖЦ сценарій актора в моделі вимог трансформується в сценарій поводження системи, до елементів моделі можуть додаватися нефункціональні вимоги, що забезпечують запуск сценарію, введення даних і відпрацювання нестандартних ситуацій. У процесі проектування виконується трансформація сценарію в опис функціональних компонентів системи і перевірка їх за допомогою верифікації. Вимоги користувачів до системи відбивають в описі інтерфейсів компонентів, що розміщаються в репозитарії. За допомогою сценаріїв можна побудувати прототип системи для моделювання дій акторів у процесі їхнього виконання і відпрацювання різних їхніх деталей. 78 Розділ 3 3.2.2. Текстовий підхід Альтернативним терміном для сценарію є прецедент. Як і у випадку сценаріїв, задача опису вимог прецедентами зводиться до аналізу дерева цілей системи і до опису реакції системи у випадку недосяжності тієї або іншої поставленої мети щодо проектованої системи. Головною умовою завдання вимог прецедентами є повнота системних вимог до інтерфейсу користувача, до протоколів і форматів ведення [2,5]. Прецедент – це деякий випадок у системі, що міститься у деколькох екземплярах. Екземпляр – це послідовність дій виконання системою, що може бути ініційована конкретним екземпляром актора. Опис прецеденту містить у собі назву і те, що відбудеться в системі, коли прецедент буде виконаний. Набір прецедентів установлює всі можливі шляхи використання системи. При визначенні вимог створюється модель прецедентів, що моделює те, що повинно робити система з погляду потреб користувачів. На рівні реалізації проекту в цю модель додаються технічні вимоги, що зображаються в термінах класів. Змістовна сторона системних вимог – опис функцій, даних і умов функціонування. Методологія формування вимог за допомогою прецедентів реалізована в середовищі Rational Rose (www.rational.com.uml) і передбачає побудову ряду моделей на їхній основі. Прецеденти відіграють визначену їм роль у кожному з основних процесів проектування: розроблення вимог, аналіз і проектування, виконання й випробування системи. Екземпляр прецеденту у реалізації відображає послідовність дій, виконуваних системою, і спостережень за одержанням результату. У керованому прецедентами проекті розробляються два зображення системи – зовнішнє і внутрішнє. Зовнішнє зображення ПрО визначає, що повинно відбуватися в системі, щоб забезпечити замовнику необхідні результати. Після подання цілей системи прецедентами розробляються принципи взаємодії системи і її суб'єктів. Внутрішнє зображення – це принципи організації роботи системи для досягнення запланованих результатів. Воно містить у собі сутності, що беруть участь у виконанні прецеденту, і зв'язки між ними. При цьому кожний із прецедентів виконує визначену дію для досягнення цілі і необхідних результатів у системі. У процесі аналізу проблеми і формування вимог створюється модель прецедентів з відображенням мети системи. Вона складається з: – використовуваних термінів (глосарія) предметної області; – головних діючих осіб і їхніх цілей; – використовуваних технологій і принципів взаємодії з іншими системами; – вимог до форматів і протоколів взаємодії; – вимог до тестування і до процедури розгортання системи у замовника; – організації керування процесом розробки системи. На процесі аналізу і проектування модель прецедентів реалізується в моделі проекту в термінах взаємодіючих об'єктів, тобто дається опис того, як прецедент буде виконуватися в системі. Із синтаксичної точки зору ця модель має такий вигляд. Розділ 3 79 <Модель прецеденту ::= <ім'я прецеденту/діючої особи>, <ім'я ролі / короткий опис ролі діючої особи>, <опис меж системи>, <список усіх зацікавлених осіб при аналізі ключових цілей системи>, <вихідні умови>, <результат успішного занінчення визначення цілей системи>, <кроки сценарію для формування шаблону досягнення цілей проекту>, <опис інформації, необхідної розробнику для реалізації системи>. Даний підхід до зображення системи за допомогою прецедентів можна задавати у формі шаблонів [5], які застосовуються в офісній сфері, де діловий прецедент відбиває зображення цієї сфери з зовнішньої сторони, щоб забезпечити суб'єкта необхідними результатами. При виконанні ділового прецеденту визначається взаємодія ділової сфери і суб'єкта. Сукупність ділових прецедентів установлює межі системи. Внутрішнє зображення ділового прецеденту – це реалізація, що охоплює функції ділових працівників і, відповідно, бере участь у їхньому виконанні, а також зв'язки між ними. Таке завдання системи розробляється для того, щоб вирішити, як повинна бути організована робота системи за допомогою ділового прецеденту. |