Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем
Досліджені існуючі методи оцінювання характеристик проектів, на основі яких з урахуванням досвіду виконання проектів запропоновано методику оцінювання економічних характеристик проектів, що поєднує методи експертних оцінок, FPA та COCOMO. Експериментально перевірено можливість використання оцінок за...
Збережено в:
| Дата: | 2004 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
Інститут програмних систем НАН України
2004
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/1343 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем /І.А. Стрєлов, П.П. Ігнатенко // Проблеми програмування. — 2004. — N 1. — С. 38-51. — Бібліогр.: 13 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860251542716678144 |
|---|---|
| author | Стрєлов, І.А. Ігнатенко, П.П. |
| author_facet | Стрєлов, І.А. Ігнатенко, П.П. |
| citation_txt | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем /І.А. Стрєлов, П.П. Ігнатенко // Проблеми програмування. — 2004. — N 1. — С. 38-51. — Бібліогр.: 13 назв. — укр. |
| collection | DSpace DC |
| description | Досліджені існуючі методи оцінювання характеристик проектів, на основі яких з урахуванням досвіду виконання проектів запропоновано методику оцінювання економічних характеристик проектів, що поєднує методи експертних оцінок, FPA та COCOMO. Експериментально перевірено можливість використання оцінок за мето дом FPA як вхідних даних для моделі COCOMO. За результатами експериментальних випробувань оцінено ефективність застосування методики на даних по виконаних проектах і показано, що розбиття даних на класи для калібрування моделі COCOMO підвищує точність оцінок.
|
| first_indexed | 2025-12-07T18:43:59Z |
| format | Article |
| fulltext |
Методы и средства программной инженерии
© І.А. Стрєлов, П.П. Ігнатенко, 2004
38 ISSN 1727-4907. Проблемы программирования. 2004. № 1
УДК 681.3.06
І.А. Стрєлов, П.П. Ігнатенко
ПІДХІД ДО ОЦІНЮВАННЯ ЕКОНОМІЧНИХ
ХАРАКТЕРИСТИК ПРОЕКТНИХ РІШЕНЬ ПРИ РОЗРОБЦІ,
МОДИФІКАЦІЇ ТА РЕІНЖИНІРИНГУ ПРОГРАМНИХ
СИСТЕМ
Досліджені існуючі методи оцінювання характеристик проектів, на основі яких з
урахуванням досвіду виконання проектів запропоновано методику оцінювання еко-
номічних характеристик проектів, що поєднує методи експертних оцінок, FPA та
COCOMO. Експериментально перевірено можливість використання оцінок за мето-
дом FPA як вхідних даних для моделі COCOMO. За результатами експериментальних
випробувань оцінено ефективність застосування методики на даних по виконаних
проектах і показано, що розбиття даних на класи для калібрування моделі COCOMO
підвищує точність оцінок.
Вступ
Оцінювання характеристик, важ-
ливих в економічному аспекті, при ви-
конанні проектів з розробки, модифі-
кації або реінжинірингу ПС є необхід-
ною складовою процесу керування
розробкою та супроводженням життє-
здатних ПС [1]. Застосування методів
оцінювання економічних характерис-
тик дозволяє більш точно прогнозувати
як матеріальні ресурси, необхідні для
реалізації проекту, так і людські та ча-
сові ресурси. Це дає можливість при-
ймати обгрунтовані рішення щодо фо-
рмування пакету нових розробок ПС в
організації, a також доцільності проек-
тів модифікацій чи реінжинірингу су-
проводжуваних ПС. Внаслідок цього
можна точніше планувати процеси ви-
конання як окремого проекту, так і па-
ралельних.
З іншого боку, існуюча система
сертифікації рівня технологічної зріло-
сті SEI CMM ставить впровадження в
організації методики оцінки розміру
проектів (одна з характеристик, роз-
глядуваних у статті) як основну вимогу
для отримання сертифікату рівня CMM
Level 3.
Отже, використання методів оці-
нки економічних характеристик проек-
тів значно підвищує рівень технологіч-
ної зрілості організації – розробника
ПС, яка їх застосовує [2].
У даній статті висвітлено наступ-
ні задачі розглядуваної проблеми:
• здійснено огляд існуючих ме-
тодів оцінки економічних характерис-
тик проектів з розробки, модифікації
та реінжинірингу ПС;
• розроблено підхід та запропо-
нована методика оцінювання ефектив-
ності проектних рішень при розробці,
модифікаціях чи реінжинірингу ПС з
урахуванням досліджених методів;
• розглянуто питання ефектив-
ності застосування пропонованої мето-
дики.
1. Існуючі методи оцінювання
проектів
В галузі управління проектами з
розробки ПС гостро стоїть проблема
оцінювання проектів з розробки, мо-
дифікації чи реінжинірингу ПС в аспе-
кті необхідних для їх виконання ресур-
сів, бюджету та строків. Існування цієї
проблеми пов’язане з тим, що процес
створення ПС є процесом перетворен-
ня специфікацій та вимог до системи у
програмні коди готової ПС. Складність
управління такими процесами викли-
кана складністю вимірювання характе-
ристик цих процесів для отримання кі-
лькісних характеристик вхідної та ре-
зультуючої інформації, складністю мо-
делювання цих процесів. За відсутності
засобів підтримки прийняття цих рі-
шень управління проектами часто ве-
деться методом проб та помилок, а ус-
піх залежить від досвіду та інтуїції ке-
рівника.
Методы и средства программной инженерии
39
Найголовнішими економічними
характеристиками, що впливають на
ефективність управління проектами, є
такі:
• розмір проекту;
• трудомісткість;
• час, необхідний для виконання;
• вартість.
Існуючі підходи до оцінювання
цих характеристик можна класифіку-
вати за їх застосуванням та ступенем
формалізації, як показано на рис. 1.
Методи, що базуються на експе-
ртних оцінках, більш універсальні і
можуть застосовуватися у різних цілях,
тоді як модельні прив’язані до конкре-
тної цілі. Внаслідок цього експертні
методи є найбільш широко застосову-
ваними. Модельні ж методи, як для
вимірювання розмірів розроблюваних
систем, так і моделювання процесів
розробки, потребують менших витрат
при їх застосуванні та дають результа-
ти, які є об’єктивними та легко переві-
ряються [2—4].
Коротко розглянемо методи,
приведені на рис. 1. Детально вони
описані в існуючій літературі [2—3].
1.1. Експертні методи. Звичай-
ний метод експертних оцінок. Цей
метод [5] базується на використанні
неформалізованих знань експертів у
певній проблемній області. При цьому
результати залежать від підготовки,
досвіду або навіть настрою чи стану
здоров’я експерта. Також варіюються
потреби експертів у документації по
оцінюваному проекту, хоча зазвичай
чим більше даних про проект може
обробити експерт, тим точнішою буде
оцінка. Важливою є наявність докуме-
нтації по раніше виконаних проектах з
тієї ж прикладної області зі схожими
вимогами.
Метод Delphi. Метод Delphi [6] є
розвитком методу експертних оцінок у
напрямку підвищення об’єктивності та
зниження похибки оцінки за рахунок
компенсації розбіжностей в оцінках
різних експертів.
Для зниження похибки викорис-
товуються результати оцінки декількох
експертів, а для підвищення об’єк-
тивності обмін результатами між ними
здійснюється анонімно. Практичне за-
стосування цього методу виглядає так:
• Обираються від 2 до 5 експер-
тів для участі у робочій групі.
• Кожен експерт отримує пакет
проектної документації, необхідні дові-
дкові та історичні матеріали і форму
для внесення до неї результатів.
• Експерти збираються на зу-
стріч, на якій обговорюються всі необ-
Ступінь
формалізації
Експертні
методи
Модельні
методи
COCOMOFPA COSMIC
FFPMkII FPA Експертна
оцінкаDelphi Розбиття
на підзадачі
Область
застосування
Оцінювання
розміру
SLOC
Розрахунок
зусиль та часу
розробки
Будь-яка
Рис. 1. Класифікація методів оцінювання проектів
Методы и средства программной инженерии
40
хідні організаційні та технічні моменти
щодо визначення розміру проекту.
• Кожен експерт робить власну
оцінку, використовуючи будь-який уз-
годжений метод, та анонімно заносить
результати до форми.
• Експерти збираються на зу-
стріч, де обговорюються найнижча та
найвища оцінки, при цьому авторство
оцінок не розкривається.
• Якщо експерти не можуть дій-
ти згоди щодо найнижчої та найвищої
оцінок, процес продовжується з кроку 3.
Перевагою такого методу є біль-
ша точність оцінки, недоліком – збі-
льшення потреби у людських та часо-
вих ресурсах у порівнянні зі звичай-
ним методом експертних оцінок про-
порційно кількості задіяних експертів.
Експертна оцінка з розбиттям
проекту на підзадачі. Цей метод [5] є
розвитком методу експертних оцінок у
напрямку підвищення об’єктивності та
зниження похибки оцінки за рахунок
розбиття проекту на менші задачі, які
або легше піддаються оцінюванню, або
вже мають добре відому та чітко ви-
значену оцінку. Звичайно вимагається,
щоб ієрархія задач мала не менше двох
та не більше трьох рівнів у глибину.
Кількість задач на кожному рівні не
обмежується. Розбиття проекту та оці-
нювання окремих задач можуть вико-
нуватися різними експертами.
Перевагою такого методу є біль-
ша точність та можливість перевірити
результат, не повторюючи процедуру
оцінювання, недоліком – потреба у
більших часових ресурсах у порівнянні
зі звичайним методом експертних оці-
нок.
1.2. Методи оцінки розміру.
SLOC (Source Lines Of Code). Цей ме-
тод [7] базується на вимірюванні най-
більш очевидної характеристики про-
грамного забезпечення – кількості ря-
дків коду у вихідних текстах.
Головними недоліками методу є
різне трактування поняття “рядок ко-
ду” для різних мов програмування, різ-
ний розмір однієї і тієї ж системи за-
лежно від мов та технологій, викорис-
таних для її створення, залежність кі-
лькості рядків коду від стилю його
написання.
Позитивними рисами цього ме-
тоду є його наочність, легкість автома-
тизації, відсутність необхідності у на-
вчанні спеціалістів, які будуть викори-
стовувати цей метод, легкість перевір-
ки результатів. Завдяки цим якостям
метод SLOC набув широкого застосу-
вання, оскільки головні його недоліки
можна компенсувати введенням стан-
дартів на стиль написання коду та чіт-
ким визначенням поняття рядка коду.
FPA (Function Point Analysis). Го-
ловною метою розробників методу FPA
[8] було встановлення загальної одини-
ці виміру функціонального розміру
програмного забезпечення (ПЗ), шкали
виміру та методу вимірювання функці-
онального розміру. На відміну від ме-
тоду SLOC функціональний розмір
(ФР) не залежить від технологій, вико-
ристаних для створення системи, сти-
лю написання коду або мови програ-
мування. За стандартом ISO/IEC, фун-
кціональний розмір програмного за-
безпечення є кількісною мірою його
функціональності та визначається як
кількісна оцінка функціональних вимог
користувача до ПЗ. Функціональні ви-
моги визначають процеси та процеду-
ри, які будуть виконуватися ПЗ, або,
іншими словами, що буде програма ро-
бити. ФР не залежить від того, як буде
ПЗ працювати (наприклад, від вимог до
якості або продуктивності), або від
особливостей реалізації ПЗ. Метод FPA
придатний до вимірювання ПЗ у всіх
сферах застосувань і був успішно за-
стосований у широкому колі проектів,
від систем керування ракетною зброєю
до систем фінансової звітності. FPA ба-
зується на таких поняттях: користувач
(людина або ПЗ, які обмінюються ін-
формацією з вимірюваним ПЗ), межа
ПЗ (відокремлює ПЗ, що вимірюється,
від користувачів), елементарний про-
цес (будь-який обмін інформацією між
ПЗ та користувачем, тут розрізняються
на зовнішній ввід – ЗВВ, зовнішній
вивід – ЗВ, зовнішній запит – ЗЗ),
файл (розрізняються внутрішні логічні
файли – ВЛФ та зовнішні інтерфейс-
Методы и средства программной инженерии
41
ні файли – ЗІФ), елемент (елементар-
ний процес або файл).
Після ідентифікації елементів ви-
значається їх рівень складності та від-
повідна кількісна оцінка в одиницях
функціональності. Функціональний роз-
мір всього ПЗ отримується як сума
оцінок його елементів.
Для оцінки складності елементів
розглядаються такі їх характеристики,
як кількість задіяних елементарних да-
них (ЕТД), типів записів (ТЗ) та типів
файлів (ТФ).
Функціональний розмір елемен-
тів системи залежно від кількості заді-
яних ТФ, ТЗ та ЕТД визначається спе-
ціальними таблицями.
Нарешті, розмір всієї системи в умо-
вних одиницях функціональності отри-
мується як
+++= ∑∑∑ ЗВВЗІФВЛФ SizeSizeSizeSize
∑∑ ++ ЗЗЗВ SizeSize .
MkII FPA (Mark II Function Point
Analysis). Метод MkII [9] є клоном ори-
гінального методу FPA, орієнтованим
на оцінювання систем, що працюють з
базами даних. За MkII система склада-
ється з трьох типів елементів:
Вхідні дані, що надходять у сис-
тему, перетинаючи її межу.
Результуючі дані, що виходять із
системи, перетинаючи її межу.
Обробка даних – процес, який
використовує вхідні дані та породжує
результуючі.
На відміну від FPA метод MkII
включає всі випадки повторного вико-
ристання одних і тих же типів даних у
загальну оцінку.
Показник функціонального роз-
міру системи розраховується за фор-
мулою
обробррезрезвхвх WNWNWNSize ×+×+×= ,
де N – відповідно кількість вхідних або
результуючих даних або процесів об-
робки даних, а константи W мають зна-
чення Wвх = 0.58, Wрез = 0.26, Wобр = 1.66 [5].
COSMIC FFP (Common Software
Measurement International Consortium
Full Function Points). COSMIC FFP [10]
базується на тих самих визначеннях
межі ПЗ та елементарного процесу, що
і FPA. Але, на відміну від нього, відпові-
дно до [10], система складається з про-
цесів переміщення та обробки даних.
Для оцінювання розміру у сис-
темі виділяються чотири типи базових
процесів: зовнішній ввід, зовнішній ви-
від, внутрішнє зчитування, внутрішній
запис.
Зовнішні операції відбуваються
між виділеним шаром системи та ко-
ристувачем, при цьому перетинаючи
межу системи, тоді як внутрішні відбу-
ваються між шарами системи всереди-
ні межі.
Розмір i-го шару системи у оди-
ницях Cfsu (Cosmic Functional Size
Unit) отримується як
++= )()( вивідCardввідCardSizei
)()( записCardзчитуванняCard ++ ,
де Card (множина) – це потужність
множини підпроцесів певного типу.
Оцінювання процесів маніпулю-
вання даними у методі версії v.2.2 не
було визначене.
1.3. Методи оцінювання трудо-
місткості, тривалості та вартості прое-
ктів. COCOMO (Constructive Cost
Model). В основі моделі COCOMO ле-
жить припущення [11], що розмір сис-
теми (Size), виражений у одиницях
SLOC, та величина зусиль, необхідних
для розробки проекту, виражена у лю-
дино-місяцях (person-month – PM),
пов’язані співвідношенням вигляду
BSizeAPM +×= loglog .
Це припущення було перевірено
на базі, яка включала 161 проект з
розробки ПЗ [12]. На цій же базі було
визначено фактори, які мають значний
вплив на хід виконання проекту. Від-
повідні кількісні їх значення входять у
змінні A та B.
Розрахунок зусиль на розробку.
Оцінка зусиль на виконання проекту (у
людино-місяцях) за COCOMO прово-
диться за наведеними формулами. Ін-
декс NS у значень PM та TDEV позначає
те, що ці оцінки зусиль та тривалості
Методы и средства программной инженерии
42
відносяться до номінального розкладу,
тобто обрахованого за моделлю
COCOMO. Бюджет, виражений у лю-
дино-місяцях NSPM оцінюється за фор-
мулою
∏
=
××=
17
1i
i
E
NS EMSizeAPM , де
∑
=
×+=
5
1
01.0
j
jSFBE , (1)
де константи A та B дорівнюють відпо-
відно 2.94 та 0.91 [13]; EMi – мульти-
плікативні фактори; SFj – експонен-
ційні фактори COCOMO. Розмір має
бути вираженим в одиницях KSLOC
(1 KSLOC = 1000 SLOC).
Розрахунок тривалості та ціни.
Тривалість розробки (time to develop –
TDEV) TDEVNS оцінюється за формулою
F
NSNS PMCTDEV )(×= ,
де
)(2.001.02.0
5
1
BEDSFDF
j
j −×+=××+= ∑
=
,
де константи C та D дорівнюють відпо-
відно 3.67 та 0.28 [13].
Вартість проекту отримується
множенням кількісної величини зу-
силь, виражених у людино-місяцях, на
вартість людино-місяця.
2. Підхід до створення методики
оцінювання економічних
характеристик проектів з розробки,
модифікацій та реінжинірингу ПС
Розглянемо коротко рішення, які
приймаються у цьому аспекті в біль-
шості організацій, ролі, задіяні у про-
цесі оцінювання, та методи прийнят-
тя рішень, що при цьому використо-
вуються.
Рішення – про відповідність
проекту профілю організації-розробни-
ка (наявність обладнання та програм-
ного забезпечення, досвіду розробки,
можливість забезпечення потрібного
рівня якості), про визначення розміру
проекту, необхідних для його виконан-
ня зусиль, графіка та терміну вико-
нання, складу проектної команди, вар-
тості проекту, економічну доціль-
ність, прийняття проекту у розробку.
Ролі – вище керівництво, пред-
ставник замовника, менеджер проекту,
технічний керівник проекту, член про-
ектної команди.
Методи прийняття рішень –
експертна оцінка (використовується
для отримання оцінок розміру проекту
в цілому та окремих його частин, та-
кож цей метод застосовувався для без-
посереднього оцінювання зусиль та
розкладу виконання проекту), експер-
тна оцінка із розбиттям проекту на
підзадачі.
Недоліки існуючого підходу:
• немає визначеної схеми взає-
модії ролей та прийняття рішень під
час оцінювання проектів;
• використовуються виключно
методи експертних оцінок;
• не використовуються методи
визначення розміру проектів та не
встановлено внутрішні стандарти на
оцінки розміру.
Вимоги до створюваної методики
оцінювання. Така методика повинна:
• давати оцінки для розміру,
бюджету, вартості та тривалості проек-
ту;
• бути застосовною на всіх ета-
пах виконання проекту та на етапі роз-
гляду його доцільності;
• якнайменше залежати від екс-
пертних оцінок;
• використовувати базу даних
параметрів раніше виконаних проектів;
• визначати процедуру внесення
змін у саму методику.
2.1. Підхід до створення методи-
ки оцінювання. Аналіз застосовності
досліджених методів та їх викорис-
тання. Як уже було відмічено, най-
більш важливими параметрами проекту
для управління є його розмір, трудомі-
сткість, час, необхідний для виконан-
ня, та вартість. Серед них три остан-
ні залежать від першого – розміру.
Тому можна виділити два етапи:
• оцінювання розміру;
• оцінювання трудомісткості,
вартості та тривалості з використанням
вже отриманого значення розміру.
Методы и средства программной инженерии
43
Для 2-го етапу добре підходить
модель COCOMO, оскільки вона роз-
роблялася саме з метою оцінки бю-
джету, вартості та тривалості проектів і
є зараз найбільш широко застосовува-
ною моделлю. Модель COCOMO вико-
ристовує як вхідний параметр розмір
ПС у рядках вихідного коду (SLOC).
Отримати точний розмір у таких оди-
ницях можна лише після завершення
проекту. На будь-якому попередньому
етапі розмір має визначатися за допо-
могою експертних оцінок або деякої
методики оцінювання розміру проекту,
яка може дати оцінку в одиницях
SLOC. У той же час найкращим вибо-
ром для оцінювання розміру проекту є
метод FPA: він має об’єктивний харак-
тер, простий у застосуванні, найбільш
широко використовуваний в індустрії
розробки ПЗ, має статус міжнародного
стандарту та загально доступний. Роз-
мір ПС, отриманий за допомогою FPA,
можна використати у моделі COCOMO,
оскільки для багатьох мов програму-
вання існують залежності між розмі-
ром ПС у одиницях UFP та SLOC [2].
Існуючі методи експертних оці-
нок також включені в схему, оскільки
застосування більш формалізованих
методів у певних випадках може бути
неможливим або невигідним.
Схема поєднання згаданих мето-
дів приведена на рис. 2.
Організаційні аспекти підходу
до оцінювання проектів. Запропонова-
на організаційна схема наведена на
рис. 3, де процес оцінювання ділиться
на чотири етапи:
а) підготовка – вибір методу
оцінювання, планування процесу оці-
нювання;
б) виконання – підготовка вхід-
них даних, оцінювання розміру, зусиль
та вартості, термінів виконання проек-
ту, підготовка звіту про оцінювання;
в) перевірка – контроль отри-
маних результатів, збір даних про про-
цес оцінювання;
г) аналіз та покращення проце-
су оцінювання – зміна процесу оціню-
вання.
Особливості застосування мето-
ду FPA. Для успішного використання в
пропонованому підході методу FPA не-
обхідно попередньо оцінити такі його
характеристики: стабільність оцінок,
які дає цей метод, їх узгодженість зі
Проектна
документація
Знання експертів
у проблемній
області
Інформація про
організацію та
процеси розробки
FPA Оцінка розміру
проекту (UFP)
Експертна
оцінка
COCOMO
Оцінка
трудомісткості,
тривалості та
вартості
Оцінка розміру
проекту (KSLOC)
Дані по
виконаних
проектах
Рис. 2. Покриття цілей оцінювання за допомогою методів FPA та COCOMO.
Методы и средства программной инженерии
44
статистикою по індустрії ПС, узго-
дженість оцінок між проектами.
Підхід використовує припущення
про існування співвідношення розмірів
проектів в одиницях SLOC та UFP.
Причому величина цього співвідно-
шення для різних проектів однакова.
Ці припущення були підтверджено
експериментально.
Особливості застосування моде-
лі COCOMO. Модель COCOMO дає
змогу отримати більш точні результати,
якщо відкалібрувати її за даними по
історичних проектах, тобто визначити
такі значення параметрів моделі, які б
відображали особливості виконання
проектів в умовах конкретної органі-
зації.
У рівнянні COCOMO для оцінки
бюджету проекту присутні дві калібро-
вочні константи A та B.
Допустимо, є дані по n проектах.
Нехай nj ,1= – порядковий номер
проекту. Після логарифмування та оче-
видних перетворень рівняння (1) мати-
ме такий вигляд:
−
−=×+ ∏
=
17
1
loglogloglog
i
ijjj EMPMSizeBA
j
i
ij SizeW log01.0
5
1
×
×− ∑
=
.
Позначимо
Менеждер проекту
Технічний керівник
Розробник
Вище керівництво
1.1
Вибір методу
оцінювання
1.2
Планування процесу
оцінювання
2.1
Підготовка вхідних
даних
2.2
Оцінювання
розміру
2.3
Оцінювання зусиль
та вартості
2.4
Оцінювання термінів
виконання
2.5
Підготовка звіту
про оцінювання
3.1
Перевірка резуль-
татів
3.2
Збір даних про процес
оцінювання
4.1
Зміна процеса
оцінювання
Рис. 3. Повна схема процесу оцінювання проекту
Методы и средства программной инженерии
45
−
−= ∏
=
17
1
loglog
i
ijjj EMPMD
j
i
ij SizeW log01.0
5
1
×
×− ∑
=
,
тоді jj DSizeBA =×+ loglog або у вектор-
ному вигляді
[ ]=
BA
SizeSizeSize n
log
log...loglog
1...11
21
[ ]nDDD ...21= ,
Якщо ввести позначення
[ ]nDDDY ...21= ,
=
nSizeSizeSize
X
log...loglog
1...11
21
,
[ ]BAK log= ,
то матимемо YXK = , звідки можна от-
римати ( ) YXXXK TT 1−
= або
×
= ∑
=
n
j
jj SizeD
Det
A
1
log1log
×
−
× ∑∑∑
===
n
j
j
n
j
j
n
j
j SizeDSize
1
2
11
loglog ,
−
= ∑∑
==
n
j
j
n
j
j SizeD
Det
B
11
log1
×− ∑
=
n
j
jj SizeDn
1
log ,
( ) −
== ∑
=
2
1
logdet
n
j
j
T SizeXXDet
×− ∑
=
n
j
jSizen
1
2log .
Таким чином, можна отримати
значення калібровочних констант для
певних умов виконання проектів.
Комплексну схему виконання про-
понованого підходу відображає рис. 4.
3. Експериментальна перевірка
застосовності пропонованого підходу
Було проведено оцінювання еко-
номічних характеристик декількох ви-
браних проектів, що виконувалися в
організації.
Оцінка ефективності застосу-
вання методу FPA. В експерименті
брали участь декілька експертів. Підбір
проектів та експертів проводився за
такими критеріями:
Співставлення розрахунків за COCOMO та реальних значень
0
50
100
150
200
250
300
1 2 3 4 5 6 7 8 9 10 11 12
№ проекту
Зу
си
лл
я,
л
ю
ди
но
-м
іс
яц
і
Фактичні значення COCOMO, стандартна калібровка
COCOMO, локальна калібровка
Рис. 4. Співставлення розрахунків за моделлю COCOMO з фактичними даними
Методы и средства программной инженерии
46
• проект реалізовано на мові
C++ або Java;
• експерт мав досвід у відповід-
ній прикладній області або мав змогу
звернутися до розробника проекту за
поясненнями;
• процес оцінювання мав покри-
ти весь діапазон розмірів існуючих
проектів.
В результаті було отримано такі
дані (табл. 1):
Таблиця 1. Результати оцінювання проектів за методом FPA
№ проекту 1 2 3 4 5
Розмір, SLOC 8377 7321 18862 15425 27123
Розмір, UFP (1) 126 119 461 337 456
Розмір, UFP (2) 122 107 — — 378
Розмір, UFP (3) 90 — — — —
Середнє значення 112.67 113.00 — — 417.00
СКВ 16.11 6.00 — — 39.00
Відносне СКВ 14% 5% — — 9%
Мова програмування C++ C++ Java C++ Java
В табл. 1 наведено дані по п’яти
проектах, які незалежно оцінювали від
одного до трьох експертів. Розбіжності
у результатах достатньо малі.
Якщо згрупувати оцінки за мо-
вою програмування, то отримаємо на-
ступні результати (табл. 2):
Таблиця 2. Статистика відношення SLOC/UFP для мов програмування
№ оцінки C++ Java
1 66.48 40.92
2 68.66 59.48
3 93.08 71.75
4 61.52 —
5 68.42 —
6 45.77 —
Середнє значення 67.32 57.38
СКВ 13.94 12.68
Відносне СКВ 23% 21%
Враховуючи точність методу FPA,
можна стверджувати, що між розміром
системи в одиницях UFP та SLOC існує
достатньо чітка відповідність.
Оцінка ефективності застосу-
вання методу COCOMO. Проекти від-
биралися за такими критеріями:
метою проекту було створення,
модернізація чи реінжиніринг програ-
мної системи;
проект розроблявся з викорис-
танням не більше двох різних мов про-
грамування;
проект використовував такі мови
програмування, для яких чітко визначе-
ні правила підрахунку кількості рядків;
проект є зовнішнім замовленням.
Ці умови найбільш відповідають
тим, для яких розроблялася модель
COCOMO.
Методы и средства программной инженерии
47
Методика визначення парамет-
рів проектів для моделі COCOMO. Да-
ні по параметрах проектів наведено у
табл. 3. У стовпчику “№ проекту” за-
значений його номер у списку. Назви
не наводяться через конфіденційність.
Величини зусиль на виконання проекту
було взято з проектної документації. Ці
значення відображають фактично ви-
трачений робочий час у людино-
годинах. Значення змінної PM (люди-
но-місяці) було розраховано, виходячи
із зусиль у людино-годинах та типової
кількості робочих годин за місяць –
152, згідно [11].
Значення SLOC отримано шля-
хом підрахунку кількості рядків всього
вихідного коду, який розроблено та
модифіковано у ході виконання проек-
ту. Для цього було використано пакет
CodeCount, створений у Центрі про-
грамної інженерії Університету Пів-
денної Каліфорнії.
Значення змінних EAF та SF ви-
значалися за результатами опиту мене-
джерів відповідних проектів. Однакові
значення змінних EAF відповідають
схожим умовам розробки проектів з
огляду на досвід проектної команди та
якості вимог до проекту. Зменшення
цих значень для певних проектів пояс-
нюється наявністю досвіду, який було
отримано під час розробки попередніх
проектів, завдяки чому були розробле-
ні більш чіткі та повні вимоги до прое-
ктів, покращилося розуміння розроб-
никами прикладної області.
Змінна SF характеризує органі-
зацію та її персонал в цілому, тому її
значення для різних проектів однакові,
оскільки у період, протягом якого роз-
роблялися обрані проекти, суттєвих
змін в організації, проектних командах
або процесах розробки не відбувалося.
Калібрування моделі COCOMO
та аналіз результатів. Розрахунки
проводилися за вищенаведеними фо-
рмулами. Отримані результати зведе-
ні у табл. 4 (стовпчик „Локальна калі-
бровка”).
Таблиця 4. Результати калібрування
моделі COCOMO
Константа Стандартна
калібровка
Локальна
калібровка
A 2.54 2.23
B 0.91 0.49
Для порівняння у стовпчику
“Стандартна калібровка” наведені зна-
чення констант для стандартної каліб-
ровки моделі COCOMO.
За результатами калібрування
розраховані зусилля на розробку прое-
ктів. Отримані значення, результати
обчислень за стандартною калібров-
кою, фактичні дані та відхилення у від-
Таблиця 3. Вихідні дані для калібрування COCOMO
№ проекту Зусилля PM KSLOC EAF SF
1 514 3.38 1.20 0.54 25.35
2 1718 11.30 8.38 0.54 25.35
3 1976 13.00 14.64 0.54 25.35
4 3758 24.72 18.86 0.48 25.35
5 848 5.58 9.71 0.80 25.35
6 5265 34.64 34.46 0.80 25.35
7 5635 37.07 15.43 0.80 25.35
8 438 2.88 7.82 0.80 25.35
9 485 3.19 7.63 0.80 25.35
10 512 3.37 8.50 0.80 25.35
11 521 3.43 3.68 0.80 25.35
12 3843 25.28 54.35 0.80 25.35
Методы и средства программной инженерии
48
сотках від фактичного значення подані
у табл. 5.
Ці ж результати у графічному
вигляді подані на рис. 4. Можна бачи-
ти, що калібрування моделі за базою
історичних проектів дозволяє отримати
оцінки, у більшості випадків більш
близькі до фактичних, ніж з викорис-
танням стандартної калібровки. Але
навіть для моделі з локальною калібро-
вкою існує розкид відхилень оцінок від
фактичних значень (стовпчик “Відхи-
лення, %, локальна калібровка”). Існу-
ють наступні можливі причини таких
відхилень: мала вибірка, шуми або
«викиди» вихідних даних, різні мови
програмування проектів.
Для перевірки третьої причини,
впливу специфіки мови програмуван-
ня, модель COCOMO було відкалібро-
вано за двома різними вибірками
проектів для мов C++ та Java. Ре-
зультати калібрування наведено у
табл. 6.
Таблиця 5. Результати обчислень за каліброваною моделлю
№
п/п
PM
фактичне
PM, стан-
дартна
калібровка
Відхилення, %,
стандартна
калібровка
PM, локальна
калібровка
Відхилення, %,
локальна
калібровка
1 3.38 1.96 42% 1.37 60%
2 11.30 18.83 67% 6.40 43%
3 13.00 16.09 24% 5.75 56%
4 24.72 43.03 74% 10.84 56%
5 5.58 33.11 493% 10.66 91%
6 34.64 144.57 317% 29.14 16%
7 37.07 56.75 53% 15.40 58%
8 2.88 25.73 793% 8.97 211%
9 3.19 25.03 685% 8.81 176%
10 3.37 28.38 742% 9.60 185%
11 3.43 10.72 213% 4.94 44%
12 25.28 109.66 334% 24.13 5%
Таблиця 6. Результати калібрування моделі COCOMO для різних мов
програмування
Константа Стандартна
калібровка
Локальна
калібровка
Калібровка
для мови C++
Калібровка
для мови Java
A 2.54 2.23 5.44 0.59
B 0.91 0.49 0.41 0.88
Таблиця 7. Результати калібрування моделі COCOMO для мови C++ у
порівнянні з калібровкою для всіх проектів
№
п/п
PM
фактичне
PM,
калібровка по
всіх проектах
Відхилення, %,
для всіх
проектів
PM,
калібровка по
C++ - проектах
Відхилення, %,
для C++ -
проектів
1 3.38 1.38 59% 3.31 2%
2 11.30 5.90 48% 12.00 6%
3 13.00 5.33 59% 10.98 16%
4 37.07 13.78 63% 26.65 28%
Методы и средства программной инженерии
49
Видно, що параметри моделі для
різних мов суттєво відрізняються. Ре-
зультати застосування відкаліброваних
моделей наведено у табл. 7, 8 та у гра-
фічному вигляді на рис. 5, 6. Для мови
C++ максимальне відхилення стано-
вить 28%, що є прийнятним для вико-
ристання, проте результати не можуть
вважатися достовірними, оскільки
отримані за малою кількість вихідних
даних. Результати для мови Java є не
такими вражаючими, і максимальне
відхилення становить 70%, проте такі
оцінки вже можуть використовуватися
як орієнтири для подальшого процесу
оцінювання.
Висновки
У статті досліджені існуючі мето-
ди оцінювання окремих характеристик
проектів, на основі яких, з урахуван-
ням досвіду виконання проектів, за-
пропоновано комплексну методику
оцінювання економічних характерис-
тик проектів, що поєднує методи екс-
пертних оцінок, FPA та COCOMO.
Запропоновано та експеримента-
льно перевірено можливість викорис-
Таблиця 8. Результати калібрування моделі COCOMO для мови Java у
порівнянні з калібровкою для всіх проектів
№
п/п
PM
фактичне
PM,
калібровка по
всіх проектах
Відхилення, %,
для всіх
проектів
PM,
калібровка по
Java - проектах
Відхилення, %,
для Java-
проектів
1 24.72 9.61 61% 7.79 68%
2 5.58 9.75 75% 6.13 10%
3 34.64 25.12 27% 25.66 26%
4 2.88 8.30 188% 4.80 67%
5 3.19 8.15 155% 4.68 47%
6 3.37 8.84 162% 5.28 57%
7 3.43 4.73 38% 2.05 40%
8 25.28 35.30 40% 42.93 70%
Рис. 5. Співставлення розрахунків для калібровок за всією вибіркою та за
проектами на C++
Результати калібрування для C++
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
1 2 3 4
№ проекту
Зу
си
лл
я,
л
ю
ди
но
-м
іс
яц
і
Фактичні зусилля Калібровка за всіма даними
Калібровка за C++ проектами
Методы и средства программной инженерии
50
тання оцінок за методом FPA як вхід-
них даних для моделі COCOMO. За ре-
зультатами експериментальних випро-
бувань методики оцінено ефективність
застосування методів FPA та COCOMO
на даних по виконаних проектах і по-
казано, що розбиття даних на класи
для калібрування моделі COCOMO
підвищує точність оцінок.
Використання формалізованої
методики оцінювання економічних ха-
рактеристик проектів дає певні перева-
ги: по-перше, її застосування зменшує
витрати на оцінювання проектів, по-
друге, при систематичному її викорис-
танні можливе покращення точності
оцінок за рахунок уточнення моделей
та їх параметрів на даних по виконува-
них проектах а, фактично, уточнення
методики.
Крім того, впровадження форма-
лізованих методів оцінювання має на-
ступні позитивні особливості, які не є
очевидними:
• при проведенні аналізу систе-
ми з огляду на оцінки розміру виявля-
ються помилки, незрозумілі місця та
неповні описи у вимогах до системи,
що дозволяє зменшити кількість дефе-
ктів у системі на самому ранньому
етапі розробки;
• спеціаліст, який має досвід в
оцінюванні проектів за цими методами,
буде здатний розробляти вимоги до на-
ступних проектів із урахуванням необ-
хідності їх вимірювання, а як результат
– вимоги будуть більш структурова-
ними, легше піддаватимуться вимірю-
ванню та міститимуть менше дефектів;
• наявність певної структури ре-
зультуючих документів дає можливість
створити шаблони документації, які ав-
томатизують розрахунки та конверта-
цію одиниць вимірювання, використо-
вуваних різними методами;
• документи, створені за цими
шаблонами, можуть слугувати також
засобом накопичення даних по істори-
чних проектах. Наявність певної струк-
тури в таких документах дає змогу ав-
томатизувати збір цих даних.
1. Ігнатенко П.П. Проблеми забезпечення
життєздатності програмних систем та під-
ходи до їх вирішення // Пробл. програм. –
2002. – №3—4. – С. 58—73.
2. Основы инженерии качества программных
систем. / Андон Ф.И., Коваль Г.И., Коро-
тун Т.М., Суслов В.Ю. – К.: Академперио-
дика, 2002. – 504 с.
3. Методика определения затрат на создание
автоматизированных систем (версия 1.1) /
Волощук А.С., Коваль Г.И., Коротун Т.М.,
Суслов В.Ю., Портяной В.С., Слабоспиц-
Рис. 6. Співставлення розрахунків для калібровок за всією вибіркою та за
проектами на Java
Результати калібрування для Java
0.00
5.00
10.00
15.00
20.00
25.00
30.00
35.00
40.00
45.00
50.00
1 2 3 4 5 6 7 8
№ проекту
Зу
си
лл
я,
л
ю
ди
но
-м
іс
яц
і
Фактичні зусилля Калібровка за всіма даними
Калібровка за Java проектами
Методы и средства программной инженерии
51
кая О.С. – К.: Институт программных сис-
тем, 1998. – 53с.
4. Boehm B.W., Abts C., Chulani S. Software de-
velopment cost estimation approaches. A sur-
vey // Annals of Software Engineering. –
2000. – 10. – P. 177—205.
5. Devnani-Chulani S. Bayesian Analysis of Soft-
ware Cost and Quality Models – dissertation
// Computer Science Department, USC Cen-
ter for Software Engineering, 1999. – 231 p.
6. Turoff M., Linstone H.A. The Delphi Method
Techniques and Applications. – Los Ange-
les, CA.: University of Southern California,
1992. – 618 p.
7. Park R. Software Size Measurement: A Frame-
work for Counting Source Statements // Tech.
Report. – Pittsburg: Software Eng. Inst.
CMU/SEI-92-TR-020., 1992. – 242 p.
8. Longstreet D. Function Points Analysis Train-
ing Course // www.softwaremetrics.com,
2002. – 116 p.
9. KPMG, 2001: KPMG Consulting, Inc.: MK II
Function Point Analysis Counting Practices
Manual. Version 1.3.1 // www.kpmg.co.uk/-
kpmg/uk. – 92 p.
10. COSMIC, 2003: The Common Software Meas-
urement International Consortium. The
COSMIC FFP Measurement Manual. Version
2.2 // www.cosmicon.com. – 81 p.
11. CSE, 1999: Center for Software Engineering.
COCOMO II Model Definition Manual. //
Computer Science Department, USC Center
for Software Engineering, 1999. – 37 p.
12. Clark B., Devnani-Chulani S., Boehm B.W.
Calibrating the COCOMO II Post-Architec-
ture Model. // ICSE, 1998. – p. 477—480.
13. CSE, 1999: Center for Software Engineering.
COCOMO II Reference Manual. // Computer
Science Department, USC Center for Software
Engineering, 1999. – 86 p.
Отримано 17.11.03
Про авторів
Стрєлов Ігор Анатолійович,
аспірант
Ігнатенко Петро Петрович,
кандидат технічних наук, завідувач від-
ділом
Місце роботи авторів
Інститут програмних систем НАН України,
просп. Академіка Глушкова, 40,
Київ-187, 03680, Україна
Тел. (044) 452 5791, 266 1540
E-mail: ignat@isofts.kiev.ua,
ihors@svitonline.com
|
| id | nasplib_isofts_kiev_ua-123456789-1343 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T18:43:59Z |
| publishDate | 2004 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Стрєлов, І.А. Ігнатенко, П.П. 2008-07-25T16:00:15Z 2008-07-25T16:00:15Z 2004 Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем /І.А. Стрєлов, П.П. Ігнатенко // Проблеми програмування. — 2004. — N 1. — С. 38-51. — Бібліогр.: 13 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1343 681.3.06 Досліджені існуючі методи оцінювання характеристик проектів, на основі яких з урахуванням досвіду виконання проектів запропоновано методику оцінювання економічних характеристик проектів, що поєднує методи експертних оцінок, FPA та COCOMO. Експериментально перевірено можливість використання оцінок за мето дом FPA як вхідних даних для моделі COCOMO. За результатами експериментальних випробувань оцінено ефективність застосування методики на даних по виконаних проектах і показано, що розбиття даних на класи для калібрування моделі COCOMO підвищує точність оцінок. uk Інститут програмних систем НАН України Методы и средства программной инженерии Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем Article published earlier |
| spellingShingle | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем Стрєлов, І.А. Ігнатенко, П.П. Методы и средства программной инженерии |
| title | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| title_full | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| title_fullStr | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| title_full_unstemmed | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| title_short | Підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| title_sort | підхід до оцінювання економічних характеристик проектних рішень при розробці, модифікації та реінжинірингу програмних систем |
| topic | Методы и средства программной инженерии |
| topic_facet | Методы и средства программной инженерии |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/1343 |
| work_keys_str_mv | AT strêlovía pídhíddoocínûvannâekonomíčnihharakteristikproektnihríšenʹprirozrobcímodifíkacíítareínžiníringuprogramnihsistem AT ígnatenkopp pídhíddoocínûvannâekonomíčnihharakteristikproektnihríšenʹprirozrobcímodifíkacíítareínžiníringuprogramnihsistem |