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...

The Capability Maturity Model SM for Software developed by the Software Engineering Institute has had a major influence on software process and quality improvement around the world. Although the CMM has been widely adopted, there remain many misunderstandings about how to use it effectively for business-driven software process improvement, particularly for small organizations and small projects. Some of the common problems with interpreting the Software CMM for the small project/organization include: What does "small" mean? In terms of people? Time? Size of project? Criticality of product? What are the CMM "requirements"? Are there key process areas or goals that should not be applied to small projects/organizations? Are there "invariants" of good processes? What are the drivers and motivations that cause abuse of the CMM? This paper discusses how to use the CMM correctly and effectively in any business environment, with examples for the small organization. The conclusion is that the i...

Abstract not found

Two complementary standards are compared, both of which are concerned with the production of quality software. One, IEC 61508, is concerned with the safety of software intensive systems and the other, ISO/IEC TR 15504, takes a process view of software capability assessment. The standards are independent, though both standards build on ISO/IEC 12207. The paper proposes a correspondence between the safety integrity levels (SILs) of 61508 and the capability levels (CLs) of 15504, and considers the appropriateness of the 15504 reference model as a framework for assessing safety critical software processes. Empirical work from the SPICE trials and COCOMO II is used to support the arguments of the paper as well as to investigate their consequences. The development of a 15504 compatible assessment model for software in safety critical systems is proposed. Keywords Process assessment, safety critical software, international standards 1

ISO/IEC 15504 is an emerging international standard on software process assessment. It defines a number of software engineering processes, and a scale for measuring their capability. A basic premise of the measurement scale is that higher process capability is associated with better project performance (i.e., predictive validity). This paper describes an empirical study that evaluates the predictive validity of the capability measures of the ISO/IEC 15504 software development processes (i.e., develop software design, implement software design, and integrate and test). Assessments using ISO/IEC 15504 were conducted on projects world wide over a period of two years. Performance measures on each project were also collected using questionnaires, such as the ability to meet budget commitments and staff productivity. The results provide evidence of predictive validity for the development process capability measures used in ISO/IEC 15504 for large organizations (defined as having more than 50 IT staff).

Abstract not found

de l’information

Abstract not found

Abstract not found

The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange.