TDDD36. Projekttermin: Säkra mobila system

TDDD36 Projekttermin: Säkra mobila system Hösten 2010 1

Innehållsförteckning 1 Förord... 3 1.1 Examination... 3 2 Projektet... 5 2.1 Aktörer... 5 2.2 Krav... 6 3 Projektledning... 7 3.1 Projektmodell... 7 3.2 Inför projektet... 7 3.3 Anvisningar för projektplanen... 8 3.4 Redovisningar... 9 3.5 Litteratur... 10 4 Teknisk utformning... 11 4.1 Programutveckling... 11 4.2 Systemets utformning... 11 4.3 Explicita krav i projektet... 13 4.4 Handledning... 14 4.5 Redovisning... 14 4.6 Litteratur... 14 5 MTS... 17 5.1 Redovisning... 17 5.2 Litteratur... 17 6 Psykologi... 19 6.1 Redovisning... 20 6.2 Litteratur... 20 7 Etik... 21 7.1 Rapporten... 22 7.2 Kvalitet... 22 7.3 Explicita krav i projektet... 22 7.4 Redovisning... 22 7.5 Litteratur... 22 8 Avstämningar... 23 8.1 Kundmöte... 23 8.2 Avstämning 1: Krav och projektplan... 24 8.3 Avstämning 2: Krav, arkitektur, design... 25 8.4 Avstämning 3: Helheten... 26 9 Slutrapportering... 27 9.1 Den skriftliga rapporten... 27 9.2 Intern-PM... 27 9.3 Muntlig redovisning... 28 9.4 Demonstration av projektet... 28 A Scenariobeskrivningar... 29 B Python... 35 C Programmering med handdatorn... 36 D Installera utvecklingsomgivningen... 39 2

1 Förord Denna dokumentation ger en beskrivning av hur projektterminen är upplagd. Det övergripande målet är att få en insikt i hur ett projektarbete kan fungera, för att arbeta i projekt är en del av ingenjörens vardag. Under denna projekttermin kommer du att: - få kunskap och erfarenhet av en projektmodell, - få praktisk övning i projektplanering och uppföljning, - parallellt med projektet få kunskaper i olika ämnen, såsom mobila system, informationssäkerhet, systemprogramvara, etik och psykologi, och - få möjlighet att se teknik och teknikutveckling i ett helhetsperspektiv. Detta dokument är upplagt enligt följande: - Kapitel 2 introducerar bakgrunden till projektet, och vad som ska implementeras. - Kapitel 3 till 7 tar upp de olika delämnena i projektet, inklusive projektledning, etik, MTS, psykologi och den tekniska utformningen i projektet. Här finns även litteraturlistor. - Kapitel 8 och 9 beskriver avstämningarna under projektets gång och slutredovisningen av projektet. 1.1 Examination Terminen består av två delar: en kursdel och en projektdel. Kursdelen examineras i enlighet med kursplanen genom skriftliga tentamina, kontrollskrivning och seminarier. Projektdelen examineras genom periodvisa avstämningar och en slutredovisning. 3

2 Projektet Vid större olyckor och krissituationer kan kommunikationen mellan aktörer, såsom räddningstjänst, polis och militär, i krishanteringssystemet vara avgörande för hur framgångsrikt man hanterar situationen. I det här projektet kommer ni att utveckla ett system för kommunikation i samband med krishantering. Varje projektgrupp kommer att bygga ett separat system, anpassat till den aktör i krishanteringssystemet som gruppen representerar. Dessa separata system ska sedan kunna kommunicera med varandra, så att information som produceras i ett system även kan användas i de andra. 2.1 Aktörer För det här projektet använder vi en förenklad modell av krishanteringssystemet, där vi endast tar hänsyn till tre eller fyra grupper aktörer (beroende på hur många projektgrupper som finns). 2.1.1 Sjukvård Sjukvårdens främsta ansvar är att vårda skadade och sjuka. Uppdraget omfattar evakuering av sjuka, ambulanstransporter och vård. Man är beroende av att snabbt får information om var insatser behövs, och vilken sorts insatser det är frågan om. Det krävs också aktuell information om var egna och andras resurser finns så att man kan arbeta effektivt och snabbt kan rycka ut vid larm. Sjukvården utgör även en resurs för andra. Polis, räddningstjänst, och andra kan behöva ge akut medicinsk hjälp till nödställda, och sjukvården kan i sådana lägen agera rådgivare. Här utnyttjas ljud, bild och video för att ge de rådgivande experterna så bra information som möjligt. Dessutom har sjukvården information, såsom patientjournaler, som kan vara av stor vikt vid räddningsinsatser. Informationen i dessa är dock belagd med sekretess, vilket begränsar möjligheterna att sprida den, och därmed dess nytta i krissituationer. 2.1.2 Räddningstjänsten Räddningstjänstens uppdrag är att begränsa skador på människor, egendom och miljö i samband med olyckor eller fara för olyckor. Uppdraget innefattar mycket varierande uppgifter, såsom brandförsvar, att bygga vallar som skydd vid översvämning, att reparera kritisk infrastruktur, att röja efter storm eller översvämning, och mycket mer. Den information som räddningstjänsten behöver för att utföra sitt uppdrag är lika varierat som uppgifterna. Först och främst krävs information om var insatser behövs, och vilken typ av insats som krävs. Utöver detta ställer varje insats sina krav på information. För att arbeta effektivt och samordna med andra grupper krävs att räddningstjänsten kontinuerligt vet var deras egna resurser befinner sig och vad de gör. 2.1.3 Försvarsmakten Försvarsmaktens insatser kan vara oerhört varierande. Man arbetar i första hand som en resurs för andra organisationer, såsom räddningstjänsten och sjukvården. 5

Exempel på insatser som försvarsmakten kan göra är fördelning av drivmedel, utlåning av fordon, drift av reservkraftverk, uppbyggnad av tillfälliga telekommunikationssystem, eftersökning, evakuering, hembesök och transport av förnödenheter till befolkningen. Med ett så varierat uppdrag är försvarsmakten beroende av information om var deras insatser krävs, och är beroende av att kunna förmedla information om vilka resurser de kan tillhandahålla. I och med att man har tillgång till en stor flotta fordon av varierande slag är försvarsmakten särskilt väl skaffad att kartlägga skador på infrastruktur och miljö, framkomlighet med mera. I samband med större insatser som stöd för samhället kallar försvarsmakten även in hemvärnet. 2.1.4 Polis Polisens främsta ansvar är att upprätthålla ordningen i samhället, men man gör även mycket annat. Till exempel kan polisen göra hembesök hos utsatta, undsätta drabbade och kartlägga situationen på marken. Man ansvarar även för att söka efter saknade och är en viktig länk till allmänheten. I och med att polisens uppdrag är så varierat så ställs höga krav på kommunikation så att man vet var insatser behövs, och vilka resurser som finns tillgängliga. Vid behov kan polisen kalla in beredskapspoliser, personer som har andra yrken men frivilligt arbetar under Polisens ledning i krissituationer. Under 2010 kommer vi inte att ha någon projektgrupp med polisen som fokus. 2.2 Krav En viktig del i varje utvecklingsprojekt är att identifiera vilka krav som ska implementeras. I det här projektet finns följande källor för krav: - Scenariobeskrivningarna i det här dokumentet. - Explicita krav i det här dokumentet (under respektive ämnesområde). - Intervjuer med er kundrepresentant. - Saker ni hittar på själva. 6

