Inception

Kom ihåg att RUP är avsedd att anpassas. Skapa inte fler dokument än vad som behövs

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.

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. Speciellt kort blir inception om det, som i vårt fall, redan är bestämt att projektet ska gå vidare in i nästa fas. Inception består normalt (och absolut i vårat fall) bara av en iteration.

Slutresultat

Den största delen 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. Vi kan också skriva prototyper för att försäkra oss om att det vi avser göra är möjligt. 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.

Vision

Detta är den mest övergripande artifakten. Den innehåller en beskrivning av vilka som har intressen i systemet och vilka dessa intressen är samt vad systemet är till för och vad det 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å. Om det behövs (vilket är sannolikt) omarbetas vision sedan mot slutet av fasen så att det innehåller en summering av de andra artifakterna.

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, denna är hämtad från http://www.usecases.org. Jag kommer att dela ut ett exempel på den.
  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 "resultatet ska presenteras i uPortal".
  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 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

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 vilka problem som löses 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. Jag kommer att dela ut ett exempel på supplementary specification.

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.

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

Om vi tvivlar på att kraven går att lösa kan vi bygga en proof-of-concept. Denna prototyp ska  då ha följande egenskaper:
I vårt fall finns det tekniskt sett inget behov av en sådan prototyp eftersom detta redan är gjort och dokumenterat. Jag tycker dock det är lämpligt ändå att göra en sådan prototyp för att ni snabbt ska komma igång med tekniken (vilket kan ta tid) och ge mig ett proof-of-concept på att ni klarar av att bygga en sådan lösning.

Tidplan

Det är på det här stadiet omöjligt att göra en tidplan. Vad som egentligen borde göras är en plan för nästa iteration, den första i elaboration, men det är inte lätt innan ni gått igenom vad den fasen innehåller. Vi nöjer oss med att fastställa när inception ska vara klart, jag föreslår att den får ta 2-3 veckor men det får vi diskutera närmare på första mötet.