Rational Unified Process (RUP) е една от най-добрите методологии за разработка на софтуер, създадена от Rational Software. Въз основа на опита от много успешни софтуерни проекти, Unified Process ви позволява да създавате сложни софтуерни системи, базирани на методи за индустриално развитие. Един от основните стълбове, на които RUP разчита, е процесът на създаване на модели с помощта на Unified Modeling Language (UML). Тази статия е за използването на UML диаграми в работния процес за разработка на софтуерни системи, използвайки методологията на Rational Software.
Не е тайна, че създаването на софтуер е сложен процес, който, от една страна, има много общо с творчеството, а от друга, въпреки че е високодоходен, той е и скъп бизнес. Жестоката конкуренция на пазара принуждава разработчиците да търсят по-ефективни методи на работа. Начини за създаване на софтуерни системи за още по-бързо време, на по-ниска цена и с по-добро качество. Сложността на програмите непрекъснато се увеличава. Доскоро софтуерните продукти можеха да бъдат създадени в обозримо време от отделни лица или например в ИТ отдела на автоматизирано предприятие.
В днешно време хората, които създават програми на колене, са оставени с областта на малките помощни програми и различни модули за разширение за „тежки“ софтуерни продукти. Бъдещето принадлежи на индустриалния подход към създаването на софтуер. През 1913 г. Хенри Форд пуска първата автомобилна поточна линия, а през 90-те години подобна поточна линия започва да се използва в областта на IT технологиите. Развитието на екипа изисква съвсем различен подход и различна методология, която рано или късно трябваше да бъде създадена.
Rational Software Corporation (http://www.rational.com) пусна структурирана база от знания, наречена Rational Unified Process (RUP), която е набор от изчерпателни препоръки за създаване на почти всеки софтуерен продукт. Попивайки опита от най-добрите разработки, RUP разказва подробно кога, кой и какво трябва да направи в проекта, за да се получи софтуерна система навреме, с определена функционалност и в рамките на определения бюджет.
Единният процес може да се разглежда като сбор от различните дейности на компанията за разработка, необходими за превеждане на изискванията на клиента в софтуерна система. Система, която ще осигури „смислени резултати“ на потребителите и ще направи точно това, което очакват от системата. Следователно процесът се контролира от случаите на използване на системата или по друг начин - прецеденти.
За да се изпълнят изискванията на клиента навреме, Унифицираният процес е разделен на фази, които се състоят от итерации, поради което процесът се нарича още итеративен и инкрементален. Всяка итерация преминава през цикъл на основна работа и довежда разработчиците до крайната цел: създаване на софтуерна система. По време на итерации се създават междинни артефакти, които са необходими за успешното завършване на проекта и версия на софтуерната система, която изпълнява определен набор от функции, който се увеличава от итерация на итерация. Фазите и основните работни потоци на процеса са показани на фиг. 1 там са дадени и приблизителните разходи за труд на работа по етапи.
ориз. 1 RUP фази и работни потоци
Трябва да се отбележи, че на фиг. 1 е показана само основната работа на Единния процес. Например дейностите по управление на дейности не са показани тук, за да се избегне претрупването на диаграмата.
Цялата разработка на софтуер се разглежда в RUP като процес на създаване на артефакти. Всеки резултат от проекта, било то изходни текстове, обектни модули, документи, прехвърлени на потребителя, модели - това са подкласове на всички артефакти на проекта. Всеки член на екипа на проекта създава свои собствени артефакти и носи отговорност за тях. Програмистът създава програмата, мениджърът създава плана на проекта, а анализаторът създава системните модели. RUP ви позволява да определите кога, от кого и какъв артефакт трябва да бъде създаден, модифициран или използван.
Един от най-интересните класове проектни артефакти са моделите, които позволяват на разработчиците да дефинират, визуализират, конструират и документират артефакти на софтуерната система. Всеки модел е самостоятелен изглед на разработваната система и има за цел както да очертае проблемите, така и да предложи решения. Самодостатъчността на моделите означава, че анализатор или разработчик може да получи цялата необходима информация от конкретен модел, без да се обръща към други източници.
Моделите ви позволяват да разгледате бъдещата система, нейните обекти и тяхното взаимодействие дори преди да инвестирате значителни средства в разработката; те ви позволяват да я видите през очите на бъдещите потребители отвън и разработчиците отвътре, дори преди първия ред на източника кодът е създаден. Повечето модели са представени чрез UML диаграми; можете да прочетете повече за UML, например, в.
Unified Modeling Language се появява в края на 80-те и началото на 90-те години, главно благодарение на усилията на „тримата приятели“ Гради Буча, Джим Рамбо и Ивар Джейкъбсън. Вече е приет от консорциума OMG като стандартен език за моделиране, който предоставя на разработчиците ясна нотация, която позволява моделите да бъдат показвани в графични елементи, които са общоприети и разбираеми от всички в проекта.
Не бива обаче да забравяме, че езикът за моделиране предоставя само нотация - инструмент за описание и моделиране на система, а унифициран процес определя методологията за използване на този инструмент, както и на други инструменти за поддръжка на методологията от Rational. UML може да се използва без специфична методология, тъй като е независим от процеса и без значение коя опция за процес се използва, можете да използвате диаграми, за да документирате решенията, взети по време на разработката, и да показвате създадените модели.
Софтуерната система е създадена за решаване на конкретни потребителски проблеми, а не за програмисти, за да тестват нови технологии и да трупат опит за ръководителя на проекта. Като цяло, потребителят не се интересува дали използвате обектно-ориентиран подход, UML, RUP или създавате система, използвайки метода XP (екстремно програмиране) в процеса на разработка. Използването на определени методи, технологии и създаването на оптимална вътрешна структура на проекта остава на съвестта на разработчиците, които вземат решения въз основа на предишен опит и собствените си предпочитания. Потребителят обаче няма да ви прости пренебрегването на неговите изисквания. Дори една софтуерна система да бъде разработена десет пъти с помощта на най-съвременни методи и технологии, ако потребителят не получи това, което се нарича „смислен резултат“ от нея, вашият софтуерен проект ще се провали мизерно.
От това следва, че необмисленото прилагане на UML, просто защото е модерно, не само няма да доведе развитието до успех, но може също да предизвика недоволство сред служителите, които трябва да изучават голямо количество допълнителна литература и ръководителите на проекти, когато се окаже, че разходите за труд по проекта се увеличават, а възвръщаемостта не се увеличава. Трябва ясно да разберете какво искате да получите от прилагането на тази технология и да следвате тази цел. Използването на UML спестява ресурси за разработка, тъй като ви позволява да добиете представа за системата по-бързо, отколкото когато създавате оформления и прототипи, изразходвайки несравнимо по-малко ресурси.
Диаграмите улесняват комуникацията на членовете на проекта помежду си и, което е особено ценно, включват крайните потребители на системата в процеса. Моделирането ви позволява да намалите рисковете на проекта, тъй като за програмистите винаги е по-лесно да правят това, което е ясно и разбираемо, отколкото да стигнат до несигурен резултат. Създаването на диаграми е подобно на създаването на проект в строителството - можете да го направите без него, например, когато изграждате навес на лятна вила, но колкото по-голяма е сградата (в нашия случай софтуерен продукт), толкова по-трудно е да се направи и толкова по-несигурен е крайният резултат.
Веднъж преподавах семинар по RUP в софтуерна компания, която беше доста успешна на пазара от десет години, но изобщо не използваше моделиране в работния си процес, а се базираше на прототипи. В залата се събраха около двайсетина млади и опитни програмисти, които внимателно изслушаха всичко, което им разказах за RUP и UML. И един от тях, гледайки дъската, покрита с примерни диаграми, отбеляза: „Всичко това е интересно и вероятно е добро за други проекти“, каза той, „но ние работим доста дълго време без всичко това, откакто сме все пак успяхме без UML, вероятно просто нямаме нужда от него.
Този въпрос ме накара да мисля, че промяната в бизнес процесите, която неизбежно трябва да настъпи в компания за разработка на софтуер при внедряването на RUP и UML, може да бъде толкова трудна, колкото внедряването на информационна система в индустриално предприятие.Всяко внедряване е разчупване на стереотипите. Тъй като квалификацията на служителите в компания за разработка на софтуер е доста висока, за такива хора е по-трудно да изоставят възгледите си, отколкото за „простосмъртните“, а трудностите и отхвърлянето, които възникват, могат да бъдат сравнени с прехода от процедурен към обектен ориентирано мислене.
1.Определяне на изискванията
Унифицираният процес е процес, управляван от случаи на употреба, които отразяват сценарии за взаимодействие с потребителя. Всъщност това е погледът на потребителите към софтуерната система отвън. Така един от най-важните етапи на разработка, според RUP, ще бъде етапът на дефиниране на изискванията, който се състои в събиране на всички възможни желания за работата на системата, за които потребителите и анализаторите могат да се сетят. По-късно тези данни ще трябва да бъдат систематизирани и структурирани, но на този етап, чрез интервюта с потребители и изучаване на документи, анализаторите трябва да съберат възможно най-много изисквания за бъдещата система, което не е толкова просто, колкото изглежда на пръв поглед. Потребителите често нямат представа какво трябва да получат в крайна сметка. За да улеснят този процес, анализаторите използват диаграми на случаи на използване (фиг. 2)
Фигура 2. Пример за диаграма на случай на използване
Диаграмата е отражение на актьорите (актантите), които взаимодействат със системата, и реакцията на софтуерните обекти към техните действия. Актантите могат да бъдат както потребители, така и външни агенти, които трябва да предават или получават информация. Иконата на случая на използване отразява реакцията на системата към външен вход и показва какво трябва да се направи за актанта.
За детайлизиране на конкретен случай на употреба се използва диаграма на дейността, пример за която е даден на фигура 3.
ориз. 3 Пример за диаграма на дейността
Опростеността на диаграмата на случаите на използване позволява на анализаторите лесно да комуникират с клиентите по време на процеса на дефиниране на изискванията, като идентифицират ограниченията, наложени на системата и върху изпълнението на отделни изисквания, като например време за реакция на системата, които по-късно попадат в раздела на нефункционалните изисквания.
Диаграма на случаи на използване може също да се използва за създаване на тестови сценарии, тъй като всички взаимодействия между потребителите и системата вече са дефинирани.
За да определят правилно изискванията, разработчиците трябва да разберат контекста (част от предметната област), в който ще работи бъдещата система. За целта се създават модел на домейн и бизнес модел, които са различни подходи към един и същи проблем. Често се създава едно нещо: модел на домейн или бизнес модел.
Разликата между тези модели е, че моделът на домейна описва важните концепции, с които ще работи системата и техните връзки помежду си. Докато бизнес моделът описва бизнес процесите (съществуващи или бъдещи), които системата трябва да поддържа. Следователно, в допълнение към дефинирането на бизнес обектите, включени в процеса, този модел дефинира работниците, техните отговорности и действията, които трябва да извършват.
За създаване на модел на домейн се използва обикновена класова диаграма (Фигура 6), но тя очевидно не е достатъчна за създаване на бизнес модел. В този случай се използва диаграма на случай на използване, като се използват допълнителни икони, които отразяват същността на бизнес процесите - това са бизнес актант, случай на бизнес употреба, бизнес субект и управление на бизнеса. Този модел е много по-близо до следващия модел, създаден в процеса на разработка – моделът за анализ.
2.Анализ
След определяне на изискванията и контекста, в който ще работи системата, идва ред на анализ на получените данни. По време на процеса на анализ се създава аналитичен модел, който насочва разработчиците към архитектурата на бъдещата система. Аналитичният модел е изглед на системата отвътре, за разлика от модела на случай на използване, който показва как ще изглежда системата отвън.
Този модел ви позволява да разберете как трябва да бъде проектирана системата, какви класове трябва да има и как те трябва да взаимодействат помежду си. Основната му цел е да определи посоката на внедряване на функционалността, идентифицирана на етапа на събиране на изискванията и да скицира архитектурата на системата.
За разлика от дизайнерския модел, който се създава по-късно, моделът за анализ е по-скоро концептуален модел и само приближава разработчиците до класовете за внедряване. Този модел не трябва да има възможни противоречия, които могат да възникнат в прецедентния модел.
За да се покаже моделът на анализ с помощта на UML, се използва диаграма на класове със стереотипи (модели на поведение) „граничен клас“, „субект“, „контрол“ и се използват диаграми за сътрудничество за детайлизиране (Фигура 4). Стереотипът „граничен клас“ изобразява клас, който взаимодейства с външни актанти, стереотипът „субект“ изобразява класове, които са хранилища на данни, а стереотипът „контрол“ изобразява класове, които управляват заявки към обекти.
Фигура 4. Пример за диаграма за сътрудничество
Номерирането на съобщенията показва техния ред, но целта на диаграмата не е да вземе предвид реда на обменените съобщения, а ясно да покаже връзките на класовете един с друг.
Ако се съсредоточим върху реда на взаимодействие, тогава друго представяне би било диаграма на последователност (Sequence), показана на фигура 5. Тази диаграма ви позволява да разгледате обмена на съобщения във времето, показвайки визуално последователността на процеса. Когато използвате инструмент за създаване на модел като Rational Rose, тези два типа диаграми могат да бъдат създадени автоматично един от друг (можете да прочетете повече за Rational Rose, например в).
Ориз. 5 Пример за диаграма на последователност
Решението коя от двете диаграми да се създаде първа зависи от предпочитанията на отделния разработчик. Тъй като тези диаграми са представяне на един и същ процес, и двете ви позволяват да отразявате взаимодействието между обектите.
3.Дизайн
Следващият етап в процеса на създаване на система е проектирането, по време на което се създава модел на дизайн въз основа на моделите, създадени по-рано. Този модел отразява физическата реализация на системата и описва създадения продукт на ниво клас и компонент. За разлика от модела за анализ, моделът на проектиране има ясна зависимост от условията на изпълнение, използваните езици за програмиране и компоненти. За най-точното разбиране на системната архитектура този модел трябва да бъде възможно най-формализиран и да се поддържа актуален през целия жизнен цикъл на разработка на системата.
За създаване на модел на проектиране се използва цял набор от UML диаграми: диаграми на класове (фиг. 5), диаграми на сътрудничество, диаграми на взаимодействие, диаграми на активност.
Фигура 6. Пример за класова диаграма
Освен това този работен поток може да създаде модел на внедряване, който е внедрен въз основа на диаграма на внедряване. Това е най-простият тип диаграма, предназначена да моделира разпределението на устройства в мрежа. За дисплея се използват само две опции за иконите на процесора и устройството, заедно с връзките между тях.
4.Внедряване
Основната задача на процеса на внедряване е да се създаде система под формата на компоненти - програмни изходни кодове, скриптове, двоични файлове, изпълними модули и др. На този етап се създава модел на изпълнение, който описва как се изпълняват елементи от модела на проектиране, кои класове ще бъдат включени в конкретни компоненти. Този модел описва начина на организиране на тези компоненти в съответствие с механизмите за структуриране и модулиране, приети в избраната програмна среда и е представен чрез диаграма на компонентите (фиг. 7).
ориз. 7 Примерна диаграма на компонентите
5.Тестване
По време на процеса на тестване се проверяват резултатите от внедряването. За този процес се създава модел за тестване, който се състои от тестови случаи, процедури за тестване, тестови компоненти, но няма представяне на UML диаграма, така че няма да се спираме на него.
6. Заключение
Тук бяха разгледани само основните процеси на рационалната методология. RUP е доста обширен и съдържа препоръки за изпълнение на различни софтуерни проекти, от създаването на програми от група разработчици от няколко души, до разпределени софтуерни проекти, които обединяват хиляди хора на различни континенти. Но въпреки огромните им различия, методите за използване на модели, създадени с помощта на UML, ще бъдат еднакви. UML диаграмите, създадени на различни етапи на разработка, са неделими от останалите артефакти на софтуерния проект и често са връзката между отделните RUP процеси.
Решението за използване на конкретни диаграми зависи от изградения в компанията процес на разработка, който, въпреки че се нарича унифициран, не е нещо замразено. Rational не само предлага нейното подобряване и усъвършенстване, но също така предоставя специални инструменти за извършване на промени в RUP базата данни.
Но във всеки случай използването на UML заедно с унифициран процес ще ви позволи да получите предвидим резултат, да изпълните определения бюджет, да увеличите въздействието на участниците в проекта и качеството на създадения софтуерен продукт.
Кратчън. Е. Въведение Рационален унифициран процес . Изд. 2-ри - М.: Издателска къща Уилямс, 2002. - 240 с.: ил.
Jacobson A., Buch G., Rambo J. Унифициран процес на разработка на софтуер - Санкт Петербург: Peter, 2002. - 496 с.: ил.
Фаулър М., Скот К. UML накратко. Приложение на стандартен език за моделиране на обекти: Прев. от английски – М.: Мир, 1999. – 191 с., ил.
Бек. E. Екстремно програмиране. – Санкт Петербург: Питър, 2002. – 224 с.: ил.
ТрофимовС. CASE технологии: Практическа работа в Rational Rose.
Изд. 2-ри - М.: Бином-Прес, 2002 - 288 с.
Единният процес (UP) е обобщен кадърпроцес, който може да бъде специализиран за широк набор от софтуерни системи, различни области на приложение, нива на умения и размери на проекти.
Унифициран процес компонентно ориентиран.Това означава, че създадената софтуерна система е изградена на базата на софтуер компоненти, свързани чрез добре дефинирани интерфейси.
Специфичните аспекти на UP се крият в неговите три характеристики:
● водени от случаи на употреба;
● е с архитектурна насоченост;
● е итеративен и инкрементален .
Унифициран жизнен цикъл на процеса
Жизненият цикъл на UP е разделен на цикли, всеки от които кулминира в доставянето на пускане на продукт. Всеки цикъл на разработка се състои от четири фази – анализ на изискванията и планиране, проектиране, изграждане, внедряване. Всяка фаза е разделена на повторения.
UP включва осем работни процеса: пет основни- дефиниране на изисквания, анализ, проектиране, внедряване, тестване и три спомагателни (за подпомагане на основните) - управление на конфигурация и промяна на изискванията, управление на проекти, управление на околната среда.
За да дефинирате структура на работен поток, първо трябва да определите какво видове изпълнителиучастват в процеса. Тогава реши артефакти, които трябва да бъдат създадени по време на даден работен процес от всеки тип работник.
18. XP е процес.
Екстремно програмиране(на английски: Extreme Programming, XP) е една от гъвкавите методологии за разработка на софтуер. Автори на методиката са Кент Бек, Уорд Кънингам, Мартин Фаулър и др.
Дванадесетте основни техники на екстремно програмиране (според първото издание на книгата Екстремно програмиране обяснено) могат да бъдат комбинирани в четири групи:
1. Кратък цикъл на обратна връзка (фина обратна връзка)
а. Разработка, водена от тестове
b. Игра за планиране
° С. Клиентът е винаги наблизо (Цял екип, клиент на място)
д. Програмиране по двойки
2. Непрекъснат, а не партиден процес
а. Непрекъсната интеграция
b. Рефакторинг (Подобряване на дизайна, Рефакторинг)
° С. Чести малки издания
3. Споделено от всички разбиране
а. Простота (прост дизайн)
b. Комуникация
° С. уважение
д. Колективна собственост върху код или избрани шаблони за проектиране (Колективна собственост върху модели)
д. Стандарт за кодиране или конвенции за кодиране
4. Благосъстоянието на програмиста:
а. 40-часова работна седмица (устойчиво темпо, четиридесет часова седмица)
В XP процесът е разделен на много малки стъпки в сравнение с планираните процеси. Това води до това, че първите стъпки отнемат дни или седмици вместо месеци или дори години за всяка стъпка в модела на водопада. Първо се пишат автоматизирани тестове, за да опишат целите на разработката. След това идва кодирането, което приключва в момента, в който всички тестове преминат и програмистите не могат да измислят нови тестове. Дизайнът се прави от същите хора, които пишат кода. (само последната стъпка - свързване на дизайн и код - е обща за всички гъвкави процеси). Незавършена, но работеща система се показва на тесен кръг потребители (най-често това са самите разработчици). В този момент те започват да пишат тестове за следващата най-важна част от системата.
19. ICONIX е процес.
ICONIX е разработен от Дъг Розенберг в Софтуер ICONIXПроцесът ICONIX е базиран на случаи на използване, но няма много от своите недостатъци. Този процес също използва езика за моделиране UML, но се използва само основната нотация от UML - това е 20% от езика. Процесът ICONIX се основава на четири основни стъпки за разработка на софтуер, базирани на случаи на употреба:
● моделиране на домейн;
● моделиране на прецеденти;
● анализ на пригодността на изискванията (проверка дали всички функционални изисквания са изпълнени);
● изграждане на диаграми на последователности.
Основните етапи на процеса са както следва:
● Анализ на изискванията
● Идеен проект
● Дизайн
● Внедряване
Процесът се основава на изграждането на минимален брой модели, които отразяват бъдещата система. На етапа на анализ се създават модели на случаи на употреба, модел на потребителски интерфейс и модел на обект на домейн. По време на фазата на предварителния дизайн се създава диаграма на устойчивост. Моделът на прецедент и моделът на обект на домейн също се допълват. По време на фазата на детайлен дизайн се създава диаграма на последователност (SequenceDiagram) и се създава диаграма на класове. По време на фазата на внедряване се създава изходният код. Можете също така да създадете диаграма за разполагане и диаграма на компоненти. всеки етап завършва с етап на преглед, където генерираните диаграми трябва да бъдат обсъдени с колеги.
20. SCRUM е процес.
Scrum е набор от принципи, върху които е изграден процесът на разработка, като се допускат строго фиксирани кратки периоди от време ( спринтовеот 2 до 4 седмици) предоставят на крайния потребител работещ софтуер с нови функции с най-висок приоритет. Възможностите на софтуера за внедряване в следващия спринт се определят в началото на спринта на етапа на планиране и не могат да се променят през цялото му времетраене. В същото време строго фиксираната кратка продължителност на спринта дава предвидимост и гъвкавост на процеса на развитие.
Основни актьорски роли в Scrum: ScrumMaster- този, който води Scrumсъбира и следи за спазването на всички принципи Scrum(ролята не предполага нищо друго освен правилното поведение на Scrum-а, ръководителят на проекта по-скоро се отнася за Собственик на продуктаи не трябва да бъде ScrumMaster);Собственик на продукта (Собственик на продукта) - лице, което представлява интересите на крайните потребители и други лица, заинтересовани от продукта; и кръстосано функционален Екип (Скръм екип), състоящ се както от разработчици, така и от тестери, архитекти, анализатори и др. (като идеалният размер на екипа е 7±2 души). Екипът е единственият пълноценен участник в разработката и носи отговорност за резултата като едно цяло. Никой друг освен екипа не може да се намесва в процеса на развитие по време на спринта.
По време на всеки спринт се създава функционален растеж на софтуера. Наборът от функции, които се доставят във всеки спринт, идва от етап, наречен продуктово изоставане(документиране на заявки за работа) с най-висок приоритет по отношение на нивото на работните изисквания, които трябва да бъдат изпълнени. Заявки за работа ( натрупани елементи), определени навсякъде съвет за планиране на спринта (среща за планиране на спринт), се преместват в етапа на спринта. По време на тази среща собственикът на продукта съобщава задачите, които трябва да бъдат изпълнени. След това екипът определя каква част от това, което искат да постигнат, за да изпълнят необходимите части по време на следващия спринт. По време на спринт екипът изпълнява определен фиксиран списък от задачи (т.нар. спринт изоставане). През този период никой няма право да променя списъка с изисквания за работа, което трябва да се разбира като изисквания за замразяване ( изисквания) по време на спринт.
Артефакти
Продуктово изоставанее документ, съдържащ списък с функционални изисквания, подредени по важност. Натрупването на продукти е списък на това, което трябва да бъде доставено. Елементите в този списък се наричат "истории" ( потребителска история) или натрупани елементи ( натрупани елементи). Белогът на продукта е отворен за редактиране от всички участници в процеса на Scrum.
05.10.17 1.6KРационален унифициран процесе универсална методология за разпределение на задачите и отговорностите при разработването на софтуер. Целта му е да създаде висококачествен софтуер, който да отговаря на нуждите и изискванията на потребителите. RUP методологията е разработена в Rational Software Corporation, която беше придобита от IBM през 2003 г.
Невероятният успех на подхода RUP помогна на много компании да разберат колко е важно да има ясно дефиниран и документиран процес на разработка.
RUP методологията е предназначена за големи проекти за развитие, така че много мениджъри смятат, че не е подходяща за малки задачи, които не изискват голямо количество ресурси. Но има много примери, при които малки проекти са се възползвали значително от прилагането на RUP.
Например RUP се използва в системата за управление на онлайн обучението TAP University. Компанията си е поставила за цел да разшири обхвата на традиционното офлайн обучение и да подобри своите услуги за корпоративни, частни потребители и студенти.
Въпреки че беше малък проект, прилагането на методологията на RUP показа отлични резултати. Тя помогна за изграждането на набор от принципи, необходими за организиране на сценарии за използване на услугите на TAP University и помогна да се видят насоките за преход към третата, най-важна фаза на RUP - изграждането.
Какво представлява рационалният унифициран процес (RUP)?
Работа върху процеса– екипът за разработка на RUP работи в тясно сътрудничество с клиенти, партньори и групи от компании, като непрекъснато актуализира методологията.
RUP оптимизира работата в екип– предоставя на екипа за разработка безплатен достъп до база от знания с инструкции за използване на софтуерни инструменти. Това ви помага да се справите с критичните проблеми по-бързо. Благодарение на това екипът лесно намира общ език, докато работи по проекта.
RUP е фокусиран върху създаването и поддържането на модели– вместо писане на голямо количество хартиена документация, при използването на методологията RUP се създават модели – семантични представяния на разработения от екипа софтуер.
RUP – това са инструкции за използване на Unified Modeling Language (UML)– UML позволява на екипа лесно да комуникира своите изисквания към проекта, неговата архитектура и план за изпълнение.
RUP е конфигурируем процес, подходящ е както за малки екипи за разработка, така и за големи организации.
Шест основни принципа на RUP
RUP се основава на шест основни принципа:
- Итеративен модел на развитие– елиминирането на рисковете на всеки етап от проекта ви позволява да разберете по-добре проблема и да направите необходимите промени, докато се намери приемливо решение;
- Управление на изискванията– RUP описва процеса на организиране и проследяване на функционални изисквания, документация и избор на оптимални решения ( както в процеса на развитие, така и в управлението на бизнес);
- Компонентна архитектура– системната архитектура е разбита на компоненти, които могат да се използват както в текущи, така и в бъдещи проекти;
- Визуално софтуерно моделиране - показва методологията за разработка на RUPкак да създадете визуален модел на софтуер, за да разберете структурата и поведението на архитектурата и нейните компоненти;
- Проверка на качеството на софтуера– по време на процеса на разработка на софтуера се контролира качеството на всички екипни действия;
- Контрол на направените промени– проследяването на промените ви позволява да изградите непрекъснат процес на развитие. Създава се благоприятна среда, в която екипът ще бъде защитен от промени в работния процес.
RUP структура
Този подход описва кой какво прави, как и кога. RUP може да се разглежда като четири основни елемента:
Служители – „Кой“
Елементът „работник“ определя поведението и отговорността на всички членове на екипа, фокусирани върху обща цел - създаване на изкуствени обекти (артефакти). В RUP работникът е по-скоро роля, която определя как хората трябва да изпълняват работата си. Служителят не само извършва определени действия, но също така притежава набор от артефакти.
Действия – „Как“
Дейността е единица работа, която работникът може да извърши. Всяко действие има ясно определена цел. Всяко действие се възлага на конкретен служител. Действията могат да включват създаване или актуализиране на артефакти като модел, клас или план.
Артефакти (изкуствени обекти) – „Какво“
В RUP методологията обекти или информация се произвеждат и променят в процеса на работа върху крайния резултат. Артефактите служат както като принос към действията на работниците, така и като резултати от тези действия.
Работен процес - "Кога"
Работният процес е последователност от действия, водещи до видим резултат. В термините на UML можете да мислите за работния поток като диаграма на последователност, диаграма на сътрудничество или диаграма на дейност:
Жизнен цикъл на RUP
Жизнен цикъл на RUPе разделен на четири основни фази, във всяка от които се работи върху ново поколение на продукта: фаза на стартиране на проекта, изясняване, изграждане и внедряване.
- Начална фаза на проекта
В тази фаза екипът определя структурата и основната идея на проекта. Екипът решава дали проектът си струва да бъде преследван въз основа на прогнозната му цена, необходимите ресурси и целта, която трябва да бъде постигната.
- Изясняване
Целта на тази фаза е да се анализират системните изисквания и нейната архитектура, да се разработи план на проекта и да се елиминират най-рисковите елементи. Това е най-важната фаза от всички, защото бележи прехода от нисък към висок риск. По време на тази фаза екипът решава дали да премине към фазата на изграждане ( разработка и кодиране) или не.
- Строителство
В тази фаза на RUP методологията екипът започва разработването на всички компоненти и функции на софтуера и ги интегрира в крайния продукт. Това е производствен процес, в който екипът се фокусира върху управлението на ресурсите, за да оптимизира разходите, времето и качеството на продукта.
- Внедряване
Фазата, когато продуктът е готов и доставен на клиентите. Но след като потребителите получат продукта, може да възникнат нови предизвикателства. Екипът ще трябва да поправи грешки, да хване бъгове и да завърши функции, които не са били внедрени в първоначално зададения срок.
В края на всяка фаза има маркер за завършване на фазата ( Проект Milestone) е моментът, в който вашият екип оценява дали целите му са постигнати. В същото време екипът взема важни решения, които влияят върху хода на следващата фаза.
Рационален унифициран процес(RUP) е технологична рамка за разработка на софтуер, разработена и предлагана на пазара от Rational Software. Той включва глобални най-добри практики в разработката на софтуер и осигурява дисциплинарен подход към възлагането и управлението на задачи и отговорности в рамките на организация за разработка на софтуер. Прилагайки този процес, екипите за разработка на софтуер ще могат да създават висококачествен софтуер, който отговаря на нуждите на техните крайни потребители, и да го правят в рамките на предвидим график и бюджет.
RUP насочва софтуерните професионалисти да прилагат ефективно настоящите най-добри практики, като напр итеративно развитие, приложение ориентиран към архитектурата подход, случаи на използване, намаляване на риска на всички етапи от процеса и непрекъсната проверка на програмата.
Рационалният унифициран процес се основава на няколко основни принципа, събрани от много успешни проекти:
· Започнете да атакувате основните рискове по-рано и го провеждайте непрекъснато, или те сами ще преминат в офанзива срещу вас.
· Уверете се, че изискванията на клиента са изпълнени.
· Концентрирайте се върху програмата, която се изпълнява.
· Адаптирайте се към промените от самото начало на проекта.
· Ранно установяване на изпълнима архитектура.
· Изграждане на система от компоненти.
· Работете заедно като екип.
· Превърнете качеството в начин на живот, а не в закъснение.
RUP използва итеративен подходВсяка итерация извършва малко работа по изискванията, анализ, дизайн, внедряване и тестване. Всяка итерация се основава на резултатите от предишни итерации и създава изпълнима програма, която се приближава с една стъпка по-близо до крайния продукт.
RUP осигурява структуриран подход към итеративно развитие, разделяйки проекта на четири фази: начална фаза, проектиране, изграждане и изпълнение. Всяка фаза е придружена от така наречения етап, контролна точка на процеса, в която се проверява постигането на целите на следващата фаза и се взема решение за преминаване (или не) към следващата фаза. Следователно всяка от четирите фази на RUP има крайъгълен камък и ясно дефиниран набор от цели. Тези цели се използват, за да се определи какви задачи да се изпълняват и какви артефакти да се създават. Всяка фаза се фокусира стриктно върху това, което е необходимо за постигане на бизнес целите на фазата.
Всички елементи на процеса - роли, задачи, артефактии свързани концепции, ръководства и шаблонигрупирани в логически контейнери, наречени дисциплини(Дисциплини). В стандартния RUP продукт има само девет дисциплини. Те включват: бизнес моделиране, управление на изискванията, управление на проекти, управление на промените и среда.
Всеки работен поток на процеса: събиране на изисквания, анализ, проектиране, внедряване и тестване дефинира набор от свързани артефакти и дейности. Спомнете си, че артефактът е документ, отчет, изпълним елемент и т.н. Артефактмогат да бъдат произведени, преработени или консумирани.
Има зависимости между артефакти на нишки. Например моделът на случая на използване, генериранипо време на събирането на изискванията, TBCмодел за анализ от процеса на проектиране, се изпълнявамодел на изпълнение от процеса на внедряване и се проверяватестов модел от процеса на тестване.Модел- най-важният вид артефакт. Предлагат се девет модела, които заедно покриват всички решения за визуализация, спецификация, проектиране и документиране на софтуерни системи:
· бизнес модел. Дефинира абстракцията на организацията, за която се създава системата;
· модел на домейн. Коригира контекстната среда на системата;
· Случай на използване на модела. Определя функционалните изисквания към системата.
· модел за анализ. Интерпретира системните изисквания по отношение на модела на проектиране;
· дизайнерски модел. Дефинира речника на домейна на проблема и неговото решение;
· модел на разположение. Определя хардуерната топология, в която работи системата;
· модел на изпълнение. Дефинира частите, които се използват за сглобяване и внедряване на физическа система;
· тестов модел. Дефинира тестови случаи за проверка на системата;
· модел на процеса. Дефинира паралелизъм в системата и механизми за синхронизация.
Технически артефактиса разделени на четири основни групи:
· набор от изисквания. Описва Каквосистемата трябва да направи;
· дизайнерски комплект.
Описва каксистемата трябва да бъде проектирана;· набор от реализации. Описва асемблирането на разработени софтуерни компоненти;
· комплект за поставяне. Предоставя цялата информация за предоставената конфигурация.
Набор от изискванияможе да включва модел на случай на използване, модел на нефункционални изисквания, модел на домейн, модел за анализ и други форми на изразяване на потребителски нужди.
Дизайнерски комплектможе да включва проектен модел, тестов модел и други форми на изразяване на същността на системата.
Набор от реализациигрупира всички данни за софтуерните елементи, които изграждат системата (програмен код, конфигурационни файлове, файлове с данни, софтуерни компоненти, информация за сглобяване на системата).
Комплект за поставянегрупира цялата информация за опаковане, доставка, инсталиране и стартиране на системата.
Всеки технологичен процес е придружен риск. При разработване на софтуерен продукт незадоволителен резултат (UN) може да бъде: надвишаване на бюджета, ниска надеждност, неправилно функциониране и др. Въздействието на риска се изчислява с помощта на израза
Индикатор за риск = Вероятност (LP) * Загуба (LP).
Управление на рискавключва шест действия:
1. Идентификация на риска – идентифициране на рискови елементи в проекта.
2. Анализ на риска – оценка на вероятността и размера на загубата за всеки рисков елемент.
3. Класиране на риска - подреждане на рисковите елементи според степента на тяхното влияние.
4. Планиране на управлението на риска – подготовка за справяне с всеки елемент на риска.
5. Резолюция на риска – елиминиране или разрешаване на рискови елементи.
6. Мониторинг на риска – проследяване на динамиката на рисковите елементи, предприемане на коригиращи действия.
Първите три действия принадлежат към етапа на оценка на риска, последните три действия към етапа на контрол на риска.
Има три категории източници на риск: проектен риск, технически риск и търговски риск. След идентифициране на рисковите елементи трябва да се определи количествено тяхното въздействие върху софтуерния проект и да се разрешат въпросите за възможните загуби. Тези въпроси се разглеждат по време на стъпката за анализ на риска. И накрая, план за управление на всеки рисков елемент, т.е. набор от функции за управление на всеки рисков елемент, е интегриран в общия план на софтуерния проект.
Унифициран процесразработен от Rational (Rational Unified Process, RUP) е сбор от различни дейности, необходими за трансформиране на потребителските изисквания в софтуерна система. Неговото абстрактно и подробно представяне е показано на фиг. 7.2.
Основните концепции на RUP са артефакт и прецедент. Артефакти- Това са част от продуктите на даден проект, които се генерират или използват в проекта, докато се работи върху крайния софтуерен продукт. Прецедентиили случаи на употреба(случай на употреба) ‑ Това са последователности от действия, извършвани от софтуерна система за получаване на видим резултат.
Целият процес на разработване на софтуерна система се разглежда в RUP като процес на създаване на артефакт. Освен това, това, което попада в ръцете на крайния потребител, било то софтуерен модул или софтуерна документация, е един от подкласовете на всички артефакти на проекта.
Всеки член на екипа на проекта създава свои собствени артефакти и носи отговорност за тях. Програмистът разработва програмата, мениджърът разработва плана на проекта, а анализаторът разработва модела на системата. RUP ви позволява да определите кога, от кого и какъв артефакт трябва да бъде създаден.
(А)
Ориз. 7.2.Единен процес на разработка на софтуер ( А- абстрактно представяне, b– подробно представяне на основните RUP процеси)
RUP обаче е повече от един процес; това е обобщена рамка на процеса, която може да бъде специализирана за широк набор от софтуерни системи, области на приложение, нива на умения и размери на проекти. RUP - компонентно ориентиран.Това означава, че създаваната софтуерна система е изградена на базата на софтуерни компоненти, свързани чрез добре дефинирани интерфейси.
За разработване на графични представяния (модели) на софтуерна система RUP използва унифициран език за моделиране(UML) . Всъщност UML е неразделна част от RUP - те са разработени заедно.
Но наистина специфичните аспекти на процеса на RUP се крият в три фрази - задвижван от случай на употреба, ориентиран към архитектурата, итеративни и инкрементални. Това прави унифицирания процес уникален.
Пълното представяне на софтуерна система в RUP включва девет модела, които заедно покриват всички критични решения относно визуализация, спецификация, дизайн и документация на софтуерна система (Фигура 7.3):
1. модел на бизнес процес, което формализира абстракцията на организацията (с всички възможности за използване на системата за управление и връзките им с потребителите);
2. модел на случай на използване- формализира функционалните изисквания към системата;
3. модел на домейнили бизнес модел, описващ контекста на системата.
4. модел за анализ, който има две цели - да изясни детайлите на случаите на използване и да създаде първично разпределение на поведението на системата върху набор от обекти, които предоставят различни опции за поведение;
5. модел на процеса(по избор) - формализира механизмите на паралелност и синхронизация в системата;
6. дизайнерски модел, което определя: ( А) - статичната структура на системата, като подсистеми, класове и интерфейси, и ( b) - случаи на използване, внедрени във формуляра кооперациимежду подсистеми, класове и интерфейси;
7. модел на изпълнение, което включва компоненти (представени чрез изходен код) и оформление на класове между компоненти;
8. модел на разгръщане, който дефинира физическите компютри - мрежови възли и разположението на компонентите в тези възли;
9. модел за тестване, който описва тестови случаи за валидиране на случаи на употреба;
Ориз. 7.3. RUP модели (под формата на съответните UML диаграми)
и техните връзки,
Всички тези модели са свързани. Заедно те напълно описват софтуерната система. Елементите на един модел имат зависимости за проследяване напред и назад, организирани чрез връзки с други модели (виж Фиг. 7.3). Например случай на употреба (в модел на случай на употреба) може да бъде проследен до съответно изпълнение на случай на употреба (в модел на проектиране) и тестов случай (в тестов модел). Проследяването улеснява разбирането и извършването на промени. UML диаграмите, създадени по време на процеса на разработка на RUP, дават пълна картина на софтуерния продукт).
Основният акцент в RUP не е върху изготвянето на документи като такива, а върху моделиранесистемата, която се разработва. Моделите помагат да се очертаят както проблема, така и начините за разрешаването му, и са създадени с помощта на езика UML, който отдавна се е превърнал в стандарт de facto за описание на сложни системи и позволява на разработчиците да дефинират, визуализират, конструират и документират артефакти на софтуерни системи от всякакви сложност.