Model og metode til programudvikling. Om undertegnede... Struktureret Systemudvikling. Dagens menu... Tankevækkende erfaringer med systemudvikling...

Transkript

1 Model og metode til programudvikling 2004 minimodul 11: Struktureret/Systematisk System Udvikling Kursusholder: Ove Andersen Om undertegnede... Ove Andersen, civ. ing., 1989, ph.d arbejdet på diverse nationale og internationale projekter om taleteknologi megen erfaring med u-struktureret systemudvikling knap så megen erfaring med struktureret systemudvikiling erfaring med SPU metoden fra et 27 måneders udviklingsprojekt med TeleDanmark, Københavns Universitet, Speech-Ware og Aalborg Universitet Struktureret Systemudvikling De følgende fire minimoduler: mm11: Struktureret systemudvikling mm12: Krav- og accepttestspecifikation mm13: Black-box test mm 14: White-box test Dagens menu... Struktureret systemudvikling Vandfaldsmodeller UML og SPU Iterative modeller Oplæg til næste forelæsning vedr. kravspecifikation og accepttest Opgaveregning Tankevækkende erfaringer med systemudvikling Cirka hvilken procentdel af softwareudviklingsprojekter, der påbegyndes, bliver også færdiggjort? 70-79% 2. En undersøgelse af USAs Government Accounting Office i 1979 fandt følgende for softwareudviklingskontrakter: 2 % blev brugt som de var leveret. 3 % blev brugt efter ændringer. 45 % blev stoppet eller ændret. 20 % blev leveret men ikke brugt. 30 % blev betalt for men ikke leveret.

2 3. En mere nutidig undersøgelse (1995) af 365 IT-arbejderes produkter fandt følgende statistik for softwareudviklingsprojekter: 16% var en succes. 53% kunne køre (men var ikke ligefrem en succes). 31% blev stoppet. Ustruktureret vs. struktureret systemudvikling 4. Hvilken procentdel af softwarebudgettet for en IT-virksomhed udgør softwarevedligeholdelse? Gennem 1980 erne: 60% Gennem 1990'erne: 80% Konklusion Udvikling er ikke let, specielt ikke hvis det skal ende med succes! Hvornår skal man ikke anvende struktureret systemudvikling? Når der udarbejdes et minimalt personligt system til engangsbrug!! Højere succesrate: Struktureret/systematisk Systemudvikling Hvornår skal man anvende struktureret systemudvikling? Ellers altid! Hvorfor? Tidsstyring Vedligeholdelse Dokumenentation Risikominimering Kvalitetsoptimering Genbrug m.m. Systemudvikling Systemudvikling er mere håndværk end videnskab! Der markedsføres mange forskellige metoder! Ingen passer præcist til nogen situation! Skal skræddersys til det aktuelle tilfælde! To metoder I vil støde på i løbet af tiden på AAU: Struktureret SystemUdvikling (el. Systematisk SystemUdvikling) - SPU Objekt Orienteret Analyse og Design (OOAD)

3 SPU-UML konceptet SPU - udviklingsmodellen 1. Benyt en udviklingsmodel 2. Udarbejd en kravspecifikation 3. Design før kodning 4. Planlæg test 5. Anvend reviewteknikken 6. Foretag projektstyring 7. Dokumentér undervejs 8. Foretag konfigurationsstyring SPU-udviklingsmodel Kravspecifikationsfasen omfatter: kravspecifikation accepttest-specifikation foreløbig brugervejledning prototype Programdesign omfatter: opdeling i parallelle processer og fælles moduler eksterne grænseflader interne grænseflader synkronisering procesintegrations-specifikation hvordan udviklingsrækkefølge (kritiske først) Procesdesign: procesdesign (opdeling i moduler) sekventielt program grænseflader fællesmoduler specifikation for hvert modul modulintegrations-specifikation integration test

4 Moduldesign: moduldesign (hvordan) detail-design af funktioner og datastrukturer detaljeringsgrad er umiddelbart over kildekode modultest-specifikation black-box test white-box test Modulkodning: omsætning af design til kildekode følge kodningsstandard Kodegranskning når koden kan compileres forbedret omhu nedbrudt ejerskab uddannelseseffekt Modultest overholdes modulspecifikation? testdrivere og teststubbe gerne automatiseret Modultestrapport Modulintegration samling af moduler (trinvis vs. samlet) test af moduler Integrationstestrapport Procesintegration samling af moduler parallelle processer kommunikation mellem processer Accepttest opfyldes kravspecifikation Accepttestrapport Procesintegrationstestrapport 4

5 SPU s V-model (SW) Resultater fra SPU faserne Kravspec. Programdesign Procesdesign Moduldesign Modultest Accepttest Procesintegration Modulintegration Implementation. Bekendt situation? Tre grundlæggende modeller Basic Life-Cycle/Process Models Ad-hoc Development Waterfall Models Iterative Models Ref.: Darryl Green and Ann DiCaterino, (1998) "A Survey of System Development Process Models" Ad-hoc udvikling Karakteriseret ved: ingen eksplicit udviklingsmodel afhængighed af de enkelte projektdeltagers evner og erfaringer kaotisk/tilfældig upræcise tidsplaner usikre budgetter uklar funktionalitet inkonsistent produkt kvalitet dårlig basis for forbedringer af produktivitet og kvalitet Ad-hoc udvikling - fortsat Passer denne beskrivelse på noget I er stødt på tidligere?? Kan føre til enestående resultater, men dette skal tilskrives enkeltpersoner/hold og ikke organisation!!! Ingen garanti for efterfølgende resultater.

