improving software development

8/10/2019 Improving Software Development

http://slidepdf.com/reader/full/improving-software-development 1/82 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2 0 7 4 0 - 7 4 5 9 / 0 2 / $ 1 7. 0 0 © 2 0 0 2 I E E E

ISO 9000, the Capability Maturity Model,1,2

Spice (Software Process Improvement andCapability Determination, also known asISO/IEC 15504), and Bootstrap to promotemature software development practices. TheCMM has been supplemented with the Idealimprovement model, the Personal Software

Process, and Team CMM. Most of theseframeworks have become well known amongpractitioners and researchers. In the US,more than 1,000 CMM-based assessmentshave been carried out. From 1994 to 2000,the Commission of the European Unionfunded more than 450 so-called process im-provement experiments (PIEs) through itsEuropean Systems and Software Initiative(ESSI).

Despite the amount of resources spent onthese improvement efforts, several critical is-

sues are still open, as the many ongoing ini-tiatives, projects, and standardization effortstestify. In particular, evaluating whether an

assessment and consequent improvementplan have had a causal, significant, and posi-tive impact on company success is difficult.Certainly, some studies show that process as-sessment techniques benefit software devel-opment organizations.3 In reality, these posi-tive effects are not so evident. Some

researchers claim that most improvement ini-tiatives have had limited success.4 Further,companies such as Microsoft have developedsuccessful commercial software without ad-hering to external process standards or pur-suing ambitious improvement initiatives.

The problems go deeper than just needingto downsize and tailor SPI frameworks. Asthe Spice and CMM experience has shown,rather than just repair and adjust the process(model), we should also question some un-derlying assumptions and refocus SPI to be

more company- and user-oriented. Indeed,one of the basic SPI-QA (quality assurance)assumptions is that “the quality of a soft-

focusImproving SoftwareProcess Improvement

Reidar Conradi, Norwegian University of Science and Technology

Alfonso Fuggetta, Politecnico di Milano, Italy

Two dichotomies

characterize

software process

improvement effortsand approaches:

disciplined vs.

creative work and

procurer risks vs.

user satisfaction.

Based on these

perspectives, the

authors introduce

six theses to

illuminate the

problems ofpursuing SPI.

T

he past years have seen an increasing interest in methods, mod-

els, and techniques (so-called frameworks) to support the assess-

ment and improvement of software development processes.

Here, software process improvement encompasses process assess-

ment, process refinement (traditional SPI), and process innovation (introduc-ing major process changes). National and international bodies have proposed

and supported frameworks such as the Quality Improvement Paradigm,

out of the box


http://slidepdf.com/reader/full/improving-software-development 2/8

ware product is largely governed by thequality of the process used to develop andmaintain it.”2 The CMM also states that “if a process is not under statistical control, sus-

tained progress is not possible until it is.”1

However, software work, like other designwork, is not like mechanized or disciplinedmanufacture. It has a strong creative compo-nent involving human and social interactionthat cannot be totally preplanned in a stan-dardized and detailed process model.

SPI should ultimately lead to a learning-and user-oriented organization, as empha-sized by the “mother” of all SPI-QA frame-works, Total Quality Management (TQM).5

A good business process is simply one that

leads to satisfied users—the only ones whocan define product quality. Such a process isnot necessarily one with high CMM or ISO9000 ratings, though software procurerswho think they represent potential users of-ten emphasize these ratings. Just take a lookat today’s cellular phone providers to ob-serve the disparity between business successand formal CMM levels. (For example, Mo-torola is partly at CMM Level 5, Ericssonpartly at Level 3, and Nokia at Level 1.)

The SPI community knows most of the

arguments on all sides of this issue. In spiteof this, substantial parts of SPI frameworksand efforts have been biased toward disci-pline rather than creativity in their internalfocus and toward procurers rather thanusers in their external focus. These twopairs of opposing biases, or dichotomies,cover the range of attitudes; the challenge isto reconcile them.

