System Affordability

Increasing competitive pressures and scarcity of resources create a high priority for SE techniques to improve systems affordability. Several recent initiatives have made affordability their top technical priority, and recommend improved systems autonomy and human performance augmentation as research priorities to reduce labor costs, more efficient equipment to reduce supplies costs, and adaptable systems to cost-effectively extend systems’ useful lifetimes.

Yet, methods for cost and schedule estimation and more affordable systems development processes have not changed significantly to address these new challenges and opportunities. New methods are needed for better cost and schedule estimation; tradeoff analyses between cost, schedule, effectiveness, and resilience; and methods to adjust priorities and deliverables to meet budgets and schedules, all in the context of the rapid changes underway in technology, competition, operational concepts, and workforce characteristics.

In many cases, cost and schedule estimation is decoupled from technical systems engineering tradeoff analyses and decision reviews. Most models and tools focus on evaluating either cost-schedule performance or technical performance, but not the tradeoffs between the two. Only in 2010 did the INCOSE SE Handbook include affordability as one of the criteria for evaluating requirements.

Often, however, organizations and their systems engineers have focused on affordability as minimizing acquisition costs. They would often be drawn into easiest-first approaches that would produce early successes, but that frequently would also produce brittle, expensive-to-change architectures that increased technical debt and life cycle costs. This has created a stronger focus on systems engineering for maintainability, flexibility, and evolvability.

A key SE principle in this regard involves modularization of the system’s architecture around its most frequent sources of change. Then when changes are needed, their side effects are contained in a single systems element, rather than rippling across the entire system. This approach creates needs for three further improvements. One is to refocus the system requirements not only on a snapshot of current needs, but also on including the most likely sources of requirements change, or evolution requirements. Another is to monitor and build up knowledge of the most frequent sources of change to better identify evolution requirements. A third is to evaluate the system’s proposed architecture on how well it will support the evolution requirements as well as the initial snapshot requirements.

An extension of this approach is to identify families of products or product lines, in which the SEs identify the commonalities and variabilities across the product line, and to develop architectures for creating (and evolving) the common elements once, with plug-compatible interfaces for inserting the variable elements. This approach has been extended into principles for service-oriented system elements, which are characterized by their inputs, outputs, and assumptions, and which can easily be composed into systems in which the sources of change were not anticipated.

This approach can also be extended into classes of smart or autonomous systems, which include many sensors that identify needed changes, and autonomous agents that can determine and effect such changes in microseconds, or much more rapidly than can humans. Such autonomy can not only reduce reaction time, but also reduce the amount of human labor needed to operate the systems, thus improving affordability.

Here also, though, there are pitfalls for the unwary. There are several hazardous failure modes for autonomous systems. For example, one failure mode is system instability due to positive feedback, in which an agent will sense a parameter reaching a control limit and give the system a strong push in the other direction, after which the system will rapidly approach the other control limit, causing the (or another) agent to give it an even stronger push in the original direction, and so on. Another is that autonomous agents are frequently self modifying, which makes their failures difficult to debug when the failure occurs after several self-modifications. Another is the well-known weakness of autonomous agents to do commonsense reasoning about why human operators have made system control decisions, and to make the wrong conclusions and resulting decisions about controlling the system. Another is that multiple agents may make contradictory decisions about controlling the system, and lack the ability to understand the contradiction or to negotiate a solution that will resolve it.

These highlight the need for human supervision of such autonomous systems, along with better methods for trend analysis and human visualization of undesired trends. It also implies extending the focus from life cycle costs to total ownership costs, which include the cost of owning systems whose failures include losses in sales, profits, mission effectiveness, or human quality of life.

This creates a further need to evaluate affordability with respect to the value added by the system under consideration. In principle, this involves evaluating the system’s total cost of ownership with respect to its mission effectiveness and resilience across a number of operational scenarios. However, determining the appropriate scenarios and their relative importance weights is not easy, particularly for multi-mission systems of systems. Often, the best that can be done is a mix of scenario evaluation and evaluation of general attributes such as cost, schedule, performance, etc.

Further, this surfaces the challenge that different success-critical stakeholders will have different preferences or utility functions for these various system attributes, and that converging on a mutually satisfactory choice among the candidate system solutions involves the resolution of the multi-criteria decision analysis (MCDA) problem among the stakeholders. This is a well-known problem, with several paradoxes such as the Arrow Impossibility Theorem of inability to guarantee a mutually optimal solution among several stakeholders, and several paradoxes in stakeholder preference aggregation, in which different voting procedures will produce different winning solutions. Still, groups of stakeholders need to make decisions, and various negotiation support systems enable people to better understand each others’ utility functions and to arrive at a mutually satisfactory decision in which nobody gets everything that they want, but everyone is at least as well off as they are with the current system.

References

Citations

Citations

Primary References

Primary references.

Additional References

Additional References.