6 Vandfaldsmodel Første strukturerede metode til system udvikling Storhedstid i 70 erne og 80 erne, men benyttes stadig (endda med succes)! Fryser kravspecifikationer Et eksempel Udvikling af MS Word var i slutningen af 1980 erne baseret på vandfaldsmodellen (streng sekventiel udvikling) Estimeret til at tage 365 dage Endte med at tage 1187 dage John Hogan, Developers sink 'waterfall' in favor of 'sync Vandfaldsmodel Fordele: God basis for gennemført og konsistent design Vedligeholdelsesvenligt resultat Mindre og/eller overskuelige/veldefinerede projekter Ulemper: virklighedens projekter følger sjældent et strengt sekventielt forløb ingen garanti for at brugeren får det ønskede! dårlig tilpasning til ændrede omstændigheder stor usikkerhed i starten af projektet (lyder det bekendt?) intet kørende system før til slut i projektforløbet? Iterativ model Iterativ = inkrementel Hver iteration = mini-vandfaldsmodel Fordele: hurtigere demonstrerbare resultater mindre krav til specifikation af krav større fleksibilitet Iterativ model - fortsat Problemer: slutbrugerne skal være aktivt involverede => tage tid fra udviklingen kommunikation og koordination essentielle stigende krav ( mer-vil-have-mer ) (eng. scope-crepe ) Ad-hoc Development Variationer over den Iterative Model Basic Life-Cycle/Process Models Waterfall Model Iterative Models Prototyping / RAD Exploratory Model The Spiral Model The Reuse Model 'Synch-and-stabilize'...

7 SPU-UML Spiralmodel for styring Iterativ udgave af traditionel SPU For såvel SW som HW udvikling Indeholder vandfaldsmodellen som specialtilfælde De fire perspektiver: ROPES Rapid Object-oriented Process for Embedded Systems Spiralmodel Fordele: minimere risiko (dele forbundet med størst usikkerhed/risiko udvikles tidligt) synliggøre udviklingsforløb korte lærecykler (vigtig ved ny teknologi) Udviklingsmodel Udgangspunkt: X Use Cases Parallel udvikling af SW og HW Testmodel (V-model)

8 Leverance-model Velegnet til styring (8 milepæle) Kravspecifikation Komplet kravspecifikation: Kravspecifikation - fortsat Usikkerhed om specifikke krav: Opsamling Struktureret/systematisk systemudvikling Vandfaldsmodeller UML og SPU Iterative modeller Oplæg til næste forelæsning vedr. kravspecifikation og accepttest Use Cases i kravpsec. OPGAVEREGNING...

9 UML Use Case Notation (Basic) UML (Unified Modeling Language) = en OMG (Object Management Group) standard ( OMG er en sammenslutning af ca. 800 virksomheder. UML anvendes i dag verden over som beskrivelsesværktøj i forbindelse med udviklingsprojekter. Actor Use Case Participates-In Association System Boundary (often implied) Customer Use Case (Basic) Example Online shop Place Order Process Customer Bill Ship Order Sales Clerk Financial Institution Use Case En Use Case: specificerer en komplet funktionalitet, som har værdi for brugeren actor (bruger) befinder sig eksternt i forhold til systemet. Kan være en person, hardware, m.m. actor er karakteriseret ved sin rolle, hvilket også skal fremgå af navnet! systemet betragtes som en black box skal ikke omhandle design! kun det antal use cases der er nødvendige for at forstå systemets funktionalitet Use Cases (Advanced) Use Case (Advanced) Example Actor Base Use Case Specialized Use Case Base Use Case Base Use Case <<extend>> Extending Use Case Customer Place Order <<extend>> Handle Rush Order <<include>> Validate User Special Actor Special Actor <<include>> Included Use Case Commercial Customer Residential Customer Check Password

10 Use Case Modeling: Core Elements Construct Description use case actor system boundary A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A coherent set of roles that users of use cases play when interacting with these use cases. Represents the boundary between the physical system and the actors who interact with the physical system. Syntax UseCaseName ActorName Construct Description Syntax association generalization extend Use Case Modeling: Core Relationships The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other. A taxonomic relationship between a more general use case and a more specific use case. A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case. <<extend>> Use Case Modeling: Core Relationships (cont d) Construct Description Syntax include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case. <<include>> Use Case Beskrivelse Use Case navn: f.eks. overvåg temperatur Målbeskrivelse: hvad er det use case n tilbyder aktøren Normal scenario: beskrevet ved et antal trin Undtagelser: beskrivelse af undtagelser og afvigelser samt hvordan de håndteres af systemet Eksempel: MP3 afspiller Tekstuel beskrivelse Lytteren Uploader PC MP3 afspiller Afspil mp3 fil Vis ID-tag info Upload af mp3 filer Forstærker anlæg Use Case Navn: Afspil mp3 fil Målbeskrivelse: På baggrund af lytterens valg dekodes og afspilles en mp3 fil Nomal scenario: 1. Lytteren tænder for mp3 afspilleren 2. Et musiknummer vælges 3. Dette afspilles 4. Afspilning stopper

11 Tekstuel beskrivelse (fortsat) Undtagelser: Enkodningen ikke understøttet 1. send besked til display 2. fortsæt til næste nummer Ingen filer uploaded 1. send besked til display