DSDM

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 28 mars 2021; kontroller kräver 8 redigeringar .

Dynamic Systems Development Method (DSDM) är i första hand en mjukvaruutvecklingsteknik baserad på konceptet Rapid Application Development (RAD). DSDM är ett iterativt och inkrementellt tillvägagångssätt som betonar fortsatt användar-/konsumentsengagemang i processen.

Målet med metoden är att leverera det färdiga projektet i tid och inom budget, samtidigt som man hanterar förändringar i projektkrav under dess utveckling. DSDM är en del av en familj av agil mjukvaruutveckling och icke-informationsteknologisk utveckling.

Den senaste versionen av DSDM heter DSDM Atern. Namnet Atern är en förkortning av Arctic Tern. Tärnan är en fågel som kan resa långa sträckor. Det symboliserar många aspekter av metoden, såsom prioritering eller samarbete, som är ett naturligt sätt att driva ett arbetsflöde.

Den tidigare versionen av DSDM (släpptes i maj 2003) som fortfarande är giltig och flitigt använd är DSDM 4.2, som är en något utökad version av DSDM 4. Den utökade versionen innehåller vägledning om hur man använder DSDM i samband med Extreme Programmering.

Översikt över DSDM Atern

År 2007 undersökte ett team som bildades av DSDM-konsortiet essensen av metoden och beslutade att de grundläggande mekanismerna och strukturen var välskrivna, men metodens terminologi och uppmärksamhet var helt fokuserad på informationsteknologiområdet. Därför måste de förbättras för att möta behoven hos projekt under det nya millenniet (en del av metoden har inte förändrats sedan 1995). Den nya versionen släpptes den 24 april 2007 på Cafe Royale i London.

Översikt över DSDM version 4.2

Som en förlängning av konceptet med snabb applikationsutveckling fokuserar DSDM på informationssystemprojekt som kännetecknas av snäva deadlines och budgetar. DSDM innehåller indikationer på typiska fel i informationssystemprojekt, såsom överskridande av budget, sena leverans(utförande) deadlines, otillräcklig involvering av användare och högsta chefer i arbetet med projektet. DSDM består av:

Under vissa förutsättningar är det möjligt att inkludera delar av andra metoder i DSDM, såsom Rational Unified Process (RUP), Extreme Programming, PRINCE2. En annan flexibel metod som liknar DSDM i process och koncept är Scrum .

DSDM-metoden utvecklades i Storbritannien på 1990-talet av DSDM Consortium. DSDM-konsortiet är en sammanslutning av mjukvaruutvecklare och experter som etablerats med syftet att "gemensamt utveckla och främja ett oberoende RAD-ramverk" genom att kombinera bästa praxis från föreningens medlemmar. DSDM Consortium är en ideell organisation av oberoende utvecklare som äger och driver DSDM-ramverket. Den första versionen av ramverket färdigställdes i januari 1995 och publicerades i februari 1995. I juli 2006 släpptes versionen med öppen källkod av DSDM 4.2 och gjordes tillgänglig för privatpersoner för visning och användning. Den som distribuerar DSDM måste dock vara medlem i detta ideella konsortium.

DSDM och DSDM-konsortiet - tidiga dagar

I början av 1990-talet började en ny term spridas inom informationsteknologibranschen - Rapid Application Development (RAD). Användargränssnitt för tillämpningsprogram har utvecklats från de gamla gröna skärmarna till de grafiska användargränssnitten som fortfarande används idag. Nya verktyg för applikationsbyggande började komma in på marknaden, till exempel PowerBuilder . De gjorde det lättare för utvecklare att dela sina planerade utvecklingar med kunder – prototyper dök upp och förstörelsen av klassiska, sekventiella (kaskad-) utvecklingsmetoder började.

