DSDM

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 28. marts 2021; checks kræver 8 redigeringer .

Dynamic Systems Development Method (DSDM) er primært en softwareudviklingsteknik baseret på konceptet Rapid Application Development (RAD). DSDM er en iterativ og inkrementel tilgang, der lægger vægt på fortsat bruger-/forbrugerinddragelse i processen.

Målet med metoden er at levere det færdige projekt til tiden og inden for budgettet, samtidig med at man håndterer ændringer i projektkrav under udviklingen. DSDM er en del af en familie af agil softwareudvikling og ikke-informationsteknologiske udviklinger.

Den seneste version af DSDM hedder DSDM Atern. Navnet Atern er en forkortelse for Arctic Tern. Polarternen er en fugl , der kan rejse lange afstande. Det symboliserer mange aspekter af metoden, såsom prioritering eller samarbejde, som er en naturlig måde at køre en arbejdsgang på.

Den tidligere version af DSDM (udgivet i maj 2003), som stadig er gyldig og meget brugt, er DSDM 4.2, som er en lidt udvidet version af DSDM 4. Den udvidede version indeholder vejledning i, hvordan man bruger DSDM i forbindelse med Extreme Programming.

Oversigt over DSDM Atern

I 2007 undersøgte et hold dannet af DSDM-konsortiet essensen af ​​metoden og besluttede, at de grundlæggende mekanismer og struktur var velskrevet, men metodens terminologi og opmærksomhed var fuldstændig fokuseret på informationsteknologiområdet. Derfor skal de forbedres for at imødekomme behovene for projekter i det nye årtusinde (en del af metoden har ikke ændret sig siden 1995). Den nye version blev udgivet den 24. april 2007 på Cafe Royale i London.

Oversigt over DSDM version 4.2

Som en forlængelse af konceptet med hurtig applikationsudvikling fokuserer DSDM på informationssystemprojekter præget af stramme deadlines og budgetter. DSDM indeholder indikationer på typiske fejl ved informationssystemprojekter, såsom overskridelse af budgettet, forsinket levering (udførelses-) deadlines, utilstrækkelig inddragelse af brugere og topledere i arbejdet med projektet. DSDM består af:

Under visse betingelser er det muligt at inkludere dele af andre metoder i DSDM, såsom Rational Unified Process (RUP), Extreme Programming, PRINCE2. En anden fleksibel metode, der ligner DSDM i proces og koncept er Scrum .

DSDM-metoden blev udviklet i Storbritannien i 1990'erne af DSDM Consortium. DSDM-konsortiet er en sammenslutning af softwareudviklere og eksperter etableret med det formål at "i fællesskab udvikle og fremme en uafhængig RAD-ramme" ved at kombinere den bedste praksis fra foreningens medlemmer. DSDM-konsortiet er en non-profit organisation af uafhængige udviklere, der ejer og driver DSDM-rammen. Den første version af rammen blev afsluttet i januar 1995 og offentliggjort i februar 1995. I juli 2006 blev open source-versionen af ​​DSDM 4.2 frigivet og gjort tilgængelig for enkeltpersoner til visning og brug. Enhver, der distribuerer DSDM, skal dog være medlem af dette non-profit konsortium.

DSDM og DSDM-konsortiet - tidlige dage

I begyndelsen af ​​1990'erne begyndte et nyt udtryk at brede sig i informationsteknologiindustrien - Rapid Application Development (RAD). Applikationssoftware brugergrænseflader har udviklet sig fra de gamle grønne skærme til de grafiske brugergrænseflader, der stadig er i brug i dag. Nye applikationsbygningsværktøjer begyndte at komme ind på markedet, såsom PowerBuilder . De gjorde det lettere for udviklere at dele deres planlagte udviklinger med kunder - prototyping dukkede op, og ødelæggelsen af ​​klassiske, sekventielle (kaskadende) udviklingsmetoder begyndte.

