Лекція 4. Управління програмним проектом.

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

метриками.

У IEEE Standard Glossary of Software Engineering Terms метрика визначена як міра ступеня володіння властивістю, що має числове значення. У програмній інженерії поняття

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

•Процес оцінки

•При плануванні програмного проекту треба оцінити людські ресурси (у людино-днях),

тривалість (у календарних датах) і його вартість (у тисячах у.о.).

•Зазвичай виходять з минулого досвіду. Якщо новий проект за розміром і функціями схожий на попередній проект, цілком імовірно, що буде потрібно такі ж ресурси, час і гроші (а для цього потрібно вести історію своїх проектів).

•Аналіз ризиків

На цій стадії досліджується область невизначеності, що постає перед створенням програмного продукту. Аналізується її вплив на проект. Чи немає прихованих від уваги важких технічних проблем? Чи не стануть зміни, що виявляться в ході проектування, причиною неприпустимого відставання по термінах? В результаті ухвалюється рішення — як усунути ризики та чи братись за виконання проекту взагалі…

• Планування

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

• Трасування і контроль

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

Врезультаті повторного планування:

можуть бути перерозподілені ресурси;

можуть бути реорганізовані завдання;

можуть бути переглянуті вихідні зобов'язання.

2.Планування проектних завдань

Основним завданням при плануванні є визначення WBS — Work Breakdown Structure (низхідна структура розподілу робіт). Вона складається за допомогою утиліти планування проекту. Типова WBS приведена на рис.4.2.

Першими виконуваними завданнями є системний аналіз і аналіз вимог замовника до ПП. Ці документи закладають фундамент для формування подальших паралельних завдань.

35

Лекція 4. Управління програмним проектом.

Системний аналіз проводять з метою:

1)з'ясування потреб замовника;

2)оцінки можливості реалізації системи;

3)виконання економічного і технічного аналізу;

4)розподілу функцій по елементах комп'ютерної системи (апаратурі, програмах, людях, базах даних і т. д.);

5)визначення вартості і обмежень планування;

6)створення функціональної специфікації.

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

Аналіз вимог функціональної специфікації дає можливість:

1)визначити функції і характеристики програмного продукту;

2)позначити інтерфейс продукту з іншими системними елементами;

3)визначити проектні обмеження програмного продукту;

4)побудувати моделі: процесу, даних, режимів функціонування продукту;

5)створити такі форми представлення інформації і функцій системи, які можна використовувати в ході проектування.

Рис. 4.2. Типова структура розподілу робіт над програмним проектом.

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

Як видно з типової структури, проектні роботи над окремими модулями ПП та роботи по проектуванню і плануванню тестів можуть бути розпаралелені. Завдяки модульній природі ПЗ для кожного модуля можна передбачити паралельний шлях для детального (процедурного) проектування, кодування і тестування. Після отримання всіх модулів ПЗ вирішується завдання інтегрального тестування — тобто об'єднання модульних елементів в єдиний ПП. Далі проводиться тестування правильності, яке забезпечує перевірку відповідності ПЗ вимогах замовника.

Ромбами на рис.4.2 позначені віхи (milestone) — процедури контролю проміжних результатів. Важливо, щоб віхи були регулярно розставлені через певні інтервали (впродовж усього процесу розроблення ПП). Це допоможе керівнику регулярно отримувати інформацію про поточну ситуацію. Віхи розповсюджуються і на документацію як на один з результатів успішного вирішення задачі.

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

36

Лекція 4. Управління програмним проектом.

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

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

1.Ранній час початку рішення задачі Тminin (за умови, що всі попередні завдання вирішені в найкоротший час).

2.Пізній час початку рішення задачі Тmaxin (ще не викликає загальну затримку проекту).

3.Ранній час закінчення рішення задачі Тminout .

Tminout +Tminin +Tріш .

4.Пізній час закінчення рішення задачі Тmaxout .

Tmaxout +Tmaxin +Tріш .

5.Загальний резерв — кількість запланованого надлишку або втрати часу, що не приводять до збільшення тривалості критичного шляху Тк.ш.

Всі ці значення дозволяють керівнику (спеціалісту з планування) кількісно оцінити хід виконання завдань.

Правило розподілу витрат проекту: 40-20-40:

на аналіз і проектування припадає — 40% витрат (з них на системний аналіз — 5%);

на кодування — 20%;

на тестування і відладку — 40%.

3.Розмірно-орієнтовані метрики

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

Розмірно-орієнтовані метрики прямо вимірюють програмний продукт і процес його розробки. Грунтуються розмірно-орієнтовані метрики на LOC-оцінках (Lines Of Code).

LOC-оцінка — це кількість рядків в програмному продукті. Початкові дані для розрахунку цих метрик беруться з попередніх проектів і водяться в наступну таблицю.

Таблиця 4.1. Початкові дані для розрахунку LOC-метрик

Таблиця містить дані про проекти за декілька останніх років.

Наприклад, запис про проект «aaa01» показує: 12 100 рядків програми було розроблено за 24 людино-місяці і це коштувало $168 000. Крім того, за проектом «aaa01» було розроблено 365 сторінок документації, а протягом першого року експлуатації було зареєстровано 29 помилок. Розробляли проект «aaa01» три людини.

На основі таблиці обчислюються розмірно-орієнтовані метрики продуктивності і якості (для кожного проекту):

37

Лекція 4. Управління програмним проектом.

Продуктивність: Пр = Довжина тис.LOC ; Затрати люд.- міс.

Якість: Як = Помилки Одиниць ; Довжина тис.LOC

Питома_вартість: Пв = Вартість Тис.$ ; Довжина LOC

Достоїнства розмірно-орієнтованих метрик:

1)досить широко використовуються і тому їх можна порівнювати;

2)прості і легко обчислюються.

Недоліки розмірно-орієнтованих метрик:

1)не пристосовані до непроцедурних мов програмування.

2)залежні від мови програмування;

3)вимагають початкових даних, які важко отримати на початковій стадії проекту;

4.Функціонально-орієнтовані метрики

Функціонально-орієнтовані метрики також вимірюють програмний продукт і процес його розробки, але роблять це непрямими методами. Замість підрахунку LOC-оцінки при цьому розглядається не розмір, а функціональність або корисність продукту.

Використовується 5 інформаційних характеристик.

1.Кількість зовнішніх способів введень. Підраховуються всі способи введення користувачем різних прикладних даних. Такі введення повинні бути відокремлені від запитів, які підраховуються окремо.

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

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

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

5.Кількість зовнішніх інтерфейсних файлів. Підраховуються всі логічні файли з інших застосувань, на які посилається даний ПП.

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

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

38

Лекція 4. Управління програмним проектом.

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

Зовнішній запит — елементарний процес, що працює як з тими, що вводяться, так і з виводяться даними. Його результат — дані, повертані з внутрішніх логічних файлів і зовнішніх інтерфейсних файлів. Вхідна частина процесу не модифікує внутрішні логічні файли, а вихідна частина не несе даних, що обчислюються програмою (у цьому і полягає відмінність запиту від виводу).

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

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

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

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

Тип елементу-запису — підгрупа елементів даних, розпізнавана користувачем в межах файлу.

Тип елементу даних — унікальне не рекурсивне (неповторюване) поле, розпізнаване користувачем.

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

Таблиця 2.3. Приклади елементів даних

Таблиця 2.4. Правила обліку елементів даних з графічного інтерфейсу користувача

39

Лекція 4. Управління програмним проектом.

вважається окремим елементом даних

Списки Список може бути зовнішнім запитом, але результат запиту може бути елементом даних зовнішнього введення

Дані для визначення рангу і оцінки складності транзакцій і файлів приведені в табл. 2.5- 2.9 (числова оцінка вказана в круглих дужках). Використовувати їх дуже просто. Напр., зовнішньому введенню, яке посилається на 2 файли і має 7 елементів даних, по табл. 2.5 призначається середній ранг і оцінка складності 4.

Таблиця 2.5. Ранг і оцінка складності зовнішніх введень

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

Після збору всієї необхідної інформації приступають до розрахунку метрики — кількості функціональних покажчиків FP (Function Points). Автором цієї метрики є А.Албрехт (1979).

Початкові дані для розрахунку зводяться в табл. 2.10.

40

Лекція 4. Управління програмним проектом.

Таблиця 2.10. Початкові дані для розрахунку FP-метрик

У таблицю заноситься кількісне значення характеристики кожного виду (по всіх рівнях складності). Місця підстановки значень відмічені прямокутниками (прямокутник грає роль мітки-заповнювача). Кількісні значення характеристик умножаються на числові оцінки складності. Набутих в кожному рядку значень підсумовуються, даючи повне значення для даної характеристики. Ці повні значення потім підсумовуються по вертикалі, формуючи загальну кількість.

Кількість функціональних покажчиків обчислюється за формулою

i=1

