TDDD36 Projekttermin: Säkra mobila system

TDDD36 Projekttermin: Säkra mobila system Hösten 2011

Innehållsförteckning 1 Översikt... 1 1.1 Examination... 1 2 Projektet... 3 2.1 Aktörer... 3 2.2 Krav... 4 3 Projektledning... 5 3.1 Projektmodell... 5 3.2 Inför projektet... 5 3.3 Anvisningar för projektplanen... 6 3.4 Redovisningar... 7 3.5 Litteratur... 8 4 Teknisk utformning... 9 4.1 Programutveckling... 9 4.2 Systemets utformning... 9 4.3 Explicita krav i projektet... 11 4.4 Handledning... 12 4.5 Redovisning... 12 4.6 Litteratur... 12 5 MTS... 15 5.1 Redovisning... 15 5.2 Litteratur... 15 6 Psykologi... 17 6.1 Redovisning... 18 6.2 Litteratur... 18 7 Etik... 19 7.1 Rapporten... 20 7.2 Kvalitet... 20 7.3 Explicita krav i projektet... 20 7.4 Redovisning... 20 7.5 Litteratur... 20 8 Avstämningar... 21 8.1 Kundmöte... 21 8.2 Avstämning 1: Krav och projektplan... 22 8.3 Avstämning 2: Krav, arkitektur, design... 23 8.4 Avstämning 3: Helheten... 24 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

1 Översikt 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 1 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. 1

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 Den kommunala räddningstjänsten Den kommunala 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. 3

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. 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 olika situationer. 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 2011 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. - Intervjuer med personer som arbetar i respektive aktör ni får ta kontakterna själva, men kan eventuellt få förslag på kontaktpersoner från lärarlaget. - Saker ni hittar på själva. I de fall då krav är vaga, motsägande eller saknas så är det er uppgift att ta reda på kundens förväntan. Det är viktigt att kundens och er syn på hur systemet skall se ut är lika. 4

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. 5

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. 6

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. 7

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 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. 8

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 handdator/smartphone som kommunicerar trådlöst med övriga delar av systemet. 9

- 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 «wirel ess,secure» «high availability» Server Annan tjänst Annan tjänst «filtered,secure» Aktör 2 «mobile» Klient «wirel ess,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 programmeras i Java. Plattformen är Google Nexus S med Android 2.3 eller senare som operativsystem. Varje grupp utformar själva arkitekturen för klienten; den 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. Under projektet tillhandahåller vi en Windows-miljö för Android-utveckling, och ger tillgång till Linux och Solaris för servern, för det grupper som så önskar. 10

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 Funktionalitet Alla grupper ska implementera åtminstone följande funktioner: - Video- och röstkommunikation via eget protokoll eller via SIP. - Synkronisering av kontakter mellan alla klienter. Ytterligare krav kan identifieras från de scenarion som finns i projekthandboken. 4.3.2 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. Använd gärna en metod som CORAS eller RMF för att hantera riskerna. 4.3.3 Mobila system Ett mobilt system är inte alltid anslutet till sitt nätverk. I projektet ska ni minst säkerställa att: - 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, trafik och batterinivå. - Inga viktiga meddelanden förloras. 11

4.3.4 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å. - 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 kan vara långsammare, dock med svarstider max två gånger motsvarande icke-feltoleranta lösning. 4.4 Handledning Till er hjälp finns ett antal experter som ni kan konsultera under projektets gång: Laurent Delosieres Anna Vapen Ännu ej utsedd Systemprogramvara, QoS Autentisering, identifiering, Scrum Risk- och hotanalys, kravanalys, säkerhet 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 1 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. 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 12

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 Coulouris, 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 - 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 13

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 begrepp och 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 ett diskussionsseminarium och en hemtentamen. Diskussionsseminariet och hemtentamen och är gemensamma med etik-momentet. Dessutom redovisas delar vid avstämningarna och vid slutredovisningarna. Se avsnitt 1 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. 15

- Ev. ytterligare några aktuella artiklar. 16

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 hemuppgifter under hösten. För att få skriva dessa 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. 17

6.1 Redovisning Psykologimomentet examineras dels vid ett särskilt seminarium och dels vid avstämningarna och slutredovisningen. Se avsnitt 1 och 9 för detaljer om dessa. Ett första preliminärt utkast av gruppdagbokens fokus (strukturer och processer) ska lämnas in inför 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. 18

7 Etik Den tekniska utvecklingen går snabbt framåt. 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? Det dröjer också innan ett adekvat juridiskt ramverk utvecklas. 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 därigenom har 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 socialt och etiskt 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 redskap 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 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 det viktigt att göra en explicit etisk bedömning av projektet. Personlig integritet och valfrihet är etiska aspekter som bör beaktas vid systemets utformande. Den etiska analysen ska presenteras i projektets slutrapport. 19

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 etikmomentet innebär kvalitet att ni har 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 Detta moment redovisas skriftligt vid avstämning 1, och presenteras vid avstämning 3, samt slutredovisningen. 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 20

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. Projektor finns, men deltagarna ansvarar själva för övrig teknisk utrustning. Det är viktigt att förbereda presentationerna ordentligt! - Rapporteringar är informella presentationer inför en mindre grupp. Det är viktigt att förbereda rapporteringarna ordentligt! - Skriftlig redovisning innebär att ni lämnar in ett dokument som ni får skriftlig och eventuellt muntlig feedback på i samband med eller efter avstämningen. - Diskussioner är en interaktiv dialog mellan studenter och handledare/lärare. Se schemat för lokalanvisningar. Skriftliga rapporter ska levereras via kursplatsen till lärarlaget några dagar innan avstämningstillfället. Varje grupp har en egen mapp där de kan ladda upp sina rapporter. Till varje avstämning kan även finnas helt 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). Det är viktigt att allt skriftligt material har ett omslag med gruppnummer, namn och medlemmar, så att det enkelt kan identifieras. Lämpligtvis skapar gruppen en enkel mall i början av projektet som sedan används genomgående. 8.1 Kundmöte Datum: Omkring den 5/9 ni bestämmer tid med er kund 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. 21

8.2 Avstämning 1: Krav och projektplan Datum: Torsdag 15/9 Syfte: Deltagare: Form: Förberedelser: Genomgång av kraven som har identifierats under projektets inledningsfas. Alla i projektgruppen Kundrepresentanter Lärare: projektledning, säkerhet, mobila system Rapportering av, och diskussion om, kraven. Skriftlig redovisning av utkast till etisk analys, projektplan och gruppdagbok. Ladda upp en skriftlig rapport med kravbeskrivningar, samt utkast om etiska risker till kursplatsen senast klockan 23:59 måndagen den 12/9. 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 8.2.1.1 Krav 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. 8.2.1.2 Etiska risker Inför avstämning 1 skall även ett utkast levereras som identifierar de etiska risker som kan uppstå i samband med systemet. Motivera varför de identifierade riskerna kan utgöra ett etiskt problem. 8.2.1.3 Projektplan 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, tidsplanering, 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 22

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å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.2.1.4 Gruppdagbok Ett första preliminärt utkast av gruppdagbokens fokus (strukturer och processer) ska lämnas in inför avstämningen tillsammans med en tidsplan för gruppdagboken. 8.3 Avstämning 2: Krav, arkitektur, design Datum: Torsdagen den 13/10 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, mobila system, systemprogramvara, MTS Rapportering av, och diskussion om nya krav. Rapportering av, och diskussion om systemarkitektur och design, inklusive presentation av riskanalysen. Ladda upp skriftligt underlag till alla punkter till kursplatsen senast klockan 23:59 måndagen den 10/10. 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 8.3.1.1 Krav 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 bör ni redovisa någon form av riskanalys och hur den har lett till era krav. För pålitlighet (tillförlitlighet) förväntas ni redovisa analys av tänkbara fel och ange de felmodeller mot vilka ert system kommer att uppvisa feltolerans. För klientsidan förväntas ni även redovisa hur ert system kommer att anpassas då handburna enheters energinivå varierar över tid. Kraven ska vara realistiska (eller åtminstone gå att anpassa så de blir realistiska) och ska vara testbara. 8.3.1.2 Arkitektur och design 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. 23

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. 8.3.1.3 MTS MTS-momentet syftar till att ni ska presentera en bild av de tänkta, kommande användarna och de situationer som systemet kommer att användas i. Hänsyn ska också tas till de olika organisatoriska förutsättningar som finns representerade. Redovisa en bakgrundsanalys av de olika tänkta aktörerna utifrån exempelvis - Vilka är aktörerna (inom er organisation)? - Vilken kompetens har de? - Vilka är (huvud)uppgifterna (i en normalsituation)? - Vilka är (huvud)uppgifterna (vid en extraordinär händelse)? - Vilka samarbetar (internt)? - Vilka samarbetar (externt)? - Vilken kommunikationsutrustning finns idag? - Vilka kommunikationsvägar finns? -... När det gäller organisationen är det viktigt att analysera organisationsstrukturen t.ex. genom att beskriva både den formella organisationen (den på papper) och den informella (den levda). Det handlar bland annat om vem som gör vad, vem som har ansvar och hur beslut fattas och distribueras i organisationen. Förutom att läsa informationsmaterial m.m. från de olika organisationerna bör in intervjua minst en representant för den organisation som ni har som kund. 8.4 Avstämning 3: Helheten Datum: Torsdagen den 24/11 Syfte: Deltagare: Form: Förberedelser: Uppföljning av projektets resultat hittills. Alla i projektgruppen. Lärare: säkerhet, mobila system, systemprogramvara, etik Presentation av uppdaterad riskanalys samt reviderade krav. Presentation av etiska risker. Redovisning och diskussion av reviderad arkitektur, design, implementation. Skriftlig redovisning av gruppdagboken. Ladda upp skriftligt underlag till alla delar, inklusive analys av gruppdagboken och analys av etiska risker till kursplatsen senast klockan 23:59 måndagen den 21/11. Schema: Tid Grupp 1 8:15-9:15 Räddningstjänst 9:30-10:30 Sjukvård 10:45-11:45 Försvarsmakt 24

