Analys och förundersökning

Enkelt och kortfattat

Under analysen samlar man ihop dokument och information och intervjuar användare av systemet förutsatt att det finns något. De allra flesta systemen är för komplexa att förstå i sin helhet, därför brukar man dela in systemet i små bitar, så kallade subsystem. Analysdelen inkluderar också mera detaljer än undersökningen men den innehåller färre än till exempel designdelen som följer senare.

Ett exempel på undersökning skulle kunna vara ett konkret problem där en skola till exempel har problem med sina registreringar till kurser etcetera. Låt säga att de manuella funktionerna visar sig kanske fallera. Dröjsmålen och kostnaderna som uppstår därav är inte godkända. Efter att ha studerat system på andra skolor kan man bestämma sig för att en telefonservice vore den bästa lösningen till problemet. Ytterligare ett par år senare har detta system också skapat problem och skolan bestämmer sig för att utveckla ett system som möjliggör registrering via WWW. När systemet når sin implementationsfas har telefonsystemet fått gå i pension.

Ovanstående är exempel på de olika faserna analys och förundersökning. Mycket enkelt och kortfattat.

Programutveckling/systemutveckling går i huvudsak ut på att analysera olika flöden i en organisation samt hitta, analysera och finna lösningar på olika problem. Detta arbete leder fram till en så kallad kravspecifikation som beskriver vad det kommande datorsystemet ska göra, vilka funktioner det ska innehålla etc. Man vet alltså vad programmet ska göra, men inte mycket om hur användarinteraktionen ska gå till. Man nöjer sig med den formella funktionsbeskrivningen och sätter sig glad i hågen för att konstruera och implementera systemet. Användargränssnittet, framför allt de psykologiska aspekterna, får i dessa metoder mycket litet eller inget uttalat utrymme.

Granskningar och förundersökningar spelar en avgörande/fundamental roll i programutvecklingen. Dessa genomförs ofta internt inom projektet av konsulter/systemvetare. Konsulten är anlitad för att göra en förändringsanalys i vilken han/hon ska försöka utreda vad verksamheten har för förändringsbehov. Utifrån dessa förändringsbehov formuleras en plan inför fortsatt utveckling av verksamheten. FA/SIM som är en mycket använd metod för att analysera består av fem delpunkter som jag visar här nedan. Dessa moment är också utförligt beskrivna.

FA/SIM består av fem analysområden (generella faser)

• skillnaden mellan "hur jag vill att det skall vara" och "hur jag uppfattar att det är"

• problematisera, ifrågasätta
• förhöra, intervjua
• skapa kunskap om problemen
• reducera det problematiska
• bryta ned i delproblem

• man reducerar det problematiska i en situation

Arbetsmetodik dokumentationsform

• Identifiering och formulering av problem och problemlista
• Problemområdesavgränsning vara med, lämnas utanför
• Problemområdesindelning (härleda delproblem) problemområdesdokument
• Analys av problemsamband (orsak, samband, effekt) problemgraf

• Hur jag vill att det ska vara

• styra verksamheten


• bedömer riktning på behov och åtgärder redan här (överensstämma)


• bryta ned i delmål

Har man inga mål, då har man heller inte några problem

• Målidentifiering idag Mållista, nuläge


• Analys av målsamband

(relationer, samverkan, målkonflikter, målgraf)

• Målvärdering (klassificering) Målvärderingsdokument


• Målbestämning

(nya, framtida mål, tips, idéer) Mållista framtid

• klargöra och beskriva nuvarande verksamheter
• studera arbetsuppgifter och ansvar
• klargöra problem, mål och åtgärder
• studera outnyttjade möjligheter
  

• Analys av verksamhetsstruktur verksamhetsområdesdokument handlingsgrafer


• Egenskapsanalys (Hur många, hur ofta, hur mycket?) egenskapsdokument.


• Ansvarsanalys (Vilka arbetsuppgifter utförs/skall utföras av vem?)

En genomförd behovsanalys skall ge svar på frågan: Vilka behov är så angelägna att vi skall arbeta vidare med FA för att finna åtgärder som tillgodoser dessa behov?

• fastställa genuina behov av att förändra (komma över tröskeln, vilja, entusiasm)


• analysera den totala problemsituationen


• skapa visioner för framtiden


• formulera välgrundade behov

• Problemvärdering

(problem överensstämma med mål), problemstatus grundat på problemgrafer, mållista-framtid, målgrafer-framtid, (sålla, begränsa)

• Analys av styrka och möjligheter

(nu, i framtiden, inom/utom organisationen) styrke/möjlighetsdokument
(Det finns alltid ngt bra, positivt i verksamheten, trots problem)

• Formulering av förändringsbehov

(vad som skall förändras behovslista)

• fastställa lämpliga åtgärder för bästa problemlösning
• utveckla idéer och visioner
• prognostisera effekter
• värdera lösningar
• Generera en bra och total problemlösning

• Skapande av förändringsåtgärder

(kartlägga vilka problem som ska åtgärdas, åtgärdslista, åtgärdsbeskrivning kreativitet, initiativ)

• Åtgärdsvärdering

(bedöm och klassificera åtgärderna, värdering ur olika aspekter, genomförbarhetsdokument)

• Val av åtgärdsalternativ beslutsprotokoll, beslutsunderlag.

(Rekonstruera ett motiv för åtgärdsprogram, som är en kombination av komplexa problemlösningar, prioriterat, kompromissat, och valt.)

