This paper discusses the problems that a software development organization must address in order to assess and improve its software processes. In particular, the authors are involved in a project aiming at assessing and improving the current practice and the quality manual of the "Business Unit Telecommunications for Defence (BUTD)" of a large telecommunications company. The paper reports on the usage of formal process modeling languages to detect inconsistencies, ambiguities, incompleteness, and opportunities for improvement of both the software process and its documentation.

The paper is aimed at examining the relationship between the three topics of the workshops that gave rise to this book: security, fault tolerance, and software assurance. Those three topics can be viewed as different facets of dependability. The paper focuses on diversity, as a desirable approach for addressing the classes of faults that underlay all these topics, i.e., design faults and intrusion faults. 1. Introduction The paper is aimed at examining the relationship between the three topics of the workshops that gave rise to this book: security, fault tolerance and software assurance. Those three topics can be viewed as different facets of dependability [29, 33], (see also the paper by Brian Randell in this volume). The second section is devoted to a fault classification, which identifies three major classes of faults: physical faults, design faults, (human-machine) interaction faults, where the latter two classes can be either accidental or deliberate. The classes of faults that ...

/gray exch def /start exch def /rotval exch def /mode exch def findfont /infont exch def /printme exch def

A software product is often behind schedule, over budget, non-conforming to requirements and of poor quality. Controlling and improving the processes used to develop software has been proposed as a primary remedy to these problems. The Software Engineering Institute at Carnegie Mellon University has published the Software Capability Maturity Model (SW-CMM) for use as a set of criteria to evaluate an organization's Process Maturity. The model is also used as a roadmap to improve a software development process 's maturity. The premise of the SW-CMM is that mature development processes deliver products on time, within budget, within requirements, and of high quality. This research examines the effects of Software Process Maturity, using the SWCMM, on software development effort. Effort is the primary determinant of software development cost and schedule. The technical challenge in this research is determining how much change in effort is due solely to changing Process Maturity when this change generally occurs concurrently with changes to other factors that also influence software development effort. The six mathematical models used in this research support the following conclusion: For the one hundred twelve projects in this sample, Software Process Maturity was a significant factor (95% confidence level) affecting software development effort. After normalizing for the effects of other effort influences, a one-increment change in the rating of Process Maturity resulted in a 15% to 21% reduction in effort. The modeling approach used in this analysis can be used in other areas of Software Engineering as well.

this report is to review and summarize the empirical evidence thus far on the costs and benefits of SPI. The intention is that this review would be utilized to support the business case for initiating and continuing SPI programs, to aid in the selection amongst the alternative improvement paradigms, to make more accurate estimates of the costs and benefits of such efforts, and to help set and manage the expectations of technical staff and management. The need for such a review is supported by the results of two recent surveys that were conducted by the SEI. The first survey was administered to individuals at the National SEPG Conference in 1993 and at an SPI tutorial during the Software Engineering Symposium in 1993 [25]. The respondents represented organizations that had mature SPI programs. More than seventy percent stated that they need information on the benefits of SPI (by choosing the "very high" or "high" response category in terms of characterizing their needs), which was also ranked as the highest need of the respondents. This indicates a need for consolidation of the evidence on the benefits of SPI. The second survey solicited information from organizations that had conducted software process assessments between 1992 and 1993 [26]. The results indicate that 77% of the respondents "Strongly Agree" or "Agree" that SPI has taken longer than expected and 68% stated that SPI has cost more than expected. This indicates a need for information to help estimate the costs of SPI and to set and manage expectations from SPI. Two general paradigms to SPI have emerged, as described by Card [10]. The first is the analytic paradigm. This is characterized as relying on "quantitative evidence to determine where improvements are needed and whether an improvement initiative has b...

Abstract—Understanding how to implement software process improvement (SPI) successfully is arguably the most challenging issue facing the SPI field today. The SPI literature contains many case studies of successful companies and descriptions of their SPI programs. However, the research efforts to date are limited and inconclusive and without adequate theoretical and psychometric justification. This paper extends and integrates models from prior research by performing an empirical investigation of the key factors for success in SPI. A quantitative survey of 120 software organizations was designed to test the conceptual model and hypotheses of the study. The results indicate that success depends critically on six organizational factors, which explained more than 50 percent of the variance in the outcome variable. The main contribution of the paper is to increase the understanding of the influence of organizational issues by empirically showing that they are at least as important as technology for succeeding with SPI and, thus, to provide researchers and practitioners with important new insights regarding the critical factors of success in SPI.

Over the last few years the Software Engineering Institute has participated in several workshops and site visits with maturity level 4 and 5 software organizations. This paper summarizes the lessons learned from those interactions with high maturity organizations, while preserving the anonymity of the organizations involved. Specific areas of interest include statistical process and quality control and product lines/families, but the observations cover a variety of engineering and management practices, including issues outside the scope of the Capability Maturity Model for Software. A survey was distributed to informally test the anecdotal observations about high maturity practices. 1. Introduction During the last several years, we have had the privilege of working with a number of high maturity software organizations, as measured by the Capability Maturity Model for Software (CMM ) [Paulk95], in workshops, conferences, assessments, and site visits. The Software Engineering I...

This paper describes an industrial experience in process improvement at one of the Unisys development labs in Australia. Following a Capability Maturity Model (CMM) mini-assessment, the organization is undertaking significant changes in the requirements management process, which include the introduction of group session approaches to requirements analysis and a structured method for writing requirements. An empirical evaluation which investigated other aspects of the process improvement than the CMM model indicates tangible benefits as well as perceived long-term benefits during design and testing. Findings confirm that a more thorough requirements analysis results in more clearly defined, better understood and specified requirements, and an enhanced ability to address the market needs and product strategy requirements. The catalyst behind these improvements included project management leadership, managing the human dimension, collaboration among stakeholders and senior management support.

This paper describes ten factors that affect organizational change in software process improvement initiatives based on the Capability Maturity Model or the ISO 9000 quality standards. It also assesses the relative importance of these factors and compares the findings with the results of previous research into organizational change in software process improvement. The paper is based on an analysis of published experience reports and case studies of 56 software organizations that have implemented an ISO 9000 quality system or that have conducted a CMMbased process improvement initiative.

There are now many methods for assessing the maturity and capabilities of software engineering organizations. Assessment scores are being used in making the contract award decision by the U.S. Navy [Ru93] and Air Force [SK95], as well as in commercial organizations [MC96]. Furthermore, conformance to process standards such as ISO 9001, as determined during an audit, is a necessity for doing business in many European countries. Software process assessments are also an essential element of the self-improvement cycle for many organizations (e.g., see[Ba96][Dy95]). There has been a relative dearth of empirical investigations of the core premises of most contemporary assessment methods and their underlying models. Software organizations were being required and/or pressured to conform to certain standards (e.g., to be at Level 3 on the CMM) without adequate empirical evidence supporting the assumptions made by these standards. At least partly because of this, a certain