3 Projektledning Projektarbetet bedrivs självständigt. Med projektarbete i termin 5 menar vi lösande av problem där: - arbetet utförs i grupp, - arbetet utförs självständigt, - arbetet kräver analys och tidsplan, och - arbetet kräver ansvar från gruppen och dess medlemmar. Basgruppsarbete förutsätter att alla gruppmedlemmar gör samma sak. I projektarbete delas problemet istället upp i delproblem som fördelas mellan medlemmarna så att problemet kan lösas snabbare. Projektarbete är alltså inte problembaserat lärande! I projektarbete är det nyttigt att skilja på problem och arbetssätt. Problemet är vad man jobbar med. Arbetssättet är hur man jobbar med problemet. För att arbetet ska fungera måste gruppen enas om arbetssättet innan man ger sig i kast med problemet. 3.1 Projektmodell A pig and a chicken are walking down a road. The chicken looks at the pig and says, Hey, why don't we open a restaurant? The pig looks back at the chicken and says, Good idea. What do you want to call it? The chicken thinks about it and says, Why don't we call it Ham and Eggs? I don't think so, says the pig, I d be committed, but you'd only be involved. I detta projekt förväntas grupperna för den initiala planeringen använda vattenfallsmetoden, och därefter tillämpa en process som kallas Scrum. Scrum är en iterativ inkrementell utvecklingsprocess som hör till familjen lättrörliga processer (engelska agile ). Scrum har sina rötter i arbete med att ta fram bättre processer för produktutveckling under 1980 och 1990-talen. Scrum publicerades första gången 1995 på OOPSLA-konferensen. Scrum är en iterativ processmodell med ett litet antal definierade roller och aktiviteter. De viktigaste rollerna är: scrummästaren (scrum master), som underhåller processen och agerar lagledare; produktägaren (product owner), som representerar kunder, användare och andra intressenter; och laget (team), som är utvecklarna. Processen bygger på så kallade sprints, som är relativt korta iterationer av processen. Inför varje sprint beslutar man vilka krav som ska implementeras under iterationen, och efter varje sprint demonstrerar man resultatet. En grundprincip är att kraven på ett system kan ändras (men under en sprint är kraven för den iterationen normalt låsta). I det här projektet kommer ni att arbeta med sprints som är två veckor långa. Varannan måndag (ungefär) ska ni hålla möten för att utvärdera föregående och planera kommande sprint. Under dessa möten får även kundrepresentanterna delta. 3.2 Inför projektet Inför projektet ska ni ta fram en projektplan. Den krävs för att komma överens om arbetsformerna, men till viss del även om problemet. Projektplanen inventerar tillgängliga resurser, innehåller övergripande planering om projektets genomförande och beskriver hur ni realiserar projektmodellen. 7

I ett traditionellt projekt, där man försöker planera så mycket som möjligt i förväg, så har projektplanen en större roll än den har här. Framförallt så kommer er projektplan inte att innehålla en detaljerad planering av uppgifterna i projektet, utan en översiktlig planering som identifierar när era iterationer är, aktiviteter som konkurrerar med projektet (till exempel tentor, schemalagda kurser), externt ställda krav (milstolpar, delrapporter och liknande). Planen blir en kalender för er, och ett underlag vid planeringen av varje enskild sprint. Projektplanen ska även: - tilldela roller till projektdeltagarna, - bestämma övergripande mål för arbetet, - inventera kunskaper och erfarenheter som kan komma till nytta, - fastslå arbetsrutiner för projektet, och - planera projektets utförande. Det är också mycket viktigt att gruppen bestämmer hur beslut ska fattas, hur missnöje inom gruppen ska tas upp samt vad som kommer att krävas av gruppens medlemmar. En del av dessa punkter ges av Scrum, men långt ifrån allt. Projektplanen är ett levande dokument som ska uppdateras kontinuerligt. Om ni, till exempel, ändrar hur ni tidsuppskattar uppgifter, ska projektplanen uppdateras. Om det tillkommer konkurrerande aktiviteter så ska de föras in. 3.3 Anvisningar för projektplanen Projektplanen ska innehålla följande: Projektets bakgrund, syfte och mål, avgränsningar, åtgärds-/resursplanering, tidplanering, projektorganisation, samt planering för information/förankring av projektet (Lööw 1999:57). 3.3.1 Bakgrund, syfte, mål Bakgrundsbeskrivningen sätter projektplanen i ett sammanhang och klargör vad som har föregått projektet. Det leder fram till syftet med projektet, dvs. skälet till att det genomförs. Syftet konkretiseras i termer av effektmål det resultat man vill uppnå på längre sikt. Projektplanen innehåller dessutom projektmål, som beskriver vad projektet ska åstadkomma, dvs. vad man ska leverera till beställaren/produktägaren. Ofta bryts detta ned i ett antal etappmål/delleveranser. När man tillämpar Scrum kan dessa utgöras av olika releaser. Gemensamt för olika slags mål är att man bör eftersträva att göra dem SMARTa, dvs. Specifika för det aktuella projektet, Mätbara för att möjliggöra kontroll av måluppfyllnad, Accepterade av samtliga berörda parter, Realistiska med hänsyn till projektets förutsättningar, och Tidssatta för att klargöra när man ska kontrollera måluppfyllnad. 3.3.2 Avgränsningar Vad projektet inte skall leverera. Avgränsningar klargörs för att undvika ogrundade förhoppningar hos projektets olika intressenter. 3.3.3 Krav Enligt IEEE (Institute of Electrical and Electronics Engineering) så är ett krav en funktionalitet som en användare behöver för att lösa ett problem / uppnå ett mål. 8

