• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Метод випадкового використання

У 1993 Gustav Karner розробив метод випадкового використання (Use Case Points method). Метод застосовується до об'єктно-орієнтованого програмування для вимірювання і оцінки проектів. Цей метод є вдосконаленим методом FPA і його версії MK II. Основна перевага - оцінювання виконується користувачем (функціональність програми), а не дизайнером або програмістом. Метод випадкового використання розроблений на основі моделей UML.

Моделі випадкового використання в UML

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

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

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

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

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

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

Модель випадкового використання - абстрактне представлення системи, видиме акторами, які її використовують. Деталі відображаються, оскільки обгрунтування відбувається на абстрактному рівні. Діаграми містять в собі акторів (персони) і випадкові використання (еліпси з ім'ям). Стрілки на графічному зображенні, які зв'язують акторів і випадкове використання, також включені. Випадкове використання представляє системні функції, тому взаємозв'язки між випадковим використання – це взаємозв'язки між окремими функціями. Одне випадкове використання бере до уваги поведінку іншого. UML вводить також і інші відносини: "розширення" і "використання" позначають стрілками. "Розширення" означає розширення одного випадкового використання іншим, "використання" означає загальний фрагмент багатьох випадкових використань. Загальна частина характеризується концептуальною схожістю, і її вилучення спрощує реалізацію.

Моделі і оцінка випадкового використання

Правильна оцінка, заснована на випадковому використанні, залежить від розробленої структури моделі.

Якість підходу значень випадкового використання залежить від:

· ретельного вибору і моделювання акторів, розширяючи їх на декілька персон та моделюючи одну персону багатьма акторами,

· ретельного зображення взаємозв'язків між випадковим використанням,

· відповідного рівня деталізації, використаного в моделюванні.

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

Алгоритм оцінки випадкового використання

Класифікація акторів і випадкове використання

Значення обчислюються, грунтуючись на діаграмах випадкового використання. Актори класифікуються як прості, середні або складні.

Простий актор представляє зовнішню систему, яка зв'язується з нашою через інтерфейс, зазвичай - через API - програмний інтерфейс програми (Application Program Interface).

Актор середньої складності - зовнішня система, зазвичай з TCP/IP, HTTP або подібних, символічного терміналу. Бази даних також входять в цей тип.

Складний актор - кінцевий користувач, що зв'язується з системою через інтерфейс або www.

Кожному акторові призначається відповідна вага:

Таблиця. 12.8.1. Ваги, привласнені акторам методами оцінки випадкового використання.

В кінці нескоректовані ваги акторів (UAW, Unadjusted Actor Weights) повинні бути обчислені шляхом підсумовування числа акторів, помножених на відповідні коефіцієнти.

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

Класифікація випадкового використання наступна:

· Простий випадок використання - складається з трьох і менше транзакцій,

· Середній випадок використання - складається з семи і менше транзакцій,

· Складний випадок використання - складывается з більш ніж семи транзакцій.

Таблиця 12.8.1.a Привласнення вагів для випадкового використання в методі оцінки випадкового використання.

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

Технічна модифікація і модифікація середовища

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

Таблиця 12.8.2. Ваги, привласнені технічним чинникам.

Підсумовуються результати технічних чинників і вагів і їх сума називається TFactor. Технічний чинник складності (TCF, Technical Complexity Factor) обчислюється за формулою:

TCF = 0.6 + (0.01 * TFactor)

Таблиця 12.8.2.a Ваги, привласнені чинникам середовища.

Результати чинників середовища і відповідної ваги підсумовується і цей результат чинника середовища називається - EFactor.

Чинник середовища EF обчислюється по наступній формулі:

EF = 1.4 + (-0.33 * EFactor)

Скоректована оцінка випадкового використання, AUCP (Adjusted Use Case Points) обчислюються шляхом множення нескоректованої оцінки випадкового використання, UUCP (Unadjusted Use Case Points) на технічний коефіцієнт і коефіцієнт складності середовища:

UCP = UUCP* TCF* EF

У класичному методі оцінки випадкового використання вважається, що один UCP відповідає 20 програмістам * час.

8. Короткий звіт

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

У наступній таблиці ми показуємо декілька груп вимірювань програмного забезпечення.

Малюнок 12.9.1. показує застосування методів оцінки.

Мал. 12.9.1. Застосування методів оцінки.

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

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

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

XIII. Управління конфігурацією ПЗ і версіями

1. Управління конфігурацією ПЗ

Метою управління конфігурацією ПЗ (SCM, Software Configuration Management) є планування, організація, контроль і координування всіх дій в розробці ПЗ. Ці дії означають знаходження проблем, зберігання ПЗ і його зміна на всіх етапах розвитку.

Конфігурація важлива для ефективної розробки і подальшого обслуговування ПЗ.

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

Недолік відповідного управління конфігурацією може "підвісити" програму.

Огляд управління конфігурацією ПЗ

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

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

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

Завдання супервізора в управління конфігурацією ПЗ.

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

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

Виконання управління конфігурації ПЗ

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

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

Малюнок 13.2.1. Управління конфігурацією ПЗ.

Найголовніші дії зображені на малюнку 13.2.1.

2. Елементи конфігурації ПЗ

Елементи конфігурації

Всі елементи проекту і ПЗ повинні розглядатися управлінням конфігурації ПЗ. УКПЗ містить:

· документації вимог, аналізу, проектування, тестування, призначену для користувача документацію і т.д.,

· модулі з початковим кодом, об'єднаним кодом, двійковим кодом,

· інтерфейс користувача,

· файли з текстовими даними (наприклад, повідомлення), словниками і т.п.,

· компілятори, інтерпретації, бібліотеки, протоколи, інструменти CASE, апаратура і т.п.,

· тестування ПЗ і даних,

· www-сервери з відповідними html-сторінками і ПЗ.

Ієрархія конфігурації ПЗ

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

Малюнок 13.3.1. Ієрархія конфігурації елементів.

Читайте також:

1. D) методу мозкового штурму.
2. H) інноваційний менеджмент – це сукупність організаційно-економічних методів управління всіма стадіями інноваційного процесу.
3. I Метод Шеннона-Фано
4. I. Метод рiвних вiдрiзкiв.
5. VII. Нахождение общего решения методом характеристик
6. А. науковий факт, b. гіпотеза, с. метод
7. А. Розрахунки з використанням дистанційного банкінгу.
8. Автоматизація водорозподілу на відкритих зрошувальних системах. Методи керування водорозподілом. Вимірювання рівня води. Вимірювання витрати.
9. Агрегативна стійкість, коагуляція суспензій. Методи отримання.
10. АгротехнІЧНИЙ метод
11. Адаптовані й специфічні методи дослідження у журналістикознавстві
12. Адміністративні (прямі) методи регулювання.

Переглядів: 705