Зміст
Введення
Керівництво програмним проектом
Планування проектних завдань
Конструктивна модель вартості
Висновок
Список літератури
Введення
Керівництво програмним проектом - перший шар процесу конструювання ПЗ. Термін "шар" підкреслює, що керівництво визначає сутність процесу розробки від його початку до кінця. Принцип керівництва ілюструє рис. 2.1.
Рис. 2.1. Керівництво в процесі конструювання ПЗ
На цьому малюнку прямокутник позначає процес конструювання, в ньому виділено етапи, а вгорі, над кожним із етапів, розміщений шар діяльності "керівництво програмним проектом".
Для проведення успішного проекту потрібно зрозуміти обсяг майбутніх робіт, можливий ризик, необхідні ресурси, майбутні завдання, прокладаються віхи, необхідні зусилля (вартість), план робіт, яким необхідно дотримуватися. Керівництво програмним проектом забезпечує таке розуміння. Воно починається перед технічною роботою, продовжується в міру розвитку ПЗ від ідеї до реальності і досягає найвищого рівня до кінця робіт [32], [64], [69].
2. Керівництво програмним проектом
Початок проекту
Перед плануванням проекту слід:
встановити цілі та проблемну область проекту;
обговорити альтернативні рішення;
виявити технічні й управлінські обмеження.
Виміри, міри і метрики
Вимірювання допомагають зрозуміти як процес розробки продукту, так і сам продукт. Вимірювання процесу виробляються з метою його покращення, вимірювання продукту - для підвищення його якості. У результаті вимірювання визначається міра - кількісна характеристика якої-небудь властивості об'єкта. Шляхом безпосередніх вимірів можуть визначатися тільки опорні властивості об'єкта. Всі інші властивості оцінюються в результаті обчислення тих чи інших функцій від значень опорних характеристик. Обчислення цих функцій проводяться за формулами, що дає числові значення і званим метриками.
У IEEE Standard Glossary of Software Engineering Terms метрика визначена як міра ступеня володіння властивістю, що має числове значення. У програмній інженерії поняття міра і метрика дуже часто розглядають як синоніми.
Процес оцінки
При плануванні програмного проекту треба оцінити людські ресурси (в людино-місяцях), тривалість (у календарних датах), вартість (у тисячах доларів). Зазвичай виходять з минулого досвіду. Якщо новий проект за розміром і функцій схожий на попередній проект, цілком імовірно, що будуть потрібні такі ж ресурси, час і гроші.
Аналіз ризику
На цій стадії досліджується область невизначеності, яка є в наявності перед створенням програмного продукту. Аналізується її вплив на проект. Чи немає прихованих від уваги важких технічних проблем? Чи не стануть зміни, що проявилися в ході проектування, причиною неприпустимого відставання по термінах? У результаті приймається рішення - виконувати проект чи ні.
Планування
Визначається набір проектних завдань. Встановлюються зв'язку між завданнями, оцінюється складність кожного завдання. Визначаються людські та інші ресурси. Створюється мережевий графік завдань, проводиться його тимчасова розмітка.
Трасування і контроль
Кожне завдання, позначена в плані, відстежується керівником проекту. При відставанні у вирішенні завдання застосовуються утиліти повторного планування. За допомогою утиліт визначається вплив цього відставання на проміжну віху і загальний час конструювання. Під віхою розуміється тимчасова мітка, до якої прив'язане підведення проміжних підсумків.
У результаті повторного планування:
можуть бути перерозподілені ресурси;
можуть бути реорганізовані завдання;
можуть бути переглянуті вихідні зобов'язання.
3. Планування проектних завдань
Основним завданням при плануванні є визначення WBS - Work Breakdown Structure (структури розподілу робіт). Вона складається з допомогою утиліти планування проекту. Типова WBS наведена на рис. 2.2.
Першими виконуваними завданнями є системний аналіз та аналіз вимог. Вони закладають фундамент для подальших паралельних завдань.
Системний аналіз проводиться з метою:
з'ясування потреб замовника;
оцінки здійсненності системи;
виконання економічного і технічного аналізу;
розподілу функцій за елементами комп'ютерної системи (апаратурі, програмами, людям, баз даних і т. д.);
визначення вартості і обмежень планування;
створення системної специфікації.
У системній специфікації описуються функції, характеристики системи, обмеження розробки, вхідна і вихідна інформація.
Аналіз вимог дає можливість:
визначити функції та характеристики програмного продукту;
позначити інтерфейс продукту з іншими системними елементами;
визначити проектні обмеження програмного продукту;
побудувати моделі: процесу, даних, режимів функціонування продукту;
створити такі форми подання інформації та функцій системи, які можна використовувати під час проектування.
Рис. 2.2. Типова структура розподілу проектних робіт
Результати аналізу зводяться в специфікацію вимог до програмного продукту.
Як видно з типової структури, завдання з проектування та планування тестів можуть бути распараллелена. Завдяки модульній природі ПЗ для кожного модуля можна передбачити паралельний шлях для детального (процедурного) проектування, кодування і тестування. Після отримання всіх модулів ПЗ вирішується завдання тестування інтеграції - об'єднання елементів в єдине ціле. Далі проводиться тестування правильності, яке забезпечує перевірку відповідності ПЗ вимогам замовника.
Ромбиками на рис. 2.2 позначені віхи - процедури контролю проміжних результатів. Дуже важливо, щоб віхи були розставлені через регулярні інтервали (уздовж всього процесу розробки ПЗ). Це дасть керівникові можливість регулярно отримувати інформацію про поточний стан справ. Віхи поширюються і на документацію як на один з результатів успішного вирішення завдання.
Паралельність дій підвищує вимоги до планування. Так як паралельні завдання виконуються асинхронно, планувальник повинен визначити межзадачного залежності. Це гарантує "безперервність руху до об'єднання". Крім того, керівник проекту повинен знати завдання, що лежать на критичному шляху. Для того, щоб весь проект був виконаний в строк, необхідно виконувати в строк всі критичні завдання.
Основний важіль у плануючих методах - обчислення кордонів часу виконання завдання.
Зазвичай використовують наступні оцінки:
Раннє час початку виконання завдання T in min (за умови, що всі попередні завдання вирішені в найкоротший час).
Пізніше час початку виконання завдання T in max (ще не викликає загальну затримку проекту).
Раннє час кінця рішення задачі T out min
T out min = T in min + T реш
Пізніше час кінця рішення задачі T out max
T out max = T in max + T реш.
Загальний резерв - кількість надлишків та втрат планування задач у часі, що не приводять до збільшення тривалості критичного шляху T К.П.
Всі ці значення дозволяють керівнику (планувальником) кількісно оцінити успіх в плануванні, виконанні завдань.
Рекомендоване правило розподілу витрат проекту - 40-20-40:
на аналіз та проектування припадає 40% витрат (з них на планування та системний аналіз - 5%);
на кодування - 20%;
на тестування і налагодження - 40%.
Виконання в ході керівництва проектом
Процес керівництва програмним проектом починається з багатьох дій, що об'єднуються загальною назвою планування проекту. Перше з цих дій - виконання оцінки. Воно закладає фундамент для інших дій з планування проекту. При оцінці проекту надзвичайно висока ціна помилок. Дуже важливо провести оцінку з мінімальним ризиком.
Виконання оцінки проекту на основі LOC-та FP-метрик
Мета цієї діяльності - сформувати попередні оцінки, які дозволять:
пред'явити замовнику коректні вимоги по вартості і витрат на розробку програмного продукту;
скласти план програмного проекту.
При виконанні оцінки можливі два варіанти використання LOC-та FP-даних:
в якості оцінних змінних, що визначають розмір кожного елемента продукту;
в якості метрик, зібраних за минулі проекти і входять до метричний базис фірми.
Обговоримо кроки процесу оцінки.
Крок 1. Область призначення проектованого продукту розбивається на ряд функцій, кожну з яких можна оцінити індивідуально:
f 1, f 2, ..., f n.
Крок 2. Для кожної функції f 1 планувальник формує кращу LОС лучшi (FР лучшi), гіршу LOС ХУДШi (FР ХУДШi) і ймовірну оцінку LOС вероятнi (FР вероятнi). Використовуються досвідчені дані (з метричного базису) або інтуїція. Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.
Крок 3. Для кожної функції f i відповідно до β-розподілом обчислюється очікуване значення LOC-(або FP-) оцінки:
LOC ожi = LOC лучшi + LOC худшi + 4 x LOC вероятнi) / 6.
Крок 4. Визначається значення LOC-або FP-продуктивності розробки функції.
Використовується один з трьох підходів:
для всіх функцій приймається одна і та ж метрика середньої продуктивності Вироб ср, взята з метричного базису;
для i-ї функції на основі метрики середньої продуктивності обчислюється настроюється величина продуктивності:
Вироб i = Вироб ср х (LOС СР / LOС ожi),
де LOC cp - середня LOC-оцінка, взята з метричного базису (відповідає середній продуктивності);
4. Конструктивна модель вартості
У даній моделі для виведення формул використовувався статистичний підхід - враховувалися реальні результати величезної кількості проектів. Автор оригінальної моделі - Баррі Боемі (1981) - дав їй назву СОСОМО 81 (Constructive Cost Model) і ввів в її складу три різні за складністю статистичні подмодели [1].
Ієрархію подмоделей Боемі (версії 1981 року) утворюють:
базисна СОСОМО - статична модель, обчислює витрати розробки та її вартість як функцію розміру програми;
проміжна СОСОМО - додатково враховує атрибути вартості, що включають основні оцінки продукту, апаратури, персоналу та проектного середовища;
вдосконалена СОСОМО - об'єднує всі характеристики проміжної моделі, додатково враховує вплив всіх атрибутів вартості на кожен етап процесу розробки ПЗ (аналіз, проектування, кодування, тестування і т. д.).
Подмодели СОСОМО 81 можуть застосовуватися до трьох типів програмних проектів. За термінологією Боемі, їх утворюють:
поширений тип - невеликі програмні проекти, над якими працює невелика група розробників з гарним стажем роботи, встановлюються м'які вимоги до проекту;
напівнезалежний тип - середній за розміром проект, виконується групою розробників з різним досвідом, встановлюються як м'які, так і жорсткі вимоги до проекту;
вбудований тип - програмний проект розробляється в умовах жорстких апаратних, програмних і обчислювальних обмежень.
Рівняння базової подмодели мають вигляд
Е = a b x (KLOC b b [чол-міс];
D = c b x (E) d b [Mec],
де Е-затрати в людино-місяцях, D - час розробки, KLOC - кількість рядків у програмному продукті.
Висновок
СОСОМО II - авторитетна і багатопланова модель, що дозволяє вирішувати найрізноманітніші завдання управління програмним проектом.
Розглянемо можливості цієї моделі в задачах аналізу чутливості - чутливості програмного проекту до зміни умов розробки.
Будемо вважати, що корпорація "СверхМобільниеСвязі" замовила розробку ПЗ для вбудованої космічної системи обробки повідомлень. Очікуваний розмір ПЗ - 10 KLOC, використовується серійний мікропроцесор. Приймемо, що масштабні чинники мають номінальні значення (показник ступеня В = 1,16) і що автоматична генерація коду не передбачається. До проведення розробки залучаються головний аналітик і головний програміст високої кваліфікації, тому середня зарплата в команді складе $ 6000 на місяць. Команда має річний досвід роботи з цією проблемною областю і півроку працює з потрібною апаратною платформою.
У термінах СОСОМО II проблемну область (область застосування продукту) класифікують як "операції з приладами" з наступним описом: вбудована система для високошвидкісного мультіпріорітетного обслуговування віддалених ліній зв'язку, яка забезпечує можливості діагностики.
Оцінку пост-архітектурних факторів витрат для проекту зведемо в табл. 2.27.
З таблиці випливає, що збільшення витрат в 1,3 рази з-за дуже високої складності продукту врівноважується їх зменшенням внаслідок високої кваліфікації аналітика і програміста, а також активного використання програмних утиліт.
Список літератури
Боемі Б. У. Інженерне проектування програмного забезпечення. М.: Радіо і зв'язок, 1985. 511 с.
Липа В. В. Налагодження складних програм: Методи, засоби, технологія. М.: Вища школа, 1993. 384 с.
Майерс Г. Мистецтво тестування програм. М.: Фінанси і статистика, 1982. 176с.
Орлов С. А. Принципи об'єктно-орієнтованого та паралельного програмування на мові Ada 95. Рига: TSI, 2001. 327 с.
Чеппел Д. Технології ActiveX і OLE. M.: Російська редакція, 1997. 320 с.
Abreu, F. У., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS'96. Santa Barbara, California 1920 pp. July 1996.