М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Шаблон робочої книги (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) Враховує вплив тимчасових: обмежень, що накладаються на проект і на значення трудовитратСПИСОК ЛІТЕРАТУРИ
