Systems engineers working today face many challenges, both in building the complex systems of systems of the future and in building the complex systems of which they are composed. Systems engineers need to be able to design around stable requirements when there are long-lead manufactured items required, and they also need to evolve the design along with changing requirements for larger systems. Software plays an integral role in helping systems engineers accomplish these goals.
The importance of software engineering to systems engineering, and vice-versa, cannot be overstated. As I stated in an earlier blog post
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.
In this post, I examine whether the ways in which systems engineers talk about software has changed in the two decades by examining INCOSE's Systems Engineering journal. The reason for this inquiry is to understand whether systems engineers have come to accept that software is a huge and growing fraction of the systems they engineer and to understand how to partner with them on programs and in acquisition efforts.
This post is the first in a series introducing our research into software and system complexity and its impact in avionics.
On July 6, 2013, an Asiana Airlines Boeing 777 airplane flying from Seoul, South Korea, crashed on final approach into San Francisco International airport. While 304 of the 307 passengers and crew members on board survived, almost 200 were injured (10 critically) and three young women died. The National Transportation Safety Board (NTSB) blamed the crash on the pilots, but also said "the complexity of the Boeing 777's auto throttle and auto flight director--two of the plane's key systems for controlling flight--contributed to the accident."
In today's systems it's very hard to know where systems end and software begins. Software performs an integrating function in many systems, often serving as the glue interconnecting other system elements. We also find that many of the problems in software systems have their roots in systems engineering, which is an interdisciplinary field that focuses on how to design and manage complex systems over their life cycles. For that reason, staff at the Carnegie Mellon University Software Engineering Institute (SEI) often conduct research in the systems engineering realm. Process frameworks, architecture development and evaluation methods, and metrics developed for software are routinely adapted and applied to systems. Better systems engineering supports better software development, and both support better acquisition project performance. This blog post, the latest in a series on this research, analyzes project performance based on systems engineering activities in the defense and non-defense industries.
The role of software within systems has fundamentally changed over the past 50 years. Software's role has changed both on mission-critical DoD systems, such as fighter aircraft and surveillance equipment, and on commercial products, such as telephones and cars. Software has become not only the brain of most systems, but the backbone of their functionality. Acquisition processes must acknowledge this new reality and adapt. This blog posting, the second in a series about the relationship of software engineering (SwE) and systems engineering (SysE), shows how software technologies have come to dominate what formerly were hardware-based systems. This posting describes a case study: the story of software on satellites, whose lessons can be applied to many other kinds of software-reliant systems.
As part of an ongoing effort to keep you informed about our latest work, I would like to let you know about some recently published SEI technical reports and notes. These reports highlight the latest work of SEI technologists in secure coding, CERT Resilience Management Model, malicious-code reverse engineering, systems engineering, and incident management. This post includes a listing of each report, author(s), and links where the published reports can be accessed on the SEI website.
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.
Building a complex weapon system in today's environment may involve many subsystems--propulsion, hydraulics, power, controls, radar, structures, navigation, computers, and communications. Design of these systems requires the expertise of engineers in particular disciplines, including mechanical engineering, electrical engineering, software engineering, metallurgical engineering, and many others. But some activities of system development are interdisciplinary, including requirements development, trade studies, and architecture design, to name a few. These tasks do not fit neatly into the traditional engineering disciplines, and require the attention of engineering staff with broader skills and backgrounds. This need for breadth and experience is often met by systems engineers. Unfortunately, system engineering is often not valued among all stakeholders in the Department of Defense (DoD), and is often the first group of activities to be eliminated when a program is faced with budget constraints. This blog post highlights recent research aimed at demonstrating the value of systems engineering to program managers in the DoD and elsewhere.