де Fi — коефіцієнти регулювання складності. Коефіцієнт може приймати наступні значення: 0 — немає впливу, 1 — випадкове, 2 — невелике, 3 — середнє, 4 — важливе, 5 — основне.

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

Таблиця 2.11. Визначення системних параметрів ПЗ

41

Лекція 4. Управління програмним проектом.

Після обчислення FP на його основі формуються метрики продуктивності, якості і т. д.:

Область застосування методу функціональних покажчиків — комерційні інформаційні системи. А для продуктів з високою алгоритмічною складністю використовуються метрики покажчиків властивостей (Features Points). Вони застосовні до системного і інженерного ПЗ, ПП реального часу і вбудованого ПЗ.

Для обчислення покажчика властивостей додається одна характеристика — кількість алгоритмів. Алгоритм тут визначається як обмежена підпрограма обчислень, яка включається в загальну комп'ютерну програму. Приклади алгоритмів: обробка переривань, інвертування матриці, розшифровка бітового рядка. Для формування покажчика властивостей складається табл. 2.12.

Після заповнення таблиці, аналогічно як і в попередньому випадку, за формулою (4.1) обчислюється значення покажчика властивостей. Для складних систем реального часу це значення на 25-30% більше значення, що обчислюється по таблиці для кількості функціональних покажчиків.

Достоїнства функціонально-орієнтованих метрик:

•Не залежать від мови програмування.

•Легко обчислюються на будь-якій стадії проекту.

Недолік функціонально-орієнтованих метрик:

•результати засновані на суб'єктивних даних,

•використовуються не прямі, а непрямі вимірювання.

FP-оцінки легко перерахувати в LOC-оцінки. Як показано в табл. 2.13, результати перерахунку залежать від мови програмування, використовуваного для реалізації ПО.

42

Лекція 4. Управління програмним проектом.

Таблиця 2.13. Перерахунок FP-оценок в LOC-оценки

5.Оцінка проекту на основі LOC- і FP-метрик

Мета цієї діяльності — сформувати попередні оцінки, які дозволять:

•пред'явити замовникові коректні вимоги за вартістю і витратами на розробку програмного продукту;

•скласти план програмного проекту.

При виконанні оцінки можливі два варіанти використання LOC- і FP-данных:

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

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

Обговоримо кроки процесу оцінки.

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

f1, f2, fn.

Крок 2. Для кожної функції fi, планувальник формує кращу LOC+ (FР+), гіршу LOC- (FР-) і вірогідну оцінку LOC0 (FР0). Використовуються досвідчені дані (з метричного базису) або інтуїція. Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.

Крок 3. Для кожної функції, відповідно до розподілу, обчислюється очікуване значення LOC (або FP) оцінки:

LOCоч =(LOC+ + LOC- +4*LOC0 )/ 6.

Крок 4. Визначається значення LOC або FP продуктивності розробки функції.

Використовується один з трьох підходів:

1)для всіх функцій приймається одна і та ж метрика середньої продуктивності Продср, узята з метричного базису;

2)для i-ї функції на основі метрики середньої продуктивності обчислюється величина продуктивності, що настроюється:

Продi =Продср * (LOCср /LOCоч i),

де LOCcp — середня LOC оцінка, узята з метричного базису (відповідає середній продуктивності);

43

Лекція 4. Управління програмним проектом.

3)для i-ї функції величина продуктивності, що настроюється, обчислюється по аналогу, узятому з метричного базису:

Продi =Продан i * (LOCан i /LOCоч i).

Перший підхід забезпечує мінімальну точність (при максимальній простоті обчислень), а третій підхід — максимальну точність (при максимальній складності обчислень).

 Крок 5. Обчислюється загальна оцінка витрат на проект: для першого підходу

ЗАТРАТИ = (∑n LOCочi ) / Продср[люд.- міс];

i=1

для другого і третього підходів

ЗАТРАТИ = ∑n (LOCочi / Продi )[люд.- міс].

i=1

Крок 6. Обчислюється загальна оцінка вартості проекту: для першого і другого підходів

ВАРТІСТЬ = (∑n LOCочi ) ×ПИТ_ВАРТІСТЬср ,

i=1

де ПИТ_ВАРТІСТЬср — метрика середньої вартості одного рядка, узята з метричного базису.

для третього підходу

ВАРТІСТЬ = ∑n (LOCочi ×ПИТ_ВАРТІСТЬанi ),

i=1

де ПИТ_ВАРТІСТЬан i — метрика вартості одного рядка аналога, узята з метричного базису.

44