7

Лабораторна робота №1 аналіз предметної області, створення переліку вимог до системи, що розробляється, засобами мови uml

Мета: ознайомитися з процесом аналізу предметної області та розроблення моделі системи що розробляється на етапі збору вимог замовника та інформаційного забезпечення аналітиком розробника системи.

Вступна частина

Сутність процесу навчання при виконанні даної лабораторної роботи міститься у наступній послідовності дій:

1. Ознайомлення з основними термінами та визначеннями

2. Ознайомлення з позначеннями концептів в моделі системи, що розробляється засобами Rational Rose

3. Розбір прикладу виконання аналітичної роботи на етапі формулювання вимог замовника та інформаційного забезпечення аналітиком розробника системи для:

   1. Пізнання способу аналізу предметної області

   2. Пізнання способу створення концептуальної моделі системи, що розробляється із застосуванням Rational Rose

   3. Пізнання способу формулювання С-вимог до системи збоку замовника

   4. Пізнання способу формулювання D-вимог у відповідності зі сформульованими С-вимогами

   5. Пізнання способу документування вимог та варіантів використання для інформаційного забезпечення розробника системи

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

Сутність процесу, що має виконати аналітик для створення нформаційного забезпечення для розробника системи полягає у наступній послідовності дій:

Опис проблеми у бізнесі та цілей, що мають бути досягнені (цілі можуть мати вигляд конкретних кількісних або якісних показників)

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

Склад діаграм наступний:

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

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

3. Діаграма процесу (IDEF0) та потоку процедур (IDEF3), на якій чітко зображені не лише потоки об’єктів та процедур, але також і потоки даних, які вони використовують або генерують

4. Опис центрів витрат в головному, допоміжних та управлінських процесах, побудова моделі TO-BE та вибір частин процесу для їх автоматизації

5. Діаграма функцій (Tree Node Diagram), на якій треба помітити функції, які є кандидатами для їх автоматизації

1. Організація відомостей про предметну область в таблицю, інформація з якої має слугувати основою для побудови переліку вимог замовника до системи, що буде автоматизувати його роботу

2. Вибір критеріїв групування вимог для ефективного документування та управління ними на основі наукового аналізу предметної області

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

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

5. Побудова діаграм бізнес-варіантів (потоків даних, документів та задач) для кожного представлення користувача

6. Побудова переліку ключових вимог до системи з боку замовника (С-вимог) та їх документування в таблицю вимог

7. Побудова для кожного бізнес-варіанту переліку сервісів системи, що розробляється, тобто її варіантів використання, необхідних для автоматизації бізнес-варіанту (задачі чи її підзадачі)

8. Деталізація опису С-вимог відповідно до переліку варіантів використання для кожного бізнес-варіанта

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

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

11. Надання кожному варіанту оцінки його важливості (приорітета) під час реалізації С-вимог та групування варіантів використання за пріоритетом

Після виконання пункту 12 аналітик має передати розробнику системи склад варіантів використання з визначеним пріоритетом для кожного варіанта а також модель системи, розроблену в Rational Rose.

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

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

Після цього аналітик та розробник мають розробити рекомендації щодо планування тестів.

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

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

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