The value of SPI debatedIn a recent report on the Spice trials,6 we

found some disturbing observations: Approximately three fifths do not believe that

the assessment has had a major impact on the

organization. This may be due to there not be-

ing sufficient time since the assessment for SPI

to have taken root or due to the organizations

not being able to act on the recommendations

and findings from the assessment….This is

further reinforced by the finding that only 28

percent disagree with the statement that noth-

ing much has changed since the assessment. It

is interesting to note that 79 percent believe

that SPI was overcome by events and crises,

indicating potentially that the organizationswere not in a state that is ready for long term

SPI initiatives (i.e. there were other more im-

portant things to attend to).

These comments are serious and raise im-portant points that go well beyond acciden-tal management or priority problems. Fur-

thermore, as James D. Herbsleb and DennisR. Goldenson document,3 quite a few peo-ple working with the CMM describe SPI ashaving no or very little effect (26 percent) oreven being counterproductive (4 percent).Forty-nine percent said they were disillu-sioned by the lack of results. Other re-searchers have written about the problemsof achieving SPI in small organizations.7

On the other hand, there is a growingbody of success stories, where CMM-basedSPI gets credit for significant productivity

gains and reliability improvements.8

Thereare also observations around Cocomo II9 in-dicating that each increased CMM level(aside from other effects) means a productiv-ity gain of 4 to11 percent. However, in mostof this work, causally relating the claimedgains to a chosen improvement method’s ap-plication is difficult. That is, would any sys-tematic SPI-QA (quality assurance) initiativehave yielded similar results cost-efficiently; isthere a reference group? Likewise, could theapplication of just a few novel core tech-

niques—estimation, inspections, or reuse,for example—have led to a similar gain ormajor share of the gain?

We have performed several Europeanstudies in small- and medium-sized enter-prises (SMEs), both in Scandinavia10 andItaly.11 These studies conclude that short-term priorities, combined with business andmarket turbulence, may severely prevent,hamper, and even abort well-planned, low-key SPI efforts. Further, many of the citedSPI frameworks are hardly suited or appli-

cable in their present forms for SMEs. Con-sequently, the Norwegian Software ProcessImprovement for Better Quality project,known as SPIQ, has defined a downscaledand pragmatic subset of existing SPI frame-works aimed at busy and often small ITcompanies.12

Internal SPI focus: discipline vs.creativity

The first perspective, discipline, refers tointroduction of and adherence to more

structured work processes, usually as nor-mative process models and plans. This is inline with most QA efforts and usually in-

J u l y / A u g u s t 2 0 0 2 I E E E S O F T W A R E 3

A good businessprocess is

simply one thatleads tosatisfied

users—theonly ones who

can defineproduct quality.



volves setting up procedures, rules, andguidelines and possibly certifying or stan-dardizing many of these processes. Thereare more than 250 proposed software stan-

dards, many of them recommending stan-dard process models—but how many of these are in practical use?

The other perspective, creativity, empha-sizes that software development relies on acollaborative design process known as par-ticipatory development. This applies to boththe project team and the future user, whereeven requirements are subject to continuousclarification and (re)negotiation. Althoughthere is no excuse for not trying to make aninitial set of clear, fixed requirements, the

reality of software development is not well-defined and stable.Many of the ideas and techniques on

quality improvement (TQM and others)come from manufacturing, which involvesstable products, processes, and organiza-tions. Information technology, on the otherhand, is characterized by rapid product in-novation, not process refinement. Undersuch circumstances, Stan Rifkin claims, wehave offered the “wrong medicine” to smallsoftware companies, which have conse-

quently failed their SPI programs.4

An Eng-lish software consultancy company, OxfordSoftware Engineering, is advocating whatthey call rapid process improvement. In In-ternet time, one year is like a “dog year”(seven years) in other disciplines, and time-to-market seems sacred. The strength of many small software companies lies in fastturnaround and their ability to convert nextweek’s technologies into radically newproducts and services. According to IBMSoftware manager Daniel Sabbah in a con-

