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.

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.

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

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

uppdragsgivarens roll i projekterings- och planeringsfaserna

Här kommer min syn på uppdragsgivarens roll i projekterings- och planeringsfaserna.

Uppdragsgivaren har den viktigaste rollen genom hela projektet och då speciellt före och vid projektstart, eftersom uppdragsgivaren där lägger grunden till det projektet skall behandla. Därmed är det viktigt att uppdragsgivaren har en klar bild över var det är systemet skall åstadkomma samt fungera och har förankrat det här hos de som skall använda systemet. Annars finns det en överhängande risk att systemet inte kommer att användas eftersom projektet inte möter användarnas krav.

För att säkerställa att projektet kan fortskrida utan förseningar samt för att kunna hålla uppdragshandlingen levande är det viktigt uppdragsgivaren finns lätt tillgänglig. Det är även viktigt att denna kontakt finns om det uppstår några problem eller oklarheter som behöver redas ut. Annars är det lätt att projektet drar ut på tiden, eller inte möter uppdragsgivarens förväntningar vid leverans.

Så en löpande och regelbunden kommunikation mellan projektledaren och uppdragsgivaren är vital för att kunna genomföra ett projekt som blir väl utarbetat för den funktion det senare skall fylla.

\\ Daniel

\\ Daniel

Uppdragsgivarens roll i projekterings- och planeringsfaserna

Uppgragsgivaren har ett problem eller en vision om något. Detta görs om till projektdirektiv eller en kravspecifikation om vad som måste göras. Direktiven/kravspecifikationen lämnas till gruppen som ska realisera projektet, kan vara programmerare om det handlar om ett datorprogram.
Uppgragsgivaren är chefen över gruppen och ska få regelbunden information om projektets gång och eventuella problem som uppstår. Denna informationen måste få feedback tillbaka till projektgruppen, så allt går enligt planerna.

När direktiven skrivs ner på papper så ska det innehålla några viktiga punkter. Tid för projektet, högsta kostnader projektet får kosta, målet med projektet. Om det finns några resurser att använda som gamla dokumentationer.

Problem som kan uppstå:
Om inte direktiven är nerskrivna eller felaktiga kan hela projektet äventyras då projektgruppen går efter dessa felaktiva direktiven eller har glömt av något som måste finnas med.
Problemet motverkas med regelbunden kommunikation till uppdragsgivaren.

Slutsats: Uppgragsgivarens roll i projekterings- och planeringsfaserna är nödvändig om slutprodukten ska bli en lösning på ett problem eller realisering av en vision.

// Markus Nordin

Uppdragsgivarens roll i projekterings- och planeringsfaserna

Uppdragsgivaren i projektplanerings faserna är av samverkande natur. Samverkningarna skall ske tillsammans med den projektgrupp som skall utföra Uppdraget(projektet). Målet är ju naturligtvis att projektgruppen skall få en likställd bild av problemet som Uppdragsgivaren har. Allt för att man skall göra och planera inför att göra rätt saker. Det inledande samverkandet skall ge projektgruppen så mycket kött på benen att de kan skriva ihop ett projektdirektiv. Detta kan ju senare användas av uppdragsgivaren som en kvittens på att projektgruppen har förstått vad som skall ingå i projektet. Har uppdragsgivaren synpunkter på direktivet så blir detsamma istället föremål för diskussion att klargöra vad som eventuellt har en felaktig inriktning etc.

Däremot så förefaller det projektgruppen som framställer projektdirektivet att vara mycket tydliga samt använda ett språk som uppdragsgivaren förstår. Sedan är det naturligtvis så att även om man skrivit ett projektdirektiv som inte angav några synpunkter hos uppdragsgivaren så kan det fortfarande uppstå frågetecken under projektets gång som gör att en tät kommunikation med Uppdragsgivaren ofta kan vara av godo för projektets resultat.

Uppdragsgivarens roll i projekterings- och planeringsfaserna

I ett projekt som vårat har uppdragsgivaren, så här långt, haft stor betydelse. Vid första anblick av vårat projekt förstod vi knappt vad som skulle utföras. Genom snabb kontakt fick vi bokat ett möte redan i de första dagarna av projektets start. Detta möte gav oss en större förståelse vad som skulle göras samt hur vi kunde utföra detta på bästa sätt.

