Керівництво програмним проектом
В цьому розділі розглянемо такий процес конструювання ПЗ, як керівництво програмним проектом. Звернемо увагу на найбільш популярну модель оцінки затрат – COCMO 11. В якості ілюстрації наведемо приклади попередньої оцінки проекту, аналізу впливу на проект конкретних умов розробки.
Процес керівництва проектом
Керівництво програмним проектом – перший шар процесу конструювання ПЗ, підкреслимо, що керівництво процесу розробки проходить від початку до закінчення. Принцип керівництва проілюстровано на рис. 2.1.
Керівництво програмним проектом |
|||
ЕТАПИ |
|||
Аналіз |
Проектування |
Кодування |
Тестування |
|
Рис. 2.1. Керівництво в процесі конструювання ПЗ
Для проведення успішного проекту необхідно зрозуміти об’єм наступних робіт, можливий ризик, необхідні ресурси, наступні задачі, встановлення віх, вартість, план роботи якому необхідно слідувати.
Початок проекту
Перед плануванням проекту необхідно:
встановити цілі та проблемну область проекту;
обговорити альтернативні рішення;
виявити технічні та управлінські обмеження.
Виміри, міри та метрики
Виміри допомагають зрозуміти як процес розробки продукту так і сам продукт. Виміри процесу проводяться в цілях його покращення, виміру продукту – для підвищення його якості. В результаті виміру визначається міра – кількістна характеристика якої не будь характеристики об’єкту. Шляхом безносереднього вимірювання може визначатись тільки головні властивості об’єкту. Всі остання властивості оцінюються шляхом обчислень тих або інших функцій від зміни головних характеристик. Обчислення даних функцій проводиться за формулами, які визначають числові значення та називаються метриками.
В ІЕЕЕ Standard Glossary of Software Engineering Terms метрика визначається як міра степені володіння властивістю, що має числове значення. В програмній інженерії поняття міра і метрика дуже часто розглядають як синоніми.
Процес оцінки
При плануванні програмного проекту потрібно оцінити людські ресурси (в людино-місяцях), тривалість (календарних днях), вартість (в тис. гривень). Зазвичай виходять з минулого досвіду. Якщо новий проект за розміром і функціями подібний на попередній проект, достатньо ймовірно, що необхідно такі ж ресурси, час та гроші.
Аналіз ризику
На цій стадії досліджується область невизначеності, що існує в наявності перед створенням програмного продукту. Аналізується її вплив на проект та приймається рішення – виконувати проект або ні.
Планування
Визначається перелік проектних задач. Встановлюється зв'язок між задачами, оцінюється складність кожної задачі. Визначаються людські та інші ресурси. Створюється сітковий графік зада, проводиться його часова розмітка.
Трасування та контроль
Кожна задача, відмічена в плані, відслідковується керівником проекту. При відставанні в розв’язку задачі застосовуються утиліти повторного планування. За допомогою утиліт визначається вплив цього відставання на проміжну віху та загальний час конструювання. В результаті повторного планування:
можуть бути перерозподілені ресурси;
можуть бути реорганізовані задачі;
можуть бути переглянуті вихідні зобов’язання.
Планування проектних задач
Основною задачею при плануванні є визначення WBS – Work Breakdown Structure (структури розподілення робіт). Вона складається за допомогою утиліт планування проекту. Типова WBS наведена на рис. 2.2.
Першими задачами що виконуються є системний аналіз і аналіз вимог. Вони складають фундамент для наступних паралельних задач.
Системний аналіз проводиться з метою:
визначення потреб замовника;
оцінка виконуваності системи;
проведення економічного та технічного аналізу;
розподіл функцій по елементах комп’ютерної системи(апаратурі, програмам, людям, базах даних та ін.);
визначення вартості та обмежень планування;
створення системної специфікації.
В системній специфікації описуються функції, характеристики системи, обмеження розробки, вхідна та вихідна інформація.
Аналіз вимог дає можливість:
визначення функції і характеристики програмного продукту;
визначити інтерфейс продукту з іншими системними елементами;
визначити проектні обмеження програмного продукту;
побудувати моделі: процесу, даних, режимів функціонування продукту;
створити такі форми подання інформації системи, які можна використовувати в ході проектування.
створити такі форми відображення інформації і функцій системи, які можливо вик
Результати аналізу формуються в специфікацію вимог до програмного продукту.
Як видно з типової структури, задачі по проектуванню та плануванню тестів можуть бути розпаралелені. Завдяки модульній природі ПЗ для кожного модуля можливо передбачити паралельний шлях для детального (процедурного) проектування, кодування та тестування. Після отримання всіх модулів ПЗ вирішується задача тестування інтеграції – об’єднання елементів в єдине ціле. Далі проводиться тестування правильності, яке забезпечує перевірку відповідності ПЗ вимогам замовника.
Р омбами на рис. 2.2. позначені віхи – процедури контролю проміжних результатів. Дуже важливо, щоб віхи були розставлені через регулярні інтервали на протязі всього процесу розробки ПЗ. Це дає керівництву можливість регулярно отримувати інформацію про наявні результати справ. Віхи поширюються і на документацію як один із результатів як один із результатів успішного вирішення задачі. Паралельність дій підвищує вимоги до планування. Оскільки паралельні задачі виконуються асинхронно, планувальник повинен визначити міжзадачні залежності. Це гарантує «неперервність руху до об’єднання ». Крім того керівник проекту повинен знати задачі, що лежать на критичному шляху. Для того щоб весь проект був виконаний в заданий термін, необхідно виконати в задані терміни всі критичні задачі.
Основний засіб в плануючих методах – розрахунок часових меж виконання задачі.
Як правило використовуються наступні оцінки:
Ранній час початку вирішення задачі (при умові, що всі попередні задачі вирішені в найкоротший час).
Пізній час початку вирішення задачі (ще не викликає загальної затримки проекту).
Ранній час закінчення вирішення задачі , .
Пізній час закінчення вирішення задачі , .
Загальний резерв – кількість надлишків і втрат планування задач в часі, що не викликає збільшення тривалості критичного шляху Тк. ш..
Всі ці значення дозволяють керівнику кількісно оцінювати успіх в плануванні, виконанні задач.
Рекомендоване правило розподілу затрат проекту – 40 – 20 - 40:
на аналіз та проектування припадає 40% (з них на планування та системний аналіз – 5%);
на кодування – 20%;
на тестування та відладку -40%.