versation at ICSE 2001, even his large or-ganization, with 4,500 software developersworking on middleware, spends 30 percentof its resources on technology-drivenprocess changes.

We must therefore adopt a set of qualityand improvement technologies that can op-erate under constant change.13 For instance,we should be careful in overly reducingprocess variance (as implied by CMM Level4), because this constrains future technolog-ical opportunities. That is, we run the risk

of refining an outdated process. On theother hand, we should not let softwarework degenerate into an unstructured hap-

pening, discarding discipline and formaliza-tion altogether. We need to balance the“odd couple” of discipline and creativity.14

Appropriate perspectives should be applied

to different parts of the software process—for example, discipline and rigor to inspec-tions and configuration management, andcreativity and collaboration to requirementsengineering and high-level software design.

External SPI focus: procurer risksvs. user satisfaction

Software development has three mainroles in a value chain: software developer,procurer, and user. The role of the customer,who is paying for the actual software, may

be either of the latter.A software procurer is in charge of ac-quiring software from a software developer(provider or contractor) according to statedand often fixed requirements. It might be amass-produced article but is usually a tailor-made system that’s part of a new informa-tion system. Providers are frequently pickedafter a round of bidding, evaluation, andcontract negotiation, which covers productquality (functionality, reliability, and so on),price, delivery scheduling, and possibly fu-

ture maintenance. Naturally, the aim is toreduce procurer risks—how can the user beconfident that the provider can deliver thepromised software on time and budget?Here, certification, a well-proven techniquein other engineering and manufacturing dis-ciplines, comes into play.

The Software Engineering Institute’s workon the CMM has identified five certificationlevels of software maturity. The SEI assertsthat these levels and their key process areascapture relevant company processes that, in

combination, will lead to desired productquality as well as budget and schedule com-pliance from a procurer’s viewpoint. TheCMM and similar frameworks are thusmeant to evaluate (assess) engineering andmethodological aspects of software processes,such as project management, requirement en-gineering, configuration management, and soon. However, they do not consider the successfactors of the contracting company (softwaredeveloper), such as profitability, competitive-ness, market strategy, and user satisfaction.

Indeed, these frameworks hardly touch on thecontractor’s success; their focus is work disci-pline and risk reduction.

Softwaredevelopment

has three mainroles in a valuechain: software

developer,procurer, and

user. The role ofthe customer,who is paying

for the actualsoftware, maybe either of the

latter.

4 I E E E S O F T W A R E J u l y / A u g u s t 2 0 0 2



A user (or end user) is one who interactswith the delivered software, directly or indi-rectly. The user, being a person or an organ-ization, implicitly defines product quality—

whether the functionality, price, and deliverytime of a software piece (and what comeswith it) satisfy the user’s evolving needs.

Poor product quality can lead to disas-trous errors (for example, unsafe, unreliable,or insecure systems) and “dead-upon-deliv-ery” incidents of misconceived informationsystems. However, time-to-market is becom-ing more important, both for software com-panies and other organizations that rely onsoftware. Internet time has even reached thelarge telecom companies, and Ericsson has

stated its priorities: “faster, better,cheaper”—in that order. An end user is notinterested in the procurement or develop-ment of a piece of software but in how thesoftware helps create a high-quality product.The delivery of such products should there-fore be the software provider’s and develop-ers’ dominating concern, as TQM clearlystates. Given the risks of developing infor-mation systems with unclear or evolving re-quirements, many organizations have turnedto more incremental methods with more in-

teraction between users and developers.Methods such as the Dynamic Systems De-velopment Method and the Rational UnifiedProcess are rapidly taking hold. Organiza-tions consider the static view of formal prod-uct procurement harmful and are rapidlyabandoning it. Instead, they are formingstrategic partnerships and signing develop-ment contracts without always agreeing on afinal set of requirements. As another exam-ple, the Norwegian Computer Society(www.dnd.no) offered a course in spring

