Kvalitetssikring. Revision: 1.4. Sidst opdateret: Date : 2003/11/1918 : 11 : 58. A Referat af morgenmøde mandag d. 22.

Transkript

1 Kvalitetssikring Revision: 1.4 Sidst opdateret: Date : 2003/11/1918 : 11 : 58 Indhold 1 Indledning 2 2 Interviews med brugerne 2 3 Interne reviews 3 4 Eksterne reviews 3 5 Test 6 A Referat af morgenmøde mandag d. 22. september B Referat af eksternt review af kravspecifikation, d. 22. september C Referat af review af designspecifikation, d. 20. oktober

2 1 Indledning Det har været vigtigt for projektgruppen at udvikle et produkt og ikke mindst en rapport, vi fagligt kan stå inde for og hvor gode erfaringer overskygger dårlige. Derfor har vi løbende forsøgt at forebygge katastrofer i projektet og dermed sikre kvaliteten i arbejdet. Men hvad er kvalitet for en størrelse, når vi har at gøre med systemudvikling? Kvalitet kan i de fleste andre produktsituationer vurderes efter faste målbare kriterier, eksempelvis kan et nybygget hus vurderes ud fra valg af materiale til vægge, gulve, vinduer osv. Er der brugt billig gulvbelægning, der hverken tåler fugt eller flere års slid eller har man valgt en dyrere løsning, der kan holde til både fugt og slitage? Softwarekvalitet adskiller sig på flere områder væsentligt fra kvalitet i synlige, fysiske produkter som f.eks. et hus. I udviklingen af et rigtigt softwaresystem til en rigtig kunde vil brugertilfredsheden naturligvis spille en altafgørende rolle i vurderingen af, om produktet er udtryk for kvalitetsarbejde eller ej. Ligeledes vil man kunne vurdere kvaliteten ud fra, om afleveringen af produktet er sket inden for de økonomiske og tidsmæssige rammer. I vores tilfælde, hvor vi hverken oplever brugerreaktioner eller overskridelse af budget og tid - udover interne deadlines i projektforløbet - er vi nødt til at bruge andre kriterier og metoder. Og det er det, vi beskriver i dette dokument. 2 Interviews med brugerne Et vigtigt kvalitetskriterium har fra starten været at udvikle et produkt, der stemmer overens med brugerbehovet. Den behovsbaserede kvalitet har dermed haft en stor plads i forløbet, hvorfor vi har lagt en del energi i udarbejdelsen af Projectivitys kravspecifikation. Da vi ikke fandt beskrivelsesdokumentet fra Softwarehuset fyldestgørende i forhold til vores forståelse af systemet, foretog vi to interviews med to brugere. Disse interviews dannede sammen med beskrivelsesdokumentet grundlaget for udarbejdelsen af kravspecifikationen og er vedlagt som bilag til kravspecifikationen. Der var især uklarhed om der var specifikke behov og ønsker i forhold til brugergrænsefladen og interaktion med andre af Software- Husets systemer. Ligeledes spurgte vi ind til ting i beskrivelsesdokumentet, hvor vi savnede mere fyldestgørende information. F.eks. var det ikke klart, hvad der mentes med en aktivitet og hvad der mentes med opløsning på ugenummerniveau og at søge assistance hos en kollega i beskrivelsesdokumentet. Med de to interviews fik vi svar på vores spørgsmål og kunne gå i gang med at udarbejde kravspecifikationen. 2

