A Complex Adaptive Systems Engineering (CASE)...

IEEE Systems Conference (SysCon)

18-21 April 2016 – Orlando, FL

A Complex Adaptive Systems Engineering

(CASE) Methodology—The Ten-Year Update

B. E. White, Ph.D.

See Notes Page

Tuesday p.m., 18 April 2016

Hyatt Regency Grand Cypress Hotel

Copyright 2016 by Brian E. White. 1 4/14/2016


18-21 April 2016 – Orlando, FL 4/14/2016 2

• Acronyms – CASE: Complex Adaptive Systems Engineering

– CS: Complex System – CSE: Complex Systems Engineering

– ESE: Enterprise Systems Engineering

– M&S: Modeling and Simulation

– SE: Systems Engineering

– SEA: Systems Engineering Activity

– SoS: System of Systems

– SoSE: System of Systems Engineering

– SSM: Soft Systems Methodology

• Statement of Objectives

• CASE Methodology – Advocate Workable Methodology

– Apply CASE Specifically to SoSE

– 25 Interrelated Activities

• References

Outline of Talk



• A workable methodology is imperative in any

effective CSE framework.

• CSE, ESE, and SoSE theories are in early stages.

• We need to try them out in practice to see how well they work.

• Feedback from experience in CSE informs the theory.

• CSE theory will be refined by instituting lessons learned.

(Gorod et al. 2015)

3

Statement of Objectives (1/2) –

Advocate Workable Methodology

3 4/14/2016

See Notes Page



• This latest version of the CASE is the most extensive so far. (especially compared to the original flow chart shown below; see next chart)

• Particular attention is paid to SoSE terms because of recent

popular emphasis on SoSs.

• Typical SoS instances are illustrated when citing examples of

specific CASE activities.

4 4/14/2016

Statement of Objectives (2/2) –

Apply CASE Specifically to SoSE

Legend: Segments that are on

The Main Path

An Alternative Path

Architect a

Strategy

2Create Climate

for Change

1

Reward Results

4Target Outcome

Spaces

3

Formulate

Decision-Making

Heuristics

5

Stimulate Natural

Processes

6

Assess, Learn,

and Re-Plan

8

Develop in

Operational

Environs

7

See Notes Page



CASE (White 2015b) Systemigram (Boardman and Sauser 2008)

1b(Persistent)

Problem

2cStakeholders

3dIncentiveStructures

1aMindsights

4bArchitecture

4aSelf-OrganizedCollaborations

6a Behaviors of

PrimaryAlternatives

3b System Boundary

2dDesirableOutcomeSpaces

5b Potential

Approaches

2aOpportunities

and Risks

5a Specific

Interventions

5cDecisionTakers

3cAnti-Fragility

6b Users

6cAppropriate

Actions

9aIncrementalCapabilities

7 What

Happens

8 Results

9bLessonsLearned

10b Contributors

10aProgress

11Continued

Effort?

2bOrganizational

Efforts

3a Team andResources

Are Evaluatedand Dealt WithAppropriately

Are Postulated

AreChanged

Is BetterUnderstood

Is Decided

AreBrainstormed,Evaluated, and

Selected

Is Established

AreBalanced

AreStimulated

Are Helped WithHeuristics

IsMeasured

Are AssessedCollaboratively

Are Instilled

Is PublicizedIs Renewed Iteratively

Are Rewarded forUseful Results

Are Taken

AreProposed

Are Analyzed,Modeled, and

Simulated

Are Added toComplex System

IncludesIdentifying

IncludesConsidering

IncludesSharing

Information,Building Trust,

Competiton, andCooperation

AreAdjusted

IncludesLeadership

CreatingSelf-Organized,

Bottom-Up

IncludesMounting

Build

Encourage

ConveysFlexibleAttitudes

EmbracingMultiple

Perspectives

MayInclude

New

IncludesLeaders TakingInformed Risks