2001 on chaos and complexity theory tohelp its members prepare for modern IT sys-tem development.

The essential problems of SPIinitiatives: six theses

We believe that the essential problems un-dermining most companies’ SPI initiativescome from using these two dichotomies to in-terpret SPI. Frameworks such as CMM,which is inherently discipline- and procurer-oriented, have greatly influenced such initia-

tives. CMM assessments and correspondingSPI initiatives have not consistently correlatedwith company success, as the examples of

Nokia, Motorola, and Ericsson demonstrate.The results of recent empirical studies aremixed; they show that “improving” (or struc-turing) the process does not automatically

improve the company’s competitiveness. Nev-ertheless, a software procurer might force adeveloper to initiate and carry out SPI or aquality certification (ISO-9000, for example).

The two identified foci and their perspec-tives are not intrinsically in conflict. They allidentify legitimate and useful visions for as-sessing and improving a company. Weshould decide which SPI approach or frame-work is best for which context. For instance,the CMM might work well for stable com-panies. The real problem is managing goals,

expectations, and viewpoints. A softwareprocurer’s goal is to select the best contrac-tor objectively and rationally. A softwarecompany’s goal is to survive and grow in acompetitive market. An end user’s goal is toacquire the software product that can solvethe right problem, at the right time, at an ac-ceptable price. We cannot expect the sameSPI approach and consequent effort to ac-commodate all these viewpoints.

These observations suggest a strong needto revise the approach and assumptions un-

derlying existing SPI frameworks and re-lated company initiatives. Over the past fiveyears, we have been involved in several SPIinitiatives. Based on this experience, wepresent six theses on how to enhance andbetter apply SPI frameworks.

Thesis 1

SPI frameworks should support improvement

strategies that focus on goal orientation and

product innovation.

Most SPI frameworks implicitly require ahigh stability level. The CMM, for instance,assumes that applying several significant(and often expensive and time-consuming)changes causes improvement. These changeswill progressively move the company from alow maturity level to a higher one. However,most companies cannot base their improve-ment strategies on such a long-term effortand do not have a well-established baselinefor comparison. The environment is fast-paced: time-to-market is crucial, and compa-

nies are continuously created, merged, anddestroyed. Most of them would never con-sider this kind of SPI as a priority. For these


Theseobservations

suggest astrong need to

revise theapproach andassumptionsunderlyingexisting SPIframeworks

and relatedcompany

initiatives.



companies, the real issue is product innova-tion, not process stabilization and refine-ment. Processes (if any) must “follow thestream” and let the company effectively pur-

sue product innovation. If a CEO’s problemis to deliver a product within six months, hewill not seriously consider an SPI initiativethat won’t be finished for at least one year.That is, we need specific goal orientation—not general symptom orientation.

In a study of Norwegian and SwedishPIEs supported by the EU’s ESSI program,all the failed PIEs (10 of 29) were due topersonal or organizational instabilities10 Inthe SPIQ project,12 a collaborative Norwe-gian SPI project, only 2 out of 15 companies

completely avoided such instabilities from1997 to 1999, and 6 of 15 companiesaborted their improvement efforts during ei-ther planning, startup, or implementation.

Generally, SPI frameworks should iden-tify an action list that offers sufficient localleverage and a time line consistent with thecompany’s market dynamics. This requiresheavily extending our assessment methodsand considering a range of currently ex-cluded dimensions (for example, market andeconomic variables). If the company context

is suited for applying the CMM, that is fine,but one size does not fit all. The remedy is to

Make the SPI initiative consistent withbusiness goals and strategy to ensurethat it will have the desired effects oncompany performance.

Start with improvement activities thatdeal with the most pressing needs.

Define realistic and visible short- andlong-term goals.

Thesis 2

Developers are motivated for change; if possi-

