7. Revisionslista

8. Litteratur
 
 
 
 

1. Inledning

Sharktech information valde som fördjupningsuppgift under projektuppgift 2a, att presentera kapitel 29, 30 och 31 ur Software Engeneering (Sommerville 95). Kapitel 29 behandlar kostnadsuppskattning, kapitel 30 handlar om kvalitet och kapitel 31 behandlar processförbättring.

Gemensamt för alla kapitel är kampen om att få kunder. Med kostnadsuppskattning försöker man sälja produkten (program) med det bästa priset till så mycket kunder som man kan. Kvalitet är något som är ett klart val för alla företag och något som man ständigt måste ta hänsyn till. Samma sak gäller processförbättring då man ständigt måste leta efter förbättringar i produktionen. Detta gäller också för tjänsteföretag.

Med några exempel som underlättar förståelse av det väsentligaste i våra kapitel försöker vi visa hur viktigt det som vi presenterar är.
 
 

2. Kostnadsuppskattning

När man planerar ett projekt delar man upp projektet i ett antal olika delar. Sen uppskattar man hur mycket arbete och tid varje del tar. Projektledaren måste uppskatta följande tre frågor.
 

Man tar fram projektets kostnadsuppskattning och tidsuppskattning samtidigt. Kostnadsuppskattning måste göras i början. Dessa uppskattningar är nödvändiga för att man ska kunna göra en budget för projektet så att man kan sätta ett pris till kunden. Kravdefinition med få detaljer och kanske nya datorer och utvecklingsverktyg. Känner inte till hur skickliga programmerarna är.

När ett projekt pågår bör man uppdatera kostnads och tidsuppskattningen hela tiden. Det här hjälper till vid planeringsprocessen och möjliggör en effektivare användning av resurserna. Om man upptäcker att kostnaden överstiger kostnadsuppskattningen på någon punkt måste projektledaren agera. Kanske kan han ansöka om ytterligare resurser om arbetet.

De kostnader som ingår i ett projekt är inte bara löner till programmerarna utan även en mängd andra kostnader. Här följer några exempel.
 

Ofta arbetar man ju för en större organisation som sköter alla övriga kostnader. Dessa kostnader brukar uppgå till ungefär dubbelt så mycket som programmerarnas löner. Om man har tre anställda ingenjörer med 20 tusen var i månaden blir lönekostnaden över 700 tusen per år, men de totala kostnaderna kan ligga på över 2 miljoner kronor per år.

2.1 Prissättning

Ofta sätter man ju ett pris till kunden vad programmet ska kosta. Man kan då tänka sig att man tar det priset som man uppskattar att programmet ska kosta och sedan lägger på en viss procent som vinst, men riktigt så enkelt är det inte. Här är några andra faktorer som också spelar in.
 

2.2 Produktivitet

Man kan mäta produktiviteten genom att dela antalet färdiga enheter med antalet timmar. Detta är inte alltid så meningsfullt. Två andra sätt:

Storleksrelaterad mätning: Tittar på antal rader kod. Det vanligaste är att man mäter antalet rader per månad. Under den tiden ska man också göra analys, design, testning och dokumentation. Det var lättare att räkna antalet rader förr när man använde fortran och Cobol. När man skriver i Java eller C++ lägger man ju ibland in kommentarer, och ibland kan en instruktion ta flera rader. Det finns räknesystem som bara räknar de exekverbara raderna. Så länge man använder samma system hela tiden spelar det inte så stor roll vilket system man använder. Man kan inte jämföra olika programmerings språk eftersom lågnivå språk ger mycket fler rader.

Funktionsrelaterad mätning: Hur många användbara funktioner som produceras på en viss tid. En stor fördel är att den är språkoberoende. Den mest kända metoden är funktionspunkts metoden. Det totala antalet funktionspunkter kommer man fram till genom att titta på vilka typer av funktioner det finns. Var och en av dessa får sedan ett värde mellan 3 och 15 beroende på deras komplexitet. Det slutgiltiga värdet fås genom att multiplicera värdet av varje typ med antalet funktioner av den typen och sedan addera dessa. Problemet är att funktionspunkterna kommer att bero mycket på uppskattarens bedömning.