to PursuePromising

Opportunities

IncludesAnticipating Black

Swans andEncouraging Small

Pertubations

Is Created

IncludesEmbracing

Practitioners

Are ExperimentedWith Safely

Includes Observing

IncludesRecognition of

Includes LeadershipEstablishing Vision and Mission

IncludesCreation of

EffectiveMeasures and

Efficient Metrics

Includes InvolvingTeam Representation

to Consider

IncludesImpact ofEmergingEvents On

IncludesAgent-Based

ModelingConcepts

IncludesMore M&S?

Includes RespectingTime Delays

Preliminaries Positive Aspects(White 2015b)

Complex Adaptivce SystemEngineering (CASE) Methodology

People Involved Neutral AspectsRoutine ActionsCreative Aspects

5 4/14/2016

See Notes Page



CASE Methodology* (1/27) Various Activities

4/14/2016 6

1a - Changing mindsights

1b - Understanding persistent problem

2a - Balancing opportunities and risks

2b - Mounting organizational efforts

2c - Evaluating stakeholders

2d - Postulating desirable outcome spaces

3a - Building team and resources

3b - Deciding system boundary

3c - Creating anti-fragility

3d - Adjusting incentive structures

4a - Stimulating self-organized collaborations

4b - Establishing architecture

*(White 2010c) (White 2009) (White 2008)

(White 2008a); developed for (White 2015b)

5a - Proposing specific interventions

5b - Brainstorming potential approaches

5c - Helping decision takers

6a - Modeling and simulating behaviors

6b - Experimenting with users

6c - Taking appropriate actions

7 - Measuring what happens

8 - Assessing results

9a - Adding incremental capabilities

9b - Instituting lessons learned

10a - Publicizing progress

10b - Rewarding contributors for useful results

11 - Renewing continued effort?

There is insufficient time to discuss these here.



CASE Methodology (2/27) –

1a - Changing Mindsights

• A proper mindsight is helpful in complex

domains and in practicing SoSE.

• Traditional SE mindsets* focused on

requirements, reductionism, optimization,

etc., do not work with CSs.

• Mindsight is conveys a more flexible attitude

that embraces multiple perspectives.

• Self-organized collaborations yield a much better

understanding of the problem and what to do about it.

__________

* “Mindsights” is a better word (Hawn 2011, p. xiv).

7 4/14/2016

See Notes Page



• In Checkland’s Soft Systems Methodology (SSM) understanding the problem is a primary goal.

• Each level of understanding triggers intervening action.

• Problem understanding is a continual process that is re-exercised after observing each result.

• In SoSs reaching mutual understanding, among component system organizations is not easy.

• This collaboration warrants extra effort in establishing sustainable SoS mechanisms and pathways for this purpose.


1b - Understanding Persistent Problem

8 4/14/2016

See Notes Page



• Traditional SE focuses on risk mitigation.

• With CSs it is all about opportunities.

• But pursue opportunities only with informed risk.

• Reward those that seek improvements this way.

• Protect against Black Swans (Taleb 2007) and stimulate anti-fragile development (Taleb 2012).

• Risks can lead to opportunities and vice versa.

• Balance risks and opportunities.

• Reasonable balance between all competing factors, not separate sub-optimizations, is fundamental in SoSE.

• Ensure SoS adaptability in advance with a management process for the unexpected.


2a - Balancing Opportunities and Risks

System of Systems View

Systems View

Enterprise View

Risk

Risk

Opportunity

Opportunity

UnknownUn-assessable

Uncertainty

9 4/14/2016

See Notes Page



CASE Methodology (5/27) – 2b - Mounting Organizational Efforts

• Simple problems can often be addressed by individual efforts on a more or less ad hoc basis.

• More often than not, complex problems require additional effort, usually of an organizational variety, typically involving multiple organizations.

