1.   Problembeskrivning

1.1 Bakgrund

Under varje höst kommer ett stort antal nya studenter till Datasektionen för att påbörja sin utbildning på KTH. Under veckorna innan de nya studenterna, n0llan, kommer så pågår en febril aktivitet bland de daddor, drifvare och doqumentarister som utgör mottagningen. Det skapas n0llegrupper, trycks n0llekort, sångböcker, arbetsscheman med mera. Arbete som tar en hel del tid att utföra. Arbete som med stor sannolikhet skulle kunna förenklas med hjälp av lämplig programvara.

1.2 Syfte

Syftet med projektet är att dels skapa ny programvara för att underlätta arbetet under n0llningen, dels att integrera befintlig programvara som finns för olika delar av arbetet som exempelvis tillverkning av n0llekort och sångböcker.

 

Uppdragsgivaren vill att vi skapar program för att kunna presentera och behandla relevant information om n0llan. De vill också kunna behandla bilder med tillhörande information, som tagits under aktiviteterna, i systemet. Detta ska bland annat underlätta vid skapandet av schlemmhäftet. Schlemmhäftet är en katalog med bilder, som tas under mottagningen, på samtliga n0llan.

 

Vidare vill uppdragsgivaren att man i systemet kan lagra relevant information om de personer som ingår i dadderiet  och vid vilka tillfällen dessa kan arbeta med mera.

 

Slutligen ska vissa delar av systemet kunna nås via webben samt ha ett användarvänligt gränssnitt. Det är också viktigt att koden dokumenteras bra för att underlätta framtida vidareutvecklingar av systemet.     

1.3 Krav och avgränsningar

1.3.1   Funktioner

1      Möjliggöra för systemet att kommunicera med befintlig programvara.

2      Programmet ska kunna presentera en lista över n0llan med relevant information som n0llegrupp, telefonnummer, allergier och kostvanor.

3      Kunna införa information som ovan i systemet.

4      Man ska kunna lägga till och ta bort n0llan samt daddor i systemet om någon försvinner eller tillkommer.

5      Man vill kunna skapa arrangemang och deltagarlistor i systemet.

6      Man vill också kunna skriva ut sådana deltagarlistor både n0llegruppsvis och i bokstavsordning.

7      Programmet ska kunna summera olika poster, så man exempelvis kan beräkna antalet personer som ska delta på ett arrangemang eller hur många av dessa som är vegetarianer.

8      Man vill ha möjlighet att lägga in information om när daddorna kommer vara borta och liknande.

9      Lägga till n0llegrupper till systemet med information om vilka n0llan och vilka daddor som ingår i grupperna.

10   Man ska även kunna införa bilder och information om bilderna i systemet.

11   Man vill sedan kunna visa dessa bilder samt tillföra information till systemet över webben.

12   tkomsten till webbsidan ska begränsas på lämpligt sätt.

13   Programmet ska ha ett lämpligt användargränssnitt.

1.3.2   Datormiljö

1.3.2.1   Hårdvara

Vi kommer att lägga upp vårt system på en MySQL-server.

1.3.2.2   Mjukvara

Vi kommer att programmera en databas i MySQL för att lagra informationen som läggs in i systemet. Själva programmet kommer skrivas i Java.

1.3.3   Användare

      Användarna kommer att vara de som är ansvariga för mottagningen på datasektionen, det vill säga daddor, drifvare och doqumentarister.

 

 

2 Förslag till lösning

 

2.1 Systemskiss

 

      SKISSEN H€R:

 

2.1.1 Beskrivning av olika delar av programmet

 

Denna del syftar till att specificera vad olika roller ska kunna utföra i vilka

delar av programmet.

 

Applikation

 

Finns på mottagningens konto

 

Ger möjlighet att:

                Skriva ut n0llekort

                Skriva ut schlemhäften

                Skriva ut sånghäften

                Skriva ut daddekit

                Skapa nytt nolleår

                Lägga till/ändra/ta bort n0llan

                Lägga till drivare/daddor/mammor

                Dela in n0llan i n0llegrupper


 

 

Webbgränssnitt

 

Körs på Nadas webbserver

 

    

