Dokumenatationens betydelse i systemutvecklingsprojekt

Dokumentationens betydelse är mycket viktig för ett systemutvecklingsprojekt - men det är inte någon garanti för ett lyckat resultat.

Dokumentationens roll är mångfaciterad.

I inledningsskedet av ett projekt så är dokumentationens roll att hitta en gemensam angreppspunkt om systemets funktion och krav. Detta görs genom en förstudie tillsammans med en kravspecifikation.
Detta är något som många gånger plockas fram av projektgruppen och som stäms av med uppdragsgivaren. Om projektgruppen längre in i projektets gång finner fel och brister i förstudien som kommer påverka kravspecifikationen så skall detta kommuniceras till uppdragsgivaren.

Under projektets gång formuleras även ett analysdokument med diverse användningsfall, klassdiagram och andra olika tillstånd som projektets olika entiter kan utsättas för och vilka konsekvenser respektive handling skall ge. I denna fas hittar man lämpliga kandidater till teknik osv för det kommande systemet om inte detta redan finns i kravspecen. Dock är inget här skrivet i sten eftersom man med fördel arbetar iterativt kring dessa delar.

Senare kommer då Designdokumentet som skall dokumentera närmare den faktiska programkoden. Man modellerar databaser och finner det slutgiltiga utseendet på modellen, hur olika komponenter skall kommunicera osv (arkitektur).

När ovan är klart så gäller det att implementera. Och det är här den kritiska punkten kan uppstå. Systemet kan vara korrekt dokumenterat och modellerat fram hit. Det gäller alltså för de som faktiskt skall göra systemet att de håller sig till arkitekturen! Om man inte kan detta och "hittar på" sina egna vägar i kodstrukturen - så faller hela poängen med dokumentationen man genomfört. Hela dokumentet kan i ett sådant här läge slängas i papperskorgen - eftersom det inte stämmer överrens med dokumentationen.

Hursomhelst är dokumentationen dessutom viktig för "efterlevande" dvs, de som eventuellt skall ta över systemet efter en själv - eller om det går en tid innan man själv får en underhållsaktivitet på systemet - Då är det viktigt att veta hur man tänkte och varför saker är som dem är. Då kan man gå tillbaka till dokumentationen och se och förmodligen via den göra en mer träffsäker förstudie för det kommande underhållet.
//Fredrik L

Utveckling av websystem på Lavasoft

Mycket kloka ord har redan nämnts från mina övriga gruppmedlemmar i det här ärendet. Något som jag tycker är alldeles uppenbart i det här sammanhanget är att man valt en linje där man "själv" går in och fixar till kravspecens när frågetecken kring dem uppstår. Detta utan att kontakta uppdragsgivaren.
Innan man går in och ändrar en kravspec så är det mycket viktigt att kommunicera detta till kund. I ett systemutvecklingsprojekt är det ju mycket vanligt att krav man från början har, och eventuellt ser som möjliga - efter viss utredning i ämnet visar sig vara omöjliga att förverkliga. Eller att de inte stämmer överrens med den tidsuppskattning man från början hade.

När den här typen av problem uppstår - Kommunicera detta med uppdragsgivare, berätta om situationen och eventuellt ha några alternativa lösningar på förslag för att sedan tillsammans komma fram till bästa alternativet.

Förvisso. kan man oxå tänka sig att följande. Att innan man sätter en kravspec - så krävs det ju naturligtvis att man har utfört en förstudie som i så långt som möjligt skall kunna täcka in alla eventuella frågetecken som berör kravspecifikationen.

Sammanfattningsvis alltså...
- Dålig kommunikation mellan projektledare och uppdragsgivare under projektets gång är huvudorsaken till projektets resultat. Detta får senare konsekvenser av att man inte levererar ett system som möter de från början satta kraven vilket obarmhärtigen leder till en missnöjd uppdragsgivare.

//Fredrik L

Utveckling av websystem på Lavasoft

1: Vad var det som gick fel med projektet?

Enligt min reflektion så gick det mesta fel i projektet då Lavasoft inte kunde hålla tidsplanen för vad gällande implementeringen. Projektledaren i det här fallet verkar ha anlag för hybris samt vara en mindre teamplayer en vad projekten efterfrågade. Trots att flera medlemmar i projektet verkade vara oense om vilket slags system som bäst uppfyller kraven på webplatsen, anser Maja att det är mer eller mindre uppenbart vilket slags system som efterfrågas. En viktig detalj som bidrog till ett stort misstag var att man isolerade projektgruppen från andra utvecklingsgrupper i Lavasoft. Varför tar man ett sådant beslut? På vilket sätt påverkar detta övriga i gruppen? En annan sak som man i ett tidigt skede även bör lägga mer tid på, så att det inte sker stora frågetecken längre fram i projektet är att, fastställa ett systemperspektiv utifrån kundens krav och önskemål, dvs. åtminstonde säkra sig om att det nya systemet är kompatibelt gentemot det gamla. I det här fallet så blev konsekvensen förödande mot tidsplanen, vilket i sin tur gjorde att hela projektet och implementeringen blev 2 månader försenat, samt att man gick miste om en kontinuerlig relation med kunden.

