Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
Rational Unified Process (RUP) є ітеративним процесом розробки програмного забезпечення створеним — підрозділом IBM з 2003. RUP не є єдиним, конкретним розпорядчим процесом, а скоріше фреймворком процесу, що має бути адаптованим організаціями які займаються розробкою та командами розробників які оберуть елементи процесу, які підходять під їх потреби.
Історія
Rational Unified Process (RUP) являє собою продукт, спочатку розроблений Rational Software, яка була придбана компанією IBM в лютому 2003 року. Продукт містить у собі базу знань з гіперпосиланнями, та прикладами і докладні описи для різних видів діяльності. RUP входить в продукт (RMC), який дозволяє налаштування процесу.
До 1997 року, Rational придбав Verdix, Objectory, Requisite, SQA, Performance Awareness, та Pure-Atria. Поєднання баз досвіду цих компаній привело до вироблення семи «найкращих практик» сучасної програмної інженерії:
- Розробляти ітеративно, керуючись ризиками.
- Управляти вимогами
- Використовувати компонентну архітектуру
- Моделювати програмне забезпечення візуально
- Постійно перевіряти якість
- Контролювати зміни
- Підлаштовуватись
Ці найкращі практики рухали розробку продуктів Rational, та використовувались польовими командами Rational, щоб допомогти клієнтам вдосконалити якість, та передбачуваність їх розробницьких зусиль. Щоб зробити ці знання доступнішими, Філіпу Крачтену, було поставлено завдання збирати явні фреймворки сучасної розробки програмного забезпечення. Ці зусилля використовував заснований на HTML механізм доставки процесів розроблений Objectory. У результаті «Раціональний уніфікований процес» (RUP) завершив стратегічну опору для Rational:
- Адаптовний процес що направляє розробку
- Інструменти, що автоматизують використання цього процесу
- Сервіси, що прискорюють впровадження і процесу, і інструментів.
Теми Раціонального Уніфікованого Процесу
Будівельні блоки RUP
RUP заснований на наборі будівельних блоків, чи містить елементи, що описують те, що повинно бути зробленим, необхідні навички, та покрокове пояснення того, як досягаються конкретні цілі розробки. Основними будівельними блоками, чи елементами вмісту, є наступні:
- Ролі (хто). Роль визначає набір навичок, компетенції та відповідальності.
- Робочі продукти (що). Робочий продукт являє собою щось отримане з завдання, в тому числі всі документи і моделі, випущені під час роботи впродовж процесу.
- Завдання (як). Завдання описує одиницю роботи, яка доручена ролі, яка забезпечує значущий результат.
У кожній ітерації, завдання діляться на дев'ять дисциплін: шість «інженерних дисциплін» (бізнес-моделювання, вимоги, аналіз і проєктування, реалізація, тестування, розгортання) і трьох допоміжних дисциплін (конфігурація і керування змінами, управління проєктами, середовища).
Чотири фази життєвого циклу проєкту
RUP визначає життєвий цикл проєкту, що складається з чотирьох фаз. Ці фази дозволяють процесу, бути представленим на високому рівні, подібно до того як представляються проєкти у «водоспадному» стилі, хоча, по суті, ключем до процесу є ітерації розробки, які простягаються вздовж всіх фаз. Крім того, кожен етап має одну ключову ціль, та віху в кінці, яка позначає досягнення цілі.
Початкова фаза
Первинною ціллю є адекватна оцінка системи, як база для обчислення початкових розцінок та бюджету. На цьому етапі встановлюються бізнес випадки, які включають бізнес-контекст, фактори успіху (очікувані доходи, визнання на ринку, і т.д.), а також фінансовий прогноз. На додаток до бізнес випадку генерується базова модель прецедентів, план проєкту, попередня оцінка ризику і опис проєкту (основні вимоги до проєкту, обмеження та основні характеристики). Після їх завершення проєкт перевіряється на відповідність наступним критеріям:
- Зацікавлені сторони досягають згоди з визначення масштабів і оцінки вартості/термінів.
- Розуміння вимог як свідчення якості первинних прецедентів.
- Достовірність оцінок вартості/термінів, пріоритетів, ризиків, та процесу розробки.
- Глибина і ширина будь-якого архітектурного прототипу, який був розроблений.
- Встановлення базової лінії за допомогою якої можна порівняти фактичні витрати із запланованими витратами.
Якщо проєкт не пройде цей етап, що називається віхою життєвого циклу, він може бути як скасований так і повторений після переконструювання з метою кращого задоволення критеріїв.
Фаза уточнення
Основна мета полягає в пом'якшенні ключових ризиків, виявлених на основі аналізу до кінця цієї фази. Фаза уточнення — фаза де проєкт починає набувати форми. На цьому етапі робиться аналіз предметної області, і архітектура проєкту отримує свою базову форму.
Ця фаза має пройти віху життєвого циклу архітектури (LCA), задовольняючи такі критерії:
- Модель прецедентів, в якій ідентифікуються прецеденти та актори, та розробляється більшість описів прецедентів. Модель прецедентів повинна бути завершена на 80%.
- Опис архітектури програмного забезпечення в процесі розробки програмної системи.
- Виконувана архітектура, яка реалізує архітектурно значимі прецеденти.
- Бізнес — випадки та список ризиків переглядаються.
- План розвитку проєкту в цілому.
- Прототипи, що явно зменшили кожен виявлений технічний ризик.
Якщо проєкт не може переступити цю віху, ще є час для того, щоб він був скасований або змінений. Тим не менше, після закінчення цього етапу, проєкт переходить в операцію з високим ступенем ризику, де зміни набагато складніші та згубні, при здійсненні.
Системна архітектура є ключовим елементом розробки, що отримується з аналізу предметної області.
Фаза конструювання
Основна мета полягає в створенні програмної системи. На цьому етапі основна увага приділяється розробці компонентів та інших характеристик системи. Це етап, коли відбувається основна частина кодування. У більших проєктах може бути кілька фаз конструювання, в спробі поділити прецеденти на керовані сегменти, які можуть утворити презентабельні прототипи.
Цей етап створює перший реліз програмного забезпечення. Його завершення позначає віха початкової боєготовності.
Фаза впровадження
Основна мета полягає в переведенні системи з розробки у продукт, зробивши її доступною та зрозумілою для кінцевого споживача. Діяльність у рамках цієї фази включає навчання кінцевих користувачів та обслуговчого персоналу, бета-тестування системи для перевірки її на відповідність очікуванням користувачів. Продукт також перевіряється на відповідність рівню якості, встановленого в початковій фазі.
Якщо всі вимоги задоволені, досягається віха релізу продукту, і цикл розробки завершується.
Шість інженерних дисциплін
- Дисципліни бізнес-моделювання
- Бізнес-моделювання пояснює, як описати бачення організації, в якій буде розгортатись система і як використати це бачення для виділення процесу, ролей та обов'язків.
- Організації стають все залежнішими від ІТ систем, що вимагає від інженерів інформаційних систем знання того, як застосунок що вони розробляють вписується в організацію. Підприємства інвестують в ІТ, коли вони розуміють, конкурентні переваги і вартість що додає технологія. Метою є по-перше встановити глибше розуміння та комунікаційний канал між та програмною інженерією. Розуміння бізнесу означає, що програмісти повинні розуміти структуру і динаміку цільової організації (клієнта), нинішні проблеми в організації, а також можливі удосконалення. Вони повинні також забезпечити загальне розуміння цільової організації між клієнтами, кінцевими користувачами та розробниками.
- Дисципліни вимог
Вимоги пояснюють, як виявити запити зацікавлених осіб і перетворити їх в набір вимог, робочих продуктів, що осягають створювану систему й надають детальні вимоги до того, що система повинна робити.
- Дисципліна аналізу та проєктування
- Метою аналізу і проєктування, є показати, яким чином система буде реалізована. Ціллю є створення системи, яка:
- Виконує — в особливому середовищі реалізації — задачі та функції описані в описах прецедентів.
- Виконує всі свої вимоги.
- Легко змінити, коли змінюються функціональні вимоги.
- Проєктування дає в результаті модель проєктування, а аналіз відповідно модель аналізу. Модель дизайну служить абстракцією вихідного коду; тобто модель дизайну працює «синькою», розміткою того як буде структурований та написаний вихідний код. Дизайн моделі складається проєктування класів структурованих в пакети і підсистеми з чітко визначеними інтерфейсами, які представляють, що стане компонентами у реалізації. Він також містить опис того, як об'єкти цих сконструйованих класів співпрацюють для виконання прецедентів.
- Дисципліна реалізації
- Метою реалізації є:
- Визначити організацію коду з точки зору реалізації підсистем, які організовані в шари.
- Реалізація класів та об'єктів у термінах компонентів (вихідних файлів, виконуваних файлів, та інших).
- * Для тестування розроблених компонент та модулів.
- * Для інтеграції результатів, отриманих окремими виконавцями (чи групами) у виконувану систему.
- Системи реалізуються через реалізацію компонентів. Процес описує як повторно використати існуючі компоненти, чи реалізувати нові компонетни з чітко визначеними відповідальностями, роблячи систему легше підтримуваною і збільшуючи можливості для повторного використання.
- Дисципліна тестування
- Цілі тестування:
- * Перевірити взаємодії між об'єктами.
- * Перевірити належну інтеграцію всіх компонентів програмного забезпечення.
- * Щоб переконатися, що всі вимоги були правильно виконані.
- * Щоб визначити та переконатись що дефекти будуть розглянуті до розгортання програмного забезпечення.
- * Переконатись, що всі дефекти виправлені, повторно перевірені та закриті.
- Раціональний уніфікований процес пропонує ітеративний підхід, а це означає, що тестування відбувається протягом всього проєкту. Це дозволяє виявляти дефекти якомога раніше, що радикально знижує вартість виправлення дефекту. Тести проводяться за чотирма вимірами якості:надійності, функціональності, продуктивності додатків і продуктивності системи. Для кожного з цих вимірів критеріїв якості, процес описує як пройти життєвий цикл планування, проєктування, виконання і оцінки тесту.
- Дисципліна розгортання
- Метою розгортання є успішно робити релізи продукту, та постачати програмне забезпечення для кінцевих користувачів. Вона охоплює широке коло заходів, у тому числі виробництво зовнішніх версій програмного забезпечення, запаковування програмного забезпечення та бізнес-додатків, розповсюдження програмного забезпечення, встановлення програмного забезпечення та надання допомоги і підтримки для користувачів. Хоча діяльність по впровадженню в основному зосереджена на перехідному етапі, багато які з цих заходів повинні бути включені в більш ранні етапи, щоб підготуватись до розгортання в кінці фази конструювання. Процеси Розгортування та середовищаіз RUP містять менше деталей, ніж інші робочі процеси.
Три допоміжні дисципліни
- Дисципліна середовища
- Дисципліна середовища зосереджується на діяльності необхідній для налаштування процесу під проєкт. Вона описує
Цей розділ потребує доповнення. (квітень 2010) - Дисципліна конфігурації та управління змінами
Цей розділ потребує доповнення. (квітень 2010) - Дисципліна управління проєктами.
- Дисципліна управління проєктами та планування проєктів в RUP відбувається на двох рівнях
Цей розділ потребує доповнення. (квітень 2010)
Шість найкращих практик
Шість найкращих практик як описані в RUP є парадигмою програмної інженерії, яка перечислює шість ідей яким варто слідувати при конструюванні будь-якого проєкту щоб мінімізувати провали, та збільшити продуктивність. Цими практиками є:
- Ітеративна розробка
- Найкраще було б знати всі вимоги наперед; тим не менш, часто це не той випадок. Існує кілька процесів розробки програмного забезпечення, які мають справу з рішеннями які дозволяють зменшувати вартість в термінах фаз розробки.
- Управління вимогами
- Завжди пам'ятати вимоги встановлені користувачами.
- Використання компонент
- Розбиття складного проєкту не тільки пропонується, а є фактично неминучим. Це дає можливість тестувати окремі компоненти до того, як вони будуть інтегровані в більшу систему. Також, повторне використання коду є великим плюсом та може бути здійснене легше через використання ООП.
- Візуальне моделювання
- Використовуйте діаграми щоб представити всі основні компоненти, користувачів, та їх взаємодії. «UML», скорочено від Unified Modeling Language, є інструментом що може зробити це завдання більш здійсненним.
- Перевірка якості
- Завжди робіть тестування більшої частини проєкту в будь-який момент часу. Тестування стає важчим з розростанням проєкту, та воно має бути постійним фактором в будь-якому створенні програмного продукту.
- Контроль змін
- Багато проєктів створюються багатьма командами, іноді з різним місцезнаходженням, використовуючи різні платформи, і т.п. Як результат є важливим переконатись, що зміни які вносяться в систему синхронізуються та перевіряються постійно. (Див. Неперервна інтеграція).
Конкуруючі фреймворки та технології
Згадані нижче методики та / чи фреймворки не обов'язково конкурують з RUP на всіх фронтах, але роблять це різною мірою
- Cleanroom Software Engineering
- Dynamic Systems Development Method (DSDM)
- легка, гнучка підмножина практик RUP
- Extreme Programming — корисний для маленьких проєктів з малими ризиками
- (MSF)
- (OUM)
- легка OpenSource гнучка версія RUP що підтримується , Number Six Software та іншими
- (PSP) не є процесом розробки, а є процесом персонального менеджменту
- Scrum легка, гнучка підмножина практик RUP
Примітки
- Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.
- . Архів оригіналу за 1 травня 2009. Процитовано 22 квітня 2010.
| Цю статтю треба для відповідності Вікіпедії. (травень 2010) |
| Ця стаття потребує додаткових для поліпшення її . (березень 2017) |
 | Це незавершена стаття про програмування. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Rational Unified Process RUP ye iterativnim procesom rozrobki programnogo zabezpechennya stvorenim pidrozdilom IBM z 2003 RUP ne ye yedinim konkretnim rozporyadchim procesom a skorishe frejmvorkom procesu sho maye buti adaptovanim organizaciyami yaki zajmayutsya rozrobkoyu ta komandami rozrobnikiv yaki oberut elementi procesu yaki pidhodyat pid yih potrebi IstoriyaRational Unified Process RUP yavlyaye soboyu produkt spochatku rozroblenij Rational Software yaka bula pridbana kompaniyeyu IBM v lyutomu 2003 roku Produkt mistit u sobi bazu znan z giperposilannyami ta prikladami i dokladni opisi dlya riznih vidiv diyalnosti RUP vhodit v produkt RMC yakij dozvolyaye nalashtuvannya procesu Do 1997 roku Rational pridbav Verdix Objectory Requisite SQA Performance Awareness ta Pure Atria Poyednannya baz dosvidu cih kompanij privelo do viroblennya semi najkrashih praktik suchasnoyi programnoyi inzheneriyi Rozroblyati iterativno keruyuchis rizikami Upravlyati vimogami Vikoristovuvati komponentnu arhitekturu Modelyuvati programne zabezpechennya vizualno Postijno pereviryati yakist Kontrolyuvati zmini Pidlashtovuvatis Ci najkrashi praktiki ruhali rozrobku produktiv Rational ta vikoristovuvalis polovimi komandami Rational shob dopomogti kliyentam vdoskonaliti yakist ta peredbachuvanist yih rozrobnickih zusil Shob zrobiti ci znannya dostupnishimi Filipu Krachtenu bulo postavleno zavdannya zbirati yavni frejmvorki suchasnoyi rozrobki programnogo zabezpechennya Ci zusillya vikoristovuvav zasnovanij na HTML mehanizm dostavki procesiv rozroblenij Objectory U rezultati Racionalnij unifikovanij proces RUP zavershiv strategichnu oporu dlya Rational Adaptovnij proces sho napravlyaye rozrobku Instrumenti sho avtomatizuyut vikoristannya cogo procesu Servisi sho priskoryuyut vprovadzhennya i procesu i instrumentiv Temi Racionalnogo Unifikovanogo ProcesuBudivelni bloki RUP RUP zasnovanij na nabori budivelnih blokiv chi mistit elementi sho opisuyut te sho povinno buti zroblenim neobhidni navichki ta pokrokove poyasnennya togo yak dosyagayutsya konkretni cili rozrobki Osnovnimi budivelnimi blokami chi elementami vmistu ye nastupni Roli hto Rol viznachaye nabir navichok kompetenciyi ta vidpovidalnosti Robochi produkti sho Robochij produkt yavlyaye soboyu shos otrimane z zavdannya v tomu chisli vsi dokumenti i modeli vipusheni pid chas roboti vprodovzh procesu Zavdannya yak Zavdannya opisuye odinicyu roboti yaka doruchena roli yaka zabezpechuye znachushij rezultat U kozhnij iteraciyi zavdannya dilyatsya na dev yat disciplin shist inzhenernih disciplin biznes modelyuvannya vimogi analiz i proyektuvannya realizaciya testuvannya rozgortannya i troh dopomizhnih disciplin konfiguraciya i keruvannya zminami upravlinnya proyektami seredovisha Chotiri fazi zhittyevogo ciklu proyektu Fazi ta disciplini RUP RUP viznachaye zhittyevij cikl proyektu sho skladayetsya z chotiroh faz Ci fazi dozvolyayut procesu buti predstavlenim na visokomu rivni podibno do togo yak predstavlyayutsya proyekti u vodospadnomu stili hocha po suti klyuchem do procesu ye iteraciyi rozrobki yaki prostyagayutsya vzdovzh vsih faz Krim togo kozhen etap maye odnu klyuchovu cil ta vihu v kinci yaka poznachaye dosyagnennya cili Pochatkova faza Pervinnoyu cillyu ye adekvatna ocinka sistemi yak baza dlya obchislennya pochatkovih rozcinok ta byudzhetu Na comu etapi vstanovlyuyutsya biznes vipadki yaki vklyuchayut biznes kontekst faktori uspihu ochikuvani dohodi viznannya na rinku i t d a takozh finansovij prognoz Na dodatok do biznes vipadku generuyetsya bazova model precedentiv plan proyektu poperednya ocinka riziku i opis proyektu osnovni vimogi do proyektu obmezhennya ta osnovni harakteristiki Pislya yih zavershennya proyekt pereviryayetsya na vidpovidnist nastupnim kriteriyam Zacikavleni storoni dosyagayut zgodi z viznachennya masshtabiv i ocinki vartosti terminiv Rozuminnya vimog yak svidchennya yakosti pervinnih precedentiv Dostovirnist ocinok vartosti terminiv prioritetiv rizikiv ta procesu rozrobki Glibina i shirina bud yakogo arhitekturnogo prototipu yakij buv rozroblenij Vstanovlennya bazovoyi liniyi za dopomogoyu yakoyi mozhna porivnyati faktichni vitrati iz zaplanovanimi vitratami Yaksho proyekt ne projde cej etap sho nazivayetsya vihoyu zhittyevogo ciklu vin mozhe buti yak skasovanij tak i povtorenij pislya perekonstruyuvannya z metoyu krashogo zadovolennya kriteriyiv Faza utochnennya Osnovna meta polyagaye v pom yakshenni klyuchovih rizikiv viyavlenih na osnovi analizu do kincya ciyeyi fazi Faza utochnennya faza de proyekt pochinaye nabuvati formi Na comu etapi robitsya analiz predmetnoyi oblasti i arhitektura proyektu otrimuye svoyu bazovu formu Cya faza maye projti vihu zhittyevogo ciklu arhitekturi LCA zadovolnyayuchi taki kriteriyi Model precedentiv v yakij identifikuyutsya precedenti ta aktori ta rozroblyayetsya bilshist opisiv precedentiv Model precedentiv povinna buti zavershena na 80 Opis arhitekturi programnogo zabezpechennya v procesi rozrobki programnoyi sistemi Vikonuvana arhitektura yaka realizuye arhitekturno znachimi precedenti Biznes vipadki ta spisok rizikiv pereglyadayutsya Plan rozvitku proyektu v cilomu Prototipi sho yavno zmenshili kozhen viyavlenij tehnichnij rizik Yaksho proyekt ne mozhe perestupiti cyu vihu she ye chas dlya togo shob vin buv skasovanij abo zminenij Tim ne menshe pislya zakinchennya cogo etapu proyekt perehodit v operaciyu z visokim stupenem riziku de zmini nabagato skladnishi ta zgubni pri zdijsnenni Sistemna arhitektura ye klyuchovim elementom rozrobki sho otrimuyetsya z analizu predmetnoyi oblasti Faza konstruyuvannya Osnovna meta polyagaye v stvorenni programnoyi sistemi Na comu etapi osnovna uvaga pridilyayetsya rozrobci komponentiv ta inshih harakteristik sistemi Ce etap koli vidbuvayetsya osnovna chastina koduvannya U bilshih proyektah mozhe buti kilka faz konstruyuvannya v sprobi podiliti precedenti na kerovani segmenti yaki mozhut utvoriti prezentabelni prototipi Cej etap stvoryuye pershij reliz programnogo zabezpechennya Jogo zavershennya poznachaye viha pochatkovoyi boyegotovnosti Faza vprovadzhennya Osnovna meta polyagaye v perevedenni sistemi z rozrobki u produkt zrobivshi yiyi dostupnoyu ta zrozumiloyu dlya kincevogo spozhivacha Diyalnist u ramkah ciyeyi fazi vklyuchaye navchannya kincevih koristuvachiv ta obslugovchogo personalu beta testuvannya sistemi dlya perevirki yiyi na vidpovidnist ochikuvannyam koristuvachiv Produkt takozh pereviryayetsya na vidpovidnist rivnyu yakosti vstanovlenogo v pochatkovij fazi Yaksho vsi vimogi zadovoleni dosyagayetsya viha relizu produktu i cikl rozrobki zavershuyetsya Shist inzhenernih disciplin Disciplini biznes modelyuvannya Biznes modelyuvannya poyasnyuye yak opisati bachennya organizaciyi v yakij bude rozgortatis sistema i yak vikoristati ce bachennya dlya vidilennya procesu rolej ta obov yazkiv Organizaciyi stayut vse zalezhnishimi vid IT sistem sho vimagaye vid inzheneriv informacijnih sistem znannya togo yak zastosunok sho voni rozroblyayut vpisuyetsya v organizaciyu Pidpriyemstva investuyut v IT koli voni rozumiyut konkurentni perevagi i vartist sho dodaye tehnologiya Metoyu ye po pershe vstanoviti glibshe rozuminnya ta komunikacijnij kanal mizh ta programnoyu inzheneriyeyu Rozuminnya biznesu oznachaye sho programisti povinni rozumiti strukturu i dinamiku cilovoyi organizaciyi kliyenta ninishni problemi v organizaciyi a takozh mozhlivi udoskonalennya Voni povinni takozh zabezpechiti zagalne rozuminnya cilovoyi organizaciyi mizh kliyentami kincevimi koristuvachami ta rozrobnikami Disciplini vimog Vimogi poyasnyuyut yak viyaviti zapiti zacikavlenih osib i peretvoriti yih v nabir vimog robochih produktiv sho osyagayut stvoryuvanu sistemu j nadayut detalni vimogi do togo sho sistema povinna robiti Disciplina analizu ta proyektuvannya Metoyu analizu i proyektuvannya ye pokazati yakim chinom sistema bude realizovana Cillyu ye stvorennya sistemi yaka Vikonuye v osoblivomu seredovishi realizaciyi zadachi ta funkciyi opisani v opisah precedentiv Vikonuye vsi svoyi vimogi Legko zminiti koli zminyuyutsya funkcionalni vimogi Proyektuvannya daye v rezultati model proyektuvannya a analiz vidpovidno model analizu Model dizajnu sluzhit abstrakciyeyu vihidnogo kodu tobto model dizajnu pracyuye sinkoyu rozmitkoyu togo yak bude strukturovanij ta napisanij vihidnij kod Dizajn modeli skladayetsya proyektuvannya klasiv strukturovanih v paketi i pidsistemi z chitko viznachenimi interfejsami yaki predstavlyayut sho stane komponentami u realizaciyi Vin takozh mistit opis togo yak ob yekti cih skonstrujovanih klasiv spivpracyuyut dlya vikonannya precedentiv Disciplina realizaciyi Metoyu realizaciyi ye Viznachiti organizaciyu kodu z tochki zoru realizaciyi pidsistem yaki organizovani v shari Realizaciya klasiv ta ob yektiv u terminah komponentiv vihidnih fajliv vikonuvanih fajliv ta inshih Dlya testuvannya rozroblenih komponent ta moduliv Dlya integraciyi rezultativ otrimanih okremimi vikonavcyami chi grupami u vikonuvanu sistemu Sistemi realizuyutsya cherez realizaciyu komponentiv Proces opisuye yak povtorno vikoristati isnuyuchi komponenti chi realizuvati novi komponetni z chitko viznachenimi vidpovidalnostyami roblyachi sistemu legshe pidtrimuvanoyu i zbilshuyuchi mozhlivosti dlya povtornogo vikoristannya Disciplina testuvannya Cili testuvannya Pereviriti vzayemodiyi mizh ob yektami Pereviriti nalezhnu integraciyu vsih komponentiv programnogo zabezpechennya Shob perekonatisya sho vsi vimogi buli pravilno vikonani Shob viznachiti ta perekonatis sho defekti budut rozglyanuti do rozgortannya programnogo zabezpechennya Perekonatis sho vsi defekti vipravleni povtorno perevireni ta zakriti Racionalnij unifikovanij proces proponuye iterativnij pidhid a ce oznachaye sho testuvannya vidbuvayetsya protyagom vsogo proyektu Ce dozvolyaye viyavlyati defekti yakomoga ranishe sho radikalno znizhuye vartist vipravlennya defektu Testi provodyatsya za chotirma vimirami yakosti nadijnosti funkcionalnosti produktivnosti dodatkiv i produktivnosti sistemi Dlya kozhnogo z cih vimiriv kriteriyiv yakosti proces opisuye yak projti zhittyevij cikl planuvannya proyektuvannya vikonannya i ocinki testu Disciplina rozgortannya Metoyu rozgortannya ye uspishno robiti relizi produktu ta postachati programne zabezpechennya dlya kincevih koristuvachiv Vona ohoplyuye shiroke kolo zahodiv u tomu chisli virobnictvo zovnishnih versij programnogo zabezpechennya zapakovuvannya programnogo zabezpechennya ta biznes dodatkiv rozpovsyudzhennya programnogo zabezpechennya vstanovlennya programnogo zabezpechennya ta nadannya dopomogi i pidtrimki dlya koristuvachiv Hocha diyalnist po vprovadzhennyu v osnovnomu zoseredzhena na perehidnomu etapi bagato yaki z cih zahodiv povinni buti vklyucheni v bilsh ranni etapi shob pidgotuvatis do rozgortannya v kinci fazi konstruyuvannya Procesi Rozgortuvannya ta seredovishaiz RUP mistyat menshe detalej nizh inshi robochi procesi Tri dopomizhni disciplini Disciplina seredovisha Disciplina seredovisha zoseredzhuyetsya na diyalnosti neobhidnij dlya nalashtuvannya procesu pid proyekt Vona opisuye Cej rozdil potrebuye dopovnennya kviten 2010 Disciplina konfiguraciyi ta upravlinnya zminami Cej rozdil potrebuye dopovnennya kviten 2010 Disciplina upravlinnya proyektami Disciplina upravlinnya proyektami ta planuvannya proyektiv v RUP vidbuvayetsya na dvoh rivnyah Cej rozdil potrebuye dopovnennya kviten 2010 Shist najkrashih praktik Shist najkrashih praktik yak opisani v RUP ye paradigmoyu programnoyi inzheneriyi yaka perechislyuye shist idej yakim varto sliduvati pri konstruyuvanni bud yakogo proyektu shob minimizuvati provali ta zbilshiti produktivnist Cimi praktikami ye Iterativna rozrobka Najkrashe bulo b znati vsi vimogi napered tim ne mensh chasto ce ne toj vipadok Isnuye kilka procesiv rozrobki programnogo zabezpechennya yaki mayut spravu z rishennyami yaki dozvolyayut zmenshuvati vartist v terminah faz rozrobki Upravlinnya vimogami Zavzhdi pam yatati vimogi vstanovleni koristuvachami Vikoristannya komponent Rozbittya skladnogo proyektu ne tilki proponuyetsya a ye faktichno neminuchim Ce daye mozhlivist testuvati okremi komponenti do togo yak voni budut integrovani v bilshu sistemu Takozh povtorne vikoristannya kodu ye velikim plyusom ta mozhe buti zdijsnene legshe cherez vikoristannya OOP Vizualne modelyuvannya Vikoristovujte diagrami shob predstaviti vsi osnovni komponenti koristuvachiv ta yih vzayemodiyi UML skorocheno vid Unified Modeling Language ye instrumentom sho mozhe zrobiti ce zavdannya bilsh zdijsnennim Perevirka yakosti Zavzhdi robit testuvannya bilshoyi chastini proyektu v bud yakij moment chasu Testuvannya staye vazhchim z rozrostannyam proyektu ta vono maye buti postijnim faktorom v bud yakomu stvorenni programnogo produktu Kontrol zmin Bagato proyektiv stvoryuyutsya bagatma komandami inodi z riznim misceznahodzhennyam vikoristovuyuchi rizni platformi i t p Yak rezultat ye vazhlivim perekonatis sho zmini yaki vnosyatsya v sistemu sinhronizuyutsya ta pereviryayutsya postijno Div Neperervna integraciya Konkuruyuchi frejmvorki ta tehnologiyi Zgadani nizhche metodiki ta chi frejmvorki ne obov yazkovo konkuruyut z RUP na vsih frontah ale roblyat ce riznoyu miroyu Cleanroom Software Engineering Dynamic Systems Development Method DSDM legka gnuchka pidmnozhina praktik RUP Extreme Programming korisnij dlya malenkih proyektiv z malimi rizikami MSF OUM legka OpenSource gnuchka versiya RUP sho pidtrimuyetsya Number Six Software ta inshimi PSP ne ye procesom rozrobki a ye procesom personalnogo menedzhmentu Scrum legka gnuchka pidmnozhina praktik RUPPrimitkiStephen Schach 2004 Classical and Object Oriented Software Engineering 6 e WCB McGraw Hill New York 2004 Arhiv originalu za 1 travnya 2009 Procitovano 22 kvitnya 2010 Cyu stattyu treba vikifikuvati dlya vidpovidnosti standartam yakosti Vikipediyi Bud laska dopomozhit dodavannyam dorechnih vnutrishnih posilan abo vdoskonalennyam rozmitki statti traven 2010 Cya stattya potrebuye dodatkovih posilan na dzherela dlya polipshennya yiyi perevirnosti Bud laska dopomozhit udoskonaliti cyu stattyu dodavshi posilannya na nadijni avtoritetni dzherela Zvernitsya na storinku obgovorennya za poyasnennyami ta dopomozhit vipraviti nedoliki Material bez dzherel mozhe buti piddano sumnivu ta vilucheno berezen 2017 Ce nezavershena stattya pro programuvannya Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi