Inception

Kom ihåg att processen är till för er, inte tvärtom. Skapa inte fler dokument än vad ni har nytta av.

Syfte

Detta är den första fasen i RUP. Syftet är att alla inblandade ska vara överens (i stora drag) om vad produkten ska göra, hur lång tid det tar att utveckla den och vad det kostar. Detta ska utgöra ett tillräckligt underlag för att fatta beslut om projektet ska läggas ned eller om det ska gå vidare med en noggran undersökning (vilken sker i nästa fas). Syftet är alltså att fatta beslut om det är värt att göra en ordentlig undersökning, inte att göra den.

Notera att syftet inte är att göra en färdig kravspec. Syftet är att göra lagom mycket av kravspecen och lagom mycket prototypande för att få en grov uppfatning om projektets omfång.

Tidsåtgång

Inception är den kortaste av projektets fyra faser. Om den inte är kort har förmodligen för mycket arbete utförts och nästa fas påbörjats i förtid. Inception består normalt (och absolut i vårat fall) bara av en iteration.

Slutresultat

En del av inception ägnas åt en första ansats till kravanalys. Den består av Vision, Use-Case Model, User-Interface Prototype, Supplementary Specification, Glossary och Risc List. För alla dokument gäller att ingenting ska vara med som inte tillför något av vikt. Hoppa hellre över en rubrik än att skriva något bara för att den måste finnas. Kom ihåg att inget av dokumenten är slutgiltigt, de får (kommer att) ändras i kommande iterationer.

Vi bör dessutom skriva prototyper för att försäkra oss om att det vi avser göra är möjligt.

Vision

Detta är den mest övergripande artifakten. Den innehåller en beskrivning av vilka som har intressen i produkten och vilka dessa intressen är samt vad produkten är till för och vad den ska utföra. Det är lämpligt att börja inception med ett försök till vision för att alla inblandade ska få en gemensam syn på vad arbetet går ut på. Sedan, när de andra artifakterna är klara, omarbetas vision så att den innehåller en summering av dem.

Detta kan vara lämpliga rubriker i vision:
Projektförslaget ska lämnas till examinatorn i form av ett vision-dokument senast första dagen i period tre. Nedan finns mallar för vision. De är väldigt omfattande, fyll inte i alla rubriker utan välj de viktiga.
MSWord-mall: vision.dot
html: vision.html

Use-Case Model

På ett program ställs både funktionella krav (vad det ska göra) och ickefunktionella krav (säkerhet, prestanda, användarvänligt, lättunderhållet...). I use case:n sammanställs alla funktionella krav och eventuellt även inckefunktionella krav som är kopplade till något specifikt use case.

Under inception är det lämpligt att identifiera så gott som alla use case och aktörer till namn och att skriva 10-20% av use case:n i detalj.

Ett use case är en text. Ägna inte en massa tid åt att rita use case-diagram. Rita dem över huvud taget inte alls om de inte tillför något. Ägna heller inte en massa tid åt att utreda om eller hur olika use case inkluderar eller ärver varandra.

Några definitioner:

Det finns ett antal mallar för use case, nedanstående är hämtad från http://www.usecases.org. De absolut viktigaste punkterna är ett, fem och sex. Vi måste veta vem som gör det (punkt ett) och vad som görs (punkt fem och sex). Punkt fem och sex kommer att ligga till grund för både kodning och test.
  1. Primary Actor
    Den som i första hand utför det som står i use case:t.
  2. Stakeholders and Interests
    Vilka som har intressen i detta use case och vad deras intresse är. Denna lista är till för att hjälpa oss hitta alla moment i den detaljerade beskrivningen av use case:t som kommer senare.
  3. Preconditions
    Villkor som alltid måste vara uppfyllda innan use case:t påbörjas.
  4. Postconditions
    Villkor som alltid måste vara uppfyllda för att use case:t ska vara lyckat genomfört. I bankomat exemplet ovan behöver dessa villkor alltså inte uppfyllas om användaren inte kommer ihåg sin kod eller om det inte finns pengar på kontot.
  5. Main Success Scenario
    En lista över allt som normalt händer vid ett lyckat genomförande. Ange inga villkor eller förgreningar här, de kommer i nästa stycke. Skriv vad systemet gör, inte hur det görs.Punkterna i listan ska vara av någon av dessa tre typer:
    1. Interaktion mellan systemet och någon aktör.
    2. Systemet validerar inparametrar.
    3. Systemet ändrar tillstånd.
  6. Alternate Flows
    Ange allt som skiljer alternativa scenarion från scenariot i ovanstående punkt. Alla alternativa scenarion (både lyckade och misslyckade) ska beskrivas här.
  7. Special Requirements
    Ickefunktionella krav på detta use case.
  8. Technology and data Variations List
    Här anges oundvikliga krav på teknologin. Detta är egentligen beslut som ska fattas senare (under design) men om yttre omständigheter tvingar oss till vissa val kan de anges här. I vårt fall kan det till exempel vara "användargränssnittet ska skrivas med Swing".
  9. Frequency of Occurence
    Hur ofta exekveras use case:t
  10. Open Issues
    Outforskade frågor som kan förändra use case:t.
