The Government Accountability Office (GAO) recently reported that acquisition-program costs typically run 26 percent over budget, with development costs exceeding initial estimates by 40 percent. Moreover, many programs fail to deliver capabilities when promised, experiencing a 21-month delay on average. The report attributes the "optimistic assumptions about system requirements, technology, and design maturity [that] play a large part in these failures" to a lack of disciplined systems engineering analysis early in the program. What acquisition managers do not always realize is the importance of focusing on software engineering during the early systems engineering effort. Improving on this collaboration is difficult partly because both disciplines appear in a variety of roles and practices. This post, the first in a series, addresses the interaction between systems and software engineering by identifying the similarities and differences between the two disciplines and describing the benefits both could realize through a more collaborative approach.

Origins of Systems Engineering and Software Engineering

Systems engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering projects over their lifecycles. System engineering textbooks first appeared around 1960, long before the advent of software engineering. However, systems engineering only emerged as a discipline (complete with journals, documented practices, and academic departments) in the 1990s, well after software engineering had been an established field in computer science. As part of the maturation of systems engineering, two capability models were created that documented its practices; by the time they had been merged and then folded into the Capability Maturity Model Integration (CMMI) model, they had become mainstream. Standards were written in the 1990s that document systems engineering, and in the 2000s they generally have been harmonized with software standards.

The discipline of software engineering traces its roots to a 1968 NATO conference when Mary Shaw named "software engineering" as an aspiration, a field that was needed but not yet developed. Over the next several decades, software engineering both became better defined and grew in new directions. In 1996 Shaw categorized software engineering eras as "Programming-any-which-way," (1955-1965), "Programming-in-the-small," (1965-1975), "Programming-in-the-large" (1975-1985), and as "Programming-in-the-world" (1985-1995). The field continues to evolve, with recent focus on topics such as mobile programming and big data.

Present Day

Software engineers today have adopted many of the principles and practices of systems engineering. For example, developers do not merely react to requirements; they elicit, prioritize, and negotiate changes to them. Developers do not just build code; they architect it, plan it, and establish rules to ensure data is appropriately shared and processed. Software project managers do not just distribute development tasks among individual coders and hope they integrate a seamless final product; they ensure that developers collaborate using plans, processes, and daily standup meetings. Software engineers do not just write programs; they design modular pieces, define integration principles, build for interoperability and modifiability, and perform integration testing.

Meanwhile the systems whose development programs employ systems engineers are increasingly dependent on and controlled by software. For example, the effort to write and maintain software on fighter aircraft now exceeds all other costs. Systems engineers are responsible for ensuring that every part of the system works with every other, and because software represents the intelligence of human-made systems, it is especially important to the integration of the system. Yet many chief systems engineers and program managers have had more experience in mechanical or electrical engineering than in software or software engineering.

Overlap and Uniqueness

Today, systems engineering and software engineering activities overlap to a great extent. The figure below shows activities common to both disciplines in the middle (purple), activities related more to systems engineering than software on the left (red), and activities related more to software than systems on the right (blue). The term "hardware" appears only on the right, because software engineers use it to mean anything that isn't software, but systems engineers generally do not use it. Instead, they call physical subsystems by name (e.g., power, propulsion, structures) or describe disciplines or domains (e.g., mechanical engineering, survivability, software, orbit analysis, launch sequence).

It's important to note in the figure above that systems engineers' responsibilities tend to be broad but not deep, certainly not deep in software. Conversely, while software engineers' responsibilities, may be broad across the software, they are deep in areas necessary to create working code. While most of the comparisons in the figure are fairly intuitive, three points require some elaboration: customer interface, non-functional requirements, and what each group does not do.

