ECIS 2002 • June 6–8, Gdańsk, Poland — First — Previous — Next — Last — Contents — 379 CHALLENGING SOFTWARE PROCESS IMPROVEMENT BY DESIGN Ivan Aaen Department of Computer Science, Aalborg University Phone: +45 9635 8911, Fax: +45 9815 9889 Email: ivan@cs.auc.dk ABSTRACT Software process improvement (SPI) today is based mainly on a perception of software processes as artifacts and this perception has led SPI efforts to focus on perfecting such artifacts as a means to improve the practices of the people supposed to execute these software processes. Such SPI efforts thus tend to view the design of software processes as separate from their use. In this approach process designers are expected to provide process knowledge to software developers, and software developers are expected to provide experiences and problems to the process designers. This focus on software processes as artifacts implies an emphasis on formalization and externalization of process models possibly at the expense of the process knowledge in the heads of the process users. The paper point to problems related to separation and externalization from a theoretical standpoint and suggests an alternative to Improvement by Design: End-user SPI, where process users individually and collectively design their own software processes assisted by process experts. 1. INTRODUCTION Throughout its existence the software industry has sought for remedies against the missed schedules, blown budgets, and flawed products that haunt so many software projects. In the last decade much of this effort has concentrated on Software Process Improvement (SPI) based on the software capability maturity model (CMM) (Paulk, Curtis et al. 1993) or similar norms. The aim of SPI is to build an infrastructure and a culture that support effective methods, practices, and procedures so that they are the ongoing way of doing business. Experience has shown that such aims are difficult to obtain. SPI involves organizational change on a scale and with a complexity that requires commitment, resources, and skill at all organizational levels and also with a large risk of failure. It is unknown how many companies start doing SPI and likewise we cannot know for sure how many companies abandon their SPI efforts without achieving the goals set for the effort. A recent report from the Software Engineering Institute (SEI) suggests that a substantial proportion of organizations initiating SPI run into stalemates or simply abandon the effort: By August 2001 a total of 1505 organizations had reported from assessments conducted since 1987 through June 2001. Only 379 of these 1505 organizations had been reassessed corresponding to 25 per cent (SEMA 2001). The time organizations spend to move up maturity levels is also considerable according to the same report. The median time to move from maturity level 1 to 2 is 24 months, 21.5 months from level 2 to 3, 33 months from level 3 to 4, and 18 months from level 4 to 5, which shows that progression through CMM maturity levels is time-consuming and difficult. About 90 per cent of the reporting organizations are at level 3 or less.