8.4.1 Anvisningar 8.4.1.1 Produkten 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). Presentationen av lösningen ska visa hur er lösning hanterar de felmodeller som angavs under avstämning 2 och hur det implementerade systemet kommer att testas med avseende på tänkta felmoder, och batteriförlust i handenheten. 8.4.1.2 Gruppdagboken Till denna avstämning ska ett utkast till den slutliga analysen av gruppdagboken vara klar och skickas till läraren. 8.4.1.3 Etiska risker Vid denna avstämning ska en strukturerad och utförlig etisk analys av de identifierade riskerna presenteras. 25

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. Dessutom skall varje grupp göra s.k. peer review av en annan grupps arbete: utvärdera lösning och arbetssätt, ge konstruktiv kritik och förslag till, på såväl skriftliga slutrapporten och muntliga presentationen. Grupperna själva ansvarar för fördelningen av peer-review-uppgiften. 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 pålitlighet 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 27

vad ni gjorde. Reflektera även över skillnaderna mellan basgruppsarbete och projektarbete. Redovisa även tidsåtgången för själva projektet. Ur redovisningen ska gå att läsa tidsåtgång för varje enskild projektmedlem. Tid för egen kompetensutveckling som är nödvändig för projektets genomförande bör också belasta projektet. Förklara vilka principer ni har använt för tidsmätning och vilka lärdomar ni har gjort inför framtida projekt. 9.2.2 Grupp-processen En gruppvis skriftlig redovisning av projektgruppens bildande, arbete och avslutning med fokus på utvecklingen av gruppens inre arbetsprocesser. Teoretiskt bör grupputvecklingen således förankras i någon etablerad grupputvecklingsteori som ni stött på under terminen. Redovisa era reflektioner över hur de händelser av uppgiftskaraktär som förekommit har påverkat gruppen. Av gruppens redovisning ska också framgå hur man på olika sätt försökt att utnyttja beteendevetenskaplig konsultation för att underlätta den egna arbetsprocessen. Saker som kan ha bidragit till ett effektivt utnyttjande av denna resurs respektive faktorer som lagt under i vägen för nyttjande av denna resurs ska framgå. Som underlag för denna redovisning ska man i första hand referera till den gruppdagbok som varje projektgrupp ska ha fört och i andra hand till andra informationskällor. När det gäller teoretiska utgångspunkter ska man referera till de källor man hämtat dessa ur. 9.3 Muntlig redovisning Den muntliga redovisningen ska ge en översikt över kraven på systemet (och till vilken grad de har uppfyllts), riskanalysen, systemarkitektur och viktiga design- och implementationsbeslut. Uppföljning av icke-funktionella krav ska också vara med. Ni ska också kort 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, mm. 9.4 Demonstration av projektet Vid demonstrationen ska ni visa hela ert system, och demonstrera att kraven på det är uppfyllda. Demonstrationen kommer att ske inomhus, vilket innebär att GPSmottagaren inte kommer att fungera. Ni måste utforma något sätt att komma runt denna begränsning (till exempel genom att simulera GPS-koordinater, eller genom att ha en handdator där GPS-mottagaren fungerar). Vid demonstrationen förväntas ni demonstrera: - Att den viktigaste funktionaliteten är implementerar och fungerar, och att handenheterna hålls uppdaterade med korrekt information. - Att kommunikation mellan handenheter fungerar. - Att systemet klarar att nätverket försvinner. - Att systemet klarar differentiering av meddelanden vid låg batterinivå. - Att systemet klarar kraven på feltolerans. 28