Den nya RAD-rörelsen var dock mycket ostrukturerad: det fanns ingen överenskommen beskrivning av metoden, och många organisationer skapade sina egna beskrivningar och förhållningssätt till den. Många stora företag var intresserade av möjligheterna med metoden, men de var också oroliga för att kvaliteten på deras produkter inte skulle minska i slutresultatet.

DSDM-konsortiet bildades 1994 när en grupp människor träffades vid ett evenemang som anordnades av Butler Group i London. Alla som kom till detta evenemang arbetade i stora organisationer som British Airways, American Express, Oracle och Logica (företag som Data Sciences och Allied Domecq har sedan tagits över av andra organisationer).

Vid detta möte beslutades att Jennifer Stapleton, då från Logica, skulle utforma en omfattande, användarcentrerad metod med bra kvalitetskontroll för iterativ och inkrementell utveckling. Den resulterande arkitekturen designades för att vara helt kompatibel med ISO 9000 och PRINCE2. När arkitekturen var klar (en månad efter mötet) bildade konsortiet grupper för att distribuera den inom alla områden av mjukvaruutveckling, vilket inkluderade: projektledningsmetoder och verktyg, kvalitetskontroll och testning, utvecklingsmetoder och verktyg. En kontrollgrupp, ledd av arkitekten och bestående av cheferna för dessa grupper, skulle säkerställa att metoden förstods som den ursprungligen tänktes.

Trots att många medlemmar i konsortiet var direkta konkurrenter delade de fritt med sig av hur de löser problem som uppstår. Praxis har visat att det bästa resultatet bara kan uppnås genom att arbeta som en helhet. Konsortiet har vuxit – det första året från flera organisationer till sextio; beskrivningen av metoden blev mer och mer komplett. Version 1 bildades i december 1994 och publicerades i februari 1995. Resultatet är en universell metod som omfattar människor, processer och verktyg. Det bildades på grundval av erfarenheterna från organisationer som skiljer sig åt i sin verksamhet och storlek.

DSDM-metod

Principer

Det finns 9 principer, bestående av 4 grundläggande och 5 utgångspunkter.

Förutsättningar för att använda DSDM

För att framgångsrikt använda DSDM måste ett antal förutsättningar vara uppfyllda. För det första är det nödvändigt att organisera samspelet mellan projektgruppen, framtida användare och högsta ledningen. För det andra bör det vara möjligt att dela upp projektet i mindre delar, vilket möjliggör ett iterativt tillvägagångssätt.

Två exempel på projekt där DSDM inte lämpar sig väl:

Projektets livscykel

Översikt: De tre stadierna av DSDM

DSDM-ramverket består av tre på varandra följande steg, som kallas förprojektstadiet, projektets livscykelskede och efterprojektstadiet. Projektets livscykelstadium är det mest genomtänkta och detaljerade av alla andra. Den består av fem steg som bildar en iterativ, inkrementell metod för att utveckla informationssystem. Dessa tre faser och deras respektive steg kommer att beskrivas mer i detalj i följande avsnitt. För varje steg eller steg kommer de viktigaste funktionerna att gås igenom och resultaten presenteras.

Steg 1 - Förprojekt I detta skede identifieras troliga projekt, medel tilldelas och projektgruppen identifieras. Att lösa problem i detta skede hjälper till att undvika problem i senare skeden av projektet. Steg 2 - Projektets livscykel Bilden nedan visar detta stadium. Den visar 5 stadier som ett projekt måste gå igenom för att bli ett informationssystem. De två första stegen, förstudien och den ekonomiska förstudien, fortskrider sekventiellt och kompletterar varandra. Efter slutförandet av dessa steg sker iterativ och inkrementell utveckling av systemet i steg: skapande av en funktionell modell, design och utveckling, implementeringsstadium. Den iterativa och inkrementella karaktären hos DSDM kommer att beskrivas härnäst. Steg 3 - Efterprojekt I detta skede säkerställs en effektiv drift av systemet. Detta uppnås genom att underhålla projektet, förbättra det och fixa buggar enligt principerna för DSDM. Projektet stöds av fortsatt utveckling baserad på den iterativa och inkrementella karaktären hos DSDM. Istället för att slutföra ett projekt i en cykel är det vanligt att gå tillbaka till tidigare stadier eller milstolpar för att förbättra produkten.

