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

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

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

У витрати на розробку проекту входять: заробітна плата розробників, керівників проекту і допоміжного персоналу; вартість купованих і орендованих програмних і апаратних засобів, що використовуються при розробці ІС; накладні витрати (оренда приміщень, перепідготовка персоналу, утримання апарату управління тощо).

Для організації-розробника дуже важливо не занизити оцінку собівартості проекту, щоб гарантувати свою прибутковість. У той же час, надмірне завищення вартості або термінів може налякати замовника, який в цьому випадку може віддати перевагу іншому розробнику або взагалі відмовитися від створення ІС через її високу вартість.

Здійснити таке оцінювання істотно утрудняє велика кількість факторів і складний характер їх впливу на процес створення ІС.

До факторів, що істотно затрудняють оцінювання вартості проекту, можна віднести наступні:

- складність (розміри) ІС, що розробляється;

- особливості області застосування і архітектури системи (управління об'єктом, що функціонує в реальному масштабі часу; наявність складних баз даних;

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

- жорсткість обмежень на термін розробки;

- чисельність і кваліфікація розробників;

- стабільність вимог замовника;

- наявність специфічних вимог до апаратних засобів.

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

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

Тому відомі методи оцінювання і прогнозування витрат на створення ІС розраховані на застосування в досить зрілих в технологічному відношенні організаціях.

Яке ж місце в життєвому циклі проекту займає прогнозування витрат на створення ІС?

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

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

При правильно організованому технологічному процесі і високій технологічній зрілості розробника дані, достатні для оцінювання з прийнятною точністю, вдається отримати до завершення складання технічного завдання. Цим, зокрема, і пояснюється те, що в американській стандартній моделі життєвого циклу (каскадній див. тему 3) стадія планування безпосередньо слідує за розробкою технічного завдання. Саме на цій стадії найширше застосовуються методи прогнозування часу і витрат, необхідного для створення ІС.

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

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

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

• найпростіші методи, засновані на оцінюванні загального числа операторів (рядків, команд) в початкових текстах програм,

• методи, засновані на інших характеристиках складності ІС.

Як приклад першої групи методів розглянемо так звану модель СОСОМО - Constructive Cost Model, а другої - метод функціональних балів Function Point Analysis (FPA).

Починаючи з середини 1970-х років, в США постійно здійснюється збір статистичних даних про зовнішні техніко-економічних показники розробок ІС, насамперед, що виконуються по держзамовленнях. Вони стали основою для ряду досліджень з метою виявлення основних закономірностей, що дозволяють прогнозувати тривалість і витрати. Судячи з публікацій, роботу по збиранню цих даних спочатку здійснювали в різний час різні групи дослідників, що отримували фінансову підтримку від військового відомства через його різні управління. У цей час ця діяльність зосереджена в рамках Інституту програмної інженерії (SEI), що є, як відомо, головним науковим центром.

Спочатку була запропонована наступна загальна модель для оцінювання трудомісткості проектів ІC[1985]:

Е = (а + b S^c) m(Х), (12.1)

де Е - трудомісткість,

а, b, с - константи,

S - оцінка складності розроблюваної ІС, виражена в тисячах рядків початкового програмного коду,

m(Х) - нелінійна функція вектора інших параметрів проекту X.

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

Тому Б. Боэмом [1] був запропонований удосконалений варіант моделі (12.1), що отримала назву СОСОМО (Constructive Cost Model).

У залежності від характеру проекту, в ній використовують різні значення параметрів. Для цього були виділені наступні три класи ІС: прості, складні і середньої складності (проміжні).

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

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

Проекти третього класу займають проміжне положення.

Основне розрахункове співвідношення моделі, запропонованої Боемом, для трудовитрат (в людино- місяцях) наступне:

Е=a_і S^bi m(X). (12.2)

Значення параметрів а_i, оцінені за відомими статистичними даними, в залежності від класу ІС, встановлюють рівними 2.4, 3.0 і 3.6 відповідно для простих, середніх (проміжних) і складних систем. Параметру b_i, надають значення: 1.05, 1.12 і 1.20.

Вектор Х містить 15 параметрів, а функція m(Х) є добутком 15 відповідних кожному з параметрів коефіцієнтів трудомісткості. Передбачається, що в деяких усереднених умовах кожний коефіцієнт рівний одиниці.

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

1. властивості ІС (вимоги до надійності, складність бази даних, загальна складність системи,

2. властивості обчислювальної техніки (наявність обмежень на час рішення задач і на пам’ять, а також необхідність забезпечення переносимості програм на різні типи ЕОМ),

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

4. технологія (використання передових методів розробки програм, застосування CASE-засобів, якість планування робіт).

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

Крім прогнозування трудовитрат, метод СОСОМО дозволяє оцінювати тривалість розробки ІС. Її розраховують за наступною формулою:

Т=2.5E^Сi, (12.3)

де Т - тривалість в місяцях.

Значення параметра С, для простих, середніх і складних проектів встановлюють відповідно рівними 0.38, 0.35 і 0.32.

Ця модель була розроблена Б. Боемом на основі статистичних даних, накопичених в 1960-70 р.р. головним чином фірмою TRW (розробником систем ракетно-космічної оборони). Виконана пізніше перевірка її на шести інших сукупностях статистичних даних [1985] показала, що для різних вибірок від 17% до 67% оцінок, отриманих з її допомогою, мають відносну погрішність не більше за 25%, тобто модель має точність, яку не завжди можна визнати задовільною.

Наведені вище результати, що характеризують точність прогнозування, відносяться до раннього етапу застосування цієї моделі в умовах, коли не враховувалися специфічні особливості фірми-розробника. За останні 10 років, в зв'язку з введенням в дію системи атестування технологічної зрілості організації-розробників, вже з'явилися фірми, що характеризуються 4-5 рівнями зрілості. В таких фірмах повинна бути налагоджена своя власна система накопичення і аналізу статистичних даних, що дозволяє діставати набагато достовірніші оцінки, ніж це робилося 10-15 років тому.

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

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

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

Основними аргументами проти використання цієї характеристики складності наступні:

• точне число операторів програми стає відомим лише у кінці розробки, а розрахунки треба виконувати значно раніше, після складання технічного завдання;

• написання програм є лише невеликою частиною всіх трудовитрат, і тому число операторів не характеризує їх повністю;

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

• далеко не завжди зрозуміло, як здійснювати підрахунок (наприклад, чи треба враховувати коментарі і оголошення змінних тощо);

• не всі програми, що розробляються входять в комплект постачання (наприклад, програми, що забезпечують відладку і випробування).

Тому були зроблені спроби відійти від числа операторів програми як міри складності ІС і використати інші метрики. Одним з підходів, що набув досить широкого поширення є метод функціональних балів (Function Point Analysis -FPA).

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

До цих параметрів можна віднести, наприклад, число:

• класів інформаційних об'єктів,

• атрибутів інформаційних об'єктів,

• функціональних задач (інформаційних і обробки),

• число вхідних і вихідних змінних кожної задачі.

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

У виборі одного з можливих способів їх агрегування і полягає сутність так званого методу функціональних балів (Function Point Analysis - FPA). Уперше метод був запропонований в роботі [Albrecht A. J, Measuring Application Development Prodactivity, on Proc. IBM Applications Development Symposium, GUIDE Int. and SHARE Inc., IBM Corp., Moneterey, CA. Oct. 14-17, 1979]. За своїм призначенням метод FPA призначений для більш вузького класу систем, ніж метод СОСОМО. А саме, FPA орієнтований на системи, що містять у своєму складі досить складні бази даних.

У порівнянні з СОСОМО метод FPA має більш вузьку спрямованість тому , що він призначений тільки для оцінювання складності ІС, а не трудомісткості або тривалості, тобто в ньому не враховуються фактори, безпосередньо пов'язані з процесом розробки і реалізації, які враховує модель СОСОМО. По суті, метод FPA дозволяє оцінити тільки значення параметра, яке можна було б підставити в формули (20.1) або (20.2) замість довжини програми S.

Розглянемо найпростіший варіант цього методу.

В якості вхідних даних для оцінювання складності ІС, що розробляється, використовують наступні п'ять параметрів:

• число форм вхідних повідомлень - Inp,

• число форм вихідних повідомлень - Out,

• число інформаційних задач - Inq,

• число головних файлів - Maf,

• число інтерфейсів - Inf.

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

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

FP =UFP TСF, (12.4)

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

Логічну складність розраховують за наступною формулою:

UFP = а Inp + b Out + с Inq + d Mat + е Inf, (12.5)

де значення кожного з коефіцієнтів, a, b, с, d, е, встановлюють у залежності від складності відповідного елемента ІС (табл. 20.1).

Другий співмножник в (20.4) розраховують по формулі:

TCF =0.65 +0.01 • DI, (12.6)

де коефіцієнт DI (Degree of Influence) - це сума наступних 14 показників:

1. наявність і складність телекомунікації,

2. розподілена обробка,

3. особливі вимоги до якості,

4. ступінь використання ресурсів обладнання,

5. частота транзакції,

6. діалоговий режим введення даних,

7. особливі вимоги до ефективності роботи кінцевих користувачів,

8. діалоговий режим оновлення даних,

9. наявність складних алгоритмів обробки,

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

11. простота розгортання системи,

12. зручність експлуатації,

13. переносимість на інші платформи,

14. простота супроводу.

Оскільки кожному з перерахованих показників проектувальник повинен присвоїти оцінку з діапазону від 0 до 5, параметр DI може приймати значення від 0 до 70, а коефіцієнт TCF - відповідно від 0.65 до 1.35.

Таблиця 12.1. Вагові коефіцієнти логічної складності

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

Недосконалість моделі FPA досить добре видно навіть з приведеного вище переліку чинників, що враховуються при розрахунку значення параметрів DI. Двократне врахування діалогового режиму як чинника, що впливає на складність, явно відноситься до часів, коли процедури діалогової взаємодії було важко проектувати і реалізувати програмно. Це свідчить про те, що розглянута вище модель FPA потребує вдосконалення. Поліпшений варіант цього методу детально викладений у монографії [Symons, 1991].

Судячи з публікацій, метод FPA досить широко використовується по обидві сторони Атлантики. Існує Асоціація користувачів методу (FPA Users Group), яка регулярно проводить робочі зустрічі й конференції, які сприяють обміну інформацією між фахівцями і вдосконаленню методу. У Великобританії під егідою ССТА видана методична допомога по застосуванню FPA для прогнозування витрат і тривалості розробки ІС. Все це свідчить про те, що цей метод постійно удосконалюється і має важливе практичне значення.

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

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

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

Питання для самоконтролю:

1. Яка головна задача управління вартістю?

2. Опишіть основні напрямки управління вартістю у проекті.

3. З чого складаються витрати на розробку проекту?

4. Які фактори істотно затрудняють оцінювання вартості проекту?

5. Що являється основним чинником, який впливає на час і витрати упроцесі створення проекту?

6. Опишіть загальну модель для оцінювання трудомісткості проектівІC.

7. Як класифікують інформаційні системи за ступенем складності?

8. Що представляє собою модель СОСОМО (Constructive Cost Model), хто її запропонував уперше?

9. Які фактори впливають на трудовитрати?

10. Які недоліки методу СОСОМО й аналогічним йому методам

11. Що представляє собою метод функціональних балів(Function Point Analysis -FPA)?

12. Які параметри використовують для оцінювання складності ІС в моделіFPA?

13. Які недоліки методу функціональних балів(Function Point Analysis -FPA)?

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

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. B. Тип, структура, зміст уроку і методика його проведення.
3. Demo 11: Access Methods (методи доступу)
4. I. ЗАГАЛЬНІ МЕТОДИЧНІ ВКАЗІВКИ
5. II. МЕТОДИЧНІ ВКАЗІВКИ
6. II. ПОРЯДОК ПРОВЕДЕННЯ ТА ОЦІНКИ ПОТОЧНИХ ТА ПІДСУМКОВИХ ЗАНЯТЬ (ЗМІСТОВИХ МОДУЛІВ).
7. II. ПОРЯДОК ПРОВЕДЕННЯ ТА ОЦІНКИ ПОТОЧНИХ ТА ПІДСУМКОВИХ ЗАНЯТЬ (ЗМІСТОВИХ МОДУЛІВ).
8. II. УЧЕБНЫЕ И МЕТОДИЧЕСКИЕ ПОСОБИЯ, ПРАКТИКУМЫ
9. IV. КЕРІВНИЦТВО, КОНТРОЛЬ І НАДАННЯ ОРГАНІЗАЦІЙНО-МЕТОДИЧНОЇ ДОПОМОГИ ПРАКТИКАНТАМ.
10. IV. Учебно-методические рекомендации
11. IV. Электронное учебно-методическое обеспечение дисциплины.
12. V. ІНДИВІДУАЛЬНІ ЗАВДАННЯ ДЛЯ САМОСТІЙНОЇ РОБОТИ ТА МЕТОДИЧНІ РЕКОМЕНДАЦІЇ ДО ЇХ ВИКОНАННЯ

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