5 Дисципліна тестування

Цілі тестування:

1) Перевірити взаємодії між об'єктами.

2) Перевірити належну інтеграцію всіх компонентів програмного забезпечення.

3) Щоб переконатися, що всі вимоги були правильно виконані.

4) Щоб визначити та переконатись що дефекти будуть розглянуті до розгортання програмного забезпечення.

5) Переконатись, що всі дефекти виправлені, повторно перевірені та закриті.

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

6 Дисципліна розгортання

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

7 Три допоміжні дисципліни

7.1 Дисципліна середовища

Дисципліна середовища зосереджується на діяльності необхідній для налаштування процесу під проект.

7.2 Дисципліна конфігурації та управління змінами

7.3 Дисципліна управління проектами.

Шість кращих практик RUP

Шість кращих практик як описані в RUP є парадигмою програмної інженерії, яка перечислює шість ідей яким варто слідувати при конструюванні будь-якого проекту щоб мінімізувати провали, та збільшити продуктивність. Цими практиками є:[1][2]

1 Ітеративна розробка

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

2 Управління вимогами

Завжди пам'ятати вимоги встановлені користувачами.

3 Використання компонент

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

4 Візуальне моделювання

Використовуйте діаграми щоб представити всі основні компоненти, користувачів, та їх взаємодії. «UML», скорочено від Unified Modeling Language, є інструментом що може зробити це завдання більш здійсненним.

5 Перевірка якості

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

6 Контроль змін

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

Класифікація вимог до системи FURPS

Класифікація вимог до системи FURPS+ була розроблена Робертом Грейді (Robert Grady) з Hewlett-Packard і запропонована в 1992 році.

Ідеологія FURPS – Functionality, Usability, Reliability, Performance, Supportability, тобто функціональність, юзабіліті, надійність, продуктивність, підтримування.

Скорочення FURPS розшифровується так:

1. Functionality, функціональність

2. Usability, зручність використання

3. Reliability, надійність

4. Performance, продуктивність

5. Supportability, підтримування

6. + Необхідно пам'ятати про такі можливі обмеження, як:

6.1 обмеження проектування, design

6.2 обмеження розробки, implementation

6.3 обмеження на інтерфейси, interface

6.4 фізичні обмеження, physical

Якщо застосувати до цієї класифікації популярний поділ вимог на функціональні та нефункціональні, то до останніх слід віднести всі перераховані вище групи крім першої, тобто URPS +.

Тепер давайте розглянемо кожну групу вимог докладніше.

Рисунок – Класифікація вимог до системи (детальна)