ble, start bottom-up with concrete initiatives.

Developers are the ones most likely to seewhat is possibly wrong. Many frameworksemphasize that we should first seek top-management commitment. Our experienceshows that mid-level management resist-ance can also be a problem, because thesemanagers are the main players in improve-

ment initiatives. The CMM, which has atop-down orientation, also acknowledgesthe problem with middle managers.

As part of the SPIQ project, we inter-viewed software managers and developers infive SMEs about their attitudes toward im-provement and quality work and about how

improvement activities should be prioritized(for example, using a scorecard). We foundthat developers indeed are motivated forchange, and often there was broad consensuswhen identifying the most critical or possiblymost cost-effective topics to address. Bystarting with pressing needs such as estima-tion, inspections, or incremental develop-ment, improvement is coupled to concretegoals and can be effectively monitored, ana-lyzed, and evaluated. In the SPIQ project, wehave worked on more than 20 concrete im-

provement initiatives (ranging from six to 12months down to two to three months) andcooperated closely with developers and qual-ity and project managers. Top-level managersregularly receive reports and results from thiswork. This secures ongoing support, pavesthe way for more long-term improvementinitiatives (two to four years), and encour-ages experience reuse and organizationallearning. Showing concrete results to thosewhose processes “need” improvement pro-motes situated learning. Improvement and

learning cannot be forced from the outside.They must become an ingrained part of thework process. This is also consistent withhow knowledge workers perform their jobs.Such workers easily learn to work aroundand even sabotage projects involving ineffec-tive processes and fruitless directives.

So, our remedies for this thesis are to

Use a simple and focused scorecard tostart with, not a large assessment.

Rely on and enlarge developer partici-

pation through situated learning. Establish feedback lines inside and be-

tween improvement initiatives and makethem visible to top-level management.

Thesis 3

Automated software process support has been

overemphasized.

Over the last 12 years, there has been amassive research and development effort to

support the software process using comput-erized tools (so-called software processtechnology). SPT involves modeling lan-

Developers arethe ones mostlikely to see

what is possiblywrong. Manyframeworks

emphasize thatwe should

first seek top-management

commitment.




guages, editors, interpreters, and possiblyexperience bases—sometimes combinedinto a process-sensitive software engineer-ing environment (PSEE). However, because

software processes are largely dynamic andcooperative activities, the impact of suchtechnologies has been meager.

The problems and issues that SPT andworkflow–groupware management addressare the same. Indeed, we can largely reusethe experiences and results from workflowand groupware research for softwareprocesses. Further, configuration manage-ment (CM) tools are the real PSEEs. CM isthe underlying process controlling a largeportion of any software development activ-

ity. The fact that CM processes areamenable to automation explains why CMtools have been so successful on the market.

As mentioned, we have so far not sub-stantially demonstrated that SPT is useful.SPT environments and PSEEs are not usedin real software processes, as the significantlack of commercial vendors offering thiskind of product testifies. SPI should applyresults from organizational and behavioralsciences that emphasize the creativity andcooperation in software development.

These observations apply not only tosoftware activities, but to a large set of cre-ative design processes. For example, ongo-ing empirical work in computer-supportedcooperative work is exploring the use of computer-assisted tools to support unstruc-tured processes. In general, we must recon-sider the efforts and research in processtechnology and relate them to other disci-plines that have intensively studied cooper-ative and creative processes.

So, to remedy thesis 3, we propose that

Only stable processes—for inspection,testing, or configuration management,for example—are well suited for SPTsupport, especially with computer-as-sisted enactment.

An SPT tool must adapt to the specificneeds of the application; building an ad-vanced tool for the wrong application istechnological overkill.

Thesis 4

Cost – benefit analysis requires novel amortiza-

tion models.

The proof in the pudding is whether SPIresults in a positive return-on-investment(ROI)—that is, whether it contributes to in-creased competitiveness and value creation.

