• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Експертна думка

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

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

Оцінка за аналогією

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

Тому якість оцінки залежить від наявності подібних даних.

Вартісна оцінка

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

5. Конструктивна вартісна модель (COCOMO)

Метод COCOMO (Constructive Cost Model) і інші методи, отримані від нього, використовують вимірювання, залежні від технології: кількість рядків початкового коду (source code line number, LOC).

Це вимагає підрахунок кількості команд і класифікує їх по наступних групах:

· Органічні проекти. Цей клас містить в собі маленькі проекти, створені висококваліфікованими професіоналами. Домен, прикладні методи і інструменти добре відомі.

· Напіввід'єднані проекти. Члени команди мають різні кваліфікації, і деякі компоненти домена не є добре відомими.

· Дочірні проекти. Проекти розвивають системи з дуже складними вимогами. Домен, прикладні інструменти і методи не відомі. Більшість членів команди не мають досвіду в рішенні схожих проблем.

Метод COCOMO використовує наступну формулу:

Робоче навантаження [працівники * місяці] A * K бета * (експоненціальна залежність) , де K (описується як KDSI, кіло (тисяча) доставлених команд початкового коду (Kilo Delivered Source Code Instructions)). Це означає, що розмір початкового коду вимірюється в тисячах рядків. KDSI не містить коду, який не використала система. Значення а і b залежать від класу, до якого проект відноситься. Вони показані в таблиці.

Таблиця 12.6.1. Робоче навантаження проти рівня складності.

Для маленьких проектів залежність робочого навантаження від KDSI майже лінійна. Динамічність і нелінійність зростає для коду великого розміру.

Мал. 12.6.1. Залежність робочого навантаження від KDSI.

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

Наступні формули оцінюють розмір команди:

Простий проект: Час [місяці] = 2.5* робоче навантаження

Непростий проект: Час [місяці] = 2.5* робоче навантаження

Складний проект: Час [місяці] = 2.5* рабоче навантаження

Підрахунки потрібно скоректувати корегуючими чинниками.

Вони враховують наступні атрибути проекту:

· Вимоги системної надійності,

· Розмір бази даних проти розміру коду,

· Складність системи: складність структур даних, алгоритмів, комунікації з іншими системами, паралельних обчислень,

· Вимоги продуктивності системи,

· Обмеження пам'яті,

· Апаратура і програмне забезпечення, яке створюють середовище.

Недоліки методу COCOMO

Метод COCOMO має багато недоліків. Основний - те, що число рядків початкового коду відоме тільки тоді, коли він написаний. Тому оцінки зазвичай помилкові (до 100%). Оцінка залежить від технології і мови програмування. Один рядок в Smalltalk еквівалентний 30 рядкам в C. Для 4GL коефіцієнт може бути близько 1000:1. Концепція, розроблена на числі рядків початкового коду не задовольняє сучасне візуальне програмування.

Неправильний вибір модифікуючих чинників також може призвести до відмінностей між очікуваною і реальною вартістю проекту. Ідеальних методів не існує. Всі методи засновані на численних приблизних припущеннях. Проте, вони необхідні для таких проектів, оскільки вони кращі, ніж випадкові помилкові припущення.

6. Балова функціональна оцінка

Метод під назвою FPA (Балова функціональна оцінка, Function Points Analysis) був розроблений Albrecht'ом в 1979-1983. Метод комбінує аналіз розміру проекту програмного забезпечення з аналізом програмного продукту. Кількість невиправлених функціональних оцінок обчислюється по формулах:

· Ввід користувача: об'єкти, що вводяться, які впливають на системні дані,

· Вивід користувача: об'єкти, що виводяться, пов'язані з системними даними,

· Внутрішні набори даних: число внутрішніх файлів,

· Зовнішні набори даних: число зовнішніх файлів, написаних процесами,

· Зовнішні питання: інтерфейс з середовищем.

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

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

У FPA одиниця вимірювання - значення функції. Це відноситься до функціональності системи, тобто до категорій продуктивності.

У FPA є п'ять абстрактних класів функціональності:

· функціональність введення зовнішніх даних в систему - системний ввід,

· функціональність отримання внутрішніх даних з системи - системний вивід,

· функціональність внутрішніх структур даних,

· функціональність комунікації із зовнішніми програмами і даними,

· функціональність взаємодій, що не відносяться до потоку даних, - питання до системи.