Man kan kombinera dessa två metoder. Man multiplicerar då funktionspunkterna med det genomsnittliga antalet rader. Varje enskild persons produktivitet påverkas också av många faktorer. Personens skicklighet har störst betydelse. I undersökningar har det visat sig att en programmerare kan vara tio gånger mer produktiv än en annan. Detta har störst betydelse när man är få personer.

Problemet med de här sätten att mäta är att det inte tar någon hänsyn till icke funktionella delar. Det är ju egentligen viktigare att mäta funktionaliteten och kvalitén än storleken. Det här blir ett praktiskt problem om arbetsgivaren använder produktiviteten som ett mått för att bedöma programmerarna.

2.3 Utvärderingstekniker

Det kan vara svårt att göra en utvärdering i början eftersom man kanske bara har en kravdefinition med få detaljer, kanske nya datorer och utvecklingsverktyg och man kanske ännu inte känner till hur duktiga programmerarna är. Det är inte så bra att bara göra en storleksuppskattning och sedan en kostnadsuppskattning utifrån det eftersom storleksuppskattningen ofta är fel. Det finns fem olika metoder.
 

Den sista metoden verkar omoralisk och icke affärsmässig, men den används ändå ganska mycket vid mindre projekt eftersom det är dyrt att göra en omfattande kostnadsuppskattning. Det som är viktigast för att kunna göra en bra bedömning är att man har mycket erfarenhet, helst mer än sex år.

2.4 Algoritmisk kostnadsmodell

Det är den mest systematiska men inte nödvändigtvis den mest korrekta modellen. Man gör en matematisk formel som ser ut så här:

Arbetet = C * PMˆs * M

C = komplexitetsfaktor PM = storleks eller funktionalitetsfaktor. M = faktor för olika process, produkts och utvecklingsverktyg. S är en exponent som är lite större än ett och visar att kostnaden inte ökat linjärt utan något snabbare. Detta beror på att för ett stort projekt blir hela organisationen mer komplex, kommunikationssvårigheterna ökar och man måste ha fler samordnare.

Det har gjorts en undersökning där man jämförde 4 olika modeller bl.a. Cocomo-modellen som vi kommer att diskutera senare. Man fann väldigt stora variationer. Resultaten blev mellan 230 person månader och 3857 person månader för samma projekt.

Man bör ta fram flera olika uppskattningar så att man förutom den förväntade kostnaden även har en bästafalls och en värstafalls uppskattning. Ofta måste man också göra andra bedömningar. Kommer vi att tjäna på att köpa in det här utvecklingsverktyget eller nya datorer? Hur många och vilka ska vi anställa. Det går inte att gör att program jättesnabbt med jättemycket personal. Det viktigaste är att ha olika typer av personal som kan komplettera varandra.

2.5 COCOMO-modellen

Detta är en algoritmisk kostnadsmodell där man alltså använder en matematisk formel. Den ser ut så här:

PM = C * KDSI ^ e * M

PM är ett mått på projektets omfattning. C betecknar komplexiteten och brukar ha ett värde kring tre. KSDI är antal tusen leveras instruktioner. E är en exponent son är något större än ett och även den är beroende av komplexiteten.

Det finns tre olika nivåer av modellen. I första nivån tittar man bara på storleken och vilken typ som utvecklas. In nästa stadium tar man även hänsyn till en del andra faktorer. Alla faktorerna får ett värde kring ett beroende på om dom ökar eller minska arbetet. Faktorerna brukar vara mått på följande attribut:
 

I komplett Cocomo räknar man kostnaden på varje subsystem. Man bör alltid ta hänsyn till lokala omständigheter. Ibland kan det vara relevant att lägga ihop två attribut och ibland kan man lägga till några.

2.6 Projektets omfattning

Pojektledaren måste bedöma vem man ska anställa, när de ska anställas och vad var och en ska jobba med. Förhållandet mellan antalet anställda och den totala arbetsinsatsen är inte linjärt. Det går inte dubbelt så snabbt att göra ett projekt med 60 anställda som med 30 eftersom det kommer att gå åt mycket mer tid till samordning och kommunikation om man är många anställda.

I COCOMO modellen finns en formel för att beräkna hur lång tid (TDEV) ett projekt tar. Detta beror på vilken typ a projekt det är. Formeln är:

TDEV = 2,5 (PM) ^ e

där e är ett tal runt 0,35. Vanligen mellan 0,32 och 0,38. E får ett högre värde för lättare projekt och ett lägre värde för mer komplicerade projekt.

Vi ska nu visa hur vi kan räkna ut hur lång tid ett projekt ska ta. Vi sätter då först in värden i formeln som vi visat tidigare. Låt säga att vi har ett ganska enkelt projekt. Vi kan då sätta C till 2,4 och e till 1,05. Storleken är beräknad till 32 000 instruktioner. Detta ger:

PM = 2,4 (32)^1,05 = 91 p.m

Vi vill nu beräkna hur lång tid projektet ska ta. Eftersom projektet är relativt enkelt använder vi formeln:

TDEV = 2,5 (PM)^ 0,38 => 2,5 (91) ^ 0,38 =14 månader
 
 

3. Kvalitet

3.1 Kvalitets säkring

Kvalitets säkring berättar hur en organisation ska få kvalitet och hjälper företaget att välja en standard som ska användas när man skapar programvaran.

En internationell standard som kan användas för att skapa kvalité är ISO 9000. ISO 9000 är generell och tar bland annat upp hur man ska behandla:
 

ISO 9000 inte går in på detaljer vilket betyder att den inte är industrispecifik. Fler och fler kunder söker sig till ISO 9000 certifierade företag för att vara säkra på att företaget tar kvalité på allvar.

3.2 Processens kvalitets säkring

Sambandet mellan produkt och produktion är starkt i industrin. Där är det lätt att standardisera och övervaka.
 
 

När man väl har kalibrerat systemet så kan hög kvalité produceras om och om igen.

Denna model fungerar ej i programvaruprocessen. Programvaran är inte producerad utan designad. Programvaruproduktionen är en kreativ process som är starkt beroende av individuell skicklighet och erfarenhet.

För att säkra processens kvalité måste man :
 

En fara med processbaserad kvalitets säkring kan vara att den förbestämda processen inte passar programvaran. Till exempel så kan kvalitetsstandarden säga att specifikationen ska vara klar och godkänd innan implementationen påbörjas. Men vissa program kan kräva att man implementerar en prototyp. Det finns då risk för att kvalitetsgruppen hindrar detta eftersom processen blir svår att övervaka. Om detta inträffar så måste en erfaren person ingripa och se till att kvalitets processen gynnar istället för hindrar produktionen.

3.3 Kvalitets granskning

Granskning är det huvudsakliga sättet man godkänner processer eller produkter på. Den valda gruppen undersöker delar av eller hela programvaruprocessen och de tillhörande dokumenten för att hitta potentiella problem. Resultatet av granskningen noteras för att författaren eller den som är ansvarig för dokumenten ska kunna rätta till problemen.

Granskningsgruppen ska inte vara för stor 3-4 personer. Dessa personer ska ha god kunskap i systemet, t.ex. om ett undersystem ska granskas så är det bra om granskningsgruppen består av personer som designar huvudsystemet.

Själva granskningen ska högst ta 2 timmar. Om det är möjligt så ska författaren av dokumentet gå igenom dokumentet med granskningsgruppen.

Man ska ta hänsyn till alla kommentarer vilka ska vara under följande tre kategorier:
 

3.4 Programvarustandarder