Diagrammet nedan visar hela livscykeln för ett projekt. Detta diagram beskriver den iterativa utvecklingen av DSDM. En beskrivning av varje steg kommer att presenteras nedan.

De fyra stadierna i projektets livscykelstadium

Handling Subaktion Beskrivning
Studie Förstudie I detta skede avgörs om projektet faller inom ramen för DSDM. Med tanke på typ av projekt, organisations- och personalfrågor fattas beslut om man ska använda DSDM-metoden eller inte. På så sätt erhålls en tillämplighetsrapport, en godtagbar prototyp och en ungefärlig global projektplan som inkluderar en utvecklingsplan och ett protokoll över möjliga risker.
Förstudie I detta skede analyseras de viktigaste ekonomiska och tekniska egenskaperna. Ett expertmöte äger rum där de viktigaste aspekterna av systemet diskuteras och beslut fattas om utvecklingsprioriteringar. I detta skede utvecklas en lista med grundläggande krav, en beskrivning av verksamhetens omfattning, en beskrivning av systemarkitekturen och en grov prototypplan.
Skapa en funktionell modell Definiera en funktionell prototyp Definition av den funktionalitet som kommer att ingå i prototypen i detta skede. I detta delskede utvecklas en funktionell modell enligt de resultat som erhållits vid studien av ekonomisk genomförbarhet.
Samordning av planer Det finns en överenskommelse om hur och inom vilken tidsram prototypens funktionalitet ska utvecklas.
Skapande av en funktionell prototyp Utveckling av en funktionell prototyp, enligt planer och en funktionell modell.
Funktionell prototypanalys Kontrollerar den utvecklade prototypens hälsa. Detta kan uppnås genom slutanvändartestning av prototypen och/eller revision av dokumentationen. Resultatet är ett dokument som innehåller en översikt över den funktionella prototypen.
Design och utveckling Design Prototyp Definition Definition av funktionella och icke-funktionella krav på systemet. Utifrån dessa krav bör en implementeringsstrategi skapas. Om det finns en testpost från en tidigare iteration kommer den också att användas för att skapa implementeringsstrategin.
Samordning av planer Det finns en överenskommelse om hur och inom vilken tidsram de uppställda kraven ska implementeras.
Skapande av en konstruktiv prototyp Skapande av ett system (konstruktiv prototyp) som kan ges till användare för testning.
Strukturell prototypanalys Kontrollera att det designade systemet är korrekt. Detta delsteg tillämpar testning och granskning av resultaten. Skapande av användardokumentation och testrapport.
Genomförande Systemgodkännande av användaren Slutanvändare godkänner det testade systemet för implementering och vägledning.
Användarutbildning Utbilda den framtida användaren att arbeta med systemet. Resultatet av delfasen är en kontingent av utbildade användare.
Genomförande Implementering av det testade systemet bland användare.
Systemmarknadsanalys Analys av det släppta systemets inverkan på marknaden. Huvudfrågan är om det mål som satts upp vid utformningen av systemet har uppnåtts. Baserat på detta går projektet till nästa steg (efterprojekt) eller återgår till det föregående för revidering. Analysen kommer att presenteras i projektets analysdokument.

De fyra stadierna i projektets livscykel

Steg 1A: Förstudie

Under denna fas kontrolleras projektets genomförbarhet enligt DSDM. Förutsättningarna för att använda DSDM kontrolleras genom att svara på frågorna: "Kan detta projekt uppfylla de nödvändiga ekonomiska kraven?", "Projektet är lämpligt för att använda DSDM-metoden?" och "Vilka är de viktigaste riskerna i det här projektet?". Den viktigaste metoden i detta skede är användningen av arbetsgrupper.