Om vi i projektgruppen inte hade bokat detta möte hade det troligtvis blivit feltolkningar och därför ett felaktigt direktiv.
Även efter detta möte har vi haft en del kontakt med våran uppdragsgivare angående specifika delar. Direktivet skickades sedan in för att kontrolleras av uppdragsgivare, de synpunkter som då uppkom tog vi åt oss i både en komplettering av direktivet samt i projektplanen.
Med detta menar jag att uppdragsgivaren har en väldigt stor roll i dessa faser, hade inte vi fått klara krav och direktiv på vad som skulle göras hade uppdragsgivaren troligtvis varit missnöjd med de förslag som vi lade fram.

Samtidigt som det ligger på projektgruppen att förstå uppdragsgivarens krav anser jag även att denne måste vara tydlig i sin beskrivning. Som tidigare nämnt hade vi svårt att förstå våran uppgift med projektet, vi hade exempelvis inte utan kontakt fått reda på att det var två olika delprojekt.

Jag anser att även om man har relativt fria händer i ett projekt är det viktigt att alltid avstämma med uppdragsgivare under projektets gång så man är på rätt spår i utvecklingen. Finns inte denna ständiga kontakt finns det risker att tidsplaner inte kan följas och projektet blir senarelagt.

/Joakim

Uppdragsgivarens roll i projekterings samt planeringsfaserna

Ett projekt består utav multipla komponenter som är av betydande karraktär i dess livscykel. Uppdragsgivaren som enskild faktor är viktig för oss som projektdeltagare då våra interna beslut kring de olika faserna kan vara kritiska utifrån uppdragsgivarens krav och önskemål. Uppdragsgivaren bör då ha en relativt klar bild om vad det är för uppgift som vi skall erhålla och bekräfta genom en lösning. Därmed bör det uppstå en kontinuerlig dialog mellan projektgruppen och uppdragsgivaren.

Vi i våran grupp har upprättat en kommunikationsprocess kring de milstolpar i projektet som har krävt feedback samt input ifrån våran uppdragsgivare. Restriktioner kring ideer och tankar var därför avgörande utifrån den bearbetade inputen som vi erhållit, som i sin tur har varit konsekvent gentemot de etapper i projektet som följer. Projektdirektivet är ett exempel där uppdragsgivaren och projektgruppen bör konkretisera den ömsesidiga förståelsen för beslutet som sådant, i värsta fall kan det annars uppstå oklarheter och mycket iterativt arbete får då läggas för att uppnå det önskade resultatet. Om en icke ständig dialog existerar mellan uppdragsgivaren samt projektledaren/gruppen, finns det även en risk för att tidsramen som sådan bryts och planeringen uppoffras till att lägga mer tid kring. Detta vore ju inkonsekvent i förhållande till de faktiska förhållandena som bör finnas mellan uppdragsgivaren samt projektgruppen. Planeringen kan med andra ord formas utifrån andra förutsättningar om dialogen mellan samtliga nödvändiga parter är bristfällig.

Direktivet är ju ett fundament som planeringen sedan skall bygga vidare kring. Om direktivet är vagt blir även planeringen kostsamt gentemot det faktiska projektet. Direktivdialogen samt själva direktivet blir konsekvent gentemot syftet med planeringen. Dessa faktorer belyser kommunikationen mellan uppdragsgivaren samt projektgruppen, i många fall projektledaren, dock så är detta inte avgörande för projektledarens roll då samtliga parter i gruppen är aktiva kring de dialoger som uppstår emellanåt. 

//Amir

Projektplan bearbetas

Då var vi igång med V15. På dagordningen står att framta en projektplan för projektet. Vi har under gårdagen, (måndag) haft vårt veckomöte där vi gick igenom diverse kompletteringar till projektdirektivet. Vi gick dessutom in och delade upp delarna som skall skrivas för projektplanen.

Vi har upptäckt att saker och ting kommer lite bakvänt för vår del pga av de krav vi har att gå Live med somliga delar redan i månadsskiftet april/maj. Detta tvingar oss att parallellt med projektplaneringen dessutom arbeta med projektet som vi planerar för... Vilket gör situationen lite speciell. Målsättningen nu är iallafall att ha så mycket som möjligt (läs "skall vara klart") klart av projektplanen på Onsdag senast Torsdag.

//FL

Projektdirektiv

Här kommer en liten lägesrapport:)
Projektdirektivet är färdigt och skickat till Mia.

Har även försökt få tag i Ulrika angående materialet med intervjuerna. Vi vill ju gärna ha det så fort som möjligt då detta kommer ligga som grund för användningsfall, kravspec med mera. Framför allt underlätta en hel del för oss.

