Abstract
With software an increasingly significant component of most products, it is vital that teams of software and systems engineers collaborate effectively to build cost effective, reliable products. This article will identify the key aspects of software engineering and systems engineering in an effort to highlight areas of consensus and conflict to support current efforts by practitioners and academics in the both disciplines in redefining and integrating their professions and bodies of knowledge. In response to increasing concerns about software development failures, the Software Engineering Institute (SEI) pioneered a software process improvement model in 1988, with the fully developed version of their Capability Maturity Model for Software (SW- CMMâ) appearing in 1993. Since the early nineties, there have been comparable improvement models introduced in the systems engineering community as well, some of which have been published and widely accepted include: Systems Engineering Capability Maturity Model (SE-CMM), also known as the Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM), and the Integrated Product Development Capability Maturity Model (IPD-CMM). The resulting avalanche of models and standards has been described by Sarah Sheard (Software Productivity Consortium) as a “Framework Quagmire”. In December of 2000, the SEI initiated the Capability Maturity Model–Integrated (CMMISM) project, which combines best practices from the systems and software engineering disciplines. (Note: CMMâ and CMMISM are copyrights and service marks of the Software Engineering Institute.) Recent studies (Carter et al., 2003; Goldenson & Gibson, 2003) have validated the SEI’s assertion the each of the disciplines benefit from incorporation of principles from the other. Moreover, there appears to be no fundamental differences between the disciplines that would prevent their integration.
TopBackground
There is great hope that the SEI imitative will provide the impetus to overcome some long-standing discipline boundaries. The nature of the systems and software engineering work has led to terminology differences rooted in the very descriptions of the disciplines. One important problem with software is the difficulty in understanding its inherent level of quality.
Issues and concerns regarding such an integration were articulated by Barry Boehm and Fred Brooks as early as 1975. Boehm suggested that the adoption of systems engineering reliability techniques by software engineers was counterproductive. Moreover, Brooks’ Law suggests that a common systems engineering solution to schedule slippage (add more people) will only make late software projects even later.
More recently, Boehm (1994) expressed concerns that, in spite of the central function of software in modern systems, the two engineering disciplines have not been well integrated. Boehm articulated similarities and differences as shown in Figure 1.
Figure 1. Software and system engineering similarities and differences
Software engineering, as defined by the Institute of Electrical and Electronics Engineers (IEEE, 2001), is: (1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, that application of engineering to software; (2) The study of approaches as in (1)—and further identifies the body of knowledge for software engineering to be: software requirements, software design, software construction, software testing, software maintenance, software configuration management, software engineering management, software engineering process, software engineering tools and methods, and software quality.
Key Terms in this Chapter
Process Improvement: A program of activities designed to improve the performance and maturity of the organization’s processes, and the results of such a program. Quality: The ability of a set of inherent characteristics of a product, product component, or process to fulfill requirements of customers.
Process Architecture: Describes the ordering, interfaces, interdependencies, and other relationships among the process elements in a standard process. Process architecture also describes the interfaces, interdependencies, and other relationships between process elements and external processes (CMMI).
Software Engineering: The software engineering discipline covers the development of software systems. Software engineers focus on applying systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.
This work was previously published in Encyclopedia of Information Science and Technology: edited by M. Khosrow-Pour, pp. 2551-2556, copyright 2005 by Information Science Reference, formerly known as Idea Group Reference (an imprint of IGI Global)