Лабораторна робота № 6. Метод узгодженої оцінки проекту (PERT)

Мета роботи: За допомогою методу PERT отримати достатньо реалістичні оцінки трудомісткості і терміну реалізації програмного проекту, швидко і без великих витрат.

Короткі відомості

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

Діапазон невизначеності достатньо охарактеризувати трьома оцінками:

Mi — найбільш вірогідна оцінка трудовитрат;

Oi — оптимістична оцінка трудовитрат; мінімально можливі трудовитрати на реалізацію пакету робіт;

Pi — песимістична оцінка трудовитрат;

Задачею проекту була розробка на основі стандартів J2EE загальносистемного ПЗ для переводу робочих місць на нову триланкову архітектуру. Був розроблений набір стандартних компонентів і сервісів, з яких як з конструктора можливо ефективно і якісно збирати прикладні підсистеми. Багаторівнева архітектура реалізувала стандартний шаблон MVC (рисунок 3), кожний з компонентів якого мав «точки розширення» для прикладної розробки, які на рисунку виділені червоним кольором.

Такими точками розширення є:

користувацький екран (UI Form), який збирався з готових візуальних компонентів;

обробники (Action), які оброблювали на сервері додатків подій від активних візуальних компонентів, які входять в склад екрану;

об’єкти (Business Obj), які моделювали прикладну область і до яких звертались обробники подій.

Новий додаток, який розроблюється, містить 20 користувацьких екранів, 60 обробників подій, 16 нових бізнес- об’єктів і 40 нових бізнес-методів, які необхідно додати, як в нові, так і в вже існуючі бізнес-об’єкти

 

Робоче завдання

За допомогою методу PERT розрахувати:

1. Оцінку середньої трудомісткості по кожному елементарному пакету;

2. Середньоквадратичне відхилення;

3. Сумарну трудомісткість проекту;

4. Середньоквадратичне відхилення для оцінки сумарної трудомісткості;

5. Оцінки сумарної трудомісткості проекту з вірогідністю 95%.

 

Рисунок 3. Високорівнева архітектура J2EE Фреймворку для розробки додатків

 

Лабораторна робота № 7. Виконання оцінки проекту на основі LOC і FP метрик

Мета роботи: Сформувати попередні оцінки, які дозволять:

1. пред'явити замовнику коректні вимоги по вартості і витратам на розробку програмного продукту;

2. скласти план програмного проекту.

Короткі відомості

Процес оцінки складається з наступних кроків:

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

2. Для кожної функції планувальник формує оптимістичну, песимістичну і найбільш вірогідну LOC-оцінку.

3. Для кожної функції обчислюється очікуване значення LOC-оцінки

4. Визначається значення LOC-продуктивності розробки функції

5. Обчислюється загальна оцінка витрат на проект

6. Обчислюється загальна оцінка вартості одного рядка

Робоче завдання

Розглядаємо замовлення, яке надійшло від «УкрАВТО». Необхідно створити ПЗ для робочої станції дизайнера автомобіля. Ідентифіковані наступні основні функції ПЗ:

1. Засоби управління користувацьким інтерфейсом (КІ)

2. Аналіз двомірної графіки (2D)

3. Аналіз трьохмірної графіки (3D)

4. Управління базою даних (БД)

5. Засоби комп’ютерної дисплейної графіки (КГ)

6. Управління периферією (УП)

7. Модулі проектного аналізу (МП)

 

1. Заповнити Очікувану оцінку LOC в наступній таблиці:

Таблиця 11. Початкова таблиця оцінки проекту

Функція	Оптимістична (LOC)	Найбільш вірогідна (LOC)	Песимістична (LOC)	Очікувана (LOC)
КІ
2D
3D
БД
КГ
УП
МП
Всього:

 

2. Визначити продуктивність

 

Таблиця 12. Дані з метричного базису фірми

Функція	LOCан	Продуктивністьан (LOC/люд.-міс.)	Продуктивність (LOC/люд.-міс.)
КІ
2D
3D
БД
КГ
УП
МП