• Good leaders, faced with serious problems, are able to envision, formulate, negotiate, and eventually obtain buy-in participation from relevant organizations, including their own, that can potentially contribute to problem solutions.

• Initial goals include creation of an inter- organizational structure that is flexible and resilient enough to assure, to extent possible, continual effort from each organization involved.

10 4/14/2016

See Notes Page



• There are certainly many stakeholders in a typical SoS, not only because of the SoS level and environment participants but also due to those involved with the component systems.

• As with simpler systems it is advisable to – Identify – Assess – Evaluate

all the key stakeholders to determine who will – Assist – Resist – Oppose – Just need to be informed of the

o Effort

o Progress.

• Those stakeholders that are – Supportive must be continually nurtured – Against the effort must be

o Neutralized

o Marginalized.

• Clearly – Psychology – Sociology – Organizational change management – Politics – Economics – Ethics – Morality

are relevant trans-disciplines that need to be applied.


2c - Evaluating Stakeholders

11 4/14/2016

See Notes Page



• One of the initial tasks of the SoS leadership is to

establish an overall vision or mission (for military

SoS) for the SoSE team.

• This should be something that – Is compelling

– Can be internalized

to motivate and enable daily personal assessments

as to the extent common-cause contributions have been made.

• Early on the team must establish desirable outcome spaces and

measures so that it will be clear whether postulated solutions

developed later fit into at least one of these spaces.

• At this stage it is premature to focus on specific solutions and their

possible outcomes.

• As the SoSE effort proceeds, these outcome spaces need to be

continually adjusted in a fashion analogous to a vehicle’s headlights

in moving down a road; one does not want to be so – Narrow as to miss opportunities for good solutions

– Wide that the solution challenge is far too great.


2d - Postulating Desirable Outcome Spaces

12 4/14/2016

See Notes Page



CASE Methodology (8/27) – 3a - Building Team and Resources

• The inter-organizational structure is leveraged initially to – Locate, consider, select, and assemble talented and/or

qualified individuals that will compose the team

– Identify, qualify, and obtain other material and financial resources to support the effort

• Important processes are planned and emplaced to assure

– A methodology for dealing with unanticipated events

– The smooth and inevitable transition of alternative staff members into/out of the program for various good reasons

– Sensitivity to external developments and outreach to others that may usefully become involved

13 4/14/2016

See Notes Page



• A CS boundary is usually very fuzzy. • Boundaries must be decided via thorough discussions while

– Trying to understand the problem

– Exercising other CASE activities already discussed.

• Rationale: If the boundary is too

– Restricted, then the real problem may not be solved

– Ambitious, then the difficulties escalate rapidly

• Establish the SoS boundary by consensus with representatives from

– The SoS level

– Each system component

– A subset of key stakeholders

but only with people with authority to commit.

• Make known the boundary to

– The rest of the SoSE team

– Their affiliates

to help guide their collaborative work.

• Agree that the boundary might be adjusted based on future events.


3b - Deciding System Boundary

14 4/14/2016

See Notes Page



• Protect the SoS from catastrophic events that may occur.

• If the approach is no longer viable, then go with a backup.

• Focus on what might go wrong, and have a fallback.

• Traditional SE assumes things will work as intended, a flawed assumption with CSs. (Perrow 1999)

• After protections, subject the SoS to small random perturbations that can increase its – Resilience – Robustness – Strength.

• An example: Ensure that acquisition contracts

– Admit a wider selection of vendors – Increase competition – Pay for results not perceived promises.

This is a way of “stirring the pot” to ensure good results.


3c - Creating Anti-Fragility (Taleb 2012)

15 4/14/2016

See Notes Page



• People behave as they are measured and rewarded.

• In military system acquisition, officers in charge of SoS

programs are short-term oriented because they – Change jobs every two-three years

– Are not accountable for previous assignments.

• We need incentive structures that reward – Leadership styles that

o Create conditions for self-organization, bottom-up efforts