Krav är också villkor och restriktioner på ett system, en tjänst, produkt eller process. Oavsett vilken projektmodell som används, så utgör kraven bsen för den överenskommelse man har mellan beställare och projektgrupp. Först när man är överens om vilka krav som ska uppfyllas, så kan projektet startas. I projekt som drivs dynamiskt specificeras produktkraven successivt, i takt med att kunskap och erfarenhet inhämtas. 3.3.4 Åtgärds-/resursplanering För att möjliggöra planering av ett projekt är det viktigt att man bryter ned arbetet till mindre aktiviteter eller åtgärder. När man tillämpar Scrum utgör framtagningen av en product backlog en central del av åtgärdsplaneringen. Detta är en prioriterad listning över systemets önskvärda funktionalitet. Varje delelement i projektets backlog ( backlog item ) beskriver ett tänkt resultat från en sprint. En viktig utgångspunkt för framtagningen av projektets backlog är projektets resurser. Ställ frågan kan vi åstadkomma detta under en sprint?. Annars finns skäl att bryta ned arbetet ytterligare. Projektets resursåtgång planeras i en budget. För enkelhets skull beräknar vi endast projektteamets tidsinsats (mätt i arbetstimmar), som är den klart viktigaste resursen i den här typen av projekt. 3.3.5 Tidplanering Projektets tidplan beskriver när olika åtgärder/aktiviteter ska utföras (här handlar det alltså om kalendertid och inte arbetstid). Den presenteras företrädesvis i form av ett Gannt-schema (Lööw 1999:65). Tänk på att förutom själva utvecklingsarbetet (sprintar), även lägga in övergripande systemarkitektur/design samt aktiviteter i samband med projektavslut (integration, systemtest, dokumentation, projektuppföljning etc.). 3.3.6 Projektorganisation Projektorganisationen avser både rollfördelning internt i projektteamet och hur relationen till den övriga organisationen ser ut. Internt är det viktigt att definiera vem som får rollen som projektledare/scrummaster, hur rollfördelningen ser ut i övrigt samt vilket ansvar/vilka befogenheter som följer med respektive roll. Det är även viktigt att klargöra vilka spelregler man har för samarbetet i gruppen (Lööw 1999:47). I relationen till den övriga organisationen är framför kopplingar till produktägare och till andra projekt relevant. 3.3.7 Information/förankring Här beskrivs vilka rutiner projektet har för informationshantering och kommunikation. 3.4 Redovisningar Projektplanen (med störst fokus på syfte, mål, krav, risk och grov tidsplanering) ska redovisas i avstämning 1, där planen diskuteras och ett revideringsförslag tas fram. Varje vecka ska gruppen rapportera hur mycket tid (räknat i timmar) som varje person i gruppen har lagt ned på projektet, samt om gruppen ser några risker eller problem i projektet, och hur dessa ska hanteras. Denna rapport skickas med e-post till terminsansvarig senast måndagen efter veckan som rapporten gäller. 9

Under projektets gång är det viktigt att arbetet följs upp och utvärderas. Planen behöver revideras och nya detaljplaner måste tas fram. Detta arbete följs upp under avstämning 3 och slutredovisningen. Vid slutredovisningen redovisas projektets utfall i förhållande till ursprungliga planeringen avseende syfte, mål, krav, risk, grov tidsplanering och budget, samt teamets generella lärdomar kring projektplanering, projektorganisation etc. (se Lööw 1999: 101-102). 3.5 Litteratur - Ken Schwaber. SCRUM Development Process. In Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages, and Applications (OOPSLA 1995). SIGPLAN Notices 30(10). October 1995. Available on-line: http://jeffsutherland.com/oopsla/schwapub.pdf - Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice-Hall. 2002. - Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004. - Monica Lööw. Att leda och arbeta i projekt, Liber Ekonomi. 1999. 10

4 Teknisk utformning 4.1 Programutveckling 4.1.1 Agile software development Scrum är en så kallad lättrörlig process från engelskans agile. Den främsta egenskapen hos en lättrörlig process är att den kan hantera kontinuerligt föränderliga krav, och att man under utvecklingens gång ofta har ett fungerande system. I lättrörliga processer tenderar ett systems utformning att växa fram organiskt varefter enskilda funktionella krav implementeras. En nackdel är att systemövergripande aspekter som arkitektur och design lätt blir eftersatta. Under projektets gång kommer ni att förväntas införliva nya krav varefter ni upptäcker dem. Det är även möjligt att externa krav tillkommer under projektets gång. 4.1.2 Arkitektur och design Arkitektur och design är intimt sammankopplade. Arkitektur är strukturer av strukturer, ramverk som fastställer systemets utformning på hög nivå. Här är en definition ur litteraturen: The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. -- ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems Se http://www.sei.cmu.edu/architecture/definitions.html för fler definitioner av begreppet. Under projektet ska ni definiera systemets arkitektur. Genom att definiera arkitekturen skapar ni en ram inom vilken resten av utvecklingen sker. I projekt där utformningen växer fram successivt gör arkitekturen att resultatet ändå har en förutsägbar struktur och ett förutsägbart beteende. Design handlar om detaljerade beslut hur olika delar av arkitekturen ska realiseras. I en lättrörlig process tenderar man fatta sådana beslut successivt, utan någon övergripande plan. Här kommer utvecklarens erfarenhet in: en utvecklare med omfattande erfarenhet fattar bättre och mer konsekventa designbeslut än en oerfaren utvecklare. För att underlätta designbesluten och för att underlätta kommunikation om design finns ett begrepp som heter designmönster ( design pattern på engelska). Ett designmönster är en välbeprövad lösning på ett generellt designproblem. Varje mönster är väldokumenterat, inklusive dess konsekvenser för systemet i stort, fördelar och nackdelar. Under projektet räknar vi med att ni använder er av designmönster i så stor utsträckning som möjligt. 4.2 Systemets utformning Varje grupp kan fritt utforma sitt system. Dock ställs vissa tekniska krav på plattformen som påverkar vilka utformningar som är möjliga: - Systemet innehåller en mobil klient i form av en Nokia N810 handdator som kommunicerar trådlöst med övriga delar av systemet. 11

