Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
© 2015 Carnegie Mellon University
Software Solutions Conference 2015November 16–18, 2015
Distribution Statement A: Approved for Public Release; Distribution is Unlimited
Managing Software and System Complexity Sarah Sheard, Ph.D.
2Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Copyright 2015 Carnegie Mellon University
This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.
Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense.
NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
[Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected].
DM-0003038
3Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Managing Software and System Complexity
Growth of Complexity
What is Complexity?
Example: Systems of Systems complexity
Contributing Factors
What Worsens Complexity?
Reducing Objective Complexity
Reducing Subjective Complexity
Conclusion
4Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Any sufficiently advanced technology is indistinguishable from magic.
-Arthur C. Clarke
Motivation
Any technology distinguishable from magic is insufficiently advanced.
- Gehm’s Corollary
5Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Growth of Complexity
Every year, systems are more complex than last year
Capability grows…our systems do more thinking
Number of systems to interoperate with grows
Systems to be redundant, resilient, adaptable, and secure to a variety of digital threats
Results in growing complexity
6Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
What Is Complexity?
Complexity is a state or quality of being composed of many intricately interconnected parts, in a manner that makes it difficult for humans, supplemented by tools, to understand, analyze, or predict behavior
Objective ComplexityCharacteristics of technical system
Subjective Complexity Characteristics of human experience with the system
7Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Size (number of elements, requirements, users…)
Interconnectedness (number of links)
Heterogeneity (heterogeneity of elements, and of links; multi-scale important elements)
Change (short term dynamics – butterfly effect, behavior –and long term dynamics – evolution)
Sociopolitical complexity (Stakeholder conflict, stakeholder changes)
Aspects of Objective Complexity
-Sheard 2012 Dissertation, see http://seir.sei.cmu.edu/sheard/
8Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Difficulty understanding
Difficulty determining cause and effect
Confusion and frustration
Unpredictability
Inability to list all the major problems
Difficulty teasing a problem apart into component sub-problems
Aspects of Subjective Complexity
9Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Concepts Related to Complexity
Lines of codeUnmaintainableDifficult to verifyNonlinear behaviorStrong couplingOpen system Unclear system boundaryNot possible to understandCan have cascading failuresSystem of systemsHeterogeneous elementsUser cognitive load
OSSOOOSSOOOS
Are These Objective or Subjective?
10Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Objective Causes Subjective
Many pieces
Tightly coupled pieces
Nonlinear behavior
SoS with many stakeholders
UncertainRiskyHard to understandUnpredictableFrustratingUncontrollable
Causes
11Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Systems • Software, computer hardware, other
hardware • Safety case
Projects • Teams, process, constraints, laws,
deadlines, …
Environments • Technical – interfacing systems • Sociopolitical
What Can Be Complex?
12Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Complexity is in all cases difficult to deal with.It may be necessary.
Is Complexity Bad?
YesIn performance, schedule, cost: a more complex system is worse than a simpler system
NoMore complex systems can have more intelligent functionality
13Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Splitting Complexity
Split complexity between technical system and operator
• Technical system can handle complexity that could confuse an operator (e.g. calculate position from sensor data)
Goals:
• System shouldn’t be so simple it leaves all complexity to the operator
• System shouldn’t be so complex it hides issues and leaves the operator completely out of the loop
14Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Complexity, however defined objectively, relentlessly increases
Complexity, defined subjectively, relentlessly decreases (for a given system)
Complexity Changes with Time
15Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Example: Complexity of a System of Systems
Purpose: to create a multi-purpose, multi-user technology
Organization: One enterprise including several ACAT 1 programs
• Each program has cost, schedule, performance issues and makes adjustments per own priorities
• Each program can hold up all the others
Desire top-down control; best you can get is agreements
16Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
This system will be launched into orbit, and we can’t fix it after that
Dealing with legacy systems
Conflict between cheapest now and most adaptable for the future
Stakeholders change
New standards came out since we started designing this
Example: Internet of Things
Example: Contributing Factors to Complexity
17Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Reasons for Today’s Complexity IncreaseEnvironment evolves
• Distributed systems, distributed development• Requirements
• Interoperability • Safety• Resilience, flexibility and adaptability
• Evolving nature of security threats and countermeasures• Tools and environments allow it, e.g., optimizing
compilers, higher-order languages.
-- Sheard, Sarah and A. Mostashari, “Principles of complex systems for systems engineering.” Systems Engineering 12(4), 2009: 295-311.
18Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Using more components
Patching after-the-fact
Requirement changes approved midway through the program
Using components about which little is known (Legacy, COTS)
Inadequate time for engineers to think (“Just do the process”)
Multiple stakeholders, especially when they change their minds
Changing relationships among stakeholders
Lack of clarity in architecture
Lack of clarity regarding which experts are the final authority
- Experience
What Makes Complexity Worse?
19Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Reduce objective complexity
Often: Architecture
Reduce subjective complexity
Many tools and techniques from project management and systems engineering
Treat remaining complexity as risks
Dealing With Complexity
20Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Project management and systems engineering activities • Planning, tracking• Identification and prioritization of requirements• Allocation of tasks to people• Allocation of requirements to components• Trade studies • Communication with customer representatives• Risk management
Identify and address “system of systems” engineering concernsIdentify systems and software architectures that best address
needed qualities Evolve the right design by adapting proven designs
Dealing With Complexity: 2
21Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Use fewer components/pieces
Use fewer *kinds of* components or pieces
Decouple (caution: this may reduce capability)
Reduce the frequency of change (defer to “next version”)
Improve clarity of communication
Reducing Objective Complexity
22Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Establish capable modeling, configuration management, and design environment
Probe, proof the new technology: Prototype
Learn from others who are using it
Improve clarity of communication
Train engineers and give them time to think
Reducing Subjective Complexity
23Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
• Identification• Analysis
• What, how, when• Any cascading effects • How likely and how bad • Evaluation
• Mitigation• Monitoring
Treat Remaining Complexity as Risks
24Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
Objective complexity relates to the system and can be measured • Systems become more objectively complex over time
Subjective complexity varies with person and time• A system becomes less subjectively complex with familiarity and
tools
Reduce complexity with standard tools and techniques• Architecture; planning, tracking, communicating
Treat remaining complexity as a risk: identify, analyze, mitigate
Conclusion
25Managing Software and System ComplexityNovember 17, 2015© 2015 Carnegie Mellon UniversityDistribution Statement A: Approved for Public Release; Distribution is Unlimited
PresenterSarah A. SheardSenior EngineerTelephone: +1 412.268.7612Email: [email protected]
Contact Information