Genom att ta hjälp av analysen kan man systemera framtiden. Det finns flera olika sätt att utföra en förändringsanalys. När ett arbetsresultat är klart granskar man det kritiskt och man kan på så sätt följa upp utvecklingen av programmet. Man försöker hitta så många fel som möjligt i ett tänkt program eller ett redan befintligt program som skall uppgraderas eller göras mer användarvänligt.

Arbetet genomförs med personalen som ska utnyttja programmet vilket på så sätt medför att system och organisation utvecklas parallellt med varandra. Genom att ta hänsyn till personalens önskemål och behov vid genomförandet ökar personalens motivation och kunskap i takt med att systemet utvecklas. Detta ger en positiv inställning till det nya systemet. I samband med implementeringen av systemet skulle man även kunna ge möjligheter till utbildning för att öka motivationen ännu mer. En glad personal jobbar bättre och effektivare.

Man bör alltså ifrågasätta och utveckla idéer med en viss metodik. De olika utvärderingsmetoder som finns har som nämnts vissa brister, men kombinerar man dem kan dessa brister i alla fall delvis undvikas. Och att använda en mindre bra utvärderingsmetod är bättre än att inte använda någon alls. Ett bra sätt är att hitta banden som binder samman målen med problemen och vise versa för att strukturera upp företagets verksamhet på ett lättöverskådligt sätt. Detta kan till exempel ske genom uppritande av grafer. Den bör då ge en övergripande bild av programmets funktioner och innehåll, liksom beskrivning av den tekniska lösningen. På ett sådant sätt blir det väldigt enkelt att "nysta ihop garnet" om problem uppstår.

Alla anmärkningar ska dokumenteras och man ser till att de åtgärdas, varefter man fastställer dokumenten. Granskningarna man genomför är hela tiden till för att förbättra kvaliteten hos resultatet man uppnår.

Under analysen tar man reda på och fastställer kraven på den blivande produkten. Konsulten skriver en s.k. kravspecifikation och personalen på företaget som skall köpa och framförallt använda produkten går igenom den skrivna specifikationen väldigt kritiskt. I och med detta gör man klart för sig själv och konsulten vad man verkligen behöver och vill ha. Kraven dokumenteras sedan i en kravspecifikation. Efter att ha godkänt kravspecifikationen genom noggrann kontroll av kompetent personal går man vidare i analysen. Kravspecifikationen är inte klar förrän konsultens rapport blivit kontrollerad av personalen/beställaren och denne/denna tycker att den stämmer överens med hur kraven och uppfattningen av programmet beskrivs. Man skulle kunna säga att man sätter ramar för hur produkten ska se ut och vad den får lov att kosta. Man arbetar därefter med specifikationen som ram. Denna utgör en form av avtal i detta skick. Programutvecklaren måste på så vis följa dessa ramar och tillgodose beställarens krav.

Den allmänt mest accepterade och använda modellen för programutveckling är den s.k. livscykelmodellen, som består av ett antal faser som börjar med planering och slutar med underhåll av programvaran.

Kravanalys involverar utförande av marknadsundersökningar samt identifiering och utvärdering av kundkrav. Därefter sker en kravdefinition som bygger på kravanalysen. Informationen definieras här mer detaljerat för att kunna användas i den fortsatta programutvecklingen. Resultatet av detta steg är en kravspecifikation, som innehåller de krav som programmet förväntas uppfylla. När kravspecifikationen är klar kan designfasen påbörjas, där den övergripande arkitekturen för programmet definieras, vilket resulterar i en designspecifikation. Nästa steg är själva kodningen av programmet, som är själva implementationen av designspecifikationen. Här påbörjas en viss testning i och med att programmeraren själv kontrollerar sina egna programrutiner. Enligt livscykelmodellen påbörjas sedan den egentliga testningsfasen. Testningen sker utifrån en testplan, som baseras på information från kravspecifikationen och designspecifikationen. Målet med testningen är att kontrollera att mjukvaran uppfyller de krav som angivits. Då testningen är klar och programmet blivit lanserat, vidtar underhållsfasen som sträcker sig till dess att supporttiden för programmet gått ut. I samtliga faser av livscykelmodellen skall dokumentation och granskningar av resultat ske.

Livscykelmodellen kan ha långtgående konsekvenser som sträcker sig avsevärt bortom själva programutvecklingen - livslängden på en typisk mjukvaruprodukt kan sträcka sig från två till fem gånger utvecklingstidens längd. Att kunna ge ett kostnadseffektivt underhåll är direkt relaterat till vilken mjukvaruutvecklingsmetod som används (Rakitin, "Software Verification and Validation", 1997).

Ian Sommerville förklarar i sin bok "Software Engineering" (1992) att testning består av verifiering & validering (V&V). V & V är en allmän term som syftar till att kontrollera om mjukvaran möter upp till de ställda kraven på produkten och att dessa krav motsvarar behoven hos den tänkta kunden. V & V bör enligt Sommerville ingå i hela livscykelprocessen, som en del i alla faser inklusive planeringsfaserna och bör ha två mål; dels att upptäcka defekter i mjukvaran, dels att bedöma om mjukvaran är användbar ur användarsynpunkt. Verifiering betyder att man kontrollerar om programmet följer uppsatta specifikationer, validering innebär att man kontrollerar om programmet möter användarens förväntningar. Vi avser inte att använda dessa termer i fortsättningen, då termerna lätt kan blandas samman och skapa förvirring, speciellt vid översättning från engelska till svenska.