- I systemet finns en server som samordnar alla klienter och som ansvarar för att leverera information till dem. Denna server ska ha hög tillgänglighet. - De olika gruppernas system ska kommunicera, och den kommunikationen ska vara säker och filtrerad, så att enbart information som ska levereras kan levereras. Den övergripande arkitekturen som är mest trolig visas i figur 1. deployment Öv ergripande arkitekt... Aktör 1 «mobile» Klient «wireless,secure» «high availability» Server Annan tjänst Annan tjänst «filtered,secure» Aktör 2 «mobile» Klient «wireless,secure» «high availability» Server Annan tjänst Annan tjänst Figur 1. Övergripande systemarkitektur 4.2.1 Klient Klienten är en eller flera komponenter på den mobila enheten. Klienten kan programmeras i Python, C eller C++ (eller en blandning). Plattformen är Nokia N810 med Maemo 4. N810 är en handhållen dator baserat på TI OMAP 2420-processorn. Den har 128MB RAM och 256 MB Flash för primärminnet, och sekundärminne om 1GB (kan expanderas med MiniSD-kort). Den kan kommunicera med USB, WiFi, Bluetooth. Det finns en VGA-kamera, mikrofon, högtalare, GPS-mottagare och tangentbord. Skärmen är 4.13 tum med en upplösning på 800x480 bildpunkter, och har 16-bitsfärg. Maemo 4 är en miljö som baseras på Debian/Gnu Linux och GTK. Nokia har tillfört en del programvara, drivrutiner och bibliotek som underlättar utveckling av tillämpningar som integrerar väl med plattformen. Maemo programmeras oftast i C, C++ eller Python. Plattformen utnyttjar DBus för kommunikation mellan olika program. Varje grupp får välja vilket programmeringsspråk och vilken arkitektur man väljer för klienten. Vi rekommenderar en lösning där olika funktioner realiseras av olika pro- 12

gram som kommunicerar med exempelvis DBus. Arkitekturen för klienten kommer att ha stor inverkan på hur projektet fortlöper. Klienten ska kommunicera trådlöst med servern. Detta kan ske genom infrastrukturnät eller ad-hoc-nätverk. Det står varje grupp fritt att implementera detta som man tycker passar bäst. Kommunikationen ska vara säkrad från avlyssning och manipulering. 4.2.2 Server Servern är en komponent i det fasta nätet, som kommunicerar trådlöst med klienterna. Huvuduppgiften för servern är att koordinera klienterna, tillhandahålla information som de behöver, och ta emot information som de producerar. Servern ska ha hög tillgänglighet, vilket innebär att tjänsten ska fortsätta fungera även om det uppstår en hårdvaru- eller programvarukrasch. Under projektet tillhandahåller vi en Linux-miljö och en Solaris-miljö. Vilken som kan användas för servern. De olika gruppernas system ska kunna kommunicera. Detta sker (om inte grupperna kommer överens om något annat) över Internet. Här är det viktigt att enbart information som får överföras (baserat på juridiska och etiska hänsynstaganden) överförs, och att kanalen är skyddad på lämpligt sätt. 4.2.3 Andra tjänster Flera av scenarierna varifrån krav ska hämtas beskriver information som finns i källor som befolkningsregister eller patientjournalsystem. Dessa är andra tjänster i nätet, som tillhandahåller information som klienterna (eller andra aktörer) vill använda. Gruppen ska implementera minst en sådan enkel tjänst för att demonstrera att kraven relaterade till andra tjänster är uppfyllda. 4.3 Explicita krav i projektet 4.3.1 Informationssäkerhet Ett krishanteringssystem ställer höga krav på informationssäkerhet. I det här projektet ska ni minst säkerställa följande: - Servern autentiserar varje meddelande den tar emot från de mobila klienterna, för att garantera att meddelandet är äkta och kommer från en auktoriserad användare. - Data som sänds till andra aktörer filtreras, så att endast data som får sändas verkligen sänds. - Data som skickas mellan klient och server, mellan klienter, och mellan aktörer inte går att avlyssna eller manipulera (utan att det upptäcks). Utöver detta kan gruppen själva lägga till krav på säkerhet. En riskanalys ska genomföras för att ge vägledning kring vilken nivå av säkerhet, och vilket ytterligare skydd som behövs. 4.3.2 Mobila system Ett mobilt system är inte alltid anslutet till sitt nätverk. I projektet ska ni minst säkerställa att: 13

- Tillämpningarna på klienten fungerar (om än med begränsad funktion) oavsett om klienten har tillgång till nätverk eller inte. - Återuppkoppling till nätet ska ske utan att användaren behöver agera. - Kommunikationen anpassas till tillgänglig nätverkskapacitet. - Inga viktiga meddelanden förloras. 4.3.3 Systemprogramvara - Systemprogramvara i varje klient ska innefatta en QoS manager vars uppgift är att anpassa kommunikationen efter tillgänglig batterinivå. Systemets beteende i form av vilka typer av meddelanden som kommer att skickas, ska vara predikterbar givet en viss batterinivå. - Systemprogramvara på serversidan ska se till att tjänsten är tillgänglig även om programvaru- eller hårdvarukrasch uppstår. Vid replikering skall konsistens i serverns tillstånd upprätthållas. Den feltoleranta lösningen ska inte vara långsammare än motsvarande icke-feltoleranta lösning med en faktor 100%. 4.4 Handledning Till er hjälp finns ett antal experter som ni kan konsultera under projektets gång: Mikael Asplund Shanai Ardi Anna Vapen Systemprogramvara, QoS Risk- och hotanalys, kravanalys, säkerhet Autentisering, identifiering, Scrum Experterna är tillgängliga för konsultation endast enligt överenskommelse. Maila den person ni vill träffa för att boka en tid. 4.5 Redovisning Redovisning sker vid avstämningarna och vid slutredovisningen. Se avsnitt 8 och 9 för detaljer. Ni ska dessutom när som helst kunna visa upp er product backlog. 4.6 Litteratur Litteraturen är mycket viktig. Kursdelarna (säkerhet, systemprogramvara, mobila system) examineras till största delen ur litteraturen; se läsanvisningarna på kurshemsidan för detaljer. 4.6.1 Arkitektur och design Ni förväntas lära er om krav, arkitektur och design på egen hand. Detta är nödvändigt för att kunna utforma systemet på ett bra sätt. - Len Bass, Paul Clements and Rick Kazman. Software Architecture in Practice, Second Edition. Addison Wesley. 2003. - David Garland and Mary Shaw. An Introduction to Software Architecture. Technical Report CMU/SEI-94-TR-021. Software Engineering Institute, Carnegie Mellon University. 1994. On-line: http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr21.94.pdf - Amnon Eden and Rick Kazman. Architecture, Design, Implementation. In Proceedings of the 25 th International Conference on Software Engineering. 14

IEEE Computer Society.2003. On-line: http://dx.doi.org/10.1109/icse.2003.1201196 - Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. 1995. - Pattern Catalog. On-line: http://hillside.net/patterns/onlinepatterncatalog.htm För designmönster erbjuder Wikipedia-artikeln Design Pattern (computer science) ett stort antal användbara referenser och länkar utöver de som räknas upp här. 4.6.2 Informationssäkerhet Computer Security: Art and Science är huvudsaklig kurslitteratur för säkerhetsdelen. Se kurshemsidan för läsanvisningar inför tentamen. Övriga delar i boken, samt annat material i listan här kan vara användbara i projektet. - Matt Bishop. Computer Security: Art and Science. Addison-Wesley. 2002. - Paco Hope, Steven Lavenhar, Gunnar Peterson. Architectural Risk Analysis. Cigital. 2005. On-line: https://buildsecurityin.us-cert.gov/daisy/bsi/10- BSI.html - Gary McGraw. Risk Management Framework. Cigital. 2005. On-line: https://buildsecurityin.us-cert.gov/daisy/bsi/250-bsi.html - Mick Bauer. Practical Threat Analysis and Risk Management. Linux Journal. 2002. On-line: http://www.linuxjournal.com/article/5567 - Alfred J. Menezes, Paul C. van Oorshot and Scott A. Vanstone. Handbook of Applied Cryptography. CRC Press. 2006. On-line: http://www.cacr.math.uwaterloo.ca/hac/. 4.6.3 Mobila system Ad Hoc Wireless Networks: Architectures and Protocols är kurslitteratur för mobila system. Se kurshemsidan för läsanvisningar. - C. Siva Ram Murthy, B. S. Manoj. Ad Hoc Wireless Networks: Architectures and Protocols. Prentice-Hall. 2004. 4.6.4 Systemprogramvara Operating System Concepts och Distributed Systems: Concepts and Design är kurslitteratur för systemprogramvara. Se kurshemsidan för läsanvisningar. Dessa och övrigt material kan vara användbara i projektet. - Avi Silberschatz, Petre Baer Galvin, and Greg Gagne. Operating System Concepts, 7 th Edition. John Wiley & Sons. 2004. Kapitel 4, 6, 7, och 8. - George Couloutis, Jean Dollimore, and Tim Kindberg. Distributed Systems: Concepts and Design, 4 th Edition. Addison-Wesley. 2005. Kapitel 2 och 15. - Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing, IEEE Transactions on Dependable and Secure Computing, 1(1):11-33, 2004. Online: http://dx.doi.org/10.1109/tdsc.2004.2 15

- Mohamed El-Gendy, Abhijit Bose and Kang Shin. Evolution of the Internet QoS and Support for Soft Real-Time Applications. Proceedings of the IEEE, Vol 91, No. 7, Juli 2003. On-line: http://dx.doi.org/10.1109/jproc.2003.814615 16

5 MTS Kursmomentet Människa, teknik och samhälle består av två delar, dels en del som behandlar samhällsvetenskaplig teori kring risk, dels ett kommunikationsmoment. Studenterna ska kunna redogöra för olika samhällsvetenskapliga teorier kring risk och då särskilt i relation till teknik och teknisk utveckling. De ska också kunna reflektera kring frågor som vad som konstituerar en risk, hur olyckor kan tolkas och hur säkerhet kan uppnås. Mer specifikt kan kursinnehållet beskrivas med följande frågor: - Hur konstrueras, förhandlas och hanteras risk av olika aktörer i deras vardag? - Hur och varför kommer aktörers tolkningar av risk och osäkerhet att betraktas som fakta? Hur kan vi förstå denna process och resultatet av den? - Hur skapar t.ex. operatörer, räddningsledare, räddningspersonal och frivilliga mening och säkerhet i olika typer av organisationer och tekniska system? Dessa kunskaper ska studenterna sedan kunna införliva i sina egna projekt. Målen med delmomentet Kommunikation är att studenterna ska kunna kommunicera enligt de förutsättningar som ges i inom projektet. Detta sker genom att studenterna både skriftligt och muntligt presenterar sitt projekt vid avstämning 2 samt vid slutredovisningen. I samband med slutredovisningen ska projektgruppen även ansvara för en opponering på en annan grupps presentationer (både den muntliga och skriftliga). 5.1 Redovisning Momentet som behandlar människa, teknik och samhälle kommer att examineras med en hemtentamen och ett diskussionsseminarium. Hemtentamen och diskussionsseminariet är gemensamma med etik-momentet. Dessutom redovisas delar vid avstämningarna och vid slutredovisningarna. Se avsnitt 8 och 9 för detaljer. Kommunikationsmomentet examineras i samband med slutredovisningen 5.2 Litteratur Följande litteratur ska vara läst tillhemtentamen och diskussionsseminariet: - Boel Berner. Regeln i undantaget. Om olyckor, kunskap och tekniska system. On-line: http://www.tema.liu.se/content/1/c6/05/86/32/regeln%20i%20undanta GET.pdf - Gregory A. Bigley and Karlene H. Roberts. The Incident Command System: High-Reliability Organizing for Complex and Volatile Task Environments. Academy of Management Journal. 44(6):1281-1299, 2001. - Lionel Dyck. High Reliability Organizations (HRO) in Practice. Technical Support. Januari 2007. - Karl E. Weick. The Collapse of Sensemaking in Organizations: The Mann Gulch Disaster. Administrative Science Quarterly, 38(4):628-652, 1993. - Ev. ytterligare några aktuella artiklar. 17

6 Psykologi När en projektgrupp arbetar tillsammans för att nå gemensamma mål spelar gruppens struktur, arbetsprocesser och ledarskap viktig roll. En grupp med välfungerande struktur, arbetsprocesser och ledarskap har bättre förutsättningar för att nå de gemensamma målen. Med gruppstruktur avses inom gruppsykologin exempelvis gruppnormer och roller och med arbetsprocesser avses hur gruppens strukturer samverkar. Vidare innefattar processer hur en grupp utvecklas över tid, från gruppens första möte tills det att gruppen har slutfört sin uppgift. Målen med kursen är att studenterna ska förstå och kunna använda sig av grundläggande gruppsykologiska begrepp såsom struktur, process och utveckling, samt kunna beskriva och förklara ledarskapets betydelse för individers och gruppers effektivitet. Ledarskap i en krissituation samt aspekter av beslutsprocesser och ledarskap som blir aktuella för de individer som eventuellt kommer att använda sig av ett mobilt krishanteringssystem skall också kunna beskrivas. Kursen kommer att examineras med en hemtentamen under hösten. För att få skriva hemtentan krävs att man har närvarat vid kursens seminarium. För att synliggöra projektgruppens struktur, inre arbetsprocesser och utveckling under terminen ska varje projektgrupp föra en egen gruppdagbok. Detta arbete kan liknas vid en loggbok över gruppens inre liv och arbete, och bör fokusera på arbetsrelaterade processer, även hindrande sådana processer. Arbetet bör bygga på kontinuerliga observationer och noteringar så att man kan följa kontinuiteten i gruppens arbete och utveckling (helst minst en gång per vecka). Uppgiftens syfte är dels att ge träning till observation av och reflektion över grupprocesser i en liten arbetsgrupp, med de betingelser som gäller då man samtidigt sköter de uppgifter som förekommer under projektterminen, dels en fördjupningsuppgift. Gruppdagboken kan ses som ett sätt att beskriva och reflektera över de händelser av uppgiftskaraktär som förekommer och hur de kommer att påverka den projektgrupp man tillhör. Dokumentationen bör vara deskriptiv och utmärkas av en icke värderande ansats. Den bör ha både ett individ- och ett grupperspektiv, men med klar tyngdpunkt på grupperspektivet. En viktig fokusering när det gäller gruppens utveckling är att se till balansen mellan uppgifts- och relationsorientering. Utöver detta har gruppen själv frihet att välja några områden av arbetet i gruppen som granskas och beskrivs. Försök att hålla er fritt och sakligt kritiskt. Sök gärna alternativa mönster för gruppens utveckling, som att inte bara slentrianmässigt utgå från exempelvis Tuckman och Wheelans utvecklingsmodell. Gruppdagboken ska bearbetas under de avslutande veckorna på kursen. Ett första utkast av en skriftlig sammanställning av gruppens iakttagelser som gjorts i gruppen över tid ska lämnas till gruppsykologiläraren senast till avstämning 4 (se nedan). Gruppen kommer att få återkoppling på detta utkast och ska därefter bearbeta en slutlig skriftlig version som ska ingå i slutrapporten. Resultatet av arbetet med gruppdagboken presenteras vid ett redovisningstillfälle i samband med slutredovisningen. Studenterna kommer även att genom egen erfarenhet av arbete i projektgrupp träna sig i att avtala med externa konsulter om olika former av professionellt stöd för utveckling av den egna gruppens förmåga att underhand lösa sina interna frågor och problem. 19

