tool support for software process assessment and improvement

SOFTWARE PROCESS—Improvement and Practice, Vol. 3, 213–223 (1997)

Tool Support for SoftwareProcess Assessment andImprovement

Robin Hunter1*, Gordon Robinson2 andIan Woodman3

1University of Strathclyde, Department of Computer Science, 26 Research SectionRichmond Street, Glasgow, G1 1XH, U.K.2Memex Technology Ltd., 2 Redwood Court, East Kilbride, G74 5PF,U.K.3APERTA, 12 Mollins Court, Westfield, Cumbernauld, G68 9HP, U.K.

Many software process assessment models have been developed based on, or inspired by,the Software Engineering Institute’s Capability Maturity Model (CMM). The outputs arisingfrom such models can be voluminous and complex, requiring tool support to comprehendand analyse them. The paper describes some tools developed in order to visualize the resultsof SPICE conformant assessments. The tools, which are equally useful to software producersand to software procurers, also have a valuable research role and have been used tosummarize the results of the world-wide trials of the SPICE reference model. This work hasitself led to the enhancement of the tools based partly on experience of their use and partlyon revisions to the SPICE model. 1997 John Wiley & Sons Ltd

Softw. Process Improve. Pract., 3, 213–223 (1997)

KEY WORDS: process assessment; process improvement; tool support

1. INTRODUCTION

Software process assessment has been a popularand widely used method of ensuring the productionof quality software. Developed at the SoftwareEngineering Institute (SEI) in Pittsburgh for theuse of major software procurers such as the USDepartment of Defense (DoD), software processassessment has also been found useful to softwareproducers wishing to improve their software pro-cess, and hence their software products. The twouses of process assessment are referred to as

* Correspondence to: Robin Hunter, University of Strathclyde,Department of Computer Science, 26 Richmond Street, GlasgowG1 1XH, U.K. Tel. +44 141 548 3585; E-mail: rbhKcs.strath.ac.uk

CCC 1077-4866/97/040213-11$17.50 1997 John Wiley & Sons, Ltd.

Capability Determination and Process Improvement,respectively.

The Software Capability Maturity Model (CMM)developed at the SEI in 1987 has been widely used,especially in the US, and, based on experience ofits use and informed public comment, has beensubject to considerable development and revisionsince its original version. The current version isdescribed in Paulk et al. (1995) and a furtherrevision (version 2) should appear shortly. As wellas the development of the CMM, many othersoftware assessment schemes based on it, orinspired by it, have also appeared. These areusually targeted at particular types of software,particular sectors of industry or for use in particularregions of the world. Examples are BOOTSTRAP(Kuvaja and Bicego 1994) for use in Europe,TRILLIUM (Coallier 1995) for use in the telecom-

Research Section R. Hunter, G. Robinson, and I. Woodman

munications industry and the Software Diagnostic(Craigmyle and Fletcher 1993) for use by smallenterprises developing software.

The plethora of software assessment methodsled the International Standards Organization (ISO)in 1991 to approve a study period to investigatethe need and requirements for an internationalstandard for software process assessment. Theresults of this study led to the setting up ofthe SPICE (Software Process Improvement andCapability dEtermination) project to develop aframework for software process assessment andimprovement incorporating the best features of theleading existing methods. SPICE was to be unique,as a standards project, in a number of ways:

I the standard would be produced initially as atechnical report;

I the process assessment method would be exten-sively trialled prior to becoming an inter-national standard.

It is the trialling of the method that has providedinvaluable experience in the data handling issuesinvolved in applying the method, as well asinsights into the benefits and limitations of usingthe method, which has been a major factor in itsvarious revisions. Data handling has also becomean issue with other process assessment methods.The result of a CMM assessment, for example, wasoriginally one of five categories, Initial, Repeatable,Defined, Managed, Optimizing; but the results fromthe current version include an array of values ofthe form not satisfied, partially satisfied, or fullysatisfied for 18 key process areas relating to fivematurity levels. According to Dunaway et al. (1998),a survey showed that nearly a third of leadassessors in CMM assessments had difficulties insummarizing evidence. Other models, such asTRILLIUM, have also undergone revision withconsequent increases in their complexity and theamount of data associated with an assessment.Thus data handling and data analysis have becomeimportant aspects of process assessment.

The paper identifies the need for tools to handlesoftware process data. It describes tools developedat the University of Strathclyde to visualize suchdata, and the uses to which the tools have beenput. The fact that the tools can handle data collectedfrom SPICE-conformant assessments using a rangeof assessment methods, facilitates the use of thesoftware assessment data to: 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

214

I identify norms (in terms of assessment results)for particular types of software, or softwaredeveloped for particular application domains;

I investigate the basic assumptions inherent insoftware process assessment methods.

Section 2 of the paper discusses the data handlingissues associated with software process assessmentand makes the case for developing visualizationtools. Section 3 describes the original version ofthe Strathclyde tool set. Sections 4 and 5 describehow the tools were used in phase 1 of the SPICEtrials and for related research, respectively. Section6 describes how the toolset was enhanced, basedon experience of its use and changes to the SPICEreference model.

2. DATA HANDLING ISSUES

The principal data handling aspects associatedwith software process assessment are:

I data capture;I data storage;I data visualization and analysis.

The efficient and reliable capture of assessmentdata is all important and is addressed in theSPICE project through the notion of an assessmentinstrument (AI). An assessment instrument is(ISO/IEC 1996, part 9):

A tool or set of tools that is used throughout anassessment to assist the assessor in evaluating theperformance or capability of processes and inhandling assessment data and recording theassessment results.

In principal, an assessment instrument may bebased on manual procedures or may be automated.A number of automated AIs have emerged fromthe SPICE project, for example the SEAL tool (HimLok and Walker 1997), and these serve to supportthe data collection and storage procedures associa-ted with a SPICE assessment.

The analysis and visualization of assessmentdata is a complementary issue to data collectionand storage, though it could be based on a commondatabase. The data produced from a SPICE-con-formant assessment is complex and can most easilybe visualized using tool support.

Research Section Tool Support for Software Process Assessment and Improvement

With the aid of suitable visualization tools:

I a summary of the main results of an assessmentcan be viewed in graphical form;

I the ratings for particular processes, or processesin particular process categories, may be viewed;

I the ratings at a particular capability level maybe viewed.

Such tools allow a user to browse through thedata in order to identify process weaknesses andprioritize improvement activities. If data collectedfrom a coherent set of assessments can be handledin the same way, norms for particular applicationdomains or particular types of software can beidentified. Data from specific assessments maythen be compared with relevant industrial norms.

Tools to visualize software assessment data aretherefore of value both to software producers whowish to improve their processes compared withtheir competitors, and for software procurers whowish the assess the processes of potential contrac-tors against those used in the industrial sectorinvolved.

The authors’ involvement in the SPICE trials ledthem to develop the sort of tools proposed inorder to analyse the data collected from the trials.In the case of the SPICE trials, the results of thevarious trial assessments formed only part of thedata to be analysed. In addition, a significantamount of demographic data was collected, in partto capture the coverage of the trials. Also somesoftware product and project data was collected,allowing the possibility – valuable from a researchpoint of view – of correlating the various types ofdata (process/product/project). Phase 1 of theSPICE trials took place in 1995 and the results ofthe analysis of the trials has been published in theIEEE Software Process Newsletter in Spring 1996 (ElEmam and Goldenson 1996, Marshall et al. 1996,Woodman and Hunter 1996) as well as in atextbook (El Emam et al. 1997). The Strathclydetoolset (version 1) was used to perform demo-graphic and other types of analysis of the datacontained in the phase 1 trials database, with aview to evaluating the current assessment modeland its documentation. Analysis of the data col-lected during phase 2 of the SPICE trials, basedon the updated SPICE model, is now taking place(January 1998) and is using version 2 of theStrathclyde toolset. 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

215

The principal requirements for visualization toolsfor the purposes outlines above were:

I to be able to view summaries of the assessmentdata and subsets of the data in a meaningfulform;

I to be able to browse through the data focusingon particular aspects of the process for moredetailed investigation;

I to be able to analyse multiple assessments;I to provide demographic information;I to be able to present data in tabular form to

help identify anomalies;I to be able to show the coverage of an assessment

in terms of processes and process categoriesassessed;

I to perform various research-oriented types ofanalysis (described in Section 5).

3. VERSION 1 OF THE STRATHCLYDETOOLSET

