Improving Processes

1. Improving Processes Gruppe 9 Skule NotøPer Ivar JacobsenØystein RogstadAlfred SkariPer Kristian FørrisdalAnnette KjuusSynne Nygaard

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

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

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

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

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

7. Is Capability Maturity holding NASA Back • Software tilNASA’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

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

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

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

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

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

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

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

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

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

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