As we mentioned in Thesis 1, many compa-nies want a six- to 12-month time line forimprovement efforts. A recent Norwegiansurvey indicates that software companies’average project length is three to sixmonths, with increments of three to sixweeks inside projects.15 On the other hand,it takes four to five years to move fromCMM Level 1 to Level 3. Admittedly, SEInever claimed to have designed the CMM toincrease productivity, although there aremany CMM-related and other SPI papers

on ROI. Regrettably, they are often basedon uncertain data.Because many SPI frameworks (CMM,

Spice, ISO 9000) advocate clustering manydifferent techniques as part of a certificationprocedure, it becomes difficult to show acausal relationship between future benefitand any actual applied techniques. More-over, methods for incremental or compo-nent-based development assume that manytechniques are combined in new and com-plex ways that may not fit the grouping in

the SPI frameworks. A general problemwith all software improvement initiatives(reuse programs, metrics programs, or SPI)is that they spend resources now, while—aswith any other investment—the gain lies inthe future. We therefore need a standardizedmarket-value model, such as the one em-ployed in Cocomo II,9 to account for soft-ware improvement initiatives. On the otherhand, many companies have no uniform, in-ternal interest rate even for physical invest-ments, such as new buildings, office furni-

ture, or computer equipment. In spite of this, they often require SPI efforts to show apositive ROI in one year or less. Maybe themistrust in yet another software technologyis rooted in the upper-management sphere?

Remedies for this problem are to

Develop incremental and novel cost–ben-efit models (such as Cocomo II).

Strive for a common company-internalcost–benefit model.

Execute one SPI effort (experiment) at a

time, possibly against baseline projects. Tell management that reproducible and

convincing results might take some time.


SPTenvironmentsand PSEEs are

not used in realsoftware

processes, asthe significant

lack ofcommercial

vendors

offering thiskind of product

testifies.



Thesis 5

SPI assumes cultural changes, so we need expertise

from social sciences.

The engineering profession, includingsoftware engineering, combines technicaland social aspects. The same must apply forSPI to properly initiate, carry out, study, andlearn from improvement efforts. Thus, weshould draw on social sciences (to conductproper case studies, for example), social an-thropology (to study how people reallywork), organizational sciences (for organiza-tional learning), and so on. This applies toboth software managers and researchers.

Software developers are knowledge work-

ers. They tend to respond negatively to top-level dictates on how to do work or changeprocesses. Organizations must integrate newtools such as PSEEs or experience bases intonormal work practices, otherwise such toolsare doomed to fail. A focus on continuous im-provement and quality requires participativeattention by all employees and cannot be del-egated to internal visionaries, quality man-agers, or process champions. Managing SPIand quality is not something that an organiza-tion can do, for example, for one year and

then put aside for the next three. Managementbooks taught by management “gurus” world-wide admittedly emphasize most of this. How-ever, the heavy time pressure in innovativefields like IT makes this a demanding task.

This brings up the fundamental methodproblem of how to influence and study so-cial organizations. The SPI advocate or re-searcher will often serve as an “influenceagent” in a moving-target organization andwork closely with the persons under study.These SPI initiatives must

Use multidisciplinary teams—for exam-ple, combined with action research.

Establish participative engagement on allprocess changes and associated activities.

Emphasize the cultural, learning, andlong-term dimensions of SPI work.

Start humbly with small steps.

Thesis 6

SPI is about learning — not control, as in QA.

There are many textbooks on learningorganizations and knowledge management.

Long-term quality work is not about pun-ishing those who commit errors, but aboutsystematizing and learning from past expe-riences and users’ needs and reactions col-

lectively and without ego. The slogan of theNASA Software Engineering Laboratory inthe 1980s and ’90s was that measurementand learning from experience were “part of our way of doing business.” However,“smoke-screening” or “scape-goating” willtypically prevent systematic learning fromfailed projects in organizations, both inter-nally and externally. According to recent re-ports from other parts of NASA, in autumn1999, an engineer could risk being fired if he reported a problem, whereas in the pio-