o Discourage autocratic, hierarchical, top-down approaches

– Informed risk taking in pursuing promising opportunities

– More integrated career accountability.


3d - Adjusting Incentive Structures

16 4/14/2016

See Notes Page



• Early organizational efforts are appropriate – A leader and/or manager, are/is put in charge – An initial action team is assembled – Resources are provided or requisitioned – An overall vision/goal is established.

• Establish spirit of collaboration among the participants to help facilitate

– Information sharing – Trust building – Individual exchanges

o Perceptions o Viewpoints o Opinions

– Cooperation – Competition.

• Collaboration enables self-organization critical in achieving solutions.

• This is difficult in SoSs, for component systems’ self-interests dominates.


4a - Stimulating Self-Organized Collaborations

17 4/14/2016

See Notes Page



• SoSE needs a good guiding architecture.

• Establish a stable architecture early.

• This architecture can be modified when unexpected events

indicate a different direction.

• In some frameworks there is a temptation to create “views”

“check a box” required by management.

• This is dangerous if views are promulgated

before the underlying architecture has been

fully developed.


4b - Establishing Architecture

18 4/14/2016

See Notes Page



• The SoSE team is often almost ready to try something else.

• These would be interventions that have uncertain outcomes.

• First propose each intervention to key stakeholders to obtain

their reactions.

• Some additional M&S may also be

indicated.

• Before fully committing to

implementation some experimentation

would also be advisable.


5a - Proposing Specific Interventions

19 4/14/2016

See Notes Page



• Brainstorming is a too casual term for this important activity but it conveys proper meanings.

• Here the SoSE team, hopefully in a high-performing, collaborative state, shares ideas about how the problem might be solved, mostly from a technical point of view.

• However, they must still be mindful of the non-technical aspects, however, considering all the trans-disciplinary areas that apply.

• As in normal brainstorming, the free-flow of ideas should run its course before anyone on the team attacks any particular idea.

• Then the more evaluative phase begins, where the offered ideas are – Criticized – Rejected – Retained – Refined.

• The remaining potential approaches should all fit within the agreed

– Vision/Mission – Desired outcome space – System boundary.

• Finally, there should be decisions on which approaches to

– Pursue most vigorously – Bring along with lesser degrees as backup options.


5b - Brainstorming Potential Approaches

20 4/14/2016

See Notes Page



• “Taker” indicates a more proactive attitude.

• SoS decision taking is more complex with larger numbers and variety of stakeholders involved.

• In CSs decision makers take decisions too early.

• Time delays are an important factor.

• Better advise decision takers to wait a while.

• Provide decision takers with good heuristics.

• Example heuristic: When any component system is (too much) deemphasizing the SoS in favor of their own system.


5c - Helping Decision Takers

21 4/14/2016

See Notes Page



• After selecting a few viable approaches, an analysis of primary alternatives begins.

• M&S augment analytical capabilities.

• When people are part of the CS intentionally, one benefits from agent-based modeling.

• Autonomous, independent agents follow a small set of rules while interacting with other agents and their environment.

• An SoS provides a particularly rich opportunity for this.

• Thousands of iterations including tens or hundreds of agents can be run with only modest memories and computational power.

• Much can be learned from what emerges.

• Rules can be modified or added/subtracted with experimentation.

• Outcomes inform the SoS development.


6a - Modeling and Simulating Behaviors

22 4/14/2016

See Notes Page



• Again, because of uncertainties associated with most SoSs, the

SoSE team should experiment with promising ideas in multiple

venues.

• Rather than confining these experiments to laboratory

environments typical of traditional SE efforts, one should

embrace practitioners and experiment with users in the field, as

it were, to the extent possible.

• Users know better what is needed operationally, and much

progress can be made by leveraging their

expertise and experience.

• This is much better than – Developing something in a “vacuum”

– “Throwing it over the wall”

– Having users reject or misuse the supposedly

additional capability.

