© 2013 Carnegie Mellon University Software: The 21st Century's Strategic Resource Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Paul Nielsen May 2013
© 2013 Carnegie Mellon University
Software: The 21st Century's Strategic Resource
Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
Paul NielsenMay 2013
2Paul NielsenMay 2013© 2013 Carnegie Mellon University
My Talk Today
• Why is Software So Important?• What is the Current State of Software Engineering?• What Can We Do?• Will We Be Ready for the Future?
3Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software is Everywhere
4Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software is Increasingly Complex
5Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software Connects Us
6Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software is Becoming More Personal
7Paul NielsenMay 2013© 2013 Carnegie Mellon University
“Software is Eating the World”
“More and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.”
Marc Andreessen, August 2011
8Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software is Important
Manufacturing Finance
Space Engineering
9Paul NielsenMay 2013© 2013 Carnegie Mellon University
Software is Today’s Strategic Resource
10Paul NielsenMay 2013© 2013 Carnegie Mellon University
The Current State
• Great capabilities, but struggling
• Bifurcated community
11Paul NielsenMay 2013© 2013 Carnegie Mellon University
Large U.S. Government Programs Often Stumble
12Paul NielsenMay 2013© 2013 Carnegie Mellon University
What Commercial Companies Provide …
• Nimble• Social• Quick to market• Agile• Online and wireless updates
13Paul NielsenMay 2013© 2013 Carnegie Mellon University
… and What Many Government and Enterprise Efforts Need to Consider• Life- and safety-critical applications• High reliability requirements• Security concerns• Long life cycles• Financial and personal data
14Paul NielsenMay 2013© 2013 Carnegie Mellon University
Difficult-to-Assure Dependability Attributes
Safe concurrency • Races and memory model
– Lock based– Thread confined– Data races
• Deadlocks• Real-time thread/memory
Policy compliance• API policy compliance• Framework patterns• Protocol compliance• Architectural compliance• Object references and aliasing• Modularity for composition
Information flows• Aliases, references, effects• Security attributes• Encapsulation, overlay abstractions
Code safety• Appropriate typing
Hard to test
• Non-determinism
Hard to inspect
• Non-local
• Model-based
15Paul NielsenMay 2013© 2013 Carnegie Mellon University
Cap
abili
ty/T
imel
ines
s/A
gilit
y
Quality/Security
The Software Frontier
16Paul NielsenMay 2013© 2013 Carnegie Mellon University
Cap
abili
ty/T
imel
ines
s/A
gilit
y
Quality/Security
The Software Frontier
• More flexibility• Growing size• Growing complexity• More interconnected• More autonomy• Emergent behavior• Better V&V• Improved interfaces
17Paul NielsenMay 2013© 2013 Carnegie Mellon University
Cap
abili
ty/T
imel
ines
s/A
gilit
y
Quality/Security
The Software Frontier
• More flexibility• Growing size• Growing complexity• More interconnected• More autonomy• Emergent behavior• Better V&V• Improved interfaces
18Paul NielsenMay 2013© 2013 Carnegie Mellon University
What We Can Do: Government
• Policy
• Investment
• Infrastructure
• Incentives
• Strategy
• Research
19Paul NielsenMay 2013© 2013 Carnegie Mellon University
What We Can Do: Academia
• Curricula
• Executive training
• Research
• Thought leadership
• Workforce supply
20Paul NielsenMay 2013© 2013 Carnegie Mellon University
What We Can Do: Industry
• Research
• Investment
• Technology
• Transition
• Infrastructure
• Workforce development
• Product lines
21Paul NielsenMay 2013© 2013 Carnegie Mellon University
What We Can Do: Collaborate
Across fields:• Commerce• Education• Science• Information Technology
Across disciplines:• Software• Systems• Electrical Engineering• Aeronautical Engineering• Other
Across countries and regions:• Japan• US• EU• Asia-Pacific
22Paul NielsenMay 2013© 2013 Carnegie Mellon University
Research and Community Trends
Cybersecurity
Clouds
Big data
Data analysisArchitecture
Agile at scale
Development environments
Autonomy
Global supply chains
Social nets
Evolution
Emergent behavior
High reliability
23Paul NielsenMay 2013© 2013 Carnegie Mellon University
Architecture is Critical
The quality and longevity of a software-reliant system is largely determined by its architecture.
In recent studies by OSD, the National Research Council, NASA, and the NDIA, architectural issues are identified as a systemic cause of software problems in DoD systems.
24Paul NielsenMay 2013© 2013 Carnegie Mellon University
The right architecture paves the way for system success.The wrong architecture usually spells some form of disaster.
Why is Software Architecture So Important? Represents earliestdesign decisions
• hardest to change • most critical to get right• communication vehicle
among stakeholders
First design artifact addressing
• performance• modifiability• reliability• security
Key to systematic reuse • transferable, reusable abstraction
Key to system evolution • manage future uncertainty• assure cost-effective agility
25Paul NielsenMay 2013© 2013 Carnegie Mellon University
What is Architecture-Centric Engineering?
Architecture-Centric Engineering (ACE) is the discipline of using architecture as the focal point for performing ongoing analyses to gain increasing levels of confidence that systems will support their business and mission goals.
The ACE Initiative develops principles, methods, foundations, techniques, tools, and materials in support of creating, fostering, and stimulating widespread transition of the ACE discipline.
Architecture is of enduring importance because it is the right abstraction for performing ongoing analyses throughout a system’s lifetime.
26Paul NielsenMay 2013© 2013 Carnegie Mellon University
Architecture Challenges Extend Across a Spectrum of System Types and ScaleChallenges include:• determining how to structure and adapt systems at all scales• managing interactions among these types of systems• assuring software-reliant capabilities that are sufficiently reliable, secure,
responsive, and adaptable to change
Ultra-Large-Scale Systems
webs of software-reliant systems, people,
economies, and cultures
Embedded Systemssoftware embedded in hardware devices
Standalone Systemssoftware applications
Software Product Lines
families of similar systems
Systems of Systems federations of
independent systems
Predict and control behavior Assure and bound behavior
Coupling to organizational structure and practices increases
Cyber-Physical Systems
mutually dependent computational
systems and physical processes
27Paul NielsenMay 2013© 2013 Carnegie Mellon University
Key Principles of Resilience
Resilience is the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation.
• security “built in”• failure scenarios
understood, planned for• redundancy is provided
in key areas• capability remains
available under adverse conditions
resilience
28Paul NielsenMay 2013© 2013 Carnegie Mellon University
People—Still the Heart of Software Innovation
29Paul NielsenMay 2013© 2013 Carnegie Mellon University
Will We Be Ready for the Future?
• Ray Kurzweil’s singularity• Hyperconnectivity• Internet of everything• Surfeit of data and bandwidth• More intimate human–computer interface• Advanced autonomous systems
30Paul NielsenMay 2013© 2013 Carnegie Mellon University
Summary
• Software is important• Reliability/assurance is challenging• World-class problem requiring collaboration• Rushing to the future
31Paul NielsenMay 2013© 2013 Carnegie Mellon University
Copyright 2013Carnegie Mellon UniversityThis 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.This material has been approved for public release and unlimited distribution except as restricted below.The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013 and 252.227-7013 Alternate I.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]
32Paul NielsenMay 2013© 2013 Carnegie Mellon University
Contact Information
Paul NielsenDirector and CEOTelephone: +1 412-268-5800Email: [email protected]
U.S. MailSoftware Engineering InstituteCustomer Relations4500 Fifth AvenuePittsburgh, PA 15213-2612USA
Webwww.sei.cmu.eduwww.sei.cmu.edu/contact.cfm
Customer RelationsEmail: [email protected]: +1 412-268-5800SEI Phone: +1 412-268-5800SEI Fax: +1 412-268-6257