Statistical Process Control for Software: Fill the Gap

Abstract

The characteristic of software processes, unlike manufacturing ones, is that they have a very\ud high human-centered component and are primarily based on cognitive activities. As so, each\ud time a software process is executed, inputs and outputs may vary, as well as the process\ud performances. This phenomena is better identified in literature with the terminology of\ud “Process Diversity” (IEEE, 2000). Given the characteristics of a software process, its intrinsic\ud diversity implies the difficulty to predict, monitor and improve it, unlike what happens in\ud other contexts. In spite of the previous observations, Software Process Improvement (SPI) is a\ud very important activity that cannot be neglected. To face these problems, the software\ud engineering community stresses the use of measurement based approaches such as QIP/GQM\ud (Basili et al., 1994) and time series analysis: the first approach is usually used to determine\ud what improvement is needed; the time series analysis is adopted to monitor process\ud performances. As so, it supports decision making in terms of when the process should be\ud improved, and provides a manner to verify the effectiveness of the improvement itself.\ud A technique for time series analysis, well-established in literature, which has given\ud insightful results in the manufacturing contexts, although not yet in software process ones is\ud known as Statistical Process Control (SPC) (Shewhart, 1980; Shewhart, 1986). The technique\ud was originally developed by Shewhart in the 1920s and then used in many other contexts.\ud The basic idea it relies on consists in the use of so called “control charts” together with their\ud indicators, called run tests, to: establish operational limits for acceptable process variation;\ud monitor and evaluate process performances evolution in time. In general, process\ud performance variations are mainly due to two types of causes classified as follows:\ud  Common cause variations: the result of normal interactions of people, machines,\ud environment, techniques used and so on.\ud  Assignable cause variations: arise from events that are not part of the process and\ud make it unstable.\ud In this sense, the statistically based approach, SPC, helps determine if a process is stable or\ud not by discriminating between common cause variation and assignable cause variation. We\ud can classify a process as “stable” or “under control” if only common causes occur. More\ud precisely, in SPC data points representing measures of process performances are collected.\ud These values are then compared to the values of central tendency, upper and lower limit of\ud admissible performance variations.\ud While SPC is a well established technique in manufacturing contexts, there are only few\ud works in literature (Card, 1994; Florac et al., 2000; Weller, 2000(a); Weller, 2000(b); Florence,\ud 2001; Sargut & Demirors, 2006; Weller, & Card. 2008; Raczynski & Curtis, 2008) that present\ud successful outcomes of SPC adoption to software. In each case, not ...

Support for Statistic Process Control of software process

“…R5 Caso o processo esteja estável e haja uma quantidade de dados suficiente, a organização deve estabelecer uma baseline de desempenho do processo [3], [5], [8], [10], [12], [13], [15], [19], [21], [24]. R6 Caso o processo apresente instabilidades, a organização deve registrar os problemas, causas especiais relacionadas a eles e ações a serem realizadas para eliminar as causas [3], [5], [8], [10], [12], [13], [15], [19], [21], [24].…”

“…R6 Caso o processo apresente instabilidades, a organização deve registrar os problemas, causas especiais relacionadas a eles e ações a serem realizadas para eliminar as causas [3], [5], [8], [10], [12], [13], [15], [19], [21], [24]. R7 A organização deve acompanhar as melhorias realizadas, para verificar se os problemas foram solucionados [24].…”