Difference between revisions of "Affordability"

From SEBoK
Jump to: navigation, search
(Discipline Relationships)
Line 42: Line 42:
==Discipline Interactions==
==Discipline Standards==
==Discipline Standards==

Revision as of 17:08, 29 July 2016

A system is affordable to the degree that system performance, cost, and schedule constraints are balanced over the system life, while mission needs are satisfied in concert with strategic investment and organizational needs (INCOSE 2011). Design for affordability is the practice of considering affordability as a design characteristic or constraint.

Increasing competitive pressures and the scarcity of resources demand that systems engineering (SE) improve affordability. Several recent initiatives have made affordability their top technical priority. They also call for a high priority to be placed on research into techniques — namely, improved systems autonomy and human performance augmentation — that promise to reduce labor costs, provide more efficient equipment to reduce supply costs, and create adaptable systems whose useful lifetime is extended cost-effectively.

Yet methods for cost and schedule estimation have not changed significantly to address these new challenges and opportunities. There is a clear need for

  • new methods to analyze tradeoffs between cost, schedule, effectiveness, and resilience;
  • new methods to adjust priorities and deliverables to meet budgets and schedules; and
  • more affordable systems development processes.

All of this must be accomplished the context of the rapid changes underway in technology, competition, operational concepts, and workforce characteristics.


Historically, cost and schedule estimation has been decoupled from technical SE 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. Meanwhile, organizations and their systems engineers often focus on affordability to minimize acquisition costs. They are then drawn into the easiest-first approaches that yield early successes, at the price of being stuck with brittle, expensive-to-change architectures that increase technical debt and life cycle costs.

Two indications that the need for change is being recognized in systems engineering are that the INCOSE SE Handbook now includes affordability as one of the criteria for evaluating requirements (INCOSE 2011); and, there is a trend in SE towards stronger focus on maintainability, flexibility, and evolution (Blanchard, Verma, and Peterson 1995).

There are pitfalls for the unwary. Autonomous systems experience several hazardous failure modes, including

  • system instability due to positive feedback — where an agent senses a parameter reaching a control limit and gives the system a strong push in the other direction, causing the system to rapidly approach the other control limit, causing the agent (or another) to give it an even stronger push in the original direction, and so on
  • self-modifying autonomous agents which fail after several self-modifications — the failures are difficult to debug because the agent’s state has been changing
  • autonomous agents performing weakly at commonsense reasoning about system control decisions by human operators, and so tend to reach wrong conclusions and make wrong decisions about controlling the system
  • multiple agents making contradictory decisions about controlling the system, and lacking the ability to understand the contradiction or to negotiate a solution to resolve it

Modularization of the system’s architecture around its most frequent sources of change (Parnas 1979) is a key SE principle for affordability. This is because when changes are needed, their side effects are contained in a single systems element, rather than rippling across the entire system.

This approach creates the need for three further improvements:

  • refocusing the system requirements, not only on a snapshot of current needs, but also on the most likely sources of requirements change, or evolution requirements;
  • monitoring and acquiring knowledge about the most frequent sources of change to better identify requirements for evolution; and
  • evaluating the system’s proposed architecture to access how well it supports the evolution requirements, as well as the initial snapshot requirements.

This approach can be extended to produce several new practices. Systems engineers can

  • identify the commonalities and variability across the families of products or product lines, and develop architectures for creating (and evolving) the common elements once with plug-compatible interfaces for inserting the variable elements (Boehm, Lane, and Madachy 2010);
  • extrapolate principles for service-oriented system elements that are characterized by their inputs, outputs, and assumptions, and that can easily be composed into systems in which the sources of change were not anticipated; and
  • develop classes of smart or autonomous systems whose many sensors identify needed changes, and whose autonomous agents determine and effect those changes in microseconds, or much more rapidly than humans can, reducing not only reaction time, but also the amount of human labor needed to operate the systems, thus improving affordability.

System Description

Discipline Management

Discipline Relationships



Discipline Standards

Personnel Considerations

Autonomous systems need human supervision, and the humans involved require better methods for trend analysis and visualization of trends (especially, undesired ones).

There is also the need, with autonomous systems, to extend the focus from life cycle costs to total ownership costs, which encompass the costs of failures, including losses in sales, profits, mission effectiveness, or human quality of life. This creates a further need to evaluate affordability in light of 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 is not easy, particularly for multi-mission systems of systems. Often, the best that can be done involves a mix of scenario evaluation and evaluation of general system attributes, such as cost, schedule, performance, and so on.

As for these system attributes, different success-critical stakeholders will have different preferences, or utility functions, for a given attribute. This makes converging on a mutually satisfactory choice among the candidate system solutions a difficult challenge involving the resolution of the multi-criteria decision analysis (MCDA) problem among the stakeholders (Boehm and Jain 2006). This is a well-known problem with several paradoxes, such as Arrow’s impossibility theorem that describes the inability to guarantee a mutually optimal solution among several stakeholders, and several paradoxes in stakeholder preference aggregation in which different voting procedures produce different winning solutions. Still, groups of stakeholders need to make decisions, and various negotiation support systems enable people to better understand each other’s utility functions and to arrive at mutually satisfactory decisions, in which no one gets everything that they want, but everyone is at least as well off as they are with the current system.

Also see System Analysis for considerations of cost and affordability in the technical design space.




Primary References

Works Cited

Blanchard, B., D. Verma, and E. Peterson. 1995. Maintainability: A Key to Effective Serviceability and Maintenance Management. New York, NY, USA: Wiley and Sons.

Boehm, B., J. Lane, and R. Madachy. 2010. "Valuing System Flexibility via Total Ownership Cost Analysis." Proceedings of the NDIA SE Conference, October 2010, San Diego, CA, USA.

Boehm, B., and A. Jain. 2006. "A Value-Based Theory of Systems Engineering." Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium (IS), July 9-13, 2006, Orlando, FL, USA.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2. p. 79.

Parnas, D.L. 1979. "Designing Software for Ease of Extension and Contraction." IEEE Transactions on Software Engineering. 5 (2): 128-138.

Primary References

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2. p. 79.

Blanchard, B., D. Verma, and E. Peterson. 1995. Maintainability: A Key to Effective Serviceability and Maintenance Management. New York, NY, USA: Wiley and Sons.

Parnas, D.L. 1979. "Designing Software for Ease of Extension and Contraction." IEEE Transactions on Software Engineering. 5 (2): 128-138.

Additional References

Kobren, Bill. 2011. "Supportability as an Affordability Enabler: A Critical Fourth Element of Acquisition Success Across the System Life Cycle." Defense AT&L: Better Buying Power. Accessed August 28, 2012. Available: http://www.dau.mil/pubscats/ATL%20Docs/Sep-Oct11/Kobren.pdf.

Myers, S.E., P.P. Pandolfini, J.F. Keane, O. Younossi, J.K. Roth, M.J. Clark, D.A. Lehman, and J.A. Dechoretz. 2000. "Evaluating affordability initiatives." Johns Hopkins APL Tech. Dig. 21 (3): 426–437.

< Previous Article | Parent Article | Next Article >
SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus