Ранг та оцінка складності зовнішніх виведень
Процес керування проектом
Для проведення успішного проекту потрібно:
1.Розуміти об’єкт робіт які потрібно виконати.
2.Можливий ризик.
3.Потрібні ресурси.
4.Майбутні задачі.
5.Необхідні зусилля.
6.План робіт, якого бажано дотримуватися.
Перед плануванням проекту потрібно:
1.Встановити цілі та проблемну область проекту.
2.Обсудити альтернативні рішення.
3.Знайти технічні та керуючі обмеження.
За допомогою вимірів визначаються опорні властивості об’єкту.
Метрики –це обчислення певних функцій від значень опорних характеристик.
При плануванні проекту потрібно оцінити людські ресурси, тривалість та вартість (за звичай використовують минулий досвід).
Під час планування визначається набір проектних задач, встановлюються зв’язки між задачами, оцінюється складність кожної задачі, визначається людський та інші ресурси, створюється сітковий графік задач та проводиться його тимчасова розмітка. Кожна задача яка відмічена в плані відслідковується керівником проекту. При запізненні у розв’язанні задачі застосовуються утіліти повторного планування.
В результаті повторного планування можуть бути:
1. Перерозподілені ресурси.
2. Реорганізовані задачі.
3. Переглянуті вихідні обов’язки.
Планування проектних задач
Основною задачею при плануванні являється визначення структури розподілу робіт. Спочатку виконується системний аналіз і аналіз вимог.
Мета системного аналізу:
1.Визначити потреби замовника.
2.Оцінювання виконуваності системи.
3.Виконання економічного і технічного аналізу.
4.Розподіл функцій за елементами комп'ютерної системи (апаратурі, програмам, людям, базам даних).
5.Визначення вартості і обмежень планування.
6.Створення системної специфікації.
У системній специфікації описуються функції, характеристики системи, обмеження розробки, вхідна і вихідна інформація.
Аналіз вимог дає можливість:
1.Визначити функції і характеристики програмного продукту;
2.Позначити інтерфейс продукту з іншими системними елементами;
3.Визначити проектні обмеження програмного продукту;
4.Побудувати моделі: процесу, даних, режимів функціонування продукту;
5.Створити такі форми представлення інформації і функцій системи, які можна використовувати в ході проектування.
Результати аналізу зводяться в специфікацію вимог до програмного продукту.
Задачі по проектуванню і плануванню тестів можуть бути паралельними.
Після отримання всіх модулів ПЗ вирішується завдання тестування інтеграції — об'єднання елементів в єдине ціле.
Тестування правильності забезпечує перевірку відповідності ПЗ вимогам замовника.
Основний важіль в плануючих методах — обчислення меж часу виконання задачі.
Зазвичай використовують наступні оцінки:
1. - ранній час початку розв’язання задачі (за умови, що всі попередні задачі вирішені в найкоротший час).
2. - пізній час початку розв’язання задачі (ще не викликає загальну затримку проекту).
3. - ранній час кінця розв’язання задачі.
4. - пізній час кінця розв’язання задачі.
5. - загальний резерв — кількість надлишків і втрат планування задачі в часі, що не приводять до збільшення тривалості критичного шляху.
Рекомендоване правило розподілу витрат проекту — 40-20-40:
· на аналіз і проектування приходиться 40% витрат (з них на планування і системний аналіз — 5%);
· на кодування — 20%;
· на тестування і відлагодження — 40%.
Розмірно-орієнтовані метрики (РОМ)
РОМ вимірюють ПП і процес його розробки. Базується РОМ на LOC-оцінках (Lines Of Code). LOC-оцінка — це кількість рядків в ПП.
Вихідні дані для розрахунку цих метрик зводяться до таблиці:
Проект | Витрати, люд.-міс | Вартість, тис. $ | KLOC, тис. LOC | Прогр. док-ти, сторінки | Помилки | Люди |
ааа01 | 12,1 | |||||
bbb02 | 27,2 | |||||
ссс03 | 20,2 |
Наприклад, запис про проект aaa01 показує: 12 100 рядків програми було розроблено за 24 людино-місяці і коштували $168 000. Крім того, за проектом aaa01 було розроблено 365 сторінок документації, а протягом першого року експлуатації було зареєстровано 29 помилок. Розробляли проект aaa01 3 людини.
На основі таблиці обчислюються РОМ-и продуктивності і якості (для кожного проекту):
1. ;
2. ;
3. ;
4. .
Переваги РОМ:
1.Широко поширені.
2.Прості і легко обчислюються.
Недоліки РОМ:
1.Залежні від мови програмування.
2.Вимагають початкових даних, які важко отримати на початковій стадії проекту.
3.Не пристосовані до не процедурних мов програмування.
Функціонально-орієнтовані метрики (ФОМ)
ФОМ побічно вимірюють програмний продукт і процес його розробки. Замість підрахунку LOC-оцінки при цьому розглядається не розмір, а функціональність або корисність продукту.
Використовується 5 інформаційних характеристик.
1. Кількість зовнішніх введень. Підраховуються всі введення користувача, по яких поступають різні прикладні дані. Введення повинні бути відокремлені від запитів, які підраховуються окремо.
2. Кількість зовнішніх виведень. Підраховуються всі виведення, по яких до користувача поступають результати, обчислені програмним застосуванням. У цьому контексті виведення означають звіти, екрани, роздруковки, повідомлення про помилки.
3. Кількість зовнішніх запитів. Під запитом розуміється діалогове введення, яке приводить до негайної програмної відповіді у формі діалогового виведення. При цьому діалогове введення в додатку не зберігається, а діалогове виведення не вимагає виконання обчислень. Підраховуються всі запити — кожен враховується окремо.
4. Кількість внутрішніх логічних файлів. Підраховуються всі логічні файли (тобто логічні групи даних, які можуть бути частиною бази даних або окремим файлом).
5. Кількість зовнішніх інтерфейсних файлів. Підраховуються всі логічні файли з інших додатків, на які посилається даний додаток.
Кожній з характеристик призначений низький, середній або високий ранг складності та формується числова оцінка рангу.
Тип елементу-запису — підгрупа елементів даних, розпізнавана користувачем в межах файлу.
Тип елементу даних — унікальне (неповторюване) поле, розпізнаване користувачем.
|
Посилання на файл | Елементи даних | ||
1 – 4 | 5 – 15 | > 15 | |
0 – 1 | н(3) | н(3) | с(4) |
н(3) | с(4) | в(6) | |
> 2 | с(4) | в(6) | в(6) |
Ранг та оцінка складності зовнішніх виведень