3. Розрахувати вартість і витрати

Таблиця 13. Кінцева таблиця оцінки проекту

Функція	Очікувана (LOC)	П_Вартістьан ($/LOC)	Вартість ($)	Витрати
КІ
2D
3D
БД
КГ
УП
МП
Всього

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

1. Знайти очікувану оцінку і кількість

Таблиця 14. Оцінка інформаційних характеристик проекту

Функція	Опт-на	Найб. вірогідна	Песим-на	Очіку-вана	Склад-ність	Кіль-кість
Введення					x4
Виведення					x5
Запити					x4
Логічні файли					x10
Інтерфей-сні файли					x7
Загальна кількість

Кожний коефіцієнт може приймати наступні значення: 0 — нема впливу, 1 — випадкове, 2 — невелике, 3 — середнє, 4 — важливе, 5 — основне.

2. Визначити FP згідно значень з таблиць 14,15.

3. Продуктивність, витрати і вартість.

4. Перевірити достовірність результатів.

Таблиця 15. Оцінка системних параметрів проекту

Коефіцієнт регулювання складності	Оцінка
F1	Передачі даних
F2	Розподілена обробка даних
F3	Продуктивність
F4	Поширеність використовуваної конфігурації
F5	Швидкість транзакцій
F6	Оперативний ввод даних
F7	Ефективність роботи кінцевого користувача
F8	Оперативне оновлення
F9	Складність обробки
F10	Повторне використання
F11	Легкість інсталяції
F12	Легкість експлуатації
F13	Різноманітні умови розміщення
F14	Простота вимірювань
Всього

Лабораторна робота № 8. Засоби оцінки вартості програмного забезпечення

Мета роботи: За допомогою програми SoftStar Systems Costar розрахувати вартість ПЗ на основі власних параметрів.

Короткі відомості

Параметри вартості. Параметр вартості (cost driver) – це суб’єктивна величина, яка оцінює різні часові, якісні і ресурсні аспекти розробки ПЗ. Кожний з параметрів може бути відкаліброваним. Калібрування параметрів вартості – це корегування значень параметрів, яка впливає на значення трудовитрат, і відповідно на час і вартість, при оцінці програмного проекту. При калібруванні вказаних далі сімнадцяти параметрів вибирається оціночний рівень (дуже високий, високий, вище номінального, номінальний, нижче номінального, низький, дуже низький) параметру. В формулах цей рівень відображується у вигляді коефіцієнту трудовитрат і, таким чином, на кожній стадії розробки проекту впливає на вартість і тривалість той або іншої стадії. Виділяють наступні групи параметрів (табл.16): продукту (product factors), платформи (platform factors), персоналу (personnel factors) і проекту (project factors). В табл. 17 наданий короткий опис кожного параметру.

Таблиця 16

Параметри	Опис
Продукту	Враховують характеристики ПЗ, кий розроблюється. (RELY, DATA, CPLX, RUSE, DOCU)
Платформи	Враховують характеристики програмно-апаратного комплексу, який необхідний для функціонування ПЗ. (TIME, STOR, PVOL)
Персоналу	Враховують рівень знань і злагодженості роботи колективу програмістів. (ACAP, PCAP, PCON, APEX, PLEX, LTEX)
Проекту	Враховують вплив сучасних підходів і технологій, територіальної віддаленості членів колективу розробників і терміни виконання проекту. (TOOL, SITE, SCED)

 

Таблиця 17

Параметри	Опис
RELY (Required Software Reliability)	Враховує міру виконання програмою задуманої дії на протязі певного часу
DATA (Database Size)	Враховує вплив об`єму тестових даних на розробку продукту. Рівень цього параметру розраховується як співвідношення байт в тестованій базі даних до SLOC в програмі
CPLX (Product Complexity)	Включає п`ять типів операцій: управління, рахункові, пристрій-залежні, управління даними, управління користувацьким інтерфейсом. Рівень складності це суб`єктивне середньо-зважене значення рівнів типів операцій
RUSE (Developed for Reusability)	Враховує трудовитрати, необхідні додатково для написання компонентів, призначених для повторного використання в даному або наступних проектах. Використовує наступні оціночні рівні: “в проекті”, “в програмі”, “в лінійці продуктів”, “в різних лінійках продуктів”. Значення параметру накладає обмеження на наступні параметри: RELY и DOCU
DOCU (Documentation Match To Life-Cycle Needs)	Враховує степінь відповідності документації проекту його життєвому циклу
TIME (Execution Time Constraint)	Враховує часові ресурси, які використовуються ПЗ, при виконанні поставленої задачі
STOR (Main Storage Constraint)	Враховує процент використання сховищ даних
PVOL (Platform Volatility)	Враховує термін життя платформи (комплекс апаратного і програмного забезпечення, який необхідний для функціонування ПЗ, який розроблюється)
ACAP (Analyst Capability)	Враховує аналіз, здатність проектувати, ефективність і комунікативні здібності групи спеціалістів, які розроблюють вимоги і специфікації проекту. Параметр не повинен оцінювати рівень кваліфікації окремо взятого спеціаліста
PCAP (Programmer Capability)	Враховує рівень програмістів в колективі. При виборі значення для цього параметру слід особливо звернути увагу на комунікативні і професійні здібності програмістів і на командну роботу в цілому
PCON (Personnel Continuity)	Враховує плинність кадрів в колективі
APEX (Applications Experience)	Враховує досвід колективу при роботі над додатками певного типу
PLEX (Platform Experience)	Враховує вміння використовувати особливості платформ, такі як графічний інтерфейс, бази даних, сітьовий інтерфейс, розподілені системи
LTEX (Language and Tool Experience)	Враховує досвід програмістів (мови, середовище і інструменти)
TOOL (Use Of Software Tools)	Враховує рівень використання інструментів розробки
SITE (Multisite Development)	Враховує територіальну віддаленість (від офісу до міжнародних офісів) членів команди розробників засоби комунікації, які ними використовуються (від телефону до відео конференц-зв`язку)
SCED (Required Development Schedule)	Враховує вплив часових обмежень, накладених на проект і на значення трудовитрат

Робоче завдання

Запустити програму Costar 7.0 Demo

Ввести в програму свої параметри (вводити параметри згідно свого варіанту з лабораторної 2, завдання 2):

1 крок – вибрати модель COCOMO II – ранню розробку проекту чи постархітектурну

2 крок – ввести кількість рядків вихідного коду (SLOC)

3 крок – вибрати фактори масштабу (5 характеристик)

4 крок – вибрати Параметри вартості (cost driver) – (17 характеристик)

5 крок - Отримати результат.

Рисунок 4. Детальний звіт

Після появи вікна з результатами (рис.4) – перенести значення, які у червоному обрамлені, в закладку Costs (рис 5)

Рисунок 5. Введення витрат

Вивести вікно результату, де будуть виведені зусилля 1 людино-місяця, строк розробки, вартість.

В методиці використовуються п’ять факторів масштабу SF_;, які визначаються наступними характеристиками проекту:

PREC — прецедентність, наявність досвіду аналогічних розробок (Very Low — досвід в продукті і платформі відсутній; Extra High — продукт и платформа повністю знайомі)

FLEX — гнучкість процесу розробки (Very Low — процес строго детермінований; Extra High — визначені тільки загальні цілі).

RESL — архітектура і дозвіл ризиків (Very Low — ризики невідомі/не проаналізовані; Extra High — ризики дозволені на 100%)

TEAM — спрацьованість команди (Very Low — формальна взаємодія; Extra High — повна довіра, взаємозамінність і взаємодопомога).

PMAT — зрілість процесів (Very Low — CMM Level 1; Extra High — CMM Level 5)

Значення фактора масштабу, в залежності від оцінки його рівня відображено в таблиці 13.

Таблиця 18