Resultatet av detta steg är en rapport om tillämplighet och en acceptabel prototyp, som tar hänsyn till projektets genomförbarhet, samt en ungefärlig global projektplan och ett protokoll över möjliga risker som beskriver de viktigaste riskerna med projektet.

Steg 1B: Förstudie

Förstudien utökar och kompletterar förstudiestadiet. Efter att projektet har erkänts som genomförbart inom ramen för DSDM kontrolleras affärsprocesser i detta skede, användargrupper involveras och deras krav och önskemål analyseras. Och återigen, den mest populära metoden i detta skede är användningen av arbetsgrupper. Som en del av arbetsgrupperna samlas projektdeltagarna för att diskutera det planerade systemet. Information som erhålls efter dessa händelser samlas i en kravlista. Ett viktigt inslag i denna lista är fördelningen av prioriteringar mellan kraven. Dessa krav fördelas enligt MoSCoW-metoden. Utifrån den mottagna sekvensen skapas en utvecklingsplan som ska vara vägledande för hela projektet.

För att skapa denna plan används en mycket viktig teknik för projektet - time-boxing. Denna metodik är väsentlig för att uppnå målen för DSDM - uppfylla deadlines och budget, och samtidigt upprätthålla den erforderliga kvaliteten på produkten. Systemarkitekturen är ytterligare ett hjälpmedel för att hantera utvecklingen av ett informationssystem. Resultatet av denna fas är en affärsomfattningsbeskrivning som innehåller projektets sammanhang inom företaget, en systemarkitekturbeskrivning som ger en initial global arkitektur för informationssystemet under utveckling, och en utvecklingsplan som beskriver de viktigaste stegen i utvecklingsprocess. Dessa två dokument är baserade på en lista med krav. Protokollet över möjliga risker kompletteras med de uppgifter som erhålls i detta skede.

Steg 2: Skapa en funktionell modell

Kraven som definierades i föregående steg omvandlas till en funktionell modell. Den består av en fungerande prototyp och modeller. Prototyping är en nyckelprojektteknik i detta skede, vilket gör det möjligt att organisera användarengagemang i projektet. Den utvecklade prototypen analyseras av olika användargrupper. För att uppnå den kvalitet som krävs, testas vid varje iteration. Den viktigaste delen av testningen presenteras i detta skede. Skapandet av en funktionell modell kan delas in i följande understeg:

  • Definition av en funktionell prototyp: definition av den funktionalitet som kommer att införlivas i prototypen i detta skede.
  • Samordning av planer: det finns en överenskommelse om hur och inom vilken tidsram prototypens funktionalitet ska utvecklas.
  • Skapande av en funktionell prototyp: utveckla en prototyp. Studera och förfina prototypen vid denna iteration enligt den funktionella prototypen som erhållits vid tidigare iterationer.
  • Analys av den funktionella prototypen: för att kontrollera det designade systemets hälsa. Detta delsteg tillämpar testning och granskning av resultaten.

Resultatet av detta steg är en funktionell modell och en funktionell prototyp, som tillsammans representerar den funktionalitet som erhålls i denna iteration, redo för användartestning. Därefter uppdateras kravlistan - redan implementerade objekt tas bort från den och ordningen på de återstående objekten ändras igen. Protokollet över möjliga risker uppdateras också, efter analysen av den funktionella prototypen.

Steg 3: Design och utveckling