Den nye RAD-bevægelse var dog meget ustruktureret: Der var ingen aftalt beskrivelse af metoden, og mange organisationer lavede deres egne beskrivelser og tilgange til den. Mange store virksomheder var interesserede i de muligheder, metoden gav, men de var også bekymrede for, at kvalitetsniveauet af deres produkter ikke ville falde i slutresultatet.

DSDM-konsortiet blev dannet i 1994, da en gruppe mennesker mødtes til et arrangement arrangeret af Butler Group i London. Alle, der kom til dette arrangement, arbejdede i store organisationer som British Airways, American Express, Oracle og Logica (virksomheder som Data Sciences og Allied Domecq er siden blevet overtaget af andre organisationer).

På dette møde blev det besluttet, at Jennifer Stapleton, dengang fra Logica, ville udvikle en omfattende, brugercentreret metode med god kvalitetskontrol til iterativ og inkrementel udvikling. Den resulterende arkitektur blev designet til at være fuldt ud kompatibel med ISO 9000 og PRINCE2. Da arkitekturen var klar (en måned efter mødet), dannede konsortiet grupper til at distribuere den inden for alle områder af softwareudvikling, som omfattede: projektledelsesmetoder og værktøjer, kvalitetskontrol og test, udviklingsmetoder og værktøjer. En kontrolgruppe, ledet af arkitekten og bestående af lederne af disse grupper, skulle sikre, at metoden blev forstået, som den oprindeligt var tænkt.

På trods af at mange medlemmer af konsortiet var direkte konkurrenter, delte de frit, hvordan de løser problemer, der opstår. Praksis har vist, at det bedste resultat kun kan opnås ved at arbejde som en helhed. Konsortiet er vokset - på det første år fra flere organisationer til tres; beskrivelsen af ​​metoden blev mere og mere komplet. Version 1 blev dannet i december 1994 og offentliggjort i februar 1995. Resultatet er en universel metode, der favner mennesker, processer og værktøjer. Det blev dannet på grundlag af erfaringerne fra organisationer, der adskiller sig i arten af ​​deres aktiviteter og størrelser.

DSDM-metode

Principper

Der er 9 principper, bestående af 4 grundlæggende og 5 udgangspunkter.

Forudsætninger for at bruge DSDM

For at kunne bruge DSDM skal en række forudsætninger være opfyldt. For det første er det nødvendigt at organisere samspillet mellem projektteamet, fremtidige brugere og topledelsen. For det andet skal det være muligt at opdele projektet i mindre dele, hvilket vil muliggøre en iterativ tilgang.

To eksempler på projekter, hvor DSDM ikke er velegnet:

Projektets livscyklus

Oversigt: De tre stadier af DSDM

DSDM-rammen består af tre på hinanden følgende faser, som kaldes forprojektfasen, projektets livscyklusfase og postprojektfasen. Projektets livscyklusfase er den mest gennemtænkte og detaljerede af alle de andre. Den består af fem trin, der danner en iterativ, trinvis tilgang til udvikling af informationssystemer. Disse tre faser og deres respektive trin vil blive beskrevet mere detaljeret i de følgende afsnit. For hvert trin eller trin vil de vigtigste funktioner blive gennemgået, og resultaterne vil blive præsenteret.

Fase 1 - Forprojekt På dette stadium identificeres sandsynlige projekter, midler tildeles og projektteamet identificeres. Løsning af problemer på dette stadium vil hjælpe med at undgå problemer på senere stadier af projektet. Fase 2 - Projektets livscyklus Nedenstående figur viser denne fase. Den viser 5 stadier, som et projekt skal igennem for at blive et informationssystem. De første to faser, feasibility-undersøgelsen og den økonomiske feasibility-undersøgelse, forløber sekventielt og supplerer hinanden. Efter afslutningen af ​​disse faser foregår iterativ og trinvis udvikling af systemet i etaper: oprettelse af en funktionel model, design og udvikling, implementeringsfase. Den iterative og inkrementelle karakter af DSDM vil blive beskrevet i det følgende. Fase 3 - Efterprojekt På dette stadium sikres en effektiv drift af systemet. Dette opnås ved at vedligeholde projektet, forbedre det og rette fejl i henhold til principperne for DSDM. Projektet er understøttet af fortsat udvikling baseret på den iterative og inkrementelle karakter af DSDM. I stedet for at gennemføre et projekt i én cyklus, er det almindeligt at gå tilbage til tidligere stadier eller milepæle for at forbedre produktet.

Nedenstående diagram viser hele livscyklussen for et projekt. Dette diagram beskriver den iterative udvikling af DSDM. En beskrivelse af hver fase vil blive præsenteret nedenfor.

De fire faser af projektets livscyklusfase

Handling Subaktion Beskrivelse
Undersøgelse Forundersøgelse På nuværende tidspunkt afgøres det, om projektet falder ind under DSDM. I betragtning af projekttype, organisatoriske og personalemæssige forhold tages der stilling til, om der skal anvendes DSDM-metoden eller ej. På denne måde opnås en anvendelighedsrapport, en acceptabel prototype og en tilnærmet global projektplan, som omfatter en udviklingsplan og en protokol over mulige risici.
Forundersøgelse På dette stadium analyseres de vigtigste økonomiske og teknologiske karakteristika. Der afholdes et ekspertmøde, hvor de vigtigste aspekter af systemet drøftes, og der tages stilling til udviklingsprioriteter. På dette trin udvikles en liste over grundlæggende krav, en beskrivelse af forretningsomfanget, en beskrivelse af systemarkitekturen og en grov prototypingsplan.
Oprettelse af en funktionel model Definition af en funktionel prototype Definition af den funktionalitet, der vil blive inkluderet i prototypen på dette stadium. På denne delfase udvikles en funktionel model i overensstemmelse med de resultater, der er opnået på stadiet af undersøgelsen af ​​økonomisk gennemførlighed.
Koordinering af planer Der er enighed om hvordan og i hvilken tidsramme prototypens funktionalitet skal udvikles.
Oprettelse af en funktionel prototype Udvikling af en funktionel prototype, efter planer og en funktionel model.
Funktionel prototypeanalyse Kontrol af sundheden for den udviklede prototype. Dette kan opnås ved slutbrugertest af prototypen og/eller revision af dokumentationen. Resultatet er et dokument, der indeholder en oversigt over den funktionelle prototype.
Design og udvikling Design Prototype Definition Definition af funktionelle og ikke-funktionelle krav til systemet. På baggrund af disse krav bør der udarbejdes en implementeringsstrategi. Hvis der findes en testpost fra en tidligere iteration, vil den også blive brugt til at oprette implementeringsstrategien.
Koordinering af planer Der er enighed om, hvordan og i hvilken tidsramme de stillede krav skal implementeres.
Oprettelse af en konstruktiv prototype Oprettelse af et system (konstruktiv prototype), der kan gives til brugere til test.
Strukturel prototypeanalyse Kontroller rigtigheden af ​​det designede system. Dette undertrin anvender test og gennemgang af resultaterne. Udarbejdelse af brugerdokumentation og testrapport.
Implementering Systemgodkendelse af brugeren Slutbrugere godkender det testede system til implementering og vejledning.
Brugertræning Træning af den fremtidige bruger til at arbejde med systemet. Resultatet af delfasen er et kontingent af uddannede brugere.
Implementering Implementering af det testede system blandt brugere.
System markedsanalyse Analyse af virkningen af ​​det frigivne system på markedet. Hovedspørgsmålet er, om det mål, der blev sat ved design af systemet, er nået. Ud fra dette går projektet til næste fase (efterprojekt) eller vender tilbage til det forrige til revision. Analysen vil blive præsenteret i projektanalysedokumentet.

De fire faser af projektets livscyklus

Fase 1A: Gennemførlighedsundersøgelse

I denne fase kontrolleres projektets gennemførlighed under DSDM. Forudsætningerne for at bruge DSDM kontrolleres ved at besvare spørgsmålene: "Kan dette projekt opfylde de nødvendige økonomiske krav?", "Projektet er velegnet til at bruge DSDM-metoden?" og "Hvad er de vigtigste risici i dette projekt?". Den vigtigste metode på dette stadium er brugen af ​​arbejdsgrupper.

