TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

Transkript

1 TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst. problem Designspec Implementation Verifiering

2 TPFD Beskrivning Rev 4 2(10) Innehållsförteckning 1. ALLMÄNT REFERENSER TERMINOLOGI STANDARDTEXTER AKTIVITETSÖVERSIKT AKTIVITETER PROJEKTPLAN KONFIGURATIONSDOKUMENT ANVÄNDARKRAV DETALJKRAV TESTPLAN DESIGNSPECIFIKATION IMPLEMENTATION VERIFIERING TEST-OCH-FELRÄTTNING PAKETERING AKTIVITETER SOM INTE SYNS I FIGUREN PROTOTYPNING ENHETSTEST...10 ÖVRIGT...10

3 TPFD Beskrivning Rev 4 3(10) 1. ALLMÄNT Det här dokumentet beskriver på ett översiktligt sätt TPFD-metoden för ordnad program- och systemutveckling. TPFD-metoden föreslår ett antal aktiviteter för att strukturera och bygga komplexa programvarubaserade system. Ordningen på aktiviteterna är sådan att vi ska lära oss så mycket som möjligt om det system som vi ska utveckla innan vi påbörjar design och implementation. Metoden är lämplig för små projekt eller för små inkrement inom ett större projekt. Den föreskriver inga andra verktyg än en ordbehandlare. Det gör den lämplig att använda då studenter ska utföra projektarbete, de kan snabbt komma igång med projekten. Se [Lindegren-2003] för en grundlig bakgrundbeskrivning av varför metoden ser ut som den gör. 2. REFERENSER [Lindegren-2003] Lindegren, Håkan: Programvaruprojekt (2003). Lindegren och Studentlitteratur. 3. TERMINOLOGI Enhet En enhet är den minsta beståndsdelen i ett subsystem. Det kan vara en källkodsmodul i form av en H- och en CPP-fil, det kan vara en Adaspecifikation och -body, det kan vara en enskild HTML- eller ASP-fil i ett webbaserat system. Komponent En komponent byggs upp av flera enheter. Subsystem Ett subsystem är en samling av logiskt sammanhörande komponenter eller enheter, lämpliga att bygga och hantera tillsammans. System Ett system är en ordnad samling av subsystem som ska samverka med varandra. TBD TBD är en ofta utnyttjad förkortning i TPFD-dokument och mallar. TBD står för To Be Determined, ett problem som ska redas ut senare. 4. STANDARDTEXTER Här listas ett antal standardtexter som ska utnyttjas vid författande av dokument. Standardtexter underlättar för en granskare. De underlättar också för en författare så snart denne har lärt sig standardtexterna. Avsiktligt lämnad tom Använd för en fast rubrik där beslutet är att inte skriva informativ text. TBD Använd för de delar av ett dokument där sannolikheten är hög att texten kan behöva kompletteras. I valet mellan "Avsiktligt lämnad tom" och TBD bör man i inledningen av ett inkrement föredra TBD.

4 TPFD Beskrivning Rev 4 4(10) När ett dokument ska färdigställas, sök på TBD. Då det inte finns några TBD kvar är dokumentet klart för granskning. Dokumentera som återstående problem Vid problemhantering fattar man ofta beslutet att skjuta på lösningar till senare inkrement. Använd standardtexten "Dokumentera som återstående problem" för sådana problem. 5. AKTIVITETSÖVERSIKT I figur 4.1 skissas aktiviteterna i TPFD-metoden. Projektplan Initialt ska en projektplan skrivas. Den ska sedan följa projektet och planeras om vid bestämda tillfällen. Användarkrav In till ett projekt kommer en mer eller mindre luddig önskan om ett nytt system eller en förändring av ett existerande system. Denna bild ska specificeras på ett för användaren begripligt språk i användarkravspecifikationen. Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst. problem Designspec Verifiering Implementation Figur 5.1: er i TPFD-metoden Detaljkrav Användarkravspecifikationen ska formuleras om och vidarebearbetas till en detaljkravspec som i detalj ska specificera kraven på det system som ska utvecklas. Man bör sträva efter att formulera kraven på ett sådant sätt de blir enkla att testa. Testplan Testplan ska tas utvecklas i samband med detaljkraven för att förbereda testning av det byggda systemet. en bidrar också till granskning och förbättring av detaljkraven. Konfigurationsdokument Konfigurationsdokumentet ska specificera utvecklings- och målmiljö. Vidare ska den specificera hur dessa ska paketeras innan leverans. Versionshantering och manuella rutiner ska också skrivas ner. Designdokument Designdokumentet ska givet användar- och detaljkrav specificera hur systemet ska konstrueras. Arbetet med design kan påbörjas tidigt, redan i samband med att arbetet med detaljkraven börjar. Det