En av de viktigaste rollerna kvalitetssäkrings gruppen har är att skapa en produkt och process standard. Ett exempel på produktstandard är granskningsformen som definierar hur informationen ska fås under granskningen. Ett exempel på process standard är hur en fortlöpande definition av en design ska vara organiserad.

Kvalitetssäkrings gruppen som skapar standarden bör normalt basera denna på en nationell eller internationell standard. Med denna ska de skapa en handbok som ska definiera de standarder som är lämpliga för deras organisation. Exempel på sådana standarder följer nedan.

Produkt standarder:
 

Process standarder:
 

3.5 Dokumentations standarder

Dokumentstandarden i ett programvaruprojekt är speciellt viktigt eftersom det är det ända verkliga sättet att representera programvaran och programvaruprocessen. Det finns tre typer av dokumentations standarder:

3.5.1 Dokumentations processens standard

De här standarderna definierar processen som ska följas vid skapandet av dokumenten. För arbetspapper och anteckningar behovs det ingen kvalitets kontroll. Men när dokument blir formella eller utgivna till kunden så ska kvaliteten på dokumenten ha blivit kontrollerade.

3.5.2 Dokument standarder

Standarder som styr själva dokumenten. Dokuments standarderna gäller för alla dokumenten i programmet och berör områden som sidnumrering, sidhuvud, typsnitt och logotyper. Alla dokumenten ska ha samma struktur och de ska vara lätta att känna igen. Ändringar i dokumenten ska reflektera ändringar i systemet.

3.5.3 Dokumentutbytes standarder

Det är viktigt att ett utbyte av dokument sker via e-post och att dokumenten lagras i en databas. För att allas dokument ska se lika ut så utbytes ett standardformat. Men det kan bli problem mellan olika ordbehandlings program eftersom de inte alltid representerar formatet exakt lika. Lösningen på detta problemet är att använda sig av ett format som set likadant ut på alla datorsystem. Exempel på dessa är SGML, RTF och Adobe Acrobat.

3.6 Programvarans mått

Ett programvarumått är vilken typ av mätning som helst som kan relateras till programvarusystemet.

Hittills har mått på program använts relativt lite i programvaruindustrin. Men medvetandet om dess viktiga roll i kvalitetsförbättringen ökar. Flera stora företag samlar in data för att kunna förbättra processen. Störst fokus har lagts på insamlingen av data som berör programdefekter och granskningsmetoden.

3.6.1 Data insamling

Programvarumåtten måste kalibreras så att de speglar det karakteristiska med den individuella organisationen. Tre typer av automatiserad data insamling kan identifieras:
 

Den verkliga kostnaden av data insamlingen kan variera från organisation till organisation beroende på hur mycket data som samlas in. Men vanligen så är det bara liten del av den totala kostnaden.

Det är viktigt att man sparar på gammal data även om den inte längre används. För när man väl har fått en stor databas över gamla projekt, först då kan man jämföra projekten.

3.6.2 Analysen av mätningen

Det kan vara svårt att förstå vad datan om programvaran verkligen betyder. Om man hittar en anledning till att ändra på något i programvaran så måste detta dokumenteras. Om klagomålen på en produkt har minska i jämförelse med en tidigare produkt så kan detta betyda att företaget har blivit bättre på kvalitet. Men det kan också betyda att fler och fler användare har bytt till en konkurrents produkt. Antalet klagomål har minskat för att antalet användare också har minskat, detta är något man måste ta hänsyn till vid granskningen av datan.

3.7 Produktens kvalitetsmått

3.7.1 Design kvalitetsmått

Det finns ett antal olika attribut på designens kvalitetsmått, förutom korrektheten finns även underhåller av designen. Det går inte att mäta underhållet i sig själv, men det finns saker som underhållet är relaterat till.
 

För att beräkna komplexiteten på en komponent så kan man använda följande formel:

Komplexiteten = Längden * (Fan-in * Fan-out)²

Längden är måttet på antal rader komponenten har.