tkomligt för alla daddor

                            Komma åt information om n0llan

                            Komma åt information om daddan

                            Skriva ut schema (för arrangemang)

                            Ange kostvanor för n0llan och daddan

                            Lägga till/ändra gäster samt deras kostvanor

                            Lägga till/ändra hjälpsamma personer

                            Lägga till/ändra önskemål om frånvaro

                            Komma åt och skriva ut deltagarinformation (om ett visst arrangemang)

 

 

     tkomligt för vissa.

                           Allt som daddan kan göra

                           Skapa/ändra arrangemang

                           €ndra/lägga till personalbehov (för arrangemang)

                           Boka personal (skapa schema för arrangemang)

                           Acceptera frånvaro

                           Lägg till/ändra deltagare (till arrangemang)

                           Importera arrangemang från tidigare år

 

3.1 Systematisk metod

 

Vi har valt att använda en blandning av olika systematiska metoder, men

med störst vikt på eXtreme programming-metoden.

Denna metod lämnar öppet för möjligheten att ändra i designen under

projektets gång med anledning av ändrade krav från uppdragsgivarna

eller oss själva. Vi kommer inte att följa denna metod till punkt och

pricka utan behålla det vi anser givande för projektets framgång. Med det menar vi bland annat att kontinuerligt modellera och testa systemet för att

upptäcka svårigheter och fel tidigt. Vi avser även att bygga moduler som är

fristående från varandra som sedan fortgående

integreras isystemet. På detta sätt

kommer vi minska risken att hela systemet faller pga en misslyckad modul.

 

3.2 Ansvarsfördelning i gruppen

 

Vi har valt att ha vissa huvudroller i gruppen, men alla personer har inte en

unik roll. Som projektledare har vi Jenny Olsson. Hon ska sköta kontakterna med uppdragsgivarna och kursledare samt se till att målen som är uppsatta nås

på utsatt tid och även samordna insatserna i gruppen. Som implementationsansvarig har vi valt Anna Malmqvist. Hon kommer att ha huvudansvaret för att implementationsfasen flyter på och att exempelvis olika moduler fungerar tillsammans. Viktor Edvardsson ska ha hand om alla dokument som produceras samt se till att lokaler tillalla möten bokas och även hålla koll på alla deadlines. Magnus Köhler kommer att ha hand om sammanställning av dokumentationen samt vara ansvarig för användarhandboken.

 

3.3 Tidsplanering av aktiviteter

 

Nedanstående tidsplan är preliminär.

 

Antal kurspoäng: 4

Antal timmar/poäng: 40

Antal projektmedlemmar: 8

Antal timmar att tillgå: 4 * 40 * 8 = 1280

Antal förbrukade timmar = 40

Antal resterande timmar = 1280 - 40 = 1240

 

Aktivitet

% av tid

Antal timmar

Tidsperiod

Möten

5

62

17 februari - 15 maj

Dokumentation

10

124

vecka 17 - vecka 18

Inlärning av ny kunskap

10

124

vecka 12

Implementation

50

620

vecka 13 - vecka 17

Testning av produkten

25

310

vecka 13 - vecka 17

Summor:

100

1240

 

 

 

3.4 Administration, möten etc.

 

Redan genomförda möten:

 

14 februari: 08.30-09.30 Första möte med uppdragsgivaren. 3 projektmedlemmar närvarande. Totalt 3 h.

17 februari:   En timmes möte. Allmän diskussion om projektet. 5 projektmedlemmar närvarande. Totalt 5 h.

19 februari:   2 timmars möte. Uppdelning av stycken i preliminära specifikationen.

8 medlemmar, totalt 16 h.

27 februari:   2 timmars möte. Redovisning av preliminära specifikationen. Andra mötet med uppdragsgivaren. 8 projektmedlemmar närvarande, totalt 16 h.

 

Planering av kommande möten och redovisningar. Preliminära datum och tider:

 

Möte:            måndag 17 mars, kl.15. Planering av arbetet och genomgång av återlämnad preliminär specifikation.

Möte:            tisdag 25 mars, kl.10. Tredje mötet med uppdragsgivaren.

Möte:            vecka 14. Avstämning av arbetet.

Möte:            vecka 15. Avstämning av arbetet.

Möte:            vecka 16. Avstämning av arbetet.

Möte:            vecka 17. Avstämning av arbetet.

Möte:            vecka 18. Avstämning av arbetet.

Förhandsvisning: tisdag 6 maj, 13-16.

Slutredovisning: torsdag 15 maj, 15-17.

 

3.5 Arbete med dokumentation

 

Arbetet med dokumentationen kommer att fortgå under hela projektets gång. En preliminär systembeskrivning görs redan i denna specifikation.  Denna kommer dock att vidarearbetas på under projektet. Användarhandledningen kommer att skrivas så fort användargränssnittet är klart och vi vet exakt vilka funktioner som kommer att ingå.

 