3 3 Interne reviews Kravspecifikationen er skridtet på vejen imod udviklingen af et godt produkt, men uden løbende opfølgning er kravspecifikationen som produkt værdiløs. Derfor har vi brugt meget tid på at vende tilbage til kravspecifikationen både under analysen, designet, programmeringen og testen. Her har vi gjort brug af interne og eksterne reviews, hvis formål har været at højne både procesog produktkvalitet. De interne reviews er foregået løbende og har ikke været formelle. Fælles mandagsmorgenmøder har dannet rammen for projektarbejdet, hvor vi har udvekslet informationer og fremlagt problemer eller spørgsmål. Dette har ligeledes været forummet, når vigtige beslutninger er blevet truffet. En anden form for kvalitetssikring har været de gange, hvor nogle af gruppemedlemmerne har påtaget sig specifikke kvalitetssikringsopgaver. F.eks. gik et gruppemedlem fra testgruppen kravspecifikationen igennem for at vurdere, hvorvidt kravene var testbare. Dette gjaldt både de funktionelle og ikke-funktionelle krav. Det viste sig, at to af kravene ikke var testbare, hvorfor vi ændrede dem. Dette skete før det eksterne review med opponentgruppen og på den måde kom denne aktivitet til at fungere som et internt review med det formål at sikre kvaliteten. Samtidig afholdt vi et morgenmøde samme dag som det eksterne review af kravspecifikationen skulle foregå. Her diskuterede vi, hvad vi hver især mente om vores egen kravspecifikation. På den måde blev kritiske forhold omkring kravspecifikationen afklaret inden opponentmødet. (jvf appendix A) Et andet eksempel på kvalitetssikring i denne sammenhæng er at et gruppemedlem sammenlignede kravspecifikationen og designspecifikationen for at vurdere sporbarheden. Kunne kravene fra kravspecifikationen genfindes i det efterhånden meget konkrete designdokument? Ligeledes vurderede en anden fra gruppen de valgte krav, som blev til use cases i forhold til konceptmodellen og fandt en use case, der dannede grundlag for et af elementerne i konceptmodellen. Problemet var blot, at den pågældende use case var blevet fravalgt som krav og den havde derfor ingen berettigelse i konceptmodellen, hvorfor den blev fjernet. 4 Eksterne reviews De eksterne reviews havde til formål at finde fejl, mangler og uklarheder ved henholdsvis kravspecifikationen og designspecifikationen. Udover de to reviews med opponentgruppen afholdt vi et review af designspecifikationen med Klaus J. Jeppesen. Første opponentmøde, hvor det gjaldt om gensidig kritisk vurdering foregik på en afslappet facon, hvilket sandsynligvis skyldtes at ingen af os 3

4 havde prøvet det før. Vi fulgte eksempelvis ikke den udleverede tjekliste til review af kravspecifikation og vi havde heller ikke på forhånd aftalt hverken faser eller roller i reviewet. Eneste fastlagte var, hvem der skulle tage referat af mødet. Alligevel lykkedes det os at påpege problemer, fejl og mangler ved opponentgruppens kravspecifikation. Omvendt fik vi en masse konstruktiv kritik [Referat af dette møde vedlagt som appendix B i dette dokument]. Der skal her gøres opmærksom på, at læseren i mange tilfælde ikke vil kunne slå op på de omtalte punkter fra referatet, da vi efterfølgende har tilrettet kravene og de tilhørende nummereringer i kravspecifikationen. I det følgende beskriver vi de vigtigste fejl, mangler og uklarheder, opponentgruppen og instruktor Michael Hartman påpegede. Samtidig beskriver vi, hvilke noterede fund, vi fandt betydelige og som vi efterfølgende tilrettede. Hvert fund har et nummer i referatet, hvilket er det nummer, der refereres til i gennemgangen. De steder, hvor det er muligt at referere direkte til kravspecifikationen, har vi indsat en reference til Kravspecifikationen [KS]. Fund 3: Til at starte med havde vi ingen krav om adgangskontrol. Vi indførte efterfølgende kravet Log ind i systemet [KS], pkt Dog er eneste adgangskontrol brugernes initialer. Argumentet for at indføre login var, at vi ønskede at identificere brugerne således, at de kun ser de aktiviteter, de er tilknyttet, under timeregistreringsdelen. Fund 4: Tanken med kompetencematching var, at hver udviklingsmedarbejder skulle have tilknyttet respektive kompetencer, hvilket ville være et brugbart redskab for projektlederne, når et projekt bemandes. Vi tog kritikken til efterretning og besluttede efter reviewet, at denne funktion ville blive for kompliceret at implementere, hvorfor vi droppede dette krav. Fund 5 og 6: Forvirringen omkring disse fund skyldtes, at vi i en vis udstrækning havde formuleret kravspecifikationen således at den henvendte sig til underviser og ikke så meget Softwarehuset. Dette skyldtes at vi havde svært ved at skrive til en fiktiv kunde. Dette fik vi dog efterfølgende tilrettet. Fund 7: Vi havde ikke formuleret præcist, hvornår en aktvitet kunne slettes. Efterfølgende ændrede vi kravet således, at det kun er muligt at slette en aktivitet hvis der ikke er registreret timer på den [KS], pkt Fund 8 og 9 og 15: Vi havde ikke beskrevet forhold omkring hardwareog softwaregrænseflader. Dette blev efterfølgende tilrettet og er beskrevet i kravspecifikationen [KS], pkt. 3.2, 3.3 og 3.4. Fund 10: Vi havde beskrevet et stringent datoformat ved oprettelse af et projekt og oprettelse af projektaktivitet. Dette blev påpeget som 4