Resultatet af denne fase er en rapport om anvendelighed og en acceptabel prototype, som overvejer projektets gennemførlighed, samt en tilnærmet global projektplan og en protokol over mulige risici, der beskriver de vigtigste risici ved projektet.

Fase 1B: Gennemførlighedsundersøgelse

Forundersøgelsen udvider og supplerer forundersøgelsesfasen. Efter at projektet er blevet anerkendt som gennemførligt inden for rammerne af DSDM, kontrolleres forretningsprocesser på dette stadium, brugergrupper inddrages og deres krav og ønsker analyseres. Og igen, den mest populære metode på dette stadium er brugen af ​​arbejdsgrupper. Som en del af arbejdsgrupperne samles projektdeltagerne for at diskutere det planlagte system. Oplysninger indhentet efter disse begivenheder er samlet i en liste over krav. Et vigtigt træk ved denne liste er fordelingen af ​​prioriteter blandt kravene. Disse krav er fordelt efter MoSCoW-metoden. Ud fra den modtagne sekvens laves en udviklingsplan, som vil være vejledende for hele projektet.

For at lave denne plan bruges en meget vigtig teknik til projektet - time-boxing. Denne metodik er essentiel for at nå målene for DSDM – overholde deadlines og budget, og samtidig opretholde den nødvendige kvalitet af produktet. Systemarkitekturen er en anden hjælp til at styre udviklingen af ​​et informationssystem. Outputtet af denne fase er en forretningsomfangsbeskrivelse, der indeholder konteksten for projektet i virksomheden, en systemarkitekturbeskrivelse, der giver en indledende global arkitektur for informationssystemet under udvikling, og en udviklingsplan, der skitserer de vigtigste trin i udviklingsproces. Disse to dokumenter er baseret på en liste over krav. Protokollen over mulige risici er suppleret med de data, der er opnået på dette stadium.

Trin 2: Oprettelse af en funktionel model

De krav, der blev defineret i det foregående trin, omdannes til en funktionel model. Den består af en fungerende prototype og modeller. Prototyping er en nøgleprojektteknik på dette stadium, som gør det muligt at organisere brugerinddragelse i projektet. Den udviklede prototype analyseres af forskellige brugergrupper. For at opnå den krævede kvalitet udføres test ved hver iteration. Den vigtigste del af testen præsenteres på dette stadium. Oprettelsen af ​​en funktionel model kan opdeles i følgende underfaser:

  • Definition af en funktionel prototype: definition af den funktionalitet, der vil blive inkorporeret i prototypen på dette stadium.
  • Koordinering af planer: der er enighed om hvordan og i hvilken tidsramme prototypens funktionalitet skal udvikles.
  • Oprettelse af en funktionel prototype: udvikle en prototype. Undersøg og forfin prototypen ved denne iteration i henhold til den funktionelle prototype opnået ved tidligere iterationer.
  • Analyse af den funktionelle prototype: at kontrollere sundheden for det designede system. Dette undertrin anvender test og gennemgang af resultaterne.

Resultatet af dette trin er en funktionel model og en funktionel prototype, som tilsammen repræsenterer den funktionalitet, der opnås i denne iteration, klar til brugertest. Dernæst opdateres listen over krav - allerede implementerede varer fjernes fra den, og rækkefølgen af ​​de resterende varer ændres igen. Protokollen over mulige risici opdateres også efter analysen af ​​den funktionelle prototype.

Fase 3: Design og udvikling

