Web Single Sign-on. Prosjektgruppe november Institutt for Datateknikk og Informasjonsvitenskap. TDT4290 Kundestyrt Prosjekt

Transkript

1 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

2 ii Web Single Sign-on

3 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 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 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

4 Innhold 1 Prosjektdirektiv Innledning Bakgrunnen for prosjektet Om prosjektdirektivet Prosjektmandat Prosjektnavn Prosjektsponsor Effektmål Resultatmål Omfang Rammebetingelser Økonomi Tid Prosjektplan Beskrivelse av fasedokumentene Organisering av gruppa Maler og standarder Generelt Fasedokumenter Dokumentmaler Katalogstruktur Navngiving av filer Sikkerhetskopi Litteraturhenvisninger Versjonskontroll og dokumenthåndtering Programvare Prosjektoppfølging Prosjektmøter Internrapportering Statusrapportering TROKK Kvalitetssikring Responstider Rutiner iv

5 2 Forstudie Innledning Dagens Situasjon Om Kantega Oppgaven Dagens teknologi Dagens alternativer Forretningsmessige krav/avgrensinger Evalueringskriterier Beskrivelse av fremtidig løsning Arbeids- og informasjonsflyt Personvern Markedsundersøkelse Beskrivelse av teknologiske løsninger Webtjenester Project Liberty Utviklingsplattform Webserver Teknologier Maskinvare og utviklingsverktøy Valg av løsning Kravspesifikasjon Innledning Beskrivelse av systemet Hensikt med systemet Reelle aktører Funksjonelle krav Use Cases Funksjonelle krav til prosjektet WSSO Oppsummeringsscenario Ikke-funksjonelle krav Portabilitet Sikkerhet (Security) Ytelse Pålitelighet Gjenbruk av kode Brukerdokumentasjon Installasjonsveiledning Brukeropplevelse Evaluering av Libertys brukeropplevelse Arbeidsestimering Datagrunnlag Estimat for samtlige Use Case Estimat for høyt prioriterte Use Case Konklusjon for arbeidsestimering INNHOLD v

6 4 Konstruksjon Innledning Arbeidet med konstruksjon Overordnet systembeskrivelse Pakker i wsso Brukeropplevelsen Kommunikasjon HTTP Redirect SOAP XML-dokumenter Basis-sti Logout-sti Koble av nøkkelring-sti Service Provider Klassediagram Brukerautentiseringssjekk hos SP (steg 2 i basis-sti) Artefakthåndtering (steg 8 i basis-sti) Håndtering av global utlogging (steg 2 i Single Logout-sti) Prosesser Logout (steg 6 i Single Logout-sti) Prosesser deføderasjon (steg 2 i Kople av nøkkelring-sti) DB-diagram, Service Provider (SP) Identity Provider Klassediagram Brukerautentiseringssjekk (steg 5 i basis-sti) Artefaktoppslag (steg 10 i basis-sti) Prosesser Logout (steg 4 i Single Logout-sti) Prosesser deføderasjon (steg 4 i Kople av nøkkelring-sti) DB-diagram, Identity Provider (IDP) wsso.misc-pakken Klassediagram Implementasjonsspesifikasjon Innledning Arbeidet med implementasjon Eclipse CVS Tomcat web.xml Katalogstruktur Benyttede objekter i Tomcat-bibliotekene Axis deploy.wsdd Benyttede objekter i Axis-biblioteker OpenSAML Bruk av OpenSAML med Axis Benyttede objekter i OpenSAML-biblioteket vi INNHOLD

7 5.5 Bygging Ant build.xml build.properties Andre biblioteker dom3-xml-apis jar dom3-xercesimpl jar saaj.jar mysql-connector-java stable-bin.jar jaxrpc.jar Systemvariable sp.properties VariableHolder-klassen Service Providere Nettsidene Identity Provider Nettsidene Databaseimplementasjon Generelt Navnekonvensjoner Databaseoperasjoner Databaseskjema Dokumentasjon Innledning Installasjonsveiledning Systemkrav Installasjon Brukerveiledning Hva er WSSO? Hvorfor WSSO? Figurer Eksempler på mulige scenarier Testdokument Innledning Overordnet testplan Planlagte tester Klassifisering av feil og godkjenningskriterier Testpersonell og tidsplan Detaljerte testspesifikasjoner Enhetstesting Modultesting Systemtesting Testlogg Testlogg for systemtestene INNHOLD vii

8 8 Prosjektevaluering Innledning Formål med evalueringen Grunnlag for evalueringen Kunde, oppgave og gjennomføring Kunde Oppgave Gjennomføring Evaluering av faser Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon og implementasjonsspesifikasjon Dokumentasjon Testplan Prosjektevaluering Presentasjon og demonstrasjon Totalvurdering Måloppnåelse Tidsrammer og progresjon Tekniske aspekter Organisatoriske aspekter Hva har vi lært? Fagevaluering Faget som helhet Veiledere Forelesninger Seminarer og kurs Videre arbeid Mulige utvidelser Tidsanslag for å gjøre systemet ferdig A Interessenter 251 A.1 Kunde A.2 Veiledere A.2.1 Hovedveiledere A.2.2 Hjelpeveileder A.3 Prosjektgruppe B Maler 255 B.1 Møteinnkalling gruppemøte, gruppe B.2 Møteinnkalling kundemøte, gruppe B.3 Møteinnkalling veiledermøte, gruppe B.4 Referat gruppemøte, gruppe B.5 Referat kundemøte, gruppe viii INNHOLD

9 B.6 Referat veiledermøte, gruppe B.7 Statusrapport C XML-dokumenter 263 C.1 <AuthnRequest> C.2 <samlp:request> C.3 <samlp:response> C.4 <FederationTerminationNotification> C.5 <LogoutRequest> C.6 <LogoutResponse> C.7 <SOAP-Skjelett> D Teknologier 269 D.1 Utviklingsplattform D.1.1 J2EE D.1.2.NET D.1.3 Sammenlikning D.2 Utviklingsverktøy D.2.1 Tekst- og dokumentbehandling D.2.2 Utviklingsmiljø D.2.3 Versjonskontroll D.3 Databasehåndteringssystem (DBHS) D.3.1 Aktuelle databaseløsninger D.3.2 Konklusjon D.4 Maskinvare og operativsystem D.4.1 Microsoft Windows D.4.2 Linux D.4.3 Konklusjon D.5 Nettleser D.5.1 Aktuelle nettlesere D.5.2 Tabellarisk sammenligning av forskjellige nettlesere E Testvedlegg 285 E.1 Feilrapporteringsskjema E.2 Sjekkliste ved inspeksjon av kode F Tekstlige Use Case 289 G Betraktninger rundt bruk av flere IDPe 297 H Programmeringsstandard 299 H.1 Generelle programmeringsnormer H.2 Navngiving H.3 Blanke linjer/mellomrom H.4 Deklarasjoner og utsagn H.4.1 JSP H.4.2 Konstruksjon INNHOLD ix

10 I Kommentering og dokumentasjon 303 I.1 Kommentering I.2 Javadoc J Eksempler på bruk av programmeringsstandard 305 J.1 Java J.2 JSP K Ordliste 315 K.1 Ordliste L Referanser 321 x INNHOLD

11 Figurer 1.1 Gantt-diagram som viser faser og varighet Katalogstruktur på BSCW Figuren viser WSSO med Identity Provider og Service Providere Figuren WSSO med kun Service Providere APM-diagram som viser bruk av Web Single Sign-on Kontrollflyt assosiert med prosessen for endring av nettsted Overordnet dataflyt diagram for Web Single Sign-on nivås dataflyt-diagram for Web Single Sign-on Dekomponering av Bruk -prosessen Dekomponering av Registrere -prosessen Single Sign-on Videresending mellom SP og IDP via brukeren Utlogging fra en Identity Provider Utlogging fra en Service Provider Meldingssti PKIX-arkitekturen Use Caset UC Use Casene UC-1 og UC Use Casene UC-2 og UC Use Casene UC-4, UC-1 og UC Use Caset UC Use Caset UC Overordnet Libertyarkitektur Sekvensdiagram for brukeropplevelsen basis-sti Global utlogging Koble av nøkkelring UML-klassediagram for wsso.sp-pakken Steg 2 i basis-sti, APM-notasjon Steg 8 i basis-sti, APM-notasjon Steg 2 i Single Logout-sti, APM-notasjon Steg 6 i Single Logout sti, APM-notasjon Steg 2 i Kople av nøkkelring-sti, APM-notasjon xi

