Improving Processes Gruppe 9 Skule Notø Per Ivar Jacobsen Øystein Rogstad Alfred Skari Per Kristian Førrisdal Annette Kjuus Synne Nygaard

Process and Capability Maturity Det finnes mange modeller for å bedre Maturity I utviklingsprossesen. CMM, ISO 9000 og SPICE Disse modellene og deres vurderingsmetoder har blitt standard I mange organisasjoner Men helt siden introduksjonen av disse modellene har det vært protester og skepsis mot deres iverksettelser og bruk

Bollinger og Mc Gowan pekte på mange problemer med å bruke CMM De pekte på at begrensede spørsmål fanget bare en liten del av karakteristikken av god software praksis og deres ja /nei svar gjør partisk ettergivenhet umulig å måle. De pekte også på at CMM antok et fabrikkmessig mønster for software utvikling De mente også at prosess maturity approach ikke gravde dypt nok inn i hvordan software utviklings praksis er implementert

Card(1992) rapporterte at inkonsistente resultater var oppnådd fra CMM vurderinger av den samme organisasjonen utført av forskjellige team. En annen undersøkelse gikk på hvor pålitelige slike vurderinger er De fant klare bevis på upålitelighet når det gjelder, standardisering, prosjektledelse, verktøy og organisering.

Under regi av SEI samlet (Herbsleb) inn data fra 13 organisasjoner som representerte forskjellige nivåer I capability maturity Og så deretter på forandringer i opptreden etter at prosses improvement aktiviteter var implementert.

Men i denne undersøkelsen deltok bare frivillige organisasjoner. Og det ble ikke foretatt noen undersøkelse for å bestemme hvor representativt prosjektet var. Og denne karakteristiken ser ikke på kundetilfredshet eller funksjonalitet, den tar for seg teknisk kvalitet framfor business kvalitet. Det finnes tilfeller der høy maturity faktisk begrenser business fleksibilitet

Is Capability Maturity holding NASA Back Software til NASA’s Space shuttle er laget og vedlikeholdt av en organisasjon som har blitt rangert på level 5 av CMM skalaen Software’n har vært ekstra pålitelig og er primært drevet av tabeller, og før hver oppskyting, må NASA utvikle nye datatabeller for å beskrive oppskytingen og kontrollere software’n Å utvikle nye tabeller er meget tidkrevende og kostbart, og kan også forsinke/utsette en oppskyting

Og det er mulig å bedre utviklingsprossesen og dermed korte ned på tidsforbruk og kostnad brukt på å utvikle tabeller. Men fordelen med en mer fleksibel prosess vil kanskje føre til en lavere CMM rangering Dette vil igjen føre til at systemutviklerne vegrer seg for å gjøre forandringer på prosessen. Med andre ord det er uklart om dette vil hindre eller hjelpe NASA og optimalisere prossesen.

Mange forskere mener at disse modellene hjelper oss å gjøre bedre ”hva vi allerede gjør” men tillater oss ikke noen fleksibilitet til å prøve nye ting eller å forandre teknikken. Så det er en del viktige spørsmål som må tas i betrakning ved bruken av disse prosessene og organisasjons rammeverket. Vi må forstå hvor pålitelige og gyldige målingene og modulene er, vite hvilke enheter og attributter som er blitt målt og teste sammenhengen mellom maturity scores og behaviors som maturity er antatt og produsere eller forbedre.

Eksempel 1 Fra NASA’s Software Engineering Laboratory (SEL) Det er alltid en viss risiko involvert når man skal ta i bruk en ny teknologi. Man kan derfor utforske den nye teknikken eller verktøyet utenfor det normale prosjekt miljøet – der den ikke utgjør en trussel for prosjekt målene. Slike offline – studier blir vanligvis utført som formelle, kontrollerte eksperimenter eller case studies. SEL begynner vanligvis med et lite eksperiment – der størrelsen tilsier at variablene kan kontrolleres.

Ser resultatene fra eksperimentet lovende ut, sjekker man ut om resultatene verifiseres ved hjelp av en case study på et større prosjekt. Når SEL er overbevist om at den nye teknikken er god nok for NASA, dokumenterer de erfaringene sine slik at andre også kan forstå og bruke teknologien.

Eksempel 2 Basili og Green undersøkte nøkkel prosessene ved cleanroom for å se om NASA kunne dra nytte av dem. De organiserte studiene i fem deler; - gjennomførte først 2 kontrollerte eksperimenter - deretter 3 case studies

I det første eksperimentet sammenliknet de lesing av kode med den testingen NASA vanligvis utførte. Erfaringer de gjorde seg: - leserne mente at de hadde funnet ca halvparten av feilene som var plantet i koden – noe som viste seg å være noenlunde riktig - testerne mente at de hadde funnet nærmest alle feilene – noe de ikke var i nærheten av.  Dette kan tyde på at det gir testerne en falsk trygghet å utføre en rekke tester på en kode. - leserne fant også flere av feilene, samt de fant de hurtigere.

I det andre eksperimentet sammenliknet de cleanroom med cleanroom-pluss-testing. De fant blant annet ut at: - cleanroom laget var mer effektive til å lese offline. -cleanroom-pluss-testing laget fokuserte mer på funksjonell testing enn på lesing. - cleanroom produktene var mindre kompleks, hadde mer global data og flere kommentarer. Basili og Green mener at kontrollgruppen (cleanroom- pluss-testing) ikke tok seg tid til å lære seg og bruke andre teknikker, fordi de visste de kunne støtte seg til testing.

Basili og Green gjennomførte så 3 case studies der de bygget på resultatene fra eksperimentene. For hver case study analyserte de effektene av den, og tok med seg erfaringene videre til neste case study. De forsøkte hele tiden å tilpasse metodene slik at de fungerte best mulig til NASA’s personell.

Konklusjoner Basili og Green har vist hvordan man kan bruke en kombinasjon av eksperimenter og case studies for å sammenlikne en ny teknikk med en eksisterende teknikk. De skreddersydde både teknikk og undersøkelses prosessen til organisasjonen involvert og resultatene av tidligere studie.  Altså; de modifiserte cleanroom fremgangsmåten etterhvert som de lærte hvordan deltakerene av studiet reagerte på de forskjellige cleanroom aktivitetene. De tok ibruk mer enn en type case studies slik at de kunne kontrollere så mye variasjon som mulig.

Vi kan bruke liknende studier til å vurdere cleanroom i våre egne organisasjoner, men det er da sannsynlig at vi får andre resultater. Resultater som vil reflektere de ferdigheter, behov og preferanser som finnes i vår organisasjon. Poenget er ikke at cleanroom alltid vil virke. Det er heller at vi kan få det til å virke. Vi må finne ut hvordan vi kan skreddersy det til å virke best mulig i vår organisasjon, og til hver enkelt situasjon.