Huvudsyftet med denna iteration är att kombinera de funktionella komponenterna från föregående steg till ett enda system som uppfyller användarnas krav. Även icke-funktionella krav beaktas här. Och igen i detta skede sker testning. Design och utveckling kan delas in i följande delsteg:

  • Definiera en designprototyp: Definierar de funktionella och icke-funktionella krav som systemet ska ha.
  • Samordning av planer: det finns en överenskommelse om hur och inom vilken tidsram de uppställda kraven ska genomföras.
  • Structural Prototyping: Skapa ett system som kan ges till användare för dagligt bruk. Studera och förfina prototypen vid denna iteration.
  • Analys av en konstruktiv prototyp: kontrollera tillståndet hos det designade systemet. Detta delsteg tillämpar testning och granskning av resultaten. Testrapporten och användarfeedback används för att skapa användardokumentation.

Resultatet av steget är skapandet av en konstruktiv prototyp för användartestning. Det testade systemet fortsätter till nästa steg. I detta skede är systemets utseende och funktion i allmänhet klara. Ett annat resultat är skapandet av användardokumentation.

Steg 4: Implementering

Vid implementeringsstadiet levereras det testade systemet tillsammans med användardokumentation till framtida användare och de utbildas i att arbeta med systemet. Systemet analyseras för överensstämmelse med de krav som ställdes i de tidiga skedena av projektet. Implementeringen kan delas in i följande delsteg:

  • Användarvalidering av systemet: Slutanvändare validerar det testade systemet för implementering och vägledning.
  • Användarutbildning: träna den framtida användaren att arbeta med systemet. Resultatet av delfasen är en kontingent av utbildade användare.
  • Implementering: implementering av det testade systemet bland användare.
  • Systemmarknadsanalys: analys av effekten av det släppta systemet på marknaden. Huvudfrågan är om det mål som satts upp vid utformningen av systemet har uppnåtts. Baserat på detta går projektet till nästa steg (efterprojekt) eller återgår till det föregående för revidering.

Resultatet av steget: ett komplett system lämpligt för slutanvändare, en kontingent av utbildade användare och ett detaljerat projektanalysdokument.

Stadiet för att skapa en funktionell DSDM-modell

Metadatamodell

Samband mellan begrepp i skedet av att skapa en funktionell modell visas i modellen i figuren nedan.

begrepp Beskrivning
Protokoll över möjliga risker Protokoll över upptäckta risker. Viktigt för efterföljande steg, innehåller problem som sannolikt kommer att uppstå. Bör uppdateras ständigt.
Lista över krav efter prioritet Lista över krav sorterade efter prioritet. Distributionsprocessen är baserad på MoSCoW-metoden, som bestämmer vilka krav som ska implementeras först (ur ekonomisk synvinkel)
Lista över icke-funktionella krav En lista över icke-funktionella krav som kommer att behöva hanteras i nästa steg.
Funktionskrav Den här funktionen används för modellbyggande och prototyper enligt prioriteringar.
funktionell modell En modell byggd utifrån funktionskrav. Den kommer att användas för att utveckla prototypen i nästa delsteg. Denna modell kommer att användas för att skapa prototypplanen.
prototypframställning Processen att snabbt bygga en fungerande modell (prototyp) för att testa design, illustrera idéer och funktioner och samla in feedback från användare tidigt.
Lista över tidsintervall En lista med tidsintervall för utförandet av enskilda arbeten är nödvändig för att passa in i schemat för genomförandet av hela projektet.
Prototypplan En plan för att prototypprocessen ska slutföras i tidsluckor som planerat.
Driftschema En uppsättning arbeten och tidpunkten för dessa arbeten, överenskomna av utvecklarna. Används vid implementering av en funktionell prototyp.
funktionell prototyp En prototyp som låter dig se alla funktioner i systemet och hur systemet kommer att utföra dessa funktioner.
Implementationsplan Förberedelse av arbeten för implementering av en funktionell prototyp enligt arbetsschema och kravlista.
Förbättrad funktion En prototypfunktion som har förbättrats och testats i denna iteration innan den slogs samman med andra delar av prototypen.
Gemensam funktion En prototypfunktion som har slagits samman med funktioner från tidigare iterationer. Den nya kombinerade funktionella prototypen kommer att testas i nästa fas.
Testrapport En testpost som består av ett testskript, testprocedur och testresultat.
Funktionell prototypanalysdokument Består av användarkommentarer om den aktuella versionen, nödvändiga för arbete med efterföljande iterationer. Detta dokument används för att uppdatera protokollet för möjliga risker och kravlistan.

