RAD
I dagens affärsklimat är företagen betydligt mer kostnadsmedvetna
än för endast ett par år sedan. Att driva flerårsprojekt
är ur ett ekonomiskt perspektiv inte längre ett alternativ om
man vill utveckla nya komplexa system kostnadseffektivt. Alla vet att
det tar längre tid att stoppa en oljetanker än att stoppa flera
mindre fartyg.
Att dra igång ett utvecklingsprojekt med RAD som metod
är betydligt lättare då eventuella problem med projektet
ej slår lika hårt mot verksamheten.
Vad
är RAD?
RAD står för Rapid Application Development och begreppet myntades
av James Martin i boken ’Rapid Application Development’ från
1991.
RAD är en metod för att utveckla mjukvara på kortast möjliga
tid, för minsta möjliga kostnad och med största möjliga
kvalité. Metoden har en del typiska beståndsdelar för
programutveckling men dessa har finslipats och anpassats till just RADs
krav.
Några arbetsmetoder inom RAD förutom de som beskrivs nedan
är; Workshops, SWAT Teams, TimeBox-utveckling, technical reviews,
miniature milestones, aktiv riskanalys och delleveranser.
RADs iterativa modell består av flera metoder som tillsammans bidrar
till den korta utvecklingscykeln och den höga kvalitén, bland
annat är prototyper viktiga inom RAD för att tidigt i ett utvecklingsprojekt
försäkra sig om att mottagaren av systemet får det han
har beställt. Andra fördelar med att ta fram prototyper tidigt
i ett utvecklingsprojekt är att användaren lättare kan
komma med synpunkter om programmets funktionalitet, innan någon
djupare programmering har skett och via prototypen upptäcka behov
som ej behandlats i kravspecifikationen och som skulle ha varit svåra,
ja till och med omöjliga att upptäcka genom den ordinarie kravanalysen.
Vi vet ju genom erfarenhet att mottagandet av ett system baserar sig på
de uppfyllda kraven i kravspecifikationen men även på de outtalade
kraven som ej finns med i kravspecifikationen. Genom att fånga in
de outtalade kraven genom till exempel en prototyp kan man undvika gissningslekar
och leverera ett system som uppfyller användarens samtliga krav.
En annan förutsättning för att lyckas med ett RAD-projekt
är tydliga avgränsningar i systemutvecklingen och speciellt
i själva konstruktionsfasen i systemutvecklingen. Vissa leverantörer
hävdar att de vill ’överträffa kundens förväntningar’
– en sund inställning som helt klart har en plats i den generella
marknadsföringen i ett företag, men som inte har något
att göra i ett system-utvecklingsprojekt där i stort sätt
alla försök till att ’överträffa kundens förväntningar’
ofta slutar i havererade tidplaner och överskriden utvecklingsbudget.
Man kallar detta populärt för Gold Plating; att ’förgylla’
ett system med funktioner som användaren inte har önskat sig
eller behöver.
CASE-verktyg
En annan central aspekt i ett typiskt RAD-projekt är att man arbetar
med CASE-verktyg för att på snabbast möjliga sätt
få fram både prototyper och färdiga program. Verktyg
som Visual Basic har gjort att programutvecklingen varken behöver
ta lång tid eller vara speciellt komplicerad. På marknaden
finns flera andra exempel på verktyg som underlättar och effektiviserar
utvecklingen av programvara. Även objektorienterad programutveckling
kan bidra till ett RAD-projekt med sin återanvändbara kod.
Under senare år har även de olika verktygen för webproduktion
utvecklats från rent grafiska verktyg till utvecklingsverktyg där
relativt komplexa websystem numera kan utvecklas med hjälp av RADs
principer. Detta var otänkbart för bara några år
sedan då webtekniken fortfarande var ny och webhandelsplatser och
portaler var några av de nya begreppen.
De flesta stora databastillverkare och leverantörer av lösningar
för Business Intelligence har idag CASE-verktyg för att kunna
tillgodose RAD-projektens behov, några exempel är Oracle, SAS
Institute och Sybase. Dessa har i vissa fall utvecklat helt egna 4GL-språk,
ibland väldigt lika befintliga programmeringsspråk. Detta har
gjort att även större informationssystem och system för
Business Intelligence kan utvecklas med snabba resultat och hög kvalité,
med hjälp av RADs principer.
Projekthantering
En mycket viktig aktivitet i ett RAD-projekt, och ofta slarvigt utförd
i ett vanligt utvecklingsprojekt, är riskanalysen och riskhanteringen.
Eftersom RAD-projekten är väldigt korta och intensiva krävs
en betydligt aktivare riskanalys än i ett vanligt projekt eftersom
även mycket små problem kan äventyra tidplanen och orsaka
relativt stora förseningar.
En veckas försening i ett halvårsprojekt är acceptabelt
men en veckas försening i ett tvåmånadersprojekt kan
vara katastrofalt. Genom att angripa problemen och riskerna innan de angriper
projektet kan man eliminera de kända riskerna och istället vara
förberedd på de okända riskerna. Detta betyder att projekt-ledaren
inte bara bör planera utvecklingsaktiviteter och skriva åtgärdsplaner,
som används om olyckan är framme, utan även planera för
att aktivt eliminera riskerna och säkerställa projektets tidplan.
En RAD-projektledare kan till exempel välja att, inför ett projekt,
vaccinera projektmedlemmarna under influensatider eller köpa in extra
datorutrustning som kan finnas på plats om den ordinarie datorutrustningen
skulle krångla.
Alla ovanstående grundprinciper vore relativt ineffektiva i ett
RAD-projekt om man inte använde en strikt projektstyrning. Det är
nämligen en av förutsättningarna för att lyckas med
ett RAD-projekt. I ett vanligt utvecklingsprojekt tillåts vanligtvis,
direkt eller indirekt, vissa brister i projekthanteringen och projektstyrningen.
Man kanske tenderar till att ha en mer passiv riskhantering, en underutvecklad
ändringshanteringsprocess eller lägre krav på dokumentationen.
I ett RAD-projekt är däremot en strikt projektstyrning en grundförutsättning
för att RADs metoder skall få den önskade effekten. För
det normala utvecklingsprojektet skulle en sådan hög grad av
struktur vara svår att upprätthålla och dessutom vara
påfrestande både för projektledaren och projektmedlemmarna.
Ett RAD-projekt är däremot endast tänkt att pågå
mellan ca 60 och 90 dagar vilket gör det lättare att hålla
en högre grad av struktur.
Större utvecklingsprojekt med RAD som metod är möjliga
genom att dela upp huvudprojektet i mindre delprojekt.
Sammanfattning
I slutändan är RAD en mycket effektiv utvecklingsmetod som är
lämpad för små och medelstora utvecklingsprojekt. Även
om RAD går att tillämpa på större projekt ställer
detta höga krav på projektledning och projekt-medlemmar då
kraven på struktur kan värka tuffa. Fördelen med RAD är
däremot att man i ett vanligt utvecklingsprojekt kan välja vissa
av RADs metoder och verktyg för att förbättra projektstyrningen
och få ökad kontroll.
Mandrillo Consulting erbjuder projektledning enligt RAD men även
enligt utvalda delar från RAD, för att bättre passa kundens
projekthantering.
Vi kan även skapa en kundanpassad utvecklingsmodell eller modifiera
befintliga modeller bland annat utifrån de metoder som finns inom
RAD.