Håndtering af non functional risks

For at undgå at de ovennævnte non functional risks bliver problematiske, er det nødvendigt at tage stilling til, hvorledes disse ønskes håndteret. Det vil her blive gennemgået for de forskellige tilfælde.

5.8.4.1 Urealistisk kravspecifikation

Det er næsten utænkeligt, at der til at begynde med udvikles en fuldstændigt perfekt kravspecifikation. Det er derfor nødvendigt at have en strategi til at holde denne ajour.

Det skal i forbindelse med dette projekt gøres ved, at der ved afslutning af hver iteration tages stilling til, hvilke aspekter af kravspecifikationen, der skal redigeres. På denne måde kan det sikres, at kravspecifikationen ikke er ude af trit med virkeligheden, og at der ikke er længere mellem den aktuelle implementering og kravspecifikationen, end at det er muligt at gå tilbage, hvis en evt. ændring viser sig at være uhensigtsmæssig.

I og med at dette projekt har en deadline, der ligger i den overskuelige fremtid, kan det vise sig, at den oprindelige kravspecifikation har elementer, der ikke kan implementeres indenfor den mulige tidshorisont. Dette skal som udgangspunkt helst undgås ved fornuftig projektstyring, men det kan være nødvendigt at revidere kravspecifikationen, hvis det viser sig, at tidsplanen skrider pga. at der ikke er afsat tid nok til de forskellige opgaver.

5.8.4.2 Urealistisk tidsplan

En række dele af projektet kan vise sig at tage længere tid end ventet. Et vigtigt redskab til at undgå at dette bliver et problem er at have løbende projektstyring. På den måde kan det sikres, at tidsplanen hele tiden tilpasses realiteterne, og det ligeledes hele tiden er muligt at få overblik over, hvor vidt der skal indsættes ekstra kræfter på nogle områder. I yderste konsekvens kan det, som det er nævnt i afsnit 5.8.4.1, være nødvendigt at foretage en prioritering af projektets delelementer for at sikre at kritiske dele gennemføres – muligvis på bekostning af mindre essentielle dele.

For at undgå at tidsplanen skrider, skal der tages en række instrumenter i brug. Først og fremmest skal der defineres en overordnet projektplan. Til dette formål skal Microsoft Project anvendes, og der skal her udarbejdes en plan for hele projektforløbet. Denne skal løbende justeres, efterhånden som delopgaver bliver færdige, og der skal korrigeres, når delopgaver tager kortere eller længere tid end ventet. Overordnet skal denne plan inddeles i de forskellige RUP iterationer. Der skal endvidere udarbejdes ugeplaner, der beskriver de opgaver, der skal afvikles i løbet af ugen.

5.8.4.3 Systemet lever ikke op til slutbrugerens forventning

Det er et alvorligt problem, hvis det produkt, der leveres ikke lever op til NNE’s opfattelse af, hvad der skulle laves. Der skal derfor arbejdes tæt sammen med dem om at specificere systemet. Det betyder, at NNE løbende skal involveres, herunder både i forbindelse med udarbejdelse af use-cases og efterhånden som applikationen udvikles.

Det er derfor også vigtigt at alle designvalg afspejler det system, der er blevet opridset vha. use-cases. Hvis der dukker designmæssige problemer op, der skyldes uhensigtsmæssigheder i use-cases, må den relevante use-case tages op og ændres, hvor det er nødvendigt, således at NNE hele tiden er involverede i, hvad der foretages af funktionelle ændringer. På den måde undgås det også, at der i forbindelse med design laves uigennemskuelige lappeløsninger, som eventuelt senere hen viser sig at forringe eller ændre applikationens funktionalitet i forhold til det, som NNE forventer.

5.8.4.4 Koden bliver uigennemskuelig

Uigennemskuelig kode vil gøre vedligeholdelse yderst besværlig. Det er derfor vigtigt, at det overvejes, hvorledes koden kan gøres nemt forståelig. Der er forskellige måder at gøre dette på. En måde er at man undgår at lave ”smarte løsninger”, hvor det er muligt at lave en traditionel løsning. Ulempen ved sådanne smarte løsninger er, at de ofte er meget specifikke for det enkelte problem og oftest siger det ikke sig selv, hvad der sker i koden. Til tider kan det dog være nødvendigt at lave noget kode, der ikke er selvforklarende, hvorfor det er vigtig at kommentere koden tilstrækkeligt. Et andet vigtigt instrument til at sikre mere gennemskuelig og struktureret kode er at anvende design patterns til at sikre en systematisk opbygget kode.

5.8.4.5 Manglende gennemtest af systemet

Det er vigtigt at alle aspekter af systemet er blevet testet, da systemet ellers kan blive ustabilt.

5.8.4.6 Sikkerhed

Det skal sikres, at det ikke er muligt at tilgå oplysninger gennem systemet, hvis man ikke har rettigheder dertil. For brugerdelen af applikationens vedkommende skal det, som nævnt i use-case #3, sikres ved, at der opretholdes et register over, hvilke PDA’er, der har lov til at tilgå systemet. Dette skal gøres ved at en administrator

vedligeholder en tabel i LMES+ databasen, der indeholder lovlige Mac-adresser. Skal ikke implementeres i forbindelse med dette projekt.

5.8.4.7 Hastighed

Det er vigtigt, at de kriterier for ydelse, der er specificerede i de enkelte use-cases efterleves. Dette punkt har høj prioritet, og der skal optimeres såfremt dette ikke er tilfældet.

5.8.4.8 Udvikling

I forbindelse med udvikling af applikationen vil en række IDE-produkter blive anvendt, og dette kan afføde nogle problemer i det omfang, disse anvendes til automatisk kodegenerering. Fx indeholder Visual Studio en Designer, der kan anvendes til at oprette databaseforbindelser. Det er en risiko, at anvendelse af denne gør, at udvikleren mister overblikket over, hvorledes der oprettes forbindelse til databasen, samt at der muligvis genereres store mængder kode, der er overflødig eller unødigt kompliceret. Derudover er det også et problem, hvis denne kode ikke er tilstrækkelig og skal redigeres, da autogeneret kode ofte kan være svær at gennemskue og i nogle tilfælde bliver den autogenerede del af koden hele tiden opdateret, således at eventuelle ændringer forsvinder. Denne problemstilling skal holdes for øje, og der skal kun anvendes autogenereret kode, hvor dette er en fordel.

Derudover kan det udgøre et stort problem, hvis forskellige produkter ikke kan arbejde sammen. Det skal derfor sikres på forhånd, at de produkter, der anvendes er indbyrdes kompatible, således at der ikke vælges et udviklinsværktøj, der ikke kan anvendes sammen med de applikationer, der i forvejen anvendes.