Det är ofta svårt att veta om någon viss händelse är ett eget use case eller bara ett moment i ett större use case. Naturligtvis finns inget exakt rätt eller fel svar på denna fråga men en bra riktlinje är att ett use case är något som utförs av en person vid ett tillfälle, som tillför verksamheten något av värde och som lämnar systemet i ett tillåtet tillstånd. Det vanligaste felet är att göra för många små use case, till exempel är logga in knappast ett use case, däremot kanske starta en session. Ett undantag från denna regel är att vissa moment ingår i flera andra use case. Dessa moment får då brytas ut i eget use case som inkluderas i de andra även om det i sig själv är onödigt detaljerat.

Ett bra sätt att hitta use case är att identifiera aktörer och sedan fråga sig (eller ännu hellre fråga aktören själv) "vilka är dina mål?" och "vad är målet med det målet?". När vi på det sättet fått fram tillräckligt abstrakta (övergripande) mål har vi ett use case med samma namn som målet.

Några vanliga aktörer (och därmed use case) som lätt missas kan identifieras med frågor som:

Supplementary Specification

Denna artifakt behandlar de ickefunktionella kraven (säkerhet, prestanda, användarvänligt, lättunderhållet...).

Nu stöter vi för första gången på begreppet arkitektur. Arkitekturen är systemets "skelett", allt som behövs för att förstå hur det fungerar. Arkitekturen talar om att problem kan lösas och var de löses men inte hur (det hör till design). Vid ett husbygge behövs det kanske en hiss. Arkitekten ritar då ett hisschakt, designern ritar en hiss och konstruktören monterar in hissen.

Både arkitekturell kravanalys och arkitekturell design är komplexa och svårbemästrade vetenskaper som i stor utsträckning bygger på erfarenhet och är svåra att formalisera. Det här är inget försök att gå igenom dessa.

Supplementary specification ska innehålla arkitekturella (dvs övergripande) krav som inte täcks i use case-modellen. Detta är de ickefunktionella kraven, även ickefunktionella krav som finns i avsnitten special requirements i use case:n  bör upprepas här. Notera att supplementary specification ska innehålla kraven (problemen), inte lösningarna på dem. Lösningarna ska vi söka först i nästa fas.

Exempel på frågor som bör beaktas här är:
Det är viktigt att så gott det går gradera dessa punkter både vad gäller hur svåra de är att lösa och hur viktiga de är att lösa. Använd få nivåer (till exempel tre) vid graderingen.

User-Interface Prototype

Med ledning av främst use case-model men även supplementary specification byggs en user interface prototype som innehåller så detaljerade förslag som möjligt på användargränssnitt. Det är viktigt att kunden tittar noga på dessa eftersom det även är ett bra sätt att upptäcka brister i systemets funktionalitet. "I värsta fall" ritas de på papper men det är absolut att föredra att de utvecklas i skarp kod. Om användargränssnittet ska skrivas i swing kan det vara bra att utveckla prototypen med någon GUI builder.

Glossary

Många termer i de andra dokumenten är tvetydiga. Här definieras alla sådan termer. Ange även till exempel enheter, tillåtna värden och andra regler för validering, relationer till andra termer samt synonymer

Risc List

Det är viktigt att så många risker som möjligt är kända på det här stadiet. Här kan ni sammanställa risker av mer övergripande karaktär än tex punkterna i Supplementary Specification. Exempel på sådana risker kan vara "Vi får aldrig tillgång till vår datasal" eller "Vi förstår inte vad kunden vill".  Det kan också vara sammanfattningar av stora problem som dyker upp i Supplementary Specification tex "databasen kan inte hantera transaktioner" eller "vi har ingen aning om hur krypterad kommunikation ska implementeras".

Prototyper

Det är mycket lämpligt bygga en proof-of-concept protoype. Syftet är dels att övertyga sig om att de tilltänkta teknologierna är användbara, dels att leka och labba med alla inblandade produkter för att vara förtrogen med dem när utvecklingen börjar "på riktigt". Denna prototyp ska  då ha följande egenskaper:

Tidplan

Det är på det här stadiet omöjligt att göra en tidplan som omfattar något mer än slutdatum för inception.