5 TPFD Beskrivning Rev 4 5(10) är lämpligt eftersom design är en lång, svår och trög process. Designspecifikationen kan däremot inte godkännas förrän testplanen är godkänd. Det beror på att testplanen är sista steget i kravanalysen och designspecifikation ska täcka in samtliga krav. Verifiering Verifiering innebär att granska att systemet har byggts enligt intentionerna i kravdokumenten och designspecifikationen. Test-och-felrättning Systemet ska testas enligt testplan. Testresultat ska dokumenteras i testloggar. Ickefunktionella krav som inte kan testas på ett enkelt sätt ska granskas mot det faktiska systemet. Paketering Utvecklings- och målsystem ska paketeras enligt konfigurationsdokumentet. Ändringslogg Dokument som utvecklas i flera av aktiviteterna ska godkännas. Ett godkänt dokument betecknas som stängt. Ändringsförslag ska under tiden som ett dokument är stängt skrivas ner i en ändringslogg. Ändringsloggen fungerar som indata till verifiering. Återstående problem Problem som identifieras men som inte ska lösas inom ramen för aktuell projektfas ska dokumenteras som återstående problem. Terminologi Ett terminologidokument ska upprättas omedelbart som ett projekt startar. 6. AKTIVITETER För varje aktivitet specificeras indata, vad som ska göras och utdata. Projektplanen ska ses som in- och utdata för varje aktivitet, utgå från PROJPLAN.DOC. Varje aktivitet ska avslutas med granskningar och granskningsgenomgångar. Vid projektstart ska ett terminologidokument upprättas och en ansvarig ska utses för att fylla på det dokumentet allteftersom projektet fortskrider. Utgå från TERMS.DOC. Ett dokument för återstående problem ska upprättas vid start av projektet. I detta dokument ska problem som dyker upp men som inte löses inom ramen för den här projektfasen skrivas ner. Utgå från PROBLEM.DOC. Observera att löpande problem dokumenteras under PROBLEM-rubriker i respektive dokument. Det är bara i de fall där lösning bör göras men skjuts upp till senare projektfaser som sådana problem ska föras över till återstående problem. 6.1 Projektplan En kravbild. Det kan vara en kravspecifikation från en kund eller en idé om ett nytt system som kanske bör byggas. Granska den givna kravbilden. Gör en grovplanering för projektet där TPFD-metodens aktiviteter sätts in i tidsordning. Gör dessutom en preliminär plan för hur utvecklingsmiljön ska se ut och sättas upp. Analysera risker för projektet, följ upp mot återstående problem.