Мал. 12.7.1. Ваги, привласнені в FPA проектам.

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

Повна складність обчислюється, грунтуючись на вагах в таблиці в кожному невідрегульованому значенні функції (UFP, Unadjusted Function Point). Для цього використовується наступна формула:

UFP - невідрегульоване значення функції,
w – значення ваги,
n – кількість елементів в проекті,
i - порядковий номер оброблюваного елементу,
j – рівень складності.

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

1. Існування комунікаційної апаратури.

2. Розподіл обробки.

3. Час очікування відповіді.

4. Вихід з апаратного робочого навантаження.

5. Частота виконання великих транзакцій.

6. Прямий режим вхідних даних.

7. Продуктивність кінцевого користувача.

8. Пряме оновлення даних.

9. Складність обробки даних.

10. Можливість багатократного використання програми.

11. Інсталяційний пристрій.

12. Сервісний пристрій.

13. Розповсюдження фізичної пам'яті.

14. Пристрій підтримки.

Мал. 12.7.3. Оцінка коректування чинників FPA.

Кожен чинник оцінюється значенням від 0 до 5, де 0 означає нульовий вплив, а 5 - сильний. Оцінка виконується суб'єктивним чином - з використанням інтуїції і досвіду. Кінцева складність функції, тобто число скоректованих покажчиків, обчислюється з формули:

FP = (0,65 + 0,01 * VAF) * UFP
FP = (0,65 ...1,35) * UFP

де:

VAF – комбінований настроювальний коефіцієнт,

FP – значення функції,
K - К-те значення настроювального коефіцієнта.

Приклад обчислення значень функції

1. Послідовність підрахунку значень функції

2. Визначення системи.

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

4. Необхідні набори даних і визначення їх складності.

5. Функціональні елементи і визначення їх складності.

6. Обчислення.

7. Перевірка.

8. Звіти.

Мал. 12.7.5. містить приклад обчислення значення функції.

Мал. 12.7.5. Приклад обчислення значення функції.

Обчислення значення функції

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

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

Функція із значенням 1 дорівнює 125 командам на C

Таблиця 12.7.2. Значення функції порівняно з типом проекту.

Також ми можемо використовувати значення функції для оцінки трудового споживчого чинника проекту. Діаграма, показана нижче, ілюструє взаємозв'язок між трудовим споживанням і значенням функції.

Мал. 12.7.6. Функціональна залежність трудового споживання.

Інші застосування функціональних залежностей:

· Оцінка складності системи

· Перевірка проекту

· Вибір інформаційної системи для перепроектування (вартість підтримки/значення функції)

· Оцінка тестів

· Оцінка якості командної роботи і продуктивності

· Вартість підтримки і прогноз системного розвитку

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

Значення функції і мови баз даних:

(з дослідження продуктивності програмного забезпечення)

Таблиця 12.7.7. Значення функції і бази даних.

(з дослідження продуктивності програмного забезпечення)

Таблиця 12.7.8. Значення функції і продуктивність.

Перевага FPA є мови програмування і його якість. Інші способи вимірювання програм не мають цих переваг. Недолік FPA - суб'єктивність методу в самому заданні значень функції. Ефективність методу може залежати від навиків і "відчуття" аналітика. Автоматичне призначення значень функції неможливе. Іноді суб'єктивність вважається перевагою, подібно до оцінки експертних методів.

Читайте також:

1. Висловлення й думка
2. Виховання, школа і педагогічна думка у Стародавньому Римі. Педагогічні ідеї М.Ф.Квінтіліана
3. Господарська система та економічна думка Західної Європи в ХІ – ХV ст.
4. Господарський роз-к Китаю в осьовий час та його ек.думка. 1 страница
5. Господарський роз-к Китаю в осьовий час та його ек.думка. 10 страница
6. Господарський роз-к Китаю в осьовий час та його ек.думка. 11 страница
7. Господарський роз-к Китаю в осьовий час та його ек.думка. 12 страница
8. Господарський роз-к Китаю в осьовий час та його ек.думка. 13 страница
9. Господарський роз-к Китаю в осьовий час та його ек.думка. 14 страница
10. Господарський роз-к Китаю в осьовий час та його ек.думка. 15 страница
11. Господарський роз-к Китаю в осьовий час та його ек.думка. 2 страница
12. Господарський роз-к Китаю в осьовий час та його ек.думка. 3 страница

Переглядів: 781