Hovedformålet med denne iteration er at kombinere de funktionelle komponenter fra den forrige fase til et enkelt system, der opfylder brugernes krav. Her tages der også hensyn til ikke-funktionelle krav. Og igen på dette stadium finder test sted. Design og udvikling kan opdeles i følgende underfaser:

  • Definition af en designprototype: Definition af de funktionelle og ikke-funktionelle krav, som systemet skal have.
  • Koordinering af planer: der er enighed om hvordan og i hvilken tidsramme de opstillede krav skal implementeres.
  • Strukturel prototyping: Oprettelse af et system, der kan gives til brugere til daglig brug. Undersøg og forfin prototypen ved denne iteration.
  • Analyse af en konstruktiv prototype: Tjek det designede systems sundhed. Dette undertrin anvender test og gennemgang af resultaterne. Testrapporten og brugerfeedback bruges til at oprette brugerdokumentation.

Resultatet af etapen er skabelsen af ​​en konstruktiv prototype til brugertest. Det testede system fortsætter til næste fase. På dette stadium er systemets udseende og funktionalitet generelt klar. Et andet resultat er oprettelsen af ​​brugerdokumentation.

Fase 4: Implementering

På implementeringsstadiet bliver det testede system sammen med brugerdokumentation leveret til fremtidige brugere, og de trænes i at arbejde med systemet. Systemet analyseres for overholdelse af de krav, der stilles i de tidlige faser af projektet. Implementering kan opdeles i følgende undertrin:

  • Brugervalidering af systemet: Slutbrugere validerer det testede system til implementering og vejledning.
  • Brugertræning: træning af den fremtidige bruger til at arbejde med systemet. Resultatet af delfasen er et kontingent af uddannede brugere.
  • Implementering: implementering af det testede system blandt brugere.
  • System markedsanalyse: analyse af virkningen af ​​det frigivne system på markedet. Hovedspørgsmålet er, om det mål, der blev sat ved design af systemet, er nået. Ud fra dette går projektet til næste fase (efterprojekt) eller vender tilbage til det forrige til revision.

Resultatet af etapen: et komplet system, der er egnet til brug af slutbrugere, et kontingent af uddannede brugere og et detaljeret projektanalysedokument.

Stadiet med at skabe en funktionel DSDM-model

Metadatamodel

Relationer mellem begreber på stadiet med at skabe en funktionel model er vist i modellen i nedenstående figur.

koncept Beskrivelse
Protokol over mulige risici Protokol over opdagede risici. Vigtigt for efterfølgende faser, indeholder problemer, der sandsynligvis vil blive stødt på. Bør løbende opdateres.
Liste over krav efter prioritet Liste over krav sorteret efter prioritet. Distributionsprocessen er baseret på MoSCoW-metoden, som bestemmer, hvilke krav der skal implementeres først (ud fra et økonomisk synspunkt)
Liste over ikke-funktionelle krav En liste over ikke-funktionelle krav, der skal behandles i næste trin.
Funktionskrav Denne funktion bruges til modelbygning og prototyping efter prioritering.
funktionel model En model bygget på baggrund af funktionelle krav. Det vil blive brugt til at udvikle prototypen i næste deltrin. Denne model vil blive brugt til at skabe prototypeplanen.
prototyping Processen med hurtigt at bygge en arbejdsmodel (prototype) til at teste designs, illustrere ideer og funktioner og indsamle brugerfeedback tidligt.
Liste over tidsintervaller En liste over tidsintervaller for udførelse af individuelle arbejder er nødvendig for at passe ind i tidsplanen for gennemførelsen af ​​hele projektet.
Prototyping plan En plan for prototypingsprocessen, der skal afsluttes i tidsintervaller som planlagt.
Driftsplan Et sæt værker og tidspunktet for disse værker, aftalt af udviklerne. Anvendes ved implementering af en funktionel prototype.
funktionel prototype En prototype, der giver dig mulighed for at se alle systemets funktioner, og hvordan systemet vil udføre disse funktioner.
Gennemførelsesplan Udarbejdelse af arbejder til implementering af en funktionel prototype i henhold til arbejdsplanen og kravlisten.
Forbedret funktion En prototypefunktion, der er blevet forbedret og testet i denne iteration, inden den blev slået sammen med andre dele af prototypen.
Fælles funktion En prototypefunktion, der er blevet slået sammen med funktioner fra tidligere iterationer. Den nye kombinerede funktionelle prototype vil blive testet i næste fase.
Test rapport En testpost, der består af et testscript, testprocedure og testresultater.
Funktionel prototypeanalysedokument Består af brugerkommentarer om den aktuelle version, nødvendige for arbejdet med efterfølgende iterationer. Dette dokument bruges til at opdatere protokollen over mulige risici og listen over krav.