• However, these operational type experiments

must be done safely, so that no one is put in

jeopardy.


6b - Experimenting With Users

23 4/14/2016

See Notes Page



• Complex systems operating where they should, at the edge of

chaos, continue to evolve whether one intervenes or not.

• That is why, before taking further action, decision takers should

objectively observe what is happening over some period of time,

as previously mentioned.

• Interventions are necessary; after all, that is what decision takers

are expected to do.

• These actions should be taken in the spirit of pursuing an

opportunity while being informed of potential risks, again, as

already discussed.

• Whatever actions are taken within an SoS, it is

quite appropriate to tell other key stakeholders at

the SoS level, within the SoS environment, and

across all the component systems.

• Then they have increased abilities to consider their

own actions to hopefully improve the SoS situation.

• This sharing of information is not so typical in traditional SE

environments, where it seems that most are punished, rather than

rewarded, for sharing information across organizations.


6c - Taking Appropriate Actions

24 4/14/2016

See Notes Page



• Fundamentally, the SoSE team must be interested in results that fit into the desired SoS outcome space.

• There should already be measures in place to better determine whether outcomes fall within that desired space.

• Better yet, each measure should include metrics that are easily available for gathering relevant data.

• For example, component system managers might report their contributions to the SoS level along with why they think each contribution will fit into the SoS’s outcome space, and those instances would be recorded and shared.

• Some care should be expended to be assured that whatever data gathered is actually used to help avoid a waste of resources.


7 - Measuring What Happens

25 4/14/2016

See Notes Page



• Here the main challenge may be in reaching consensus across the SoS as to whether improvements have indeed been made.

• The key stakeholders within any component system may not agree on the relative tradeoffs between their local objectives and those of the SoS level stakeholders.

• Stakeholders within the environment of the SoS but not directly engaged in the SoS should also be consulted to see whether they have noticed improvements.

• If the SoS is to provide a public service, progress might also be assessed by – Conducting limited

o Polls o Surveys

– Contacting selected o Government

Officials Lawmakers

A sense of accomplishment

would do well in continuing the improvement efforts.


8 - Assessing Results

26 4/14/2016

See Notes Page



• Traditional SE focuses on requirements.

• This must continue in CSs because requirements are incomplete, unclear, unstable, and/or unknown.

• In SoSs rely on vision/mission and desired outcome space.

• Decision takers continually assess whether the SoS enjoys additional capabilities – or not.

• If the SoS moves in the positive direction, the next intervention targets additional capability.

• If not, try something else.

• This is incremental, where one builds a little, tests a little, and fields a little.

• Gradually the SoS situation improves.


9a - Adding Incremental Capabilities

27 4/14/2016

See Notes Page



• Learning lessons is good.

• Sometimes lessons are given short shrift.

• Often lessons are not really learned.

• Retain and institute lessons for all applicable projects.

• Instill this importance throughout the SoS.

• Systemically collect SoS-related lessons

from all component systems.

• Share with other SoSs.


9b - Instituting Lessons Learned

28 4/14/2016

See Notes Page



• Publicize rewarding recipients for results.

• These publications need not be detailed.

• This motivates accomplishing similar outcomes.

• Investments by SoS component system stakeholders are

necessary when only rewarding results because contractors

– Would not receive up-front funding

– Promises to deliver “goods” would be irrelevant

– Would be compensated/given bonuses only if only

successful

• Those successful contractors would develop

“deep pockets” and be able to invest again.

• Contractors that cannot deliver would “dry up and go away”.

• Individual contributors within organizations tend to be

rewarded with raises, bonuses, and promotions only after

the fact, so this is merely being extended upwards.


10a - Publicizing Progress

29 4/14/2016

See Notes Page

Will enough stakeholders “warm” to these ideas?!



• This is the most important CASE activity, at least in

terms of improving acquisition processes.

• Too often, programs or projects fail when rewards are given up-front

