Лабораторна робота № 1. Розрахунок трудомісткості розробки програмного продукту

Лабораторна робота № 1. Розрахунок трудомісткості розробки програмного продукту

Мета роботи: Навчитися розраховувати трудомісткість ПП

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

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

Надати механізм розрахунку трудомісткості і вартості робіт проекту створення інформаційної системи державних органів на стадії розробки техніко-економічного обґрунтування проекту (до початку проектування інформаційної системи).

Задачі:

Забезпечити єдиний підхід до оцінки трудомісткості і вартості всіх проектів створення інформаційних систем.

Визначити єдині нормативи на створення, розвиток і супровід інформаційних систем.

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

Апаратне забезпечення (обчислювальне й телекомунікаційне устаткування);

Готові програмні продукти (ОС, СУБД, сервера додатків, галузеві додатки й ін.) від ІТ - вендорів (Microsoft, SAP, Oracle, IBM, Fujitsu ін.);

Готові платформи розробки (мова програмування, СУБД, бібліотеки компонентів);

Інженерна інфраструктура (серверні приміщення);

Послуги зв'язку (Інтернет, виділені канали та інш.).

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

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

(1)

Було використано емпіричне правило — зростання розміру ПЗ втроє збільшує трудомісткість розробки і виготовлення в сім раз.

Показник степені зростання трудомісткості з ростом об’єму коду дорівнює 2,35.

де класифікатори проекту створення інформаційної системи:

K₁ - масштаб об’єкту автоматизації;

K₂ - тип замовника;

K₃ - тип програмного забезпечення.

визначаються по таблиці №1

Таблиця №1

К1 – масштаб об’єкту автоматизації	К2 – тип замовника	К3 – тип програмного забезпечення
Автоматизація бізнес процесу одного структурного підрозділу 1	Місцевий виконавчий орган - 8	Готове програмне забезпечення, яке потребує налаштування - 1
Автоматизація бізнес-процесів одного відомства - 8	Центральний державний орган - 14	База даних - 6
Автоматизація бізнес-процесів одного відомства з територіальними підрозділами - 9	Державний орган, діяльність якого пов’язана з небезпекою для життя - 15	Клієнт-серверне (товстий клієнт) - 8
Автоматизація бізнес-процесів відомства і інтеграція з зовнішніми інформаційними системами - 10		Клієнт-серверне (тонкий клієнт) - 11
Автоматизація бізнес-процесів декількох відомств - 12		Сервіс-орієнтоване - 15
Автоматизація бізнес-процесів декількох відомств і інтеграція з зовнішніми інформаційними системами - 13

 

Розмір коду прикладного програмного забезпечення інформаційної системи в тисячах логічних рядків вихідного коду (далі – РК) визначається за формулою 2:

(2)

де КП - коефіцієнт переводу балу функціональності в кількість логічних рядків коду, значення якого визначається за таблицею 1.1 (додаток 1)

Лабораторна робота № 3. Розрахунок чисельності виконавців проекту, строки виконання роботи.

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

 

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

Визначення об’єму і трудомісткості ПЗ

Базою для розрахунку планового кошторису витрат на розробку ПЗ є об’єм ПЗ.

Загальний об’єм (Vз) програмного продукту визначається за формулою 5, виходячи з кількості і об’єму функцій, які реалізуються програмою (додаток 2, табл. 2.1.)

(5)

де V_з – об’єм окремої функції ПЗ;

n – загальне число функцій.

Незважаючи на досить значний перелік видів одиниць виміру
обсягу ПЗ, найбільш широке поширення одержали лише перші три.
Причому функціональні крапки й крапки властивостей дотепер використаються тільки в сполученні з кількістю рядків вихідного коду (LОС). Всі інші види одиниць виміри застосовуються в основному при розробці спеціалізованих проектів.

У даній лабораторній роботі як одиниці виміру обсягу ПЗ використається рядок вихідного коду (LОС). Переваги використання рядків коду як одиниць виміри укладаються в тім, що ці одиниці:

• відображають сутність праці програмістів;

• широко поширені й можуть легко адаптуватися;

• дозволяють виконувати зіставлення розмірів ПЗ й продуктивності в різних групах розроблювачів;

• безпосередньо пов'язані з кінцевим продуктом;

• можуть використатися для оцінки робіт до завершення проекту;

• дозволяють автоматизувати збір даних про кількість LОС від початку до кінця проекту;

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

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

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

Нормативна трудомісткість розробки ПЗ. На підставі прийнятого до розрахунку обсягу (V_з) і категорії складності (додаток 2, табл.2.2.) визначається нормативна трудомісткість ПЗ (Тн), що уточнюється з урахуванням складності й новизни проекту й ступеня використання стандартних модулів при розробці.