2: Vilka misstag gjorde man inledningsvis i projektet?

En viktig komponent inom alla utvecklingsprojekt för vad gällande informationsbearbetandesystem är den kommunikativa processen mellan kund och leverantör. Om kunden inte blir nöjd med det färdigimplementerade systemet, blir det iterationer vilket leder till kostnader. Därför bör en kravspecifikation fylla upp alla aspekter som kan vara avgörande för hur systemet formas. I Lavasofts fall så verkade det inte vara några inledningsvis stora frågetecken kring kundens krav och önskemål, dock så var inte alla medlemmar i gruppen ense om systemvalet. Detta borde Maja ha tagit hänsyn till i ett tidigt skede eftersom "luckan inte fylldes upp", dvs man blev tvungen att i ett senare skede i projektet ta itu med dessa frågor. Maja bidrog hursomhelst med en presentation av systembeskrivningen för resterande projektmedlemmar vilket vissa i gruppen tyckte var alltför vag och otydlig. När man har kommit så här långt i projektet, bör man åtminstonde ha en homogen bild i gruppen av hur systemet bör formas. 

3: Hur kunde problemen kvarstå utan åtgärd under så lång tid?

Enligt min uppfattning och tolkning så återstod problemen först och främst för att Maja inte tog någon vidare hänsyn till dem övriga i gruppen och deras åsikter, samt att man valde att isolera gruppen från andra utvecklingsgrupper inom Lavasoft. Sedan så hade man tydligen inte någon kompetens som i gruppen som matchade med en del av kraven i kravspecifikationen, vilket ledde till att man ändrade en del punkter i den. 

4: Egna reflektioner

Det vore i ett verkligt fall ganska absurt för ett företag att låta en projektledare som i det här fallet verkar var av den oerfarne typen, leda en projektgrupp. Dock så lär man sig ju även av sina misstag, men detta bortser inte från faktum att hela projektet gick med förlust i slutändan, vilket även gjorde att man tappade en potentiell kund i framtiden i Lavasoft. Det är en sak att göra bort sig totalt i en mindre omfattning, men att göra bort sig såpass mycket så att kunden inte vill höra av sig längre fram i tiden, det är inte gynnsamt för en verksamhet, utan det leder till en konsekvent posiotionering av företaget för vidare potentiella kunder i framtiden.

Dokumenatationens betydelse i systemutvecklingsprojekt

Jag skulle vilja påstå att detta är den viktigaste delen i varje projekt, vad projektet än handlar om. Att börja med en analysfas för att få en överblick vad som kommer behöva göras är viktigt. Det finns flera dokument i denna process som är viktiga för projektets vidareutveckling och framgång.
Som exempel behövs det alltid kravspecifikation, användningsfall, problemställning, tidsplan, olika sorters diagram med mera.
All denna dokumenation är ett viktigt skede i ett projekt, det är viktigt att inte gå igenom denna del för fort då det oftast kan uppstå problem. Dessa problem kommer vanligtvis senare i projektet på grund av för dålig planering och dokumentation. Vi läste bland annat om projektet som lavasoft utförde i den förra blogguppgiften. Där gick de för fort fram vilket innebar stora problem i utvecklingsfasen av systemet.

Om man bara tittar på ett sådant dokument som kravspecifikationen, om denna inte skulle överensstämma med uppdragsgivarens krav kan detta gå väldigt fel. Säg att man börjar utveckla ett system utefter de krav man kommit fram till, utan att uppdragsgivare har godkänt detta dokument, kan detta i slutändan innebära att man levererar en felaktig produkt.
En tidsplan är också ett väldigt viktigt steg i planering. Här får man en överblick på vilka deadlines man har och på så sätt hamnar man rätt i fas och slipper förklara för uppdragsgivare varför systemet inte är färdigställt.

/Joakim

Dokumentationens betydelse i systemutvecklingsprojekt

Analys

- Kravspecifikationen
Det här är ett av de viktigaste dokumenten eftersom det visualiserar det som systemet skall innehålla. Kravspecifikationen ligger till grund för hela projektet och man bör vara överens med beställaren om vad som skall finnas i kravspecifikationen och inte leverera varken mer eller mindre än vad kravet ifrån beställaren är. Eftersom om man gör mer än vad beställaren har beställt kommer man få svårt att ta betalt för det, samtidigt som om man gör det gratis så kommer beställaren räkna med att det är något man gör även nästa gång.

- Tidsplan
Genom att utforma en tidsplan kan man se hur lång tid projektet kommer att ta men tidsplanen är även väldigt viktigt under projektets gång då man på ett bra och lätt överskådligt sätt kan se hur man ligger till.

- Riskanalys
Riskanalysen är ett viktigt dokument för att åskådligöra de risker som föreligger innan de händer. Riskanalysen är däremot ett svårt dokument att utforma eftersom det finns otroligt många risker som kan vara svåra att förutspå.