5 værende for specifikt, hvorefter vi tilrettede det. Fund 11: Det blev påpeget at det var uklart, hvilke ændringer, der bliver gemt i Redigér et projekt [KS], pkt Dette blev efterfølgende tilrettet. Fund 13: Her er der tale om en klar fejl, som blev tilrettet i henhold til kundeinterview. Fund 14: I Projectivity skelner vi ikke mellem brugerne og vi opererer kun med een rolle - medarbejder. Dette valg blev kritiseret flere gange under reviewet, men vi besluttede hurtigt at fastholde vores beslutning, da en fuldstændig gennemførelse af en rollefordeling ville være for tidskrævende. Dette første review fik via en række kritikpunkter og efterfølgende tilretninger en væsentlig betydning for kravspecifikationen, som den foreligger nu. Den efterfølgende mandag godkendte vi kravspecifikationen, hvilket dermed var projektets første baseline. Designspecifikationen var genstand for andet review. Heller ikke denne gang fulgte vi den udleverede tjekliste til review af designspecifikation, og igen var det eneste fastlagte, hvem der skulle tage referat af mødet. Alligevel havde forløb opponnentmødet ganske konstruktivt [appendix C]. Igen gælder det, at læseren i mange tilfælde ikke vil kunne slå op på de omtalte punkter fra referatet, da vi efterfølgende har tilrettet designspecifikationen og de tilhørende nummereringer. Igen beskriver vi de vigtigste fejl, mangler og uklarheder, der blev påpeget. Samtidig beskriver vi, hvilke noterede fund, vi fandt betydelige og som vi efterfølgende tilrettede. Hvert fund har et nummer i referatet, hvilket er det nummer, der refereres til i gennemgangen. De steder, hvor det er muligt at referere direkte til designspecifikationen, har vi indsat en reference til [DS]. Fund 1: At vi ikke havde adskilt de to dokumenter skyldtes at vi havde arbejdet med analyse- og designfasen parallelt. Efterfølgende adskilte vi analysen og designet i henholdsvist en anaysespecifikatyion og en designspecifikation, hvilket først og fremmest har betydet at vi har haft nemmere ved løbende at undersøge den røde tråd imellem de to dokumenter. Fund 2: Til at begynde med havde vi ikke sat vores use cases i hver deres tabel. Dette blev efterfølgende gjort, hvilket gav et godt overblik over især det typiske forløb og det alternative forløb for en use case. Fund 3: Vi diskuterede efterfølgende, hvorvidt vi skulle konstruere tilstandsdiagrammer for de mest centrale objekter, og blev enige om, 5

