Результати стратегічного етапу

Користувач отримує звіт, який містить в собі:

· мета проекту,

· область дії проекту,

· опис зовнішніх систем,

· формулювання основних вимог,

· модель системи,

· пропоноване рішення,

· попередній графік роботи.

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

Короткий звіт

Стратегічний етап - це попередня стадія проекту. Головна мета - доставити відповідні дані, потрібні для проектного стратегічного ухвалення рішення. Це дуже складне завдання, для вдалого виконання якого необхідний досвід.

V. Розпізнавання вимог і документація

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

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

Складнощі у формулюванні вимог

Цей етап дуже важливий. Він визначає успішність проекту. Також це - дуже складне завдання.

Існує багато причин складності цього етапу:

· клієнт зазвичай не знає, як досягти мети,

· існує багато шляхів для рішення завдання,

· великі системи часто використовуються безліччю користувачів, і вони протирічать один одному,

· користувачі можуть спілкуватися, використовуючи різні словники,

· люди, що робили замовлення, і люди, що використовуватимуть систему, можуть бути різними. Люди, що роблять замовлення, можуть не розуміти до кінця всіх потреб.

Рівні опису вимог

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

Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.

Специфікація ПЗ - формальний опис вимог.

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

Якість опису вимог

Хороший опис вимог повинен задовольняти наступні вимоги:

· бути повним і послідовним,

· описувати зовнішній режим роботи,

· описувати обмеження системи,

· бути доступним для модифікування,

· брати до уваги можливі майбутні зміни,

· описувати швидкодію системи в екстремальних або небажаних ситуаціях.

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

Рекоммендациі до правильних визначеннях

Вимоги повинні бути представлені критичним порівнянням з існуючим ПЗ і прототипами. Угода повинна бути складена між розробниками і користувачами. Знання і досвід розробників повинен бути втілені у проект і зрозумілими для замовника.

Вимоги користувача повинні бути:

· зрозумілими,

· унікальними,

· такими, щбо їх можна було перевірити,

· точними,

· реалістичними,

· виконуваними.

Методи ідентифікації вимог

Найбільш важливі методи ідентифікації вимог:

· Зустрічі і огляди (зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекти. Вони повинні проходити серед презентабельної групи користувачів, які прагнуть схвалення проекту).

· Вивчення існуючого ПЗ (часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати з ними нові вимоги, якщо система повинна бути частиною старої).

· Вивчення досяжності (повинні бути визначені реалістичні цілі і методи).

· Прототипування (проектування прототипів систем з меншим об'ємом і спрощеним інтерфейсом).

Методи опису вимог

Системні вимоги можуть бути документовані декількома способами.

Можливі методи:

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

· Математичний формалізм – вживається рідше, ніж колись.

· Структурована звичайна мова. Звичайна мова з обмеженим словником і семантикою. Предмети і проблеми описані в секціях і підсекціях.

· Табліци, форми. Вимоги задані в таблицях (зазвичай двохрівневі), асоційовані різними зв'язками (наприклад, таблиця із зв'язками типів користувачів із сервісами).

· Блоки і діаграми: графічні форми, що зображують процеси.

· Контекстні діаграми: показують системи, оточення, входи і виходи.

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

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

Типи вимог

Основні вимоги розділені на дві групи:

· функціональні вимоги,

· нефункціональні вимоги.

Функціональні вимоги

Описують функції (дії, операції) виконувані системою, що використовує зовнішні системи.

Функціональний опис вимог здійснює:

· ідентифікація всіх типів користувачів системи,

· ідентифікація всіх типів користувачів підтримки, таких як адміністратори, клерки,

· визначення кожного типу користувачів всіх системних функцій і шляхів використання системи,

· опис зовнішніх систем (бази даних, інтернету, мережі), що використовуються системою

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

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

Приклад формулювання вимог з використанням шаблону.

Назва функції	Майстер обробки прибутку
Опис	Функція дозволяє редагувати прибуток платника податків заданого року
Вхідні дані	Дані про доходи, отримані з різних джерел, витрати на отриманий прибуток, податки на різні внески. Інформація про квитанції. Інформація та документи платника податків.
Джерело вхідних даних	Інформація податкової служби
Результат
Початкова умова	Прибуток = весь прибуток - витрати на отриманий прибуток. Весь прибуток, прибуток і витрати на отримання прибутку - всі джерела прибутку.
Кінцева умова	Така ж, як зазначено вище
Побічні ефекти	Змінення бази оподаткування
Причина	Функція дозволяє робити розрахунки швидше і без помилок

Таблиця 5.5.1.

Нефункціональні вимоги

Опис вимог вимагає від предмету, над яким будуть виконануватись певні функції:

· вимога продуктів, наприклад, повинна бути доступна клавіатура,

· вимога процесів, наприклад, процес планувальника повинен виконуватись за стандартом XXXA/06,

· зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.

Хороша форма представлення нефункціональних вимог - це таблиця, наприклад:

№	Дата	Автор	Вимога	Причина	Примітки
	99/04/14	A.Nowak, J.Pietrjak	Програма повинна видавати результат не більше, ніж через 5 секунд при роботі 100 користувачів одночасно	Програма не буде конкурентоспроможною	Може працювати нестабільно
	00/02/05	K.Lubicz	Кожен клієнт повинен мати дуже коротку IP-адресу	Інші ідентифікатори (SIN, Pesel) нестабільні, довгі, можуть повторюватися у різних користувачів
	...	...	...	...	...

Малюнок 5.5.2.

Чинники нефункціональних вимог:

· Системні функції: ієрархія функцій, що виконуються системою,

· Об’єм: скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки сенсорів буде керовано? скільки інформації буде збережено?

· Швидкість: час для виконання операції (або черги операцій), кількість операцій за одиницю часу, максимальний час виконання операції,

· Точність: вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними,

· обмеження: обмеження інтерфейсу, якості, блоку часу, устаткування, засобів програмування і т.п.,

· Інтерфейс зв'язку: мережа, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.,

· Програмний інтерфейс: специфікація устаткування, фізичні обмеження, продуктивність (швидкість процесора, пам'ять), вимоги до офісу, вологість, температура, тиск

· Програмний інтерфейс: сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД),

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

· Адаптивність: специфікація відповіді системи на зміни - нові команди, нове вікно і т.п.,

· Безпека: конфіденційність, приватність, інтеграція, специфікація надійності і т.п.,

· Гнучкість невдач: наслідки помилок ПЗ, помилка живлення, частота збережень, зміна розкладу і т.п.,

· Стандарти: специфікація стандартів документів, форматів файлів, розміри шрифтів, стандарти процесів і продуктів і т.п.,

· Ресурси: бюджет, людський ресурс і обмеження матеріальних ресурсів,

· Час: необхідний час для створення системи, тренування і установки.

Перевірка вимог

Часта помилка формування нефункціональних вимог - нестача критеріїв, визначених для перевірки вимог. Кожна нефункціональна вимога повинна бути перевірена. Це вимагає вибір критеріїв. Деякі критерії:

Характеристика	Міра
Продуктивність	Кількість транзакцій за секунду Час відгуку
Розмір	Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача	Час, потрібний для навчання Розмір документації
Надійність	Вірогідність помилки транзакції Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість	Розмір платформозалежного коду Кількість платформ Вартість перенесення

Малюнок 5.6.1. Перевірка нефункціональних вимог.

Документ з вимогами

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

Приклад такого документа:

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення	Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
1. Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2. Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3. Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги Доповнення

Малюнок 5.7.1. Документ з вимогами.

Послідовність дій, застосованих до документа, повинна бути наступною:.

Якщо немає інформації, записати "не додається".

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

Будь-який матеріал, що не ввійшов до секції, повинен бути доданий в "Додаток".

Часто до документа додаються:

· Вимоги апаратного і програмного забезпечення,

· Модель системи (архітектура),

· Словник (термінологія, акроніми, абревіатури),

· Зміст.

Якість документа з вимогами

Найбільш важливі чинники для якісних вимог:

Стиль

· Ясність: однозначне формулювання, ясне для користувача і розробника,

· Структура документа,

· Відповідність: ніяких протиріч у формуванні вимог,

· Змінність: формулювання по ключових моментах.

Гнучкість

· Можливість додавання нових вимог.

Специфікація ролей

· Можливість пов'язати особу з вимогою, описувати дію вимоги.

Помірність

· Паперовий або електронний варіант,

· Контроль версії документа.

Словник

Не може бути незрозумілих термінів для якої-небудь із сторін.

Всі специфічні треміни повинні бути додані в словник.

Всі невизначеності повинно бути уточнено. Приклад:

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

Малюнок 5.7.2. Словник.

 

Чинники успіху

Ключові чинники успіху етапу формулювання вимог:

· Надання лієнту зразків для усунення неясності,

· повна ідентифікація вимог, виявлення специфічних і виняткових вимог.,

· завершеність і перевірка змісту,

· формулювання нефункціональних вимог в певній формі.

Короткий звіт

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

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

VI. Розробка моделі

Потреба в розробці моделі

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

Яка мета розробки моделі?

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

Розробники інформаційних систем використовують моделі.

Зазвичай створюють наступні моделі:

· модель вимог - описується, наприклад, випадками використання,

· аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,

· модель дизайну - описується мовою UML більш деталізовано. Наприклад, присутні фізичні діаграми.

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

Аналітична модель

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

Наступний етап - етап дизайну. Він відповідає на питання, як система повинна реалізовуватися і описує цю реалізацію.

Границі аналітичної моделі

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

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

· Імпортування в модель елементів із зовнішніх систем робить систему більш загальною і всеосяжною,

· Протягом розробки ми можемо все ще не знати, які готові елементи будуть включені у фінальну версію продукту, а які будуть написані уручну,

· Бюджет може не дозволити повного проектування системи "з нуля", і визначення способів розробки буде проведено під час аналізу.