Processutvecklingsmodell

Jobbet med att definiera en funktionell prototyp är att definiera den funktionalitet som kommer att finnas i prototypen vid en given iteration. Analys och programmering klar; prototyper sätts ihop; och erfarenheterna från dem används för att förbättra analysmodellerna (och baseras även på en uppdaterad kravlista och ett protokoll över möjliga risker). Byggda prototyper slängs inte utan förs gradvis till den kvalitet som krävs för att senare ingå i det färdiga systemet. Ett överenskommet arbetsschema behövs för att avgöra när och inom vilken tidsram prototyper kommer att implementeras; det utökar prototypschemat och planen. Och testning, som genomförs under hela processen, är också en oumbärlig del av detta steg och ingår i prototypanalysprocessen direkt efter att prototypen byggts. Testprotokollet kommer också att användas för att analysera prototypen och skapa ett analysdokument. Nedan är ett diagram över denna process.

Handling Subaktion Beskrivning
Definiera en funktionell prototyp Kravanalys Kraven för den aktuella prototypen analyseras enligt den kravlista som skapats tidigare (i föregående iteration och/eller steg).
Lista över krav för den aktuella iterationen Val av funktionskrav som kommer att implementeras i prototypen vid den aktuella iterationen, och skapande av en lista med funktionskrav.
Lista över icke-funktionella krav Bildande av en lista över icke-funktionella krav för systemet.
Skapa en funktionell modell Analys av modell och prototypkod samt skapande av en funktionell modell.
Samordning av planer Definition av tid Fastställande av ett eventuellt schema för genomförande av prototyparbete i enlighet med prototypplan och strategi.
Gör en utvecklingsplan Skapa en prototypplan som inkluderar allt prototyparbete som ska slutföras i tidsluckor som planerat.
Samordning En överenskommen tidsplan för hur och inom vilken tidsram allt prototyparbete ska slutföras.
Skapande av en funktionell prototyp Studie Kravforskning; analys av funktionsmodellen och framtagande av en genomförandeplan utifrån analysen. Resultaten kommer att användas för att bygga prototypen i nästa delaktivitet.
Förbättring Implementering av funktionsmodell och implementeringsplan för att bygga en funktionell prototyp. Denna prototyp kommer sedan att förbättras innan den kombineras med andra funktioner. Prototypen bringas till önskad kvalitet för att sedan ingå i det färdiga systemet.
En förening Kombinera den förbättrade funktionella prototypen med prototypen som utvecklades i föregående iteration. Den resulterande prototypen kommer att testas i nästa steg.
Funktionell prototypanalys Prototyptestning En oumbärlig del av DSDM-metoden som måste finnas under hela processen. Testrapporten, tillsammans med användarkommentarer, kommer att användas för att skapa ett prototypanalysdokument i nästa steg.
Prototypanalys Användarkommentarer och dokumentation samlas in. De kommer att spela en viktig roll i utvecklingen av prototypgranskningsdokumentet. Baserat på detta dokument kommer listan över krav och protokollet för möjliga risker att uppdateras, och ett beslut kommer att fattas om att genomföra en ny iteration av steget för att skapa en funktionell modell.

Mer om DSDM

MainDSDM-tekniker

  • tidsboxningTimeboxing är en av de viktigaste DSDM-teknikerna. Det används för att uppnå huvudmålen för DSDM - att utveckla ett informationssystem i tid, hålla budget och samtidigt upprätthålla kvalitet. Huvudidén med timeboxing är att dela upp hela projektet i delar, var och en med sin egen budget och deadlines. För varje sådan del väljs krav som har fördelats enligt MoSCoW-principen. Eftersom tid och budget är fast är det enda som kan ändras kraven. Till exempel, om ett projekt ligger efter schemat eller över budget, tas kraven med lägst prioritet bort. Detta betyder inte att en ofärdig produkt kommer att visa sig. Baserat på 20/80-principen kommer 80% av projektet från 20% av kraven. Därför, när dessa viktigaste 20% av kraven är implementerade i systemet, uppfyller det de ekonomiska kraven. Det är värt att notera att inget system byggdes perfekt första gången.
  • MOSKVAMoSCoW-metoden ger ett sätt att prioritera objekt. I DSDM-sammanhang används MoSCoW-metoden för att prioritera ett krav. Denna förkortning står för:
MÅSTE – kravet MÅSTE uppfylla ekonomiska behov. BÖR - Huruvida detta krav SKA uppfyllas om projektets framgång inte beror på det. KAN - Huruvida detta krav SKA lämnas om det inte påverkar projektets affärsbehov. VILL INTE - Är det MÖJLIGT att fördröja uppfyllandet av kravet om det fortfarande finns tid.
  • prototypframställningDenna teknik hänvisar till prototypframställning av ett system under tidig utveckling. Det låter dig identifiera brister i systemet och låter framtida användare testa det. Därmed realiseras användarens engagemang i arbetet - en av de viktigaste framgångsfaktorerna för DSDM-metoden.
  • TestningDen tredje viktiga aspekten för att uppnå målet med DSDM är att skapa ett informationssystem av hög kvalitet. För att uppnå detta insisterar DSDM på att testa varje iteration. Projektgruppen kan fritt välja hur testning ska hanteras.
  • ArbetsgruppDetta är en av DSDM-teknikerna, vars syfte är att samla olika projektdeltagare för att diskutera krav, funktionalitet och bygga ömsesidig förståelse. Medlemmar i varje arbetsgrupp samlas för att diskutera projektet.
  • ModelleringDenna teknik är obligatorisk och används för att i form av diagram visualisera en separat sida av systemet eller aktivitetsområdet som man arbetar med. Modellering ger en bättre förståelse för hela projektgruppen för projektets affärsområde.
  • KonfigurationshanteringEn bra implementering av en konfigurationshanteringsteknik är viktig på grund av DSDMs dynamiska natur. Eftersom många olika händelser inträffar under systemutvecklingsprocessen och produkter ofta släpps ganska ofta, kräver produkter strikt kontroll för att de ska kunna produceras framgångsrikt.

Rolleri DSDM

  • Verkställande sponsor/producent eller på annat sätt projektets mästare. En mycket viktig roll. Han har förmågan och skyldigheten att förvalta medel och resurser. Denna roll har också full befogenhet att fatta beslut.
  • Visionären är den som får igång projektet och hittar de första grundkraven. Visionären har den mest exakta förståelsen av affärsmålen för systemet och projektet.
  • Representative User Representerar användare i projektet. Ansvarig för att utvecklare får tillräcklig feedback från användarna under utvecklingsprocessen.
  • Konsultanvändare Kan vara vilken användare som helst som ger en viktig syn på projektet och tillför projektet kunskap om någon aspekt av att använda produkten.
  • Projektledare Kan vara från användargemenskapen eller från IT-området. Ger övergripande projektledning.
  • Teknisk koordinator Ansvarig för utvecklingen av systemarkitekturen och kontrollerar kvaliteten på projektet.
  • Team Leader Leder utvecklingsteamet och säkerställer att det fungerar effektivt.
  • Utvecklare Analyserar systemkrav och modellerar det. Detta innebär att skriva kod och prototyper.
  • Testare Kontrollerar projektets riktighet från den tekniska sidan genom att utföra tester. Skriver kommentarer och dokumentation.
  • Sekreterare Ansvarig för att samla in och anteckna krav, överenskommelser och beslut som fattas i respektive arbetsgrupp.
  • Mäklare Leder arbetsgrupper.
  • Övriga roller Verksamhetsarkitekt, kvalitetschef, systemintegratör m.m.

