By Sarah Sheard
Member of the Technical Staff
Software Solutions Division
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 astelephones 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.
By Douglas C. Schmidt
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.
By Sarah A. Sheard
Software Solutions Division
This post is the first in a series on this topic.
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.
By Joseph Elm
Senior Member of the Technical Staff
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.