Abstract-En effektiv datainsamlingsmetod för att utvärdera programvara Vious [15], [32]- [34] och följeslagare [35] dokument presenterar utvecklingsmetoder och för att studera data för programvaruutveckling och utvärderingsresultat, som erhållits från två olika softprocess beskrivs. Metoden använder målriktad datainsamling för att utvärdera metoder med avseende på de påståenden som gjorts för dem. Sådana wrevdevelopmenti wenroeints (n theestuechnues påståenden används som grund för att definiera målen för datainsamlingen, som tidigare nämnts ingick i dessa studier.) Den förteckning över frågor av intresse som skall besvaras med dataanaly metodologi som beskrivs i denna rapport utvecklades som en del av sis, definiera en uppsättning data kategorisering system, och utforma en data studier som utförs av Naval Research Laboratory (NRL) insamling form. och av NASA's Software Engineering Laboratory (SEL) [36]. De uppgifter som ska samlas in baseras på de ändringar som gjorts i programvaran Resten av detta avsnitt diskuterar motivation för data under utvecklingen och erhålls när ändringarna görs. För att säkerställa att uppgifterna är korrekta utförs validering samtidigt med céction och stheatbutes oaseful data collectione mjukvaruutveckling och datainsamling. Validering baseras på avsnitt II är en steg-för-steg-beskrivning av datainsamlingsvyerna med de personer som tillhandahåller uppgifterna. Resultat från meth-metoden. I avsnitt III beskrivs tillämpningen av odologin, vilket visar att datavalidering är en nödvändig del av förändringsdatametoden för SEL-miljön. Avsnitt IV sammanfattar insamlingen. Utan det, så mycket som 50 procent av data kan vara de lärdomar som dragits när det gäller datainsamling och dess associerronous. åtpolm, lmttosanaplcin. Genomförbarheten hos datainsamlingsmetoden visades genom problem, begränsningar och tillämpningar. tillämpa den på fem olika projekt i två olika miljöer. Ansökan visade att metoden var både genomförbar och Software Engineering Experimentation användbar. Förloppet i de flesta vetenskaper inför en Index Terms-Data insamling, datainsamling metodologi, felfråga åsikt är att få experimentell verifiering. Mjukanalys, felklassificering, programvarutekniska experiment. Tvister om krigsteknik löses sällan på det sättet. Det finns uppgifter från experiment, men de gäller sällan den fråga som skall avgöras. Det finns ett antal skäl till detta tillstånd av I. INLEDNING. Förmodligen de två viktigaste är antalet A CORDING till mytologin av datavetenskap, de potentiella förbryllande faktorer som är inblandade i programvarustudier och första datorprogram som någonsin skrivits innehöll ett fel. Kostnaden för försök att utföra kontrollerade studier i en indusError detektering och felkorrigering anses nu vara försöksmiljö som omfattar medelstora eller storskaliga system. De viktigaste kostnadsfaktorerna i mjukvaruutvecklingen [1] -[3] I stället för att försöka med kontrollerade studier har vi tagit fram en aktuell och aktuell forskning som syftar till att hitta metoder för att göra korrekta kausala analyser av programvarufel i produktionen. Forskningen omfattar bl.a. miljöer. Causal analyser är insatser för att upptäcka orsakerna krav definition [4], automatisk och halvautomatisk av fel och orsakerna till att ändringar görs i programvara. programgenerering [5], [6], funktionell specifikation [7], Sådana analyser är utformade för att ge viss inblick i den abstrakta specifikationen [8] - [11], förfarandespecifikation [12], programvaruutveckling och underhållsprocesser, bidra till att bekräfta kodspecifikation [13] [27] och språkdesign [16], [28] - [31]. Fel. Relativt få exempel på denna typ av studie finns i Ett resultat av denna forskning är att tekniker påstås vara litteraturen; några exempel är [4], [15], [32], [37], [38]. Effektivt för att förebygga fel finns i överflöd. Tyvärr har det gjorts få försök till experimentell verifiering av attribut för användbara datainsamling sådana påståenden. Syftet med detta dokument är att visa hur man ger användbara data, en datainsamling metod måste få giltiga uppgifter som kan användas både för att lära sig mer om displa vissa attribut. Eftersom en stor del av de data som är av intresse för programvaruutvecklingsprocessen och för utvärdering av programvara samlas in under testfasen, görs en fullständig analys av utvecklingsmetoderna i produktionsmiljöer. Pre-data måste invänta slutförandet av projektet. Av noggrannhetsskäl mottog den den 13 december 1982; reviderad 11 januari 1984.ismprathttadecleioanvldtonrcedoDetta arbete stöddes delvis av National Aeronautics and Space som för närvarande håller på att utvecklas. Administration enligt Grant NSF-S5123 till University of Maryland. Utvecklare kan tillhandahålla data när de gör förändringar under V. R. Basili är vid institutionen för datavetenskap, universitetets utveckling. I en relativt välkontrollerad programvara devel- både datainsamling och datavalidering är ganska viktigt för riktigheten av analysen. De projekt som studeras varierar kraftigt med hänsyn till faktorer som noggrann validering innebär att de data som ska samlas in måste som applikation, storlek, utvecklingsteam, metodologi, hårdvara, noggrant specificeras, så att de som levererar data, de vali-och support programvara. Samma grundläggande data som sammanställer data och de som utför analyserna kommer dock att ha en kontionsmetod som tillämpas överallt. Schemat använde en konsekvent bild av de insamlade uppgifterna. Detta är särskilt viktigt har sex grundläggande steg, listade i följande, med betydande för att upprepa studierna i både samma feedback och iteration sker på flera olika platser. och olika miljöer. 1) Upprätta målen för datainsamlingen: Vi delar upp Noggrann specifikation av uppgifterna kräver att datainsamlingens mål delas in i två kategorier: de som kan användas för att utvärdera en för att ha en tydlig uppfattning om studiens mål. Att ange mål specifik programvaruutveckling metod i förhållande till själva är en viktig fråga, eftersom, utan mål, man kör de påståenden som gjorts för det, och de som är gemensamma för alla metodrisk att samla in orelaterade, meningslösa data. Ursäkter som ska studeras. För att få insikt i programvaruutvecklingsprocessen, det Som ett exempel, ett mål för en viss metod, såsom datainsamlare behöver veta vilka typer av fel som begåtts och information som döljer [41], kan vara att utveckla programvara som de typer av förändringar som gjorts. För att identifiera besvärliga frågor är det lätt att ändra sig. Motsvarande uppgiftsinsamlingsmål är att göra de ansträngningar som krävs för att göra varje förändring. För bästa utvärdering av utvecklarnas framgång i att uppfylla detta mål, dvs. användbarhet, skulle man vilja studera projekt från programvara utvärdera den lätthet med vilken programvaran kan ändras. Produktionsmiljöer där grupper av programmerare deltar. Mål i denna kategori kan vara av större intresse för dem som Vi kan sammanfatta det föregående eftersom följande sex är involverade i att utveckla eller testa en viss metod, kriterier. och måste definieras i samarbete med dem. 1) Uppgifterna skall innehålla information som gör det möjligt att identifiera ett mål som är av intresse oavsett vilken metod som används för att fastställa vilka fel och ändringar som gjorts. används för att hjälpa till att förstå miljön och fokusera på atten- 2) Data nmust inkluderar kostnaden för att göra förändringar. Det handlar om tekniker som är användbara där. Ett annat sådant mål är 3) Data som skall samlas in måste definieras som ett resultat av tydliga förändringar som gör det möjligt att jämföra studiens mål i förhållande till specifikationen. projekt och miljöer. Sådana mål kan intressera soft-4) Data bör omfatta studier av projekt från produktionsingenjörer, programmerare, chefer, och andra mer än miljöer, som involverar grupper av programmerare. Mål som är specifika för framgång eller misslyckande av en viss 5) Dataanalys bör vara historiska; data måste samlas in metodik. och valideras samtidigt med utveckling. Konsekvenser av utelämnande av mål: Utan mål är en 6) Dataklassificeringssystem som ska användas måste vara noggrant benägna att erhålla data där antingen ofullständiga mönster eller ingen specificerad för att studien ska kunna upprepas i samma mönster är märkbara. Som ett exempel, ett mål för en tidig och olika miljöer. Studie [15] skulle karakterisera fel. Under dataanalysen blev det önskvärt att upptäcka den del av felen som var resultatet av ändringar i programvaran av någon anledning andra Vår datainsamlingsmetod är målinriktad. Det börjar än att korrigera ett fel. Tyvärr, inget av målen för med en uppsättning mål för att vara nöjd, använder dessa för att generera en uppsättning studien var relaterad till denna typ av förändring, och det fanns frågor som skulle besvaras, och sedan fortsätter steg-för-steg ingen sådan data tillgängliga. Genom utformning och genomförande av en datainsamling 2) Utveckla en lista över frågor av intresse: När målen för och valideringsmekanismen. Analys av data ger svar studien har fastställts, de kan användas för att utveckla till frågor av intresse, och kan också ge en ny uppsättning av en lista över frågor som ska besvaras av studien. Frågor. Förfarandet bygger i hög grad på ett interaktivt dataintresse som definierar dataparametrar och kategoriseringar som möjliggör valideringsprocessen; de som tillhandahåller data intervjuas för kvantitativ analys av data. I allmänhet kommer varje mål att resultera valideringssyften samtidigt med programvaran utvecklas-i generering av flera olika frågor av intresse. Förhandlingsförlopp. Metodiken har använts i två olika exempel, om målet är att karakterisera förändringar, några korremiljöer att studera fem programvaruprojekt som utvecklats genom sponding frågor av intresse är: "Vad är fördelningen av grupper med olika bakgrund, med hjälp av mycket olika mjuka förändringar beroende på orsaken till förändringen?""Vad är ware utvecklingsmetoder. I båda miljöerna är det fördelning av förändringar mellan olika systemkomponenter?""Vad får svar på de flesta frågor av intresse och viss insikt fördelningen av ansträngningen att designa förändringar?" de utvecklingsmetoder som används. Tabell I är en summaSom ett andra exempel, om målet är att utvärdera enkelheten med Maria av egenskaper hos avslutade projekt som har varit vilken programvara som kan ändras, kan vi identifiera frågor av studerade. Definitioner av egenskaperna är desamma som i intresse såsom: "Är det tydligt var en förändring måste göras i [40]. Alla exempel som används i denna uppsats är tagna från studier programvaran?"Är förändringar kopplade till enskilda moduler?", om SEL-miljön. "Vad var den genomsnittliga ansträngningen för att göra en förändring?" 730 IEEE TRANSAKTIONER PÅ SOFTWARE ENGINEERING, VOL. SE-10, nej. 6 NOVEMBER 1984 Frågor av intresse utgör en bro mellan subjektivt kan resultera i data som senare inte kan identifieras som passande några bestämda mål i studien och de kvantitativa åtgärderna särskild kategorisering. Varje förändring definierar sedan sin egen för att användas i studien. De gör det möjligt för utredarna att bestämma kategori, och resultatet är en överväldigande mångfald av minor de mängder som behöver mätas och de aspekter datakategorier, med lite data i varje kategori. av de mål som kan mätas. Som ett exempel, för att upptäcka 4) Design och Test Data Collection Formulär: För att ge en hur ett designdokument används, kan man samla in data permanent kopia av data och för att förstärka programmerarnas som visar hur dokumentet användes när behovsminnen, en datainsamling form används. Formulärdesign var för en förändring till den upptäcktes. Detta kan vara den enda aspekten av de knepigaste delarna av de genomförda studierna, främst av dokumentets användning som är mätbar. Eftersom former utgör en kompromiss mellan motstridiga frågor Förutom att tvinga fram en tydligare definition av mål, frågor mål. Typiska konflikter är önskan att samla in ett comof intresse har den önskvärda egenskapen att tvinga Investiga-plete, detaljerad uppsättning data som kan användas för att svara på en bred tors att överväga de dataanalyser som ska utföras innan någon rad frågor av intresse, och behovet av att minimera tiden data samlas in. och de ansträngningar som krävs för att tillhandahålla uppgifterna. Att tillfredställa de tidigare målen för vilka frågor av intresse inte kan formuleras leder till stora, detaljerade formulär som kräver mycket tid att fylla och mål som inte kan uppfyllas på grund av lämpliga åtgärder. Den senare kräver en kort, check-off-boxar typ av kan inte definieras kan kasseras. En gång (nedan kallade ändringar). Bilda. 1 visar den sista versionen av det formulär som används för SEL Var och en av dessa kategorier kan vara ytterligare delkategoriserade studier som redovisas här. (En tidigare version av blanketten var enligt förnuftet. Till exempel skulle ändringar kunna ändras avsevärt till följd av de erfarenheter som vunnits i samband med de ändringar som gjorts till följd av krav på datainsamling och analysprocesser.) De första delarna av ändringarna, ändringar till följd av en ändring i formuläret, begär textbeskrivningar av ändringen och stödmiljön (t.ex. kompilatorändring), planerade skäl till att det gjordes. Följande avsnitt innehåller frågor och förbättringar, optimeringar och andra. Kontrolltabeller som återspeglar olika kategoriseringssystem. En sådan kategorisering tillåter karakterisering av förändringarna Som exempel, en kategorisering av tid för att utforma förändringar är med avseende på stabiliteten i utvecklingsmiljön, begärs i den första frågan efter beskrivningen av den med avseende på olika typer av utvecklingsverksamhet, förändring. Den som fyller i blanketten får välja mellan fyra o.s.v. När matchas med en annan kategorisering såsom kategorierna (en timme eller mindre, en timme till en dag, en dag till svårighet att göra förändringar, visar detta system också vilka tre dagar, och mer än tre dagar) som täcker alla möjligheter är de svåraste att göra. kliar för designtid. Varje kategoriseringssystem bör vara komplett och consisKonsekvenser av att inte använda ett formulär för uppgiftsinsamling: Witent, dvs. varje ändring bör passa exakt en av subcate-out ett formulär för uppgiftsinsamling, är det nödvändigt att förlita sig på systemets develgories. För att säkerställa fullständighet brukar vi lägga till operans minnen och på genomslag av tidiga versioner av design kategorin "Annat" som en underkategori. Om vissa ändringar är dokumentation och kod för att identifiera och kategorisera de ändringar som inte lämpar sig för systemet, görs underkategorin "Ej tillämplig". Denna appro)ach leder till ofullständiga, felaktiga uppgifter. kan användas. Eftersom insamling och validering är samtidiga med programvara devel-intresse. Som ett exempel, för att besvara frågan "Vad var alternativet; ju kortare fördröjningen mellan att fylla i blanketten och fördelningen av förändringar enligt anledningen till att genomföra intervjun, desto mer exakta uppgifter. Förändring?", en sådan fördelning som den som visas i Fig. 2 kan vara den kanske mest betydande problemet under datainsamling som beräknas från data. och validering säkerställer att uppgifterna är fullständiga, dvs. att varje förändring har beskrivits på ett formulär. Ju bättre tillämpning av Schemat trolled utvecklingsprocessen, desto lättare är detta att göra. Vid tillämpning av schemat kräver iterering bland stegen seveach skede av processen där konfigurationsstyrning är im-erala tider. Definiera målen och fastställa de frågor som ställs, kan ändra data samlas in. Där projekt som vi intresserar oss för är tätt sammankopplade, liksom att fastställa frågorna om har studerat använda formella konfigurationskontroll, har vi inte-intresse design och testa formulär, och samla in och river konfiguration kontroll förfaranden och data col-validera data. Många av de överväganden som ingår i lection förfaranden, med användning av samma formulär för båda, och att genomföra och integrera stegen i schemat har varit fördel av konfiguration kontroll förfaranden för validering utelämnas här så att läsaren kan ha en översikt över syftena. Eftersom alla ändringar måste ses över genom en configura-process. Den fullständiga uppsättningen mål, frågor av intresse och kontroll i sådana fall, vi garanteras insamling av data kategoriseringar för SEL-projekt visas i [33]. Alla förändringar, d.v.s. att våra data är fullständiga. Dessutom absorberas datainsamlingen overhead in i konfigurationen SupportProcedures andFacilities control overhead, och är inte synlig som en separat källa för irritaFörutom de aktiviteter som är direkt involverade i data till utvecklarna. Insamlingsansträngningar, det finns ett antal stödåtgärder och konsekvenser av att utelämna validering: Ett resultat av förenklingar krävs. Som stödaktiviteter ingår testning av aktuell utveckling, datainsamling och validering av data är formulär, insamlings- och valideringsförfaranden, utbildning av att insamlingsprocessens noggrannhet kan kvantifieras. Programmerare, välja ett databassystem för att möjliggöra enkel analyAccuracy kan beräknas genom att observera antalet fel i data, kodning och inmatning av data i databasen, tar vid ifyllande datainsamlingsformulär. Man kan då och utveckla analysprogram. jämföra, för alla datakategorier, distributioner före validering med distributioner efter validering. Vi kallar en sådan analys för ett III. Detaljer för valideringsanalysen av SEL-UPPGIFTER. Valideringsanalysen av SEL-data OCH VALIDATION visar att det är möjligt för felaktigheter i storleksordningen 50 perI SEL-miljön användes programbibliotek för att förvänta sig att införas genom att utelämna validering. Att betona port och kontroll programvara utveckling. Det fanns en heltid konsekvenserna av att utelämna valideringsförfarandena, vi bibliotekarie tilldelas för att stödja SEL-projekt. Alla projektbibliotek presenterade några av resultaten av valideringsanalysen av SEL-ändringarna via bibliotekarien. I allmänhet, vi data i Avsnitt III. Definiera en ändring för att vara en ändring till baselined design, kod, 6) Analysera data: Data analyseras genom att beräkna pa-eller dokumentation. För SEL-ändamål studerades endast ändringar av kod, rametrar och distributioner som behövs för att besvara frågorna och dokumentationen i koden. Den (Fig. 1) Vi definierar ett fel som en avvikelse mellan en specifikation mer än 5 procent av ändringarna och fel är felklassificerade och dess genomförande. Även om det inte alltid var möjligt i någon av datainsamlingskategorierna. För den större kateten att identifiera den exakta platsen för ett fel, det var alltid possi-gories, såsom om en ändring är ett fel eller en ändring, kan identifiera exakt varje felkorrigering. Som ett resultat, vi typ av förändring, och typ av fel, är osäkerheten i allmänhet använder termen fel för att betyda felkorrigering, förmodligen inte mer än 3 procent. För datavalideringsändamål, de viktigaste delarna av För SEL3, försökte vi kvantifiera resultaten av valithe datainsamlingsförfarandet är översynen av ändringsprocedurerna mer noggrant. Efter validering, bildar analytiker, och tillhörande programmerare intervju att lösa kategoriserades enligt vårt förtroende för deras exakthet. Ovisshet om uppgifterna. Vi använde fyra kategorier. ................................................................................................................ Bilda. 4 visar antalet genererade formulär uttryckta i procent av de totala validerade formulären. Variation i felklassificering Bild 3 visar att prevalidering SEL3-formulären var signifikant Data om misciassificering av förändring och feltyp subcate mer exakt än de prevalidering SELl- eller SEL2-formulären. Målen för insamlingen av uppgifter, frågor av intresse och formulären för insamling av uppgifter kan behöva revideras i enlighet därmed, t.ex. enligt tabell III. Förutom de processuella problemen med att utforma och genomföra en datainsamlingsstudie, fann vi flera IV* REKOMMENDATIONER FÖR DATASAMLAKTORER andra fallgropar som kunde ha påverkat våra resultat starkt och vi anser att vi nu har tillräcklig erfarenhet av att ändra deras tolkning. De finns förtecknade i följande tabell. datainsamling för att kunna tillämpa den framgångsrikt i en bred vari-1) Kanske den mest betydande av dessa fallgropar var danety av miljöer. Även om vi har kunnat tolka resultaten utan att försöka förstå jämförelser mellan de data som samlats in i de två miljöfaktorer i miljön som kan påverka uppgifterna. Som vi har studerat, skulle vi vilja göra jämförelser, vi hittade en förvånansvärt liten andel av gränssnittet med en större variation av miljöer. Sådana jämförelser kommer att leda till fel i alla SEL-projekt. Detta var förvånande eftersom det endast är möjligt om mer data blir tillgängliga. Att uppmuntra gränssnitt är en ofta kallad källa till fel. Det var också inrättandet av fler datainsamlingsprojekt, vi anser att det är andra bevis i data att programvaran var ganska amenable viktigt att beskriva en framgångsrik datainsamling metodol-för att förändras. När vi försökte förstå dessa resultat diskuterade vi ogy, som vi har gjort i de föregående avsnitten, för att påpeka dem med huvuddesignern av SEL-projekten (alla de fallgropar som berörs, och för att föreslå sätt att undvika dem som hade samma tillämpning). Det var tydligt från diskuspitfallen. 736 IEEE TRANSAKTIONER PÅ SOFTWARE ENGINEERING, VOL. SE-10, nej. 6 NOVEMBER 1984 hade formgivarna lärt sig vilka förändringar som väntade sig att deras sys- studeras, så att datan kan användas för jämförelse tems, organiserade designen så att de förväntade förändringarna skulle syften, och så att de som fyller i formulären förstår vara lätt att göra, och sedan återanvända designen från ett projekt den terminologi som används. Gör övningsövningar i att fylla i till nästa. I stället för att misstolka uppgifterna för att betyda att formulär för nykomlingar. gränssnitt var inte ett betydande programvaruproblem, vi var 5) Integrera datainsamling och valideringsförfaranden i ledde till en bättre förståelse av miljön vi var konfigurationskontroll processen. Data fullständighet och studier. Noggrannheten förbättras därmed, datainsamlingen är diskret, 2) En andra fallgrop underskattade de resurser som behövs och insamling och validering blev en del av det normala för att validera och analysera data. Förståelse för förfarandena för förändringsutveckling. I fall där konfigurationskontrollrapporter tillräckligt bra för att genomföra meningsfulla, effektiva program-används inte eller är informell, tilldela betydande tid till promer intervjuer för validering ändamål initialt konsumerade con-grammer intervjuer, och, om möjligt, dokumentation söka åtkomliga mängder av förändringsanalytikernas tid. Verifierar det och kodläsning. databasen var internt konsekvent, komplett och konsekvent 6) Automatisera så mycket av dataanalysprocessen som möjligt. med papperskopiorna av rapporterna var en ständig källa till frustration och ett handfat för tid och ansträngning. Begränsningar 3) En tredje potentiell fallgrop i datainsamlingen är sensitiv-Det har tidigare noterats att den huvudsakliga begränsningen av användningen av data. Programmerare och designers behöver ibland en målinriktad datainsamlingsmetod i en produktionsmjukhet som är övertygad om att feldata inte kommer att användas mot dem. Detta har inte visat sig vara ett betydande problem för de projekt som studeras.Forvets resultat kan inte användas för att bevisa att en särskild faktor i 2) Fastställa målen för datainsamlingsmetoden och utvecklingsprocessen orsakar särskilda typer av fel, men kan definiera frågor av intresse innan försök att några uppgifter används för att föreslå att vissa metoder, när de tillämpas i insamlingen. Upprätta mål och definiera frågor shoud vara miljö studeras, kommer att förbättra utvecklingsprocessen. en iterativ process som utförs i samråd med utvecklarna. Programutvecklaren kan då förses med en uppsättning av utvecklarnas intressen och de data som rekommenderas för att förbättra programutvecklarens. Processen i hans omgivning. 3) För inledande datainsamling, hålla uppsättningen data Som ett exempel, i SEL-miljön varken externa insamling mål liten. Både volymen av data och tidsproblem, såsom kravförändringar, eller globala problem, förbrukas i insamling, validering och analys av det kommer att vara såsom gränssnitt design och specifikation, var sigifilcant. Oväntat stor. Dessutom var utvecklingsmiljön ganska stabil. 4) Designa datainsamlingsformuläret så att det kan användas De flesta problem förknippades med det individuella programmet för konfigurationskontroll, så att det är skräddarsytt för projektet/projekten mer. Uppgifterna visar att det i SEL-miljön skulle
Det är därför svårt att besvara konkreta frågor när ett systems hållbarhet ska undersökas, vilket också begränsar tillämpningen av strukturerade mätmetoder som GQM Ref i detta sammanhang.
A Methodology for Collecting Valid Software Engineering Data
{'venue': 'IEEE Transactions on Software Engineering', 'journal': 'IEEE Transactions on Software Engineering', 'mag_field_of_study': ['Computer Science']}