Fan-in är antalet andra komponenter som anropar denna komponenten.

Fan-out är antalet andra komponenter denna komponent använder.

3.7.2 Programmets kvalitetsmått

Kvalitén för program betraktas på liknande sätt som för design uppskattning. Program ska inte vara defekta och de ska vara fria från underhåll. Detta är svårt att eller rentav omöjligt. Men det finns sätt att mäta komplexiteten så att man kan minimera felen i programmen.
 

Kvaliteten på dokumentationen som tillhör en programvara är lika viktig som själva programvaran. Det kanske mest kända sättet att mäta dokumenten på är med hjälp av Gunnings Fog index som mäter läsbarheten på dokumentet. Den baserar dig på längden på meningar och antal svåra ord.
 

4. Processförbättring

Det finns en stark koppling mellan en programvaras kvalitet och kvalitén i dess utvecklingsprocess. Produktkvalitet kan bara uppnås om man använder en lämplig utvecklingsprocess för den programvara som ska utvecklas.

Processförbättring innebär att man försöker kartlägga den existerande processen och förändra denna så att produktkvaliten förbättras och/eller kostnader och utvecklingstiden minskas. Processförbättring betyder dock inte att man bara applicerar vissa standardiserade metoder eller verktyg som har använts i andra liknande projekt. Det fungerar oftast inte i praktiken. Det finns alltid lokala organisationsberoende faktorer, procedurer och standarder som påverkar processen.
 
 

4.1 Modell för processförbättring

En generell modell för processförbättring kan beskrivas enligt följande figur:

Nyckelstadier i processförbättringsprocessen:

1. Processanalys
Undersökning och kartläggning av den existerande processen, framställning av en processmodell. Ska leda till bättre förståelse för processen.
Kompletterande processmätningar i samband med analysen ger underlag till en mer objektiv bedömning av förändringar som senare införs.

2. Identifikation av förbättringsområden
Man använder resultaten från processanalysen för att identifiera flaskhalsar som påverkar kvalitet, schema och kostnader negativt.

3. Introduktion av processförändringar
Innebär att man inför nya procedurer, metoder och verktyg i syfte att eliminera flaskhalsar. Integration av nya procedurer etc. bör få ta tid.

4. Träning
Mycket viktigt. Utan träning av personalen riskeras hela processförändringen att misslyckas hur väl genomtänkt och riktig den än kan ha varit.

5. Förfining
Processförändringar blir aldrig fullkomliga direkt efter införandet. En period av förfining av förändringar krävs därför.

Det är inte lämpligt att införa för många ändringar på samma gång eftersom det då blir svårt att identifiera en specifik ändrings effekter. Det kan också vara svårt att hitta alla förbättringsområden under en enda processanalys. Därför bör processförbättringen vara en procedur som upprepas.
 

4.2 Sambandet process/produktkvalitet

Idén om processförbättring baseras på ett antagande om att produktutvecklingsprocessens kvalitet är direkt avgörande för slutproduktens kvalitet.

Inom tillverkningsindustrin är process/produkt-relationen väldigt tydlig. Detta förhållande är mindre tydligt för produkter som inte är så påtagliga och är beroende av någon intellektuell process som inte kan automatiseras.

Mjukvarukvalitet beror inte på en konkret tillverkningsprocess utan mer på en designprocess där den mänskliga faktorn är betydelsefull.

För mjukvara (och även andra intellektuella produkter, tex böcker, filmer) finns det fyra faktorer som påverkar produktkvaliten mest:
 

För större projekt är antagligen processen den mest avgörande för kvalitet. Man har problem med integration, projektstyrning och kommunikation. Om man då följer en strikt processmodell så kan man ofta göra stora effektivitetsvinster.

I mindre projekt blir de inblandades skicklighet viktigare eftersom man inte får några större problem med integration och kommunikation.