- Användarfall
Att skapa användarfall gör att man får en bättre insyn i vad det är personerna som skall använda systemet skall göra. Vilket resulterar i att man lättare kan utforma systemet

- Omgivningsanalys
I många fall är det så att de nyutvecklade mjukvaran måste kunna kommunicera med både gamla applikationer men även mot applikationer som kan komma att utvecklas i framtiden. Det är därmed viktigt att man möjliggör sådan interaktion redan ifrån början.


Fortlöpande dokumentation

- Ändringar i Analysen
Under det att projektet fortlöper kan det hända att man kommer på lösningar som är bättre än det som man planerade för i analysfasen. I sådana fall är det viktigt att man går tillbaka och uppdaterar informationen så att dokumentationen hålls levande och inte blir inaktuellt

- Dokumentera den fortlöpande utvecklingen
Genom att dokumentera den fortlöpande utvecklingen, har man god dokumentation om någon projektmedlem skulle vara tvungen att lämna projektet och någon annan ta över. Det underlättar också även inför framtiden när man skall göra uppdateringar i systemet.

- Tidsrapportering
Under projektets gång är det även viktigt att man specificerar den tid man lägger ner i projektet. För att på sådant sätt se om den tiden man har tilldelat projektet räcker och fungerar senare även som underlag, när man skall fakturera kunden men även internt för att se att man gick med vinst och inte la ner för mycket i tid i projektet.


Leverans

- Handbok
I många projekt är det viktigt att man utarbetar en handbok så att de som skall använda systemet förstår sig på hur de skall utföra de olika momenten. Här kan man återanvända delar utav den dokumentation som man redan har skapat t.ex. användarfallen. Om man utarbetar handboken efter dessa så kommer användarna snabbt känna igen eftersom dessa är utformade efter det användaren skall göra i systemet.

- Godkännande ifrån beställare
Vid överlämnandet har man återigen nytta av tidigare delar man har skapat. Eftersom man då lätt kan granska och se att man har skapat de saker man kom överens om i kravspecifikationen.


Sammanfattning

Genom att göra grundläggande och överskådlig analys för att sedan dokumentera det fortlöpande arbetet och uppdatera och hålla dokumentationen levande, skapar man en bättre förutsättning för att få ett lyckat projekt. Även om en god dokumentation och analys inte med automatik betyder att det blir ett lyckat projekt ökar chansen för att utfallet blir bättre.

Om dokumentationen över hela projektet utförts på ett bra sätt är risken mindre att projektet misslyckas eller blir försenat samt så ökar chansen för att man får förnyat förtroende i framtiden hos uppdragsgivaren i andra projekt.

\\ Daniel

Utveckling av websystem på Lavasoft

Vad var det som gick fel med projektet?

Systemet levde inte upp till kundens förväntningar samt så blev projektleveransen försenad, vilket medförde extra kostnader för lavasoft i form av högre personalkostnader. System specifikation var bristfällig vilket ledde till extra arbete

Vilka misstag gjorde man inledningsvis i projektet?

Projektledaren hade inte den kompetensen att ta beslut om vilket system som skulle användas och borde istället för att ta beslutet själv vänt sig till projektgruppen och försökt komma underfund med vilket system som skulle ha använts. Man genomförde inte någon ordentlig omgivningsanalys vilket resulterade i att det nyutvecklande systemet inte kunde kommunicera med de omgivande systemen.

Tidsplanen borde ha tagits fram tillsammans med gruppen, eftersom det kan vara svårt för projektledaren att veta hur lång tid vissa saker kommer att ta om man inte har kompetensen inom det aktuella området.

Hur kunde problemen kvarstå utan åtgärd under så lång tid?

Förmodligen beror den här punkten på bristande tidsplanering samt dålig uppföljning utav den analys man faktiskt gjorde. Om man följt tidsplanen så skulle man tidigare märkt att man låg efter och man kunde förmodligen kunnat hålla tidsramen bättre.

\\ Daniel

Dokumentationens betydelse i systemutvecklingsprojekt

Dokumentationens betydelse i systemutvecklingsprojekt

Dokumentationen inom ett systemutvecklingsprojekt har en mycket stor betydelse för projektets framgång. Ett analysdokument ska innehålla massor av nödvändig information om det system som ska skapas.

*Klassdiagram
*Aktörer
*Användningsfall
*Funktioner
*Användargränsnitt

Och naturligtvis ingående beskrivningar om dom punkterna. Om inte dokumentation finns inom ett projekt är det mycket svårt att skapa ett system, det finns då ingen information att dubbelkolla i när programmeringsfasen börjar. Missuppfattningar kommer att ske och produkten kommer med stor sannolikhet inte bli klar i tid eller uppfylla dom önskemål som uppdragsgivaren vill.

Ett designdokument är en utveckling av analysdokumentet. Här defineras klasserna bättre och underklasser, klassnamn, funktioner, om funktionerna ska returera värden.

Hur informationen skall skickas i systemet. Meningen är att en programmerare ska kunna ta ett designdokument och skapa ett system av det. Detaljerna i beskrivningen är nyckeln till ett bra designdokument.