6.1 Redovisning Psykologimomentet examineras dels vid ett särskilt seminarium och dels vid avstämningarna och slutredovisningen. Se avsnitt 8 och 9 för detaljer om dessa. Ett första preliminärt utkast av gruppdagbokens fokus (strukturer och processer) ska presenteras vid avstämning 1. Dessutom ska en tidsplan för gruppdagboken upprättas. Till avstämning 3 ska ett utkast till den slutliga analysen av gruppdagboken vara klar och skickas till läraren. Den skrivna sammanställningen ska ha en inledning, där sammanhanget till gruppdagboken tas upp och ett tydligt syfte ska formuleras. Vidare bör ett avsnitt beskriva de metoder som har använts, hur många observationer som ligger till grund för rapporten samt en beskrivning av arbetsgrupp såsom hur många arbetade i grupper, könsfördelning, ålder och erfarenheter. Sammanfattningsvis bör sammanställningen innehålla följande punkter: - Problemformulering. - Metodbeskrivning. - Resultat av observationerna. - Slutsatser, som bygger på gruppens observationer kopplat till de gruppsykologiska teorier som behandlas i kursen. Vid examination av gruppdagboksrapporten ska samtliga gruppmedlemmar kunna redogöra för de olika punkterna och en viss grad av kreativitet en fördel vid den muntliga presentationen. 6.2 Litteratur - Donelson R. Forsyth. Group Dynamics (4 th ed). Thomson Learning. 2006. - Lars Fredholm och Anna-Lena Göransson, (red.). Ledning av räddningsinsatser i det komplexa samhället. Räddningsverket. 2006. - Susan Wheelan. Group Processes: A Developmental Perspective (2 nd ed.). Allyn and Bacon. 2005. 20

7 Etik Den tekniska utvecklingen går snabbt framåt och det dröjer innan ett adekvat juridiskt ramverket utvecklas. Ny teknik kan innebära risker som på förhand är svårt att avgöra. Artificiell intelligens och genteknik (biotekniken) är exempel på områden som ger upphov till en rad frågor av etisk karaktär och där teknikens implikationer inte är uppenbara för oss. Kan en maskin tillskrivas moraliskt ansvar och i så fall på vilka grunder? På vilket sätt, om alls, bör vi med genteknik manipulera det mänskliga genomet? Eftersom ny teknik har en starkt samhällspåverkande potential och samtidigt tenderar att omges av ett policy vakuum blir etisk reflektion över teknikens implikationer central. Teknik- och systemutvecklare förväntas traditionellt att utveckla teknik som uppfyller effektivitets-, säkerhets- och användbarhetskrav inom vissa ekonomiska ramar. Eftersom ingenjören besitter stora möjligheter att påverka samhälle, människa och miljö kan hon/han sägas ha ett ansvar för att utveckla socialt och etiskt hållbar teknik. Med hjälp av etisk analys kan ingenjören identifiera hållbara lösningar på teknikrelaterade problem och även, i viss mån, överbrygga den juridiska eftersläpningen. Det här momentet syftar till att ge tankredeskap för att diskutera teknikens etiska aspekter och ingenjörens roll i samhället. Efter detta moment ska studenten ha kunskap om de vanligaste förekommande moralfilosofiska teorierna och kunna tillämpa dem inom det egna projektet. Etisk analys handlar om att på ett systematiskt sätt, diskutera vad som är gott och rätt för människor, samhälle och miljö liksom varför. Normativ etisk teori kan ge vägledning i hur vi bör fatta beslut och agera. Etisk teori kan hjälpa civilingenjören och tekniketikern att analysera problem och dilemman orsakade av, eller som uppstår i samband med teknikutveckling och/eller teknikanvändning. Etisk analys inkluderar allmänetiska frågor kring teknik, teknologi och teknikutveckling, som till exempel: - Vad är ingenjörens ansvar? - Vad är god teknik? - Vad är god teknikutveckling? - Vad innebär yrkesetik för ingenjörer? - Var går gränsen för moraliskt aktörskap? Men det handlar också ofta om att analysera partikulära teknikrelaterade fall, som t.ex. huruvida ett visst krishanteringssystem är önskvärt. Frågor om risk och säkerhet har etisk karaktär. Vilka risker är dataöverföring mellan klient - server, klient klient aktör behäftade med? Vilka säkerhetskrav nivå bör ställas på ett krishanteringssystem utifrån ett etiskt perspektiv? Eftersom ett mobilt krishanteringssystem har potential att påverka många människor i en sårbar situation är viktigt att göra en explicit etisk bedömning av projektet. Personliga integritet och valfrihet är etiska aspekter som bör beaktas vid systemets utformande. Den etiska analysen ska presentera i projektets slutrapport. 21

