Ім'я файлу: Лекция_2.pptx
Розширення: pptx
Розмір: 837кб.
Дата: 18.06.2022
скачати
Пов'язані файли:
Курсова САПР Пархоменко.docx

Оцінка розміру і можливості повторного використання ПЗ
  • Визначення розмірів програмного продукту
  • Оцінка розміру ПЗ в процесі розробки проекту
  • Метод функціональних точок
  • Метод точок властивостей
  • Метод об’єктних точок

 При оцінці вартості проекту і кількості часу, потрібного для його виконання, потрібно виконати два основних етапи.

1. Оцінювання розміру проекту.

2. Відомості про ці розміри поряд з інформацією про інші фактори середовища, дозволяють оцінювати загальний об’єм трудовитрат і, відповідно, вартість робіт. Уточнення розмірів ПЗ, яке створюється, передує етапу кодування, яке виконується з метою реалізації вимог на практиці.

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

Одиниці виміру при оцінці розміру ПЗ

При використанні одиниць вимірювання виникає маса питань.

 Яким чином можна визначити кількість рядків коду (Lines of code, LOC) до того, як вони фактично будуть написані або просто спроектовані?

Як показник кількості рядків коду може відображати величину трудовитрат, якщо не буде враховуватися складність виробленого продукту, здатність/стиль програміста або можливості застосовуваного мови програмування?

Яким чином різниця в кількості рядків коду може бути трансформована в обсяг еквівалентної роботи?

Взаємозв'язок між LOC і затраченими зусиллями не є лінійної. Незважаючи на появу нових мов програмування, середня продуктивність програміста за останні 20 років залишилася незмінною і складає близько 3000 рядків коду на одного програміста в рік. Це говорить про те, що зменшення часу, що витрачається на цикл розробки, не може бути досягнуто за рахунок значного підвищення продуктивності праці програмістів. Причому це не залежить від удосконалень мови програмування, зусиль з боку менеджерів або від наявності/відсутності понаднормових робіт.

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

Приклади одиниць вимірювання при оцінці розміру ПЗ



- кількість рядків коду (Lines Of Code, LOC);

- функціональні точки;

- точки властивостей;

- кількість "бульбашок" на діаграмі потоку даних (Data flow diagram, DFD);

- кількість сутностей на діаграмі сутностей (Entity relationship diagram, ERD);

- кількість "квадратиків", відповідних процесу / контролю (PSPEC / CSPEC) на структурному графіку;

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

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

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

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

1. Створення структури переліку робіт – задачі розбиваються на невеликі складові елементи для оцінювання розміру.

2. Документування планів – обчислюються величини, трудовитрати, накладні витрати.

3. Оцінка вартості і трудовитрат, необхідних для завершення проекту - завдяки оцінці можливого розміру ПЗ можна судити про розмір запланованих трудовитрат. Всі ці параметри відображуються в плані управління ПП, також створюється план ризиків.

Наприклад, якщо розмір розробляється ПО оцінюється величиною в 500 LOC (одиниця оцінки розміру), а швидкість програмування в середньому дорівнює 5 LOC/год. (оцінка продуктивності), то в цьому випадку трудовитрати складуть 100 годин. Якщо невелика команда складається з двох чоловік, які можуть розподіляти між собою робоче навантаження, трудовитрати кожного з них складуть по 50 годин. Оцінка трудовитрат тягне за собою оцінку можливих накладних витрат. Якщо накладні витрати (вартість) для першого розробника складуть 15 доларів на годину, а накладні витрати для іншого розробника - 10 доларів на годину, то накладні витрати при розробці всього ПЗ складуть 1250 доларів ($ 15 * 50г. + $ 10 * 50г.) = $ 750 + $ 500= $ 1250.

4. Складання графіка – на основі оцінки трудовитрат можна скласти графік.

5. Вибір метричних показників - на базі застосовуваних одиниць виміру формується метричний показник. Його досить вибрати лише один раз (в попередньому прикладі LOC), а потім просто посилатися.

2. Оцінка розміру ПЗ в процесі розробки проекту

Оцінка показника LOC за допомогою експертних висновків і висхідного підсумовування

Кількість тисяч рядків вихідного коду (KSLOC) є похідним від загальної метрики, що вводиться при оцінках продуктивності.

Зазвичай продуктивність виражається в KSLOC / SM або KLOC / SM (де SM - staff-month (людино-години)).

Підрахунок рядків існуючого коду вручну є досить виснажливим і тривалим заняттям. В силу цього багато організацій придбають або розробляють автоматизовані LOC-лічильники.

Підрахунок вручну:

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

- Необхідно враховувати всі наявні оператори, які виконуються - кінцевий користувач може не мати можливості безпосередньо використовувати кожен оператор, але всі оператори повинні підтримуватися даним продуктом (в тому числі і утилітами).

- Визначення даних враховується лише один раз.

- Не враховуються рядки, що містять коментарі.

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

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

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

В таблиці 1.1. приведені показники SLOC для перетворення коду з мови програмування на мову Basic Assembler SLOC з розрахунку на одну функціональную точку.

Перший і другий стовпці таблиці 1.1 представляють метод трансляції SLOC, застосовуваний в різних мовах по відношенню до середнього кількості рядків SLOC в базовому мові асемблера. (Зверніть увагу, що SLOC і LOC є взаємозамінними.) Вважається за краще виконувати трансляцію з мов програмування на базовий мову асемблера з тієї простої причини, що в цьому випадку операції порівняння у багатьох проектів можуть виконуватися за ідентичною основою. Ці дані можуть бути корисними також у разі трансляції проекту зі звичайного мови програмування на мову перетворення.