A Scenariobeskrivningar I det här avsnittet beskrivs ett antal scenarier som ligger till grund för de tekniska kraven som ställs på systemet. Varje scenario beskriver en konkret situation och kan omfatta ett stort antal skilda krav. Varje scenario hör till en viss grupp i projektet, men eftersom många av kraven är generella så måste man läsa alla scenarier, och utvinna dels generella krav och dels krav på den egna gruppens tillämpning. Utöver scenarierna kan krav komma direkt från kund eller användare, eller ur allmänna principer och behov från till exempel säkerhetsområdet, etik, eller krishantering. Det är viktigt att utvinna så bra krav som möjligt för att framgångsrikt genomföra och planera projektet. A.1 Efter stormen Den 15-16/10 blåste det storm genom Östergötland. Stormen var den värsta sedan 2005, med stora skador till följd. Räddnings- och röjningsinsatserna måste kämpa med nedblåsta träd, nedfallna el- och teleledningar, förstörda mobiltelefonimaster, översvämmade vattendrag och sjöar, vägar som har rasat, och alla de skador på egendom och personer som en storm av den här magnituden för med sig. Stat, kommun och landsting har samlat krafterna för att ta itu med situationen så snabbt och effektivt som möjligt. Områdets räddningstjänster, sjukvård, polismyndigheter, kommuner, landsting och landets militär är alla mobiliserade för den stora insatsen. Till sin hjälp har de ett nyutvecklat kommunikationssystem som gör det möjligt att snabbt, effektivt och säkert dela information och kommunicera under insatsen. A.2 Aktörerna Det finns fyra aktörer i räddningsarbetet: polis, militär, sjukvård och räddningstjänst. Polisens främsta uppgifter är att motverka brottslighet, samordna sökning efter saknade personer till lands, och säkerställa den allmänna ordningen. Räddningstjänsten har ett varierat uppdrag som innefattar bland räddning, annat röjning, släckning av bränder, visst infrastrukturskydd (exempelvis skydd mot översvämningar), med mera. Sjukvårdens uppdrag skiljer sig inte markant från vardagens verksamhet. Sjukvården ansvarar för transporter och vård av skadade. Slutligen har militären en roll som allmän resurs. Till exempel kan man bygga broar, installera reservaggregat för elektricitet, assistera vid sökning och röjning, skapa lägesbilden, koordinera evakueringar, och mycket mer. Varje aktör har ett eget kommunikationssystem som består av handdatorer kopplade till ett centralt system. De olika centrala systemen är sedan sammankopplade för att underlätta samverkan mellan aktörerna. 29

