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

11. Виконання оцінки проекту на основі loc- і fp-метрик

Мета цієї діяльності - сформувати попередні оцінки, які дозволять:

- пред'явити замовникові коректні вимоги за вартістю і витратами на розробку програмного продукту;

- скласти план програмного проекту.

При виконанні оцінки можливі два варіанти використання LOC- і FP-данных:

- як оцінні змінні, що визначають розмір кожного елементу продукту;

- як метрики, що зібраних за минулі проекти і входять в метричний базис фірми.

Порядок проведення процедури оцінки.

1. Область призначення проектованого продукту розбивається на ряд функцій, кожну з яких можна оцінити індивідуально: f1, f2..., fn.

2. Для кожної функції fi планувальник формує кращу Locлучшi(Fpлучшi), гіршу Locхудшi(Fpхудшi) і вірогідну оцінку Locвер i(Fpвер i). Використовуються досвідчені дані (з метричного базису) або інтуїція. Діапазон значення оцінок відповідає ступеню передбаченої невизначеності.

3. Для кожної функції fi відповідно до розподілу обчислюється очікуване значення LOC- (або FP-) оцінки:

4. Визначається значення LOC- або FP-производительности розробки функції. Використовується один з трьох підходів:

а) для всіх функції приймається одна і та ж метрика середньої продуктивності Проїзвср, узята з метричного базису;

б) для i-й функції на основі метрики середньої продуктивності обчислюється величина продуктивності, що настроюється:

,где Loccp - середня LOC-оценка, узята з метричного базису (відповідає середній продуктивності);

в) для i-й функції величина продуктивності, що настроюється, обчислюється по аналогу, узятому з метричного базису:,

Перший підхід забезпечує мінімальну точність (при максимальній простоті обчислень), а третій підхід - максимальну точність (при максимальній складності обчислень).

5. Обчислюється загальна оцінка витрат на проект

12. Проект. Склад і структура колективу розробників, їх функції.

Сучасні крупні проекти ІС характеризуються, як правило, наступними особливостями:

- складність опису (достатньо велика кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними), що вимагає ретельного моделювання і аналізу даних і процесів;

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

- відсутність прямих аналогів, що обмежує можливість використання яких-небудь типових проектних рішень і прикладних систем;

- необхідність інтеграції що існують і знов розробляються додатків;

- функціонування в неоднорідному середовищі на декількох апаратних платформах;

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

- істотна тимчасова протяжність проекту, обумовлена, з одного боку, обмеженими можливостями колективу розробників, і, з іншого боку, масштабами організації-замовника і різним ступенем готовності окремих її підрозділів до впровадження ІС.

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

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

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

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

Зрозуміло, що як склад, так і значущість ролей розробників і тих, хто з ними пов'язаний, розрізняються залежно від виконуваного проекту, від колективу виконавців, прийнятої технології, від інших чинників. Неоднозначність вибору ролей приводить до того, що їх список часто стає непомірно великий (ілюстрацією тому може служити перша редакція документації по Rational Unified Processing (RUP), в якій визначено понад 20 ролей; у подальших версіях документа це число скорочене до осяжного рівня [30]). Надмірне збільшення числа є наслідок ототожнення ролі і функції і, відповідно, ігнорування поняття спорідненості функцій. В той же час, якщо ролей вибрано недостатньо, є небезпека, що не всі потрібні в проекті функції будуть охоплені плануванням і управлінням.