7.1 Rapporten Rapporten ska inkludera en identifikation och beskrivning av de risker som systemet ni utvecklar kan ge upphov till. Till denna uppgift hör att motivera varför de identifierade riskerna kan utgöra ett moraliskt problem. Vidare ska följande punkter ingå i rapporten: - En etisk analys av de risker som har identifierats. - En redogörelse för på vilket sätt moraliska och etiska hänsynstaganden har påverkat utformningen av systemet. 7.2 Kvalitet Inom etikmoment innebär kvalitet ett kritiskt (i betydelsen analyserande) etiskt förhållningssätt till teknik och teknologisk utveckling samt förmåga att tillämpa etisk analys. 7.3 Explicita krav i projektet Etikrapporten ska vara en litteraturstudie och en systematisk bearbetning av skriftliga källor. För uppgiften relevanta texter och teori ska presenteras och tolkas i relation till den konkreta uppgift som ska lösas. Rapporten ska presentera och analysera de etiska problem som identifieras i samband med projektet. 7.4 Redovisning Inför avstämning 1 skall ett utkast levereras som identifierar de risker som kan uppstå i samband med systemet. Motivera varför de identifierade riskerna kan utgöra ett etiskt problem. Utkastet ska skickas in till för momentet ansvarig lärare inför avstämning 1. Vid avstämning 3 ska en strukturerad och utförlig etisk analys av de identifierade riskerna presenteras. 7.5 Litteratur Litteratur som examineras: - Sven Ove Hansson. Teknik och etik. Kompendiet hämtas från: http://www.infra.kth.se/~soh/tekniketik.pdf - Helen Nissenbaum. "Privacy as contextual integrity". Washington Law Review, 2004. Artikeln hämtas från: http://crypto.stanford.edu/portia/papers/revnissenbaumdtp31.pdf - Philip Brey. Disclosive Computer Ethics. Computers and Society, Vol. 30. Issue 4. Pp. 10-16. 2000. Etiska koder för ingenjörer: - Association for Computing Machinery and IEEE Computer Society. Software Engineering Code of Ethics and Professional Practice. Version 5.2. On-line: http://www.acm.org/about/se-code 22

8 Avstämningar Projektet innehåller tre avstämningar. Syftet med avstämningarna är dels att följa upp arbetet och dels ett tillfälle för handledning. Avstämningarna kan ta olika form: - Presentationer ska vara ordentligt förberedda och professionellt upplagda. Deltagarna ska vara propert klädda och uppföra sig korrekt. Projektor finns, men deltagarna ansvarar själva för övrig teknisk utrustning. - Rapporteringar är informella presentationer inför en mindre grupp. - Diskussioner är en interaktiv dialog mellan studenter och handledare/lärare. - Opposition innebär att en grupp kritiskt granskar och kommenterar på en annan grupps arbete. Granskningen sker på skriftliga dokument som laddas upp i förväg till kursplatsen. Syftet med oppositionen är att öva på ett kritiskt förhållningssätt till teknisk utformning, och att hjälpa varandra komma fram till bättre lösningar. Grupp 1 opponerar på grupp 2, grupp 2 på grupp 3 och grupp 3 på grupp 1. Se schemat för lokalanvisningar. Skriftliga rapporter ska levereras via kursplatsen till lärarlaget. Varje grupp har en egen mapp där de kan ladda upp sina rapporter. Till varje avstämning kan även finnas skriftliga redovisningar. Det är material som enbart redovisas skriftligt, och på vilket ni får skriftliga kommentarer från respektive lärare (alt. Kallas till särskilt möte). 8.1 Kundmöte Datum: 6 september 2010 Syfte: Deltagare: Form: Förberedelser: Kundmötet är ett första tillfälle för grupperna att träffa sina respektive kundrepresentanter för att få svar på frågor och för att få ett tillfälle att diskutera uppgiften. Alla i projektgruppen Kundrepresentanter Diskussion om projektuppgiften. Läs igenom projekthandboken, skapa en initial uppfattning om projektuppgiften och formulera frågor att diskutera. Kundmötet är gruppens första tillfälle att koncentrerat få svar på frågor om projektet. Det är därför viktigt att i förväg formulera frågor eller diskussionspunkter för mötet, och det är gruppens ansvar att driva mötet. Efter kundmötet kommer ni att ha tid att kontakta representanter för respektive aktör. Dessa kan ge er en bild av hur aktörerna arbetar idag, men är inte er främsta kravställare. 23

8.2 Avstämning 1: Krav och projektplan Datum: 13 september 2010 Syfte: Deltagare: Form: Förberedelser: Genomgång av kraven som har identifierats under projektets inledningsfas. Alla i projektgruppen Kundrepresentanter Lärare: projektledning, säkerhet, systemprogramvara, mobila system Rapportering av, och diskussion om, kraven. Ladda upp en skriftlig rapport med kravbeskrivningar, projektplan, samt utkast och tidsplan för gruppdagboken till kursplatsen senast klockan 23:59 den 11 september. Schema: Tid Grupp 8.2.1 Anvisningar 13:15-14:00 Sjukvård 14:15-15:00 Försvarsmakt 15:15-16:00 Räddningstjänst Skapa en förteckning över krav (användarkrav, organisationskrav, tekniska krav) på systemet. De tekniska kraven skall vara uttryckta på ett bra sätt, vara lagom stora och testbara/mätbara. Kraven ska vara motiverade av användar/organisationskrav, och det ska gå att spåra dem tillbaks till dessa. Kraven behöver inte vara realistiska för det här projektet att välja ut genomförbara krav är en fråga om prioriteringar i senare skede. Vid rapporteringen ska kraven presenteras tillsammans med deras motiveringar och planer/idéer för hur de ska testas/mätas. Den skriftliga rapporten som ska laddas upp till kursplatsen ska vara utformad i första hand som stöd för senare arbete i projektet det kan m.a.o. vara början på en product backlog eller liknande. Ett första preliminärt utkast av gruppdagbokens fokus (strukturer och processer) ska rapporteras och diskuteras vid denna avstämning. Dessutom ska en tidsplan för gruppdagboken upprättas. Et utkast som identifierar de risker som kan uppstå i sambandet skal laddas upp till kursplatsen inför avstämningen. Utkastet ska motivera varför de identifierade riskerna kan utgöra etiska problem. Slutligen ska ni lämna in en projektplanering. Den ska innehålla följande: projektets bakgrund, syfte och mål, avgränsningar, åtgärds-/resursplanering, tidplanering, projektorganisation, samt planering för information/förankring av projektet. Av projektplanen ska alltså framgå vilka resurser ni har till ert förfogande och hur ni tänker nyttja dem. Det ska finnas en övergripande tidsplanering som tar hänsyn till redan schemalagda aktiviteter. Projektplanen ska dessutom innehålla lämplig definition och dokumentation av arbetssätt, roller, med mera. Redovisa de principer ni använde och de övervägande ni gjorde när ni utarbetade er projektplan och beslöt er för en viss organisation och ett visst arbetssätt. Under diskussion tillsammans med experter är må- 24

