Software CMM Research Articles

10.1 Achieving CMMI level 3

AbstractThales Training and Simulation (TT&S) SA achieved CMMI level 3 in June 2003. This covers Software, Project Management and Systems Engineering.Following an action plan on Software (CMM level 3 achieved in 1996) TT&S defined a strategy leading to reach CMMI level 3 for all disciplines (including Bid and Project management). This paper aims at sharing : lessons learnt to reach CMMI level 3 benefits perceived by TT&S brakes encountered during implementation of the action plan Three keys strongly contributed to this success. The first one is the experience that TT&S gained during the Software CMM action plan. The second one is the involvement of management. The third one is measurement of progress through internal assessmentsNote: CMM and CMMI are registered copyrights of CMU/SEI

Realizing the benefits of the CMMISM with the CeBASE method

AbstractFuture systems will be increasingly software‐intensive, but the type of software development they will need is not well covered by current development and maturity models such as the waterfall model and Software Capability Maturity Model® (CMM®). Future development of software‐intensive systems will need situation‐specific balancing of discipline and flexibility to address such issues as COTS, open source, distribution, mobility rapid change, agents, collaboration support, and simultaneous achievement of rapid development and high dependability. This article shows how the CMMISM's integration of modern systems engineering, software engineering, and integrated process and product development concepts provides a framework for redressing the shortfalls of the Software CMM®, and for enabling projects and organizations to achieve the right balance of discipline and flexibility for their particular situations. But the CMMISM has shortfalls of its own. It provides little guidance on how to define and execute specific processes for a specific project or organization. The article summarizes various process model generators for software intensive systems such as the spiral, the Rational Unified Process (RUP), MBASE, and the CeBASE Method. It concludes that the CeBASE Method best covers the full range of concerns in the CMMISM, resolves its practice‐focus shortfalls, and covers additional best practices not in the CMMISM, such as business case analysis, requirements prioritization, and evolution requirements. © 2002 John Wiley & Sons, Inc. Syst Eng 5: 73–88, 2002; DOI 10.1002/sys.10016

Pursuing coherence in software process assessment and improvement

AbstractThe improvement of software development processes is certainly one of the top priorities of the IT industry. Software has become the most critical component in any modern product and service. All sectors of our society have been affected and influenced by the introduction of software and software‐based features. To support the improvement of software development processes, a number of process assessment and improvement techniques have been proposed and applied in a significant number of cases. However, the evaluation of the effects produced by the introduction of assessment and improvement methods and models is raising much controversy among researchers and practitioners. In particular, it is extremely difficult to evaluate if, under what circumstances, and to what extent an assessment approach (and the consequent improvement plan) has had a direct, significant and positive impact on the company performance. This paper reports our experiences in conducting process assessment/improvement initiatives in three companies. The assessments have been based on SEI's Capability Maturity Model for software (Software CMM). The main finding of this study is that effective process assessment (and consequently improvement) models/methods must necessarily pursue the coherent improvement of all the aspects of a company and not just of the engineering factors. In the paper we provide a detailed discussion of the case studies and of the motivations that justify our position. Also, as a synthesis of our experiences, we outline a strategy to software process assessment and improvement that takes into account the concerns and requirements we have identified in our work. Copyright © 2001 John Wiley & Sons Ltd

Software maintenance from a service perspective

In this paper we investigate the differences between software maintenance and software development from a service point of view, and the consequences for the maturity of software maintenance organizations. We argue that software maintenance can be seen as providing a service, whereas software development is concerned with the development of products. Differences between products and services affect the way in which customers assess their respective quality. Consequently, customers judge the quality of software maintenance differently from how they judge the quality of software development. This in turn implies a need to carry out software maintenance through different processes from those used by the average software development organization. We discuss two overall approaches to achieving a high-quality IT service organization which include these service-specific processes: ITIL and the IT service capability maturity model. ITIL is a set of best practices widely used within the IT service industry. The IT service CMM is a maturity growth model akin to the software CMM. Copyright © 2000 John Wiley & Sons, Ltd.

3 CMMI and Systems Engineering

AbstractIn late 1999 the systems engineering community will be presented with a new process maturity model produced by the Capability Maturity Model Integration (CMMI) project. The immediate significance to systems engineers is that the new model offers, for the first time, strong integration and consistency with the Software CMM (SW‐CMM v2). Organizations can choose to use one or more of several highly integrated models – a Systems Engineering CMM, a Software CMM and a Systems + Software CMM.Organizations can further choose to use a continuous or a staged version of each model and be assured of equivalent content. This paper describes the relationship of the new CMMI models to the recently completed EIA/IS 731, Systems Engineering Capability Model, and the potential impacts to systems engineering process appraisal and improvement. An overview of the CMMI models and terminology is provided as a basis for describing the relation to the EIA/IS 731

A structured approximate reasoning-based approach for gathering ?lessons learned? information from system development projects

