Цілі й завдання реінжинірингу
Цілі реінжинірингу
Цілі проведення реінжинірингу полягають в наступному:
· одержання уяви про склад існуючої системи;
· моделювання існуючої системи;
· визначення фрагментів програмного коду, які можуть бути використані в розроблювальній новій системі;
· визначення наслідуваних даних.
Завдання реінжинірингу
Завдання, розв'язувані при реінжинірингу, включають:
· визначення системних архітектур;
· визначення акторів існуючої системи;
· визначення функціональності існуючої системи;
· визначення логічної структури системи;
· відновлення реляційної моделі даних.
Порядок рішення цих завдань принципово відрізняється від порядку дій, виконуваних при розробці нових проектів. Логічна архітектура системи визначена її реалізацією, зокрема, структурою каталогів, розміщенням файлів по каталогах, розподілом завдань між сервером і клієнтськими місцями. Крім того, частина моделей системи може бути отримана автоматично за допомогою інструментальних засобів. Таким чином, не функціональний опис системи є основою для виявлення класів і відносин між ними, а навпаки, попередньо отримані діаграми класів можуть суттєво полегшити опис поведінки системи.
Проблеми при реінжинірингу
Як правило затверджується, що "легше розробити новий програмний продукт". Це зв'язане з наступними проблемами:
1. Звичайному програмісту складно розібратися в чужому ісходному коді
2. Реінжиніринг найчастіше дорожче розробки нового програмного забезпечення, тому що потрібно убрати обмеження попередніх версій, але при цьому залишити сумісність із попередніми версіями
3. Реінжиніринг не може зробити програміст з низкою й середньої кваліфікації. Навіть професіонали часто не можуть якісно реалізувати його. Тому потрібна робота програмістів з великим досвідом переробки програм і знанням різних технологій.
У той же час, якщо споконвічно програма мала строгу і ясну архітектуру, то провести реінжиніринг буде на порядок простіше. Тому при проектуванні, як правило, аналізується, що вигідніше: провести реінжиніринг або розробити програмний продукт "з нуля".
Керування вимогами
Вимоги до ПС
Вимога – це характеристика або умова, якому повинна задовольняти ПС.
Функціональні вимоги визначають дії, які повинна виконувати ПС, без урахування фізичних обмежень. Тим самим вони визначають поведінку системи при введенні й виведенні. Процес виявлення функціональних вимог досить складний і трудомісткий. Це пояснюється наступними причинами:
· таких вимог до системи звичайно багато,
· замовник не завжди здатний чітко сформулювати, чого він прагне від системи,
· вимоги в підсумковому документі повинні бути викладені так, щоб вони однаково розумілися замовником і виконавцем і не допускали неоднозначності,
· між функціональними вимогами можуть бути різні залежності, що ускладнюють керування ними, якщо буде потреба внесення змін.
Для подолання цих труднощів застосовується моделювання вимог. Модель вимог дозволяє, по-перше, установити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне представлення вимог і залежностей між ними, по-третє, дозволяє зв'язати графічну форму представлення з текстовою, забезпечуючи людину повною інформацією.
Нефункціональні вимоги не описують поведінку програмної системи, але описують її атрибути або атрибути оточення. Нефункціональні вимоги не потрібно включати в модель вимог, але вони повинні бути точно сформульовані. Звичайно нефункціональних вимог не буває багато, однак вони кардинальним образом впливають на вибір архітектури системи.
Керування вимогами – це досить складний і розтягнутий у часі процес. Він триває протягом більшої частини життєвого циклу, оскільки зміни можуть вноситися як під час розробки, так і після здачі системи на етапі дослідної експлуатації й при супроводі. Причини цього в тому, що вимоги:
· неочевидні,
· ісходять із багатьох джерел,
· важко формулюються (мова неоднозначна),
· складаються з безлічі різних деталей,
· нерівнозначні,
· зв'язані один з одним,
· лежать не тільки у функціональній області.
· можуть змінюватися протягом розробки й при супроводі.
Цілі аналізу й моделювання вимог
Цілями аналізу й моделювання вимог є:
· досягнення угоди між розроблювачами, замовниками й користувачами про те, що повинна робити ПС;
· досягнення кращого розуміння розроблювачами того, що повинна робити система;
· обмеження системної функціональності;
· створення базису для планування розробки проекту;
· визначення користувацького інтерфейсу;
· складання специфікації вимог.
Ролі
· Системний аналітик – фахівець організації-розроблювача, який очолює й координує роботи з виявлення й моделюванню вимог.
· Розроблювач ВВ – фахівець організації-розроблювача, який деталізує й уточнює моделі вимог.
· Зацікавлені особи – люди, що надають інформацію.
· Експерт – представник замовника, що брав участь у розробці моделі вимог.
· Розроблювач користувацького інтерфейсу – фахівець організації-розроблювача, який створює прототип користувацького інтерфейсу ПС.
Артефакти
Для досягнення поставлених цілей передбачається створення наступних документів:
· Попередня згода – текстовий документ, який описує, що буде включено в ПС і що вирішено виключити, тобто, він обмежує системну функціональність. У ньому відображаються побажання зацікавлених осіб, а також вказуються основні нефункціональні вимоги (наприклад, описується платформа реалізації, точність обчислень, час відгуку).
· Модель вимог служить для досягнення угоди між замовником і розроблювачами, даючи можливість замовникові переконатися в тому, що система буде робити те, що вони очікують, а розроблювачам - створити те, що потрібно. Модель вимог дозволяє, по-перше, установити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне представлення вимог і залежностей між ними, по-третє, дозволяє зв'язати графічну форму представлення з текстовою. Модель включає акторів і ВВ, показує, як система взаємодіє з акторами, й що вона робить у кожному ВВ.
· Специфікація вимог (Software Requirements Specification) – основний документ, використовуваний при проектуванні й розробці ПС. Вона включає модель вимог і додаткові специфікації, які являють собою текстовий опис вимог до кінцевого продукту, але не до процесу його розробки й не містить деталей реалізації вимог.
· Прототип користувацького інтерфейсу забезпечує візуальне представлення інтерфейсу користувача із ПС.
· Глосарій – текстовий документ, що містить визначення основних понять і термінів, які повинні однаково розумітися замовником і розроблювачем.
Джерелами даних для створення перерахованих артефактів можуть, зокрема, служити артефакти, створені при бізнес-аналізі.
Процес
У процесі аналізу й моделювання вимог можна виділити кілька основних етапів (див. рис.1).
Рис.1 Технологічний процес керування вимогами.
Початок аналізу.
Спочатку слід визначити коло зацікавлених осіб. Якщо проводився бізнес-аналіз, то вони вже відомі. Збираються побажання зацікавлених осіб до майбутньої ПС. Ці побажання аналізуються, визначаються основні властивості й границі ПС, досягаються угоди про те, які проблеми повинні бути вирішені.
Результати. Повинен бути складений документ « Попередня угода», який буде відправною точкою для виконання всіх наступних робіт. На цьому етапі починається створення глосарія. Якщо глосарій був створений при бізнес-аналізі, то він використовується як відправний документ. Оскільки тут мова йде про виявлення вимог до ПС, у глосарій можуть включатися терміни, що відносяться до реалізації (наприклад, браузер, сервер і ін.). Визначення цих термінів повинно сприяти кращому розумінню системи зацікавленими особами.
Побудова моделі вимог
Ця робота передбачає виявлення акторів, ВВ й взаємодій між ними. Якщо було проведене обстеження організації, то в якості джерела для визначення акторів і ВВ може служити бізнес-модель.
Якщо число ВВ занадто велике, то для спрощення читаності й підтримки моделі доцільно розділити їх по пакетах. Це також спрощує розуміння моделі й розподіл відповідальності шляхом призначення розроблювачів, відповідальних за пакети ВВ. Пакети дозволяють організувати ієрархію вимог. Верхній рівень ієрархії звичайно визначається, виходячи з основних видів діяльності організації. Якщо був виконаний бізнес-аналіз, то основні види діяльності вже представлені в бізнес-моделі у вигляді пакетів, і вони можуть бути просто скопійовані в модель вимог. Пакетів верхнього рівня не повинне бути багато. Доцільно виділити пакет адміністрування й пакет допоміжних дій, і 2 – 4 пакета основних видів діяльності. У свою чергу, пакети верхнього рівня можуть включати пакети наступного рівня і т.д.
Коли ви окреслите ісходну модель вимог, ви повинні уважно перевірити, що вона покриває всі заявки зацікавлених осіб, що представлені в документі « Попередня угода».
Деталізація моделі вимог
Цілі даної діяльності:
· витяг з ВВ характерних фрагментів, які можуть розглядатися як окремі абстрактні ВВ. Прикладами таких частин можуть бути загальні фрагменти, необов'язкові фрагменти й виключення;
· виявлення нових абстрактних акторів, які відіграють ролі, що поділяються декількома акторами;
· реструктуризація моделі вимог;
· детальний опис потоків подій для ВВ;
· завдання пріоритетів ВВ.
Коли ви просунетеся досить далеко, ви можете захотіти переглянути ісходну модель, оскільки існує тенденція вводити спочатку занадто багато акторів. Слід пам'ятати, що будь-яка модифікація акторів може викликати істотні зміни в системному інтерфейсі й поведінці.
Деталізація ВВ припускає розробку діаграм послідовностей, кооперацій або діяльностей, що описують виконання основної і допоміжних робіт у конкретному ВВ.
Визначення пріоритетів означає, що всі ВВ ранжуються на критичні, важливі й допоміжні. Критичні ВВ, представляють основну системну функціональність або мають істотне архітектурне значення. Важливі ВВ визначають такі системні функції, як збір статистики, складання звітів, контроль і функціональне тестування. Якщо вони не реалізовані, то система може виконувати своє призначення, але зі значно гіршою якістю сервісу. Допоміжні ВВ визначають зручність використання ПС.
Складання додаткових специфікацій
Додаткові специфікації являють собою текстові описи вимог. Вони доповнюють модель вимог і поряд з нею включаються в підсумковий документ – специфікацію вимог до ПС. Слід чітко розуміти, що кожний ВВ є деяка ієрархічна вимога до ПС. Дуже важливо, щоб між моделлю вимог і описом вимог у специфікації була точна відповідність. Якщо ВВ простій, то в специфікації він описується як окрема функціональна вимога. У більш складних випадках ВВ може бути розбитий на декілька більш простих варіантів (на діаграмах це можна зробити за допомогою пакетів, увівши ще один рівень ієрархії, у специфікації – увести наступний рівень нумерації).
Проектування користувацького інтерфейсу
Цей процес виконується для того щоб замовник міг більш точно уявити собі роботу й можливості майбутньої ПС і видати свої зауваження й уточнення вимог. Залежно від складності проекту й рівня підготовленості замовника результати цих робіт можуть бути представлені в різних формах:
· програмна реалізація, що відтворює точний вигляд екранних вікон;
· альбом екранних форм;
· модель навігації екранів у вигляді діаграм класів із вказівкою атрибутів – полів і операцій – кнопок.
Створення специфікації вимог
Специфікація вимог створюється на основі моделі вимог і додаткових специфікацій. Вона затверджується керівництвом замовника й розроблювача й служить основним відправним документом для проектування й розробки. Зокрема, модель вимог, що входить у неї, надалі буде розвинена в модель аналізу й дизайну.
Аналіз і проектування
Ціль і завдання аналізу й проектування
Ціль процесу аналізу й проектування полягає в розробці технічних інструкцій, що пропонують, як реалізувати ПС, що задовольняє сформульованим вимогам. Для цього слід добре зрозуміти вимоги до ПС і перетворити їх у проект системи, вибравши правильну стратегію реалізації. На ранніх стадіях процесу повинна бути створена стійка архітектура, на основі якої можна спроектувати ПС, легку для розуміння, побудови й розгортання. Архітектура повинна бути погоджена із середовищем реалізації з метою задоволення вимог по продуктивності, стабільності, безпеки, розширюваності й тестуємості.
До розв'язуваних завдань при цьому відносяться:
· розробка точної архітектури розподіленої програмної системи;
· перетворення моделі вимог у проектну модель розроблювальної системи;
· адаптація проекту системи до середовища реалізації з метою підвищення продуктивності розробки;
· вибір механізмів реалізації й визначення обмежень на реалізацію;
· розробка компонентної структури;
· розподіл компонентів по вузлах.
Головним завданням аналізу є перетворення вимог у форму, зрозумілу розроблювачеві, тобто, визначення підсистем, компонентів і класів, за допомогою яких реалізується необхідна поведінка ПС. В основі такого перетворення лежать ВВ, створені при визначенні вимог до ПС. При цьому розглядаються тільки функціональні вимоги й ігноруються нефункціональні.
Проектування– це уточнення результатів аналізу, спрямоване на оптимізацію з урахуванням обмежень, що накладаються нефункціональними вимогами, середовищем реалізації і т.д.
Ролі
Системний архітектор – керує роботами з аналізу й проектуванню ПС. Він визначає загальну структуру кожного архітектурного представлення, декомпозицію представлень, угруповання елементів і інтерфейси між групами.
Розроблювач – проектує класи й відносини між ними Він визначає, як погоджувати класи із середовищем реалізації.
Розроблювач БД – відповідає за проектування бази даних ПС.
Артефакти
У процесі аналізу й проектування створюються наступні документи:
Модель проектування – це основна модель ПС. Вона описує підсистеми, пакети, компоненти, інтерфейси й класи, а також їх взаємодії, що забезпечують необхідне поведінку ПС.
Документ «Архітектура ПС», у якому зібрані різні архітектурні представлення ПС.
Модель даних – це опис структури даних, збережених у БД (наприклад, реляційна модель даних).
Технологічний процес
Спрощена схема діяльностей, що виконуються в окремій ітерації процесу аналізу й проектування, наведена на рис.2. Виконання деяких діяльностей залежить від фази розробки, що показане у вигляді коментарів на діаграмі діяльностей.
Рис.2 Діаграма діяльностей, що описує процес аналізу й проектування
Визначення потенційної архітектури. Дана діяльність включає архітектурний аналіз і аналіз ВВ. Визначається первісний набір архітектурно значимих елементів і механізмів реалізації, виконується початкова розбивка на рівні, визначається структура системи, вибираються ВВ, які будуть реалізовуватися в першій ітерації фази розвитку проекту. У результаті створюється ескіз архітектури ПС. На основі аналізу архітектурно значимих ВВ визначаються основні класи, які включаються в модель аналізу. У модель аналізу включаються діаграми, що описують взаємодію основних класів.
Уточнення архітектури. Діяльність включає визначення механізмів проектування, елементів проекту, об'єднання існуючих елементів проекту, опис архітектури реального часу (якщо проектована ПС відноситься до цього класу). У результаті виконання цих робіт досягаються наступні цілі:
· Забезпечується перехід від аналізу до проектування шляхом визначення з елементів і механізмів аналізу - елементів і механізмів проектування;
· Підтримується цілісність і несуперечність архітектури шляхом інтеграції нових елементів проекту, обумовлених у поточній ітерації, із уже існуючими й повторним використанням доступних елементів проекту.
· Здійснюється плавний перехід від проектування до реалізації;
Аналіз поведінки. Ця діяльність включає аналіз ВВ, визначення елементів проекту й огляд проекту. Ця діяльність має на меті перетворення описів поведінки у вигляді ВВ в набір елементів проекту (класи, відносини, операції й ін.).
Проектування компонентів. Цілі даної діяльності полягають в:
· Визначенні й уточненні елементів проекту шляхом докладного опису того, як ці елементи реалізують необхідну поведінку.
· Визначенні й уточненні реалізації ВВ на основі нових елементів проекту.
· Контролі й рецензуванні проекту в міру його розвитку.
Проектуються ВВ, підсистеми, класи й компоненти ПС. Точно описуються інтерфейси компонентів і їх реалізація.
Проектування БД. Дана діяльність виконується для проектів, що використовують бази даних. Вона включає:
· Визначення персистентних (постійно зберігаємих) класів;
· Проектування структури БД для зберігання таких класів;
· Визначення механізмів і стратегій зберігання й доступу до збережених даних, що задовольняють вимогам по продуктивності й надійності ПС.
Аналіз і проектування зв'язує керування вимогами й реалізацію. У цьому технологічному процесі створюється модель проектування. Одне з її представлень – логічна модель – відображає декомпозицію ПС у набір логічних елементів (класи, підсистеми, взаємодії). Процедурне представлення відображає ці елементи в процеси й підпроцеси системи. Представлення розгортання відображає ці процеси в набір вузлів обчислювального комплексу, на яких вони виконуються.
Реалізація
9.
Цілі процесу реалізації
Основні цілі процесу можна сформулювати в такий спосіб:
· Визначити структуру коду у вигляді рівнів;
· Реалізувати компоненти, класи й об'єкти;
· Провести блокове тестування компонентів;
· Інтегрувати розробки, що виконані окремими розроблювачами, у єдину виконуючу систему.
У процес реалізації не включене тестування всієї ПС, для якого в RUP передбачений окремий процес.
Особливості процесу реалізації
RUP припускає поелементну інтеграцію протягом усього життєвого циклу. Це означає, що коди пишуться невеликими блоками, після чого вони поєднуються в єдине ціле шляхом поступового додавання блоків. Це спрощує процес локалізації помилок. Передбачено два рівні інтеграції – інтеграція результатів роботи групи розроблювачів у підсистему й інтеграція підсистем у ПС. Інтеграція відбувається в кожній ітерації відповідно до плану ітерації, де визначені ВВ, які проектують і реалізуються в цій ітерації. Таким чином, план ітерації визначає класи, які будуть реалізовані в цій ітерації.
У фазі конструювання створюється еволюційний прототип системи, який згодом розбудовується в кінцеву ПС. Це прототип використовується для демонстрації фрагментів ПС замовникові й керівництву. За результатами представлення прототипу можна одержати зауваження, які дозволяють уточнити, змінити або доповнити вимоги до ПС. RUP декларує можливість створення, крім еволюційних, поведінкових одноразових прототипів для проведення певних досліджень, що стосуються функціональних можливостей системи.
В RUP декларується необхідність відповідності моделі й програмного коду. При цьому допускається можливість зміни коду з наступною переробкою моделі, яка забезпечувала б необхідну відповідність. Для цієї мети використовують інструментальні засоби, що включають можливості автоматичного реінжинірингу.
Ролі
Конструктор (кодувальник) розробляє компоненти й класи, виконує блокове тестування.
Системний інтегратор виконує інтеграцію елементів у програмні конструкції (систему й підсистеми).
Архітектор визначає структуру реалізації (організацію рівнів і підсистем).
Рецензент коду перевіряє якість програмного коду і його відповідність стандартам проекту.
Артефакти
Підсистема реалізації - це набір компонент і інших підсистем реалізації, які використовуються для утворення моделі реалізації. Це поняття дозволяє ієрархічно представити модель реалізації.
Компонент - частина програмного коду.
План інтеграції - документ, що визначає порядок реалізації компонентів і підсистем.
Процес
Створення моделі реалізації. Ця діяльність виконується у фазі розвитку. Метою її є побудову моделі реалізації, яка дозволить щонайкраще виконати розробку й кодування. При цьому кінцевий продукт буде створюватися за допомогою прототипів, що послідовно укрупнюються.
Планування ітерації. Для кожної ітерації треба визначити, які підсистеми повинні бути реалізовані в цій ітерації й порядок їх інтегрування. За яку підсистему відповідає конкретний конструктор, що визначає порядок реалізації класів.
Реалізація компонентів. Виконується написання вихідних кодів програм, їх компіляція, формування коду, що виконується, і блокове тестування. Блокове тестування виконує сам кодувальник. Це, по суті, автономне налагодження розроблених програм. При виявленні помилок в ісходний код вносяться зміни, після чого зазначені дії повторюються. Після завершення блокового тестування перевіряється якість ісходного коду і його відповідність прийнятим стандартам проекту.
Інтеграція підсистем. Якщо підсистема розробляється групою виконавців, виконується інтеграція компонентів, розроблених усіма членами групи. Інтеграція підсистеми завершується створенням набору програмних конструкцій підсистеми, кожна з яких тестується окремо.
Інтеграція системи. Виконується інтеграція системи шляхом послідовного додавання в неї нових підсистем, створених у рамках поточної ітерації. Інтеграція підсистеми завершується створенням набору програмних конструкцій підсистеми, кожна з яких тестується окремо. Для тестування системи в RUP передбачений окремий процес.
Тестування
Тестування – це процес, що дозволяє оцінити якість виробленого продукту. Якісний програмний продукт повинен відповідати пропонованим до нього вимогам як функціональним, так і нефункціональним. ПС повинна реалізовувати всі необхідні ВВ й не мати дефектів – відмінностей реально існуючих властивостей або поведінки від необхідних. Крім того, ПС повинна мати властивості надійності ( повинні бути відсутніми зависання, аварійні відмови та ін.), безпеки, забезпечувати потрібну продуктивність, бути зручною в експлуатації, розширюваною і т.д. Таким чином, тестування являє собою процес аналізу ПС, спрямований на виявлення дефектів і на оцінку властивостей ПC.
Цілі процесу тестування
Метою тестування є оцінка якості програмного продукту шляхом
· Перевірки взаємодії компонентів;
· Перевірки правильності інтеграції компонентів;
· Перевірки точності реалізації всіх вимог і виявлення дефектів.
Особливості процесу тестування в RUP
Тестування – це ітеративний процес, виконуваний у всіх фазах життєвого циклу. Робота над тестами починається із самого початкового етапу виявлення вимог до майбутнього продукту й тісно інтегрується з поточними завданнями. На кожну ітерацію визначається мета тестування й методи її досягнення. Наприкінці кожної ітерації визначається, наскільки ця мета досягнута, чи потрібні додаткові випробування, чи не треба змінити принципи й інструменти тестування.
Кожний знайдений дефект реєструється в базі даних проекту з описом ситуації, у якій він знайдений. Аналітик визначає, чи дійсно це дефект і чи не є він повтором виявленого раніше дефекту. Знайденому дефекту привласнюється пріоритет, що визначає важливість виправлення. Конструктор, відповідальний за розробку підсистеми, компонента або класу, або інший виконавець, призначений керівником, приступає до усунення дефекту. Порядок виправлення дефектів регулюється їхніми пріоритетами. Тестувальник повторює виконання тестів і переконується (або не переконується) в усуненні дефекту.
Ролі
Розроблювач тестів відповідає за планування, розробку й реалізацію тестів. Він створює план і модель тестування, методики випробувань (див. нижче) і виконує оцінку результатів тестування.
Тестувальник (випробувач) відповідає за виконання системного тестування. У його обов'язки входить настроювання й виконання тестів, оцінки виконання тесту, відновлення після помилок, реєстрація виявлених дефектів.
Артефакти
У процесі тестування створюються наступні документи:
План тестування – документ, що визначає стратегію тестування в кожній ітерації. Він містить опис цілей і завдань тестування в поточній ітерації, а також стратегій, які будуть використовуватися. У плані вказується, які будуть потрібні ресурси, і приводиться перелік тестів.
Модель тестування – це представлення того, що і як буде тестуватися. Модель включає набір контрольних завдань, методик випробування, сценаріїв випробувань і очікуваних результатів (test cases), тестових скриптів і описів взаємодій тестів.
· Контрольне завдання – набір тестових даних, умов виконання тестів і очікуваних результатів.
· Методика випробувань – документ, що містить вказівки по настроюванню й виконанню контрольних завдань, а також по оцінці одержуваних результатів.
· Сценарій тестування – це спрощений опис тесту, включаючи вихідні дані, умови й послідовності виконання дій і очікувані результати.
· Тестовий скрипт є програмою, виконуваної при автоматичному тестуванні за допомогою інструментальних засобів тестування.
· Опис взаємодії тестів являє собою діаграму послідовностей або кооперацій, що відображає впорядкований у часі потік повідомлень між компонентами тестів і об'єктом тестування.
Результати тестування й дані, отримані в процесі виконання тестів.
Модель робочого навантаження використовується для моделювання зовнішніх функцій, які виконуються кінцевими користувачами, обсягів цих функцій і навантаження, яке створюється цими функціями. Модель призначається для проведення навантажувального й/або стресового тестування, що імітує роботу системи в реальних умовах.
Дефекти – це описи виявлених при проведенні тестування фактів невідповідності системи потрібним вимогам. Вони являють собою вид запитів на внесення змін.
Процес
Роботи з тестування виконуються в кожній ітерації у всіх фазах, але цілі й завдання в різних фазах проекту суттєво різні.
Фаза входження в проект. У цій фазі виконується підготовка до тестування. Вона включає:
· Створення плану тестування, що містить вимоги до тестів і стратегії тестування. Може створюватися єдиний план для всіх видів тестування (функціональне, навантажувальне і т.д.) або окремі плани для кожного виду.
· Аналіз обсягу тестування.
· Формулювання критеріїв якості й завершення тестування.
· Установку й підготовку до роботи інструментальних засобів тестування.
· Формулювання вимог до проекту розробки ПС, обумовлених потребами тестування.
Фаза розвитку. В ітераціях цієї фази починається побудова моделі тестування й пов'язаних з нею артефактів. Оскільки в цій фазі вже присутня модель ВВ, то можна починати проектувати сценарії тестування. У той же час недоцільне виконання тестів, оскільки звичайно в цій фазі ще не існує завершених фрагментів ПС. Виконуються наступні діяльності:
· Створення плану тестування для кожної ітерації.
· Розробка сценаріїв тестування.
· Створення заготовок тестових скриптів.
· Розробка контрольних завдань.
· Розробка методики випробувань.
· Розробка моделі робочого навантаження.
Фаза конструювання. У цій фазі з'являються завершені фрагменти систем і прототипи, які повинні тестуватися. При цьому практично в кожній ітерації перевіряються всі модулі ( як раніше розроблені й протестовані, так і нові, додані в поточній ітерації). Тести, застосовані в попередніх ітераціях, використовуються й на наступних для регресійного тестування, тобто для перевірки того, що раніше реалізована функціональність системи збереглася в новій ітерації. Виконуються наступні діяльності:
· Створення плану тестування для кожної ітерації.
· Уточнення й доповнення моделі тестування.
· Виконання тестів.
· Опис виявлених дефектів.
· Опис результатів тестування.
· Оцінка результатів тестування.
За результатами тестування вносяться зміни в програмний код з метою усунення виявлених дефектів, після чого тестування виконується повторно.
Фаза розгортання. В ітераціях цієї фази виконується тестування всієї ПС як програмного продукту. Виконувані діяльності аналогічні діяльностям попередньої фази. Виявлення дефектів визначає необхідність внесення змін і повторного тестування. Ітераційний процес повторюється доти, поки не будуть виконані критерії завершення тестування.
Оцінка результатів тестування проводиться на основі метрик тестування, що дозволяють визначити якість тестируємої ПС і самого процесу тестування.
Інструментальна підтримка
Оскільки ітераційний процес тестування передбачає багаторазове повторення тестів, ручне тестування стає неефективним і не дозволяє ретельно оцінити якість програмного продукту. Особливо це стосується навантажувального й стресового тестування, де потрібно моделювати робоче навантаження й накопичується значний обсяг даних. Вихід полягає в застосуванні інструментальних засобів, що підтримують автоматизацію складання й виконання тестів.
Процеси підтримки
RUP передбачає три процеси підтримки:
· Керування проектом;
· Керування конфігурацією;
· Керування середовищем.
Управління проектом. Цілі
Основною метою процесу керування проектом є забезпечення керівництва проектом, спрямоване на успішну здачу програмного продукту. RUP акцентує увагу на плануванні життєвого циклу й окремих ітерацій, керуванні ризиками, на спостережності ходу проекту й на метриках проекту.
Планування припускає створень двох видів планів:
· План фаз – великомасштабний план проекту, що показує основні віхи життєвого циклу (дати завершення великих етапів – фаз, випуску еволюційних прототипів і т.д.) і необхідні ресурси. Він створюється на початку фази дослідження й обновляється в міру необхідності.
· План ітерацій створюється для кожної ітерації й призначається для визначення й розподілу завдань між учасниками проекту.
Ризиком будемо називати все те, що може стояти на шляху до успіху проекту й на даний момент є невідомим або невизначеним. Головна ідея керування ризиками в тому, що не потрібно пасивно чекати, поки ризик стане проблемою, але потрібно завчасно визначати лінію поведінки. Керування ризиками означає визначення й оцінку ризиків, прийняття лінії поведінки, спрямованої на усунення, зниження ймовірності ризику, а також вибір дій на випадок реалізації ризику.
Для контролю й керування проектом використовуються виміри. Вони проводяться для того щоб установити, наскільки є віддаленим поточний стан проекту від поставленої мети, спланувати роботи й визначити, як можна підвищити ефективність процесу.
Керування проектом. Діяльності
Відкриття нового проекту. Ця діяльність виконується тільки в першій ітерації. Здійснюється ініціалізація проекту, визначаються й оцінюються ризики, розробляється бізнес-план. Ціль – переведення проекту в стадію, коли можливе ухвалення рішення про продовження або про відмову від проекту.
Оцінка області дії проекту й ризиків. Метою є перегляд і уточнення можливостей і характеристик проекту, а також пов'язаних з ним ризиків.
Створення плану розробки ПС. Створюється план розробки ПС, що включає перелік ризиків, плани вимірів, керування ризиками, розв’язок проблем, прийняття продукту. Визначається структура й ресурси проекту. Розробляється план фаз проекту.
Планування ітерації. Розробляється план чергової ітерації, уточнюється й коректується бізнес-план і план розробки ПС. План ітерації докладно описує, що повинне відбутися за час ітерації. Він визначає виконавців і виконувані ними роботи. При створенні плану ітерації необхідно:
· Сформулювати об'єктивні критерії успіху ітерації. Вони будуть використовуватися при її оцінці;
· Визначити конкретні, вимірні артефакти, які потрібно розробити або змінити, а також виконувані для цього роботи;
· Використовувати типову ітераційну декомпозицію робіт для реальних дій, які повинні бути зроблені;
· Використовувати кошторис при визначенні тривалості й обсягу робіт для кожного виду діяльності, утримуючи всі значення в межах бюджету.
Спостереження й контроль. Ця діяльність включає розподіл робіт і створення графіка робіт, спостереження за станом проекту, обробку виняткових ситуацій, і створення звіту про стан. Виконується обробка запропонованих змін і включення їх у графік робіт поточної або наступних ітерацій, проводиться спостереження за активними ризиками, дається оцінка прогресу і якості проекту. В RUP постійно виконувані оцінки стану проекту є основою для вирішення різних проблем і керування ризиками проекту. Якщо команда розроблювачів виявила проблему, призначається співробітник, відповідальний за її рішення, і визначається дата, коли проблема повинна бути розв’язана. Хід процесу повинен регулярно контролюватися, а оновлення повинні виконуватися в міру необхідності.
Керування ітерацією. Метою цієї діяльності є одержання достатніх для виконання ітерації ресурсів, поділ необхідних робіт, оцінка результатів ітерації.
Завершення фази. Виконуються роботи, що завершують виконання фази. Даються відповіді на наступні основні питання:
· чи Вирішені всі основні проблеми попередньої ітерації?
· чи Відомий стан усіх основних артефактів (див. нижче керування конфігурацією)?
· чи Розглянуті всі проблеми розгортання?
При задовільному стані проекту видається дозвіл на перехід до наступної фази.
Завершення проекту. Керівник проекту підготовляє проект до завершення. Готується заключна оцінка стану. При успішній здачі проекту замовник одержує програмний продукт у користування. Ресурси, що вивільняють, можуть бути перерозподілені (використані в інших проектах).