6 TPFD Beskrivning Rev 4 6(10) Utgå från grunddokumentet PROJPLAN.DOC och konstruera en preliminär projektplan. Preliminär projektplan. 6.2 Konfigurationsdokument Delvis USERREQS.DOC, delvis DETREQS.DOC, delvis DESSPEC.DOC. Arbetet med konfigurationsdokumentet bör börja tidigt, helst redan innan arbetet med övriga aktiviteter. Under projektets gång bör konfigurationsdokumentet utökas i takt med att man lär sig mer. Granska indatadokumenten. Skissa på hur utvecklingsmiljö och målmiljö ska se ut. Skissa också på hur respektive miljö ska paketeras innan leverans och inför slutförande av denna fas i projektet. Glöm inte bort att även utvecklingsverktygen behöver paketeras tillsammans med utvecklingsmiljön. Utgå från grunddokumentet CONFIG.DOC och utveckla ett konfigurationsdokument. Ändringslogg med ändringsförslag mot övriga dokument. Godkänt konfigurationsdokument. 6.3 Användarkrav Samma som för projektplan. Analysera kravbilden med avseende på det realistiska och kommersiellt gångbara i den. Förkasta idén om den framstår som dålig eller orealistisk. Utgå från grunddokumentet USERREQS.DOC och utveckla en användarkravspecifikation. Fyll sedan på med krav på systemet. Godkända användarkrav. Upprättad ändringslogg där ändringsförslag kan skrivas ner. 6.4 Detaljkrav USERREQS.DOC. Granska användarkraven. Utveckla en konceptuell graf för att identifiera subsystem att dela upp kraven på. OBS! Var mycket noga med den konceptuella grafen och snegla samtidigt på hur en hierarkisk indelning i subsystem ska se ut. Den hierarkiska indelningen ska däremot inte dokumenteras här, det ska göras i designspecifikationen. Utgå från grunddokumentet DETREQS.DOC och utveckla en detaljkravspecifikation med numrerade krav på systemet som helhet och krav uppdelade på subsystemen. Ändringslogg med ändringsförslag för användarkraven. Godkända detaljkrav.

7 TPFD Beskrivning Rev 4 7(10) 6.5 Testplan DETREQS.DOC. Granska detaljkraven. Utgå från grunddokumentet TESTPLAN.DOC och utveckla en testplan för systemet. Testplanen ska definiera testfall sådana att samtliga detaljkrav testas. Den ska vidare föreskriva hur ickefunktionella krav som inte kan testas på ett enkelt sätt ska verifieras. Testplanen ska ha samma konceptuella uppdelning i subsystem som detaljkraven. en syftar dessutom till att analysera att detaljkraven är konsistenta, motsägelsefria och kompletta upp till en rimlig grad. Ändringslogg med ändringsförslag för detaljkraven. Godkänd testplan. 6.6 Designspecifikation USERRECS.DOC, DETREQS.DOC, CHGLOG.DOC Granska indatadokumenten, speciellt den konceptuella indelningen i subsystem. Skissa på en indelning och förfining av subsystemen. Identifiera eventuellt en annorlunda subsystemindelning. Glöm inte bort eventuella hjälpsystem som behöver utvecklas. Utgå från DESSPEC.DOC och utveckla en designspecifikation där subsystemen dokumenteras. Specificera utvecklings- och integrationsordning. Om ett subsystem blir omfattande, skriv en separat designspecifikation för det. Modifierad ändringslogg. Godkänd designspecifikation. 6.7 Implementation DETREQS.DOC, DESSPEC.DOC, CHGLOG.DOC Implementera subsystemen i den ordning och på det sätt som designspecifikationen föreskriver. Utnyttja manuell granskning och enhetstester för centrala subsystem, komponenter eller enheter. Modifierad ändringslogg. System klart för verifiering.

8 TPFD Beskrivning Rev 4 8(10) 6.8 Verifiering USERREQS.DOC, DETREQS.DOC, TESTPLAN.DOC, DESSPEC.DOC, CHGLOG.DOC, PROBLEM.DOC. Granska designspecifikationen. Granska systemet. Säkerställ att de subsystem som definierats i designspecifikationen har implementerats. Granska speciellt gränssnitten, stämmer alla namn som anges i designspecifikationen? Säkerställ att testförberedelser är gjorda. Utgå från VERIF.DOC och dokumentera resultatet av verifieringen och logga de rättningsåtgärder som vidtogs. Skriv ner återstående problem i PROBLEM.DOC. Verifierings- och övriga dokument godkända. System klart för test-och-felrättning. Tom ändringslogg. 6.9 Test-och-felrättning TESTPLAN.DOC Utgå från TESTLOG.DOC, upprätta en eller flera testloggar. Sätt TEST_TBD för samtliga testfall. I första steget, verifiera de ickefunktionella kraven: while ( TEST_TBD kvar för ickefunktionella krav ) loop for ( Varje testfall!= TEST_OK ) loop Kör igenom testfallet if ( Gick bra ) then Ändra status till TEST_OK elsif ( Gick fel ) then Sätt status till TEST_FEL else -- Kunde ej genomföras Sätt status till TEST_GICK_INTE end if for ( Alla testfall med status TEST_FEL ) loop Analysera felsituationen Identifiera testsekvens (sätt status till TEST_TBD) Rätta till felet Gå därefter in i en test-och-felrättningsloop för de funktionella kraven: while ( TEST_TBD kvar för funktionella krav ) loop for ( Varje testfall!= TEST_OK ) loop Kör igenom test if ( Gick bra ) then Ändra status till TEST_OK elsif ( Gick fel ) then Sätt status till TEST_FEL else -- Kunde ej genomföras Sätt status till TEST_GICK_INTE

