09/29/2010 1 Barry Boehm, USC-CSSE SUNY-IT Seminar September 29, 2010 Some Future Software Engineering Opportunities and Challenges.

Slides:



Advertisements
Similar presentations
Connected Health Framework
Advertisements

Leverage MarkITS for agile solutions delivery that balances strategic thinking with tactical execution for “Business & Technology Convergence” MarkITS.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Chapter 2 – Software Processes
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 1998 by Carnegie Mellon.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Systems Engineering in a System of Systems Context
Basic guidelines for the creation of a DW Create corporate sponsors and plan thoroughly Determine a scalable architectural framework for the DW Identify.
Lecture 5 Themes in this session Building and managing the data warehouse Data extraction and transformation Technical issues.
1 Independent Verification and Validation Current Status, Challenges, and Research Opportunities Dan McCaugherty IV&V Program Manager Titan Systems Corporation.
© Copyright Richard W. Selby and Northrop Grumman Corporation. All rights reserved. 0 Process Synchronization and Stabilization February 2007 Rick.
Rational Unified Process
University of Southern California Center for Software Engineering CSE USC System Dynamics Modeling of a Spiral Hybrid Process Ray Madachy, Barry Boehm,
1 / 24 CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley,
Azad Madni Professor Director, SAE Program Viterbi School of Engineering Platform-based Engineering: Rapid, Risk-mitigated Development.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Unit Five – Transforming Organizations
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC CS 510 Lecture Fall 2011 Value-Based Software Engineering.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
University of Southern California Center for Software Engineering C S E USC Agile and Plan-Driven Methods Barry Boehm, USC USC-CSE Affiliates’ Workshop.
COMP8130 and 4130Adrian Marshall 8130 and 4130 Test Management Adrian Marshall.
project management office(PMO)
The Strategic Management Process
Enterprise Architecture
University of Southern California Center for Software Engineering C S E USC ISERN 2005 November 15, 2005 Stefan Biffl, Aybuke Aurum, Rick Selby, Dan Port,
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
Modernizing Legacy Systems Lucy Watts, PMP RKV Technologies Inc.
Software Development Process
Solution Overview for NIPDEC- CDAP July 15, 2005.
® IBM Software Group © IBM Corporation IBM Information Server Understand - Information Analyzer.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Organizational competence in harnessing IS/IT
VALUE BASED SYSTEMS ENGINEERING THE VALUE ADDED PATH FORWARD Joseph Maley October 8, 2015.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Decision Support System Development By Dr.S.Sridhar,Ph.D., RACI(Paris),RZFM(Germany),RMR(USA),RIEEEProc. web-site :
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
10/29/ Barry Boehm, USC-CSSE Fall 2012 Some Future Software Engineering Opportunities and Challenges.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
CS223: Software Engineering Lecture 2: Introduction to Software Engineering.
Object-Oriented Software Engineering Chapter 1 Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
UCI Large-Scale Collection of Application Usage Data to Inform Software Development David M. Hilbert David F. Redmiles Information and Computer Science.
Building Systems for Today’s Dynamic Networked Environments A Methodology for Building Sustainable Enterprises in Dynamic Environments through knowledge.
© 2005 Prentice Hall, Decision Support Systems and Intelligent Systems, 7th Edition, Turban, Aronson, and Liang 6-1 Chapter 6 Decision Support System Development.
SRA 2016 – Strategic Research Challenges Design Methods, Tools, Virtual Engineering Jürgen Niehaus, SafeTRANS.
Chapter 1: Software and Software Engineering The Nature of Software... Software is intangible  Hard to understand development effort Software.
CIM Modeling for E&U - (Short Version)
Identify the Risk of Not Doing BA
Some Future Software Engineering Opportunities and Challenges
Script-less Automation: An Approach to Shift-Left.
CS 425/625 Software Engineering Software Evolution
Software Testing and Maintenance Maintenance and Evolution Overview
Comparison between each special case
KNOWLEDGE MANAGEMENT (KM) Session # 36
Chapter 1: Software and Software Engineering
Presentation transcript:

09/29/ Barry Boehm, USC-CSSE SUNY-IT Seminar September 29, 2010 Some Future Software Engineering Opportunities and Challenges

09/29/ Outline The Future of Information Technology –8 surprise-free trends; 2 wild-card trends –Changes since 2005 paper –Individual and combined software engineering opportunities and challenges Conclusions: General SW engineering implications –Management, staffing/education, research

