Rational Unified Process (rup) 2005 rup – процес розробки пз


НазваRational Unified Process (rup) 2005 rup – процес розробки пз
Дата конвертації24.03.2013
Розмір445 b.
ТипПрезентации


Rational Unified Process (RUP)

  • 2005


RUP – процес розробки ПЗ

  • Процес – частково впорядкований набір кроків, виконання яких дозволяє досягти мети.

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

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



Основні особливості (базові концепції) Rational Unified Process (RUP)

  • Кожен промінь наведеної семикутної зірки представляє базову концепцію RUP.



RUP як продукт Rational Software

  • RUP як продукт Rational Software – це:

    • інтерактивна (онлайнова) версія електронної бази знань – електронне керівництво користувача; для зручності у користуванні підтримуються:
      • зв'язки між поняттями у вигляді гіперпосилань (зокрема, графічних);
      • браузер основних понять – у вигляді ієрархічного дерева (treebrowser).
    • комплект документів – вступний курс RUP.
  • Розповсюджується через інтернет та на CD у HTML форматі.



RUP як програмний продукт

  • Процес розробки програмного забезпечення RUP – це також програмне забезпечення.

  • Електронному керівництву користувача RUP притаманні риси програмних продуктів:

    • використання версій;
    • доступ з “клавіатури” (у будь-якому веб-браузері);
    • інтегрованість з інструментальними засобами розробки ПЗ від IBM Rational Software;
    • розвинена навігація, зокрема на основі гіперпосилань, дерева навігації (treebrowser) та кнопок навігації;
    • нарешті, містить реальні програмні компоненти – Java-аплети, зокрема, браузер процесу, пошуковий механізм; можна, наприклад завантажувати останні версії шаблонів документів.


RUP. Електронне керівництво



RUP. Електронне керівництво



Tree browser

  • Two types of trees:

    • Default RUP trees, which are provided when you install RUP or publish RUP from RUP Builder, give different views of the topics in the RUP Extended Help. Default trees cannot be modified.
    • Customizable Personal Process View or My RUP trees are created by you and can be modified to display topics that suit your specific process and environment.


RUP. Електронне керівництво



RUP. Електронне керівництво



RUP. Електронне керівництво



RUP як контур процесу розробки ПЗ. Конфігурації RUP

  • RUP можна використовувати у готовому вигляді (RUP – процес), але також можна його конфігурувати (RUPконтур процесу).

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

  • Починаючи з версії RUP 2000 електронне керівництво містить різні варіанти процесу. Представлено як загальний, стандартний процес, так і спеціалізовані типові варіанти (з додатковими спеціалізованими керівництвами), наприклад, для електронної комерції.

  • Застосовують: Intel, Xerox, Oracle, Visa, Alcatel, British Aerospace, Ericsson, Volvo тощо.

  • Варіанти застосування:

    • розроблення власних процесів на основі RUP;
    • RUP – джерело порад, керівництв, шаблонів документів.


RUP та електронна комерція



Два виміри процесу: статичний та динамічний

  • Перший вимір представляє статичний аспект процесу: він описується в термінах потоків робіт чи технологічних процесів (виконавці, дії тощо).

  • Другий вимір представляє динамічний аспект процесу і описується часовими термінами: цикли, ітерації, фази (стадії).

  • У RUP визначаються чотири послідовних стадії (фази) ПС:

  • Задум (початок)

  • Уточнення (аналіз, дослідження)

  • Конструювання (побудова)

  • Упровадження



Два виміри процесу: статичний та динамічний



Два виміри процесу: статичний та динамічний



Динамічний аспект RUP. Віхи та версії.

  • RUP забезпечує не тільки керованість ітеративного процесу, але й можливість планування – плануються кількість та тривалість ітерацій.

  • Але як гарантувати цілеспрямованість та, зокрема, завершуваність процесу створення ПС? Як визначати, що саме має реалізовуватись у кожній з ітерацій?

  • Важливими при цьому є наступні обставини:

  • 1. Використання поняття віхи як ключового поняття ітеративної стратегії RUP. Віхи розглядаються як часові точки (точки у часі), в яких мають досягатись деякі критичні вирішення.

  • 2. Окремі ітерації визначаються короткотерміновими цілями – версіями. Прогрес (інкремент) окремої версії може вимірюватись, наприклад, виходячи з кількості реалізованих прецедентів, чи з кількості вирішених вимог, чи з кількості розв'язаних ризиків.



Динамічний аспект RUP. Чотири стадії (фази), чотири віхи RUP

  • Перша фаза – фаза задуму (або початку) – завершується віхою “Вимоги життєвого циклу”. (Віха LCOlifecycle objective).

  • Друга фаза – фаза уточнення завершується віхою “Архітектура життєвого циклу”. (Віха LCAlifecycle architecture).

  • Третя фаза – фаза конструювання (або реалізації) завершується віхою “Початкова працездатність”. (Віха IOC – initial operational capabiliny).

  • Четверта фаза – фаза переходу (або передачі, розгортання) завершується віхою “Випуск продукту”. (Віха PR – product release).



