Зміст
1. Введення
2. Керівництво програмним проектом
3. Планування проектних завдань
4. Конструктивна модель вартості
5. Висновок
6. Список літератури
Введення
Керівництво програмним проектом - перший шар процесу конструювання ПЗ. Термін "Шар" підкреслює, що керівництво визначає сутність процесу розробки від його початку до кінця. Принцип керівництва ілюструє рис. 2.1.
Рис. 2.1. Керівництво в процесі конструювання ПО
На цьому малюнку прямокутник позначає процес конструювання, в ньому виділено етапи, а вгорі, над кожним з етапів, розміщений шар діяльності "керівництво програмним проектом".
Для проведення успішного проекту потрібно зрозуміти обсяг майбутніх робіт, можливий ризик, необхідні ресурси, майбутні завдання, які прокладаються віхи, необхідних зусиль (вартість), план робіт, якому бажано слідувати. Керівництво програмним проектом забезпечує таке розуміння. Воно починається перед технічною роботою, продовжується в міру розвитку ПЗ від ідеї до реальності і досягає найвищого рівня до кінця робіт [32], [64], [69].
2. Керівництво програмним проектом
Початок проекту
Перед плануванням проекту слід:
В· встановити цілі та проблемну область проекту;
В· обговорити альтернативні рішення;
В· виявити технічні та управлінські обмеження.
Виміри, міри і метрики
Виміри допомагають зрозуміти як процес розробки продукту, так і сам продукт. Вимірювання процесу виробляються з метою його покращення, вимірювання продукту - для підвищення його якості. В результаті вимірювання визначається міра - кількісна характеристика якої-небудь властивості об'єкта. Шляхом безпосередніх вимірювань можуть визначатися тільки опорні властивості об'єкта. Всі інші властивості оцінюються в результаті обчислення тих чи інших функцій від значень опорних характеристик. Обчислення цих функцій проводяться за формулами, що дає числові значення і званим метриками.
У IEEE Standard Glossary of Software Engineering Terms метрика визначена як міра ступеня володіння властивістю, що має числове значення. В програмної інженерії поняття міра та метрика дуже часто розглядають як синоніми.
Процес оцінки
При плануванні програмного проекту треба оцінити людські ресурси (в людино-місяцях), тривалість (у календарних датах), вартість (у тисячах доларів). Зазвичай виходять з минулого досвіду. Якщо новий проект за розміром і функцій схожий на попередній проект, цілком імовірно, що будуть потрібні такі ж ресурси, час і гроші.
Аналіз ризику
На цій стадії досліджується область невизначеності, наявна перед створенням програмного продукту. Аналізується її вплив на проект. Чи немає прихованих від уваги важких технічних проблем? Чи не стануть зміни, проявилися в ході проектування, причиною неприпустимого відставання по термінах? У результаті приймається рішення - виконувати проект чи ні.
Планування
Визначається набір проектних завдань. Встановлюються зв'язки між завданнями, оцінюється складність кожного завдання. Визначаються людські та інші ресурси. Створюється мережевий графік завдань, проводиться його тимчасова розмітка.
Трасування й контроль
Кожна задача, позначена в плані, відстежується керівником проекту. При відставанні у вирішенні задачі застосовуються утиліти повторного планування. За допомогою утиліт визначається вплив цього відставання на проміжну віху і загальний час конструювання. Під віхою розуміється тимчасова мітка, до якої прив'язане підведення проміжних підсумків.
В результаті повторного планування:
В· можуть бути перерозподілені ресурси;
В· можуть бути реорганізовані завдання;
В· можуть бути переглянуті вихідні зобов'язання.
3. Планування проектних задач
Основний завданням при плануванні є визначення WBS - Work Breakdown Structure (Структури розподілу робіт). Вона складається за допомогою утиліти планування проекту. Типова WBS наведена на рис. 2.2.
Першими виконуваними завданнями є системний аналіз та аналіз вимог. Вони закладають фундамент для подальших паралельних завдань.
Системний аналіз проводиться з метою:
1. з'ясування потреб замовника;
2. оцінки здійснимість системи;
3. виконання економічного та технічного аналізу;
4. розподілу функцій за елементами комп'ютерної системи (апаратурі, програмами, людям, баз даних і т. д.);
5. визначення вартості та обмежень планування;
6. створення системної специфікації.
У системної специфікації описуються функції, характеристики системи, обмеження розробки, вхідна і вихідна інформація.
Аналіз вимог дає можливість:
1. визначити функції та характеристики Програмного продукту;
2. позначити інтерфейс продукту з іншими системними елементами;
3. визначити проектні обмеження програмного продукту;
4. побудувати моделі: процесу, даних, режимів функціонування продукту;
5. створити такі форми подання інформації та функцій системи, які можна використовувати в ході проектування.
Рис. 2.2. Типова структура розподілу проектних робіт
Результати аналізу зводяться в специфікацію вимог до програмному продукту.
Як видно з типової структури, завдання щодо проектування і планування тестів можуть бути распараллелен. Завдяки модульній природі ПО для кожного модуля можна передбачити паралельний шлях для детального (процедурного) проектування, кодування і тестування. Після отримання всіх модулів ПЗ вирішується завдання тестування інтеграції - об'єднання елементів у єдине ціле. Далі проводиться тестування правильності, яке забезпечує перевірку відповідності ПЗ вимогам замовника.
ромбики на рис. 2.2 позначені віхи - процедури контролю проміжних результатів. Дуже важливо, щоб віхи були розставлені через регулярні інтервали (уздовж всього процесу розробки ПЗ). Це дасть керівникові можливість регулярно отримувати інформацію про поточний стан справ. Віхи поширюються і на документацію як на один з результатів успішного вирішення завдання.
Паралельність дій підвищує вимоги до планування. Так як паралельні завдання виконуються асинхронно, планувальник повинен визначити межзадачного залежності. Це гарантує "безперервність руху до об'єднання". Крім того, керівник проекту повинен знати задачі, що лежать на критичному шляху. Для того щоб весь проект був виконаний в строк, необхідно виконувати в строк всі критичні завдання.
Основний важіль в плануючих методах - обчислення границь часу виконання завдання.
Зазвичай використовують наступні оцінки:
1. Ранній час початку рішення задачі T in min (за умови, що всі попередні завдання вирішені в найкоротший час).
2. Пізніше час початку рішення задачі T in max (ще не викликає загальну затримку проекту).
3. Ранній час кінця рішення задачі T out min
T out min = T in min + T реш
4. Пізніше час кінця рішення задачі T out max
T out max = T in max + T реш .
5. Загальний резерв - кількість надлишків та втрат планування завдань в часі, не призводять до збільшення тривалості критичного шляху T К.П .
Всі ці значення дозволяють керівнику (планувальником) кількісно оцінити успіх в плануванні, виконанні завдань.
Рекомендоване правило розподілу...