or with award fees when very little is accomplished.

• Stronger incentives are needed to ensure desired outcomes.

• Reserving rewards for achievement is especially challenging in SoSs.

• Existing incentive structures cannot be changed “overnight”.

• Governing bodies could improve the system over

decades, by moving funding later in the programs.

• Innovative contracts can help accommodate this

systemic change of rewarding for results.

CASE Methodology (25/27) – 10b - Rewarding Contributors for Useful Results

30 4/14/2016

See Notes Page



• The work is never done in a CS which evolves on its own.

• This was established in Checkland’s Soft Systems Methodology

(SSM) (Checkland 1999).

• CASE as an interative process that revisits its activities – During each cycle of activities

– After cycling through all activities

• A multi-wheel vehicle analogy of the SEA profiler (White 2012b)

should be adopted by each SoS component system, so that some

portion of the SoS can be renewed at appropriate milestones.

• In this case, CASE can be applied again but on a

smaller scale.

• Extending this, the entire SoS can also be continually

rejuvenated.


11 - Renewing Continued Effort?

31 4/14/2016

See Notes Page

Define the System Problem

Analyze Alternatives

Utilize a Guiding Architecture

Consider Technical

Approaches

Pursue Solutions

Manage Contingencies

Develop Implementations

Integrate Operational Capabilities

Learn by Evaluating

Effectiveness

Systems

Engineering

System 1




Consider Technical

Approaches

Pursue Solutions




Learn by Evaluating

Effectiveness

Systems

Engineering

System 3




Consider Technical

Approaches

Pursue Solutions




Learn by Evaluating

Effectiveness

Systems

Engineering

System 2




Consider Technical

Approaches

Pursue Solutions




Learn by Evaluating

Effectiveness

Systems

Engineering

System 4

System 1System 2



• To reiterate CASE activities are

– Not exercised in series.

– In parallel and iterative.

– Applicable within any SoS subset.

• CASE is a fresh, practical approach to deal

with complex problems, especially SoSs.

– There is no theoretical “proof” that this works.

– We still need to rely on case studies for viability.

• People, i.e., key stakeholders, are included intentionally.

– This makes SoSE particularly difficult.

– Good technology is still necessary for success.

– Dealing with the human element is ever more critical in today’s

increasingly complex world.

CASE Methodology (27/27) – Summary

32 4/14/2016

See Notes Page



Takeaways

4/14/2016 33

• Understand – Complexity – Complex Systems – Complex Systems Engineering

• Examine mindsights to – Approach serious problems differently – Think how one might be more successful

• Create conditions for

– Engineering the environment – Stimulating self-organization

• Watch what happens and be prepared to

– Try other intervention(s) – After suitable delays

• Elevate your goals to help solve world problems! (White 2016c)

Thank You All! Please provide me with your E-mail address if you would

like a soft copy of all the charts and Notes Pages.

The creation of the world did not take place once and for all time, but takes place every day. Samuel Beckett

(Fitzpatrick 2012)



References (1/2)

4/14/2016 34