Procesudviklingsmodel

Jobbet med at definere en funktionel prototype er at definere den funktionalitet, der vil være til stede i prototypen ved en given iteration. Analyse og programmering færdig; prototyper samles; og erfaringerne fra dem bruges til at forbedre analysemodellerne (og er også baseret på en opdateret liste over krav og en protokol over mulige risici). Byggede prototyper smides ikke ud, men bringes gradvist til den ønskede kvalitet for senere at kunne indgå i det færdige system. En aftalt arbejdsplan er nødvendig for at bestemme, hvornår og inden for hvilken tidsramme prototyping vil blive implementeret; det udvider prototypeplanen og -planen. Og test, som udføres gennem hele processen, er også en uundværlig del af denne fase og indgår i prototypeanalyseprocessen umiddelbart efter prototypen er bygget. Testprotokollen vil også blive brugt til at analysere prototypen og oprette et analysedokument. Nedenfor er et diagram over denne proces.

Handling Subaktion Beskrivelse
Definition af en funktionel prototype Kravanalyse Kravene til den aktuelle prototype analyseres i henhold til listen over krav, der er oprettet tidligere (i den tidligere iteration og/eller fase).
Liste over krav til den aktuelle iteration Udvælgelse af funktionelle krav, der vil blive implementeret i prototypen ved den aktuelle iteration, og oprettelse af en liste over funktionelle krav.
Liste over ikke-funktionelle krav Dannelse af en liste over ikke-funktionelle krav til systemet.
Oprettelse af en funktionel model Analyse af modellen og prototypekoden og oprettelse af en funktionel model.
Koordinering af planer Definition af tid Fastlæggelse af en eventuel tidsplan for udførelse af prototyping arbejde i henhold til prototyping plan og strategi.
Lav en udviklingsplan Opret en prototyping-plan, der inkluderer alt prototyping-arbejde, der skal afsluttes i tidsintervaller som planlagt.
Samordning En aftalt tidsplan for, hvordan og inden for hvilken tidsramme alt prototyparbejde vil blive afsluttet.
Oprettelse af en funktionel prototype Undersøgelse Krav forskning; analyse af funktionsmodellen og udvikling af en implementeringsplan baseret på analysen. Resultaterne vil blive brugt til at bygge prototypen i næste delaktivitet.
Forbedring Implementering af en funktionel model og implementeringsplan for at bygge en funktionel prototype. Denne prototype vil derefter blive forbedret, før den kombineres med andre funktioner. Prototypen bringes til den ønskede kvalitet, for derefter at blive inkluderet i det færdige system.
En forening Kombination af den forbedrede funktionelle prototype med prototypen udviklet i den tidligere iteration. Den resulterende prototype vil blive testet i næste trin.
Funktionel prototypeanalyse Prototype test En uundværlig del af DSDM-metoden, der skal være til stede gennem hele processen. Testrapporten vil sammen med brugerkommentarer blive brugt til at skabe et prototypeanalysedokument i næste trin.
Prototypeanalyse Brugerkommentarer og dokumentation indsamles. De vil spille en vigtig rolle i udviklingen af ​​prototypegennemgangsdokumentet. Baseret på dette dokument vil listen over krav og protokollen over mulige risici blive opdateret, og der vil blive truffet en beslutning om, hvorvidt der skal udføres en anden iteration af stadiet med at skabe en funktionel model.

Mere om DSDM

