På en allmän nivå består uppgiften av att studenterna i större grupper genomför ett fullständigt programutvecklingsprojekt, från planering till testning. Arbetet utförs huvudsakligen i enlighet med de principer om Software Engineering som anges av Roger S. Pressman. Det objektorienterade program som konstrueras under kursen implementeras med hjälp av programspråket C++, samt dokumenteras enligt de krav på modellering som ges av Booch et al. I projektarbetet kommer kunskaper från alla olika delar av kursen att praktiskt tillämpas, och projektarbetet tillåts därvid också uppta en mycket stor del av kursen både tids- och arbetsinsatsmässigt. Projektet utgår ifrån den initiala specifikation som företaget Blåsbälgen lämnat.
Arbetsmässigt tillhör projektet hela kursen och det finns, förutom om det särskilt specificeras, ingen skiljelinje mellan de två momenten i kursen vad gäller projektarbetet.
Observera att hela projektarbetet inklusive redovisningar, kundmöten och dokumentation ingår i betygsbedömningen. Dokumentationen är den del som väger tyngst, vilket inte innebär att de andra delarna är oviktiga. Märk också att kvaliteteten på den skapade programvaran inte bedöms i betygshänseende, frånsett att ett seriöst arbete med att skapa programmet givetvis krävs (se också nedan under "Målsättning").
Projektets övergripande mål är att ge en så realistisk uppfattning som möjligt om de problem och möjligheter som uppstår när programutveckling utförs tillsammans av en större grupp människor. Projektet tjänar också som kursens sammanhållande länk och ger tillfälle till praktisk tillämpning av de kunskaper som förmedlas och som inhämtas av studenterna själva genom kurslitteratur och annat material. På så sätt kan också projektarbetet ses som vägledande för studiet av litteraturen, i synnerhet vad gäller Pressman och Booch et al., där aktuella problem i projektarbetet styr inläsning och inlärning, snarare än kapitel och föreläsningsämnen.
Projektets framgång ur utbildningssynpunkt har också mycket lite att göra med kvaliteten på det slutligen producerade systemet, även om det förutsätts att varje grupp skapar ett åtminstone kör- och testbart program. Projektets mål ligger framför allt i genomförandet av processen och i att konfronteras med alla de utmaningar som ligger i att få ett utvecklingsteam att fungera tillsammans kring en så komplicerad produkt som en datorapplikation. Utöver detta ger projektet varje deltagare möjligheter att fördjupa sina kunskaper på olika intresseområden.
Projektet genomförs i grupper om 8—12 deltagare, beroende på det totala antal deltagare i kursen. Under hela projektarbetet gäller principen att varje grupp fritt disponerar de resurser man förfogar över i form av personer och tid. Detta betyder att varje grupp tillåts att mycket självständigt planera och fördela arbetet.
Under kursen kommer tid att finnas avsatt för s.k. kundmöten. Detta är möten med den tänkta kunden av det beställda systemet. Kundmötena ska alltså användas för kommunikation med beställaren, där utvecklingsgrupperna kan redovisa det man kommit fram till och inhämta synpunkter på det blivande systemet från kunden, dvs. stämma av projektets validitet gentemot beställaren. Observera alltså att dessa möten bör ses som den primära kanalen för kommunikation mellan kund och utvecklare, där dessa tillsammans ska komma överens om vilka egenskaper det nya systemet ska besitta. Kundmötena ska alltså inte på något sätt betraktas som redovisning av utbildningsresultat för lärare. Observera att vi under kursen gör en distinktion mellan lärar- och kundrollen. Lärarna på kursen kommer därför inte att kunna agera både kund och lärare på samma gång.
Denna första
redovisning som hålls ungefär mitt i kursen syftar till att presentera
utvecklingsteamets analysdokument för kunden, i synnerhet de objektorienterade
analysmodellerna ni utvecklat i notationsspråket UML.
Observera att presentationen ska vara anpassad för kunden, och inte för
lärarna eller andra utvecklare. Det gäller alltså att anpassa
och formulera presentationen på ett sådant sätt att kunden,
som t.ex. kan ha mycket liten datorvana, förstår vad det är
för system som ska byggas, hur det är tänkt att fungera och vilken
funktionalitet det är tänkt besitta.
Lärarkritik
på de objektorienterade analysmodeller varje grupp presenterar kommer
att ges skriftligt i efterhand.
Se ”Analysmodellredovisning” för mer
detaljerade instruktioner.
Viktigt: Lärarkritik innefattar bedömning av dokumentets kvalitet och synpunkter på modellernas formella utförande. Modellernas eventuella duglighet som underlag för det blivande programmet bedöms inte utan detta är upp till projektgruppen att själva avgöra och fatta beslut om tillsammans med kunden. Detta betyder att gruppen omedelbart kan fortsätta projektarbetet med programdesign, och om man är ute i god tid finns det ingen anledning att vänta på redovisningstillfället innan projektarbetet förs vidare. Tidplanen för projektarbetet bör alltså inte baseras på schemaläggningen av redovisningen.
Slutredovisning innehåller två delar:
Först presenterar och demonstrerar projektgruppen sitt ”färdiga” system för kunden. Presentationen ska innehålla både en muntlig presentation och en demonstration av systemet. Den muntliga presentationen bör åtföljas av goda illustrationer som ger en bra översikt av systemet som helhet. Denna del bör ta 15 - 20 min
Därefter görs en projektredovisning som riktar sig till medlemmarna i den andra gruppen och lärarna. Där bör tas upp framrför allt det som har med projektets genomförande, dvs vad som gick bra och vad som gick dåligt och varför samt varför och hur olika beslut fattades, hur arbetet bedrivits och organiserats mm. Kort sagt, allt som man borde ta upp i konsultfirman när man följer upp ett nyligen avslutat projekt för att dra lärdomar inför kommande uppgifter.
Denna del kan förväntas ta 30 - 40 min.
Skriftlig kritik
av dokumentationen ges i efterhand.
Utse projektledning och genomför fördelning av övriga roller i projektet. Bestäm preliminärt formerna för projektarbetet, typ av möten, mötesfrekvens, kommunikationsformer, kundmötesstrategier m.m.
I enlighet med Pressmans riktlinjer för projektplanering. Beräkningar enligt statistiska metoder kan uteslutas eftersom det kräver tillgång till tidigare projektdata och erfarenhet från tidigare projekt.
Analysen sker i enlighet med undervisningen i datamodellering och med hjälp av notationsspråket UML i enlighet med Booch et al., samt i enlighet med de krav som ställs i Software Engineering enligt Pressman.
Programdesign
ska ske i enlighet med Pressman samt med stöd av övrig litteratur
och undervisning om objektorientering.
Implementation skall
ske av en prototyp till systemet med C++, i den omfattning som är möjligt
med hänsyn till tid och kunskaper samt tekniska begränsningar. Programmet
bör också ha testats såpass att man vid presentationen har
en klar uppfattning om vilka väsentliga problem och buggar som kvarstår.
Detta arbete spänner över hela projekttiden. Projektets framskridande skall fortlöpande dokumenteras i någon form av projektdagbok. Alla deltagare måste svara för att hålla reda på sina arbetsinsatser, och rapportera dessa till den/de som ansvarar för uppföljningen. Mot slutet skall produktiviteten i projektet grovt beräknas, t.ex. i antal rader kod/tidsenhet. Alla väsentliga problem med orsak och åtgärder ska noteras.
Projektets alla steg ska dokumenteras i enlighet med de krav på projektdokumentation som anges av Pressman, med undantag för diverse statistiska uppskattningar och andra matematiska modeller som ni finner det omöjligt att genomföra med tillgängligt material.
Dokumentationen bör också innehålla en "projekthistoria", vilket betyder en redovisning av arbetsprocessen, beslutspunkter, underlag för olika beslut, problem och lösningar på dessa samt annat som har haft betydelse för projeketets genomförande.
Notera att dokumentationen är en av de viktigaste delarna i betygsbedömningen av projektet.
Blåsbälgen AB är ett företag i ventilationsbranschen. Vår specialitet är att bygga upp skräddarsydda ventilationsanläggningar, främst för mindre och medelstora företag. Dessa finns i alla branscher från verkstadsföretag till restauranger. För varje installation upprättar vi som regel ett underhållskontrakt, där kunden mot en årlig avgift får löpande underhåll och reparationer på platsen. Underhåll innefattar främst periodiska byten av filter och slitdetaljer samt rengöring av kanaler. Reparationer sker vanligast genom utbyte av komponenter.
Ett normalt ventilationssystem är uppbyggt av standardmoduler. Exempel på sådana är fläkthus i olika storlekar och utföranden, spjällhus, reglerautomatik, filterhus, kanaler och kanalanslutningar. I sin tur kan en modul bestå av ett flertal utbytbara komponenter. Ett fläkthus kan exempelvis bestå av kapsling, kanalanslutningar, fläkthjul, fläktmotor, upphängningsanordningar samt elektriska kopplings- och styrdon.
Blåsbälgen har för närvarande flera hundra kunder, alla med mycket olika behov. Det är därför fråga om en mycket stor mängd moduler och komponenter som måste finnas tillgängligt för att löpande service och reparationer skall kunna ske. Det finns t ex över 40 olika typer av filter, många av dessa också i upp till 10 olika storlekar.
Blåsbälgen har under en längre tid haft svårigheter med underhåll av kundernas ventialtionsanläggningar. Främst gäller problemen reservdelshanteringen i samband med besök av reparatörer. Innan reparatören är på plats kan det inte fastställas vilka delar som kan komma att krävas eftersom ingen ordentlig dokumentation finns över varje kunds anläggning och dess beståndsdelar.
Ett ytterligare problem är tidsplaneringen av reparatörernas arbete. Eftersom de olika anläggningarna inte är dokumenterade ordentligt är det svårt att förutse tidsåtgången inför reparations- och underhållsarbete. Detta accentueras av att reparatörerna ofta får återkomma eftersom de inte har rätt reservdelar och underhållsmaterial med till platsen.
Blåsbälgen har
idag ett lager- och beställningssystem för ventilationskomponenter.
Systemet körs på en äldre UNIX-dator med anslutna terminaler.
Det finns för närvarande inga planer att byta ut systemet eftersom
det fungerar väl för sin uppgift, är mycket stabilt och anses
som lättarbetat av de anställda.
Systemet innehåller för varje komponent detaljerade specifikationer,
samt lageruppgifter. Varje komponent har ett nr av typ FH-06-13, vilket i exemplet
står för FläktHus nr 06, delkomponent nr 13. Om delkomponentnummer
är 00 avses hela modulen. FH-06-00 avser alltså hela fläkthuset.
I ett senare skede kan det
dock bli aktuellt att byta ut eller komplettera detta register så att
det kan kopplas ihop med det nya system som specidficeras nedan.
Förutom detta finns administrativa system av sedvanlig art. Dessa berörs
inte vidare i denna specifikation.
Med utgångspunkt i
problemen ovan finner vi att det viktigaste önskemålet är ett
system för dokumentation av alla kundernas ventilationsanläggningar
med utgångspunkt i vilka beståndsdelar det är uppbyggt av samt
tidsuppgifter för allt periodiskt utbytesarbete. Vi kallar detta anläggningregistret,
AR. Dessutom skall för varje kundanläggning finnas uppgifter om restid
från Blåbälgens lokaler till kunden. Varje kundanläggning
identfieras med ett anläggningsnummer.
Kopplat till detta vill vi också införa ett åtgärdsregister,
ÅR. En åtgärd är då som regel utbyte av en viss
komponent, allt från ett filter till en hel fläkt- eller spjällmodul.
För varje åtgärd skall anges: Tidsåtgång, erforderliga
delar och eventuella behövliga specialverktyg. Varje åtgärd
har en egen kod som sätts samman av komponentnummer och ett åtgärdstypnummer,
t ex 1 för byte 2 för renovering, 3 för rengöring, etc.
Tidsåtgången skall i ÅR kunna anges för flera olika svårighetsklasser, där dessa beror på förutsättningarna hos varje kund. I AR skall för varje ingående modul i varje anläggning sättas en svårighetsklass från 1 – 5. Bedömningen görs av reparatörerna.
Inför ett visst arbete skall man då kunna ange typ av åtgärd, t ex byte av spjällmodul. Från anreg fås då den exakta specifikationen av spjället samt den bedömda svårighetsklassen. Uppgifterna förs vidare till ÅR som då visar beräknad tidsåtgång och nödvändigt material. Ett arbete kan givetvis bestå av flera olika åtgärder. Varje arbete skall kunna identifieras genom ett eget nummer som skall innehålla anläggningsnummer och ett löpnummer.
Den tredje delen av systemet är ett tidsplaneringsregister, TR, där varje reparatörs tidsschema registreras. När ett kundbesök är aktuellt registreras för arbetet avsedd avresetid. Ur AR hämtas uppgifter om restid och ur ÅR förväntad arbetstid. I registret läggs då in när reparatören förväntas vara tillgänglig igen. När reparatören återkommer registreras denne som tillgänglig för nya arbeten.
Det skall gå att söka i TR efter lediga reparatörer och om någon sådan inte finns skall den som närmast kommer att bli ledig i stället visas.
Underhålls
av: eva@informatik.umu.se
URL: http://www.informatik.umu.se/~eva/metodkonstrukt/projekt.html
Senast ändrad: 2000-10-24