9 TPFD Beskrivning Rev 4 9(10) end if for ( Alla testfall med status TEST_FEL ) loop Analysera felsituationen Identifiera testsekvens (sätt status till TEST_TBD) Rätta till felet Att ordningen blir så enkel som att vi kan börja med de ickefunktionella kraven för att sedan testa de funktionella kraven är inte givet. Status för samtliga testfall ska alltså vara TEST_OK eller TEST_GICK_INTE efter test-ochfelrättning. Anledningen till att TEST_GICK_INTE tas med är att vi kan hamna i situationer där vi inte kan köra igenom ett testfall. Det kan t.ex. handla om att kunden ska tillhandahålla en webbplats varifrån vi ska kunna testa vårt system, men den webbplatsen fungerar helt enkelt inte. De TEST_GICK_INTE som vi sitter kvar med får vi diskutera med kunden. Ifylld TESTLOG.DOC med TEST_OK eller TEST_GICK_INTE vid samtliga testfall. Granskad och rättad TESTPLAN.DOC. Testat system klart för paketering Paketering CONFIG.DOC. Testat system klart för paketering. Granska indata. Paketera målsystemet enligt plan. Paketera utvecklingssystemet enligt plan. Granskad och rättad CONFIG.DOC. Paketerad utvecklingsmiljö och målsystem. 7. AKTIVITETER SOM INTE SYNS I FIGUREN 7.1 Prototypning Speciellt under aktiviteterna användarkrav och detaljkrav kan det uppstå en önskan om prototypning. Det kan t.ex. handla om att reda ut hur ett grafiskt användargränssnitt ska se ut och uppträda eller hur en teknisk lösning ska se ut. En idé om en prototyp som ska utvecklas. Utgå från PROTOTYP.DOC. Definiera den prototyp som ska utvecklas. Det är speciellt viktigt att definiera begränsningar för en prototyp. Godkänd prototypplan.

10 TPFD Beskrivning Rev 4 10(10) 7.2 Enhetstest Under arbetet med design bör man identifiera enheter som det ska utföras enhetstester emot. Detaljkrav och designspecifikation. Utgå från indatadokumenten, den enhet som ska testas. Upprätta ett dokument för enhetstest, utgå från UNITTEST.DOC. Fyll i testfall sådana att extremfallen och minst ett normalfall testas. Säkerställ att inga oönskade felfall kan inträffa. Upprätta därefter en testlogg för enheten, utgå från UNITLOG.DOC. Sätt markören TEST_TBD vid varje testfall. Gå in i test-och-felrättningsloop: while ( TEST_TBD kvar ) loop for ( Testfall!= TEST_OK ) loop Testa if ( Gick bra ) then Ändra status till TEST_OK else Sätt status till TEST_FEL end if for ( Alla testfall med status TEST_FEL ) loop Analysera felsituationen Identifiera testsekvens (sätt status till TEST_TBD) if ( Fel i testdrivare eller stubbe ) then Rätta till testkoden else -- fel i enheten Rätta till enheten end if Observera att här betraktas inte status TEST_GICK_INTE som acceptabelt. Ifyllt och godkänt enhetstestdokument. Testprogram dokumenterat och lagrat enligt konfigurationsdokumentet. Testlogg med samtliga testfall markerade TEST_OK. ÖVRIGT Kom ihåg att varje aktivitet är i sig en iterativ process. erna överlappar därtill varandra vilket gör det hela mycket komplicerat. Systemutveckling blir inte lätt med TPFD-metoden, däremot får man stöd för vad man bör tänka på.