Software and Systems Engineering Integration

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.