Концепція у гост (пост срср)

Відповідно до ГОСТ 34.601-90 «Автоматизовані системи. Стадії створення» [2], після етапу формування (виявлення) вимог до системи виконується етап розробки концепції системи.

Основні роботи етапу:

• Вивчення об'єкту;

• Проведення науково-дослідних робіт (НДР);

• Розробка варіантів концепції АС;

• Оформлення звіту про виконану роботу.

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

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

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

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

Бачення у rup

Кроки, які необхідно пройти для формування документу «Бачення»:

• Формулювання проблем.

• Ідентифікація співвласників

• Визначення меж системи

• Ідентифікація обмежень

• Формулювання постановки завдань

• Визначення можливостей системи

• Оцінка результатів

Для опису проблем пропонується шаблон, наведений у табл.6.1.

Таблиця 6.1.

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

Ідентифікація співвласників припускає пошук і фіксацію інтересантів проекту - представників замовника і виконавця, інвесторів, зовнішніх експертів і ін.

Визначення меж системи є нетривіальним процесом. Для цього використовують контекстні діаграми [1] (див. тему №8 Моделювання вимог). RUP в пошуку меж пропонує відштовхуватися від акторів і варіантів використання.

Серед джерел обмежень зазвичай виділяють:

• Політичні

• Економічні

• Середовища

• Технічні

• Виконання

• Системні.

Опис можливостей системи є формулюванням високорівневих вимог.

Шаблон документу «Vision» RUP містить наступні основні розділи:

1. Вступ

2. Позиціонування

3. Описи співвласників і користувачів

4. Короткий огляд виробу

5. Можливості продукту

6. Обмеження

7. Показники якості

8. Старшинство і пріоритети

9. Інші вимоги до виробу

10. Вимоги до документації

11. Додаток.

У введенні описуються мета документу, його контекст (зв'язок і взаємовплив з різними проектами), визначення, акроніми і скорочення, посилання на інші документи, короткий зміст.

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

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

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

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

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

Розділ «Показники якості» містить опис найбільш суттєвих нефункціональних вимог до системи (ефективності, надійності, відмовостійкості і т.п.)

Розділ «Старшинство і пріоритети» ранжує сформульовані раніше вимоги і можливості системи за ступенем важливості, черговості реалізації тощо.

Розділ «Інші вимоги до виробу» описує вживані стандарти, системні вимоги, експлуатаційні, вимоги до довкілля.

У вимогах до документації наводяться ключові характеристики інструкції користувача, інтерактивної довідки, керівництво зі встановлення і конфігурації, файлу Read Me тощо.

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