The principal tool in the toolset, was the assessmentvisualization tool (AVT). It was developed inVisual BASIC in order:

I to allow the rapid generation of prototypeinterfaces, with graphical support for designingbuttons, graphs, menus and other componentsin order to produce an interface consistent withother Windows applications;

I to provide a good interface with the Accessdatabase used to store the trials data;

I to make use of the ‘visual’ facilities providedby Visual BASIC;

I to produce a tool for PC use.

The functionality of the AVT can best be describedwith the aid of some screen shots. Figure 1 showsthe highest level view of an assessment (or set ofassessments) provided by the tool. The ratings ateach capability level is shown for each of theprocess categories defined by the SPICE model.The data in the figure is obtained by applying allthe SPICE generic practices to all the (SPICE)processes, each application of a generic practice toa process yielding a value not, partially, largely orfully adequate. An individual bar of a histogramdenotes, for a particular process category and fora particular capability level, the percentages of thevalues in each of the categories fully, largely and


Figure 1.

partially adequate (the balance being not adequate).Alternatively, the same information may be dis-played by capability level (and within this byprocess category).

From either view it is possible to select aparticular process category or a particular maturitylevel, as shown in Figure 2, which shows theSupport process category, and then to choose aparticular process (e.g. SUP 5) within the category.Choosing a capability level next will give theratings for the base practices, as shown in Figure 3,if the data is for level 1, (performed informally)or, if the maturity level had been other than level1, the adequacy of the generic practices for thatlevel would have been shown, as in Figure 4,

Figure 2.

1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

216

Figure 3.

Figure 4.

which shows the adequacy of the generic practicesat level 2 (Planned and Tracked). Both views canbe readily used to identify weaknesses in theprocess for use in process improvement or inconnection with capability determination.

At the most basic level, the raw data, representedas tuples, giving the percentages of the genericpractices which are fully, largely, partially and notadequate for each individual process of a processcategory may be obtained as shown, in Figure 5,using the SPICE notation. For example, the tuple

SUP[*] ; 1 = [88,0,0,12]


Figure 5.

means that for process 1 (develop documentation)of the Support process category, the percentagesof the generic practices which were fully, largely,partially and not adequate were 88, 0, 0, 12, respect-ively, consistent with Figure 2. The tuples thereforerepresent the raw data behind the histograms.

These are only some of the ways in which theuser may navigate through the data viewingsummaries and subsets of the data in graphical ornumeric form. For example, the buttons to theright of Figure 2 allow the user to return to aprevious higher level of the hierarchy. In addition,the tuples view can be obtained at any stage.

4. APPLICATION TO SPICE

The AVT and associated tools were readily usedto perform certain types of analysis on the datacollected from phase 1 of the SPICE trials. Inparticular, the following types of demographicanalysis were performed:

I coverage of application domains;I coverage of business sectors;I coverage of process categories;I sample size (number of projects assessed);I coverage by geographical region.

Data were used from the 28 trials which returnedcomplete sets of ratings. Eighteen of these trialswere conducted in Europe and 10 in the Asia 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

217

Pacific region. The trials involved 49 projects with324 process instances in total. Figure 6 shows thecoverage achieved by the trials with respect toprocess category.

In addition, the AVT was used to look forfeatures of the assessment data that might indicatestrengths of the SPICE model or, alternatively,indicate weakness in the model or its docu-mentation. On the whole the trends were as wouldhave been expected. For example, the adequacy ofa process usually decreased on moving up thecapability levels. Other observations regarding thedata included:

I some process categories were generally strongerthan others. For example the Engineering Cate-gory usually had most capability;

I some generic practices were rated not adequatemore than others. The significant increasebetween levels 2 and 3 in generic practiceswhich were rated not adequate practices wasalso noted;

I the occasional example of greater adequacy atlevel 5 than at level 4.

The trends were reported back to the SPICEproject and were a major factor, along with thecomments from the national member bodies, inthe revision of the model. The last point aboveclearly suggested the need for some revision tothe model or its documentation.

Analysis of the data also led to suggestionsconcerning the collection, storage and analysis ofdata from future SPICE trials, the most significantof which was the need to distinguish clearly

Figure 6.


between generic practice ratings which were notadequate and those which were not assessed.

5. RESEARCH ASPECTS