12 4.12 DB-diagram som viser databasen hos Service Provider UML-klassediagram for wsso.idp-pakken APM-diagram som viser hvordan brukerautentisering foregår hos IDP APM-diagram som viser hvordan artefaktoppslaget foregår hos IDP Steg 4 i Single Logout-sti, APM-notasjon Steg 4 i Kople av nøkkelring-sti, APM-notasjon DB-diagram som viser databasen hos Identity Provider UML-klassediagram for wsso.misc-pakken WSSO-ikonet Eksempel på en Service Provider startside For å bruke WSSO må man logge inn med nøkkelring Brukeren har nå tilgang til beskyttet område hos SP For å bruke WSSO må man logge inn med nøkkelring Bruker må logge inn lokalt først, før SP kan legges til på nøkkelringen Brukeren har nå tilgang til beskyttet område hos SP For å bruke WSSO må man logge inn med nøkkelring Bruker må registreres hos SP før SP kan legges til på nøkkelringen Brukeren registrerer seg og setter automatisk SP på sin nøkkelring Brukeren har nå tilgang til beskyttet område hos SP For å bruke WSSO må man logge inn med nøkkelring Bruker må logge inn hos IDP for å bruke WSSO Brukeren har nå tilgang til beskyttet område hos SP For å bruke WSSO må man logge inn med nøkkelring Bruker må registrere seg hos IDP for å bruke WSSO Brukeren registrerer seg. Nøkkelring opprettes Brukeren har nå tilgang til beskyttet område hos SP For å bruke WSSO må man logge inn med nøkkelring Bruker må registrere seg hos IDP for å bruke WSSO Brukeren registrerer seg. Nøkkelring opprettes Bruker må registreres hos SP før SP kan legges til på nøkkelringen Brukeren registrerer seg Brukeren har nå tilgang til beskyttet område hos SP Global utlogging gjøres ved å trykke på lenken for global utlogging Bruker får bekreftelse på at han er logget ut globalt V-test Globalt syn på testprosess Oversikt over tidsplan for testing Moduler Gantt-diagram som viser faser og varighet Sammenligning av tid planlagt og tid brukt G.1 Figuren viser arkitektur der alle SPe også er IDPe xii FIGURER

13 Tabeller 1.1 Programvare som brukes i prosjektet Eksempel på risikotabell pr. 5. september Responstider Liberty sikkerhetsmekanismer Komponenter i Liberty-arkitekturen Sammenligning av J2EE og.net Evaluering av Java og.net Pris på servere for webtjenester Sammenlikning av webservere Sammenlikning av SOAP-implementasjoner De ulike komponentene i PKIX-arkitekturen Valg av løsning Aktør 1: Bruker Aktør 2: Service Provider Aktør 3: Identity Provider Kortfattet oversikt over de funksjonelle kravene som stilles til WSSO Krav FK-G1: Implementasjon av to SPe Krav FK-G2: Implementasjon av én IDP Krav FK-S1: SPs nettside Krav FK-S2: SPs brukerdatabase Krav FK-S3: SPs registreringsprosess Krav FK-S4: SPs autentiseringsprosess Krav FK-S5: IDPs nettside Krav FK-S6: IDPs brukerdatabase Krav FK-S7: IDPs registreringsprosess Krav FK-S8: IDPs autentiseringsprosess Krav FK-S9: Opprette nøkkelring Krav FK-S10: Legge til SP i nøkkelring Krav FK-S11: Single Sign-on (én sesjon) Krav FK-S12: Single Sign-on (to sesjoner) Krav FK-S13: Single Logout ved IDP Krav FK-S14: Single Logout ved SP Krav FK-S15: Lokal utlogging I Krav FK-S16: Lokal utlogging II xiii

14 3.23 Krav FK-S17: Koble SP av nøkkelring Krav FK-S18: Terminering av nøkkelring Krav FK-B1: Forespørsel om å opprette nøkkelring/legge SP Krav FK-B2: Avvise/godkjenne oppretting av nøkkelring/legge til SP Krav FK-B3: Melding om at SP er lagt til i nøkkelring Krav FK-B4: Avvise at SP blir lagt til i nøkkelring Krav FK-B5: Utlogging Krav FK-B6: Melding ved global utlogging Krav FK-B7: Bekreftelse på at SP er tatt bort fra nøkkelringen Oversikt over hvilke funksjonelle krav som hører til hvilket Use Case Kortfattet oversikt over de ikke-funksjonelle kravene som stilles til WSSO Krav til portabilitet Krav IFK-PO1: Maskinvareportabilitet Krav IFK-PO2: Operativsystemportabilitet Krav IFK-PO3: Database- og nettportabilitet Krav IFK-PO4: Applikasjonsserverportabilitet Krav til sikkerhet Krav IFK-S1: Kryptering av sensitiv informasjon Krav IFK-S2: Tilgang til en innlogget brukers data Krav IFK-S3: Tilgangskontroll til en Service Providers adm. rettigheter Krav IFK-S4: Tilgangskontroll til en Identity Providers adm. rettigheter Krav til ytelse Krav IFK-Y1: Tid for å legge en SP i en nøkkelring Krav IFK-Y2: Tid for utlogging Krav IFK-Y3: Ta ut SP fra nøkkelring Krav til pålitelighet Krav IFK-P1: Tilgjengelighet Krav IFK-P2: Robusthet Krav til gjenbruk Krav IFK-GB1: Koden følger Kantegas kodestandard Krav IFK-GB2: Utfyllende JavaDoc Krav IFK-GB3: Utvidbar kode Krav IFK-GB4: Uskiftbar kode Krav til brukerdokumentasjon Krav IFK-BD1: Lett tilgjengelig Krav IFK-BD2: Grundig Krav IFK-BD3: Oppdatert Krav IFK-I1: Installasjonsveiledning Krav til brukeropplevelse Krav IFK-BO1: Kontroll Krav IFK-BO2: Forenklende Krav IFK-BO3: Nytenkende Krav til brukergrensesnitt Krav IFK-BG1: Enkelt å bruke Krav IFK-BG2: Estetisk tiltrekkende Krav IFK-BG2: Feilfritt xiv TABELLER

15 3.69 Krav IFK-BG4: Diskret Krav IFK-BG5: Portabelt Krav IFK-BG6: Gjenkjennbart Krav til trygghet Krav IFK-TR1: Oversiktlig Krav IFK-TR2: Sikkert Krav IFK-TR3: Dokumentert Aktører kategorisert etter kompleksitet Use Case kategorisert etter kompleksitet Vekting og rangering av tekniske faktorer Vekting og rangering av miljøfaktorer Tabell Bruker hos Service Provider Tabell Bruker hos Identity Provider Tabell Foderasjon hos Identity Provider Tabell SP hos Identity Provider Krav til installasjonsveiledning Oversikt over nødvendige biblioteker Kortfattet oversikt over de funksjonelle kravene som stilles til WSSO Systemtest 1 Registrering av bruker Systemtest 2 Pålogging lokalt Systemtest 3 Etablering av nøkkelring Systemtest 4 Pålogging globalt Systemtest 5 Legge til SPe i nøkkelringen Systemtest 6 Single Sign-on Systemtest 7 Single Logout Systemtest 8 Terminere nøkkelringer/fjerne SPe fra nøkkelring Testlogg Testlogg for systemtest 1 Registrering av bruker Feilrapporteringsskjema F Testlogg for systemtest 2 Pålogging lokalt Feilrapporteringsskjema F Testlogg for systemtest 3 Etablering av nøkkelring Feilrapporteringsskjema F Feilrapporteringsskjema F Feilrapporteringsskjema F Feilrapporteringsskjema F Testlogg for systemtest 4 Pålogging globalt Feilrapporteringsskjema F Testlogg for systemtest 5 Legge til SPe i nøkkelringen Testlogg for systemtest 6 Single Sign-on Testlogg for systemtest 7 Single Logout Feilrapporteringsskjema F Testlogg for systemtest 8 Terminere nøkkelring Feilrapporteringsskjema F TABELLER xv

16 7.28 Feilrapporteringsskjema F D.1 Sammenlikning av tekst- og dokumentbehandlingssystem D.2 Sammenlikning av de ulike IDEene D.3 Oversikt over nettlesere og standarder D.4 De forskjellige evalueringskriteriene er vektet fra 1 5 der 5 er best E.1 Feilrapporteringsskjema F.1 UC-0: Registrering av bruker F.2 UC-1: Pålogging F.3 UC-2: Etablering av en nøkkelring F.4 UC-3: Legge til SP i en nøkkelring F.5 UC-4: Single Sign-on brukeropplevelse F.6 UC-5: Single Logout F.7 UC-6: Terminering av nøkkelring/fjerne SPe fra nøkkelring xvi TABELLER

17 Kapittel 1 Prosjektdirektiv 1

18 1.1 Innledning Kort om bakgrunnen for prosjektet og om dette dokumentet 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 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 INNLEDNING

19 1.2 Prosjektmandat Her følger en kort oversikt over prosjektet Prosjektnavn Prosjektet har fått navn Web Single Sign-on Prosjektsponsor Oppdragsgiver for prosjektet er Kantega 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 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 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

20 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 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 Økonomi 2184 timer fordelt på 7 gruppemedlemmer og 13 uker. Prosjektgruppa har i utgangspunktet ingen økonomiske midler til disposisjon Tid Prosjektperioden starter og resultatet skal være ferdig Det skal også være en preleveranse av forstudie og kravspesifikasjon den Presentasjon av resultatet er den kl i ITS PROSJEKTMANDAT

21 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 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 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 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 PROSJEKTPLAN 5

22 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 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 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 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 Testdokument Ansvarlig: Magnus En plan for testing blir utviklet i løpet av flere faser. Overordnet testplan lages i krav PROSJEKTPLAN

23 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 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 Presentasjon og demonstrasjon Denne fasen vil ikke resultere i noe fasedokument, men en presentasjon som vises den PROSJEKTPLAN 7

24 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 ORGANISERING AV GRUPPA

25 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 ORGANISERING AV GRUPPA 9

26 1.5 Maler og standarder Under følger en oversikt over maler og standarder som skal brukes i prosjektet Generelt Ordinære dokumenter skrives i L A TEX. Alle dokumenter skal følge de maler og standarder som angitt i dette dokumentet 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 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 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 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 MALER OG STANDARDER

27 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 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 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 Litteraturhenvisninger Til litteraturhenvisninger i prosjektrapporten brukes Bibtex. Dette gjør at litteraturhenvisningslista genereres automatisk. Alle litteraturhenvisninger i rapporten står i klammeparenteser ([]) MALER OG STANDARDER 11

28 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 Programvare I tabell 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å /binindex.cgi for gratis nedlasting. Veiledning finnes på doc/index.html. Axis Axis har åpen kildekode og finnes tilgjengelig på 1/ for gratis nedlasting. Installasjonsveiledning finnes på cvs.apache.org/viewcvs/ checkout /ws-axis/java- /docs/install.html På 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å for gratis nedlasting. API JavaDoc dokumentasjonen finnes på /opensaml/java/doc/api/. L A TEX L A TEX har åpen kildekode og finnes tilgjengelig fra mange forskjellige ressurser på Internett. Se på for instruksjoner for hvordan en får tak i L A TEX. Tabell 1.1: Programvare som brukes i prosjektet MALER OG STANDARDER

29 1.6 Prosjektoppfølging Avsnittet viser hvordan prosjektet følges opp fra uke til uke Prosjektmøter Under følger en oversikt over de ulike møtetypene i prosjektet Interne møter Interne møter holdes hver tirsdag og 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 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 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 PROSJEKTOPPFØLGING 13

30 Veiledermøter Møtet med hovedveileder, som i all hovedsak er obligatorisk for alle gruppemedlemmene, avholdes torsdag 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 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 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 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 dagen før veiledermøtet, og skal godkjennes av hovedveileder. Mal for statusrapport finnes i tillegg B 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 Tid Punktet beskriver hvordan gruppa ligger an fra uke til uke i forhold til planlagt tid PROSJEKTOPPFØLGING

31 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 Omfang Dersom omfanget av løsningen har minket eller økt den siste perioden vil dette bli beskrevet under dette punktet Kostnad/timer Regnearket inneholder fullstendig oversikt over timer brukt og timer estimert brukt 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 PROSJEKTOPPFØLGING 15

32 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 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 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 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

33 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 KVALITETSSIKRING 17