/Jocke

Mötet gick fint

Då har vi äntligen kommit igång på riktigt. Under gårdagen så hade vi (samtliga gruppmedlemmar) ett möte tillsammans med uppdragsgivaren där vi fick lite bättre direktiv på vad vårt projekt skulle gå ut på. Under eftermiddagen så lyckades vi knåpa ihop en riskanalys tillsammans med en preliminär tidsestimering kring de delar som vi kommer ha med i vårt projekt.

När det gäller riskanalysen så insåg vi ganska snart att det gällde verkligen att vi hade rätt planering och att vi hade förstått uppgiften rätt.

Vi har snart satt ihop vårt första utkast till Projektuppgift 1: "Projektdirektiv". Uppdragsgivaren ville titta igenom detta redan i morgon lunch.

Utöver Projektdirektivet så har vi åtagit oss att under veckan hantera det mesta av analysdelarna som behövs för att bygga en databasmodell. 

/FL

Val av miljö...

Skulle först gjort en kommentar till nedanstående inlägg av fredrik men sen blev det så långt att jag gör ett inlägg istället.

På första föreläsningen så pratades det om de hade önskemål om att stommen skulle vara uppbyggd ifrån Joomla, ni som inte vet vad Joomla är kan läsa mer på www.joomla.org. Därmed misstänker jag att de vill ha det här projektet i samma språk, alltså PHP, med en MySQL databas vilket alltså fungerar utmärkt att köra på tor. Om så inte fallet skulle vara så är det ju en väldig skillnad på en utvecklingsserver och en produktionsserver, utvecklingsservern enda uppgift är ju att ha en plats där man kan utveckla en applikation därför skall den likna en produktionsmiljö i största möjliga mån, om nu uppdragsgivaren önskar en applikation som kräver Windows så bör det ju inte vara några större problem att få fram en IIS server som vi kan använda som utvecklingsserver.

Att blanda in SVN för versionshantering m.m. känns lite att ta i, vi bör enligt min mening hålla sidprojekt m.m. till det minimala för att inte tappa fokus och lägga energi på sådant som inte direkt berör projektet. Alla fem skall ju inte heller koda, det är ju inte riktigt det som projektet går ut på, inte som jag har förstått det iaf. Utan vi bör kanske minimera själva programmeringen till två, tre personer? Dessa två eller tre personer borde kunna dela upp de olika delarna sinsemellan utan några större problem, så länge som vi har ett bra underlag att utgå ifrån. Sedan är det ju klart om det som tar på sig uppgiften, att programmera har kunskapen och erfarenhet utav att jobba i någon SVN lösningar så är det ju klart det bästa.

Med tanke på att det är så många frågetecken samt att jag tycker att projektdirektiven inte är de mest tydliga så anser jag att vi bör invänta mötet på måndag innan vi försöker oss på att ta några beslut om utvecklingsmiljö och liknande.

Btw, varför är bloggen låst för utomstående?

Frågan om miljö kan redan vara beslutad.

Ni andra har säkert ochså redan sätt informationen rörande "serverplats" som skulle stå till buds på 'tor'.

För er som inte vet så är tor en linuxmaskin vilket - om det är tvingande ställer till det för oss om vi vill köra .NET. Om detta är ett tvingande beslut för oss så gissar jag att det som ligger närmast tillhand blir att bygga i Java, JSP och då MySQL (som oxå ligger på tor). Vilket kanske iochförsig inte är en nackdel för vår uppdragsgivare eftersom licensieringskostnader och annat kommer bli mycket fördelaktigt i ett sådant här scenario. Men än är inte de kokta fläsket stekt - denna diskussion återstår fortfarande. Naturligtvis finns ju en möjlighet att de kanske har virtuella windowsmaskiner på tor oxå, och att det den vägen ger oss möjlighet till .NET?

Även om det är en hel del analys och modellerande kvar innan vi är "framme" så ser jag en risk redan nu:
Det är SVN. Jag vet inte om sådant finns uppsatt på tor oxå? Eller hur versionhantering och annan källkodshantering är tänkt att fungera. Jag har under experimentella former satt upp en SVN server på hemmaplan här - men känner mig inte helt hundra på att drifta en sådan (ännu). Någon av er andra som har kompetens av sådant här om det skulle vara så?
Hur "vana" är ni i att programmera tillsammans med andra - i samma projekt?

Competence Center-bloggen har initierats

Nu har bloggen initieras...