Характеристики окремої фази (стадії) RUP

    • Мета фази (стадії).
    • Критерії оцінювання (критерії проходження віхи стадії) та можливі дії при не проходженні віхи.
    • Основні задачі фази (стадії).
    • Результуючі артефакти (обов'язкові та не обов'язкові).


Перша фаза (фаза задуму або початку). (Віха фази –“Вимоги життєвого циклу”).

  • Мета – встановити ділові застосування ПС (критерії успіху, оцінки ризиків, оцінки необхідних ресурсів, укрупнений план) та визначити рамки проекту.

  • Критерії оцінювання (проходження віхи):

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

  • Основні задачі:

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


Перша фаза (фаза задуму або початку). Артефакти.

  • Загалом повинні бути вироблені наступні артефакти:

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

    • первісна модель прецедентів (розроблена на 10-20%);
    • модель предметної області (як розширення словника);
    • модель виробництва (ділова модель) – при необхідності;
    • один чи навіть кілька прототипів ПС.


Друга фаза (фаза уточнення). (Віха фази –“Архітектура життєвого циклу”).

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

  • Критерії оцінювання:

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

  • Ключове питання – чи варто переходити до конструювання – дорогої фази?



Друга фаза (фаза уточнення). (Віха фази –“Архітектура життєвого циклу”).

  • Основні задачі:

    • аналіз проблеми;
    • створення базових ліній: архітектури, бачення ПС, уточненого плану фази конструювання;
    • демонстрація можливості досягти бажаного бачення ПС;
    • оцінювання вартості та графіка робіт, оцінювання ризиків.
  • Базова лінія або опорна точка – затверджений (зокрема, прорецензований та узгоджений із зацікавленими сторонами) випуск артефактів, які надалі виступають незмінними, тобто є базисом наступних еволюцій.

  • На виході необхідно отримати артефакти:

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



Третя фаза (фаза конструювання). (Віха фази – “Початкова працездатність”).

  • Мета – створення працездатного продукту, готового для передачі кінцевим користувачам.

  • Критерії оцінювання:

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

  • При не проходженні віхи фазу розгортання, як правило, відкладають до наступної версії.



Третя фаза (фаза конструювання). Основні задачі та артефакти.

  • Основні задачі в рамках основної мети:

    • мінімізація вартості розробки шляхом оптимізації ресурсів аналіз проблеми;
    • найшвидше досягти прийнятного рівня якості;
    • найшвидше створення корисних версій (альфа-, бета-, інших тестових версій).
  • Необхідно отримати артефакти:

    • програмний продукт (для відповідної платформи);
    • керівництво користувача;
    • опис поточної версії.


Четверта фаза (фаза переходу). (Віха фази – “Випуск продукту”).

  • Мета – передача ПС спільноті користувачів.

  • Критерії оцінювання:

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

  • Основні задачі:

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


Четверта фаза (фаза переходу)

  • Фаза починається з випуску бета-версії.

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

  • Отже, можуть зазнати змін деякі артефакти, найчастіше такі:

    • програмний продукт (для відповідної платформи);
    • керівництво користувача;
    • опис поточної версії.


Статичний аспект RUP. Основні елементи



Скелет статичної структури RUP: виконавці, дії, артефакти

  • Процес – частково впорядкований набір кроків, виконання яких дозволяє досягти мети.

  • RUP деталізує “хто виконує, коли і як (яким чином), що буде отримано”, використовуючи терміни:

    • виконавець (роль): хто;
    • артефакт: що;
    • дія (діяльність): як;
    • технологічний процес (потік робіт, дисципліна): коли.
  • Виконавці, дії та артефакти складають скелет статичної структури RUP.



Основна тріада: роль, дія, артефакт



Виконавці

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

  • Виконавець не є фізичною особою:



Поведінка та зобов'язання виконавця. Артефакти та дії.

  • Артефакти – штучні продукти проекту, які виробляються та, можливо, використовуються в процесі розробки ПС.

  • Артефакт може містити інші артефакти, наприклад, модель складається з діаграм, діаграма класів містить окремі класи.

  • Дія (діяльність) – найменша частина роботи з деяким результатом, який є суттєвим у контексті проекту – впливає на один чи кілька артефактів.



Статичний аспект RUP. Технологічні процеси

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

  • У RUP використано 9 окремих технологічних процесів.



Технологічні процеси (дисципліни)



Опис технологічного процесу. Приклад (процес “Вимоги”).



RUP. Основні елементи (фрагмент)