Iterativoch den inkrementella karaktären hos DSDM

Förutom tidsboxning och prioritering av krav, använder DSDM också en iterativ och inkrementell metod för att bygga informationssystem.

Den funktionella modellfasen, design- och utvecklingsfasen och implementeringsfasen kan gå igenom sina delfaser många gånger innan de går vidare till nästa steg. Varje iteration utforskar nya funktioner, och varje aktuell iteration bygger på den tidigare. Och om det behövs kan varje iteration lämnas oavslutad.

Till exempel, om många nya och användbara funktioner upptäcktes under utvecklingen, men de inte kan implementeras, är det möjligt att starta om projektet genom att skriva nya krav under förstudiestadiet. Eller omvänt kan vissa funktioner utelämnas på grund av budget- eller tidsbegränsningar. Projektet kan flyttas till efterprojektstadiet först när alla krav är uppfyllda.

På grund av den iterativa karaktären hos DSDM finns det korrekt hantering av krav och konfiguration genom hela projektet. Detta säkerställer genomförandet av alla krav som ställdes i de tidiga stadierna av projektet.

Faktorer som krävs för att lyckas med DSDM-metoden

Inom DSDM finns det följande faktorer som påverkar ett projekts framgång.

  • Den första är antagandet av DSDM-metoden av ledningen och alla anställda. Detta säkerställer motivationen för alla deltagare från det ögonblick då projektet startas och deras efterföljande engagemang.
  • Den andra faktorn följer av den första - ledningens vilja att säkerställa slutanvändarnas deltagande i arbetet med projektet. Prototypprocessen kräver mycket användarengagemang i att testa och utvärdera funktionella prototyper.
  • Den tredje är designteamet. Den ska bestå av erfarna medlemmar och på sikt bli en permanent förening. Ett viktigt problem är tillit och ömsesidig förståelse i projektgruppen. Detta innebär att teamet har rätten och förmågan att fatta viktiga beslut om projektet utan ledningens formella godkännande, vilket kan ta mycket tid. För att ett team ska lyckas arbeta med ett projekt behöver det de nödvändiga verktygen - en utvecklingsmiljö, projektledningsverktyg etc.
  • Fjärde. DSDM står för en positiv relation mellan utvecklare och kund. Det gäller projekt som utvecklas inom företagen själva, samt med hjälp av tredjepartsentreprenörer.

Jämförelse med andra metoder för utveckling av informationssystem

Många metoder för att utveckla informationssystem har redan utvecklats och tillämpats i praktiken. Till exempel strukturerad systemanalys och designmetod (SSADM), RAD-applikationsutvecklingsmetoder, OOP-metoder. De flesta av dessa metoder liknar varandra och DSDM.

Extreme Programming använder också ett iterativt tillvägagångssätt för utveckling av informationssystem med involvering av användare.

The Rational Unified Process, som mest liknar DSDM, är också en dynamisk utvecklingsmetod för informationssystem. Återigen, det tar ett iterativt förhållningssätt till utveckling.

Det finns andra metoder som kan likna DSDM, men som har ett antal skillnader. För det första tillhandahåller den nödvändiga utvecklingsverktyg och sätt. Detta tillåter användare att lägga till sina egna metoder i utvecklingsprocessen på ett speciellt sätt och hjälpa till i beslutsfattande. En annan unik funktion - du kan inte ändra tiden eller utvecklingsverktygen, utan kraven för projektet. Detta tillvägagångssätt säkerställer uppnåendet av huvudmålen för DSDM - att hålla tidsfristen och hålla sig inom budgeten. Och det sista - ömsesidig förståelse och kommunikation mellan alla deltagare och deras engagemang i projektet.

Se även

Länkar