1
2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL (forts.)... 11 MOF... 13 Applikationens livscykel... 14 Översikt: Applikationens livscykel... 15 Systemutveckling... 16 Överlämning... 17 Systemförvaltning... 19 Schematisk bild... 20 Dokumentation... 21 Översikt: Dokumentation... 22 Bygga applikation... 23 Dokumentation... 24 Huvuddelar... 26 Introduktion... 27 Hantering av applikationens livscykel... 28 Krav... 29 Koncept... 30 Implementering... 31 Användaregränssnitt/API... 32 Information... 33 Utrullning... 34 Skötsel... 35 Förhindra att dokumentet föråldras... 36 Exempel på mall... 37 Introduktion... 38 Hantering av applikations livscykel... 40
3 Krav... 41 Koncept... 42 Implementering... 43 Användaregränsnitt/API... 44 Information... 45 Utrullning... 46 Skötsel... 47 Repetitionsfrågor... 48
4 Introduktion Standarder Applikationens livscykel Dokumentation
5 Standarder
6 Översikt: Standarder Avsnittet är uppdelat i följande rubriker: 1058.1-1987 IEEE Standard for Software Project Management Plans ITIL MOF
7 1058.1-1987 IEEE Standard för Software Project Management Plans Antal utvecklingsaktiviteter Standarden definierar ett antal utvecklingsaktiviteter. Har ett delresultat Varje aktivitet har ett delresultat, antingen i form av kod eller ett dokument. Ett antal Standarden tillhandahåller ett antal strukturerade mallar för dokumentering av applikationer 1. Tänkt både för Tänkt både för utbildning och som hjälp i ett applikationsprojekt. 1 http://www.utdallas.edu/~chung/ieee-templates.pdf
8 Ingående dokument
9 Syfte och struktur Syfte med de olika dokumenten: Dokument SPMP SRS SDD STD Syfte att dokumentera beslutad funktionalitet och leveransdatum. att dokumentera vad som har beslutats med projektledare, när det gäller design och funktionstest. att dokumentera beslut tagna för design för att tillhandahålla bas för implementering och test av applikation. att dokumentera hur applikationen skall testas och hur resultaten skall hanteras.
10 ITIL ITIL ITIL, The Information Technology Infrastructure Library. Utvecklat av Utvecklat av United Kingdom of Government Commerce (OGC) i slutet av 80- talet. Motsvarar statskontoret i Sverige. Mål att Mål att förbättra janteringen av IT-tjänster för statliga myndigheter. Reviderad Reviderad 2007 ITIL version 3.
11 ITIL (forts.) Definierar Definierar processer och ett antal riktlinjer, för hantering av IT-tjänster. Bygger på Bygger på Best practice. Uppdelat i Uppdelat i fem delar: - Service Strategy. - Service Design. - Service Transition. - Service Operation. - Continual Service Improvment.
12 Dessa fem delar, beskrivs i fem stycken böcker. Viktig aspekt är delen för Continual Service Improvement. Där man hela tiden försöker att ge förslag på hur man kan göra det annorlunda och förbättra tjänsten och/eller systemen.
13 MOF Microsoft Operation Framework MOF Microsoft Operation Framework. Första versionen Första versionen kom 1999. Projektmetodik som Microsoft använder sig av, för sina interna funktioner och tjänster. Senaste versionen Version 4 som är den senaste versionen, integrerar även Microsoft Solution Framework (MSF). Struktur för IT-tjänsten Ger liksom ITIL, struktur för IT-tjänsten. Närmar sig MOF närmar sig alltmer ITIL.
14 Applikationens livscykel
15 Översikt: Applikationens livscykel Avsnittet är uppdelat i följande rubriker: Systemutveckling Överlämning Systemförvaltning Schematisk bild
16 Systemutveckling Består av Systemutvecklingen består av fyra faser: - analys. - utformning. - programmering. - testning.
17 Överlämning Ligger mellan Överlämningsfasen ligger mellan systemutveckling och systemförvaltningen. Mest kritiska fasen Överlämningen är det mest kritiska fasen, det utvecklade resultat skall omvandlas till nytta för verksamheten. Det är i denna fas som projektledaren byter namn till förvaltningsledare och systemutvecklingen går över till systemförvaltning. Även det idag så populära uttrycket DevOps har sin kärna i dessa trakter, där utvecklingen (Development) möter förvaltningen och drift (Operations), sammanfogas till ett ord DevOps. Vissa organisationer inser också att det minst kostsamma sättet att lösa en bugg är att låta den som skapat den även få lösa denna. Utvecklaren tillåts att följa med en bra bit in i förvaltningen.
18 Inte helt ovanligt att nya uppdrag drivs i förvaltningen, det som kallas för aktiv förvaltningen och som även har en budget för vidareutveckling för att möta framtiden och nya krav på ett bra sätt. Det är även viktigt att kunskapsöverföring sker över hela livscykeln, för att säkerställa att transaktionstiden blir så kort som möjligt för utveckling, förvaltning och användare i form av konsumtion av dokumentation och insikt på bästa sätt över hela livscykeln.
19 Systemförvaltning Enligt Pareto principen Enligt Pareto principen 2 (80-20 regeln) så skapar 20 av orsakerna 80 procent av verkan. Forskning inom området Svenska forskning inom området visar att genom att ha en bra ordning på systemförvaltningen så kan man få 20-40 procent högre avkastmomg på investeringen. 2 http://www.forbes.com/sites/davelavinsky/2014/01/20/pareto-principle-how-to-use-it-to-dramatically-growyour-business/
20 Schematisk bild
21 Dokumentation
22 Översikt: Dokumentation Avsnittet är uppdelat i följande rubriker: Bygga applikation Dokumentering Huvudelar Förhindra att dokumentet föråldras
23 Bygga applikation Tuff process Bygga applikation är en tuff process, involverar många olika discipliner. Skall specificeras Krav skall specificeras, arkitektur skall definieras. Information hanteras Hur skall informationen hanteras? Testfasen Testfasen, hur skall test se ut? Vem skall vara involverade?
24 Dokumentation Enkel Dokumentationen skall vara enkel. Kunna fungera Skall kunna fungerar både för mindre och större projekt. Lätt att underhålla Lätt att underhålla. Som behandlas Ämnena som behandlas i dokumentet skall göra så att: - det är lätt att underhålla applikationen. - lätt att använda. - lätt att integrera.
25 - lätt att sköta.
26 Huvuddelar Dokumentmall består av nio huvudrubriker.
27 Introduktion I delen Introduktion, beskrivs syfte för applikationen, sätter applikationen i ett sammanhang och definierar mål för applikationen. Skall kunna ges till beställaren eller huvudman.
28 Hantering av applikationens livscykel I nästa del beskrivs applikationens livscykel. Hur versionskontrollen sker, hur eventuella problem hanteras och hur kvalitetskontrollen sker.
29 Krav I avsnittet krav, beskrivs funktionella krav och icke funktionella krav. Funktionella krav beskriver funktionaliteten hos det önskade systemet som oftast består av något slags beräkning och resultat, given specifikt indata. Icke funktionella krav beskriver istället hur snabbt dessa beräkningar ska utföras och hur snabbt systemet ska svara när dess funktionalitet används.
30 Koncept I avsnittet koncept, beskriv hur kommunikation med andra komponenter sker. I avsnittet beskrivs även hur säkerheten skall hanteras samt om applikationen skall finnas i andra språkversioner.
31 Implementering Under avsnittet implementering ges översikt över implementeringen, viktiga delar i implementering som kan påverka resultatet. Exempelvis att applikationen kräver viss version av SQL-server med specifika inställningar.
32 Användaregränssnitt/API I avsnittet användaregränsnitt/api visas hur gränssnittet ser ut för de som skall använda applikationen. Beskriver nyckelfunktioner för produkten. Eventella API som används, specificeras även här.
33 Information Under avsnittet information, beskriv hur lagring skall hanteras och hur användare får tillgång till informationen. Här beskriv också rättighetssystem eller vilka rättighetsroller som eventuellt finns i applikationen.
34 Utrullning Nästa avsnitt, utrullning, beskriver de olika stegen i installationsprocessen, samt hur eventuella konfigurationer skall göras.
35 Skötsel I avsnittet skötsel, beskriv hur applikationen skall hanteras. Här finns även beskrivning hur applikationen startas eller stoppas. I avsnittet finns det även beskrivet hur applikationen kan monitoreras, vilka mätvärden som skall användas och eventuell information om tröskelvärden. Här finns också beskrivet eventuella undantag, som kan dyka upp i applikationen och orsaken till dessa.
36 Förhindra att dokumentet föråldras Att förhindra att dokumentet föråldras utan några uppdatering sker, är det viktigt att tänka på sakerna nedan. Inte för detaljrikt Dokumentera inte för detaljrikt, om inte det inte behövs. Ju mer detaljrikt, desto svårare är att hålla dokumentet uppdaterat, fler faktorer som påverkar. Bättre att Bättre att dokumentera det övergripande konceptet. Visa detaljerna Programkoden skall visa detaljerna och skall ha många kommentarer. Repetera inte Repeterar inte egenskaper som är dokumenterade någon annanstans. Bättre att ha länkar inom dokumentet eller låta programvara hantera dessa.
37 Exempel på mall Dokumentation för [NAMN_PÅ_PROJEKT_ SKRIVS_HÄR]
38 Introduktion [I delen introduktion, beskrivs syfte för applikationen, sätter applikationen i ett sammanhang och definierar mål för applikationen. Skall kunna ges till beställaren eller huvudman.]
39 Innehåll Introduktion... 38 Hantering av applikations livscykel... 40 Krav... 41 Koncept... 42 Implementering... 43 Användaregränsnitt/API... 44 Information... 45 Utrullning... 46 Skötsel... 47
40 Hantering av applikations livscykel [I denna del beskrivs applikationens livscykel. Hur versionskontrollen sker, hur eventuella problem hanteras och hur kvalitetskontrollen sker.]
41 Krav [Här beskrivs funktionella krav och icke funktionella krav. Funktionella krav beskriver funktionaliteten hos det önskade systemet som oftast består av något slags beräkning och resultat, given specifikt indata. Icke funktionella krav beskriver istället hur snabbt dessa beräkningar ska utföras och hur snabbt systemet ska svara när dess funktionalitet används.]
42 Koncept [Beskriv hur kommunikation med andra komponenter sker. I avsnittet beskrivs även hur säkerheten skall hanteras samt om applikationen skall finnas i andra språkversioner.]
43 Implementering [Här ges översikt över implementeringen, viktiga delar i implementering som kan påverka resultatet. Exempelvis att applikationen kräver viss version av SQL-server med specifika inställningar.]
44 Användaregränsnitt/API [Här visas hur gränssnittet ser ut för de som skall använda applikationen. Beskriver nyckelfunktioner för produkten. Eventuella API som används, specificeras även här.]
45 Information [Här beskrivs hur lagring skall hanteras och hur användare får tillgång till informationen. Här beskriv också rättighetssystem eller vilka rättighetsroller som eventuell finns i applikationen.]
46 Utrullning [Här beskrivs de olika stegen i installationsprocessen, samt hur eventuella konfigurationer skall göras.]
47 Skötsel [Här beskriv hur applikationen skall hanteras. Här finns även beskrivning hur applikationen startas eller stoppas. I avsnittet finns det även beskrivet hur applikationen kan monitoreras, vilka mätvärden som skall användas och eventuell information om tröskelvärden. Här finns också beskrivet eventuella undantag, som kan dyka upp i applikationen och orsaken till dessa.]
48 Repetitionsfrågor 1) Vad beskriver dokumentet SPMP? 2) När lanserades ITIL version 3? 3) MOF inkluderar även ett ramverk, vilket?
49 4) Vad beskriver Pareto? 5) Varför är det viktigt att hålla din dokumentering enkel?