1. Although customer interface is a systems engineering role, the software group must participate when discussing software requirements and design. For example, software engineers in Agile sprints often interface one-on-one with a customer representative to select the next development chunk, based on customer priorities.
2. Systems engineers are responsible for ensuring that non-functional requirements are met across the system (qualities they call "ilities" that include reliability, usability, and producibility, for example). Software engineers focus on software "quality attributes" (such as reliability, usability, and maintainability, for example.) The two concepts are clearly similar, but there are some differences; for example, software's counterpart to hardware producibility, namely creating the second and later copies, is trivial, and security and maintainability are more important.
3. The contrast between systems and software engineers is most evident in what they do not do. The role of systems engineers is to balance concerns and perform tradeoff analyses at a high level and not get immersed in details in any area; they consistently delegate details to specialists. System engineers cannot say a task is not their job: if no one else is doing it and it needs to be done, the task defaults to systems engineers. In contrast, software engineers (and mechanical, electrical, etc. engineers) focus their attention inside a domain, mastering details and keeping up with evolving practices and technologies.

Theory and Practice

It is important to note that what systems and software engineers should do is not always the same as what they actually do. In fact, in our experience at the SEI, the majority of complaints each group has about the other results from a failure to meet best practices, rather than from significant differences in best practices. If the waterfall model or a Vee lifecycle model is applied as a rigid sequential process, software engineers can think systems engineering does not apply to software. If the program organizes software engineers only into integrated product teams other than the team responsible for systems engineering, integration and test, then software engineers can get frustrated with their lack of leverage. But good systems engineers also find these situations to be frustrating. Similarly, both systems and software engineers get frustrated if "agile" is used as an excuse to address only nominal-case functional requirements and not system level requirements like security and scalability.

Needed Knowledge

Most of today's systems engineers were not software engineers or computer scientists first, nor do many of them have significant background or experience with software engineering techniques, tools, and methods. What software concepts they need to know to perform systems engineering on software-reliant systems effectively is an interesting question, which I will address in a future blog post. Few universities offer a joint degree in systems and software engineering (exceptions include Cornell University and Carnegie Mellon, which offer a joint certificate in systems and software engineering). Moreover, systems engineering programs ordinarily do not require a foundational understanding of software.

The Graduate Software Engineering (GSWE) 2009 guidelines provide recommendations for how to integrate systems engineering into software engineering education. The Systems Engineering Research Center/University Affiliated Research Center (SERC-UARC) published a Systems Engineering Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) in 2012, which includes a graduate reference curriculum for a systems engineering master's program, but its relationship to software is minimally discussed (in two pages).

The Road Ahead

The earlier part of this blog identified the similarities and differences between the disciplines of software engineering and systems engineering. The remainder of this blog outlines the benefits both could realize through a more collaborative approach. At this time, there are many disconnects between software and systems engineers that could be minimized through better collaboration. Software engineers could get involved in key systems architecting decisions so that the best software architecture could be easier to build. Systems engineers could reduce work that the software engineers find to be non-value added, and would receive help from software engineers in analyzing tradeoffs. In sum, a breadth+depth combination would identify innovative ideas to solve problems and exploit opportunities.

To ensure that future software-reliant systems (and systems of systems) can be built effectively, a new collaborative relationship between systems engineering and software engineering must become the norm. Moreover, there is a clear and compelling need to understand which roles must be filled by which types of professionals and which actions must be performed to ensure the two disciplines work together effectively. Improving the relationship will require overcoming the negative emotions that sometimes appear. (Both groups at a talk on systems and software that I presented at INCOSE Three Rivers Chapter in July 2013 agreed that the others "are arrogant and not as smart as they think they are.") By learning to work together effectively, systems engineers and software engineers can help increase the probability of success of new and planned ultra-large-scale software-reliant systems and systems-of-systems. In particular, they must understand each other's strengths and objectives and work together to support them.

In future posts in this blog series, I will address the questions systems engineers must ask software engineers at the earliest program phases, and vice versa. I will examine the knowledge that systems engineers should have about software and propose how to provide them with that knowledge. I will also show that typical software engineering tasks map to systems engineering tasks and fulfill much of what customers are looking for when acquiring software-reliant systems.

What do you think systems engineering should know about software engineering? What should software engineers know about systems engineering? Please leave us feedback in the comments section below.

Additional Resources

To read the SEI technical report, The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=34061.