Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
se201_pr_2014.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
183.81 Кб
Скачать

3.2 Методичні вказівки до заняття

Завдання 1

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

Завдання 2-3

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

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

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

4 Специфікація вимог до програмної системи

4.1 Ситуаційна вправа

У чудовому рожевому платті вона кружляла по чудовому залі палацу. І от вона побачила свого чарівного принца, який прямував до неї з кришталевою туфелькою в руці. Принц не бачив нікого, крім неї. Звісно ж, він не помітив підніжку цієї злюки – фрейліни. І от результат: Принц падає, туфелька вислизає з його рук і із дзенькотом розбивається. Що ж так довго дзвенить-то? Ой, це будильник.

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

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

Таблиця 3.1 ­– Матриця вибору життєвого циклу

Критерій вибору

Модель

каскадна

спіральна

V-подібна

покрокова

прототипи

Невизначеність вимог

Ні

Так

Ні

Так

Так

Безперервна зміна вимог

Мала

Велика

Мала

Велика

Мала

Дискретизація зміни вимог

Велика

Мала

Велика

Мала

Мала

Складність проекту

Низька

Висока

Низька

Висока

Середня

Вартість застосунків

Низька

Висока

Низька

Середня

Низька

Тривалість використання застосунків

Середня

Тривала

Середня

Тривала

Коротко-

термінова

Функціональні потреби застосунку

Конкретні

Невизна-чені

Конкретні

Невизна-чені

Невизна-чені

Управління ризиками

Ні

Так

Ні

Ні

Так

Технологія виробництва

Готова

Нова

Готова

Нова

Нова

Імовірність повторного використання

Низька

Висока

Низька

Висока

Низька

Легкість використання

Просто

Складно

Просто

Складно

Просто

Якість результатів

Наново

Збері-гається

Наново

Збері-гається

Збері-гається

Продуктивність застосунків

Висока

Висока

Висока

Висока

Низька

Доступність ресурсів

Висока

Будь-яка

Низька

Будь-яка

Будь-яка

Вартість майбутніх версій

Висока

Низька

Висока

Низька

Низька

Сьогоднішній день вона збиралася присвятити новій ідеї генерального. Чомусь її реалізація викликала занепокоєння в Наталки і Сергія, і вони просили не затягувати з результатами. Марічка заварила собі чай і взялася за роботу.

Завдання

1. Сформулювати функціональні і нефункціональні вимоги до CRM-системи.

До кінця робочого дня Марічка зібрала акуратну пачку роздрукованих вимог і поклала її на стіл Сергію. Можна було із чистою совістю відправлятися додому.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]