I små projekt är även utvecklingsverktygen viktiga eftersom man ägnar mer tid åt utveckling än åt administration. I större projekt gäller det omvända förhållandet och därmed är inte utvecklingsteknologin lika viktig.

Avgörande för produktkvalitet oavsett projektstorlek är kostnad, tid och planering. Underbudgetering och orealistiska utvecklingsplaner resulterar oundvikligen i sämre kvalitet. Det är ett vanligt problem idag. Många företag tummar medvetet på den punkten för att kunna vinna kontrakt.

4.3 Processanalys och modellering

Processanalys involverar att studera den existerande processen och utveckla en abstrakt modell som kartlägger processens nyckelegenskaper. Man vill även förstå hur olika delar av processen är relaterade. Resultatet av en processanalys är en processmodell.

Formella processmodeller som fastlagts av företaget, är ofta en bra utgångspunkt för processanalys. Formella modeller definierar dock bara huvudsakliga processaktiviteter och resultatpunkter och räcker inte som underlag för processförbättring. Den process som i verkligheten nyttjas skiljer sig ofta betydligt från den formella modellen.

Två olika processanalysmetoder:

Utfrågningar och intervjuer (av utvecklare och inblandade)
Fördel: kan göras snabbt och under en kort period
Nackdel1: svårt att formulera rätt frågor
Nackdel2: intervjuoffren lämnar inte sin uppriktiga uppfattning om processen som används

Etnografiska studier
Att genom extern observation försöka förstå programvaruutveckling som en mänsklig aktivitet.
Fördel 1: ger en mer djupgående förståelse för processen
Fördel 2: resultatet blir sannolikt en mer rättvisande modell
Nackdel : blir ofta utdragen och kostsam

Om det är väldigt viktigt att processmodellen är detaljerad och verklighetstrogen så bör metod 2 användas. För metod 1 finns alltid en risk att en felaktig modell härleds pga svårigheterna med frågeställningen.

Vilken information kan vara lämpligt att ta med i en processmodell?

Aktiviteter - En aktivitet har ett tydligt definierat mål, förtillstånd och eftertillstånd. Exempel är att preparera testdata för en modul, att koda en funktion.

Processer - En process är en mängd aktiviteter som har någon form av sammanhang. Exempel är kravanalys, testplannering.

Resultat - Något som är mer konkret och som förutsagts levereras enligt en projektplan. Exempel är kravdokumentation, en programprototyp.

Tillstånd - Förtillstånd eller eftertillstånd. Något som ska gälla före eller efter en aktivitet.

Roller - En roll är knuten till ett ansvarsområde. Exempel: testutvecklare, mjukvarudesigner.

Kommunikation - Utbyte av information. Exempel: Godkännande av ett resultatdokument från en projektledare.
 

Här följer ett exempel på en processmodell som beskriver testning av en modul:

Processen modultestning delas in i ett antal aktiviteter. T.ex. att preparera testdata, testexekvering och testrapportering. Timing och beroenden mellan aktiviteter, resultat och kommunikationer bör även kunna utläsas i en processmodell. Följande figur visar hur ovan nämnda aktiviteter beror av varandra.

4.4 Processmätning

Processmått är kvantitativa data om en mjukvaruprocess. De kan användas för att bedöma om effektiviteten hos en process har ändrats till följd av exempelvis en processförändring. I viss mån kan man även bedöma huruvida produktkvaliten har förändrats genom processmätning.

Det finns tre huvudtyper av processmått:
 

De första två är nog bäst lämpade för att mäta effektiviteten i en process. Man kan tex komma fram till att man behöver förbättra kravanalysarbetet om man märker att det kräver särskilt många kundkontakter och mycket resekostnader.

Det är oftast svårt att kvantitativt bedöma om en mjukvaras kvalitet har förändrats. Metoden i punkt tre ovan kan dock användas för att mäta förändringar i mjukvarukvalite. Ökat antal fel som upptäcks under programinspektion kan ge en vink om att inspektionsprocessen har förbättrats och att man även kan förvänta sig en bättre program kvalitet.

