TDT4290 Kundestyrt Prosjekt Prosjektgruppe 17 Anders Lund Fredriksen Magnus Skuland Erik Åldstedt Sund Kaare Kristian Lilleng Bjørn-Erik Stenbakk Sverre Sundsdal 13. november 2003 Institutt for Datateknikk og Informasjonsvitenskap
ii Web Single Sign-on
Forord Denne oppgaven ble gitt av konsulentselskapet Kantega og ble utført som en del av TDT4290 Kundestyrt Prosjekt ved Institutt for Datateknikk og Informasjonsvitenskap, NTNU. Oppgaven ble opprinnelig gitt av Mogul som ble slått konkurs av eierene i juni 2003. Da tok 40 ansatte over konkursboet og grunnla Kantega. De fikk med seg kundene til tidligere Mogul inn i det nye selskapet og var innstilt på å ta med seg denne oppgaven videre. Prosjektet Web Single Sign-on har som formål å utvikle en demonstrator som viser Web Single Sign-on basert på Project Liberty. Resultatet vil i tillegg være å øke kundens kunnskap om Project Liberty og å ha et grunnlag for videre implementasjon av Liberty-spesifikasjonen. Som studenter er det en positiv opplevelse å få jobbe med en oppdragsgiver fra næringslivet med en realistisk oppgave. Web Single Sign-on er resultatet av ca. 2200 arbeidstimer fordelt på 6 personer over 85 dager. Det har vært hardt arbeid og søvnløse netter. Samtidig har dette vært den mest positive prosjektopplevelsen vi har hatt under hele vår periode på NTNU. Gruppa har vært beinmotivert og gøtset mer enn noensinne! Vi vil gjerne takke kunden vår Kantega ved Svein Otto Solem og Harald Stendal. Vi vil også takke hovedveiledere Reidar Conradi og Thomas Østerlie, samt hjelpeveileder Svein Robøle. I tillegg vil vi takke Sigurd Segtnan som var med på prosjektgruppa i starten, men trakk seg grunnet personlige årsaker. Sverre Sundsdal Anders Lund Fredriksen Bjørn-Erik Stenbakk Magnus Skuland Erik Åldstedt Sund Kaare Kristian Lilleng iii
Innhold 1 Prosjektdirektiv 1 1.1 Innledning.................................... 2 1.1.1 Bakgrunnen for prosjektet....................... 2 1.1.2 Om prosjektdirektivet......................... 2 1.2 Prosjektmandat................................. 3 1.2.1 Prosjektnavn.............................. 3 1.2.2 Prosjektsponsor............................. 3 1.2.3 Effektmål................................ 3 1.2.4 Resultatmål............................... 3 1.2.5 Omfang................................. 3 1.2.6 Rammebetingelser........................... 4 1.2.7 Økonomi................................. 4 1.2.8 Tid.................................... 4 1.3 Prosjektplan................................... 5 1.3.1 Beskrivelse av fasedokumentene................... 5 1.4 Organisering av gruppa............................ 8 1.5 Maler og standarder.............................. 10 1.5.1 Generelt................................. 10 1.5.2 Fasedokumenter............................ 10 1.5.3 Dokumentmaler............................ 10 1.5.4 Katalogstruktur............................. 11 1.5.5 Navngiving av filer........................... 11 1.5.6 Sikkerhetskopi............................. 11 1.5.7 Litteraturhenvisninger......................... 11 1.5.8 Versjonskontroll og dokumenthåndtering.............. 12 1.5.9 Programvare.............................. 12 1.6 Prosjektoppfølging............................... 13 1.6.1 Prosjektmøter.............................. 13 1.6.2 Internrapportering........................... 14 1.6.3 Statusrapportering........................... 14 1.6.4 TROKK................................. 14 1.7 Kvalitetssikring................................. 17 1.7.1 Responstider.............................. 18 1.7.2 Rutiner.................................. 19 iv
2 Forstudie 21 2.1 Innledning.................................... 22 2.2 Dagens Situasjon................................ 23 2.2.1 Om Kantega............................... 23 2.2.2 Oppgaven................................ 23 2.2.3 Dagens teknologi............................ 27 2.2.4 Dagens alternativer........................... 27 2.2.5 Forretningsmessige krav/avgrensinger............... 29 2.2.6 Evalueringskriterier.......................... 30 2.3 Beskrivelse av fremtidig løsning....................... 32 2.3.1 Arbeids- og informasjonsflyt..................... 32 2.3.2 Personvern............................... 36 2.3.3 Markedsundersøkelse......................... 38 2.4 Beskrivelse av teknologiske løsninger.................... 40 2.4.1 Webtjenester............................... 40 2.4.2 Project Liberty.............................. 41 2.4.3 Utviklingsplattform.......................... 46 2.4.4 Webserver................................ 49 2.4.5 Teknologier............................... 51 2.4.6 Maskinvare og utviklingsverktøy................... 62 2.4.7 Valg av løsning............................. 63 3 Kravspesifikasjon 65 3.1 Innledning.................................... 66 3.2 Beskrivelse av systemet............................ 68 3.2.1 Hensikt med systemet......................... 68 3.2.2 Reelle aktører.............................. 68 3.3 Funksjonelle krav................................ 70 3.3.1 Use Cases................................ 70 3.3.2 Funksjonelle krav til prosjektet WSSO................ 75 3.3.3 Oppsummeringsscenario....................... 86 3.4 Ikke-funksjonelle krav............................. 88 3.4.1 Portabilitet................................ 90 3.4.2 Sikkerhet (Security)........................... 92 3.4.3 Ytelse................................... 94 3.4.4 Pålitelighet............................... 96 3.4.5 Gjenbruk av kode............................ 98 3.4.6 Brukerdokumentasjon......................... 100 3.4.7 Installasjonsveiledning......................... 102 3.4.8 Brukeropplevelse............................ 103 3.5 Evaluering av Libertys brukeropplevelse.................. 110 3.6 Arbeidsestimering............................... 111 3.6.1 Datagrunnlag.............................. 111 3.6.2 Estimat for samtlige Use Case..................... 113 3.6.3 Estimat for høyt prioriterte Use Case................. 113 3.6.4 Konklusjon for arbeidsestimering.................. 113 INNHOLD v
4 Konstruksjon 115 4.1 Innledning.................................... 116 4.1.1 Arbeidet med konstruksjon...................... 116 4.2 Overordnet systembeskrivelse......................... 118 4.2.1 Pakker i wsso.............................. 119 4.2.2 Brukeropplevelsen........................... 119 4.3 Kommunikasjon................................. 124 4.3.1 HTTP Redirect............................. 124 4.3.2 SOAP................................... 125 4.3.3 XML-dokumenter........................... 125 4.3.4 Basis-sti................................. 126 4.3.5 Logout-sti................................ 128 4.3.6 Koble av nøkkelring-sti........................ 129 4.4 Service Provider................................. 131 4.4.1 Klassediagram............................. 131 4.4.2 Brukerautentiseringssjekk hos SP (steg 2 i basis-sti)........ 134 4.4.3 Artefakthåndtering (steg 8 i basis-sti)................ 136 4.4.4 Håndtering av global utlogging (steg 2 i Single Logout-sti).... 138 4.4.5 Prosesser Logout (steg 6 i Single Logout-sti)............ 139 4.4.6 Prosesser deføderasjon (steg 2 i Kople av nøkkelring-sti)..... 139 4.4.7 DB-diagram, Service Provider (SP).................. 140 4.5 Identity Provider................................ 142 4.5.1 Klassediagram............................. 142 4.5.2 Brukerautentiseringssjekk (steg 5 i basis-sti)............ 147 4.5.3 Artefaktoppslag (steg 10 i basis-sti)................. 148 4.5.4 Prosesser Logout (steg 4 i Single Logout-sti)............ 150 4.5.5 Prosesser deføderasjon (steg 4 i Kople av nøkkelring-sti)..... 151 4.5.6 DB-diagram, Identity Provider (IDP)................. 151 4.6 wsso.misc-pakken.............................. 154 4.6.1 Klassediagram............................. 154 5 Implementasjonsspesifikasjon 161 5.1 Innledning.................................... 162 5.1.1 Arbeidet med implementasjon.................... 162 5.1.2 Eclipse.................................. 163 5.1.3 CVS.................................... 163 5.2 Tomcat...................................... 164 5.2.1 web.xml................................. 164 5.2.2 Katalogstruktur............................. 166 5.2.3 Benyttede objekter i Tomcat-bibliotekene.............. 166 5.3 Axis........................................ 168 5.3.1 deploy.wsdd.............................. 168 5.3.2 Benyttede objekter i Axis-biblioteker................. 170 5.4 OpenSAML................................... 171 5.4.1 Bruk av OpenSAML med Axis.................... 171 5.4.2 Benyttede objekter i OpenSAML-biblioteket............ 171 vi INNHOLD
5.5 Bygging Ant................................. 173 5.5.1 build.xml................................ 173 5.5.2 build.properties............................ 175 5.6 Andre biblioteker................................ 176 5.6.1 dom3-xml-apis-2.4.0.jar........................ 176 5.6.2 dom3-xercesimpl-2.4.0.jar....................... 176 5.6.3 saaj.jar.................................. 176 5.6.4 mysql-connector-java-3.0.9-stable-bin.jar............. 176 5.6.5 jaxrpc.jar................................. 176 5.7 Systemvariable................................. 178 5.7.1 sp.properties.............................. 178 5.7.2 VariableHolder-klassen...................... 179 5.8 Service Providere................................ 180 5.8.1 Nettsidene................................ 180 5.9 Identity Provider................................ 183 5.9.1 Nettsidene................................ 183 5.10 Databaseimplementasjon............................ 184 5.10.1 Generelt................................. 184 5.10.2 Navnekonvensjoner.......................... 184 5.10.3 Databaseoperasjoner.......................... 184 5.10.4 Databaseskjema............................. 184 6 Dokumentasjon 187 6.1 Innledning.................................... 188 6.2 Installasjonsveiledning............................. 189 6.2.1 Systemkrav............................... 189 6.2.2 Installasjon............................... 189 6.3 Brukerveiledning................................ 195 6.3.1 Hva er WSSO?............................. 195 6.3.2 Hvorfor WSSO?............................. 195 6.3.3 Figurer.................................. 195 6.3.4 Eksempler på mulige scenarier.................... 196 7 Testdokument 211 7.1 Innledning.................................... 212 7.2 Overordnet testplan............................... 213 7.2.1 Planlagte tester............................. 213 7.2.2 Klassifisering av feil og godkjenningskriterier........... 214 7.2.3 Testpersonell og tidsplan....................... 215 7.3 Detaljerte testspesifikasjoner.......................... 216 7.3.1 Enhetstesting.............................. 216 7.3.2 Modultesting.............................. 216 7.3.3 Systemtesting.............................. 217 7.4 Testlogg...................................... 221 7.4.1 Testlogg for systemtestene....................... 221 INNHOLD vii
8 Prosjektevaluering 233 8.1 Innledning.................................... 234 8.1.1 Formål med evalueringen....................... 234 8.1.2 Grunnlag for evalueringen...................... 234 8.2 Kunde, oppgave og gjennomføring...................... 235 8.2.1 Kunde.................................. 235 8.2.2 Oppgave................................. 235 8.2.3 Gjennomføring............................. 235 8.3 Evaluering av faser............................... 237 8.3.1 Planlegging............................... 237 8.3.2 Forstudie................................. 237 8.3.3 Kravspesifikasjon............................ 238 8.3.4 Konstruksjon.............................. 239 8.3.5 Implementasjon og implementasjonsspesifikasjon......... 239 8.3.6 Dokumentasjon............................. 240 8.3.7 Testplan................................. 240 8.3.8 Prosjektevaluering........................... 240 8.3.9 Presentasjon og demonstrasjon.................... 240 8.4 Totalvurdering.................................. 241 8.4.1 Måloppnåelse.............................. 241 8.4.2 Tidsrammer og progresjon....................... 241 8.4.3 Tekniske aspekter............................ 244 8.4.4 Organisatoriske aspekter....................... 245 8.4.5 Hva har vi lært?............................. 246 8.5 Fagevaluering.................................. 247 8.5.1 Faget som helhet............................ 247 8.5.2 Veiledere................................. 247 8.5.3 Forelesninger.............................. 248 8.5.4 Seminarer og kurs........................... 248 8.6 Videre arbeid.................................. 250 8.6.1 Mulige utvidelser............................ 250 8.6.2 Tidsanslag for å gjøre systemet ferdig................ 250 A Interessenter 251 A.1 Kunde...................................... 252 A.2 Veiledere..................................... 252 A.2.1 Hovedveiledere............................. 252 A.2.2 Hjelpeveileder............................. 252 A.3 Prosjektgruppe................................. 252 B Maler 255 B.1 Møteinnkalling gruppemøte, gruppe 17................... 256 B.2 Møteinnkalling kundemøte, gruppe 17.................... 257 B.3 Møteinnkalling veiledermøte, gruppe 17................... 258 B.4 Referat gruppemøte, gruppe 17........................ 259 B.5 Referat kundemøte, gruppe 17........................ 260 viii INNHOLD
B.6 Referat veiledermøte, gruppe 17....................... 261 B.7 Statusrapport.................................. 262 C XML-dokumenter 263 C.1 <AuthnRequest>................................ 264 C.2 <samlp:request>................................ 265 C.3 <samlp:response>............................... 265 C.4 <FederationTerminationNotification>.................... 266 C.5 <LogoutRequest>............................... 267 C.6 <LogoutResponse>............................... 267 C.7 <SOAP-Skjelett>................................ 267 D Teknologier 269 D.1 Utviklingsplattform............................... 270 D.1.1 J2EE................................... 270 D.1.2.NET................................... 271 D.1.3 Sammenlikning............................. 272 D.2 Utviklingsverktøy................................ 273 D.2.1 Tekst- og dokumentbehandling.................... 273 D.2.2 Utviklingsmiljø............................. 275 D.2.3 Versjonskontroll............................. 278 D.3 Databasehåndteringssystem (DBHS)..................... 279 D.3.1 Aktuelle databaseløsninger...................... 279 D.3.2 Konklusjon............................... 279 D.4 Maskinvare og operativsystem........................ 280 D.4.1 Microsoft Windows........................... 280 D.4.2 Linux................................... 281 D.4.3 Konklusjon............................... 281 D.5 Nettleser..................................... 282 D.5.1 Aktuelle nettlesere........................... 282 D.5.2 Tabellarisk sammenligning av forskjellige nettlesere........ 283 E Testvedlegg 285 E.1 Feilrapporteringsskjema............................ 286 E.2 Sjekkliste ved inspeksjon av kode....................... 287 F Tekstlige Use Case 289 G Betraktninger rundt bruk av flere IDPe 297 H Programmeringsstandard 299 H.1 Generelle programmeringsnormer...................... 300 H.2 Navngiving................................... 300 H.3 Blanke linjer/mellomrom........................... 300 H.4 Deklarasjoner og utsagn............................ 301 H.4.1 JSP.................................... 301 H.4.2 Konstruksjon.............................. 301 INNHOLD ix
I Kommentering og dokumentasjon 303 I.1 Kommentering................................. 304 I.2 Javadoc...................................... 304 J Eksempler på bruk av programmeringsstandard 305 J.1 Java........................................ 306 J.2 JSP........................................ 311 K Ordliste 315 K.1 Ordliste...................................... 316 L Referanser 321 x INNHOLD
Figurer 1.1 Gantt-diagram som viser faser og varighet................. 5 1.2 Katalogstruktur på BSCW........................... 11 2.1 Figuren viser WSSO med Identity Provider og Service Providere..... 25 2.2 Figuren WSSO med kun Service Providere................. 26 2.3 APM-diagram som viser bruk av Web Single Sign-on........... 32 2.4 Kontrollflyt assosiert med prosessen for endring av nettsted....... 33 2.5 Overordnet dataflyt diagram for Web Single Sign-on............ 34 2.6 0. nivås dataflyt-diagram for Web Single Sign-on.............. 35 2.7 Dekomponering av Bruk -prosessen.................... 36 2.8 Dekomponering av Registrere -prosessen................. 37 2.9 Single Sign-on.................................. 42 2.10 Videresending mellom SP og IDP via brukeren............... 46 2.11 Utlogging fra en Identity Provider...................... 47 2.12 Utlogging fra en Service Provider....................... 47 2.13 Meldingssti................................... 52 2.14 PKIX-arkitekturen................................ 61 3.1 Use Caset UC-0................................. 70 3.2 Use Casene UC-1 og UC-2........................... 71 3.3 Use Casene UC-2 og UC-3........................... 71 3.4 Use Casene UC-4, UC-1 og UC-2....................... 72 3.5 Use Caset UC-5................................. 73 3.6 Use Caset UC-6................................. 74 4.1 Overordnet Libertyarkitektur......................... 118 4.2 Sekvensdiagram for brukeropplevelsen................... 121 4.3 basis-sti...................................... 127 4.4 Global utlogging................................ 129 4.5 Koble av nøkkelring.............................. 130 4.6 UML-klassediagram for wsso.sp-pakken.................. 132 4.7 Steg 2 i basis-sti, APM-notasjon........................ 135 4.8 Steg 8 i basis-sti, APM-notasjon........................ 137 4.9 Steg 2 i Single Logout-sti, APM-notasjon................... 138 4.10 Steg 6 i Single Logout sti, APM-notasjon................... 139 4.11 Steg 2 i Kople av nøkkelring-sti, APM-notasjon............... 140 xi
4.12 DB-diagram som viser databasen hos Service Provider.......... 141 4.13 UML-klassediagram for wsso.idp-pakken................. 143 4.14 APM-diagram som viser hvordan brukerautentisering foregår hos IDP. 147 4.15 APM-diagram som viser hvordan artefaktoppslaget foregår hos IDP.. 149 4.16 Steg 4 i Single Logout-sti, APM-notasjon................... 150 4.17 Steg 4 i Kople av nøkkelring-sti, APM-notasjon............... 152 4.18 DB-diagram som viser databasen hos Identity Provider.......... 153 4.19 UML-klassediagram for wsso.misc-pakken................ 155 6.1 WSSO-ikonet................................... 196 6.2 Eksempel på en Service Provider startside.................. 196 6.3 For å bruke WSSO må man logge inn med nøkkelring........... 197 6.4 Brukeren har nå tilgang til beskyttet område hos SP............ 197 6.5 For å bruke WSSO må man logge inn med nøkkelring........... 198 6.6 Bruker må logge inn lokalt først, før SP kan legges til på nøkkelringen. 198 6.7 Brukeren har nå tilgang til beskyttet område hos SP............ 199 6.8 For å bruke WSSO må man logge inn med nøkkelring........... 200 6.9 Bruker må registreres hos SP før SP kan legges til på nøkkelringen.... 200 6.10 Brukeren registrerer seg og setter automatisk SP på sin nøkkelring... 201 6.11 Brukeren har nå tilgang til beskyttet område hos SP............ 201 6.12 For å bruke WSSO må man logge inn med nøkkelring........... 202 6.13 Bruker må logge inn hos IDP for å bruke WSSO.............. 202 6.14 Brukeren har nå tilgang til beskyttet område hos SP............ 203 6.15 For å bruke WSSO må man logge inn med nøkkelring........... 204 6.16 Bruker må registrere seg hos IDP for å bruke WSSO............ 204 6.17 Brukeren registrerer seg. Nøkkelring opprettes............... 205 6.18 Brukeren har nå tilgang til beskyttet område hos SP............ 205 6.19 For å bruke WSSO må man logge inn med nøkkelring........... 206 6.20 Bruker må registrere seg hos IDP for å bruke WSSO............ 206 6.21 Brukeren registrerer seg. Nøkkelring opprettes............... 207 6.22 Bruker må registreres hos SP før SP kan legges til på nøkkelringen.... 207 6.23 Brukeren registrerer seg............................ 208 6.24 Brukeren har nå tilgang til beskyttet område hos SP............ 208 6.25 Global utlogging gjøres ved å trykke på lenken for global utlogging... 209 6.26 Bruker får bekreftelse på at han er logget ut globalt............ 209 7.1 V-test....................................... 213 7.2 Globalt syn på testprosess........................... 214 7.3 Oversikt over tidsplan for testing....................... 215 7.4 Moduler..................................... 216 8.1 Gantt-diagram som viser faser og varighet................. 242 8.2 Sammenligning av tid planlagt og tid brukt................. 243 G.1 Figuren viser arkitektur der alle SPe også er IDPe............. 298 xii FIGURER
Tabeller 1.1 Programvare som brukes i prosjektet..................... 12 1.2 Eksempel på risikotabell pr. 5. september.................. 16 1.3 Responstider................................... 19 2.1 Liberty sikkerhetsmekanismer......................... 45 2.2 Komponenter i Liberty-arkitekturen..................... 45 2.3 Sammenligning av J2EE og.net....................... 48 2.4 Evaluering av Java og.net.......................... 49 2.5 Pris på servere for webtjenester........................ 50 2.6 Sammenlikning av webservere........................ 51 2.7 Sammenlikning av SOAP-implementasjoner................ 56 2.8 De ulike komponentene i PKIX-arkitekturen................ 62 2.9 Valg av løsning................................. 63 3.1 Aktør 1: Bruker................................. 68 3.2 Aktør 2: Service Provider............................ 68 3.3 Aktør 3: Identity Provider........................... 69 3.4 Kortfattet oversikt over de funksjonelle kravene som stilles til WSSO.. 75 3.5 Krav FK-G1: Implementasjon av to SPe................... 76 3.6 Krav FK-G2: Implementasjon av én IDP................... 76 3.7 Krav FK-S1: SPs nettside............................ 77 3.8 Krav FK-S2: SPs brukerdatabase....................... 77 3.9 Krav FK-S3: SPs registreringsprosess..................... 78 3.10 Krav FK-S4: SPs autentiseringsprosess.................... 78 3.11 Krav FK-S5: IDPs nettside........................... 78 3.12 Krav FK-S6: IDPs brukerdatabase....................... 79 3.13 Krav FK-S7: IDPs registreringsprosess.................... 79 3.14 Krav FK-S8: IDPs autentiseringsprosess................... 79 3.15 Krav FK-S9: Opprette nøkkelring....................... 80 3.16 Krav FK-S10: Legge til SP i nøkkelring.................... 80 3.17 Krav FK-S11: Single Sign-on (én sesjon)................... 80 3.18 Krav FK-S12: Single Sign-on (to sesjoner).................. 81 3.19 Krav FK-S13: Single Logout ved IDP..................... 81 3.20 Krav FK-S14: Single Logout ved SP...................... 81 3.21 Krav FK-S15: Lokal utlogging I........................ 81 3.22 Krav FK-S16: Lokal utlogging II........................ 82 xiii
3.23 Krav FK-S17: Koble SP av nøkkelring.................... 82 3.24 Krav FK-S18: Terminering av nøkkelring................... 82 3.25 Krav FK-B1: Forespørsel om å opprette nøkkelring/legge SP....... 83 3.26 Krav FK-B2: Avvise/godkjenne oppretting av nøkkelring/legge til SP. 83 3.27 Krav FK-B3: Melding om at SP er lagt til i nøkkelring........... 84 3.28 Krav FK-B4: Avvise at SP blir lagt til i nøkkelring.............. 84 3.29 Krav FK-B5: Utlogging............................. 84 3.30 Krav FK-B6: Melding ved global utlogging................. 85 3.31 Krav FK-B7: Bekreftelse på at SP er tatt bort fra nøkkelringen....... 85 3.32 Oversikt over hvilke funksjonelle krav som hører til hvilket Use Case.. 87 3.33 Kortfattet oversikt over de ikke-funksjonelle kravene som stilles til WSSO 89 3.34 Krav til portabilitet............................... 90 3.35 Krav IFK-PO1: Maskinvareportabilitet.................... 90 3.36 Krav IFK-PO2: Operativsystemportabilitet................. 91 3.37 Krav IFK-PO3: Database- og nettportabilitet................. 91 3.38 Krav IFK-PO4: Applikasjonsserverportabilitet............... 91 3.39 Krav til sikkerhet................................ 92 3.40 Krav IFK-S1: Kryptering av sensitiv informasjon.............. 92 3.41 Krav IFK-S2: Tilgang til en innlogget brukers data............. 93 3.42 Krav IFK-S3: Tilgangskontroll til en Service Providers adm. rettigheter. 93 3.43 Krav IFK-S4: Tilgangskontroll til en Identity Providers adm. rettigheter. 93 3.44 Krav til ytelse.................................. 94 3.45 Krav IFK-Y1: Tid for å legge en SP i en nøkkelring............. 94 3.46 Krav IFK-Y2: Tid for utlogging........................ 94 3.47 Krav IFK-Y3: Ta ut SP fra nøkkelring..................... 95 3.48 Krav til pålitelighet............................... 96 3.49 Krav IFK-P1: Tilgjengelighet.......................... 96 3.50 Krav IFK-P2: Robusthet............................ 97 3.51 Krav til gjenbruk................................ 98 3.52 Krav IFK-GB1: Koden følger Kantegas kodestandard........... 98 3.53 Krav IFK-GB2: Utfyllende JavaDoc...................... 98 3.54 Krav IFK-GB3: Utvidbar kode......................... 99 3.55 Krav IFK-GB4: Uskiftbar kode......................... 99 3.56 Krav til brukerdokumentasjon......................... 100 3.57 Krav IFK-BD1: Lett tilgjengelig........................ 100 3.58 Krav IFK-BD2: Grundig............................ 100 3.59 Krav IFK-BD3: Oppdatert........................... 101 3.60 Krav IFK-I1: Installasjonsveiledning..................... 102 3.61 Krav til brukeropplevelse........................... 103 3.62 Krav IFK-BO1: Kontroll............................ 103 3.63 Krav IFK-BO2: Forenklende.......................... 103 3.64 Krav IFK-BO3: Nytenkende.......................... 104 3.65 Krav til brukergrensesnitt........................... 105 3.66 Krav IFK-BG1: Enkelt å bruke......................... 105 3.67 Krav IFK-BG2: Estetisk tiltrekkende..................... 106 3.68 Krav IFK-BG2: Feilfritt............................. 106 xiv TABELLER
3.69 Krav IFK-BG4: Diskret............................. 106 3.70 Krav IFK-BG5: Portabelt............................ 106 3.71 Krav IFK-BG6: Gjenkjennbart......................... 107 3.72 Krav til trygghet................................. 108 3.73 Krav IFK-TR1: Oversiktlig........................... 108 3.74 Krav IFK-TR2: Sikkert............................. 108 3.75 Krav IFK-TR3: Dokumentert.......................... 109 3.76 Aktører kategorisert etter kompleksitet................... 111 3.77 Use Case kategorisert etter kompleksitet................... 111 3.78 Vekting og rangering av tekniske faktorer.................. 112 3.79 Vekting og rangering av miljøfaktorer.................... 113 5.1 Tabell Bruker hos Service Provider...................... 185 5.2 Tabell Bruker hos Identity Provider...................... 185 5.3 Tabell Foderasjon hos Identity Provider................... 185 5.4 Tabell SP hos Identity Provider........................ 186 6.1 Krav til installasjonsveiledning........................ 189 6.2 Oversikt over nødvendige biblioteker.................... 191 7.1 Kortfattet oversikt over de funksjonelle kravene som stilles til WSSO.. 218 7.2 Systemtest 1 Registrering av bruker.................... 218 7.3 Systemtest 2 Pålogging lokalt....................... 218 7.4 Systemtest 3 Etablering av nøkkelring.................. 219 7.5 Systemtest 4 Pålogging globalt....................... 219 7.6 Systemtest 5 Legge til SPe i nøkkelringen................. 219 7.7 Systemtest 6 Single Sign-on......................... 220 7.8 Systemtest 7 Single Logout......................... 220 7.9 Systemtest 8 Terminere nøkkelringer/fjerne SPe fra nøkkelring.... 220 7.10 Testlogg...................................... 221 7.11 Testlogg for systemtest 1 Registrering av bruker............. 222 7.12 Feilrapporteringsskjema F1.......................... 222 7.13 Testlogg for systemtest 2 Pålogging lokalt................ 223 7.14 Feilrapporteringsskjema F2.......................... 223 7.15 Testlogg for systemtest 3 Etablering av nøkkelring........... 224 7.16 Feilrapporteringsskjema F3.......................... 224 7.17 Feilrapporteringsskjema F4.......................... 225 7.18 Feilrapporteringsskjema F5.......................... 225 7.19 Feilrapporteringsskjema F6.......................... 225 7.20 Testlogg for systemtest 4 Pålogging globalt................ 226 7.21 Feilrapporteringsskjema F7.......................... 226 7.22 Testlogg for systemtest 5 Legge til SPe i nøkkelringen......... 227 7.23 Testlogg for systemtest 6 Single Sign-on................. 228 7.24 Testlogg for systemtest 7 Single Logout.................. 229 7.25 Feilrapporteringsskjema F8.......................... 229 7.26 Testlogg for systemtest 8 Terminere nøkkelring............. 231 7.27 Feilrapporteringsskjema F9.......................... 231 TABELLER xv
7.28 Feilrapporteringsskjema F10.......................... 231 D.1 Sammenlikning av tekst- og dokumentbehandlingssystem........ 275 D.2 Sammenlikning av de ulike IDEene...................... 278 D.3 Oversikt over nettlesere og standarder.................... 283 D.4 De forskjellige evalueringskriteriene er vektet fra 1 5 der 5 er best... 284 E.1 Feilrapporteringsskjema............................ 286 F.1 UC-0: Registrering av bruker......................... 290 F.2 UC-1: Pålogging................................. 291 F.3 UC-2: Etablering av en nøkkelring...................... 292 F.4 UC-3: Legge til SP i en nøkkelring...................... 293 F.5 UC-4: Single Sign-on brukeropplevelse.................... 294 F.6 UC-5: Single Logout.............................. 295 F.7 UC-6: Terminering av nøkkelring/fjerne SPe fra nøkkelring....... 296 xvi TABELLER
Kapittel 1 Prosjektdirektiv 1
1.1 Innledning Kort om bakgrunnen for prosjektet og om dette dokumentet. 1.1.1 Bakgrunnen for prosjektet Kantega anser seg selv som et ledende konsulentmiljø innenfor sikkerhetsløsninger. De ønsker å utvikle en løsning basert på et rammeverk for åpen, føderert nettverksidentitet: Project Liberty. Project Liberty gir mulighet for å realisere Web Single Sign-on (WSSO). WSSO er et system som støtter bruk av forskjellige identiteter, med kun én enkelt brukerverifisering. Dette vil si at for eksempel Ola Nordmann med brukernavn olanord logger seg inn på en nettside. Dersom Ola nå går over til en annen nettside så er han allerede logget inn med en annen identitet Ola Nordmann kan for eksempel ha brukernavn ola på den andre nettsiden. En forutsetning er selvfølgelig at de to nettsidene er med i samme føderasjon. Kantega ønsker seg en fungerende prototyp som de kan demonstrere for kunden. De ønsker mer kunnskap om teknologiene som er en del av Project Liberty og et kodeverk som er utviklet for gjenbruk. 1.1.2 Om prosjektdirektivet Prosjektdirektivet er laget for å koordinere prosjektforløpet for Web Single Sign-on gjennom hele prosjektperioden. Dokumentet skal også være et hjelpemiddel for det videre arbeidet og for administreringen av prosjektet. Prosjektdirektivet er et dynamisk dokument som blir endret kontinuerlig under prosjektets livsløp. I avsnitt 1.2 beskrives bakgrunnen for prosjektet, oppdragsgivere, mål, rammebetingelser, økonomi og tid i forhold til prosjektet. Avsnitt 1.3 viser en overordnet prosjektplan, med estimering av timer og milepæler innenfor hver prosjektfase. Organiseringen av gruppa er beskrevet i avsnitt 1.4. Her beskrives ansvarsområdet til de ulike gruppemedlemmene. Maler og standarder er beskrevet i avsnitt 1.5, mens rutiner i forbindelse med oppfølging og kvalitetssikring blir beskrevet henholdsvis i avsnitt 1.6 og 1.7. 2 1.1. INNLEDNING
1.2 Prosjektmandat Her følger en kort oversikt over prosjektet. 1.2.1 Prosjektnavn Prosjektet har fått navn Web Single Sign-on. 1.2.2 Prosjektsponsor Oppdragsgiver for prosjektet er Kantega. 1.2.3 Effektmål Med effektmål menes den effekten som skal oppnås med prosjektet. Effektmålene er som følger: Øke kundens kunnskap om ny teknologi, spesielt innenfor Project Liberty. Gi brukerne så mye kontroll over systemet at de føler seg trygge. Redusere videre utviklingstid og -kostnader ved at kode kan gjenbrukes. 1.2.4 Resultatmål Med resultatmål menes de leveransene som prosjektet skal overlevere til kunden og brukerne. Leveransene er de resultatene som må produseres for at effektmålene skal oppnås. Resultatmålene er som følger: Prototyp som Kantega kan vise for sine kunder. Denne skal vise både styrker og svakheter ved løsningene til Project Liberty. Dokumentert og oversiktlig kode som er skrevet for gjenbruk. Produktet må kunne integreres i eksisterende løsninger. Man skal blant annet kunne benytte eksisterende brukerdatabaser i bunn. Se også avsnitt 1.1.1. 1.2.5 Omfang Prosjektet skal levere et forstudie og kravspesifikasjon i løpet av prosjektperioden. Prosjektet skal resultere i en fungerende prototype, dokumentasjon av både kode og 1.2. PROSJEKTMANDAT 3
prototype, og en rapport. Rapporten skal ha følgende kapitler: Prosjektdirektiv (kapittel 1), Forstudie (kapittel 2), Kravspesifikasjon (kapittel 3), Konstruksjon (kapittel 4), Implementasjonsspesifikasjon (kapittel 5), Dokumentasjon (kapittel 6), Testdokument (kapittel 7) og Prosjektevaluering (kapittel 8). I tillegg skal prosjektet ha en presentasjon og demonstrasjon. 1.2.6 Rammebetingelser Ukentlige møter på 1 time med hovedveileder. Gruppa har fått en datamaskin reservert for prosjektet. Utskriftskvote på 3500 sider. Prosjektet skal utvikles i Java og benytte seg av XML, Axis, SOAP, Tomcat og ellers holde seg innenfor Project Libertys rammer. 1.2.7 Økonomi 2184 timer fordelt på 7 gruppemedlemmer og 13 uker. Prosjektgruppa har i utgangspunktet ingen økonomiske midler til disposisjon. 1.2.8 Tid Prosjektperioden starter 19.08.2003 og resultatet skal være ferdig 13.11.2003. Det skal også være en preleveranse av forstudie og kravspesifikasjon den 23.10.2003. Presentasjon av resultatet er den 13.11.2003 kl. 14.15 i ITS-222. 4 1.2. PROSJEKTMANDAT
1.3 Prosjektplan Figur 1.1 viser diagrammet med faser og planlagt varighet. Figur 1.1: Gantt-diagram som viser faser og varighet Det beregnes en arbeidsinnsats på 24 timer per gruppemedlem per uke. Preleveranse av forstudie og kravspesifikasjon skal leveres sensor senest 23. oktober. 1.3.1 Beskrivelse av fasedokumentene I de påfølgende avsnittene vil en del individuelle krav til innhold og funksjon i de ulike fasedokumentene bli presentert. Først i hvert fasedokument skal det opprettes en logg som inneholder endringer, og av hvem og når endringen ble utført. 1.3.1.1 Prosjektdirektiv Ansvarlig: Erik Prosjektdirektivet regulerer den administrative biten av prosjektet og legger føringer for prosjektgjennomføringen. Prosjektmandat, prosjektplan, roller, maler, prosjektoppfølging og kvalitetssikring vil være etablert i dette dokumentet. 1.3.1.2 Forstudie Ansvarlig: Anders Utforsking av problemområdet og løsningsområdet vil ha sin plass i forstudiet. Eksisterende og fremtidige løsninger vil bli presentert, og vil gi nok beskrivelse av de teknologiene som skal benyttes til å gi leseren forståelse for hvilke valg av løsninger som gjøres. 1.3. PROSJEKTPLAN 5
1.3.1.3 Kravspesifikasjon Ansvarlig: Bjørn Erik Dokumentet skal innholde funksjonelle og ikke-funksjonelle krav til systemet. Kravspesifikasjonen vil være en slags kontrakt mellom prosjektgruppa og kunden. Kravspesifikasjonen skal inneholde en overordnet programvarearkitektur som viser hvordan programvarekomponenter og fysiske komponenter henger sammen. En overordnet testplan som legger grunnlaget for den videre testplanleggingen og -gjennomføringen utarbeides også i denne fasen. 1.3.1.4 Konstruksjon Ansvarlig: Sverre Overgangen mellom kravspesifikasjon og implementasjon vil bli beskrevet, og hvordan man kommer fra en overordnet systembeskrivelse ned til en realiserbar spesifikasjon. Detaljnivået er høyt nok til at man vet at det lar seg gjøre å programmere dette på denne måten, og planlegge programmeringsfasen og den videre gjennomføringen. Det kan være aktuelt å beskrive enkelte løsninger ved hjelp av pseudokode i dette dokumentet. 1.3.1.5 Implementasjonsspesifikasjon Ansvarlig: Erik Hvordan krav og konstruksjonen er blitt implementert vil bli forklart i implementasjonsspesifikasjonen. Implementasjonsspesifikasjonen vil inneholde standard for kode og kommentering. I tillegg finnes det her eksempler på hvordan standard for kode og kommentering fungerer i praksis, og eksempler på hvordan spesielle algoritmer er blitt programmert. Installasjons- og brukerveiledning finnes i et eget fasedokument. 1.3.1.6 Dokumentasjon Ansvarlig: Kaare Installasjonsveiledningen som utarbeides skal være god nok til at kunden klarer å installere systemet på egen hånd. Brukerveiledningen lages med tanke på at sluttbrukerne skal kunne bruke systemet i praksis. Installasjons- og brukerveiledningen er fullstendig nok til at kunden kan sette opp og ta i bruk systemet på egen hånd. Både installasjons- og brukerveiledningen blir kvalitetssikret av veilederne i prosjektet. Dette gjøres som en ekstra garanti til kunden. 1.3.1.7 Testdokument Ansvarlig: Magnus En plan for testing blir utviklet i løpet av flere faser. Overordnet testplan lages i krav- 6 1.3. PROSJEKTPLAN
spesifikasjonsfasen. Denne testplanen danner grunnlaget for testplanlegging og -gjennomføring. Detaljerte testspesifikasjoner lages i løpet av konstruksjonsfasen. Underveis i implementasjonsfasen blir det laget testrapport som viser resultatet av testingen. 1.3.1.8 Prosjektevaluering Ansvarlig: Sverre Dokumentet beskriver evaluering av prosessen, resultatet, kunden, oppgaven og faget. Det vil også bli gitt et estimat av hvor mye arbeid som gjenstår før produktet er ferdig. 1.3.1.9 Presentasjon og demonstrasjon Denne fasen vil ikke resultere i noe fasedokument, men en presentasjon som vises den 13.11.2003. 1.3. PROSJEKTPLAN 7
1.4 Organisering av gruppa Prosjektleder/Arkitekt: Sverre Sende ut møteinnkalling (ikke kundemøte). Møteleder/ordstyrer på møter. Skriver statusrapport hver uke. Delegering av oppgaver som ingen vil ta. Sørge for overholding av tidsfrister. TROKK. Kontakt med veileder. Ansvarlig for prosjektets framdrift (milepæler og tidsfrister). Konstruktør. Utforming av UML for datastruktur og implementasjon. Rammeverk, pakkestruktur og patterns. Konstruksjonen skal være mulig å implementere. Alle skal forstå konstruksjonen. Kundekontakt: Bjørn-Erik Sørge for at kunden vet og er enig med det vi gjør. Sørge for at vi forstår hva kunden vil. All kontakt mellom kunden og gruppen skal gjennom kundekontakten. Sende ut møteinnkalling til kundemøter. Ansvarlig for kravspesifikasjonsdokumentet og Use Cases. Konfigurasjonsansvarlig: Erik Skal sørge for at de som utvikler kan gjøre jobben sin effektivt. Administrator for CVS. Lage revisjoner og versjoner som legges ut på BSCW. Konfigurasjon av utviklingsmiljø (IDE, servere og slikt). L A TEX. 8 1.4. ORGANISERING AV GRUPPA
Testansvarlig: Magnus Ansvarlig for at vi har måter å finne ut om produktet er i overensstemmelse med kravene. Utforming av tester, testscript og testplan. Sørge for at testene er i henhold til kravene. Ansvarlig for gjennomføring av testene (at testene blir gjort, gjort riktig og at riktige personer gjør dem). Ansvarlig for risikooversikt. Dokumentasjonsansvarlig: Kaare Brukerens beskyttende engel. Ansvarlig for brukergrensesnittet. Ansvarlig for brukeropplevelsen. Ansvarlig for dokumentasjon og installasjonsveiledning. Sekretær: Anders Skriver møtereferat. Timeregistrering. Tar med nødvendige dokumenter til møter. Maler. Nestleder. 1.4. ORGANISERING AV GRUPPA 9
1.5 Maler og standarder Under følger en oversikt over maler og standarder som skal brukes i prosjektet. 1.5.1 Generelt Ordinære dokumenter skrives i L A TEX. Alle dokumenter skal følge de maler og standarder som angitt i dette dokumentet. 1.5.2 Fasedokumenter Samtlige fasedokumenter skal inngå som kapitler i prosjektrapporten. Innholdsfortegnelse for hele prosjektrapporten skal ligge i begynnelsen, og tillegg og referansedel skal ligge i slutten av rapporten. 1.5.2.1 Skrifttyper Formatet på skrifttyper i dette dokumentet er de som er standardene i L A TEX. Vi har valgt å bruke document class report, med skriftstørrelse 12 punkt. 1.5.2.2 Tabeller Formatet på tabeller er også i henhold til den standarden som L A TEX report dokumentklasse definerer. Alle tabeller skal ha en tabelltekst i henhold til denne standarden. 1.5.3 Dokumentmaler Det er blitt utarbeidet maler for følgende dokumenter: Møteinnkalling med dagsorden til gruppemøte. Møteinnkalling med dagsorden til kundemøte. Møteinnkalling med dagsorden til veiledermøte. Møtereferat fra gruppmøte. Møtereferat fra kundemøte. Møtereferat fra veiledermøte. Statusrapport. Malene er vedlagt i tillegg B. 10 1.5. MALER OG STANDARDER
1.5.4 Katalogstruktur Figur 1.2 viser hvordan fellesområdet på BSCW er ordnet i kataloger. Web Single Sign On Annet Dokumentasjon Kode Maler Møter Planlegging og Administrasjon Rapport Spesifikasjon Test Javadoc Systemdokumentasjon Teknologi- Sammendrag Møteinnkalling Møtereferat Fasedokumenter Prosjektfremdrift Timeoppfølging Systemtest Enhetstest Integrasjonstest Versjoner Internemøter Kundemøter Veiledermøter Design Forstudie GUI Kravspesifikasjon Use Cases Figur 1.2: Katalogstruktur på BSCW Katalogstruktur for implementasjons- og utviklingsfiler er ikke blitt opprettet. 1.5.5 Navngiving av filer Filnavn skal være så beskrivende som mulig. Med unntak av møteinnkallinger og - referater er det ikke laget noen føringer på hvordan filnavn skal være. Møteinnkallinger og -referater navngives henholdsvis innkalling type mnd dag og referat type mnd dag. 1.5.6 Sikkerhetskopi IDI tar sikkerhetskopi av dokumenter som ligger på BSCW i tilfelle uforutsette hendelser som harddiskkrasj. Gruppa tar sikkerhetskopi av dokumenter som ligger på BSCW daglig i tilfelle noe blir slettet/endret ved en feil. 1.5.7 Litteraturhenvisninger Til litteraturhenvisninger i prosjektrapporten brukes Bibtex. Dette gjør at litteraturhenvisningslista genereres automatisk. Alle litteraturhenvisninger i rapporten står i klammeparenteser ([]). 1.5. MALER OG STANDARDER 11
1.5.8 Versjonskontroll og dokumenthåndtering BSCW brukes for dokumenthåndtering av ordinære, ferdige dokumenter. For å unngå tap av data er det viktig at låsing benyttes når man arbeider på et dokument som ligger på BSCW. BSCW har også en enkel form for versjonskontroll som brukes på dokumenter som oppdateres jevnlig gjennom hele prosjektet. CVS brukes for versjonskontroll av program- og implementasjonsfiler og alle filer skrevet i L A TEX. 1.5.9 Programvare I tabell 1.5.9 står det en oversikt over hvilke programmer, applikasjoner og tjenere som skal brukes i løpet av prosjektet. Navn Kilde for installasjon og veiledning Apache Tomcat Apache Tomcat har åpen kildekode og finnes tilgjengelig på http://jakarta.apache.org/site- /binindex.cgi for gratis nedlasting. Veiledning finnes på http://jakarta.apache.org/tomcat/tomcat- 5.0-doc/index.html. Axis Axis har åpen kildekode og finnes tilgjengelig på http://ws.apache.org/axis/dist/1 1/ for gratis nedlasting. Installasjonsveiledning finnes på http://- cvs.apache.org/viewcvs/ checkout /ws-axis/java- /docs/install.html På http://ws.apache.org/axis/ finnes også linker til User s Guide, Developer s Guide, Integration Guide, Architecture Guide, Reference Guide og Reading Guide. OpenSAML OpenSAML har åpen kildekode og finnes tilgjengelig på http://wayf.internet2.edu/shibboleth/opensamljava-0.9.tar.gz for gratis nedlasting. API JavaDoc dokumentasjonen finnes på http://wayf.internet2.edu- /opensaml/java/doc/api/. L A TEX L A TEX har åpen kildekode og finnes tilgjengelig fra mange forskjellige ressurser på Internett. Se på http://www.latex-project.org/ftp.html for instruksjoner for hvordan en får tak i L A TEX. Tabell 1.1: Programvare som brukes i prosjektet 12 1.5. MALER OG STANDARDER
1.6 Prosjektoppfølging Avsnittet viser hvordan prosjektet følges opp fra uke til uke. 1.6.1 Prosjektmøter Under følger en oversikt over de ulike møtetypene i prosjektet. 1.6.1.1 Interne møter Interne møter holdes hver tirsdag 12.15 14.00 og 16.15 19.00 fra prosjektstart til og med uka før presentasjon. Mal for møteinnkallelse til internmøter finnes i tillegg B.1, og mal for møtereferat fra internmøter finnes i tillegg B.4. 1.6.1.2 Kundemøter Kundemøtene vil i all hovedsak foregå i Kantegas lokaler. Hyppigheten på kundemøtene vil sannsynligvis varigere avhengig av hvilken fase vi er inne i. For eksempel vil vi ha behov for ett møte i uken i kravspesifikasjonsfasen og noe sjeldnere i andre faser. Hovedregelen er at kundemøtene skal finne sted når det er behov for det. Møtene vil hovedsaklig omhandle diskusjon rundt oppgaven og kravene kunden har til systemet. I tillegg vil forslag til løsninger bli diskutert, og eventuelle problemer og misforståelser vil bli tatt opp og diskutert. Møteinnkallelse til kunden skal inneholde: Tid, sted og varighet. Agenda for møtet. Forberedelser gruppa ønsker at kunden skal gjøre. Nødvendige bakgrunnsdokumenter. Referat fra møtet skal sendes kunden senest klokka 12.00 neste dag. Møtereferatet skal inneholde avklaringer og beslutninger som ble tatt på møtet i tillegg til aksjoner og hvordan disse skal behandles. Møtereferatet skal godkjennes av kunden. Mal for møteinnkallelse til kundemøter finnes i tillegg B.2, og mal for møtereferat fra kundemøter finnes i tillegg B.5. 1.6. PROSJEKTOPPFØLGING 13
1.6.1.3 Veiledermøter Møtet med hovedveileder, som i all hovedsak er obligatorisk for alle gruppemedlemmene, avholdes torsdag 10.15 11.00. På veiledermøtene vil statusrapporten bli lagt frem og kommentert, og fremdriften i prosjektet evaluert. Både hoved- og hjelpeveileder vil bistå med veiledning på disse møtene. Innkallelse til veiledermøter sendes ut senest klokka 12.00 dagen før møtet. Møteinnkallelsen skal inneholde agenda for møtet, referat fra forrige kundemøte og forrige veiledermøte, og statusrapport for prosjektet. Dersom materialet som er utarbeidet den siste uka ønskes distribuert, skal dette distribueres. Mal for møteinnkallelse til veiledermøter finnes i tillegg B.3, og mal for møtereferat fra veiledermøter finnes i tillegg B.6. 1.6.2 Internrapportering Timer Utførte og gjenstående timer skal oppdateres i løpet av mandag hver uke. Utførte timer gjelder fra mandag til søndag uken før rapportering. Oppgaver Utførte og gjenstående oppgaver blir rapportert til prosjektleder på internmøtene. 1.6.3 Statusrapportering Statusrapporten skal si noe om hva som har foregått i foregående periode, og hva som skal skje i neste periode. Oppdatert TROKK (se avsnitt 1.6.4) skal være en del av statusrapporten. Statusrapporten skal foreligge klokka 12.00 dagen før veiledermøtet, og skal godkjennes av hovedveileder. Mal for statusrapport finnes i tillegg B.7. 1.6.4 TROKK I de ukentlige statusrapportene vil det bli benyttet en fast mal på hovedpunktene Tid, Risikofaktorer, Omfang, Kostnad og Kvalitet (forkortet TROKK). I statusrapportene vil det bli angitt hvordan prosjektet ligger an i forhold til prosjektdirektivet for hvert punkt. 1.6.4.1 Tid Punktet beskriver hvordan gruppa ligger an fra uke til uke i forhold til planlagt tid. 14 1.6. PROSJEKTOPPFØLGING
1.6.4.2 Risikofaktorer Tabell 1.2 inneholder en oversikt over risikoer forbundet med prosjektet. Tabellen viser også hvilke aktiviteter som rammes, konsekvens for aktiviteten, sannsynligheten for at risikoen inntreffer, strategi og tiltak for å håndtere risiko, tidsfrist og ansvar. 1.6.4.3 Omfang Dersom omfanget av løsningen har minket eller økt den siste perioden vil dette bli beskrevet under dette punktet. 1.6.4.4 Kostnad/timer Regnearket inneholder fullstendig oversikt over timer brukt og timer estimert brukt. 1.6.4.5 Kvalitet Kvalitetsbegrepet vil beskrive om gruppa ser seg nødt til å øke eller redusere kvaliteten på det endelige produktet som følge av tidspress eller andre faktorer. 1.6. PROSJEKTOPPFØLGING 15
16 1.6. PROSJEKTOPPFØLGING Tabell 1.2: Eksempel på risikotabell pr. 5. september Nr Aktivitet Risikofaktor Konsekvens Sannsynlighet Strategi og tiltak Tidsfrist Ansvar 1 Forstudie og Misforståelser, vansk- H M Tett kommunikasjon med kunde 15.09.2003 Kundekontakt kravspesifikasjon eligheter i forholdet Vanskelig å tilfredsstille er nøkkel. mellom kunde/prosjekt- kundens krav. Kan måtte gjøre gruppe forstudie og kravspesifikasjon om igjen. 2 Kravspesifikasjon Motstridende ønsker M M Gi hovedkontaktpersonen ved 03.10.2003 Kundekontakt hos kontaktpersonene Vanskelig å vite hva kunden bedriften ansvaret for å oppved kundebedriften egentlig ønsker. klare uenigheter og motstridende ønsker. 3 Alle, unntatt Implementerer feil H M Grundigere forstudie. løpende Arkitekt prosjektdirektiv løsning Prosjektresultatet kan bli og prosjekt- forskjellig fra kundens evaluering ønsker. 4 Alle Fravær/sykdom M L Økt arbeidsmengde til gjen- løpende Alle Kvaliteten på prosjektres- værende gruppemedlemmer. ultatet blir lavere. 5 Alle Tidsoverskridelser M H Bedre planlegging, kontinu- løpende Prosjektleder ved leveringer Økt arbeidsmengde i kritiske erlig rapportering, høy fokus perioder. på jevn, hard jobbing. 6 Alle Interne problemer H M Interne møter, evt. kontakte løpende Prosjektleder Enkelte faser i prosjektet blir veileder. dårligere. 7 Konstruksjon, Tekniske problemer M M Prøve å finne alternative løpende Konfigurasjonsansvarlig implementasjon og Kan få problemer med å løsninger/verktøy. Kontakte Kundekontakt testing realisere tenkt funksjonalitet. veileder/kunde. Store potensielle økonomiske tap. 8 Forstudie, Maskinen er ikke M H Legge press på PC-ansvarlig. 15.09.2003 Alle konstruksjon, oppe ennå. Gruppa risikerer å komme sent Installere programvare på implementasjon og i gang med å prøve ut program- privat utstyr. testing varen. Økonomisk kostnad. Web Single Sign-on
1.7 Kvalitetssikring For å kunne definere hvordan gruppa skal sikre kvaliteten på prosjektet, må man definere hva kvalitet er. Gruppa definerer kvalitet på et prosjektarbeid ut ifra hvor fornøyd kunden, gruppa selv og veiledere er med det endelige produktet, rapporten og prosessen i seg selv. Innforstått i prosessen selv ligger blant annet det at gruppa ikke har overskredet budsjettet både timeverk og andre økonomiske ressurser for mye. Det som vil være avgjørende for kvaliteten på selve produktet ved dette prosjektet er at det skal implementeres en prototyp. Dvs. at man ønsker kun å vise noe av funksjonaliteten til et helt ferdigsystem. Det vil være åpninger for å ta noen snarveier der prototypen ikke trenger å vise noen funksjonalitet, men hvor et ferdig system er helt avhengig av denne. Det er også av avgjørende betydning at gruppa benytter seg av en utviklingsmodell som ligger svært nær en vannfalllsmodell. Vannfallsmodellen benyttes kort og godt fordi tiden som er til rådighet ikke er stor nok til å gjøre flere iterasjoner. Kvalitetssikring gjøres fortløpende, både internt på gruppa og eksternt av veiledere og kunde, for å vurdere og kontrollere gruppas arbeid. Hoveddelen av det prosjektgruppa produserer er dokumentasjon, så den viktigste delen av kvalitetssikringen vil ligge her. Ved vurdering av dokumentasjonsarbeidet vil følgende punkter være viktige: Språkføring. Alle fasedokumenter vil ha en redaktør pluss en annen person i gruppa som er ansvarlig for gjennomlesing og feilretting i dokumentet. Tidsfrister som blir satt skal overholdes. Dette er tidsfrister på fullføring av fasedokumenter, møteinnkallelser, skriving av møtereferat og responstider. Alle vil være ansvarlig for at de overholder de tidsfristene som er satt. 1.7. KVALITETSSIKRING 17