HovedDSDM-teknikker

  • tidsboksningTimeboxing er en af ​​de vigtigste DSDM-teknikker. Det bruges til at nå hovedmålene for DSDM - at udvikle et informationssystem til tiden, overholde budgettet og samtidig opretholde kvaliteten. Hovedideen med timeboxing er at opdele hele projektet i dele, hver med sit eget budget og deadlines. For hver sådan del udvælges krav, der er fordelt efter MoSCoW-princippet. Da tid og budget ligger fast, er det eneste, der kan ændre sig, kravene. For eksempel, hvis et projekt er forsinket eller over budgettet, droppes kravene med den laveste prioritet. Dette betyder ikke, at et ufærdigt produkt vil vise sig. Ud fra 20/80 princippet kommer 80 % af projektet fra 20 % af kravene. Derfor, når disse vigtigste 20% af kravene er implementeret i systemet, opfylder det de økonomiske krav. Det er værd at bemærke, at intet system blev bygget perfekt første gang.
  • MOSKVAMoSCoW-metoden giver mulighed for at prioritere objekter. I forbindelse med DSDM anvendes MoSCoW-metoden til at prioritere et krav. Denne forkortelse står for:
SKAL - kravet SKAL opfylde økonomiske behov. BØR - Hvorvidt dette krav SKAL opfyldes, hvis projektets succes ikke afhænger af det. KUNNE - Om dette krav SKAL efterlades, hvis det ikke påvirker projektets forretningsbehov. VIL IKKE - Er det MULIGT at forsinke opfyldelsen af ​​kravet, hvis der stadig er tid.
  • prototypingDenne teknik refererer til prototyping af et system under tidlig udvikling. Det giver dig mulighed for at identificere fejl i systemet og giver fremtidige brugere mulighed for at teste det. Dermed realiseres inddragelsen af ​​brugeren i arbejdet - en af ​​DSDM-metodens centrale succesfaktorer.
  • AfprøvningDet tredje vigtige aspekt for at nå målet med DSDM er at skabe et informationssystem af høj kvalitet. For at opnå dette insisterer DSDM på at teste hver iteration. Projektteamet kan frit vælge, hvordan test skal styres.
  • ArbejdsgruppeDette er en af ​​DSDM-teknikkerne, hvis formål er at samle forskellige projektdeltagere for at diskutere krav, funktionalitet og opbygge gensidig forståelse. Medlemmer af hver arbejdsgruppe mødes for at diskutere projektet.
  • ModelleringDenne teknik er obligatorisk og bruges til i form af diagrammer at visualisere en separat side af det system eller aktivitetsområde, der arbejdes på. Modellering giver en bedre forståelse for hele projektteamet i projektets forretningsområde.
  • KonfigurationsstyringEn god implementering af en konfigurationsstyringsteknik er vigtig på grund af DSDMs dynamiske natur. Da der opstår mange forskellige hændelser under systemudviklingsprocessen, og produkter ofte udgives ret ofte, kræver produkter streng kontrol, for at de kan produceres med succes.

Rolleri DSDM

  • Executive Sponsor/Producer eller på anden måde projektets Champion. En meget vigtig rolle. Han har evnen og pligten til at forvalte midler og ressourcer. Denne rolle har også fuld myndighed til at træffe beslutninger.
  • Den visionære er den, der får gang i projektet og finder de første grundkrav. Visionæren har den mest præcise forståelse af systemets og projektets forretningsmål.
  • Repræsentativ bruger Repræsenterer brugere i projektet. Ansvarlig for at sikre, at udviklere får tilstrækkelig brugerfeedback under udviklingsprocessen.
  • Konsulentbruger Kan være enhver bruger, der giver et vigtigt synspunkt på projektet og bringer viden til projektet om nogle aspekter af brugen af ​​produktet.
  • Projektlederen kan være fra brugerfællesskabet eller fra informationsteknologiområdet. Varetager overordnet projektledelse.
  • Teknisk koordinator Ansvarlig for udvikling af systemarkitekturen og kontrollerer kvaliteten af ​​projektet.
  • Teamleder Leder udviklingsteamet og sikrer dets effektive drift.
  • Udvikler Analyserer systemkrav og modellerer det. Dette involverer skrivning af kode og prototyping.
  • Tester Kontrollerer projektets rigtighed fra den tekniske side ved at udføre tests. Skriver kommentarer og dokumentation.
  • Sekretær Ansvarlig for indsamling og registrering af krav, aftaler og beslutninger truffet i hver arbejdsgruppe.
  • Mægler Leder arbejdsgrupper.
  • Andre roller Forretningsarkitekt, kvalitetschef, systemintegrator mv.

