Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
lek_2_prog.doc
Скачиваний:
4
Добавлен:
07.08.2019
Размер:
298.5 Кб
Скачать

19

Керівництво програмним проектом

В цьому розділі розглянемо такий процес конструювання ПЗ, як керів­ництво програмним проектом. Звернемо увагу на найбільш популярну модель оцінки затрат – COCMO 11. В якості ілюстрації наведемо приклади попередньої оцінки проекту, аналізу впливу на проект конкретних умов розробки.

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

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

Керівництво програмним проектом

ЕТАПИ

Аналіз

Проектування

Кодування

Тестування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планування

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

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

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

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

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

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

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

Основною задачею при плануванні є визначення WBS – Work Break­down Structure (структури розподілення робіт). Вона складається за допомогою утиліт планування проекту. Типова WBS наведена на рис. 2.2.

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

Системний аналіз проводиться з метою:

  • визначення потреб замовника;

  • оцінка виконуваності системи;

  • проведення економічного та технічного аналізу;

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

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

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

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

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

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

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

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

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

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

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

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

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

Р омбами на рис. 2.2. позначені віхи – процедури контролю проміжних результатів. Дуже важливо, щоб віхи були розставлені через регулярні інтерва­ли на протязі всього процесу розробки ПЗ. Це дає керівництву можливість регу­лярно отримувати інформацію про наявні результати справ. Віхи поширюються і на документацію як один із результатів як один із результатів успішного вирі­шення задачі. Паралельність дій підвищує вимоги до планування. Оскільки паралельні задачі виконуються асинхронно, планувальник повинен визначити міжзадачні залежності. Це гарантує «неперервність руху до об’єднання ». Крім того керівник проекту повинен знати задачі, що лежать на критичному шляху. Для того щоб весь проект був виконаний в заданий термін, необхідно виконати в задані терміни всі критичні задачі.

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

Як правило використовуються наступні оцінки:

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

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

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

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

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]