6 at vi ikke fandt det nødvendigt, idet vores valgte use cases til implementation ikke lægger op til komplicerede ændringer af objekternes tilstande. I et mere kompliceret system ville det være en klar fordel at medtage tilstandsdiagrammer. Fund 4: Vi havde haft en del diskussioner vedrørende valg af programmeringssprog og havde op til opponentmødet endnu ikke endeligt besluttet os. På det førstkommende fælles projektmødet efter reviewet besluttede vi os for Java. Fund 5: Vi havde et ER-diagram, men havde ikke medtaget det i analyse- og designspecifikationen. Vi havde dog ikke på dette tidspunkt taget stilling til, hvordan det konkrete databasedesign skulle se ud. Vel vidende, at valg af databasemodel er afgørende for det samlede design og deraf implementation, gik vi efterfølgende i gang med designet af databasen. Fund 6: Kontrakt blev ikke forstået af opponentgruppen, hvorfor vi med det samme sørgede for en fyldestgørende forklaring [DS] pkt Fund 7: At sekvensdiagrammer skal suppleres med forklaringer var ikke en overraskelse for os, blot havde vi ikke nået det på dette tidspunkt. Ugen efter havde vi et kort review med Klaus J. Jeppesen, hvor følgende blev påpeget: Fund 1: Aalysen og designet bør skilles ad. Fund 2: Vi skal eksplicit vise, hvilken version vi arbejder med lige nu. Fund 3: Det er i det hele taget vigtigt, at I bruger entydig identifikation af de dokumenter, I bruger. Dvs. referencerne imellem dokumenterne skal være klare. Navngiv hvert dokument, evt. med et tilhørende id-nr. Fund 4: Vis forløbet i use cases: Hvordan reagerer systemet på brugernes indtastninger? I skal også beskrive situationer, hvor noget går galt. Vis også forudsætninger for hver use case. Brug evt. en matrix. Alle disse kritikpunkter fulgte vi efterfølgende op på. 5 Test Al kvalitetssikring, der vedrører test, findes i testappendixet [TAP]. 6

7 A Referat af morgenmøde mandag d. 22. september 2003 Deltagere: Stine, Troels, Mathias, Bertel, Anders, Jonas og Tina (referent) 1. Hvem er talsmand for henholdsvis konfigurations- og testgruppen? Troels for test-gruppen Stine for konfigurationsgruppen 2. Hvad synes vi - kort - om vores egen kravspecifikation? Troels: L A TEX gør noget mærkeligt ved nummereringen. Enighed om at når man ser en stavefejl, så retter man den bare Stine: Afsnit 1, 2 og 3 skal skrives ud, lige nu står afsnittene lidt i noteform Vi skal have en begrebsafklaring i appendix. Vi skal nævne at vi følger en skabelon fra artiklen af Wieger Troels går afsnit 2 igennem - når afsnit 4 er skrevet færdig Vi skal have lagt 2. interview ind som bilag: Jonas Troels: Nogle gange skriver vi mærkeligt: Droppe backup-tidspunkt i 5.2. Vi kan ikke argumentere for det Vi skal argumentere for, at systemet skal være nemt at bruge og ikke let at huske Krav til usability: Antal sider indtil man er færdig med at registrere skal skrives ned Vi mangler et krav: Registrering af tidsforbrug på en dag - skal efter 4.9 Planlagte aktiviteter på en dag skal kunne klares med 1 skærmbillede; ok at andre ikke-så-hyppige-indtastninger tager flere skærmbilleder. Ligeledes ok med flere skærmbilleder hvis man skal ind og rette i eksisterende oplysninger Fjerne at det skal køre på Windows 7

