Бачення / межі у msf

Згідно з білою книгою MSF [3], на фазі вироблення концепції (envisioning phase) закладається одна з фундаментальних основ успіху проекту - створення і об'єднання проектної групи на основі вироблення єдиного бачення. Проектна група повинна чітко уявити, що вона хоче зробити для замовника і сформулювати свою мету таким чином, щоб максимально мотивувати як замовника, так і саму проектну команду. Вироблення високорівневого погляду на цілі і умови проекту може розглядатися як рання форма планування; вона готує підґрунтя для процесів створення детальних планів, які будуть здійснені безпосередньо під час фази планування.

Основними завданнями фази вироблення концепції є створення ядра проектної групи (див. нижче) і підготовка документу загального опису і меж проекту (vision/scope document). Формування бачення проекту і специфікація його рамок - не одне і теж, хоча для успіху проекту необхідно і те, і інше. Бачення (vision) - це нічим не обмежуване уявлення про те, яким має бути рішення. Межі або рамки (scope) чітко окреслюють, що із запропонованого цим баченням буде реалізовано в умовах існуючих проектних обмежень.

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

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

Провідним ролевим кластером на фазі вироблення концепції є "Управління продуктом".

Шаблон MSF містить наступні розділи:

• Бізнес-переваги,

• Опис переваг

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

• Аналіз зисків

• Концепція рішення

• Цілі, завдання, припущення і обмеження

• Аналіз застосовності

• Вимоги

• Рамки

• Список характеристик/функцій

• Поза рамками

• Стратегія підготовки релізів

• Критерії застосовності

• Експлуатаційні критерії

• Стратегії проектування рішення

• Стратегія проектування архітектури

• Стратегія технічного проектування

Література до теми:

1. Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. – М.: СИН-ТЕГ, 1997.

2. ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания

3. Белые страницы MSF

6.3. Питання для самоконтролю

1. Як відображене «бачення» у різних методологіях?

2. Дайте стислу характеристику розділів «Vision» (RUP).

3. Наведіть приклади атрибутів можливостей.

Тема №7. Класифікація і специфікація вимог

7.1. Методичні вказівки до вивчення теми

Актори і варіанти використання

Як було зазначено раніше, результатом виявлення вимог є реєстр вимог. Вимоги співвласників зазвичай оформлюють у простій письмовій формі, без якої-небудь особливої регламентації. Типовий приклад оформлення вимоги до програми електронної пошти: «Система має дозволяти набирати текст повідомлення з можливістю форматування тексту і вставки зображень». Ці вимоги далеко не в усьому можуть задовольняти критеріям, сформульованим у темі №2: вони можуть суперечити одна одній, бути неясними, неточними тощо. Проте, документ «Вимоги співвласників», незважаючи на невисокий рівень формалізації, відіграє дуже важливу роль: у ньому зібрані думки усіх зацікавлених сторін і головна мета збору початкових вимог – отримати якомога більш повний набір вимог, не пропустивши чогось важливого.

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

Найпопулярнішим і дуже ефективним способом підвищення інформативності вимог є оформлення їх у вигляді варіантів використання (use case), запропонований І.Якобсоном [1].

Перш, ніж перейти власне до специфікації вимог у формі варіантів використання, RUP рекомендує виявити реєстр акторів (actors) і варіантів використання.

Актор - це хтось або щось, що має активність по відношенню до програмної системи. Якщо ви розробляєте простий текстовий редактор, то, швидше за все, вибір актора не складе особливих труднощів: це буде користувач, що набирає текст. Проте не завжди усе так просто. Окрім користувача в якості актора може розглядатися інша програмна система, апаратний пристрій, у ряді випадків – активна компонента самої системи. Пошук акторів корпоративної інформаційної системи зазвичай зводиться до аналізу ролей різних користувачів. Менеджер з продажів, головний менеджер і начальник відділу продажів – один актор, два або три? Це залежить від їхніх функціональних обов'язків, розмежування доступу, способів використання інформаційної системи. Пошук акторів може здійснюватися, наприклад, методом мозкового штурму. Надалі, за необхідності, знайдені актори можуть узагальнюватися, переглядатися і об'єднуватися.

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