Головна

RUP як методологія

  1. DFD - методологія в проектуванні ІС
  2. SADT - методологія в проектуванні ІС
  3. Блок 1. Теорія і методологія проектування в дизайні
  4. В) Сучасна філософія методологія науки (Мінська, Московська школи)
  5. Питання 16. Методологія аналізу ризиків країни IHS Energe Group. Методологія аналізу політичних ризиків компанії BERI.
  6. Питання 16. Основні вимоги та методологія організації соціально-педагогічного дослідження. (Він же 32).

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

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

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

Rational Unified Process - процес створення і фізичного втілення візуальних моделей. RUP фокусує увагу не на створенні великої кількості паперових документів, а на розвиток і застосування візуальних моделей - семантично багатих уявлень розробляється ІС. RUP зосереджує увагу на розробці і подальшому розвитку надійної і гнучкої архітектури, яка полегшує паралельну розробку, мінімізує необхідність змін, збільшує можливість багаторазового використання і надійність експлуатації системи. Подібна архітектура застосовується для планування використання програмних компонентів і управління їх розвитком.

Rational Unified Process - процес управління діями за допомогою прецедентів, що визначають функціонал системи. Поняття прецедентів і сценаріїв роботи сприяють ефективному управлінню технологічним маршрутом від бізнес-моделювання та вимог аж до випробувань. Вони забезпечують пов'язані і доступні для аналізу напрямки розробки і розгортання системи.

Rational Unified Process підтримує об'єктно-орієнтовану технологію. Моделювання за методологією RUP є об'єктно-орієнтованим і базується на поняттях об'єктів, класів і залежностей між ними. Ці моделі, як і багато інших технічних штучно споруджених конструкцій (артефактів), в якості єдиного стандарту для організації взаємодії учасників проекту використовують Unified Modelling Language ™ (UML) - універсальна мова моделювання.

Rational Unified Process підтримує компонентно-орієнтований підхід. Компоненти - це нетривіальні модулі або підсистеми, які виконують конкретну функцію і можуть бути використані багаторазово. Як правило, компоненти відповідають одній з промислових специфікацій, таких як CORBA, COM / DCOM, ActiveX, Enterprise Java Beans і ін.

Rational Unified Process - адаптується і конфігурується процес. Досвід одиничного проекту, навіть успішно завершеного, навряд чи підійде для створення ПЗ у всіх випадках і умовах. Але здатність RUP до адаптації підійде як маленьким групам розробників, так і великим організаціям. RUP містить рекомендації по конфігурації процесу для задоволення потреб практично будь-яких компаній і їх підрозділів.

Rational Unified Process підтримує об'єктивно здійснюване управління якістю. Оцінка якості всіх робіт, що виконуються будь-якими учасниками проекту, використовує об'єктивні метрики і критерії. Методологія RUP створювалася з прицілом на підтримку управління якістю в рамках вимог SEI CMM / CMMI.


16. Поняття «архітектура підприємства» і «архітектура ІТ».

Поняття «архітектура підприємства» вперше з'явилося в 1987 р в статті Дж. А. Захмана «Структура архітектури інформаційних систем», опублікованій в журналі IBM Systems Journal. У цій статті автор виклав своє бачення архітектур підприємств і пов'язаних з ними проблем, що задало напрямок розвитку на наступні 20 років. Як проблеми було позначено управління складністю розподілених систем. Захмана каже:

«Для зниження витрат і забезпечення успіху бізнесу, все більше залежить від інформаційних систем, необхідний суворий підхід до управління такими системами».

Термін «підприємство» більшість фахівців з архітектури і відповідні методики опису архітектури трактують досить гнучко. Це може бути організація в цілому або одне з її бізнес-підрозділів, або ж це може бути деяка сукупність підприємств або організаційних одиниць в рамках єдиного ланцюжка створення доданої вартості. Таким чином, під терміном "Підприємство" будемо мати на увазі формальне об'єднання, не обов'язково пов'язане з комерційною діяльністю. Це може бути і державна організація, і суспільне, в тому числі неформальне, об'єднання учасників, пов'язаних спільною метою. Згідно з більш загальним визначенням, Підприємство "... являє собою комплексну систему культурних, технологічних і процесних компонент, організованих для досягнення цілей організації".

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

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

Архітектура підприємства частково зачіпає і процеси управління ІТ в організації. У цьому плані вона доповнює досить ефективні методики організації і реорганізації процесів всередині ІТ-служби, такі як ITIL, COBIT і інші.

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

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

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

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

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

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

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

У найзагальнішому вигляді, відповідно до визначень Gartner, архітектура - Це:

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

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

Інші визначення:

· "архітектура - Це інвестиція в стандарти процесів, технологій і інтерфейсів в цілях поліпшення можливостей організацій та зменшення вартості розробки і супроводу інформаційних систем. Переваги інвестицій в архітектуру поширюються на кілька проектів відразу, але не всі ці проекти можуть бути відомі в момент розробки архітектури ";

· "Корпоративна архітектура ІТ - Це бачення, принципи і стандарти, якими організації керуються при розробці та впровадженні технологій "(Giga Group);

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

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

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

Рівні прийняття архітектурних рішень

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


 



Види відносин між класами | Модель Захмана.

Профілі ІС. | Принципи формування профілю інформаційної системи | Структура профілів інформаційних систем | Структурний підхід до проектування. | Методологія SADT. | Склад функціональної моделі | Стандарт IDEF0. | Діаграми потоків даних DFD (Data Flow Diagrams) | Об'єктно-орієнтований підхід до проектування. | Види відносин між об'єктами |

© um.co.ua - учбові матеріали та реферати