Загальна трудомісткість розробки ПЗ. Нормативна трудомісткість (Тн) є основою для визначення загальної трудомісткості (ТД розрахунок якої здійснюється різними способами залежно від розміру проекту. Загальна трудомісткість невеликих проектів розраховується за формулою 6.

(6)

Показник розраховується за формулою .

Значення показників К_С, К_Т і К_Н визначаються з додатку 2 (табл.2.4, 2.5., 2.6.)

Чисельність виконавців (Ч_В) визначається за формулою 7.

(7)

Значення показника Т_Р визначається залежно від строку виконання проекту в місяцях

Ефективний фонд часу роботи одного робітника (Ф_ЕФ) розраховується за формулою 8.

(8)

де:

Д_Р - кількість днів в році;

Д_С - кількість святкових днів в році;

Д_В - кількість вихідних днів в році;

Д_ВС – кількість днів відпустки.

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

В моделі СОСОМО використовуються три режими, за допомогою яких класифікується складність системи, а також середовище розробки.

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

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

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

Модель COCOMO поділяється на рівні: базовий, проміжний, деталізований. Значення драйверів витрат (додаток 3, табл.3.1)

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

1. Розрахувати за базовим рівнем моделі COCOMO трудовитрати (Е) і визначити час розробки (TDEV). Визначити середню чисельність персоналу (SS) і рівень продуктивності (Р), якщо:

Варіант 1. розмір проекту, який розроблюється, оцінюється в 10 KLOC.

Варіант 2. розмір проекту, який розроблюється, оцінюється в 300 KLOC.

Варіант 3. розмір проекту, який розроблюється, оцінюється в 50 KLOC.

Варіант 4. розмір проекту, який розроблюється, оцінюється в 55 KLOC.

Варіант 5. розмір проекту, який розроблюється, оцінюється в 320 KLOC.

Варіант 6. розмір проекту, який розроблюється, оцінюється в 25 KLOC.

Варіант 7. розмір проекту, який розроблюється, оцінюється в 72 KLOC.

Варіант 8. розмір проекту, який розроблюється, оцінюється в 85 KLOC.

Варіант 9. розмір проекту, який розроблюється, оцінюється в 400 KLOC.

Варіант 10. розмір проекту, який розроблюється, оцінюється в 7,5 KLOC.

 

2. Визначити режим складності системи за проміжним рівнем моделі COCOMO, якщо:

Варіант 1. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат ACAP, PCAP, TIME, DATA, PLEX змінюються до високих, всі інші значення номінальні.

Варіант 2. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат RELY, DATA, PVOL, PCAP, змінюються до низьких, всі інші значення номінальні.

Варіант 3. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат ACAP, CPLX змінюються до високих TIME, DATA, PLEX змінюються до низьких, всі інші значення номінальні.

Варіант 4. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат TIME, PLEX, CPLX, змінюються до дуже високі, всі інші значення номінальні.

Варіант 5. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат TOOL, SCED змінюються до низьких, PLEX, STOR змінюються до дуже високі, всі інші значення номінальні.

Варіант 6. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат CPLX, STOR, DOCU, РСАР змінюються до дуже високих, всі інші значення номінальні.

Варіант 7. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат ACAP, APEX, PCAP, PLEX змінюються до низьких, всі інші значення номінальні.

Варіант 8. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат CPLX, SCED змінюються до дуже низькі, АСАР змінюються до низьких, всі інші значення номінальні.

Варіант 9. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат RELY, DATA, ACAP, PCAP, STOR змінюються до низькі, всі інші значення номінальні.

Варіант 10. розмір проекту за першим завданням відповідно варіанту; значення множників (драйверів) витрат SITE, TOOL змінюються до дуже низькі, SCED змінюються до низьких, всі інші значення номінальні.

3. Оцінити трудовитрати, тривалість і середню чисельність персоналу проекту по моделі COCOMO II (для попередньої оцінки). Значення S згідно варіанту завдання 1. Показник Rj середній рівень (таблиця 3), Zi – високий рівень (таблиця 4).

 

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

Аналіз функціональних точок — стандартний метод вимірювання розміру програмного продукту з точки зору користувачів системи.

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

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

· Визначення типу оцінки.

· Визначення області оцінки і границь продукту.

· Підрахунок функціональних точок, пов’язаних з даними.

· Підрахунок функціональних точок, пов’язаних з транзакціями.

· Визначення сумарної кількості не вирівняних функціональних точок (UFP)

· Визначення значення фактору вирівнювання (VAF)

· Розрахунок кількості вирівняних функціональних точок (AFP)

 

 

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

1. Визначити оцінки в не вирівняних функціональних точках об’єкту даних «Студент» (рис.1)

Рисунок 1. База даних студент

Складність даних визначається на основі матриці складності (табл.6)

Таблиця 6

	1-19 DET	20-50 DET	50+ DET
1 RET	Низька	Низька	Середня
2-5 RET	Низька	Середня	Висока
6+ RET	Середня	Висока	Висока

 

В залежності від типів файлів відбувається оцінка даних (табл.7)

Таблиця 7

Складність даних	Кількість UFP (ILF)	Кількість UFP (EIF)
Низька
Середня
Висока

 

2. Підрахунок функціональних точок, пов’язаних з транзакціями

Визначити оцінку управляючої транзакції для діалогового вікна (рис.2)

Рисунок 2. Діалогове вікно Параметри Word

Для оцінки складності транзакцій служать матриці, які представлені в таблицях 8,9.

Таблиця 8

EI	1-4 DET	5-15 DET	16+ DET
0-1 FTR	Низька	Низька	Середня
2 FTR	Низька	Середня	Висока
3+ FTR	Середня	Висока	Висока

Таблиця 9

EO & EQ	1-5 DET	6-19 DET	20+ DET
0-1 FTR	Низька	Низька	Середня
2-3 FTR	Низька	Середня	Висока
4+ FTR	Середня	Висока	Висока

 

Оцінка транзакцій в невирівнених функціональних точках (UFP) може бути отримана з таблиці 10.

Таблиця 10

Складність транзакцій	Кількість UFP (EI)	Кількість UFP (EO& EQ)
Низька
Середня
Висока

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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	Простота вимірювань
Всього

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

Параметри вартості. Параметр вартості (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

	Very Low	Low	Nominal	High	Very High	Extra High
PREC	6.20	4.96	3.72	2.48	1.24	0.00
FLEX	5.07	4.05	3.04	2.03	1.01	0.00
RESL	7.07	5.65	4.24	2.83	1.41	0.00
TEAM	5.48	4.38	3.29	2.19	1.10	0.00
PMAT	7.80	6.24	4.68	3.12	1.56	0.00

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

 

1. На рисунку 6 представлений програмний текст методу SumAndProduct. Визначити послідовність лексем.

2. Привести секціановану абстракцію методу SumAndProduct.

3. Розрахувати сильну і слабу зв’язаність по даним, визначити клейкість даних.

Рисунок 6. Секція даних для методу SumAndProduct

 

4. Визначити астрактний клас для стеку (рис.7)

5. Розрахувати для класу Stack метрики зв’язаності

Рисунок 7. Відношення між елементами класу Stack

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

 

1. Визначити кількість пар методів класу (рис.8)

2. Обчислити метрику LCOM

Рисунок 8.Структура класів для розрахунку метрик Чидамбера-Кемерера

 

Лабораторна робота № 1. Розрахунок трудомісткості розробки програмного продукту

Мета роботи: Навчитися розраховувати трудомісткість ПП

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

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

Надати механізм розрахунку трудомісткості і вартості робіт проекту створення інформаційної системи державних органів на стадії розробки техніко-економічного обґрунтування проекту (до початку проектування інформаційної системи).

Задачі:

Забезпечити єдиний підхід до оцінки трудомісткості і вартості всіх проектів створення інформаційних систем.

Визначити єдині нормативи на створення, розвиток і супровід інформаційних систем.

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

Апаратне забезпечення (обчислювальне й телекомунікаційне устаткування);

Готові програмні продукти (ОС, СУБД, сервера додатків, галузеві додатки й ін.) від ІТ - вендорів (Microsoft, SAP, Oracle, IBM, Fujitsu ін.);

Готові платформи розробки (мова програмування, СУБД, бібліотеки компонентів);

Інженерна інфраструктура (серверні приміщення);

Послуги зв'язку (Інтернет, виділені канали та інш.).

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

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

(1)

Було використано емпіричне правило — зростання розміру ПЗ втроє збільшує трудомісткість розробки і виготовлення в сім раз.

Показник степені зростання трудомісткості з ростом об’єму коду дорівнює 2,35.

де класифікатори проекту створення інформаційної системи:

K₁ - масштаб об’єкту автоматизації;

K₂ - тип замовника;

K₃ - тип програмного забезпечення.

визначаються по таблиці №1

Таблиця №1

К1 – масштаб об’єкту автоматизації	К2 – тип замовника	К3 – тип програмного забезпечення
Автоматизація бізнес процесу одного структурного підрозділу 1	Місцевий виконавчий орган - 8	Готове програмне забезпечення, яке потребує налаштування - 1
Автоматизація бізнес-процесів одного відомства - 8	Центральний державний орган - 14	База даних - 6
Автоматизація бізнес-процесів одного відомства з територіальними підрозділами - 9	Державний орган, діяльність якого пов’язана з небезпекою для життя - 15	Клієнт-серверне (товстий клієнт) - 8
Автоматизація бізнес-процесів відомства і інтеграція з зовнішніми інформаційними системами - 10		Клієнт-серверне (тонкий клієнт) - 11
Автоматизація бізнес-процесів декількох відомств - 12		Сервіс-орієнтоване - 15
Автоматизація бізнес-процесів декількох відомств і інтеграція з зовнішніми інформаційними системами - 13

 

Розмір коду прикладного програмного забезпечення інформаційної системи в тисячах логічних рядків вихідного коду (далі – РК) визначається за формулою 2:

(2)

де КП - коефіцієнт переводу балу функціональності в кількість логічних рядків коду, значення якого визначається за таблицею 1.1 (додаток 1)