Software Intensive System of Systems

The domain I work in is categorized as Software Intensive System of Systems (SISoS). In this domain, we applied traditional program and project management methods for cost and schedule management at the top level. This means a Capabilities Based Plan for what business and operational capabilities are needed in what order to fulfill the Mission and Vision of the enterprise funding the program. The development of the software and sometimes the development of the hardware is done in an agile manner, using one of several Agile development methods - SAFe, Scrum for example

The system can be a business system, a collection of hardware and software for defense or space, weapons systems, business management systems. But these systems all have the same things in common. [1]

In 2019, the embedded system domain in the US alone was $100 Billion.

Here's a collection of presentations on SISoS from the University of Paderborn, Software Engineering Group, that is no longer available, but I've downloaded them before they went away

• Software Engineering for Software Intensive Systems: I Introduction
• Software Engineering for Software Intensive Systems: II Foundations
• Software Engineering for Software Intensive Systems: III The Development Life Cycle
• Software Engineering for Software Intensive Systems: IV Requirements
• Software Engineering for Software Intensive Systems: V Analysis & Design
• Software Engineering for Software Intensive Systems: VI Implementation
• Software Engineering for Software Intensive Systems: VII Verification & Validation
• Software Engineering for Software Intensive Systems: VIII Summary and Outlook

Along with this material, here's a workshop on the same topic

• "Engineering Software-Intensive Systems," Edinburgh, UK, 22-23 May 2004

"System of Systems” are not monolithic. They have five characteristics (Maier, 1998) that make the system of systems designation (Krygiel, 1999; Carlock & Fenton, 2001). 

A System of Systems possess:

1. Operational Independence of the Individual Systems. A system of systems is composed of systems that are independent and useful in their own right. If a system of systems is disassembled into the component systems, these component systems are capable of independently performing useful operations independently of one another.
2. Managerial Independence of the Systems. The component systems not only can operate independently,
   they generally do operate independently to achieve an intended purpose. The component
   systems are generally individually acquired and integrated and they maintain a continuing operational
   existence that is independent of the system of systems.
3. Geographic Distribution. Geographic dispersion of component systems is often large. Often, these systems can readily exchange only information and knowledge with one another, and not substantial quantities of physical mass or energy.
4. Emergent Behavior. The system of systems performs functions and carries out purposes that do not reside in any component system. These behaviors are emergent properties of the entire system of systems and not the behavior of any component system. The principal purposes of supporting the engineering of these systems are fulfilled by these emergent behaviors.
5. Evolutionary Development. A system of systems is never fully formed or complete. Development of these systems is evolutionary over time and with structure, function and purpose added, removed, and modified as experience with the system grows and evolves over time.

In the SISoS domain, there are several critical success factors, that may not be found in other domains:

• Capabilities drive the development of requirements
• Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters are the units of measure meaningful to the decision-makers.
• Cost, Schedule, and these measures are tightly interconnected.
• All development takes place in the presence of uncertainty and the risk this uncertainty produces.
• To make decisions about any of the work that impacts the four measures in the presence of the uncertainty requires we make estimates. This is an immutable principle based in the principles of decision making in the presence of uncertainty.

So when you hear estimates are NOT needed to make decisions in the presence of uncertainty, those making that claim must have:

• No uncertainties
• No Deadlines
• No not to exceed budgets
• No mandatory Effectiveness and Performance targets for success

If you are working in a SISoS domain and need further information on how to estimate in the presence of uncertainty here's a starting point

 

[1] On the Systems Engineering and Management of Systems of Systems and Federations of Systems, Andrew P. Sage and Christopher D. Cuppan, Information ● Knowledge ● Systems Management 2 (2001) 325–345, IOS Press