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



Relaterede dokumenter
Struktureret system udvikling Minimodul 1: Introduktion, UML og use cases

Struktureret system udvikling Minimodul 3: SPU/UML modellen

Struktureret system udvikling Minimodul 3: SPU/UML modellen

Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest

SPU UML note. Systematisk Program- Udvikling med UML. Finn Overgaard Hansen

SPU UML note. Systematisk Program- Udvikling med UML. Finn Overgaard Hansen

Struktureret system udvikling Minimodul 1: Introduktion, projekt- og tidsplanlægning

Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest

Struktureret system udvikling Minimodul 2: UML og use cases

Uge 5.3: (Search,) Select & implement and development methods

Struktureret system udvikling Minimodul 3: Kravspecifikation og accepttest

Jens Myrup Pedersen Adjunkt. Department of Control Engineering Center for Network Planning. SPU 1. kursusgang

extreme Programming Kunders og udvikleres menneskerettigheder

3D GeoInformation. Systemudvikling. 1. Introduktion til Systemudvikling og Projektmodeller. Systemudvikling L Lars Bodum

Agil-model versus V-model set i lyset af en testers dilemmaer

SOFTWARE PROCESSES. Dorte, Ida, Janne, Nikolaj, Alexander og Erla

Struktureret system udvikling Minimodul 4: Introduktion til systematisk design

2a. Conceptual Modeling Methods

Struktureret system udvikling Minimodul 4: Struktureret ProgramUdvikling (SPU) - I

P1-projekteksamen NANNY. Nøgleordsbaseret netværksovervågning Gruppe B226

Model og Metode til Programudvikling. Jens Dalsgaard Nielsen

UML-Light (Note: UML-Light T133, ver. 2004) Finn Overgaard Hansen, IHA

Fra Computer til Virkelighed. TPE-kursus Elektroniske Systemer P1

Brugervejledning - trin for trin til VIRMIK med PathXL based on contents Note: Eksamen SMEA0615E er brugt som eksempel

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Design by Contract Bertrand Meyer Design and Programming by Contract. Oversigt. Prædikater

Svendeprøve Projekt Tyveri alarm

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation

Usability-arbejde i virksomheder

Forelæsning den 31. marts 2003

Analyse af aktiviteter. Uge 8

Succesfuld implementering af automatiseret test

Central Statistical Agency.

PC-baseret analyzer og equalizer

Succes i byggeriet hvad er det, og hvordan måles det? Kristian Kreiner Netværket Ledelse i byggeriet 26. oktober 2011

Shared space - mellem vision og realitet. - Lyngby Idrætsby som case

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Projektstyring

3C03 Concurrency: Model-based Design

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

DSB s egen rejse med ny DSB App. Rubathas Thirumathyam Principal Architect Mobile

Behavior Driven Test and Development. ebay Classifieds

Algorithms & Architectures II

UML til kravspecificering

Forelæsning den 18. marts 2002

how to save excel as pdf

Program Dokumentation PC Software Skrevet af. Gruppen. Version 1.0

IBM Network Station Manager. esuite 1.5 / NSM Integration. IBM Network Computer Division. tdc - 02/08/99 lotusnsm.prz Page 1

Ventetider i projekter

Idékatalog Planlægning og brug af test i statslige it-projekter

Introduktion til Systemudvikling Efteråret 2002

Iterativ og Agil udvikling

Velkommen til. Kravspecifikation i Softwareudvikling Workshop hos Brüel & Kjær. 14. september 2012,

Portal Registration. Check Junk Mail for activation . 1 Click the hyperlink to take you back to the portal to confirm your registration

- Erfaringer med implementering af MES løsninger. SESAM RAMBØLL, d 31. marts DC Produktions IT Projekt Afdelingen Arne Boye-Møller

Netværk & elektronik

ECE 551: Digital System * Design & Synthesis Lecture Set 5

Revision af studieordninger

It-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Pain Treatment Survey

Design by Contract. Design and Programming by Contract. Oversigt. Prædikater

From Human Factors to Human Actors - The Role of Psychology and Human-Computer Interaction Studies in System Design

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Hvor er mine runde hjørner?

Process Mapping Tool

Advanced Word Template Brugermanual

Vejledning til udviklingsprocessen for projekt 2

Design til digitale kommunikationsplatforme-f2013

CHAPTER 8: USING OBJECTS

Barnets navn: Børnehave: Kommune: Barnets modersmål (kan være mere end et)

Musik afspiller Michael Frøstrup Andersen

Projekthåndbog E- og IKT projekter

Learnings from the implementation of Epic

MitID. 23. april 2018 Mogens Rom Andersen Digitaliseringsstyrelsen

Når fremtiden møder udbudsloven

Agenda. The need to embrace our complex health care system and learning to do so. Christian von Plessen Contributors to healthcare services in Denmark

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation

Software Dokumentation

Cost-effektivt Design Med UML 16. oktober 2006

Hvad kan sammenlignende etnografiske undersøgelser betyde for effektmålinger af on-line konsultationer?

Software Design (SWD) Spørgsmål 1

Datalogi V-Systemdesign og HCI

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Undervisningsbeskrivelse

CURRICULUM VITAE. Personlige oplysninger. Michael Alrøe. Uddannelse. Kurser og efteruddannelse. Michael Alrøe. Navn Fødselsår 1964 LinkedIn

dfgfdhsjfgdghjghfkfhgkfhjsrt Test som praktisk håndværksdisciplin Sara Stürup Willer

Brugerdreven innovation

Strings and Sets: set complement, union, intersection, etc. set concatenation AB, power of set A n, A, A +

Fag: Projekt E1PRJ1 Emne: Kravspecifikation Softdrink-Automat Gruppe: 6 Dato: 10. april 2003 Medlemmer: Benjamin Sørensen, Joanna Christensen, Jacob

DM536. Rapport og debug

Best Practice for it og automationsprojekter Huskeliste med råd og erfaringer

Agenda. Hvad er Smart City og hvem er aktørerne? Udfordringer. Muligheder

Terese B. Thomsen 1.semester Formidling, projektarbejde og webdesign ITU DMD d. 02/

NoteSync vejledning. Leba Innovation A/S

Linear Programming ١ C H A P T E R 2

Fra ER-Diagram til Relationel model i 7 step

South Baileygate Retail Park Pontefract

mandag den 23. september 13 Konceptkommunikation

WINDCHILL THE NEXT STEPS

Webside score templatedownload.org

Transkript:

Model og metode til programudvikling 2004 minimodul 11: Struktureret/Systematisk System Udvikling Kursusholder: Ove Andersen Om undertegnede... Ove Andersen, civ. ing., 1989, ph.d. 2003 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... 1. 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.

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)

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

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

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.

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'...

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)

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...

UML Use Case Notation (Basic) UML (Unified Modeling Language) = en OMG (Object Management Group) standard (www.omg.org) 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

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

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