The availability of a significant amount of softwareprocess, product and project data collected duringphase 1 of the SPICE trials provided a welcomeopportunity for empirical research into the majorissues concerning software process assessment andimprovement. Furthermore, the availability of abrowsing tool to help identify features of the data,which might be worth analysing in a more formalway, was invaluable. (A similar approach to theanalysis of software product data is described inHunter (1994).) With a view to gaining insight intothe major issues concerning process assessmentand improvement, the following investigationswere therefore performed:

I to identify and characterize clusters of assess-ment results corresponding to levels of criticalityand perceived importance of the ISO 9126software quality characteristics of functionality,reliability, usability, efficiency, maintainabilityand portability (ISO/IEC 1991);

I to investigate the relationship between capa-bility level and the difference in assessmentlevels between different instances of the sameprocess.

5.1. Identification of clusters

Additional tools were developed to perform hier-archical cluster analysis (Anderberg 1973) in orderto identify projects with similar process contextswith respect to criticality and desired productcharacteristics. One of the clusters identified isdescribed in Table 1. It comprised 18 projects.

The average capability of the cluster was thencompared with that of the population as a wholeand the results of this comparison are given inTable 2, for the Customer-Supplier process categoryat each of the capability levels (see Figure 7). Inorder to aggregate the values not, partially, largelyand fully adequate it was necessary to weight thesevalues in some way. For this purpose the weightingssuggested by the SPICE model (ISO/IEC 1996)were used. The figures show that, for this cluster,the capability at all levels is less than the average 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

218

Table 1.

Context variable Rating %

Application Mainly business and CASE 78domainFunctionality Essential 89Reliability Essential 72Usability Essential or substantial 72Efficiency Essential or substantial 83Maintainability Substantial or moderate 78Portability Moderate or little if any 89Safety risks Small damage to property – no 94

risk to peopleEcomonic risks Significant economic loss 83

(company affected)Security risks Protection against error risk or 83

protection of critical data orservices

Environmental No environmental risk 94risks

Table 2.

Capability level % difference from overall aggregation

1 −262 −563 −954 −975 −100

Figure 7.

for the population as a whole. Notice, however,the very limited amount of data at the higher levels.

A fuller report of the results of the clusteranalysis is given in Woodman and Hunter (1997).Three significant clusters were identified consisting


of 18, 11 and 8 projects, respectively. The secondtwo clusters were concerned with low risk businesssoftware and embedded systems, respectively.Perhaps not surprisingly, the processes associatedwith the low risk business software showed lowerthan average capability on the whole, while theprocesses associated with the embedded softwareshowed higher than average capability. It wasnoticeable, however, that the results seemed moreconsistent for each of the clusters at capabilitylevels 2 and 3 (planned and tracked and welldefined) than at the other levels. While the lack ofconsistency at the higher capability levels maysimply be explained by the limited data available,this is not the case at level 1 (performed informally).This seems to suggest the assessment results atthis level may not be so significant as at thehigher levels.

The identification of norms for the assessmentof particular types of software with particularcharacteristics or produced for particular appli-cation domains is potentially very valuable. Pro-curers will wish to know the capability of apotential contractor’s process with respect to thenorm for the type of software concerned or forthe industrial sector involved, while softwareproducers will be particularly concerned with howtheir process compares with their competitors’ pro-cesses.

5.1.1. Variation in assessment resultsWhere an organizational unit’s process wasassessed in the context of more than one projectit was possible to investigate the difference betweenassessments of the different instances of the sameprocess, and to correlate this variability with thecapability level of the process. For example, thegraphs in Figures 8 and 9 show assessments ofdifferent instances of the same process as points inthe same vertical line. An integer beside a pointindicates that there are two or more assessmentswith identical results. Capability is reduced to asingle number by weighting the raw ratings (inthe same way as for cluster analysis) and averagingthe results of the various process instances (in thecase of the x-axis). In these examples which areboth concerned with assessments at capability level2 (planned and tracked), where the trend was mostnotable, the points in each vertical line are closertogether the higher the process capability, implyingthe differences between the assessments of different 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

219

Figure 8.

Figure 9.

instances of the same process is less the greaterthe process capability.

Other examples show the same trends as illus-trated in Figures 8 and 9, though the trend is lessclear at capability levels other than level 2 (plannedand tracked). While the data available was limited,the pattern illustrated was sufficiently commonplace to give a high degree of confidence in thecorrectness of the following hypothesis:

Assessments of different instances the same process(as instantiated by different projects) are likely tobe more similar the higher the capability of theprocess concerned.

While the data were insufficient to support astatistically significant statement, further studiesbased on larger data set should be better able toestablish the significance of the above statement.The truth of the statement would imply that the


process assessments from which the data wastaken really have measured the extent to whichthe processes have been well defined. It would bea further step to conclude that a well-definedprocess produces good software, a conclusion thatcould not be reached based on process data alone.Hence the importance of collecting software processand product data, rather than trying to makesignificant conclusions based on process data alone.

6. FURTHER DEVELOPMENTS

Consequent on the results of the SPICE trials, aswell as on comments on the SPICE documents bythe member bodies, the SPICE model, and itsdocument set, was revised during 1996 (ISO/IEC1996). In particular, changes to the measurementframework reduced the amount of data requiringto be collected. It was this revised model anddocument set that was used in phase 2 of theSPICE trials. As a result of these changes, theStrathclyde toolset was revised while at the sametime the opportunity was taken to re-engineer theuser interface and some other aspects of the tool,in the light of experience of analysing the phase 1trials. In this section we describe the new AVTwith emphasis on the changes which were madefrom the previous tool. The data shown are random(but realistic).

As previously the data may be viewed by processcategory or by capability level. Although it doesnot greatly concern the use of the tool, the namesof the capability levels have changed in this versionof the SPICE model as have the SPICE processeswithin each category, and the names of thecategories. Figure 10 shows the capability at thevarious levels for the Support process category.Figure 11 represents a refinement of Figure 10 andshows the capability for the various processeswithin the Support Process Category at level 3.Figure 12 is a refinement of Figure 11 and showsthe extent to which process attributes (new to thisversion of the SPICE model) have been achievedfor the SPICE process SUP.3 (Perform QualityAssurance in this version of the model). Processattributes represent a simplification of the genericpractices, and there are one or two for eachcapability level. Figure 13 uses a pie chart toillustrate the extent to which a specific processattribute has been achieved. This view distinguishes 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

220

Figure 10.

Figure 11.

Figure 12.


Figure 13.

Figure 14.

clearly between process that have not been assessedand those which have not achieved the appropriateattribute. This was not a feature of the previousversion of the tool but was identified as a seriousomission from the data capture and storage pro-cedures used in phase 1 of the SPICE trials, andwas reported as such in the phase 1 trials report.

The tool may also be used to show the capabilitylevels achieved by individual SPICE processeswithin a process category. In this context thecapability level of a process is defined to be thelevel for which:

I the process has fully achieved all the attributesassociated with all lower capability levels;


221

I has either largely or fully achieved the attributesassociated with that level.

Where a number of assessments are involved, ora number of instances of the same process havebeen assessed in single assessment, the data onprocess capability levels may be displayed (by thetool) as in Figure 14. This data may also bepresented numerically in a tuple-like notation.

Again, there are extensive facilities for navigatingthrough the data and support to the user to keeptrack of his current context. Most facilities areavailable either through pull-down menus, buttons,or, in some cases, by clicking histograms. A graphshowing the various routes through the data isshown in Figure 15. For example, the sequence ofFigures 10 to 13 illustrate the steps involved inmoving down the right hand side of the figurefrom the second top position. In a similar way theprogression down the left hand side (to the samefinal view) could have been shown.

Issues involved in designing and implementingthis tool included:

Figure 15.


I the extent to which histogram data should becomputed ‘once and for all’ and stored oncean assessment or set of assessments had beenchosen for visualization;

I the navigational facilities which should beoffered to the user.

This tool is available, along with others, on theCD accompanying El Emam et al. (1997).

7. CONCLUSIONS

The tools served the purposes required of them inconnection with producing results for the SPICEproject as well as in the research activities whichthey supported. In addition we had the opportunityof revising and enhancing them in the light ofour experience in their use. The tools were notspecifically used for process improvement or capa-bility determination but we believe that they havea valuable role to play in these areas as well.

Further ongoing developments involving thetools include:

I facilities for viewing the results of one assess-ment in the context of a set of coherentassessment results;

I the provision of a ‘map’ to help users keeptrack of their navigational path through thetool’s facilities.