neering 1960s it was a “problem” not to re-port a problem. The medical profession hassimilar reporting inhibitors.

Too often, good quality is associatedwith zero defects—high reliability or guar-anteed safety, for example. Many software-intensive companies, therefore, have a sepa-rate QA department or quality managerwho maintains the quality system (formalroutines) for the company. However, devel-opers might not embrace these formal rou-tines (see Thesis 5), which tend to collect

dust on the shelves. Web versions of suchstandards might not fare much better. In aNorwegian survey of 23 software develop-ers and managers, developers saw formalroutines as ineffective in transferring knowl-edge; the routines were often prepared andintroduced without their participation.16

The AT&T studies on how workers actuallyperform processes also report a lack of process conformance.17 All this corrobo-rates the observation that employees willnot necessarily turn formalized and exter-

nalized experience into better work prac-tices. The same observation has been maderegarding promoting reuse through com-mon reuse repositories.18

The remedies for this problem are to

Create an SPI team separate from the QAdepartment (as in the CMM’s softwareengineering process groups), or, betteryet, combine SPI and QA in one team.

Perform empirical studies on how peo-ple actually work.

Make a reward system for reportingproblems or suggesting improvementideas.

Too often,good quality isassociated withzero defects—high reliabilityor guaranteed

safety, forexample.




I mproving the way we develop softwareor software processes is a key challengefor our society. Software is the core of

any modern service or product. Therefore,

ensuring its quality is vital. As a conse-quence, SPI is one of the most critical andimportant efforts that any software com-pany pursues. Nevertheless, many SPI initia-tives have not proven successful—that is,significantly and directly related to relevantimprovements in company performance andproduct quality. Software development com-panies’ lack of commitment and investmentmight cause this. Our opinion is that existingSPI frameworks are unable to address thecritical challenges of a software development

company, causing this lack of interest, com-mitment, and goal-oriented success.The conclusions we propose might ap-

pear obvious to some readers. Still, it is sur-prising that despite the increasing awarenessthat SPI cannot only be based on CMM-likeassessments, the number of initiatives andprojects aimed at innovating SPI methods islimited. Similarly, there are few documentedattempts to apply new or different kinds of assessment methods. Indeed, given the re-ported problems with existing SPI frame-

works and company SPI initiatives, it is timeto redirect the course of action to make SPImethods and technologies more effectiveand widely used. This means being moreflexible in choosing and applying SPI frame-works, learning from organizational scien-tists, and, most importantly, listening to acompany’s customers and aligning with acompany’s technology and business context.The discussion offered here is an initial at-tempt to provide direction on how to ad-dress these challenging issues.

References1. W.S. Humphrey, Managing the Software Process, SEI

Series in Software Eng., Addison-Wesley, Reading,Mass., 1989.

2. M.C. Paulk et al., The Capability Maturity Model forSoftware: Guidelines for Improving the SoftwareProcess, SEI Series in Software Eng., Addison-Wesley,Reading, Mass., 1995.

3. J.D. Herbsleb and D.R. Goldenson, “A Systematic Sur-vey of CMM Experience and Results,” Proc. 18th Int’l Conf. Software Eng. (ICSE 96), IEEE CS Press, LosAlamitos, Calif., 1996, pp. 323–330. See also tech. re-port SEI-94-TR-13, Software Eng. Inst., Carnegie Mel-lon Univ., Pittsburgh, Pa., 1994.

4. S. Rifkin,“Is Process Improvement Irrelevant to Pro-duce New Era Software?” Proc. Software Quality:

Quality Connection (ECSQ 02), Springer-Verlag, Hei-delberg, Germany, LNCS 2349, 2002, pp. 13–16.

5. W.E. Deming, Out of the Crisis, MIT Center for Ad-vanced Eng. Study , MIT Press, Cambridge, Mass., 1986.

