Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТППС / ТППС-лаб-2012-укр.docx
Скачиваний:
49
Добавлен:
05.06.2015
Размер:
1.11 Mб
Скачать

Лабораторна робота № 2

Тема: Специфікації вимог. Прототипування і розробка додатків

Ціль: Придбання практичних навичок проведення специфікації вимог, прототипування і розробка додатків

Короткі теоретичні відомості:

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

Принципи встановлення вимог

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

Вимоги визначають послуги, очікувані від системи (формулювання сервісів) і обмеження, яким система повинна підкорятися (формулювання обмежень). Ці формулювання сервісів можна об'єднати в кілька груп: одна з груп описує границі системи, друга - необхідні бізнес-функції (функціональні вимоги), а третя - необхідні структури даних (вимоги до даних). Формулювання обмежень можна класифікувати відповідно до різних категорій обмежень, що накладаються на систему, такі як необхідне "враження і відчуття від використання програми", продуктивність, безпека і т.д.

Вимоги необхідно отримати від замовників (користувачів і власників системи). Цей вид діяльності, називаэмий виявленням вимог (requirements elicita-tion), здійснюється аналітиком бізнес-процесів (або системним аналітиком). Для цього підходять різні методи, починаючи з традиційних інтерв'ю з замовником і закінчуючи (при необхідності) побудовою програмного прототипу, за допомогою якого розкриваються додаткові вимоги.

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

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

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

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

Соседние файлы в папке ТППС