(Boardman and Sauser 2008) John Boardman and Brian Sauser, Systems Thinking – Coping With 21st Century Problems. Boca Raton, FL: CRC Press. 2008. (Checkland 1999) Peter Checkland, Systems Thinking, Systems Practice – Soft Systems Methodology: A 30 Year Perspective. New York: John Wiley & Sons. 1999. (Gorod, White, Ireland, Gandhi, and Sauser 2015) A. Gorod, B. E. White, V. Ireland, S. J. Gandhi, and B. J. Sauser, Case Studies in System of Systems, Enterprise Systems, and Complex Systems Engineering. Boca Raton, FL: CRC Press, Taylor & Francis Group. 2015. (Hawn 2011) Goldie Hawn (with Wendy Holden), 10 Mindful Minutes. New York: Penguin Books. 2011. (Perrow 1999) Charles Perrow, Normal Accidents – Living with High-Risk Technologies. Princeton, NJ: Princeton University Press. 1999. (Taleb 2012) Nassim Nicholas Taleb, Antifragile―Things that Gain from Disorder. New York: Random House. 2012. (Taleb 2007) Nassim Nicholas Taleb, The Black Swan – Impact of the HIGHLY IMPROBABLE. New York: Random House. 2007. http://www.amazon.com/Black-Swan-Impact-Highly Improbable/dp/1400063515/ref=pd_bbs_sr_1/102-6890811- 9526543?ie=UTF8&s=books&qid=1192905688&sr=8-1. (White 2016c) B. E. White, Leadership Under Conditions of Complexity,” IEEE SoSE Conference, Kongsberg, Norway, 12-16 June 2016. (White 2016b) B. E. White, “On a Maturity Model for Complexity, Complex Systems, and Complex Systems Engineering,” Complex Systems Conference, New Forest, UK, 1-3 June 2016. (White 2016a) B. E. White, “Systems Engineering Beliefs: Contemplating Personal Perceptions regarding State of the Art.” International Journal of Design & Nature and Ecodynamics. Special Issue on Complex Systems Applications. Papers from Complex Systems 2015 conference. New Forest, UK. 12-14 May 2015. Vol. 11. No. 1. 2016, 10-23. (White 2015) B. E. White, “Complex Systems: How to Recognize Them and Engineer Them.” Tutorial- Workshop. American Society for Engineering Management (ASEM ) International Annual Conference. 7-10 October 2015. Indianapolis, IN. 8 October 2015.


18-21 April 2016 – Orlando, FL 4/14/2016 35

(White 2015a) B. E. White, “On Leadership in the Complex Adaptive Systems Engineering of Enterprise

Transformation.” Journal of Enterprise Transformation. Vol. 5. No. 3. 192-217. 11 September 2015.

Supplementary Material (Appendices):

http://www.tandfonline.com/doi/suppl/10.1080/19488289.2015.1056450; ISSN: 1948-8289 (Print)

1948- 8297 (Online) Journal homepage: http://www.tandfonline.com/loi/ujet20;

http://dx.doi.org/10.1080/19488289.2015.1056450.

(White 2015b) B. E. White, “System of Systems (SoS) Course.” Developed for the Worcester Polytechnic

Institute (WPI). For potential offering in WPI’s graduate program in Systems Engineering. February 2015.

(White 2010c) B. E. White, “Complex Adaptive Systems Engineering (CASE).” IEEE Aerospace and Electronic

Systems Magazine, Vol. 25, No. 12. December 2010. 16-22, ISSN 0885-8985.

(White 2010) B. E. White, “A Personal History in System of Systems.” Special Session on System of Systems

(SoS). International Congress on Ultra Modern Telecommunications and Control Systems (ICUMT-2010).

Moscow, Russia. 18-20 October 2010.

(White 2010b) B. E. White, “Systems Engineering Activity (SEA) Profiler.” 8th Conference on Systems

Engineering Research (CSER). 17-19 March 2010, Hoboken, NJ. 18 March 2010.

(White 2009) B. E. White, “Complex Adaptive Systems Engineering (CASE).” 3rd Annual IEEE International

Systems Conference. Vancouver, Canada. 23-26 March 2009.

(White 2008) B. E. White, “Complex Adaptive Systems Engineering (CASE).” 3rd System of Systems

Conference, National Institute of Standards & Technology, 9-10 December 2008, Gaithersburg, MD. 10

December 2008.

(White 2008a) B. E. White, “Complex adaptive systems engineering.” 8th Understanding Complex Systems

Symposium. University of Illinois at Urbana-Champaign, IL. 12-15 May 2008.

http://www.howhy.com/ucs2008/schedule.html.

References (2/2)

Date post:	10-Oct-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

A Complex Adaptive Systems Engineering (CASE)...

Documents