09/29/ The Future of Systems and Software: 2005 Eight surprise-free trends 1.Increasing integration of SysE and SwE 2.User/Value focus 3.Software Criticality and Dependability 4.Rapid, Accelerating Change 5.Distribution, Mobility, Interoperability, Globalization 6.Complex Systems of Systems 7.COTS, Open Source, Reuse, Legacy Integration 8.Computational Plenty Two wild-card trends 9.Autonomy Software 10.Combinations of Biology and Computing

2010 Trends Largely Missed in 2005 Search and mining of ultralarge data aggregations Software implications of multicore chips Rapid growth of software as a service Rapid growth of social networking technologies Changing priorities: speed and adaptability 09/29/2010 4

5 The Future of Systems and Software: 2010 Eight surprise-free trends 1.Need for Rapid Development and Adaptability 2.Software Criticality and Dependability 3.Complexity; Global/Mobile Systems of Systems 4.COTS, Open Source, Services, Legacy Integration 5.Mining huge volumes of data 6.User Patterns and End Value Focus 7.Computational Plenty and Multicore Chips 8.Increasing integration of SysE and SwE Two wild-card trends 9.Autonomy Software 10.Combinations of Biology and Computing

09/29/ Rapid Change Trends Global connectivity and competition accelerate change –More ripple effects of technology, marketplace changes Increased need for agility, continuous learning –Need to balance agility and plan-driven dependability –Decline of THWADI (That’s how we’ve always done it) –Avoid technical agility, administrative THWADI Hybrid agile/plan-driven processes needed for larger systems Need for incremental processes, methods, tools, skills Need for pro-active technology, marketplace monitoring Education: Need to learn how to learn

© USC-CSSE 7 Adaptation Challenges: A Dual Cone of Uncertainty – Need early systems engineering, evolutionary development Uncertainties in competition, technology, organizations, mission priorities Uncertainties in scope, COTS, reuse, services 09/29/2010

8 Agile and Plan-Driven Home Grounds: Five Critical Decision Factors Size, Criticality, Dynamism, Personnel, Culture Personnel Dynamism (% Requirements-change/month) Culture (% thriving on chaos vs. order) Size (# of personnel) Criticality (Loss due to impact of defects) Essential Funds Discretionary Funds Comfort Single Life Many Lives (% Level 1B)(% Level 2&3) Agile Plan - driven Personnel Dynamism (% Requirements-change/month) Culture (% thriving on chaos vs. order) Size (# of personnel) Criticality (Loss due to impact of defects) Essential Funds Discretionary Funds Comfort Single Life Many Lives (% Level 1B)(% Level 2&3) Agile Plan - driven

Architected Agile Approach Uses Scrum of Scrums approach –Up to 10 Scrum teams of 10 people each –Has worked for distributed international teams –Going to three levels generally infeasible General approach shown below –Often tailored to special circumstances 09/29/2010 9

10 2. Criticality and Dependability Trends Software increasingly success-critical to product and services –Provides competitive differentiation, adaptability to change Dependability is generally not vendors’ top-priority –“The IT industry spends the bulk of its resources… on rapidly bringing products to market.” – US PITAC Report By 2025, there will be a “9/11” – magnitude software failure –Major loss of life or collapse of world financial system This will raise dependability to vendors’ top priority –Market demand; stronger warranties and accountability –Value-based dependability processes and tools Avoid bureaucratic solutions Reflect all stakeholders’ value dependencies

© USC-CSSE 11 Achieving Agility and High Assurance -I Using timeboxed or time-certain development Precise costing unnecessary; feature set as dependent variable Rapid Change High Assurance Short, Stabilized Development Of Increment N Increment N Transition/O&M Increment N Baseline Short Development Increments Foreseeable Change (Plan) Stable Development Increments 09/29/2010

Evolutionary Concurrent Engineering: Incremental Commitment Spiral Model Agile Rebaselining for Future Increments Short, Stabilized Development of Increment N Verification and Validation (V&V) of Increment N Deferrals ArtifactsConcerns Rapid Change High Assurance Future Increment Baselines Increment N Transition/ Operations and Maintenance Future V&V Resources Increment N Baseline Current V&V Resources Unforeseeable Change (Adapt) Short Development Increments Foreseeable Change (Plan) Stable Development Increments Continuous V&V 12 © USC-CSSE09/29/2010

13 3. Complexity and Global Software-Intensive Systems of Systems (SISOS) Lack of integration among stovepiped systems causes –Unacceptable delays in service –Uncoordinated and conflicting plans –Ineffective or dangerous decisions –Inability to cope with fast-moving events Increasing SISOS benefits –See first; understand first; act first –Network-centric operations coordination –Transformation of business/mission potential –Interoperability via Integrated Enterprise Architectures

09/29/ Complexity of Solution Spaces Size: MLOC Number of external interfaces: Number of “Coopetitive” suppliers: –Even more separate work locations Depth of supplier hierarchy: 6-12 levels Number of coordination groups: –Reviews, changes, risks, requirements, architecture, standards, procedures, technologies, -ilities, integration, test, deployment, personnel, infrastructure, COTS,… –Key personnel spend 60 hours/week in meetings Unprecedentedness Emergence Rapid change

© USC-CSSE 15 Added Cost of Weak Architecting Calibration of COCOMO II Architecture and Risk Resolution factor to 161 project data points 09/29/2010

Effect of Size on Software Effort Sweet Spots 16 © USC-CSSE 09/29/2010

Future DoD Challenges: Systems of Systems 17 © USC-CSSE09/29/2010

18 The Future of Systems and Software: 2010 Eight surprise-free trends 1.Need for Rapid Development and Adaptability 2.Software Criticality and Dependability 3.Complexity; Global/Mobile Systems of Systems 4.COTS, Open Source, Services, Legacy Integration 5.Mining huge volumes of data 6.User patterns and End Value focus 7.Computational Plenty and Multicore Chips 8.Increasing integration of SysE and SwE Two wild-card trends 9.Autonomy Software 10.Combinations of Biology and Computing

09/29/ COTS: The Future Is Here Escalate COTS priorities for research, staffing, education –It’s not “all about programming” anymore –New processes required CBA Growth in USC E-Service Projects * Standish Group CHAOS 2000 *

Purchased Services Growth in USC e-Services Projects 09/29/

09/29/ Persistence of Legacy Systems Before establishing new-system increments –Determine how to undo legacy system 1939’s Science Fiction World of 2000Actual World of 2000

Some Leading Brownfield Approaches Re-engineering Legacy Software to be Service-Oriented IBM Brownfield VITA Approach –Views: Formal descriptions of enabling business systems or processes –Inventory: Repository that stores Views information –Transforms: Define relationships between as-is and to-be states –Artifacts: Results of Transforms generated from the Inventory CMU-SEI Service Migration and Reuse Technique (SMART) –SMART Process from as-is to to-be state –Service Migration Interview Guide: over 60 questions about migration context, nature, and feasibility –SMART Tool: Helps gather data, identify risks –Artifact Templates: For capturing info about stakeholders, components, migration issues, legacy components, creating service components, etc. 09/29/2010 © USC-CSSE 22

5. Mining huge volumes of data Google example: billions (B) of search hits –All in about 0.2 seconds –Video, 16.1B; TV, 9.6B; Star, 6.1B; Time, 5.4B; Movie, 4.4B; News, 2.8B; Music, 2.7B; Life, 2.3B; Play, 2.1B; Book, 1.7B –What to show first? –How to narrow search to what you want? Recommender systems –Based on preference data or past activity –Amazon.com; Pandora; Netflix Service-provider data warehousing –Better services, but service provider has your data General concerns with privacy, controls 09/29/

09/29/ User/Value Focus Trends Computerworld panel: More focus on user/ownership costs and benefits; less focus on features and license costs –Technology should adapt to people, not vice versa –Tension between usability and feature creep User-orientation has many challenges –Emergent needs and priorities: IKIWISI, Maslow –Diversity of people and cultures: no OSFA solutions –Group vs. individual performance –Engineer focus on engineer-usability  Golden Rule: Do unto others as you would have others do unto you  Platinum Rule: Do unto others as they would be done unto IKIWISI: I’ll know it when I see it OSFA: one size fits all

09/29/ Motivation for Value-Based SE Current SE methods are basically value-neutral –Every requirement, use case, object, test case, and defect is equally important –Object oriented development is a logic exercise –“Earned Value” Systems don’t track business value –Separation of concerns: SE’s job is to turn requirements into verified code –Ethical concerns separated from daily practices Value–neutral SE methods are increasingly risky –Software decisions increasingly drive system value –Corporate adaptability to change achieved via software decisions –System value-domain problems are the chief sources of software project failures

09/29/ Value-Based Testing: Empirical Data and ROI — LiGuo Huang, ISESE 2005 (a) (b)

09/29/ The Future of Systems and Software: 2010 Eight surprise-free trends 1.Need for Rapid Development and Adaptability 2.Software Criticality and Dependability 3.Complexity; Global/Mobile Systems of Systems 4.COTS, Open Source, Services, Legacy Integration 5.Mining huge volumes of data 6.User Patterns and End Value Focus 7.Computational Plenty and Multicore Chips 8.Increasing integration of SysE and SwE Two wild-card trends 9.Autonomy Software 10.Combinations of Biology and Computing

7. Computational Plenty and Multicore Chips Moore’s Law stymied by heat dissipation problems –2x circuit speed, density every 18 months Keep growth by developing multi-CPU chips –Lower circuit speed, but lower power consumption –Growth in #CPUs keeps up processing power growth –But only if programs can be parallelized –Otherwise, legacy software will run more slowly –Amdahl’s Law: Speed limited by speed of slowest part on critical computation path But can also use CPUs for other purposes –Assertion checking, intrusion detection, trend analysis, option analysis, performance monitoring, fault tolerance 09/29/

09/29/ Computational Plenty: Other Implications New platforms: smart dust, human prosthetics (physical, mental) –New applications: sensor networks, nanotechnology Enable higher levels of abstraction –Pattern programming, programming by example with dialogue –Simpler brute-force solutions: exhaustive case analysis Enable more powerful software tools –Based on domain, programming, management knowledge –Show-and-tell documentation –Game-oriented software engineering education

09/29/ Increasing SysE/SwE Integration Can’t do good SwE by neglecting SysE –Weak SysE the root cause of most SW project failures Can’t do good SysE by neglecting critical success factors –Software an increasing system critical success factor Provides most of competitive differentiation Provides most of adaptability to change Enables later binding of commitments

09/29/ Why Software Projects Fail

09/29/ , 10. Wild Cards: Autonomy and Bio-Computing Great potential for good –Robot labor; human shortfall compensation  5 Senses, healing, life span, self-actualization –Adaptive control of the environment –Redesigning the world for higher quality of life  Physically, biologically, informationally Great potential for harm –Loss of human primacy: computers propose, humans decide –Overempowerment of humans  Accidents, terrorism, 1984 revisited –New failure modes: adaptive control instability, self-modifying software, commonsense reasoning, bio-computer mismatches –V&V difficulties: cooperating autonomous agents, biocomputing Forms and timing of new capabilities still unclear

09/29/ Outline The Future of Information Technology –8 surprise-free trends; 2 wild-card trends –Changes since 2005 paper –Individual and combined software engineering opportunities and challenges Conclusions: General SW engineering implications –Management, staffing/education, research

09/29/ Software Process Management Implications Increasing uncertainty requires risk/value-based processes –Concurrent engineering of system goals, solutions, plans  Integration of systems engineering and software engineering –Thoroughly validated for consistency and feasibility  Via prototypes, benchmarks, models, role-playing  Addressing both quantitative and qualitative value factors  Validation progress becomes a key management metric  Validation shortfalls become risks to be managed Criticality and rapid change require balance of agile, plan-driven processes –Plan-driven for foreseeable change, high criticality  Parnas encapsulation of sources of change –Agile for unforeseeable change –Continuous learning and adaptation  Especially in wild-card areas

DDR&E Systems 2020 Objectives and Constraints OBJECTIVES DEVELOP FAST: Reduce by 3x the time to acquisition of first article for systems and solutions – DEVELOP FAST FLEXIBLE: Reduce by 4x the time to implement planned and foreseen changes in systems – FLEX ADAPTABLE: Embed within systems the ability for changes at the tactical edge, as the mission evolves in unplanned and unforeseen ways, e.g., IED threat – ADAPT CONSTRAINTS Achieve the objectives while maintaining or enhancing: –Trust and Assurance – Able to withstand exploitation before or after fielding, enabling the leveraging of global supply chains –Reliability – Across a range of changing operational conditions –Interoperability – Working with other systems to meet user needs

DDR&E Systems 2020 Research Areas Capability on Demand Model Based Engineering Platform Based Engineering Modeling and simulation tools for concurrent design, development & manufacture Architectural and automated design tools to rapidly insert new capabilities Systems embedded with organic adaption capabilities Faster delivery of complex, adaptive systems Trusted Systems Design Design methods and tools for system assurance that detect malice or enable self awareness

Software Engineering Education Implications Current software engineering students will be practicing into the 2050s. Their education should consider the following: –Anticipating future trends and preparing students to deal with them; –Capitalizing on information technology to enable the delivery of just-in- time and web-based education; –Monitoring current principles and practices and separating timeless principles from outdated practices; –Participating in leading-edge software engineering research and practice and incorporating the results into the curriculum; –Packaging smaller-scale educational experiences in ways that apply to large-scale projects; –Helping students learn how to learn, through state-of-the-art analyses, future-oriented educational games and exercises, and participation in research; and –Offering lifelong learning opportunities for systems engineers who must update their skills to keep pace with the evolution of best practices 09/29/

09/29/ Backup Charts Limitations to software process perfectability Value-based systems and software engineering

09/29/ Limitations: Brooks’ Four Essentials Plus Two Complexity: larger components, systems of systems, attribute tradeoffs Conformity: evolving standards, external system/COTS constraints Changeability: solution half-life, unpredictable certainties Conceptuality (invisibility): COTS opacity, multi-view consistency Community: stakeholder proliferation, distribution, diversity Centrality: software failure risks, rice-bowl implications

09/29/ Limitations: Lampson’s Continuing SW Crisis Moore’s Law enables the feasibility of new applications –Requiring new and often more complex software Easier to handle complexity in software than elsewhere –Good engineering practice to address via software Few physical limits on software applications –Easy to overreach with proposed software solutions

09/29/ Limitations: Converse of Conway’s Law Convay’s Law (extended to user organizations) –The structure of a computer program –Reflects the structure of –The organizations that build and use it

09/29/ Limitations: Converse of Conway’s Law Convay’s Law (extended to user organizations) –The structure of a computer program –Reflects the structure of –The organizations that build and use it Converse of Conway’s Law –We will learn how to build perfectly functioning software –As soon as –We learn how to build perfectly functioning organizations

09/29/ Initial VBSE Theory: with Apurva Jain Engine: Theory W (stakeholder win-win): What values are important? –Enterprise Success Theorem –Theory of Justice –Win-Win Equilibrium and Negotiation Four Supporting Theories –Utility Theory: How important are the values? –Multi-attribute utility; Maslow need hierarchy –Decision Theory: How do values determine decisions? –Investment theory; game theory; statistical decision theory –Dependency Theory: How do dependencies affect value realization? –Results chains; value chains; cost/schedule/performance tradeoffs –Control Theory: How to monitor and control value realization –Feedback control; adaptive control; spiral risk control

09/29/ Theory W: Enterprise Success Theorem – And informal proof Theorem: Your enterprise will succeed if and only if it makes winners of your success-critical stakeholders Proof of “if”: Everyone that counts is a winner. Nobody significant is left to complain. Proof of “only if”: Nobody wants to lose. Prospective losers will refuse to participate, or will counterattack. The usual result is lose-lose.

09/29/ Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking

09/29/ By NumberP-value% Gr A higher By ImpactP-value% Gr A higher Average of Concerns Average Impact of Concerns Average of Problems Average Impact of Problems Average of Concerns per hour Average Cost Effectiveness of Concerns Average of Problems per hour Average Cost Effectiveness of Problems Group A: 15 IV&V personnel using VBR procedures and checklists Group B 13 IV&V personnel using previous value-neutral checklists – Significantly higher numbers of trivial typo and grammar faults Experiment Value-Based Reading (VBR) Experiment — Keun Lee, ISESE 2005

09/29/ Software Process Research Implications – I Empirically-evolved process technology –Languages, methods, metrics, models, and tools –Incremental and ambiguity-tolerant –Accommodating incomplete, informal, and partial specification –Bridging formality, life-cycle, and culture gaps –Empirical testbed-based maturity/transition acceleration Virtual process collaboration support –Distributed, multi-stakeholder, multi-cultural Game technology for process education and training –Acquire and develop the way you train –Train the way you acquire and develop

09/29/ Software Process Research Implications – II Lean, value-based processes for balancing dependability and agility –Plus scalability, incrementality for systems of systems –General techniques for multi-attribute tradeoff analysis –Associated progress metrics, review criteria, early warning indicators Integrated technical and acquisition processes –Supporting balance of dependability and agility –Applicable to globally-distributed, multi-cultural collaboration Process capitalization on computational plenty –Self-monitoring software, higher levels of abstraction, knowledge-based tools Integration and risk assessment of wild-card technologies –Autonomy, bio-computing