Діаграма короткого огляду дій технологічного процесу. Приклад.

  • Діаграма представляє всі дії (та зв'язки між ними) відповідного технологічного процесу, у даному випадку “Ділового моделювання”.



Діаграма деталей технологічного процесу “Ділове моделювання”



Групи виконавців та головні задачі

  • Аналітики – виявлення та дослідження вимог (системний аналітик, аналітик ділової сфери, аналітик тестів тощо).

  • Розробники – проектування та реалізація програмного коду.

  • Менеджери – вироблення структури (конфігурації) процесу розробки ПС та управління ним.

  • Тестувальники – тестування.

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



Головні артефакти RUP



Як подається інформація про артефакти. Приклад (артефакт “Use-Case Model”)



Guidelines: Include-Relationship



Прагматика RUP

  • Електронне керівництво містить:

  • зв'язки з інструментальними наставниками (Tool Mentors) – допоміжними керівництвами інструментальними засобами від Rational Software, які підтримують технологічні процеси RUP (Rose, ClearCase тощо). При цьому інструментальні наставники інкапсулюють залежності RUP від інструментальних подробиць;



Підтримка потоків робіт CASE-засобами IBM Rational Software



Інструментальні наставники (Tool Mentors)



Інструментальні наставники (Tool Mentors)



RUP та інструментальні наставники (Tool Mentors)



RUP та інструментальні наставники (Tool Mentors)



Шаблони основних артефактів



Шаблони основних артефактів



Артефакти та шаблони. Приклад



Template: Use-Case Specification (Informal)



Template: Iteration Plan (Informal)



Template (Excel): Risk List



Template: Vision (Informal)



Template: Vision (Informal)



Template: Vision (Informal)



Template: Vision (Informal)



Засоби детального керівництва

  • Для полегшення розуміння й використання RUP як процесу, в електронній базі використовуються засоби детального керівництва, до яких можна віднести:

    • шаблони основних артефактів процесу та звітів;
    • інструментальні наставники;
    • списки основних понять;
    • директиви.
  • Директиви – правила, рекомендації, поради, які підтримують дії та їх складові частини (етапи). Вони описують особливу техніку створення артефактів, використовуються для визначення якості артефактів, рецензування дій тощо.

  • Прикладами директив є:

    • директиви артефактів (як артефакти розробляти, оцінювати, використовувати):
    • директиви моделювання прецедентів, класів;
    • директиви інтерфейсу користувача (наприклад, з уточненнями стилю, палітри вікон тощо);
    • директиви планування ітерацій, створення переліку ризиків тощо.
  • Важливе місце серед засобів керівництва займають перевірочні списки (Checklist) з контрольними (перевірочними) точками (Checkpoints).



Засоби детального керівництва



Як подається інформація про дії. Приклад (дія “Find Actors and Use Cases”)





Крок “Find Actors”



Tool Mentor: Finding Actors and Use Cases Using Rational Rose



Tool Mentor: Creating a Use-Case Model Survey Using Rational SoDA (Software Documentation Automation)



Артефакти, шаблони, перевірочні списки. Приклад



Перевірочні списки. Приклад



Схожі:

Rational Unified Process (rup) 2005 rup – процес розробки пз iconТехнологічний процес (потік робіт) “Ділове моделювання” 2005 Ділове моделювання та його цілі у rup
Перш ніж братись за реалізацію пс, треба зрозуміти ділову сферу. Реальним кроком для цього є
Rational Unified Process (rup) 2005 rup – процес розробки пз iconПереклад як процес І продукт translation as a process & a product

Rational Unified Process (rup) 2005 rup – процес розробки пз iconПроцес розробки Порядку визначення питомої ваги…
Процес розробки Порядку визначення питомої ваги сировини, матеріалів, основних фондів, робіт та послуг українського походження у...
Rational Unified Process (rup) 2005 rup – процес розробки пз icon2005 рік – початок розробки переліку регіональних показників (біля 70 показників) 2005 рік – початок розробки переліку регіональних показників (біля 70 показників)
Кількість спеціалістів державного департаменту з питань виконання покарань, які пройшли навчання для роботи з уразливими групами
Rational Unified Process (rup) 2005 rup – процес розробки пз iconУкраїнський центр оцінювання якості освіти та його регіональні підрозділи
Болонський процес (БП) це процес європейських реформ, що спрямований на створення спільної Зони європейської вищої освіти до 2010...
Rational Unified Process (rup) 2005 rup – процес розробки пз iconFactoring – the process of undoing multiplication Factoring – the process of undoing multiplication

Rational Unified Process (rup) 2005 rup – процес розробки пз iconОб’єкт дослідження – процес газоутворення на полігонах тпв об’єкт дослідження – процес газоутворення на полігонах тпв
Тпв та систематизація відомостей стосовно розробки методичної основи трьох(багато) компонентної національної моделі розрахунку викидів...
Rational Unified Process (rup) 2005 rup – процес розробки пз iconДіаграми прецедентів uml 2005 Діаграми прецедентів (use case diagrams)
Зокрема, прецеденти допомагають перевіряти й контролювати архітектуру пс у процесі її розробки
Rational Unified Process (rup) 2005 rup – процес розробки пз iconКодогенерація у C++ та реінженіринг з використанням ibm rational Rose

Rational Unified Process (rup) 2005 rup – процес розробки пз iconМета Мета
Цей бізнес-процес охоплює всі етапи, необхідні для налагодження та обробки проекту для розробки нового продукту

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка