Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Transkript

1 2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017

2 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave 2b 2.3 Oppgave 2c Prosjektplanlegging 3.1 Oppgave 3a Oppgave 3b Oppgave 3c Oppgave 3d Referanser

3 1 Klassediagram «Lag et klassediagram for systemet. Ta med assosiasjoner mellom klassene, og metoder og attributter til hver klasse. Husk at dere kan skrive egne forutsetninger, og forenkle der det er nødvendig. (Husk også at alle metoder og attributter dere kommer frem til i oppgave 2 skal være med her).» Diagram 1: Klassediagram som Markasykkelsystemet. To do: Spesifiser eventuelle endringer og utvidelser 2

4 2 Sekvensdiagram 2.1 Oppgave 2a «Lag en tekstlig bekrivelse for brukstilfellet Registrer utlån. Ha med aktører, eventuelle pre- og postbetingelser, hovedflyt og alternativ flyt der kunden ikke finnes i systemet fra før.» Den tekstlige beskrivelsen presentert i denne oppgaven er basert på eksemplene gitt av Meer Fjeld (2017a) og Lindsjørn (2017a). Navn Registrer utlån Aktør Bruker (primær) Markasykkelsystemet (sekundær) Prebetingelse Bruker står ved marka-sykler stativ Bruker har et reisekort fra ruter (antar at ruter sitt reisekort blir brukt som utlånskort for markasykler) Det er minst en ledig sykkel på stasjonen Postbetingelse Utlån registrert og bruker har sykkel Hovedflyt 1 Brukeren drar reisekortet sitt på et markasykkelstativ som starter utlåningsprosessen 2 Systemet verifiserer at brukeren er registrert 3 Systemet sjekker om brukeren har gyldig billett/abonnement 4 Systemet sjekker om stasjonen har ledig sykkel 5 Markasykkelsystemet registrerer utlånet 6 Markasykkelsystemet sender melding til stasjonen om å låse opp en ledig sykkel 7 Stasjonen låser opp en sykkel 8 Stasjonen viser beskjed om hvilken sykkel brukeren har blitt tildelt 9 Brukeren henter sykkelen Alternativ flyt 1 Steg 2 Brukeren er ikke registrert bruker av markasykkeltjenesten A 1. 1 Stasjonen viser beskjed om at brukeren ikke er registrert. 3

5 2.2 Oppgave 2b «Lag et sekvensdiagram for brukstilfellet Registrer utlån. Bruk de nødvendige klassene og metodene fra oppgave 1. Ta med alternativ flyt der kunden ikke finnes i systemet fra før.» Sekvensdiagrammet i denne oppgaven er basert på eksempler fra læreboken (Sjøberg og Lindsjørn, 2016) og presentasjoner fra Lindsjørn (2017c). Diagram 2: Sekvensdiagram for brukstilfellet «registrer utlån». 4

6 2.3 Oppgave 2c «Lag et sekvensdiagram for brukstilfellet Se oversikt over sykler som ikke er levert i tide.» Sekvensdiagrammet i denne oppgaven er basert på eksempler fra læreboken (Sjøberg og Lindsjørn, 2016) og presentasjoner fra Lindsjørn (2017c). Diagram 3: Sekvensdiagram for brukstilfellet «se oversikt over sykler som ikke er levert i tide». 3 Prosjektplanlegging 3.1 Oppgave 3a «Identifiser de overordnede aktivitetene som inngår i utviklingen av systemet for markasykler. Beskriv disse. Ha med minst 8 aktiviteter.» Vi tar utgangspunkt i hvordan plandreven utviklingsprosess blir beskrevet i læreboken (Sjøberg og Lindsjørn, 2016, kapittel 2 og 4). A1 Kravhåndtering Kravhåndtering går utpå å identifisere krav til systemet som skal lages og å lage en kravspesifikasjon. Kravspesifikasjon er er nødvendig for å kunne konstruere en systemarkitektur og for å kunne danne et grunnlag for hvordan et system skal implementeres. Den er også nødvendig for at forskjellige bedrifter skal kunne legge inn anbud på prosjektet, og for at kunden og organisasjonen som skal utvikle systemet skal kunne skrive en kontrakt. Den ene typen krav er brukerkrav, der kravene er satt opp på en enkel måte som er forståelig for kunden. Den andre typen krav er systemkrav, der kravene er avanserte og detaljerte, og som definerer hvordan implementasjonen skal foregå (Sjøberg, 2017). 5

7 Kravspesifikasjonen kan deles inn i funksjonelle og ikke-funksjonelle krav. Funksjonelle krav definerer hva et system skal oppnå, slik som hvilke funksjoner systemet skal ha og hvilke resultat systemet skal oppnå. Disse kravene kommer under systemets design. Ikke-funksjonelle krav definerer hvordan de funksjonelle kravene skal implementeres i systemet, slik som brukervennlighet, sikkerhet og vedlikehold (Sjøberg, 2017). Kravspesifikasjonens rolle i en systemutviklingsprosess varierer med tanke på hvilken prosessmodell som blir tatt i bruk. I plandrevne modeller spiller kravspesifikasjonen en veldig stor rolle siden all dokumentasjon skjer i starten av utviklingsprosessen. Utviklingen av plandrevne systemer skjer i faser, så det er derfor viktig at kravspesifikasjonen er fullstendig og inneholder presise og detaljerte krav før implementasjonen begynner. I smidige modeller spiller kravspesifikasjonen en mye mindre rolle, siden mye av planleggingen skjer gradvis underveis. Smidige modeller tar forbehold for endring av kravene, så i motsetning til plandrevne modeller, er det ikke like viktig at kravene er veldig detaljerte og nøye dokumenterte før implementeringen begynner. A2 Design - danner systemarkitektur Design av et system er en kreativ prosess som innebærer å lage en beskrivelse av strukturen til programvaren som skal implementeres. Prosessen går ut på å identifisere programvarekomponenter og sammenhengen mellom dem. Design og implementasjon er sammenflettede aktiviteter. Type systemarkitektur velges etter hva som passer til systemkravene. Aktiviteter som inngår under designfasen er design av programvare, database og grensesnitt, samt valg av gjenbrukbare komponenter (Sjøberg og Lindsjørn, 2016, kapittel 7). Det som skal til for å oppnå et godt design er å sette objekter i en slik relasjon at de kan utføre den jobben de skal, å ha et riktig abstraksjonsnivå, å ha en god utforming som er gjenbrukbar og forståelig, og å lage objekter med et lite og veldefinert ansvarsområde (Lindsjørn, 2017c). A3 Implementasjon Implementasjonen av et system er en kritisk fase i systemutviklingsprosessen, der en kjørbar versjon av programvaren utvikles for levering til kunde. Utvikliklingen av programkoden som skal implementeres i systemet kommer som følge av design av systemet. Design av programvare og programmering er en del av implementasjonen, som vil si at man jobber parallelt med disse to. Endringer i utviklingen av programvare må håndteres fortløpende, og da blir gjenbruk av programvare, konfigurasjonsstyring og host-target utvikling tatt i bruk. Implementasjonsfasen innebærer samarbeid mellom utviklere på tvers gitte arbeidsområder. Det forventes at endelig utfall i denne fasen er en stabil, funksjonell og kjørbar versjon av programvaren (Sjøberg og Lindsjørn, 2016, s. 40). A4 Enhetstesting Enhetstesting vil si å teste at alle enheter av programkode fungerer slik de skal, før alle enhetene settes sammen til et ferdig system. Siden det vil bli brukt objektorientert programmering for å implementere systemet, kan en enhet for eksempel være en klasse eller en metode (Sjøberg og Lindsjørn, 2016, s. 240). A5 Integrere systemet Integrering av et system er en fase hvor alle ferdigutviklede komponenter kobles sammen, og der selve programvare og harddisk kobles sammen. Det arbeides fortsatt med arkitekturen til systemet på forskellige aspekter. I noen tilfeller kan det sammenkobles forskjellige plattformer og subsystemer, som 6

8 gjennom integrering muliggjør fri dataflyt gjennom hele systemet, men denne fasen kan være tidkrevende. Det er ønskelig at programkoden som lages er gjenbrukbar, og at den eventuelt tilsvarer andre plattformer. På denne måten spares mye tid og ressurser i systemutviklingprosessen. I denne oppgaven er det viktig å ta i betraktning at mulige problemer kan oppstå ved integrering av Ruter sitt betalingssystemet og markasykkel-systemet (Rouse, 2015). A6 Systemtesting Testing av programvare er en veldig viktig del av systemutviklingsprosessen. Gjennom programvaretesting oppdages feil, det sjekkes om systemet innfrir de funksjonelle og ikke-funksjonelle kravene, og selve systemet kvalitetssikres. Det finnes forskjellige typer testing og det er anbefalt å teste systemet så tidlig som mulig, siden det koster mye mer å fikse feilene som oppstår etter at produktet er tatt i bruk. I tillegg er det viktig å vurdere ekstern testing istedenfor at utviklere tester sin egen kode (Meer Fjeld, 2017c). På bildet under viser vi til testing i de forskjellige fasene av systemutviklingen. To veldig viktige faser er validering «bygger vi det som brukerne ønsker?» og verifisering «bygger vi systemet på riktig måte?» (Software Testing Fundamentals, 2017) A7 Installere systemet Det å installere et system vil si å installere programvaren på de maskinene som systemet skal kjøre på, og å sette programvaren i bruk, alstå å kjøre programmet. A8 Vedlikehold Etter som tiden går vil systemet være under stadig endring som resultat av bruk og vedlikehold. Kravene kan endres, kunden kan komme med nye behov, og loven og markedet kan endres. Noen ganger må det gjøres endringen i koden for å holde systemet stabilt og brukbart, og det vil ikke minst bli utført debugging. En løsning er å bruke flere versjoner av systemet som kan tilpasses nyinnkommende krav. På denne måten kan flere mulige varianter bli testen for å fikse problemet (Sjøberg og Lindsjørn, 2016, s. 319). 7

9 3.2 Oppgave 3b «Ta utgangspunkt i de overordnede aktivitetene som foreslått i oppgave a). Gi hver aktivitet et unikt navn, varighet, eventuelle avhengigheter og milepæler. Gjør dette ved å lage en tabell med utgangspunkt i figur 23.5 side 295 i læreboka.» Svar på oppgaven er fremstilt i tabell 1. Tabellen er basert på eksempler gitt i læreboken (Sjøberg og Lindsjørn, 2016, s. 295) og eksempler gitt av Meer Fjeld (2017b) og Lindsjørn (2017b). Tabellen representerer hver av aktivitetene beskrevet i svaret på spørsmål 3a. Disse aktivitetene har også vært gitt unike navn jf. tabellen A1 - A8. Hver aktivitet har varighet for arbeidet som inngår i aktiviteten. Arbeidet blir målt i person-dager hvor en person-dag representerer arbeidet til en person per en vanlig arbeidsdag. Varigheten blir målt i kalenderdager. Hver aktivitet kan være avhengig av at en annen aktivitet må være ferdig før den kan starte. I plandreven utvikling der fossefallsmodellen benyttes, gjelder prinsippet at output for nåværende aktivitet er input for neste aktivitet. I denne oppgaven bruker vi ikke fossefallsmodellen, men tar utgangspunkt i at utviklingen er plandreven. Tabellen inneholder også milepæler for prosjektet, disse er representert med bokstaven M og en tall for hver milepæl. Tabell 1: Prosjektplan, aktivitet, arbeid, varighet, avhengighet og milepæler. Aktivitet Arbeid (person - dager) Varighet (dager) Avhengighet A A A1, M1 A A2 A A3, M2 A A3 A A5, M3 A A5, M3 A8 Resten av systemets levetid Resten av systemets levetid A7, M4 8

10 3.3 Oppgave 3c «Bruk tabellen til å lage et stolpediagram med utgangspunkt i figur 23.6 side 297 i læreboka.» Diagrammet er basert på eksempler gitt i læreboken (Sjøberg og Lindsjørn, 2016, s. 297) og av Meer Fjeld (2017b). Det er også basert på tabell 1 i denne oppgaven. Diagram 3: Sekvensdiagram (Meer Fjeld, 2017b) (Dager) 3.3 Oppgave 3d «Lag en risikoanalyse ved å benytte en usikkerhetsmatrise. Få med risiko, sannsynlighet for risiko, konsekvens av risiko, hvilke tiltak som må iverksettes og hvem som er ansvarlig for hvert risikomoment. Ha med minst seks risikomomenter.» Svaret på denne oppgaven er fremstilt i tabell 2. Utformingen av tabellen bygger på fremstillingen i læreboken (Sjøberg og Lindsjørn, 2016, s ). Innholdet fra tabell 2 er også satt opp i en usikkerhets-matrise i tabell 3, for en mer tydelig fremstilling av resultatene. I besvarelsen på oppgaven har vi valgt å ta med typen av hvert risikomoment. Det finnes tre hovedtyper av risiko; prosjekt-, produkt- og forretningsrisiko. I tillegg finnes det seks underordnede typer risiko vedrørende forskjellige tema innen systemutvikling; estimering, organisasjon, mennesker, krav, teknologi og verktøy. Vi har også valgt å presisere hva slags tiltak vi foreslår for hvert risikomoment, dvs. et forebyggende tiltak, et minimaliserende tiltak eller en beredskapsplan. Risikomomentene er rangert og satt opp i en nummerert liste etter hvor alvorlige konsekvensene kan være. Det bør noteres at for at lage en god risikoanalyse trengs det mye kunnskap og erfaring. Erfaring fra tidligere prosjekter kan være avgjørende for en prosjektleder som skal utføre analysen, samt detaljert kunnskap og informasjon om prosjektet, organisasjonen, utviklingsteamet og prosessen som skal brukes mv. I denne oppgaven sitter vi ikke på slik kunnskap eller erfaring og besvarelsen bør ses i lys av dette. 9

11 Tabell 2: Åtte risikomomenter, type risiko, sannsynlighet, konsekvens, tiltak og ansvar. Risiko / risikotype Sannsynlighet Konsekvens Tiltak Ansvar #1 Estimering av budsjett Budsjettet for prosjektet ble underestimert. #2 Teknisk Stasjonene som står i marka ikke er robuste nok for å tåle vinter og vær. #3 Estimering av tid Tid for programmering og integrering ble underestimert som ev. bidrar til at utviklere ikke setter av nok tid til testing og debugging. Resultatet blir et system med masse feil. #4 Krav Kravspesifikasjonen er ikke tilstrekkelig for å beskrive det systemet som skal lages. #5 Mennesker Kommunikasjons problemer hos utviklingsteamet ev. mellom utviklere og prosjektledelsen Moderat Katastrofal Forebyggende tiltak Bruk kostnadsmodeller i bland med erfarne prosjektledere for å estimere kostnader. Minimalisering av risiko og beredskapsplan Oppsigelse av ansatte og dermed lengre leveringstid for produktet. Svært lav Katastrofal Forebyggende tiltak Velg type stasjoner som har vist at de tåler vær og vind og har vært brukt i lignende prosjekter før. Beredskapsplan Erstatte stasjonene med stasjoner som er mer robuste. Moderat Alvorlig Forebyggende tiltak Test så mye som mulig underveis i programmeringen, bruk automatiske testverktøy. Beredskapsplan Eventuelt rekrutter et eksternt team for å utføre testing. Lav Alvorlig Forebyggende tiltak Prøv å etablere så godt forhold og kommunikasjon med kunden som mulig, bruk arkitektoniske modeller som utgangspunkt i kommunikasjon med kunden og utviklere. Høy Alvorlig Forebyggende tiltak Velg uformell struktur ovenfor hierarkisk struktur for teamet, tenk på teamsammensetning (personlighetstyper/kjønn), bidra til godt arbeidsmiljø. Minimaliserende tiltak Reorganiser rutiner og kommunikasjonsmåter Beredskapsplan Ev. bytt ut teammedlemmer. Arkitekt for hardware Prosjektleder Utvikler Kunden/ oppdragsgiver Prosjektledelsen/ leverandør Prosjektledelsen Prosjektledelsen Prosjektledelse 10

12 #6 Teknisk Serveren til markasyklersystemet håndterer ikke like mange brukere på samme tid som forventet. #7 Bruk av verktøy Testverktøy fungerer ikke som det skulle og oppdager færre feil enn vanlig, brukere oppdager feil i systemet etter lansering Lav Alvorlig Minimaliserende tiltak / beredskapsplan Sjekk hvilke muligheter foreligger for å erstatte eller kjøpe ny server. Lav Alvorlig Minimaliserende tiltak / beredskapsplan La brukere oppdage feiler og rapportere den. Bruk feilrapporteringsverktøy. Fiks de feilene du får rapportert. Arkitekt for hardware Prosjektledelse Utviklere #8 Organisasjon Endringer i lovverk om behandling av personopplysninger skaper utfordringer og stiller høyere krav til sikkerhet i systemet. Svært høy (Nye lover trer i kraft mai 2018, som kommer til å skape mye usikkerhet på dette området) Mindre alvorlig Forebyggende / minimaliserende tiltak Ta i bruk juridisk konsultasjon, samarbeid med datatilsynet. Beredskapsplan Sett av budsjett for ev. bøter som må betales. Bruk flere versjoner av systemet ved testing av innførte endringerkonfigurasjonsstyring Leverandør Ev. kunden/ kommunen for å fastsette retningslinjer for utvikling av systemer for forvaltningen 11

13 (Sannsynlighet) Tabell 3, viser en usikkerhetsmatrise hvor nivå av sannsynlighet og konsekvens av risiko er representert med tre farger; grønn, gul og rød. Grønn er det laveste nivået for risiko, alle risikomomenter som faller inn på de grønne feltene burde minst ha et forebyggende tiltak. Middels nivå for risiko er representert med gul farge, i dette tilfellet burde det hvert risikomoment ha minst et minimaliserende tiltak. Rød farge representerer høyeste nivå for risiko og i disse tilfellene må det eksistere en beredskapsplan. I denne tabellen har vi plassert de risikomomentene fra tabell 2 basert på sannsynligheten at de inntreffer og konsekvensene de kan ha for prosjektet, produktet og forretningen. Tabell 3: Usikkerhetsmatrise, sannsynlighet/konsekvens. (Konsekvens) Ubetydelig Mindre alvorlig Alvorlig Katastrofal Svært høy #3 Høy #5 Moderat #3 #1 Lav #4 #6 #7 Svært lav #2 12

14 Referanser Meer Fjeld, Y. de (2017a). «Use case modellering». PowerPoint-presentasjon. Universitetet i Oslo. URL: /Uke04%20-%20UseCase_gjennomgang.pdf (sjekket ). Meer Fjeld, Y. de (2017b). «Prosjektledelse, planlegging og teamarbeid». PowerPoint-presentasjon. Universitetet i Oslo. URL: gaver/losningsforslag/uke10%20-%20prosjektledelse_gjennomgang.pdf (sjekket ) Meer Fjeld, Y. de (2017c). «Testing av programvare». PowerPoint-presentasjon. Universitetet i Oslo. URL: /Uke08%20-%20Testing_gjennomgang.pdf (sjekket ) Lindsjørn, Y. (2017a). «Modellering av krav». PowerPoint-presentasjon. Universitetet i Oslo. URL: use-case-modellering.pdf (sjekket ). Lindsjørn, Y. (2017b). «Prosjektledelse, prosjektplanlegging, teamarbeid». PowerPoint-presentasjon. Universitetet i Oslo. URL: inger/inf1050_ _prosjektledelse_teamarbeid.pdf (sjekket ) Lindsjørn, Y. (2017c). «Mer om objektorientering og UML». PowerPoint-presentasjon. Universitetet i Oslo. URL: _objektorient-modellering.pdf (sjekket ) Rouse, M. (2015). Definition: Integration. TechTarget. URL: (sjekket ) Sjøberg, D. (2017). «Kravhåndtering». PowerPoint-presentasjon. Universitetet i Oslo. URL: kravha%cc%8andtering.pdf (sjekket ) Sjøberg, D. og Lindsjørn, Y. (2016). Selected Chapters from Ian Sommerville: Software Engineering. 10. utg. Pearson. 816 s. a Software Testing Fundamentals. (2017). System testing fundamentals: Definition, system testing. URL: (sjekket ) 13