Iterativog den inkrementelle karakter af DSDM

Udover time-boxing og prioritering af krav, bruger DSDM også en iterativ og inkrementel tilgang til opbygning af informationssystemer.

Den funktionelle modelfase, design- og udviklingsfasen og implementeringsfasen kan gennemgå deres delfaser mange gange, før de går videre til næste fase. Hver iteration udforsker nye funktioner, og hver aktuelle iteration bygger på den forrige. Og om nødvendigt kan hver iteration efterlades ufærdig.

For eksempel, hvis mange nye og nyttige funktioner blev opdaget under udviklingen, men de ikke kan implementeres, så er det muligt at starte projektet forfra ved at skrive nye krav under forundersøgelsesfasen. Eller omvendt kan nogle funktioner udelades på grund af budget- eller tidsbegrænsninger. Projektet kan kun flyttes til efterprojektfasen, når alle kravene er opfyldt.

På grund af den iterative karakter af DSDM er der korrekt styring af krav og konfiguration gennem hele projektet. Dette sikrer implementering af alle de krav, der stilles i de tidlige faser af projektet.

Faktorer, der kræves for succes med DSDM-metoden

Inden for DSDM er der følgende faktorer, der påvirker et projekts succes.

  • Den første er vedtagelsen af ​​DSDM-metoden af ​​ledelsen og alle medarbejdere. Dette sikrer motivationen for alle deltagere fra det øjeblik, projektet lanceres og deres efterfølgende involvering.
  • Den anden faktor følger af den første - ledelsens vilje til at sikre inddragelse af slutbrugere i arbejdet med projektet. Prototypingsprocessen kræver meget brugerinvolvering i test og evaluering af funktionelle prototyper.
  • Den tredje er projektgruppen. Den skal bestå af erfarne medlemmer og på sigt blive en fast forening. Et vigtigt problem er tillid og gensidig forståelse i projektgruppen. Det betyder, at teamet har ret og evne til at træffe vigtige beslutninger om projektet uden ledelsens formelle godkendelse, hvilket kan tage meget tid. For at et team med succes kan arbejde på et projekt, har det brug for de nødvendige værktøjer – et udviklingsmiljø, projektledelsesværktøjer mv.
  • Fjerde. DSDM står for et positivt forhold mellem udvikler og kunde. Det gælder både projekter, der er udviklet i virksomhederne selv, samt ved brug af tredjepartsentreprenører.

Sammenligning med andre udviklingsmetoder for informationssystemer

Mange metoder til udvikling af informationssystemer er allerede blevet udviklet og anvendt i praksis. For eksempel struktureret systemanalyse og designmetode (SSADM), RAD-applikationsudviklingsmetoder, OOP-metoder. De fleste af disse metoder ligner hinanden og DSDM.

Extreme Programming anvender også en iterativ tilgang til udvikling af informationssystemer med inddragelse af brugere.

The Rational Unified Process, der mest ligner DSDM, er også en dynamisk udviklingsmetode for informationssystemer. Igen kræver det en iterativ tilgang til udvikling.

Der er andre metoder, der kan ligne DSDM, men som har en række forskelle. For det første giver det de nødvendige udviklingsværktøjer og -måder. Dette giver brugerne mulighed for at tilføje deres egne metoder til udviklingsprocessen på en særlig måde og hjælpe med at træffe beslutninger. En anden unik funktion - du kan ikke ændre tiden eller udviklingsværktøjerne, men kravene til projektet. Denne tilgang sikrer opnåelsen af ​​hovedmålene for DSDM - at overholde deadline og holde sig inden for budgettet. Og det sidste - gensidig forståelse og kommunikation mellem alle deltagere og deres involvering i projektet.

Se også

Links