Unified Process ( engelska unified process ) är en metodik för att bygga mjukvaruutvecklingsprocesser som gör att utvecklingsteamet kan omvandla kundernas krav till en fungerande produkt. Beroende på krav och tillgängliga resurser kan utvecklingsprocessen anpassas genom att inkludera eller exkludera vissa projektaktiviteter. Ett exempel på en utvecklingsmetodik baserad på Unified Process är Rational Unified Process ( RUP ), som innehåller ett antal aktiviteter som inte beskrivs i ett mer generellt ramverk, men av värde för en viss typ av projekt [1] .
Unified Process använder sig mycket av Unified Modeling Language ( UML ). Kärnan i UML är en modell som gör det möjligt för ett utvecklingsteam att på ett förenklat sätt förstå mångfalden av komplexa processer som krävs för att utveckla mjukvara. Olika modeller som används i Unified Process låter dig visualisera systemet, beskriva dess struktur och beteende, dokumentera de beslut som fattas under utvecklingsprocessen [1] .
Upprinnelsen till ramverket ligger i Ericsson -medarbetaren Ivar Jakobsons arbete , publicerat i slutet av 1960-talet. Jacobson och hans kollegor modellerade enorma telekommunikationssystem med skikt av "block" (det som senare blev känt som "komponenter"): de nedre skikten fungerade som basen för delsystem från de övre skikten. Teamet byggde de nedre blocken genom att titta på trafikfall som kan ha hänt användare av systemet . Det var dessa "incidenter" som blev prototypen för användningsfall , som senare blev en del av UML [2] . Jacobsons arbete gav också drivkraften för de diagram som används i UML , inklusive aktivitets- och sekvensdiagram .
1987 grundade Jacobson sitt eget företag, Objectory AB , och tillbringade flera år tillsammans med partners för att utveckla ett projekt och en produkt som heter Objectory . 1995 publicerade Jacobson boken Object-Oriented Software Engineering , som beskriver en utvecklingsprocess som drivs av kundernas krav, som omsätts till slutprodukten genom användningsfall. Utgivningen av boken sammanföll med den första onlinepubliceringen av Unified Process -kärnan .
1995 övertogs Objectory AB av Rational Corporation . Med hjälp av ett kraftigt ökat antal kollegor börjar Jacobson utöka Objectory- processen med projektlednings- och utvecklingsverktyg. Tillsammans med Gradi Booch och James Rumbaugh , som tidigare hade arbetat på Rational , blev Jacobson medlem i gruppen av "tre amigo" [3] [4] , som ledde arbetet med att skapa en process som kallas Rational Objectory Process ( ROP ), såväl som distributionen av Unified Process , som blev grunden för Unified Modeling Language .
Under arbetet med ROP och UML fortsatte Rational Corporation att gå samman och förvärva företag som är involverade i att skapa verktyg för mjukvaruutveckling. Dessa verktyg gav möjligheten att hantera krav ("RequisitePro"), allmän testning ("SQA"), prestandatester, konfigurationshantering och förändringshantering. 1998 ändrade Rational namnet på produkten till RUP , vars konceptuella kärna förblir Unified Process .
The Unified Process bygger på användningsfall som beskriver en eller flera aktörer som interagerar med systemet och producerar resultat som är av värde för processdeltagare. Det är användningsfall som är den främsta drivkraften som styr hela utvecklingsprocessen, från insamling och diskussion av krav, och slutar med analys, design och implementering. Användningsscenarier beskrivs på ett enkelt och begripligt språk, så att de är begripliga för en utomstående läsare.
Enligt Unified Process är arkitektur den grundläggande organisationen av hela systemet i centrum för utvecklingsprocessen . Det kan inkludera statiska och dynamiska element, deras interaktion, och låter dig lösa problem med produktprestanda, utbyggbarhet, möjligheten att återanvända element, hjälpa till att övervinna ekonomiska och tekniska begränsningar. Designteamet påbörjar arbetet med arkitekturbeskrivningen så tidigt som möjligt och utökar och förbättrar den kontinuerligt under utvecklingen. Arkitektur anses vara en viktig aspekt av den förenade processen av ett antal anledningar, bland annat förmågan att se helheten, rätt tillämpning av utvecklarinsatser, underlättande av återanvändningsmöjligheter för komponenter, utvecklingen av systemet, korrekt val av användningsfall.
Den tredje grundläggande principen i Unified Process är att använda en iterativ och inkrementell metod . Iterationer är miniatyrprojekt som låter dig köra en nyare version av systemet. Resultatet av en iteration, de ändringar som gjorts i systemet, kallas ett inkrement. I synnerhet låter det iterativa tillvägagångssättet dig konsekvent förbättra systemets arkitektur, hantera ständiga förändringar i kraven och flexibelt anpassa planen för hela projektet. Engagemang för principen om kontinuerlig integration gör att du kan identifiera möjliga problem i ett tidigt skede. Dessutom hjälper iterativitet till att minimera riskerna förknippade med tekniska begränsningar, arkitektur och förändrade krav [5] .
Varje utvecklingscykel, enligt Unified Process , består av fyra faser, som representerar tidsintervallet mellan viktiga milstolpar i projektet, vilket gör det möjligt för chefer att fatta viktiga beslut angående fortsättningen av utvecklingsprocessen, arbetets omfattning, budget och tidsplan.
Den inledande fasen ( eng. Inception ) låter dig skissera systemets gränser, bestämma den föreslagna arkitekturen, identifiera kritiska risker och fatta beslut angående starten av projektet, beroende på de uppskattade uppskattningarna av dess kostnad, ansträngning, tidsplan och produkt kvalitet. Förknippad med denna fas är en viktig projektmilstolpe som kallas Life Cycle Goals.
Förberedelsefasen ( English Elaboration ) skapades för att lösa följande uppgifter: klargörande av flertalet funktionskrav; omvandla den tänkta arkitekturen till en fungerande arkitekturfokuserad prototyp; eliminering av kritiska risker; fatta ett slutgiltigt beslut om starten av projektet och skapa en tillräckligt detaljerad plan. Denna fas avslutas med en milstolpe som kallas "Lifecycle Architecture".
Konstruktionsfasen involverar iterativ utveckling av ett system som framgångsrikt kan interagera med användare i en betamiljö . Närvaron av ett mer eller mindre fungerande system markerar det framgångsrika uppnåendet av den relevanta milstolpen.
Överföring ( eng. Transition ) av ett fullt fungerande system till användare är den sista fasen av utvecklingscykeln. En milstolpe för det är lanseringen av produkten [6] .
Inom den enhetliga processen , i varje utvecklingsfas, finns det fem typer av arbetsflöden: krav, analys, design, implementering och testning.
Varje process är en uppsättning aktiviteter som utförs av olika medlemmar i projektgruppen. Syftet med kravinsamlingsprocesser är till exempel att skapa en modell av användningsfall som låter dig identifiera de huvudsakliga funktionskraven för systemet. Analysprocesser och motsvarande modell tillåter utvecklare att strukturera funktionella krav; Designprocessen beskriver den fysiska implementeringen av användningsfall och är en abstraktion för följande modell. Process- och implementeringsmodellen beskriver hur designelement förhåller sig till mjukvarukomponenter, inklusive källkod, dynamiska bibliotek etc. Den sista av modellerna, som beskriver testning, förklarar vilka systemtester och enhetstester och hur utvecklingsteamet ska utföra [7] .
Var och en av faserna som beskrivs i Unified Process består av iterationer , som är miniatyrdelprojekt med begränsad varaktighet. Som regel inkluderar varje iteration alla fem delar av arbetsflödet i en eller annan grad. Resultatet av en iteration är ett inkrement , en version som innehåller förbättringar jämfört med den tidigare versionen av produkten.
Under iterationen utför utvecklingsteamet följande steg:
Inom den förenade processen är en artefakt vilken information som helst som spelar en viktig roll i utvecklingsprocessen. Artefakterna som används av ingenjörer inkluderar modeller, prototyper, testresultat etc. Chefens artefakter är projektplanen, affärsfall etc. En viktig komponent i Unified Process är att systemet inte anses vara färdigt för användning förrän alla relevanta artefakter är inte färdigt.
En utförare är en roll som en enskild anställd kan spela i ett projekt. Skillnaden mellan en skådespelare och en aktör (från användningsfall) är att den senare ser på systemet från "utsidan", medan skådespelaren ser från "insidan". Konstnärer skapar artefakter, antingen ensamma eller i grupper eller team. Det är viktigt att komma ihåg att samma person kan spela flera roller i ett projekt: till exempel kan en analytiker också identifiera användningsfall och beskriva dem.
Var och en av varianterna av arbetsflödet inkluderar flera aktiviteter - uppgifter som artister arbetar med för att få artefakter [9] .
Den förenade processen ligger till grund för ett antal metoder för mjukvaruutveckling, inklusive [10] :
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|