8 B Referat af eksternt review af kravspecifikation, d. 22. september 2003 Deltagere: Stine, Troels, Mathias (referent), Bertel, Anders, Jonas, Sandugash og Tina 1. Indledende Fund 1: Ifølge IEEE-standarden skal man ikke skrive sprog - i vores tilfælde Java - mv i krav-spec. (Troels). Michael har en anden opfattelse - se nedenfor. 2. Fund af fejl, mangler og uklarheder i kravspecifikationen Fund 2: Der skelnes ikke mellem de forskellige brugere, og hvilke ansvar de har. Burde man ikke gøre det? Fund 3: Michael: Vi må gerne have adgangskontrol. Som systemudviklere må man gerne komme med gode forslag til at forbedre eksisterende procedurer. Minimum er at bruge initialer. Fund 4: Punkt Kompetencematching: Hvordan skal det foregå? Er det sporbart? Fund 5: Punkt 1.3 og punkt 4.3 (kunden omtales) Hvem er kunderne? Ifølge spørgsmål ved forlæsning er kravspecifikationen til SoftwareHuset og skal altså skrives henvendt til denne fiktive kunde. Ved siden af skal vi have et dokument, der fortæller hvordan vi kom frem til de pågældende krav, og hvorfor vi valgte netop dem: Sporbarhed. Fund 6: Sidste del af interviewet i krav-spec en omhandler et rapport-spørgsmål, der ikke skal med i kravspec. Fund 7: Punkt Slette en aktivitet - skal man kunne det? Er der ikke nogle krav til hvornår man må slette en aktivitet? Man må da kun slette en aktivitet, hvis der ikke er registreret timer på den. Fund 8: Punkt 2.5 Hvordan samarbejder intranettet med det nye system? Der står f.eks. ikke noget om VPN. Michael: En leder der kommer ind udefra, skal ved at læse krav-spec få et godt overblik over systemet. Beskriv software og platform i kravspec. F.eks. VPN-forbindelse, valg af sprog, Java, servletter, clientserver, serversoftware, mv.) Fund 9: Punkt 3.2 (side 6) Er det korrekt, at der ikke er nogen særlige krav til server-hardware? Hænger sammen med forslag til software - se ovenfor. 8

9 Fund 10: Punkt Går meget i dybden, virker designspecifikt, detaljer om datoformater. Michael: I gør livet svært ved at gå i dybden for hurtigt. Fund 11: Punkt 4.2 Hvilke ændringer bliver gemt? Versionsstyring - gemme rettelser? Fund 12: Punkt 4.16 Er validering et brugerkrav? Det virker for design-specifikt. Fund 13: Punkt (side 9) Der står forventet start-dato. I interviewet står der at deadline er en uge i et bestemt år. Der er en konflikt. Fund 14: Michael: Lav en matrice over krav og tilhørende prioritet og brugerroller. Den skal vise hvem der skal kunne udføre hvilke funktioner. Det er en god ide at have roller i systemet, både i forhold til sikkerhed og til brugervenlighed. En bruger med en bestemt rolle kan få en brugergrænseflade, der er tilpasset hans/hendes funktioner i firmaet. Fund 15: Michael: Lav en arkitektur-specifikation. Det behøver ikke at være så præcist, men kom ind i det og få tankerne i gang. Men det er ok at skrive om Apache, Tomcat, MySQL og lign. Michael: Det er ok at lade en deltager i projektgruppen spille rolle som medarbejder i SoftwareHuset, hvis bare interviewet indgår som bilag i krav-specifikationen. Ros: Overskueligt opbygget, let læselig, god måde det er formatteret på, godt med usecases, pkt. 5.1 er et målbart krav. 9

10 C Referat af review af designspecifikation, d. 20. oktober 2003 Deltagere: Stine, Troels, Mathias, Bertel (referent), Anders, Jonas og Tina 1. Fund af fejl, mangler og uklarheder i designspecifikationen Fund 1: God idé at skille analyse og design ad konkret i to forskellige dokumenter. Fund 2: Use case er uoverskuelige og svære at læse; følg en model som giver overblik. Fund 3: Der mangler tilstandsdiagrammer. Fund 4: I skal tage stilling til programmeringssprog så hurtigt som muligt. Fund 5: Hvordan skal jeres database se ud? Fund 6: Uklart, hvad der menes med Kontrakt i konceptmodellen. Måske skal I finde på et andet ord for det i mener. Fund 7: Sekvensdiagrammerne kan ikke stå alene, de skal forklares. 10