let att oklarheter ska upptäckas och olika synsätt belysas så att en reviderad och förbättrad planering kan göras. Experten ger klartecken om projektplanen är godkänd. 8.3 Avstämning 2: Krav, arkitektur, design Datum: 5 oktober 2010 Syfte: Deltagare: Form: Förberedelser: Uppföljning av krav (nya och gamla), genomgång av systemarkitektur och design, bakgrundsanalys. Alla i projektgruppen Kundrepresentanter Lärare: säkerhet, systemprogramvara, mobila system, MTS Rapportering av, och diskussion om nya krav. Rapportering av, och diskussion om bakgrundsanalys, systemarkitektur och design, inklusive presentation av säkerhets- och felanalyser. Ladda upp skriftligt underlag till alla punkter till kursplatsen senast klockan 23:59 den 3 september. Schema: Tid Grupp 1 8.3.1 Anvisningar 8:15-9:00 Försvarsmakt 9:15-10:00 Räddningstjänst 10:15-11:00 Sjukvård Komplettera förteckningen över krav med icke-funktionella krav (säkerhet, prestanda, tillförlitlighet, användbarhet, mm), samt revidera befintliga krav. Kraven ska vara motiverade av användar- och/eller organisationskrav och vara vidare underbyggda av lämpliga analyser: för säkerhet och tillförlitlighet innebär det till exempel analys av risker och potentiella fel. Kraven ska vara realistiska (eller åtminstone gå att anpassa så de blir realistiska) och ska vara testbara. Vid den här avstämningen ska ni redovisa en bakgrundsanalys av respektive aktör (den bör ha tillkommit tidigare i projektet eftersom den är en viktig del i att identifiera organisations- och användarkrav). Bakgrundsanalysen ska innehålla organisationens arbetsuppgifter, organisationsstruktur, resurser och restriktioner, samarbetspartners m.m. Beskriv systemarkitektur och design med t.ex. UML. Arkitekturen ska stödja kraven (funktionella såväl som icke-funktionella), och alla beslut om arkitektur bör kunna spåras till dokumenterade krav. I det här skedet av projektet är det troligt att designen fortfarande är skissartad, men arkitekturen bör vara relativt mogen den ger form till systemet medan det utvecklas. 25

8.4 Avstämning 3: Helheten Datum: 16 november 2010 Syfte: Deltagare: Form: Förberedelser: Uppföljning av projektets resultat hittills. Alla i projektgruppen. Lärare: psykologi, systemprogramvara, säkerhet, mobila system Presentation av uppdaterade risk/felanalyser samt reviderade krav. Redovisning och diskussion av reviderad arkitektur, design, implementation. Redovisning och diskussion kring gruppdagboken. Presentation av etisk analys. Ladda upp skriftligt underlag på alla delar till kursplatsen senast klockan 23:59 den 14 november. Schema: Tid Grupp 1 8.4.1 Anvisningar 8:15-9:15 Räddningstjänst 9:30-10:30 Sjukvård 10:45-11:45 Försvarsmakt Under projektets gång förväntas ni hålla risk/felanalyser kontinuerligt uppdaterade, och även revidera krav vid behov. Vid den här avstämningen ska ni helt enkelt redovisa aktuella (reviderade) versioner av dessa. Detsamma gäller systemarkitektur och systemdesign; aktuella versioner av dessa ska också redovisas. Slutligen ska ni redovisa aktuell status på själva implementationen. Eftersom ni arbetar med Scrum bör det finnas ett fungerande system att visa upp (även om det har begränsningar). Vid denna avstämning ska en strukturerad och utförlig etisk analys av de identifierade riskerna presenteras. Till avstämningen ska även ett utkast till den slutliga analysen av gruppdagboken upprättas och laddas upp till kursplatsen. 26

9 Slutrapportering Slutredovisning av projektet ska bestå av en skriftlig rapport samt muntliga presentationer och en demonstration. Dessutom ska ett intern-pm som analyserar och utvärderar den egna arbetsinsatsen skrivas. Den muntliga redovisningen sker inför lärarlaget och alla kursdeltagare. 9.1 Den skriftliga rapporten Den skriftliga slutrapporten av projektet ska innehålla en sammanfattning på en halv till en sida som beskriver problemet och hur er lösning svarar mot behoven. Det här är en så kallad executive summary riktad till personer utanför projektet. I inledningskapitlet beskrivs projektets bakgrund, syfte, och begränsningar. Här knyter ni samman alla deluppgifterna och förklarar vad rapporten ska handla om och beskriver hur den är upplagd. Därefter följer ett avsnitt som beskriver identifierade krav, samt aspekter som dependability och säkerhet. En uppdaterad riskanalys och en analys av tillförligheten i systemet ska ingå i rapporten. Därefter följer en mer detaljerad beskrivning av projektresultaten, inklusive krav (med motiveringar och anknytningar till t.ex. MTS och etik-ämnena), arkitektur och design. Om ni under projektets gång har dokumenterat varje backlog item ordentligt, så bör det här avsnittet nästintill vara skrivet vid varje givet tillfälle i projektet. Avslutningsvis knyter ni ihop hela arbetet genom att dels se tillbaka, dels blicka framåt. Det kan till exempel finnas förslag på framtida utvecklingsmöjligheter och alternativa användningsområden. Systemet kanske med bara smärre modifieringar skulle fungera i andra tillämpningar än just krishantering. Rapportens längd kommer att variera från grupp till grupp. Baserat på tidigare års rapporter gissar vi att den kommer att vara på 60 sidor eller mer. 9.2 Intern-PM I intern-pm ska ni utvärdera och reflektera över hur grupp-processen samt ert arbete med projektet fungerade, för att ni själva eller de som kommer att arbeta med projektet i framtiden ska kunna dra nytta av de erfarenheter ni gjort. Intern-PM består av två delar, uppföljning av projektarbetet och uppföljning av gruppprocessen. 9.2.1 Uppföljning av projektarbetet Dokumentera erfarenheterna från att använda Scrum och att arbeta i projekt. Hur fungerade rolltilldelningen? Vad har ni lärt er om arbetssättet under projektets gång? Vad kan göras annorlunda för att arbetet ska fungera ännu bättre nästa gång? Vad har fungerat bra? Vad har fungerat mindre bra? Körde ni fast? Hur kom ni vidare? I efterhand har ni kanske reflektioner om hur svårigheterna skulle kunna lösas snabbare än vad ni gjorde. Reflektera även över skillnaderna mellan basgruppsarbete och projektarbete. 27