A.3 P.L. kör ambulans P.L. är en ambulansförare i tjänst efter stormen. Klockan 13:43 får hon ett larm om att en äldre man i Källfallet har ramlat och antagligen brutit lårbenshalsen. Normalt skulle larmet ha gått till ambulansen i Finspång, men den är redan upptagen på annat håll. Frivilliga från socken har gått från gård till gård för att se vilka som behöver hjälp, och har ringt in larmet till S.O.S. alarm. Källfallet ligger norr om Roxen, i slutet av en grusväg i skogen. Stormen har fällt ett stort antal träd i området. P.L. söker den bästa vägen till Källfallet i sin handdator, och med hänsyn till situationen visar den att hon måste köra runt Roxens östra sida, inte via Berg eller Ljungsbro, som normalt hade varit den snabbaste vägen, för att broarna över Motala ström har rasat. P.L. uppdaterar systemet med information om vart hon är på väg, och varför. Kontinuerligt under färden markerar datorn hennes position, och skickar den till det centrala informationssystemet. Strax innan hon når Norsholm så får hon information via handdatorn att vägen längs Roxens norra strand är blockerad av en trafikolycka. Informationen kommer från Polisen och Räddningstjänsten som har kallats till platsen. Olyckan har inga skadade, så hon kan fortsätta till sitt ursprungliga mål, men hon vet att trafikskadade hade kunnat få prioritet över ett fall. Hennes rutt uppdateras automatiskt med en ny väg som undviker trafikolyckan. Vid avfarten mot källfallet ser P.L. att vägen ut mot Pukhult är blockerad av nedfallna träd, och för in den informationen i kartan på handdatorn. Informationen blir då tillgänglig för alla andra, och en anteckning läggs in om att vägen behöver röjas. Vid just det tillfället finns inte radiotäckning, vilket det brukar göra, så informationen skickas inte omgående, utan sparas tills det finns täckning igen. Väl framme i Källfallet hittar P.L. till gården där den skadade, A.N. har fått första hjälpen av sockens frivilliga. P.L. och hennes kollegor lastar in A.N. i ambulansen, meddelar (via sin handdator) att de är på väg tillbaks, och att A.N. har hämtats, så ingen annan ambulans råkar svara på larmet också. Genom handdatorn får de en rutt tillbaks, nu via Berg, där militären har byggt en tillfällig bro. P.L. kontrollerar även trafikolyckan som blockerade vägen vid Roxens strand, för att se att deras hjälp fortfarande inte behövs, och ser att vägen där nu är fri, efter att Räddningstjänsten har flyttat på olycksfordonen. 30

A.4 N.S. bygger en bro Fänrik N.S. är plutonchef för Krigsbro-5- plutonen i 2:e kompaniet vid Göta Ingenjörsregemente (Ing 2) i Eksjö, och således ansvarig för brobyggande. På morgonen den 17/10 kommenderas han att bygga en bro över Motala ström strax norr om Berg, där bron har rasat. Information om situationen finns på kartan i N.S. handdator, där den har lagts in av Räddningstjänstens personal och bekräftats av värnpliktiga i området. N.S. uppskattar färdtiden till Berg till 90 minuter. Räddningstjänsten har tagit stillbilder av det gamla brofästet och vägen, och baserat på bilderna ser det ut att vara ett relativt enkelt uppdrag, så N.S. uppskattar att bron kommer att vara byggd på bara två timmar. N.S. uppdaterar informationen i handdatorn med uppgiften att plutonen är på väg till platsen och en uppskattad tid för att arbetet ska vara klart. På väg till Berg kör plutonen förbi flera områden med nedblåst skog. En värnpliktig lägger in information om detta i handdatorn allt eftersom man ser detta. Datorn i sig övervakar tillgången till radionätet och skickar in information om områden där det saknas täckning. Den uppdaterar också kontinuerligt plutonens plats, så att ledningscentralen kan se var de befinner sig. Väl framme i Berg väntar inga överraskningar, utan bron läggs på plats på två timmar. När arbetet är klart uppdaterar N.S. informationen i handdatorn så att alla vet att vägen återigen är farbar. N.S. uppdaterar även plutonens status och får automatiskt nästa uppdrag, baserat på en prioritering ledningen kontinuerligt gör av alla inlagda tänkbara uppdrag. N.S. bekräftar och plutonen rör sig vidare till nästa problem. A.5 V.K. fixar mobiltäckningen och mera Furir V.K. är en gruppchef inom 5:e kompaniet vid Göta Ingenjörsregemente (Ing 2) i Eksjö. På förmiddagen den 17/10 får hon en order från sin plutonchef att installera ett reservkraftsaggregat för att ge ström till en kritisk mobiltelefonimast. Man har noterat att det saknas radiotäckning i ett område vid Roxens norra strand. Efter att ha rådgjort med teleoperatörerna så har man avgjort att problemet går att lösa genom att återställa elförsörjningen till basstationen i Hagadal. Detaljer om var basstationen ligger, passerkoder för att komma in till, och i, byggnaden, samt en beskrivning, inklusive foton, laddas ned till V.K.s handdator så de är tillgängliga även då det saknas radiotäckning. 31

V.K. indikerar att arbetet är påbörjat, hämtar ut ett mobilt dieselaggregat från mobiliseringsförrådet (förrådets inventarieförteckning uppdateras med aggregatets plats och användning). Handdatorn visar den snabbaste vägen till basstationen, med hänsyn taget till att bland annat Motala ström inte går att passera för närvarande. Tack vare anvisningarna i handdatorn, och tidigare övning, går installationen av aggregatet smärtfritt, och basstationen kan tas i drift. Handdatorn som V.K. använder upptäcker att radiotäckning åter är etablerad, och skickar in uppdaterad täckningsinformation till centrala system. Dessutom indikerar V.K. i sin handdator att arbetet är klart och att radiotäckningsinformation för området behöver uppdateras. På väg från Hagadal påkallar en äldre man V.K.s grupps uppmärksamhet, och ber dem hjälpa honom och hans skadade hustru. Hustrun skadades då nedblåsta grenar krossade ett fönster i deras hus. Hon har skärsår i ansiktet och på överkroppen, har förlorat mycket blod, och behöver mer vård än V.K. kan erbjuda. Eftersom situationen verkar akut så upprättar V.K. ett videosamtal med en jourhavande läkare, som råder V.K. att snarast transportera kvinnan till Norsholm, där det finns ett läkarlag på plats för att hjälpa skadade. Gruppen lastar försiktigt in kvinnan i sitt fordon medan V.K. lägger in information om situationen i sin handdator, som även meddelar läkarlaget att ett akutfall är på väg. Transporten till Norsholm går utan incident, och efter att ha lämnat kvinnan kan V.K. och hennes grupp gå vidare till nästa uppdrag. A.6 K.P. fixar backupen K.P., tekniker på räddningstjänstens IT-avdelning, blir kallad till jobbet eftermiddagen den 17/10. Räddningstjänstens centrala informationssystem, där information om insatser lagras, och varifrån information hämtas för att integreras i olika ledningssystem ser ut att ha stannat. Det visar sig att incidenten beror på att fallna träd hade slagit ut elförsörjningen till centralen i gamla övningsområdet, och att reservkraften inte har gått igång på grund av en felkoppling i undercentralen. Eftersom Räddningstjänstens eget informationssystem inte är helt pålitligt för närvarande, använder K.P. sin handdator för att rapportera problemet till Försvarsmakten, som han vet arbetar med bland annat elförsörjning i området. Han markerar rapporten som högt prioriterad eftersom Räddningstjänsten är beroende av systemen som just nu saknar el. K. P. kollar genast läget hos den sekundära servern genom att först köra till Kvarn, där reservcentralen ligger, och komma in i ledningsreservcentralen. Behörighetsdata och lokalinformation finns redan i hans handdator. Väl inne i lokalen försäkrar han sig om att den sekundära servern har tagit över från den primära, och att den verkar ha en uppdaterad lägesbild. Reservcentralen har inte samma kapacitet som den primära centralen. Man har planerat att uppgradera system och nätverk, men upphandlingen är inte klar. Eftersom systemet inte ta emot och behandla information i samma takt som den primära servern så måste alla handdatorer i systemet anpassa sig, och dels skicka data mindre ofta, och 32

dels prioritera viktig information. Användarna ska inte behöva göra något de är fullt upptagna med annat. A.7 X.P. kör lastbil X. P. kör runt i sin lastbil på väg till ett antal depåer varifrån material ska hämtas och fraktas till ett provisoriskt läger där ett 100-tal familjer från omgivningen kring Bestorp ska tillbringa de närmaste nätterna medan röjning av området pågår. Resan har tagit 3 timmar längre än vad det ska göra på grund av en trafik och hinder på vägarna, som i vissa fall har krävt alternativa körsträckor. Olyckligtvis har X.P.s bil-laddare till handdatorn gått sönder, och battierläget på datorn har sjunkit så mycket under den långa resan att datorn automatiskt går över till ett snålt läge, där enbart de viktigaste meddelandena behandlas, så att batteriet räcker så länge som möjligt, förhoppningsvis ända tills hon kan ladda om batteriet. A.8 G.A. röjer vägen Deltidsbrandmannen G.A. kallas in på förmiddagen den 16:e in för att röja upp vägsträckor som hindras av nedfallna träd och säkra föremål som riskerar att blåsa iväg och skada människor (exempelvis takplåt). Ledningscentralen har fått in hundratals rapporter och gjort en grov prioritering. G.A. får i sin handdator en översiktsbild av de för tillfället högst prioriterade uppdragen och ger sig tillsammans med sin kollega iväg för att ta hand om ett träd som har rasat mot ett flerfamiljhus i Bestorp. Trädet hindrar de boende från att ta sig ut ur huset och de känner sig inte säkra där de är eftersom de är rädda att det ska falla fler träd. På väg till bostaden tvingas de röja upp träd på vägen för att överhuvud taget kunna ta sig fram. När de röjt upp en vägsträcka, rapporterar de in det med hjälp av handdatorn. Under tiden får de in ett textmeddelande från ledningscentralen om att det bor en äldre man i området dit de är på väg. Mannen är beroende av hemtjänsten för att få lagad mat, sköta om sin hygien och lägga om sår. De får frågan om de kan ta med sig J.K. till Vist Skola i Sturefors där det finns personal från hemtjänst och sjukvård. G.A. accepterar uppdraget och markerar att ärendet är på väg att åtgärdas. Området kring Bestorp är strömlöst så det finns varken vatten eller värme, vilket kan bli ett problem. G.A. kollar med handdatorn och ser att det har satts upp en samlingspunkt med där man har ordnat med vatten och tillfälliga sängplatser. Väl framme vid huset lyckas de såga av stammen och hjälpa de boende ut så att de på egen hand kan ta sig till samlingspunkten. Några av de boende undrar om de kan hjälpa till på något sätt. G.A. skriver upp deras namn och telefonnummer (även om det inte fanns någon vid tillfället) i handdatorn och säger att det vore bra om de kunde gå runt och informera de boende i området om var de kan ta vägen för att få tag på vatten och att de ska vara försiktiga med att elda eftersom han har hört från ledningscentralen att det uppkommit ett antal brandtillbud då folk har eldat i osotade värmekaminer. 33

G.A. och hans kollega åker hem till den äldre mannen och tar med honom till Sturefors. Mannen är orolig och lite förvirrad, men de ser i sin handdator att mannen behöver ta medicin regelbundet så de ser till att få med sig medicinkartan eftersom de är osäkra på vad som finns tillgängligt på stället dit de ska ta sig. Väl framme markerar de ytterligare ett ärende som åtgärdat och går på nästa högprioriterade uppdrag. A.9 B.N. letar efter Hjalmar Hjalmar är 81 år gammal och bor i ett hus i Lövsveden. På senare år har Hjalmar blivit tankspridd, men tack vare uppmärksamma och hjälpsamma barn, barnbarn och grannar så klarar han sig bra på egen hand. Den 16/10 är fast telefoni och el utslaget i området där Hjalmar bor, men grannar tar sig till hans hus. De vet att han var hemma dagen innan, men nu syns inget spår efter honom. Grannarna ringer först släktingarna för att se att han inte är hos dem, och när det är klart att Hjalmar saknas ringer de S.O.S. Alarm för att anmäla honom försvunnen. Larmet går vidare till Polisen, som ansvarar för att hitta saknade personer. Uppdraget prioriteras högt eftersom Hjalmars möjligheter att överleva en längre tid i skogen är ganska små. Polisen B.N. tar emot uppdraget via sin handdator han är i närheten. B.N. börjar med att kontrollera vilka andra resurser som finns tillgängliga, och får bland annat upp en grupp värnpliktiga samt kontaktuppgifter till flera boende som har evakuerats från Bestorp. Han använder sin handdator för att begära in samtliga resurser till eftersökningen. Begäran sänds vidare till respektive aktör, som bedömer att resurserna är ska tilldelas detta uppdrag. Informationen i lägesbilden uppdateras, och de olika personerna rör sig mot Hjalmars hem. B.N. hämtar även upp information om Hjalmars hälsoläge. Eftersom situationen är så allvarlig och akut får han tillgång till information som kan vara kritisk för att ge Hjalmar akut vård. Här kan bland annat utläsas att Hjalmar lider av kärlkramp och hjärtsvikt och tar bland annat digitalis och nitroglycerintabletter. B.N. hittar snabbt medicinen i Hjalmars hus, och tar den med sig om den skulle behövas. Alla som deltar i eftersökningen har tillgång till en handdator. Denna skickar kontinuerligt information om sitt läge så att B.N. kan se vilket område som har genomsökts. Skulle någon hitta Hjalmar kan de markera positionen med sin handdator, så att andra snabbt kan ta sig till platsen. B.N. vet också att han snabbt kan få medicinsk hjälp från experter vid Universitetssjukhuset i Linköping om så skulle behövas. 34