Вивчення документів та аналогічних систем

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

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

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

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

16. Нарада. «Мозковий штурм».

Нарада

Нарада – скликаються для досягнення консенсусу в питаннях визначення вимог до застосувань і швидкого прийняття рішення про те, в якому направлені працювати; при чому все це здійснюється в короткий період часу. Основні зацікавлені особи збираються на невеликий, але інтенсивно використовуваний період, як правило, не більш ніж на 1-2 дні. Нарада проводиться одним із членів команди.

Мозковий штурм (МШ)

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

МШ є дуже корисним методом при проведенні нарад і в тих випадках, коли потрібні нові ідеї або творчі рішення проблем.

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

Даний процес має ряд переваг:

Підтримує участь всіх присутніх;

Дозволяє учасникам розвивати ідеї один одного;

Ведучий або секретар веде запис всього ходу обговорення;

Його можна застосовувати при різних обставинах;

Як правило, в результат - множина можливих рішень для будь-якої поставленої проблеми;

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

МШ складається з двох фаз: генерації ідей і їх відбір. Основна мета на етапі генерації – описати як можна більше ідей, не обов’язково глибоких. На етапі відбору головною задачею є аналіз усіх ідей, що виникли. Відбір ідей включає в себе відсічення (відтинання), організацію, впорядкування, розвиток, групування і уточнення.

Виділяють:

«Живий» мозковий штурм.

«Веб» мозковий штурм

Всі учасники збираються в одній кімнаті і їм роздаються матеріали для заміток. Це може бути звичайна стопка паперу і чорний товстий маркер. Кожному учаснику потрібно видати не менше 25 листків паперу на кожний сеанс МШ. Далі пояснюються правила проведення мозкового штурму і визначається мета засідання.

Правила проведення:

Не допускається критика або дебати.

Необхідно дати волю фантазії.

Необхідно генерувати якомога більше ідей.

Можна переробляти і комбінувати ідеї.

Ведучий пояснює мету процесу. Наприклад наступні питання представляють собою декілька варіантів постановки мети:

Якими властивостями, по Вашому, має бути наділений продукт?

Які послуги, по Вашому, має надавати продукт?

Які параметри, по Вашому, має відслідковувати продукт?

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

Кожний учасник записує свої ідеї на листочки. Це важливо по наступним причинам:

Щоб вони було сформульовані саме словами автора.

Щоб гарантувати, що вони не будуть втрачені

Щоб їх можна було розвивати далі (в подальшому).

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

По мірі створення ідей ведучий просто збирає їх і прикріпляє їх до стіни кімнати засідань. Тут знову – ніякої критики.

Інколи під час генерації ідей виникає період затишшя. Це не значить, що пора зупиняти процес. Таке затишшя закінчується, як тільки з’являється нова ідея. Більш тривалі періоди затишшя можуть бути приводом для того, щоб ведучий знову повторив мету або задав аналогічне питання. Більшість нарад по генерації ідей триває близько години (інколи 2-3 години). Не при яких умовах ведучий не повинен закінчувати засідання, що активно йде. Для учасників це буде означати «Ваші ідеї не такі важливі, як мій графік». Число ідей, що виникли залежить від того, наскільки плідний предмет, що обговорюється (зазвичай їх 100-200).

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

17. Прототипування. Класифікація прототипів

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

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

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

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

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

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

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

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

Класифікація прототипів:

В даний час усі види прототипів прийнято класифікувати наступним чином:

- За призначенням: горизонтальні і вертикальні;

- За глибиною опрацювання: одноразові і еволюційні

- В залежності від використовуваних інструментальних засобів: розкадровки і електронні прототипи

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

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

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

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

Вертикальні прототипи

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

"Одноразовий" прототип (досліджуваний прототип) (ОП), який після того, як виявлення вимог завершено, просто відкидається. Розробка "одноразового"прототипу націлена лише на етап встановлення вимог ЖЦ ПЗ. Як правило, цей прототип дозволяє вирішити незрозумілості і покращити вимоги до ПЗ.

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

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

Еволюційний прототип (evolutionary prototype), який зберігається після виявлення вимог і використовується для створення кінцевого програмного продукту. Еволюційний прототип націлений на прискорення поставки продукту.

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

На відміну від одноразових прототипів, що створюються «швидко та начорно», для побудови еволюційного прототипу необхідно з самого початку використовувати відмінний і якісний код. Тому на конструювання еволюційного прототипу потрібно більше часу.

Остаточний продукт – кульмінація серії еволюційного. Такі прототипи дозволяють користувачам швидко отримати діючі зразки. Еволюційний прототип добре підходять для застосувань, які з часом будуть розширятися. (Інтернет застосування).

18. Створення прототипів з використанням програмних засобів.

19. Розкадровка. Основні види.

Розкадровка

Розкадровка (storyboard) - це логічний та концептуальний опис функціональних можливостей системи для певного сценарію, включаючи необхідну взаємодію між системою та її
користувачами. В якості інструментальних засобів розкадровки вимог використовуються Microsoft Word, Microsoft Visio, Microsoft PowerPoint, IBM Rational Requirements Composer, Expression
Blend SketchFlow.

Розкадровки ділять на три типи:

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

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

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

20. Поняття аналізу. Загальні методи та засоби аналізу.

21. Засоби уніфікованої мови моделювання UML для аналізу вимог

22. Діаграми варіантів використання

23. Метод системного аналізу

24. Діаграми бізнес-процесів та потоків даних

Діаграма потоків даних (DFD) являються основним засобом моделювання функціонування вимог до системи, що проектується. З їх допомогою ці вимоги представляються у вигляді ієрархії функціональних компонентів (процесів), зв’язаних потоками даних.

Головна мета такого представлення – продемонструвати, як кожний процес перетворює свої вхідні дані у вихідні, а також виявити відношення між цими процесами.

Для побудови ДФД традиційно використовуються дві нотації, що відповідають методам Йордана і Гейна-Сарсона. Ці нотації дещо відрізняються один від одного графічним зображенням символів.

Основними компонентами ДФД є:

1. Зовнішні сутності

2. Процеси

3. Накопичувачі даних

4. Потоки даних

25. Методологія SADT.

Методологія САДТ – одна з найвідоміших методологій аналізу проектування систем. Більше 10 років САДТ була «перервою» та технологією, до середини 80х років, поки не з»явилися ПК з графічними можливостями.

Одним із перших програмних компонентів структурно-функціонального аналізу на основі САДТ був пакет AUTOIDEF, розроблений в межах програми ВПС США.

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

Моделі, що орієнтовані на функції називають функціональними, а на предмети системи – моделями даних.

За допомогою САДТ методології вирішуються наступні основні задачі:

· Аналіз функцій, що виконується системою;

· Опис специфікацій вимог і функцій системи, що проектується

· Проектування системи.

Метод САДТ представляє собою сукупність правил і процедур, призначених для побудови функціональної моделі об’єкта будь-якої предметної області.

Функціональна модель САДТ відображає функціональну структуру об’єкта. Тобто вироблені ним дії і зв’язки між цими діями.

Основні елементи методу САДТ ґрунтуються на наступних концепціях:

1. Графічне представлення блокового моделювання

2. Строгість і точність

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

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

Правила САДТ:

1. Обмеження кількості блоків на кожному рівні (3-6)

2. Зв’язність діаграм (номери блоків)

3. Унікальність міток та найменувань (відсутність імен, що повторюються)

4. Синтаксичні правила для графіки (блоків і дуг)

5. Розділ входів і управлінь (як правило визначення ролі даних).

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

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