Переваги LOC:
  • Ці одиниці вимірювання широко поширені и можуть легко адаптуватися;
  • дозволяють виконувати співставлення методів вимірювання розмірів і продуктивності в різних групах розробників;
  • безпосередньо пов'язані з кінцевім продуктом;
  • одиниці LOC легко оцінюються ще до завершення проекту;
  • оцінка розмірів ПЗ проводиться на основі точки зору розробника - фізична оцінка створення продукту (кількість написання рядків коду);

  • Недоліки LOC:
  • одиниці виміру LOC скрутні в застосуванні при оцінці розміру ПЗ на ранніх стадіях життєвого циклу розробки;
  • вихідні інструкції можуть відрізнятися в залежності від типів мов програмування, методів проектування, стилю і здібностей програміста;
  • застосування методів оцінки за допомогою підрахунку кількості рядків коду не регламентується промисловими стандартами (наприклад, ISO);
  • при підрахунку кількості одиниць LOC слід розрізняти автоматичний і вручну створений код - це завдання є більш складним, ніж "простий підрахунок", який може бути виконаний на основі лістингу, згенерованого компілятором, або за допомогою утиліти, яка виконує підрахунок рядків програмного коду;

3. Метод функціональних точок

При оцінці якості може застосовуватися наступна формула:

DQ=кількість дефектів / кількість рядків коду

 Чим більше величина DQ – тим нижче рівень програми.

Фаза кодування в більшості проектів зазвичай вимагає від 7% до 20% від загального обсягу трудовитрат. І звичайно, більш важливим є якість програмного коду, а не його обсяг. Результатом подібних роздумів є усвідомлення необхідності іншої одиниці виміру. Таким методом може виступати метод функціональних точок.

Метод функціональних точок (Function point, FP) ґрунтується на тому, що розмір ПЗ найкраще оцінювати в термінах кількості і складності функцій, реалізованих в даному програмному коді, а не за допомогою кількості рядків коду. При використанні методу функціональних точок вимірюються категорії призначених для користувача бізнес-функцій. При цьому спосіб їх визначення є більш методологічно, ніж в разі підрахунку рядків LOC.

Підхід, який раніше застосовувався, враховував лише розмір ПЗ; нинішній підхід враховує розмір і функціональні властивості.

Метод функціональних точок дозволяє виконувати наступні завдання:
  • оцінювати категорії призначених для користувача бізнес-функцій;
  • розв'язувати проблему, пов'язану зі спробою застосування одиниць вимірювання LOC на ранніх стадіях життєвого циклу розробки;
  • визначати кількість і складність вхідних і вихідних даних, запити до бази даних, файли або структури даних, а також зовнішні інтерфейси, пов'язані з програмною системою.

  • Короткий огляд процесу застосування функціональних точок:

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

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

    - встановлюються вимоги для кожної з категорій;

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

    - Здійснюється перетворення функціональних точок в одиниці виміру LOC за допомогою наступної формули:

    LOC = Функціональні точки * ADJ * множник перетворення

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

Заповнення таблиці методом функціональних точок.



3. Застосування фактору середовища

Приклад використання даного методу:

Задача ≪Заміна цифр на символ≫

Визначити клас з методом, який виконує заміну в рядку всіх цифр на символ-замінник. Рядок і символ-замінник прийняти через вхідні параметри. Рядок повертається через return.

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

  • 2. Інструкції по визначенню рівня складності

Метод точок властивостей

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

Фактор коригування складності

Метод об’єктних точок

В даному випадку кожному унікальному класу або об'єкту (екран, виведений звіт і т.д.) призначається одна об'єктна точка. В іншому цей метод подібний до методу функціональних точок і точок властивостей, лише слід врахувати, що застосовуються різні фактори перетворення. Представимо, що 20 класів об'єктів і їх характеристики виходять шляхом спостереження існуючих систем і реалізовані як середні величини в якості п'яти процедурних програм з розрахунку на один клас. Також шляхом спостереження за існуючими системами стало відомо, що середній розмір процедурної програми (мова С) дорівнює 75 LOC. Потім розмір може бути швидко обчислений наступним чином:

 Кількість процесів (класи об’єкта) * кількість програм з розрахунку на клас * розмір середньої програми = розрахунковий розмір

20 класів об’єкта * 5 програм на клас * 75 рядків LОC на програму = 7500 обчислених LОC

Якщо відомо, що кожна "бульбашка" процесу на рівні 0 DFD, приблизно відповідає 4 фактичним програмам на мові SQL, а також відомо, що середній розмір програм в бібліотеці SQL дорівнює 350 рядках LOC, тому просте множення буде достатнім для підрахунку початкового розміру. Відомо, що в даному випадку існує 7 основних "бульбашок" процесу:

Кількість процесів (“бульбашки" DFD) * кількість програм на }бульбашку" * розмір середньої програми = розрахунковий розмір

7 “бульбашок" * 4 програми на “бульбашку" * 350 рядків LOC на програму 9800 обчислених рядків LOC

Метод спільної розробки додатків (JAD) - це зареєстрований товарний знак, що відноситься до компанії IBM. Сеанс JAD має певну структуру, на ньому дотримуються певної дисципліни, і він проходить під керівництвом арбітра. В його основі лежить обмін інформацією з використанням документації, фіксованих вимог і правил роботи. З моменту появи методики JAD на сеансах використовуються CASE- інструменти та інші програмні засоби, призначені для побудови діаграм потоку даних (Data flow diagram, DFD), діаграм взаємозв'язків між сутностями (Entity relationship diagrams, ERD), діаграм зміни станів і інших об'єктно-орієнтованих діаграм.

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

Різні типи модифікованого коду

Типові множники повторного використання


Застосування множників повторного використання
скачати

© Усі права захищені
написати до нас