Виконала:

студентка групи СН-21

Добривода Наталія

А = 2,94 B = 0,91

Трудомісткість = Кількість Чинників х Середні

Затрати На Чинник

Складні формули, як правило, дуже чутливі до точності великого числа параметрів які треба поставити, щоб одержати необхідні оцінки.

Точкова оцінка трудомісткості пакету робіт нічого не скаже нам про ймовірність того, що на реалізацію цього пакету буде потрібно не

більше, ніж М люд.*міс.

Те, що наша оцінка повинна бути імовірнісним твердженням,

означає, що для неї існує деякий розподіл ймовірності, який може бути дуже широким (висока невизначеність) або досить вузьким (низька невизначеність).

Яка оцінка може вважатися хорошою?

Стів Макконнелл стверджує: «Хорошою вважається оцінка, яка забезпечує

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

цілей»

керівництво і / або замовник бояться переоцінити проект, вважаючи, що

згідно з законом Паркінсона, роботи по проекту займуть весь відведений для

нього час

множити на 2 оцінку трудомісткості, яку зробив програміст

необґрунтовані очікування на застосування нових технологій і засобів розробки

Інженерний метод оцінки трудомісткості проекту

PERT (Program / Project EvaluationandReviewTechnique)

був розроблений в 1958 році в ході проекту зі

створення балістичних ракет морського базування

«Поларіс».

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

оцінками:

– Mi - найбільш ймовірна оцінка трудовитрат.

– Oi - мінімально можливі трудовитрати на реалізацію пакета робіт. Жоден ризик не реалізувався. Швидше точно не зробимо. Імовірність такого, що ми вкладемося в ці витрати, дорівнює 0.

– Pi - песимістична оцінка трудовитрат. Всі ризики реалізувалися.

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

Ei = (Pi+ 4Mi + Oi)/6 Розрахунок середньоквадратичного відхилення :

СКОi = (Pi - Oi)/6 Сумарна трудомісткість проекту може бути

розрахована за формулою:

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

СКО = Оцінка сумарної трудомісткості проекту, яку ми не перевищимо з імовірністю 95%:

= Е + 2*СКО

Якщо ж власний досвід роботи з проектами відсутній, а колеги-експерти

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

галузевому досвіді. Серед них найбільшого поширення набули

два підходи:

- FPA IFPUG - метод функціональних точок

-метод COCOMO II, ConstructiveCostModel

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

Метод розроблений Аланом Альбрехтом в середині 70-х.

Метод був вперше опублікований в 1979 році.

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

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

1.Проект розробки

2. Проект розвитку

3. Продукт

Метод передбачає оцінки трьох типів:

Залежно від типу область оцінки може включати: - Всі розроблювальні функції; - Всі функції що додаються, змінюються і видаляються; - Тільки функції, реально використовувані, або ж всі

функції. Межі продукту визначають: - Що є «зовнішнім» по відношенню до оцінюваного

продукту; - Де розташовується «межа системи», через яку

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

- Які дані підтримуються додатком, а які - зовнішні.

До логічних даних системи відносяться:

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

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

Спочатку визначається складність даних за наступними показниками:

-DET (DataElementType) - неповторюване унікальне поле даних(наприклад: ім'я Клієнта - 1 DET; адреса Клієнта (індекс, країна, область, район, місто, вулиця, будинок, корпус, квартира) - 9 DET's);

-RET (RecordElementType) - логічна група даних (наприклад: адреса, паспорт, телефонний номер).

Матриця складності даних:

Оцінка даних у не вирівняних функціональних точках (UFP) для внутрішніх логічних файлів (ILFs) і зовнішніх інтерфейсних файлів (EIFs):

Приклад оцінки у не вирівняних функціональних точках об'єкта даних «Клієнт»:

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

У методі розрізняють такі типи транзакцій: - EI (ExternalInputs) - зовнішні вхідні транзакції; - EO (ExternalOutputs) - зовнішні вихідні транзакції,

припускають певну логіку обробки або обчислень інформації з одного або більше ILF;

- EQ (ExternalInquiries) - зовнішні запити.

Основні відмінності між типами транзакцій (О - основна; Д - додаткова; NA - не застосовна):

Оцінка складності транзакції ґрунтується на характеристиках:

- FTR (FileTypeReferenced) - дозволяє підрахувати кількість різних файлів типу ILF і / або EIF модифікуються або зчитуються в транзакції.

- DET (DataElementType) - неповторюване унікальне поле даних. Приклади: EI: поле введення, кнопка. EO: поле даних звіту, повідомлення про помилку. EQ: поле введення для пошуку, поле виведення результату пошуку.

Матриця складності зовнішніх вихідних транзакцій і зовнішніх запитів (ЕО &EQ):

Матриця складності зовнішніх вхідних транзакцій (EI):

Складність транзакцій у не вирівняних функціональних точках (UFP):

Діалогове вікно, що управляє перевіркою орфографії в MS Office Outlook:

Загальний обсяг продукту в не вирівняних функціональних точках (UFP) визначається шляхом підсумовування по всіх інформаційних об'єктах (ILF, EIF) та елементарних операціях (транзакціях EI, EO, EQ):

1. Обмін даними 2. Розподілена обробка

даних 3. Продуктивність 4. Обмеження по апаратних

ресурсах 5. Транзакційне

навантаження 6. Інтенсивність взаємодії з

користувачем 7. Ергономіка

8. Інтенсивність зміни даних користувачами

9. Складність обробки 10. Повторне використання 11. Зручність інсталяції 12. Зручність

адміністрування 13. Експортування 14. Гнучкість

Значення фактора VAF залежить від 14 параметрів, які визначають системні характеристики продукту:

14 системних параметрів (degreeofinfluence, DI) оцінюються за шкалою від 0 до 5.

Розрахунок сумарного ефекту 14 системних характеристик (totaldegreeofinfluence, TDI) :

Розрахунок значення фактора вирівнювання:

Наприклад, якщо, кожен з 14 системних параметрів отримав оцінку 3, то їх сумарний ефект складе TDI = 3*14 = 42. У цьому випадку значення фактора вирівнювання буде: VAF = (42 * 0.01) + 0.65 = 1.07

• Початкова оцінка кількості вирівняних функціональних точок для програмного додатка:

AFP = UFP * VAF • Проект розробки продукту оцінюється в DFP

(DevelopmentFunctionalPoint): DFP = (UFP + CFP) * VAF де CFP (ConversionFunctionalPoint) - функціональні точки, підраховані для додаткової функціональності, яка буде потрібна при установці продукту, наприклад, міграції даних

Проект доопрацювання і вдосконалення продукту оцінюється в EFP (EnhancementFunctionalPoint):

EFP = (ADD + CHGA + CFP)*VAFA + (DEL*VAFB)

де ADD - функціональні точки для доданої функціональності;

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

VAFA - величина фактора вирівнювання розрахованого після завершення проекту;

DEL - обсяг вилученої функціональності;

VAFB - величина фактора вирівнювання розрахованого до початку проекту.

Методика COCOMO дозволяє оцінити трудомісткість і час розробки програмного продукту.

Вперше була опублікована Баррі Боемом в 1981 році у вигляді результату аналізу 63 проектів компанії «TRW Aerospace». У 1997 методика була вдосконалена і отримала назву COCOMO II.

Розрізняються дві стадії оцінки проекту:

1) попередня оцінка на початковій фазі;

2) детальна оцінка після опрацювання архітектури.

Формула оцінки трудомісткості проекту в люд.*міс.

має вигляд:

A= 2.94

B=0,91

де SIZE - розмір продукту в KSLOC - множники трудомісткості - фактори масштабу n= 7 - для попередньої оцінки n= 17- для детальної оцінки

Оцінка кількості рядків, необхідних на реалізацію однієї не вирівняної функціональної точки для

деяких поширених мов програмування

У методиці використовуються 5 факторів масштабу SF: 1. PREC - прецедентне, наявність досвід аналогічних розробок 2. FLEX - гнучкість процесу розробки 3. RESL - архітектура і дозвіл ризиків 4. TEAM - спрацьованість команди 5.PMAT-зрілість процесів Значення фактора масштабу, в залежності від оцінки його рівня:

1. PERS - кваліфікація персоналу 2. RCPX - складність і надійність

продукту 3. RUSE - розробка для повторного

використання

4. PDIF - складність платформи розробки

5. PREX - досвід персоналу 6. FCIL - обладнання 7. SCED - стиснення розкладу

Значення множників трудомісткості, залежно від оцінки їх рівня:

Сім множників трудомісткості Mі :

Методика СОСОМО II визначає наступну послідовність обчислення трудомісткості проекту при багатокомпонентній розробці:

1. Сумарний розмір продукту розраховується, як сума розмірів його компонентів:

2. Базова трудомісткість проекту розраховується за формулою:

3. Потім розраховується базова трудомісткість кожного компонента:

4. На наступному кроці розраховується оцінка трудомісткості компонентів з урахуванням всіх множників трудомісткості, крім множника SCED:

5. І, нарешті, підсумкова трудомісткість проекту визначається за формулою:

Тривалість проекту в методиці СОСОМО II:

де C = 3,67; D = 0,28;

- трудомісткість проекту без урахування множника SCED, визначального стиск розкладу

Оцінка трудомісткості повинна бути імовірнісним твердженням.

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

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

Якщо власний досвід аналогічних проектів відсутня, а колеги-експерти недоступні, то необхідно використовувати формальні методики, серед яких найпоширенішими є:

- FPA IFPUG - метод функціональних точок, - метод COCOMO II, ConstructiveCostModel. Нереалістичність оцінок - один з найсерйозніших демотивуючих

факторів для учасників проектної команди.