4.5 SEI processmognadsmodell

The Software Engineering Institute (SEI) vid Carnegie-Mellon universitetet är finansierat av det amerikanska försvarsdepartementet. Det upprättades för att förbättra förmågan att utveckla kvalitativa produkter inom den amerikanska mjukvaruindustrin. I synnerhet hos företag som skriver kontrakt med US DoD (US Department of Defense).

Ett resultat av SEI's arbete är den sk SEI Software Capability Maturity Model. Översatt till svenska skulle det bli något i stil med "SEI's skicklighetsmognadsmodell". Det låter lite löjligt och är dessutom en något missvisande översättning. I fortsättningen skriver jag därför SEI-CMM när jag refererar till denna "processmognadsmodell".

SEI-CMM har i vid utsträckning använts för att bedöma en organisations förmåga att utveckla hög-kvalitativ programvara.

SEI-CMM delas in i 5 nivåer vilka var och en representerar ett stadium i ett mjukvaruprojekts utveckling mot en maximalt effektiv och kvalitetsäkrande organisation. De fem nivåerna är följande:

1. ("den initiala nivån")

Karaktäristiska:
 

2. ("upprepningsbara nivån")

Karaktäristiska:
 

3. ("den definierade nivån")

Karaktäristiska:
 

4. ("den styrda nivån")

Karaktäristiska:
 

5. ("den optimerande nivån")

Karaktäristiska:
 

SEI-CMM är viktig men den bör inte tas på fullt allvar. Det finns nämligen tre allvarliga problem med SEI-modellen:

1. Den fokuserar uteslutande på projektledning och berör inte själva produktutvecklingen så mycket. T.ex. tas ingen hänsyn till om organisationen använder någon speciell teknik såsom utveckling genom prototypframtagning, verktyg för statisk analys osv.

2. Den utesluter riskanalys som en nyckelaktivitet i mjukvaruprocessen trots att det är en mycket viktig del av mjukvaruutvecklingen.

3. Den är inte lämplig för att bedöma små organisationer som utvecklar mindre system.

Anledningen till dessa problem är förmodligen att SEI springer amerikanska försvarsdepartementets ärenden. Eftersom de projekt som US DoD driver är av en viss karaktär så är SEI modellen bäst lämpad för att bedöma stora organisationer som utvecklar stora system med lång livslängd och komplexa gränssnitt mot hårdvara och andra mjukvarusystem.

4.5.1 Skicklighetsbedömning

Skicklighetsbedömning (capability assessment) i praktiken baseras på enkätundersökning som designas för att identifiera nyckelprocesserna i en organisation. Detta görs under ett utvärderingsbesök då även projektledare från ett antal olika projekt inom organisationen intervjuas. Efter diskussion kring responsen på undersökningen når man ett utvärderingsresultat.

Denna utvärdeingsprocess är mycket omstridd, vilket visar på hur omoget området skicklighetsbedömning fortfarande är.

4.6 Processklassificering

I SEI-modellen försöker man klassificera processer i ett system med nivåer med ganska godtycklig gränsdragning mellan nivåerna. Den har inbyggda problem som gör den olämplig för processklassificering i vissa situationer. Ian Sommerville tror att en mer generell approach kan göras inom processklassificering och att man därigenom kan täcka in ett större spektra av organisationer och projekt.

Följande klassificeringsmodell presenteras som ett alternativ till SEI-modellen.

Olika typer av processer kan identifieras:

1. Informella processer
Det är processer som inte har en strikt och fördefinierad processmodell. Utvecklingsteamet väljer själv vilken process som ska användas.

2. Styrda processer
Det är processer som har en definierad processmodell.

