Глава 2. Керівництво програмним проектом

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

Процес керівництва проектом

Керівництво програмним проектом - перший шар процесу конструювання ПЗ. Термін «шар» підкреслює, що керівництво визначає сутність процесу розробки від його початку до кінця. Принцип керівництва ілюструє рис. 2.1.

Р ис. 2.1. Керівництво в процесі конструювання ПЗ

На цьому малюнку прямокутник позначає процес конструювання, в ньому виділені етапи, а вгорі, над кожним з етапів, розміщений шар діяльності «керівництво програмним проектом».

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

Початок проекту

Перед плануванням проекту слід:

• встановити цілі та проблемну область проекту;

• обговорити альтернативні рішення;

• виявити технічні й управлінські обмеження.

Виміри, міри і метрики

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

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

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

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

Аналіз ризику

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

Планування

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

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

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

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

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

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

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

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

Основним завданням при плануванні є визначення WBS - структури декомпозиції робіт (структури розподілу робіт). Вона складається за допомогою утиліти планування проекту. Типова WBS наведена на рис. 2.2.

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

Системний аналіз проводиться з метою: 1) з'ясування потреб замовника; 2) оцінки здійсненності системи; 3) виконання економічного та технічного аналізу;

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

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

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

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

Аналіз вимог дає можливість:

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

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

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

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

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

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

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

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

Основний важіль у плануючих методах - обчислення меж часу виконання завдання.

Зазвичай використовують наступні оцінки:

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

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

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

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

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

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

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

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

• на кодування - 20%;

• на тестування і налагодження - 40%.