Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик

Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик

Розглядається проблема ефективного оцінювання економічних характеристик проектів з розробки програмних систем за їх моделлю на мові UML (Unified Modeling Language, уніфікована мова моделювання). Наведена характеристика методики оцінювання, запропоновано спосіб ідентифікації та відображення необхідно...

Повний опис

Збережено в:
Бібліографічні деталі
Дата:2005
Автори: Стрєлов, І.А., Ігнатенко, П.П.
Формат: Стаття
Мова:Ukrainian
Опубліковано: Інститут програмних систем НАН України 2005
Теми:
Методи і засоби програмної інженерії
Онлайн доступ:https://nasplib.isofts.kiev.ua/handle/123456789/1366
Теги: Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик / І.А. Стрєлов, П.П. Ігнатенко// Проблеми програмування. — 2005. — N 3. — С. 67-75. — Бібліогр.: 7 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine
id nasplib_isofts_kiev_ua-123456789-1366
record_format dspace
spelling Стрєлов, І.А.
Ігнатенко, П.П.
2008-07-28T18:48:38Z
2008-07-28T18:48:38Z
2005
Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик / І.А. Стрєлов, П.П. Ігнатенко// Проблеми програмування. — 2005. — N 3. — С. 67-75. — Бібліогр.: 7 назв. — укр.
1727-4907
https://nasplib.isofts.kiev.ua/handle/123456789/1366
681.3.06
Розглядається проблема ефективного оцінювання економічних характеристик проектів з розробки програмних систем за їх моделлю на мові UML (Unified Modeling Language, уніфікована мова моделювання). Наведена характеристика методики оцінювання, запропоновано спосіб ідентифікації та відображення необхідної для оцінювання інформації на UML-діаграмі та приведено приклад оцінювання для типової системи CRM (Customer Relationship Management, управління відносинами з клієнтами).
uk
Інститут програмних систем НАН України
Методи і засоби програмної інженерії
Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
Identification and markup of FPA functional elements on UML model of developed system for estimation purposes
Article
published earlier
institution Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection DSpace DC
title Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
spellingShingle Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
Стрєлов, І.А.
Ігнатенко, П.П.
Методи і засоби програмної інженерії
title_short Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
title_full Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
title_fullStr Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
title_full_unstemmed Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик
title_sort ідентифікація та відображення функціональних елементів fpa-методу в uml-моделі створюваної системи для оцінювання її економічних характеристик
author Стрєлов, І.А.
Ігнатенко, П.П.
author_facet Стрєлов, І.А.
Ігнатенко, П.П.
topic Методи і засоби програмної інженерії
topic_facet Методи і засоби програмної інженерії
publishDate 2005
language Ukrainian
publisher Інститут програмних систем НАН України
format Article
title_alt Identification and markup of FPA functional elements on UML model of developed system for estimation purposes
description Розглядається проблема ефективного оцінювання економічних характеристик проектів з розробки програмних систем за їх моделлю на мові UML (Unified Modeling Language, уніфікована мова моделювання). Наведена характеристика методики оцінювання, запропоновано спосіб ідентифікації та відображення необхідної для оцінювання інформації на UML-діаграмі та приведено приклад оцінювання для типової системи CRM (Customer Relationship Management, управління відносинами з клієнтами).
issn 1727-4907
url https://nasplib.isofts.kiev.ua/handle/123456789/1366
citation_txt Ідентифікація та відображення функціональних елементів FPA-методу в UML-моделі створюваної системи для оцінювання її економічних характеристик / І.А. Стрєлов, П.П. Ігнатенко// Проблеми програмування. — 2005. — N 3. — С. 67-75. — Бібліогр.: 7 назв. — укр.
work_keys_str_mv AT strêlovía ídentifíkacíâtavídobražennâfunkcíonalʹnihelementívfpametoduvumlmodelístvorûvanoísistemidlâocínûvannâííekonomíčnihharakteristik
AT ígnatenkopp ídentifíkacíâtavídobražennâfunkcíonalʹnihelementívfpametoduvumlmodelístvorûvanoísistemidlâocínûvannâííekonomíčnihharakteristik
AT strêlovía identificationandmarkupoffpafunctionalelementsonumlmodelofdevelopedsystemforestimationpurposes
AT ígnatenkopp identificationandmarkupoffpafunctionalelementsonumlmodelofdevelopedsystemforestimationpurposes
first_indexed 2025-11-26T22:54:44Z
last_indexed 2025-11-26T22:54:44Z
_version_ 1850779196136095744
fulltext © І.А. Стрелов, П.П. Ігнатенко, 2005 67 ISSN 1727-4907. Проблеми програмування. 2005. № 3 УДК 681.3.06 І.А. Стрєлов, П.П. Ігнатенко ІДЕНТИФІКАЦІЯ ТА ВІДОБРАЖЕННЯ ФУНКЦІОНАЛЬНИХ ЕЛЕМЕНТІВ FPA-МЕТОДУ В UML-МОДЕЛІ СТВОРЮВАНОЇ СИСТЕМИ ДЛЯ ОЦІНЮВАННЯ ЇЇ ЕКОНОМІЧНИХ ХАРАКТЕРИСТИК Розглядається проблема ефективного оцінювання економічних характеристик проектів з розробки програмних систем за їх моделлю на мові UML (Unified Modeling Language, уніфікована мова моделювання). Наведена характеристика методики оцінювання, запропоновано спосіб ідентифікації та відображення необхідної для оцінювання інформації на UML-діаграмі та приведено приклад оцінювання для типової системи CRM (Customer Relationship Management, управління відносинами з клієнтами). В [1] авторами запропонована комплексна методика оцінювання еконо- мічних характеристик проектів, що поєд- нує методи FPA (Function Point Analysis, аналіз одиниць функціональності) [2] та COCOMO (COnstructive COst MOdel, конструктивна модель вартості) [3]. Методика включає наступні етапи: • ідентифікація функціональних елементів програмної системи (ПС), визначення їх складно- сті; • визначення розміру ПС в оди- ницях UFP (Unadjusted Function Point, нескоригована одиниця функціональності); • переведення одиниць UFP в одиниці SLOC (Source Lines Of Code, рядки вихідного коду); • розрахунок трудомісткості проекту; • розрахунок тривалості прое- кту. Найменш формалізованим у за- пропонованій методиці є її перший етап. Він заключається в проведенні експерт- ного аналізу функціональних вимог до системи чи проектної документації на систему, виділення функціональних еле- ментів ПС виходячи з методу FPA та ви- значення характеристик їх складності. Коли цей етап виконано, а його резуль- тати мають структуроване представ- лення, подальші етапи методики можуть бути формалізовані та автоматизовані. Слід відмітити, що проведення адекватної ідентифікації функціональних елементів ПС та визначення їх складності є основою одержання об’єктивних оцінок розміру, трудомісткості та тривалості розробки системи на подальших етапах методики. У зв’язку з цим задачі, пов’язані з формалізацією ідентифікації та відобра- ження функціональних елементів FPA- методу, а також ув’язкою результатів етапу в технологічну схему комплексної методики, що розглядається, являються важливими та актуальними. У даній статті запропоновано під- хід до формалізації задач етапу ідентифі- кації функціональних елементів FPA шляхом встановлення відповідності між елементами моделей FPA та UML (Unified Modeling Language, уніфікована мова моделювання), що дозволить вико- ристати переваги UML у формалізова- ному представленні вимог та одночасно отримати оцінки за методом COCOMO. Отримання даних для оціню- вання економічних характеристик. Метод FPA вимагає представлення сис- теми як сукупності внутрішніх файлів даних, зовнішніх інтерфейсів, з якими система взаємодіє, та транзакцій, у яких дані перетинають межу системи. Іденти- фікація та визначення властивостей цих елементів звичайно виконуються шляхом експертного аналізу проектної докумен- тації. На початковому етапі проекту це специфікації вимог та високорівнева спе- цифікація архітектури ПС. Такий підхід має типові для експертних методів недо- ліки: • суб’єктивність оцінки; Методи і засоби програмної інженерії 68 • велика вартість процедури перевірки та уточнення результа- тів; • отримані дані звичайно оформлю- ються як окремий текстовий до- кумент, що потребує його узго- дження з іншою проектною доку- ментацією системи; • неформалізоване представлення даних для FPA-методу. Завадити цим недолікам можна наступним шляхом: • автоматизувати процес отримання даних для обчислення економіч- них характеристик; • відслідковувати зміни у вимогах, одночасно оновлюючи оцінки. Для вирішення цих проблем необ- хідно задовольнити певні вимоги до ви- хідних специфікацій етапу: • вони повинні бути у структурова- ному форматі, який може читатись машиною; • мають містити всю необхідну для оцінювання інформацію; • специфікація архітектури та вимог має бути узгоджена з даними для оцінювання. Ці вимоги можуть бути виконані у випадку використання для опису вихід- них даних етапу UML-діаграм. Мова UML [4] має зображувальні засоби, до- статні для відображення як архітектур- них особливостей ПС, так і її ключових елементів з точки зору FPA-методу. Отримання даних для оціню- вання економічних характеристик із використанням UML-моделі. При по- будові FPA-моделі застосовуються спе- цифікації функціональних вимог до ПС, а UML-модель є формалізованим предста- вленням вимог до ПС, тому бажано ви- користовувати побудовану UML-модель та отримувати з неї всі необхідні для FPA дані. Проте, хоча ці дані наявні в UML- діаграмі, автоматизоване їх отримання стикається з певними проблемами. Від- повідно до специфікації FPA [2], транза- кція – це процес, у якому дані перетина- ють межу системи. В UML-моделі будь- яку взаємодію між класами системи та акторами можна вважати транзакцією, і за цим критерієм можна автоматизовано визначати транзакції. Такі взаємодії у яв- ному вигляді позначаються на діаграмах послідовностей та активностей, проте, залежно від рівня деталізації діаграми та потреб розробників, можуть позначатись і як варіанти використання. Можливі та- кож випадки, коли на діаграмі є визна- чення актора або класа, але взаємодія між ними ще не визначена або визначена на декількох рівнях деталізації (варіант ви- користання, визначення класа, актора, діаграма взаємодії). За умов ітеративної розробки UML-модель набуває заверше- ного вигляду лише у кінці розробки ПС. Для отримання оцінок вже на початкових ітераціях бажано дати можливість розро- бникам позначати певні елементи моде- лювання як такі, що відповідають або не відповідають транзакціям, а автоматизо- ване визначення транзакції використову- вати як допоміжний засіб. Засоби авто- матизації оцінювання можуть комбіну- вати програмну ідентифікацію FPA-еле- ментів та використання внесених розроб- никами позначень. Зручним шляхом для позначення транзакцій та їх типів є стереотипи UML, що являють собою засіб для внесення до- даткової інформації в UML-модель. Ме- тод FPA розрізнює три типи транзакцій. Зовнішній ввід. Процес, у якому дані перетинають межу системи, при цьому вони вводяться в неї та відбува- ється модифікація внутрішнього її стану або файлів даних, якими система керує. Прикладом може бути введення даних користувачем з клавіатури. Для позна- чення таких транзакцій пропонується ви- користання стереотипу UML «external input». Зовнішній вивід. Процес, у якому дані перетинають межу системи, при цьому з неї виводяться дані, отримані внаслідок обробки або проведених роз- рахунків. Приклад – відображення стати- стичних графіків на екрані або їх друк на принтері. Для позначення таких транзак- цій пропонується використання стерео- типу UML «external output». Зовнішній запит. Процес, у якому дані перетинають межу системи, при Методи і засоби програмної інженерії 69 цьому з неї виводяться необроблені дані. Прикладом може бути відображення тек- сту, раніше введеного користувачем. Для позначення таких транзакцій пропону- ється використання стереотипу UML «external inquiry». На рис.1-4 зображено приклади UML-діаграм системи, доповнені опи- сами транзакцій для FPA-методу. Після складання UML-моделі та позначення в разі необхідності FPA-еле- ментів у моделі, отримання даних для оцінювання зводиться до підрахування кількості FPA-елементів певних типів, визначення функціонального розміру ПС, перерахування одиниць FPA в одиниці SLOC та обчислення економічних харак- теристик за методом COCOMO. Query <<external inquiry>> Input <<external input>> Actor Output <<external output>> Рис. 1. Приклад позначення варіантів використання у вигляді транзакцій Actor Interface <<external output>> getProcessedData() <<external inquiry>> getData() <<external input>> setData() Actor Рис. 2. Приклад опису зовнішнього інтерфейсу InternalClass <<external input>> setData() <<external inquiry>> getData() <<external output>> getProcessedData() Рис. 3. Приклад опису внутрішнього класу, що реалізує методи, використовувані у транзакціях : Actor Interface : InternalClass setData( ) getProcessedData( ) Рис. 4. Приклад опису взаємодії між актором та класом системи. Методи і засоби програмної інженерії 70 У випадку використання UML- моделі як засобу для документування ар- хітектури і дизайну системи та відобра- ження необхідних для оцінювання даних методика [1] матиме схему, зображену на рис. 5. Розглянемо приклад застосування підходу щодо відображення функціональних елементів FPA-методу в UML-моделі та оцінювання економічних характеристик проекту. У якості ілюстративного прикладу для пропонованого підходу розглянемо проект створення простої CRM-системи (CRM – Customer Relationship Management – управління взаємовідноси- нами з клієнтами). Опис системи. Типова CRM-сис- тема початкового рівня складається з та- ких основних підсистем [5]: • продажів; • контролю роботи персоналу; • „Органайзер”. Як основний вихідний документ першого етапу методики було взято UML-модель системи, доповнену елеме- нтами, що зображують транзакції, та від- повідними діаграмами. Через нестачу детальної інформа- ції по системі було визначено лише зв’язки транзакцій із варіантами викори- стання (Use Case) системи, що вже є до- статнім для отримання оцінок. Отримані дані. Діаграми, додані до UML-моделі, зображено на рис. 6-10. У більшості випадків одному варіанту використання відповідає одна транзакція, але присутні й більш складні випадки відношень „один – до декількох” та „де- кілька – до одного”. У транзакції можуть брати участь один або декілька класів системи. Такі ситуації можна відобразити через залежності між прецедентами та між прецедентами та класами. C O C O M O F P A П о б у д о в а U M L- м о д е л і Збір інформації про ПС Визначення функціональних класів ПС Визначення зовнішніх інтерфейсів, з якими взаємодіє ПС Визначення файлів, типів записів та транзакцій Обчислення функціонального розміру ПС Визначення використаних мов програмування Перерахування одиниць розміру UFP у SLOC Оцінка кількісних значень факторів COCOMO Обчислення трудомісткості проекту ПС Обчислення вартості та часу виконання проекту ПС Рис. 5 Методика обчислення економічних характеристик ПС за UML-моделлю Методи і засоби програмної інженерії 71 Реєстрація купівлі клієнта <<external input>> Перегляд даних про наявні товари (на складах, в магазинах) <<external inquiry>> Складання комерційної пропозиції <<external input>> Перегляд історії (за групами товарів) купівель клієнта <<external inquiry>> Перегляд історії (за товарами) купівель клієнта <<external inquiry>> Перегляд обсягів продажу по клієнтах <<external output>> Менеджер з продажу Рис. 6. Транзакції, пов’язані з варіантами використання у підсистемі продажу Перегляд розкладу на вибраний день <<external inquiry>> Перегляд скарг за відповідальними <<external inquiry>> Побудова графіків зайнятості персоналу <<external inquiry>> Перегляд кількості та сум продажів менеджера з продажів <<external output>> Перегляд порівняльних графіків продажів менеджерів <<external inquiry>> Перегляд скарг за клієнтами <<external inquiry>> Перегляд задач на період <<external inquiry>> Перегляд проектів за вказаною контактною особою <<external inquiry>> Керівник Рис. 7. Транзакції, пов’язані з варіантами використання у підсистемі контролю роботи персоналу Методи і засоби програмної інженерії 72 Перегляд розкладу <<external inquiry>> Перегляд розкладу на сьогодніПерегляд розкладу на зазначений день чи період Перегляд задач на період, за відповідальними, ... <<external inquiry>> Створення проекту <<external input>> Перегляд проектів, у яких бере участь зазначена контакто... <<external inquiry>> Ручне внесення задачі <<external input>> Складання розкладу <<external input>>Співробітник Рис. 8. Транзакції, пов’язані з варіантами використання у підсистемі "Органайзер", робота з проектами та задачами Автоматичне внесення задач - створення процесів <<external input>> Відпрацювання процесу <<extend>> Видалення процессів <<external input>> <<extend>> Співробітник Перегляд процесу <<external inquiry>> Зміна процесу <<external input>> Редагування процесів <<extend>> <<include>> <<include>> Рис. 9. Транзакції, пов’язані з варіантами використання у підсистемі „Органайзер”, робота з процесами Методи і засоби програмної інженерії 73 Усі транзакції, задіяні у переліче- них підсистемах, зведені до табл. 1. Таб- лиця включає певні транзакції, які не присутні на Use Case-діаграмах, проте необхідні для введення та супроводу ви- користовуваних довідників. Стовпчики EI (External Input, зовнішній ввід), EO (External Output, зовнішній вивід), EQ (External Inquiry, зовнішній запит) міс- тять, відповідно, кількості транзакцій вводу, виводу та запиту даних, задіяних у реалізації певної функції системи. На етапі розробки UML-моделі ПС ще не доступна детальна інформація про функції системи та формати даних, які використовуються, але можна зро- бити припущення, що всі транзакції ма- ють середню складність: ввід – 4 UFP, вивід – 5 UFP, запит – 4 UFP. Тоді перелічені функції разом мо- жна оцінити у 153 одиниці UFP. У міру деталізації моделі системи цю оцінку можна уточнювати. У методі FPA також враховується складність структур даних. Для оціню- вання цього внеску за відсутності дета- льної архітектури можна вважати, що ПС використовує два угруповання даних: зо- внішню БД та внутрішні тимчасові дані (табл. 2). Стовпчики табл. 2 ILF (Internal Logical File, внутрішній логічний файл) та EIF (External Interface File, зовнішній інтерфейсний файл) містять, відповідно, кількості файлів, використовуваних сис- темою. Якщо рахувати ці угруповання із середніми значеннями складності (внут- рішній файл – 10 UFP, зовнішній – 7 UFP), вони додадуть 17 одиниць UFP. Отримані економічні характе- ристики. У сумі оцінка системи за FPA- методом налічує 170 одиниць функціона- Перегляд нагадувалок <<external inquiry>> Створення нагадувалок <<external input>> <<extend>> Видалення нагадувалок <<external input>> <<extend>> Редагування важливих дат <<external input>> Видалення важливих дат <<external input>> Створення важливих дат <<external input>> <<include>> <<extend>> Відміна важливої дати <<extend>> Видача нагадувань про важливі дати тим, для кого вони важливі <<external inquiry>> Перегляд загального списку важливих дат <<external inquiry>> Співробітник Рис. 10. Транзакції, пов’язані з варіантами використання у підсистемі „Органайзер”, робота з нагадуваннями та важливими датами Методи і засоби програмної інженерії 74 льності. Для подальшого застосування методу COCOMO необхідно перевести їх в одиниці SLOC. Якщо взяти, наприклад, мову програмування Java, де співвідно- шення SLOC/UFP дорівнює 50 [6], це складе 8500 рядків. Слід зауважити, що співставляти отриману таким чином кількість рядків коду із рядками реального вихідного тек- сту системи на певній мові програму- вання можна лише за умови викорис- тання локальної калібровки COCOMO, коли коефіцієнти COCOMO та відповід- ність між одиницями UFP та рядками коду визначаються для конкретних умов розробки системи. У даному випадку кількість рядків коду слугує лише вхідним параметром для подальших розрахунків. Обчислення проводяться відповідно до моделі COCOMO [7]: Номінальна трудомісткість NSPM виражена у людино-місяцях (person- month, PM) і обчислюється як ∏ = ××= n i i E NS EMSizeAPM 1 , де Size – роз- мір ПС має бути вираженим у одиницях KSLOC; ∑ = ×+= 5 1 01.0 j jSFBE ; iEM – му- Таблиця 1. Функції, виконувані системою та відповідна їм кількість транзакцій FPA Функція EI EO EQ Підсистема продажу реєстрація купівлі клієнта 1 перегляд купівлі клієнта 1 перегляд інформації щодо обсягу продажу за вибраними клієнтами 1 перегляд історії (по товарах) купівель клієнта за вказаний період 1 перегляд історії (по товарних групах) купівель клієнта за вказаний період 1 перегляд інформації щодо наявності товарів на складах та в магазинах фірми 1 складання комерційної пропозиції 1 Підсистема контролю роботи персоналу перегляд розкладів та планів робіт вибраних співробітників 1 постановка задач певному підлеглому або групі підлеглих 1 перегляд задач, поставлених підлеглим, та проектів у яких вони беруть участь 1 перегляд продажу, що здійснив вказаний менеджер (для відділу збуту) 1 перегляд порівняльних графіків кількісних та грошових сум продажу різними менеджерами за параметрами продаж або магазин 2 перегляд скарг клієнтів та відповідальних за них 1 2 Підсистема “Органайзер” створення та редагування проектів 2 1 перегляд проектів, у яких беруть участь вказані контактні особи 1 внесення та коригування поставлених задач 2 складання розкладу 2 перегляд розкладу на поточний або вказаний день 1 перегляд задач на період по відповідальному, по контактних особах, ролях контактних осіб 1 ведення процесів – вказаних послідовністей задач, так би мовити шаблонів 2 1 робота з нагадуваннями (створення, редагування, видалення) 2 2 ведення важливих дат – днів народження клієнтів та співробітників, днів фірм, днів професії тощо 3 1 ∑∑∑∑ 17 5 15 Таблиця 2. Угруповання даних, використовувані системою, та відповідна їм кількість файлів FPA Угруповання ILF EIF База даних 1 Внутрішні дані 1 ∑∑∑∑ 1 1 Методи і засоби програмної інженерії 75 льтиплікативні фактори; ni ,1= , 16=n ; jSF – експоненційні фактори; 5,1=j ; 94,2=A ; 91,0=B – калібровочні конста- нти. Номінальний час розробки NSTDEV обчислюється за формулою F NSNS PMCTDEV )(×= , де )(2.001.02.0 5 1 BEDSFDF j j −×+=××+= ∑ = , 67,3=C ; 28,0=D – калібровочні конс- танти. Отримані значення економічних характеристик зведено до табл. 3. Висновки У статті запропоновано підхід до ідентифікації та відображення на UML- моделях функціональних елементів ПС, визначення їх складності за FPA-методом із використанням UML-діаграм, що опи- сують вимоги до ПС, архітектуру та ди- зайн системи. Такий підхід має наступні переваги перед традиційним експертним підходом, використовуваним у раніше запропонованій методиці [1]: � приводить до структурованого представлення вихідних даних для оцінювання; � наочно пов’язує ці дані із зага- льною архітектурою ПС, що водночас допомагає підтриму- вати їх актуальність та робить опис архітектури більш дета- льним; � значно зменшує обсяг роботи експертів у ході оцінювання проектів за підготованими UML-діаграмами. 1. Стрєлов І. А., Ігнатенко П.П. Підхід до оцінювання економічних характеристик про- ектних рішень при розробці, модифікації та реінжинірингу програмних систем // Пробл. програм. – 2004. – №1. – С. 38-51. 2. Longstreet D. Function Points Analysis Training Course. – www.softwaremetrics.com. – 2002. – 116 p. 3. CSE, 1999: Center for Software Engineering. COCOMO II Model Definition Manual // Computer Science Department, USC Center for Software Engineering, 1999. – 37 p. 4. UML Specification, version 2.0. – www.uml.org 5. Підхід до моделювання та проектування CRM-систем / П.П. Ігнатенко, В.М. Ткаченко, І.А. Стрєлов, Р.О. Дуднік // УСиМ. – 2005. – №2. – С. 57 –65. 6. Language source statements per function point (industry average). – www.softwareestimator.com/IndustryData1.htm 7. Clark B., Devnani-Chulani S., Boehm B.W. Calibrating the COCOMO II Post-Architecture Model // ICSE, 1998. – P. 477-480. Отримано 19.04.05 Про авторів Стрєлов Ігор Анатолійович, аспірант Ігнатенко Петро Петрович, кандидат технічних наук, завідувач відділу Місце роботи авторів Інститут програмних систем НАН України, Просп. Академіка Глушкова, 40, 03680, Київ-187, Україна Тел. (044) 452 5791, 526 1540 E-mail: ignat@isofts.kiev.ua, ihors@svitonline.com Таблиця 3. Обчислені економічні характеристики проекту з розробки типової системи CRM Характеристика Значення Функціональний розмір системи, UFP 170 Кількість рядків коду 8500 Трудомісткість NSPM , людино-місяців 30,93

Схожі ресурси