4. Riskanalys

 

¥ Otillräckliga förkunskaper. Projektgruppen har inte någon större erfarenhet av vare sig servrar eller bildhantering. €ven inom säkerhetsfrågor som t.ex. begränsning av informationsåtkomst är kunskaperna inom gruppen små. Risken kan behandlas genom att försöka lära sig något nytt eller avgränsa projektet ytterligare vid tidsbrist. Riskvärde: 16.

 

¥ Tidspress. Om det inte finns tillräckligt med tid till att dels göra själva arbetet och dels till eftertanke och tester finns det risk att projektet blir sämre än förväntat eller inte klart alls.

   Risken behandlas genom att sätta upp en tidsplan som följs i största möjliga mån eller justeras i annat fall. Riskvärde: 15.

 

¥ Dåliga projektdirektiv. Utvecklaren vet inte riktigt vad beställaren efterfrågar. Utvecklaren kanske skapar en fullt funktionell produkt som användarna inte behöver. Risken behandlas genom en tydligt skriven kravspecifikation och genom en dialog med beställaren.

Riskvärde: 12.

 

¥ Integrering av nu existerande programvara och vår kommande programvara kan bli svårt.

  Risken kan behandlas genom att använda tekniker som vi vet är kompatibla med varandra. Riskvärde: 12.

 

¥ Svåranvänd slutprodukt. Det finns en risk att programmet inte blir användarvänligt utan att funktionerna bli svåra att hantera och förstå. Löses genom tester med utomstående personer och hjälpdokument. Riskvärde: 9.

 

¥ Samarbetssvårigheter. I ett projekt uppstår konflikter. Konflikter kan leda till problem.

  Det är viktigt att varje projektmedlem gör sin del av arbetet dels för att inte belasta andra medlemmar ytterligare och dels för att inte fördröja eller förhindra arbetet i nästkommande fas. Risken med konflikter löses med samtal inom gruppen eller med utomstående hjälp innan konflikterna blir problem. Gemensamma mål och spelregler minskar risken. Riskvärde: 9.

 

¥ Otydligt projektmål. Projektets mål skall vara mätbart och uppnåeligt. Annars finns risken att projektet blir orealistiskt stort och därmed alltför komplicerat. Risken behandlas genom att projektmedlemmarna kommer överens om mål och ambitionsnivå vid projektstart. Riskvärde: 8.

 

¥ Resursbrist. Inom projektarbetet kan resurser som personal, datorkapacitet och pengar saknas. Risken med personalbrist kan lösas genom att avgränsa projektet på ett lämpligt sätt. Risken med datakapacitetsbrist löses genom diskussioner och hjälp från systemansvariga. Risken med pengabrist drabbar i vårt fall endast projektmedlemmarna personligen och utanför projektet och risken kan behandlas genom att samla tillräckligt med högskolepoäng åt CSN. Riskvärde: 6.

 

¥ Dålig beställarkompetens. Beställaren vet inte om den önskade produkten är tekniskt möjlig eller om produkten kan lösa beställarens behov. Kanske behöver beställaren inte ens någon produkt. Risken behandlas genom kontinuerlig kontakt där beställaren får se prototyper och svara på frågor om användningsområdet och produktens utformning. Riskvärde: 4.

 

 

¥ Ickegodkänd ändring av projektmål. Vid projektarbete är det lätt att glida ifrån målet. Projektmedlemmarna kan hitta något de tycker är intressantare att arbeta med och glömma de gemensamma mål som sattes upp tillsammans med beställaren. Risken behandlas genom att få förändringarna i arbetet godkända eller genom att återgå till ursprungliga uppgifterna. Riskvärde: 4.

 

¥ Kompetensblindhet. Utvecklaren kan bli blind p.g.a. sin kompetens. Beställarna och användarna förstår inte det tekniska lika bra och skall ändå kunna förstå och använda produkten utan tekniska färdigheter. Risken behandlas genom att testpersoner utanför projektgruppen får testa såväl halvfärdig som färdig produkt. Produkten skall vara intuitiv. Riskvärde: 4.

 

¥ Avhopp. Projektmedlemmar kan hoppa av projektet av privata skäl eller om det tar för mycket tid i anspråk. Insatta projektmedlemmar är svåra att ersätta och med vem i så fall?

Risken kan behandlas genom att försöka ta med sådana oförutsedda händelser i tidsplanen. Riskvärde: 3.