As we have already seen, the SPICE data can beused to investigate some of the fundamentalquestions regarding software process assessment.To pursue these investigations further in a widercontext, however, requires two things:

I the availability of more software process andproduct data in the public domain;

I standardization of software process and pro-duct measures.

As far as the first of these is concerned, data havebeen collected by many of the organizations usingproprietary methods of process assessment, andthis data would be invaluable for research purposesif it were publicly available. As far as standardiz-ation issues are concerned, it seems, to us at least,that software standards bodies are overly concernedwith ambitious projects in areas often not fullyunderstood by the software community. Instead,perhaps it is time for them to turn their attention 1997 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 3, 213–223 (1997)

222

to defining basic product and process measures toallow greater comparability of software data, atthe same time providing much needed support forempirical studies of software products and pro-cesses.

In addition, we believe that the understandingand interpretation of fine grained software processand product data by software developers, procurersor researchers requires the availability of visualiz-ation and analysis tools similar to those describedin this paper. Integrated environments for thecapture, storage and analysis of assessment datafrom software processes and software productswould provide significant support to softwareassessors and researchers interested inprocess/product issues and the relationshipbetween the two.

REFERENCES

Anderberg, M.R. 1973. Cluster Analysis for Applications.Academic Press.

Coallier, F. 1995. ‘TRILLIUM: a model for the assessmentof telecom product development & support capability’,Software Process Newsletter, 2, 3–8.

Craigmyle, M. and I. Fletcher. 1993. ‘Improving ITeffectiveness through software process assessment.Software Quality Journal, 2, 257–264.

Dunaway, D.K., D.R. Goldenson, I.A. Monarch and D.M.White. 1998. How well is CBA IPI working? Userfeedback. SEPG 98.

El Emam, K. and D. Goldenson. 1996. Some initial resultsfrom the international SPICE trials. Software ProcessNewsletter, 6, 1–5.

El Emam, K., Drouin, J.–N., Melo, W. (eds). 1997. SPICE:The Theory and Practice of Software Process Improvementand Capability Determination. IEEE.

Him Lok, R. and A.J. Walker. 1997. Automated toolsupport for an emerging international software processassessment standard. ISESS 97, IEEE Computer Society,Walnut Creek, 25–35.

Hunter, R.B. 1994. Analysis of data collected fromsoftware development case studies. IFIP InternationalConference on Software Quality and Productivity, HongKong.

ISO/IEC. 1991. ISO9126: Information Technology – SoftwareProduct Evaluation – Quality Characteristics and Guidelinesfor their Use. ISO/IEC.


ISO/IEC. 1996. ISO/IEC 15504–9 Information Technology –Software Process Assessment, parts 1–9. ISO/IEC.

Kuvaja, P. and A. Bicego. 1994. BOOTSTRAP – AEuropean assessment methodology. Software QualityJournal, 3, 117–127.

Marshall, P., F. Maclennan and M. Tobin. 1996. Analysisof observation and problem reports from phase-1 of theSPICE trials. Software Process Newsletter, 6, 10–12.

Paulk, M.C., C.V. Weber, B. Curtis and M.B. Chrissis.

EDITOR’S COMMENT

Many software process assessment and improvement methods are available. If such a method is appliedcarefully, it usually results in a huge amount of collected data. To derive useful consequences for processimprovement from this data, analysis and visualization tools are absolutely necessary. This paper describesa set of such tools related to the SPICE method, which is the assessment method supported by ISOand which has been described extensively in previous issues of this journal. Basing the tools on SPICEmakes them widely usable and enables one to compare results from various projects and departmentswithin a company or, if the data is provided externally, even across companies.

—WS


223

1995. The Capability Maturity Model: Guidelines for improv-ing the Software Process. Addison Wesley.

Woodman, I.H.G. and R.B. Hunter. 1996. Analysis ofassessment data from phase 1 of the SPICE trials.Software Process Newsletter, 6, 5–10.

Woodman, I.H.G. and R.B. Hunter. 1997. Analysis ofassessment data from trials. El Emam, K., Drouin, J.–N.,Melo, W. (eds), SPICE: The Theory and Practice of SoftwareProcess Improvement and Capability Determination. IEEE.

tool support for software process assessment and improvement

Documents