In this paper, a structured approach for collecting “lessons learned” information obtained from system development projects is discussed. To aid in the analysis of lessons learned, the collection framework incorporates techniques associated with approximate reasoning. The primary goal of collecting lessons learned is to improve organizational and project performance. Therefore, this approach concentrates on focusing the collection of lessons learned on this goal. This approach ties the collection of lessons learned to the process model used by the organization. This model is typically based on capability models such as the Systems Engineering Capability Maturity Model (SE-CMM1) and Software CMM (SW-CMM), as well as process standards such as ISO 9000 and the organization's standard engineering practices. This approach utilizes the organization's process framework to provide a structured, lessons learned program which can be used by projects during and at the completion of their execution. © 1999 John Wiley & Sons, Inc. Syst Eng 2: 242–247, 1999

3.5.1 Developing and Applying a Joint SW‐CMM and SECM Appraisal Methodology

ABSTRACTPeriodic appraisals of process maturity as measured by both systems and software maturity models are costly undertakings and divert project engineers and managers from their primary focus. To minimize the cost and impact, a single appraisal method that addresses both systems and software engineering in a timely and cost‐effective manner is needed. This presentation discusses the current state of software engineering and systems engineering maturity models (using the EIA 731 SECM and the SEI CMM for Software) in terms of their commonalties and unique features and describes one company's efforts to develop a joint appraisal method.

2.5.4 How Maturity Modeling Saved My Softball Team

ABSTRACTThe general acceptance and success of the Software CMM has led to a proliferation of copycat models. There are reportedly about four dozen in some stage of creation. Systems engineering is now deeply involved in this movement. These models can have great benefit to a systems engineering program. However, there is also risk of overemphasis on the institutionalization of processes rather than the value or effectiveness of the effort. This paper looks at the traps one can fall into and how to avoid them.

Towards mature IT services

Many organizations provide information technology services, either to external or internal customers. They maintain software, operate information systems, manage and maintain workstations, networks or mainframes or provide contingency services. A widely used framework on IT service quality (at least in the Netherlands) is the Information Technology Infrastructure Library (ITIL), which seeks to publish a standard of service quality and best practices. However, it does not provide organizations with the methodology needed to assess and improve their service processes based on assessments. We propose an Information Technology Service Capability Maturity Model (IT Service CMM) that can be used to assess the maturity of IT service processes and identify directions for improvement. This IT Service CMM originates from our efforts to develop a quality improvement framework that was targeted at helping service organizations to improve service quality. Case studies which introduced parts of our framework into different organizations had mixed results. A service process capability maturity scale, similar to the Software CMM, allowed us to explain many of the differences observed. At the same time, the IT Service CMM suggests ways to improve the service process capability. Copyright © 1998 John Wiley & Sons, Ltd

Leveraging your CMM efforts for IEEE/EIA 12207

Many companies use the Capability Maturity Model for software to improve the processes used by their development teams. The processes put into place to ascend this maturity ladder will serve them well as they become compliant with the new IEEE/EIA 12207 standard. The article addresses the relationship between this new standard and the CMM for software.

Analysis of System Requirements Negotiation Behavior Patterns

ABSTRACTRoughly 35 three‐person teams played the roles of user, customer, and developer in negotiating the requirements of a library information system. Each team was provided with a suggested set of stakeholder goals and implementation options, but were encouraged to exercise creativity in expanding the stakeholder goals and in creating options for negotiating an eventually satisfactory set of system requirements.The teams consisted of students in a first‐year graduate course in software engineering at USC. They were provided with training in the Theory W (win‐win) (Boehm‐Ross, 1989) approach to system requirements determination and the associated USC WinWin groupware support system (Boehm, et al, 1995)(Horowitz, 1996). They were required to complete the assignment in two weeks.Data was collected on the negotiation process and results, with 23 projects providing sufficiently complete and comparable data for analysis. A number of hypotheses were formulated about the results. Some of the hypotheses addressed the use and potential improvement of WinWin features. Others addressed more general process issues, e.g. that the uniform set of initial conditions would lead to uniform results. This paper summarizes the data analysis, which shows that expectations of uniform group behavior were generally not realized.In terms of goals for relevant Capability Maturity Models (CMM's), this implies that the System Engineering CMM's Level 2 goal of Planned and Tracked processes is more realistic than the Software CMM's Level 2 goal of Repeatable processes.

2.2.3 PEOPLE CAPABILITY MATURITY MODEL (P‐ CMM): INCORPORATING HUMAN RESOURCES INTO PROCESS IMPROVEMENT PROGRAMS

AbstractThe People Capability Maturity Model (P‐ CMM) is an adaptation of the Capability Maturity Model SM for Software (CMM SM) focused on developing the organization's talent. The motivation for the P‐ CMM is to radically improve the ability of software organizations to attract, develop, motivate, organize, and retain the talent needed to steadily improve software development capability. Although being initially developed with a focus on software and information systems development, the principles and many practices of the P‐ CMM apply equally to systems engineering. There is thus on the horizon a family of capability maturity models to help organizations improve their development capability: the CMM for Software, the Systems Engineering CMM (SE‐CMM), and the P‐CMM.