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
söndag 31 maj 2009
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
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
lördag 30 maj 2009
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.
fredag 29 maj 2009
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
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
- 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.
söndag 24 maj 2009
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.
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.
måndag 18 maj 2009
Javasofts projekt
Vad var det som gick fel med projektet?
Lavasoft kunde inte hålla tidsplanen, misslyckades att integrera hemsidan med existerande system inom tidstamen, drog på sig större kostnader än planerat, ingen nöjd kund och misslyckades att kommunicera inom projektgruppen,
Vilka misstag gjorde man inledningsvis i projektet?
Projektgruppen var inte eniga om hur dom skulle lösa arbetsuppgiften, kravbeskrivningen var dålig och en del av kraven kunde inte uppfyllas av projektgruppen (kompetens). Med detta gjordes inga åtgärder vilket känns väldigt dåligt.
Hur kunde problemen kvarstå utan åtgärd under så lång tid?
Projektledaren beslutade om programmering innan allt var löst inom projektgruppen, problemen var fortfarande kvar och det gjorde att projektet var helt onödigt för Javasoft.
Utvecklingsgruppen ändrade specifikationen utan att informera projektledaren om jag ska tolka texten.
Ev andra egna reflektioner.
Mina egna åsikter om detta projektet så var det många fel som knyts tillbaka till kommunikation. Det verkar som hela gruppen inte kunde prata om problemen och stå på sig om dom problem som fanns. Om alla problem hade uppmärksammats så kunde ett beslut tas om projektet skulle skrotas, förlänga tidsplanen eller hyra in den kompetens som hade behövts för projektet.
Lavasoft kunde inte hålla tidsplanen, misslyckades att integrera hemsidan med existerande system inom tidstamen, drog på sig större kostnader än planerat, ingen nöjd kund och misslyckades att kommunicera inom projektgruppen,
Vilka misstag gjorde man inledningsvis i projektet?
Projektgruppen var inte eniga om hur dom skulle lösa arbetsuppgiften, kravbeskrivningen var dålig och en del av kraven kunde inte uppfyllas av projektgruppen (kompetens). Med detta gjordes inga åtgärder vilket känns väldigt dåligt.
Hur kunde problemen kvarstå utan åtgärd under så lång tid?
Projektledaren beslutade om programmering innan allt var löst inom projektgruppen, problemen var fortfarande kvar och det gjorde att projektet var helt onödigt för Javasoft.
Utvecklingsgruppen ändrade specifikationen utan att informera projektledaren om jag ska tolka texten.
Ev andra egna reflektioner.
Mina egna åsikter om detta projektet så var det många fel som knyts tillbaka till kommunikation. Det verkar som hela gruppen inte kunde prata om problemen och stå på sig om dom problem som fanns. Om alla problem hade uppmärksammats så kunde ett beslut tas om projektet skulle skrotas, förlänga tidsplanen eller hyra in den kompetens som hade behövts för projektet.
Dokumentationens betydelse i systemutvecklingsprojekt
"Dokumentationsprocessen ger upphov till den klassiska konflikten mellan att skapa
överblick och att dokumentera detaljer. Detaljer kan dränka överblicken.
En dokumentationsstandard gör det lättare att se till att dokumentationen blir
homogen"(Matthiassen, Munk-Madsen, Nielsen, Stage, 2001, sid 341).
Ovanstående citat beskriver betydelsen av en standard gentemot dokumentationen
kring ett systemutvecklingsprojekt. Standardens roll är alltså att framhäva en
tydlig konvention för att underlätta förståelsen kring innehållet.
Dokumentationen i ett systemutvecklingsprojekt spelar en central roll och tjänar olika
behov genom att styra arbetet, strukturera de inkrementella delresultaten i projektet
samt dokumentera övriga överrenskommelser om systemkrav och design. Dokumentationen
som sådan kan delas upp i två olika dokument:
* Analysdokument - En omfattande samt sammanhängande presentation av analysresultatet
* Designdokument - En omfattande samt sammanhängande presentation av designresultatet
Det är viktigt att man som utvecklare tillsammans med användaren i ett initierande läge
skapar ömsesidiga formaliteter kring de skriftliga överenskommelser som etableras.
Detta skall även vara som en grundval för den blivande kravspecifikiationen.
Designdokumentet skall å andra sidan upprätta en referensram som programmeraren kan
relatera till, och på så vis underlätta dennes arbete istället för att stagnera det
genom överflödigheter , istället bör designern
skapa förutsättningar för programmeraren genom en kort och precis dokumentation
som identifierar systemets komponenter och bestämmer dess struktur, funktionalitet samt
gränssnitt.
Språket i dokumentationen bör ligga på en perceptuell nivå för tolkaren. Tanken
är med andra ord inte att man skall förvirra läsaren med allt för abstrakt artikulerade
formuleringar, utan istället använda en terminologi som tilltalar bägge parters
verklighet. Detta kan ske med hjälp av symboler som diagram, figurer, tabeller, formler
och pseudokod. Kombinationen av dessa komponenter skulle mycket väl i samband med
ett renodlat språk kunna etablera en god dokumentation, förutsatt att den framhäver
sakinnehållet.
Sist men inte minst bör dokumentationen agera som ett "uppslagsverk" för bägge parter
i ett projekt för systemutveckling, detta delvis för att minimera konflikter mellan
parterna och på så vis vinna tid istället för att gå miste om den, då tiden anses vara
alltför värdefull i en sådan kontext.
//Amir
onsdag 13 maj 2009
Utveckling av websystem på Lavasoft
Maja har tagit rollen som projektledare alldeles för stor. Hon bestämmer över de andra vilket gör att projektet går utför. Redan i analysfasen tog hon ansvaret att göra vissa delar, dessa fick hon feedback på men tog inte åt sig detta utan gick på nästa steg. Projektet gick för fort fram på grund av att hon ignorerat de delar som borde utvecklats. Ändå försökte de andra medlemmarna nå fram till henne genom att säga vad de tyckte med hon ansåg att det var bra som det var.
Delen med att hålla deras projekt ”hemligt” från resten av företaget känns som idioti. Här hade man kanske istället kunnat ta hjälp under projektets gång istället för att undvika att hamna efter i tidsplanen.
I den tidsplan som skapats har de inte lagt tillräckligt med tid på analysfasen. De har lagt mer tid på utvecklingsfasen vilket innebär att när de väl började med programmering och dylikt blev detta fel. Stora delar fick istället göras om. Hade de lagt ned mer tid på att forska inom de olika delarna i ett tidigt skede hade de troligtvis lyckats bättre än vad de gjorde. Allt detta gjorde att projektet blev försenat med en längre tid.
Att problemen kvartod så länge kan jag tänka mig har med just planeringsfasen att göra. När de inte lade ned den tid som behövdes på denna del var denna tvungen att göras senare, i omvänd ordning för att få räta på problemet.
/Joakim
Delen med att hålla deras projekt ”hemligt” från resten av företaget känns som idioti. Här hade man kanske istället kunnat ta hjälp under projektets gång istället för att undvika att hamna efter i tidsplanen.
I den tidsplan som skapats har de inte lagt tillräckligt med tid på analysfasen. De har lagt mer tid på utvecklingsfasen vilket innebär att när de väl började med programmering och dylikt blev detta fel. Stora delar fick istället göras om. Hade de lagt ned mer tid på att forska inom de olika delarna i ett tidigt skede hade de troligtvis lyckats bättre än vad de gjorde. Allt detta gjorde att projektet blev försenat med en längre tid.
Att problemen kvartod så länge kan jag tänka mig har med just planeringsfasen att göra. När de inte lade ned den tid som behövdes på denna del var denna tvungen att göras senare, i omvänd ordning för att få räta på problemet.
/Joakim
Prenumerera på:
Kommentarer (Atom)