ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - М. Сидоров

Шаблон робочої книги (workbook) проекту SLIM Estimate під­тримує близько 50 різних форматів проведеного оцінювання прог­рамного забезпечення. Створені робочі книги можуть служити ша­блонами для оцінювання вартості подальших проектів. За умов­чанням, SLIM Estimate оцінює трудовитрати з 50% вірогідністю успішної реалізації проекту. Для зміни цього значення слід, відко-ригувати значення вірогідності за допомогою майстра налаштуван­ня вірогідності [12], Результатом оцінки розміру є загальна кіль­кість рядків коду, які може створити команда розробників у певних умовах. Результат оцінки індексу продуктивності є РІ, необхідний для реалізації проекту в заданих умовах. Оцінка непередбачених обставин використовується для генерації плану реалізації із зада­ною вірогідністю успішного завершення проекту. Ці способи мо­жуть використовуватися як незалежно, так і для уточнення результа­тів, отриманих у результаті використання майстра швидкої оцінки.

За допомогою функції Edit Historical Projects такі оцінки мо­жуть бути експортовані в SLIM DataManager. Для порівняльного аналізу результатів оцінки можливий імпорт даних з програми SLIM Metrics або іншої робочої книги SLIM Estimate.

Для оцінювання розміру проекту разом зі SLIM Estimate «постав­ляється» реалізована в Microsoft Excel таблиця, значення з якої мо­жуть бути імпортовані в робочу книгу проекту. У ранніх версіях SLIM Estimate основною одиницею вимірювання був логічний ви­раз у початковому коді (Logical Source Statement, LSS). Починаючи з версії 5.0, в SLIM Estimate використовуються рядки коду, функці­ональні і об'єктні точки (безпосередньо, без перетворення в LSS). Найбільш широко використовуваним способом калібрування моделі в SLIM Estimate є використання історичних параметрів налашту­вання (Historical Tuning Factors). Програмний комплекс SLIM Estimate може експортувати дані звітів у найбільш популярні фор­мати файлів, такі як: Microsoft Word, Microsoft Excel, Enhanced Metafile, Microsoft Project, HTML.

У комплект постачання SLIM Estimate входить база реалізовaних проектів, котрі можна використовувати для калібрування вико­ристовуваної моделі - установки значень параметрів вартості для опису характеристик проекту. Найпоширенішим способом калібру­вання моделі в SLIM Estimate с використання історичних параметрів налаштування (Historical Tuning Factors), У разі його викорис­тання значення параметрів вартості для проекту обчислюються програмним комплексом на основі обраних проектів з бази реалізо­ваних проектів.

Модель Путнема надзвичайно чутлива до значення технологіч­них чинників, тому точне визначення їх значення є дуже важливим для правильного оцінювання на основі SLIM. Перевагою моделі Путнема перед COCOMO 1.1 або COCOMO 2.0 є невелика кіль­кість параметрів, необхідних для оцінки.

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

Costar (SoftStar Systems), Cost Xpert (Marotz), SoftwareCost Calculator (SofiwareCost.com) — засоби, засновані на моделі COCOMO. Допускається використання всіх реалізацій моделі COCOMO, моделей життєвого циклу програмного забезпечення Waterfall і MBASE/RUP, підтримується робота з проектом, складе­ним з компонентів, для кожного з яких можна виконати роздільне оцінювання.

Costar, дає змогу проводити оцінювання в двох режимах: покроковому (за допомогою майстра оцінювання вартості); інтерактив­ному (що забезпечує безпосередню вказівку значень параметрів, які впливають на вартість проекту). Для визначення розміру оці­нюваного проекту використовуються функціональні точки або ряд­ки коду. Для перекладу значень, указаних у рядках коду, в програмі є конвертатор, що розраховує значення розміру коду у функціона­льних точок, виходячи з мови програмування, яка використовуєть­ся для реалізації проекту. Costar підтримує обмеження проекту, заснованого на граничних фінансових витратах і крайньому терміні реалізації проекту.

Для оцінювання витрат, пов'язаних з оплатою праці працівни­ків, існує, два альтернативні підходи: розрахунок витрат для кожно­го з етапів життєвого циклу програмного забезпечення; розрахунок місячної плати за працю для кожної категорії співробітників.

Для аналізу результатів оцінки Costar створює різні форми зві­тів, графіків і діаграм. Звіти, представлені у формі таблиць, можуть бути збережені у форматі Microsoft Excel, графіки і діаграми - у форматі растрового зображення BMP.

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

