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

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

1.3.Процес оцінки

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

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

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

1.4.Аналіз ризиків

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

1.5.Планування

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

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

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

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

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

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

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

Системний аналіз проводять з метою: з'ясування потреб замовника; оцінки можливості реалізації системи;

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

і т. д.);

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

34

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

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

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

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

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

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

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

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

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

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

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

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

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

35

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

досить широко використовуються і тому їх можна порівнювати; прості і легко обчислюються.

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

не пристосовані до непроцедурних мов програмування. залежні від мови програмування;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37

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

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

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

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

користувачем.

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

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

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

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

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

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

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

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

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

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

39

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

i=1

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

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

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

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

40

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

властивостей (Features Points). Вони застосовні до системного і інженерного ПЗ, ПП реального часу і вбудованого ПЗ.

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

Таблиця 2.12. Початкові дані для розрахунку покажчика властивостей

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

Переваги функціонально-орієнтованих метрик: Не залежать від мови програмування.

Легко обчислюються на будь-якій стадії проекту. Недоліки функціонально-орієнтованих метрик: результати засновані на суб'єктивних даних, використовуються не прямі, а непрямі вимірювання.

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

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