6. Spice, Phase 2 Trials Interim Report, version 1.00, 17 June 1998, p. 159;www.sqi.gu.edu.au/spice/trials/p2summ.html.

7. R.P. Ward, M.E. Fayad, and M. Laitinen,“ThinkingObjectively: Software Improvement in the Small,”Comm. ACM, vol. 44, no. 4, Apr. 2001, pp. 105–107.

8. B. Curtis, “The Global Pursuit of Process Maturity,”IEEE Software, vol. 17, no. 4, July/Aug. 2000, pp.76–78.

9. B.W. Boehm et al., Software Cost Estimation with Co-como II (with CD-ROM), Prentice Hall, Upper SaddleRiver, N.J., 2000.

10. T. Stålhane and K.J. Wedde, “SPI—Why Isn’t It More

Used?” Proc. EuroSPI ’99, Pori School of Technologyand Economics, Pori, Finland, Serie A25, pp.1.34–1.39.

11. F. Cattaneo, A. Fuggetta, and D. Sciuto, “Pursuing Co-herence in Software Process Assessment and Improve-ment,” Software Process: Improvement and Practice,vol. 6, no. 1, Mar. 2001, pp. 3–22.

12. T. Dybå et al., SPIQ Metodebok for Prosessforbedring [SPIQ Method Book for Software Process Improve-ment], V3, ISSN 0802-6394 Univ. of Oslo, SINTEF,and Norwegian Univ. of Science and Tech., 2000 (inNorwegian); www.geomatikk.no/spiq.

13. T. Dybå, “Improvisation in Small Software Organiza-tions: Implications for Software Process Improvement,”IEEE Software, vol. 17, no. 5, Sept./Oct. 2000, pp.82–87.

14. R.L. Glass, Software Creativity, Prentice Hall, UpperSaddle River, N.J., 1995.

15. S.F. Andersen and P.C. Nødtvedt, A Survey of Incre-mental Development in Norwegian IT Industry,prediploma thesis, Norwegian Univ. of Science andTechnology, Trondheim, Norway, 2001.

16. R. Conradi and T. Dybå, “An Empirical Study on theUtility of Formal Routines to Transfer Knowledge andExperience,” Proc. European Software Eng. Conf. 2001(ESEC 2001), ACM Press, New York, pp. 268–276.

17. D.E. Perry, N. Staudenmayer, and L.G. Votta, “People,Organizations, and Process Improvement,” IEEE Soft-ware, vol. 11, no. 4, July 1994, pp. 36–45.

18. J.S. Poulin, “Populating Software Repositories: Incen-tives and Domain-Specific Software,” J. Systems and Software, vol. 30, no. 3, Sept. 1995, pp. 187–199.

For more information on this or any other computing topic, please visit ourDigital Library at http://computer.org/publications/dlib.


About the Authors

Reidar Conradi is a professor in the Department of Computer and Information Scienceat the Norwegian University of Science and Technology in Trondheim (NTNU, previously calledNTH). He was a visiting scientist at Fraunhofer Center for Experimental Software Engineering

in Maryland and at Politecnico di Milano in 1999–2000, where he did the work for this article.His interests are process modeling, software process improvement, software engineering data-bases, versioning, object orientation, component-based development, and programming lan-guages. He received his MS and PhD in informatics from NTNU. Contact him [email protected].

Alfonso Fuggetta is a professor in the Department of Electronics and Informatics at Po-litecnico di Milano, Italy, and scientific vice-director of the affiliated CEFRIEL research institute(Education and Research Center for Information Technology). He is also a faculty associate ofthe Institute for Software Research at the University of California, Irvine. His interests are soft-

ware process improvement, software archi tecture, mobile software, Web-based and event-based systems, and applications of such technology. He graduated from the Politecnico di Mi-lano with a Laurea degree (MS) in electronic engineering. Contact him [email protected].

improving software development

Documents