Під час використання засобів на основі моделі COCOMO або COCOMO IT чинниками, що впливають на точність оцінювання вартості, є такі: правильний вибір конкретної реалізації моделі COCOMO; точність калібрування - відповідність установок почат­ковим даним. У зв'язку з цим, для застосування засобів використо­вують персонал, який не мас прямого відношення до процесів про­ектування і розробки програмного забезпечення. Він формує спе­цифікації проекту і параметри, необхідні для оцінки, які надаються співробітникам, які виконують оцінювання.

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

Параметри вартості, Параметр вартості (cost driver) - це суб'єктивна величина, яка оцінює різні тимчасові, якісні і ресурс­ні аспекти розробки програмного забезпечення. Кожен з парамет­рів може бути відкалібрований. Калібрування параметрів вартості - це коректування значень параметрів, що впливає на значення трудовитрат, а отже, на якийсь час і на вартість, оцінюючи прог­рамний проект. При калібруванні за вказаними нижче сімнадцять­ма параметрами вибирається оцінний рівень (дуже високий, висо­кий, вище номінального, номінальний, нижче номінального, низь­кий, дуже низький) параметра. У формулах цей рівень відбиваєть­ся у вигляді коефіцієнта трудовитрат і, таким чином, на кожній стадії розробки проекту впливає на вартість і тривалість тієї або іншої стадії. Виділяють такі групи параметрів (табл.7.1): продукту (product factors), платформи (platform factors), персоналу (personnel factors) і проекту (project Jactors). У табл. 7.2 подано короткий опис кожного параметра.

Таблиця 7.1

Продукт Враховують характеристики того, що розробляється ПЗ (RELY. DATA, CPLX, RUSE, DOCU) Платформа Враховують характеристики програмно-апаратного комплексу, потрібного для функціонування ПЗ (TIME, STOR, PVOL) Персонал Враховують рівень знань і злагодженості роботи колекти­ву програмістів (АСАР, РСАР, PCON, APEX, PLEX. LTEX) Проект Враховують вплив сучасних підходів і технологій, тери­торіальну віддаленість членів колективу розробників і терміни виконання проекту (TOOL, SITE, SCED)

Таблиця 7.2

Параметр Опис RELY (Required Software Reliability) Враховує ступінь виконання програмою певної дії протягом певного часу DATA (Database Size) Враховує вплив обсягу тестових даних на розробку продукту. Рівень цього парамет­ра розраховується як співвідношення байт у тестованій базі даних до SLОС у прог­рамі CPLX (Product Complexity) Включає п'ять типів операцій; управління, рахункові, пристрійно-залежні, управління даними, управління, призначене для корис­тувача інтерфейсом, Рівець складності — це суб'єктивне середньозважене значення рівнів типів операцій RUSE (Developed for Reusability) Враховує трудовитрати (потрібні додатко­во для написання компонентів), призначе­ні для повторного використання в даному або подальших проектах. Використовує такі оцінні рівні: «у проекті», «у програ­мі», «у лінійці продуктів», «у різних ліній­ках продуктів». Значення параметра нак­ладає обмеження на параметри RELY і DOCU DOCU (Documentation Match To Life-Cycle Needs) Враховує ступінь відповідності докумен­тації проекту його життєвому циклу TIME (Execution Time Constraint) Враховує тимчасові ресурси, використову­вані ПЗ при виконанні поставленого зав­дання STOR (Main Storage Constraint) Враховує відсоток використання сховищ даних PVOL (Platform Volatility) Враховує термін «життя» платформи (комп­лекс апаратного і ПЗ, який потрібний для функціонування того, що розробляється ПЗ) АСАР (Analyst Capability) Враховує аналіз, здатність проектувати, ефективність і комунікативні здібності групи фахівців, які розробляють вимоги і специфікації проекту. Параметр непови­нен оцінювати рівень кваліфікації окремо взятого фахівця РСАР (Programmer Capability) Враховує рівень програмістів у колективі. При виборі значення для цього параметра слід звернути увагу на комунікативні і професійні здібності програмістів і на ко­мандну роботу в цілому PCON (Personnel Continuity) Враховує плинність кадрів у колективі APEX (Applications Experience) Враховує досвід колективу при роботі над додатками певною типу PLEX (Platform Experience) Враховує вміння використовувати особ­ливості платформ, такі як: графічний ін­терфейс, бази даних, мережевий інтер­фейс, розподілені системи LTEX (Language and Tool Experience) Враховує досвід програмістів (мови, сере­довища та інструменти) TOOL (Use Of Software Tools} Враховує рівень використання інструмен­тів розробки SITE (Multisite Development) Враховує територіальну віддаленість (від офісу до міжнародних офісів) членів ко­манди розробинків і використовувані ними засоби комунікації (від телефону до відео конференц-зв'язку) SCED (Required Development Schedule) Враховує вплив тимчасових: обмежень, що накладаються на проект і на значення тру­довитрат

СПИСОК ЛІТЕРАТУРИ