3. Metodiska processer
Det är processer som har någon definierad utvecklingsmetod (t.ex. Booch's metod för objektorienterad design).

4. Förbättrande processer
Dessa har en specifik budget för processförbättring och procedurer för att introducera förbättringar.

Det är tydligt att dessa klassificeringar överlappar varandra och att en process kan identifieras med flera av klasserna.

Den här klassificeringsmodellen kan tjäna som grund för multidimensionell processförbättring. Dels kan den hjälpa en organisation att välja rätt typ av process för olika typer av produkter, vilket figur 31.9 på sid 653 i Sommerville, Software Engineering visar. Dels kan den vara till hjälp vid val av utvecklingsverktyg enligt figur 31.10 på sid 654 i samma bok.
 

5. Sammanfattning och exempel

5.1. Exempel 1

Vad är kvalitet?

Det finns flera definitioner om kvalitet men de flesta författarna som skrev böcker om kvalitet har inget emot följande definition.

Kvalitet är en produkts förmåga att tillfredsställa kundens krav, behov och förväntningar.

Nu förklarar jag definition med ett exempel med bilar. I bilbranschen är kvalitet inte enbart förunnat märken som Mercedes. Det är viktigt att säga att kvalitet angår alla!

Definitionen innebär att en Skoda kan ha bättre kvalitet en Mercedes. Eftersom det är kundens krav, behov och förväntningar som avgör, vilka troligen skiljer sig åt mellan en Skoda och Mercedesköpare. Antag att Skodan uppfyller kundens förväntningar, medan Mercedeskundens (högre?) förväntningar inte infrias. I så fall har enligt definition Skoda en högre kvalitet.

Vilken kund blir märkestrogen?

5.2. Exempel 2

Exempel 2 har som idé att visa att man med hög kvalitet kan tjäna stora pengar.

En taxi förare i New York som har en stor vit taxibil (en limousine ) har kommit på idé att behålla samma pris som andra taxi bilar och samt erbjuda en del extra tjänster för kunder. Med denna processförbättring förväntade han sig mer i dricks. I den minst sagt komfortabla bilen bjuder han på mobiltelefon samtal, tidningar och frukt. Med allt detta förväntade han sig att kunderna ger honom mer i dricks.

Till slut visade det sig att med de ändringarna han tjänade 20000 till 30000 dollar per år.

5.3. Exempel 3

Följande exempel ligger någonstans mellan processförbättring och fusk.

Några unga killar från Göteborg äger ett datorföretag. De har en del kunder men tänker öka försäljningen och få så många " trogna kunder" som möjligt. De kom på en idé att erbjuda en månad hemsupport, d.v.s. under första månaden fixar de problem direkt på platsen (hemma hos kunden). De ökade priset på datorer med en summa som täcker en timmes arbete och en viss kostnad för en kortare bilresa.

Förutom detta så vände de medvetet på en kontakt inne i datorn för att den inte skulle fungera. Kunden köper datorn , kommer hem och försöker att starta datorn.

Det går inte!

Kunden blir besviken men eftersom han har hemsupport ringer han direkt till företaget. Samma trevliga kille som sålde datorn svarar igen och säger att det är inget problem och att någon kommer direkt. ( Killen förväntade sig samtalet. ) Efter en halvtimme kommer den snälla killen hem till kunden och fixar felet på någon minut. ( Han viste om felet ! )

Vad tror kunden då?

Han får en känsla av att företaget verkligen satsar på sina kunder. De kom direkt. De är kunniga eftersom de fixade felet på nolltid. Kunderna blir verkligen " trogna kunder ", d.v.s. vid nästa tillfälle väljer de samma företag. Försäljning och vinst för företaget ökade kraftigt.
 

6. Ordlista

RTF Rich Text Format

SEI Software Engineering Institute

SGML Standard Generalized Mark-up Language.
 
 

7. Revisionslista

Version 1.0 Edvard Boras, Erik Thorbert, Erika Oknelid, Daniel Påhlstorp 28 april 1999. Orginalversion.

Version 1.1 Edvard Boras, Erik Thorbert, Erika Oknelid,Daniel Påhlstorp 28 april 1999. Reviderad version. Tillägg av kapitel samt en del andra förändringar.