Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University Pittsburgh, PA Stephen E. Cross, Ph.D. Director and CEO Software Engineering Institute March 12, 2002 Presentation to the USC-CSE Executive Workshop on Agile Methods

S. Cross’ USC CSE Presentation – 3/12/ page 2 © 2002 by Carnegie Mellon University DoD-sponsored FFRDC (applied R&D laboratory) situated as a college-level unit at Carnegie Mellon University Established in 1984 Technical staff of 335 Offices in Arlington, Virginia, and Pittsburgh, Pennsylvania, Purpose: Help others improve their software engineering practices Software Engineering Institute

S. Cross’ USC CSE Presentation – 3/12/ page 3 © 2002 by Carnegie Mellon University What I’d Like to Share With You Software Engineering Institute (SEI) overview Provide some thoughts on agility, discipline, and maturity Provide some thoughts on organizations, people, and development contexts Discuss how the SEI’s work has evolved over time Provide examples of current SEI products and services that support “agility”

S. Cross’ USC CSE Presentation – 3/12/ page 4 © 2002 by Carnegie Mellon University Definitions Agility the ability to move in a quick and easy fashion, nimbleness Discipline controlled behavior resulting from training Maturity the state or quality of being complete and finished This words are not anonyms (e.g., the football team relied on its maturity and disciplined thereby agilely implementing a new game plan in the second half). As defined in the American Heritage Dictionary of the English Language, 1971.

S. Cross’ USC CSE Presentation – 3/12/ page 5 © 2002 by Carnegie Mellon University Some software engineering examples Example #1 The team’s life cycle development model is the waterfall model. They need not be agile. They must be disciplined. Example #2 The team uses an evolutionary life cycle development model. They may be agile. They must be disciplined. Example #3 The team’s life cycle development model is spiral development. They are agile. They must be disciplined.

S. Cross’ USC CSE Presentation – 3/12/ page 6 © 2002 by Carnegie Mellon University An observation Success means delivering a product that delights the end- users at a cost and schedule that delights management Successful use of a life cycle development model is dependent on the organization’s management and culture, the people’s (engineers’) skill and experience, and the context of the development.

S. Cross’ USC CSE Presentation – 3/12/ page 7 © 2002 by Carnegie Mellon University Perspective on Organizations, People, and Context Engineering Organization An organization’s management & culture dictate how (or whether) it improves, changes, adapts, etc. Note: a CMM ® is only a model with an associated set of tools and guidelines People Focus Engineering skill & experience are acquired through education training work Context Focus The context is framed by functionality (e.g., features) nonfunctional attributes (e.g., usability, security) programmatic attributes (e.g., schedule, cost) strategic opportunities (e.g., reuse) ® CMM is a registered service mark of Carnegie Mellon University.

S. Cross’ USC CSE Presentation – 3/12/ page 8 © 2002 by Carnegie Mellon University History of SEI’s Body of Work (circa 1991) Engineering Organization CMM for Software, v1.1 People Focus Master of SWE curriculum Context Focus SW Risk Management Method Most adopters relied On the waterfall model Process People A Stereotypical (and often untrue) characterization Product

S. Cross’ USC CSE Presentation – 3/12/ page 9 © 2002 by Carnegie Mellon University SEI’s Body of Work 2 (today) Engineering Organization CMM Integration SM v1.1 Software Engineering Information Repository Software Technology Review Community Services (SPINs, SEPGs, …) People Focus Personal Software Process SM (PSP SM ) Team Software Process SM (TSP SM ) Context Focus Product Line FW COTS FW Evol Acq FW Context specific diagnostic and analysis methods (e.g., architecture, survivability) SM CMM Integration, Personal Software Process, PSP, Team Software Process, and TSP are a service marks of Carnegie Mellon University

S. Cross’ USC CSE Presentation – 3/12/ page 10 © 2002 by Carnegie Mellon University SEI’s Body of Work 1 (today) Engineering Organization CMM Integration v1.1 People Focus Context Focus ProcessProduct People

S. Cross’ USC CSE Presentation – 3/12/ page 11 © 2002 by Carnegie Mellon University CMMI Process Area for Requirements Development Develop Customer Requirements Develop Product Requirements Analyze & Validate Requirements Collect stakeholder needs Elicit needs Transform into customer requirements Establish product and component requirements Allocate product component requirements Identify interface requirements Establish operational concepts and scenarios Establish a definition of required functionality Analyze requirements Evaluate product cost, schedule, risk Validate requirements CMMI SM Requirements Development SM CMM Integration and CMMI are service marks of Carnegie Mellon University.

S. Cross’ USC CSE Presentation – 3/12/ page 12 © 2002 by Carnegie Mellon University There Are Many Different Practices Technology demos Prototypes Brainstorming Market surveys Stories Use cases Business case analysis Reverse engineering* Observation of existing products * for legacy products A few for requirements elicitation include:

S. Cross’ USC CSE Presentation – 3/12/ page 13 © 2002 by Carnegie Mellon University Consider Different Approaches for Requirements Elicitation Approaches Example Elicitation Practices Key Insights Synch and stabilize Usability lab, focus groups Discover features that have greatest market appeal Extreme programming StoriesPrioritized functionality Rational Unified Process Use cases Functionality/performance tradeoffs Product line practice Change cases, use case variation points Understand commonalities and identify variations COTS-driven systems Market analysis Understand marketplace influences/opportunities

S. Cross’ USC CSE Presentation – 3/12/ page 14 © 2002 by Carnegie Mellon University CMM Integration (CMMI) SEI POC: Jay Douglass, More Information: Key Ideas Software process improvement has resulted in significant quality and productivity gains over the past 10 years Common processes, guidance, assessment, evaluation, and training for software & systems engineering “Improving processes for better products” Use and Status Co-developed by industry, government, professional societies, and the SEI Version 1.1 released in Jan 2002 SEI Series, CMMI Distilled by Product Team Members Initial Managed Defined Quantitatively Optimizing Risk Productivity

S. Cross’ USC CSE Presentation – 3/12/ page 15 © 2002 by Carnegie Mellon University SEI’s Body of Work 2 (today) Engineering Organization CMM Integration v1.1 Software Engineering Information Repository Software Technology Review Community Services (SPINs, SEPGs, …) People Focus Personal Software Process (PSP) Team Software Process (TSP) Context Focus Product Line FW COTS FW Evol Acq FW Context specific diagnostic and analysis methods (e.g., architecture, survivability)

S. Cross’ USC CSE Presentation – 3/12/ page 16 © 2002 by Carnegie Mellon University Team Software Process (TSP) SEI POC: Jay Douglass, More Information: Key Idea “Maturity Level 5” outcomes by ensuring software teams have experience and commitment to use proven and validated processes Use and Status Maturity Level (ML) 5 performance achieved in 18 DoD & industry pilots TSP can be introduced quickly, improves performance at all MLs Seeking additional DoD pilots and transition opportunities System Test (Days/KLOC) BeforeAfter Sample data from 18 recent DoD & industry pilots

S. Cross’ USC CSE Presentation – 3/12/ page 17 © 2002 by Carnegie Mellon University Architecture Tradeoff Analysis (ATA) SEI POC: Jay Douglass, More Information: Key Ideas Use effective architecture evaluation practices to get early control over software system quality Quality Attribute Workshop (QAW) Architecture Tradeoff Analysis Method SM (ATAM SM ) Use and Status Numerous pilots in DoD and industry Books and training available FY02 Goal: incorporate into RFPs and SOWs conduct QAWs provide ATAM training coach adopters Supports analysis of the software system before it is built and tested SM Architecture Tradeoff Analysis Method and ATAM are service marks of Carnegie Mellon University

S. Cross’ USC CSE Presentation – 3/12/ page 18 © 2002 by Carnegie Mellon University Marketplace Design & Architecture COTS-Based Systems (CBS) SEI POC: John Foreman, (412) Jay Douglass, (412) Visit: Key Ideas Plan to evolve requirements Compare products’ processes to your own - adapt yours as needed Embrace the COTS marketplace Adopt evolution & negotiation as a way of life - use spiral approaches Change culture, update skills Plan cyclic technology refresh Current and Planned Products CBS awareness courses COTS product evaluation tutorial CURE SM – COTS Usage Risk Eval CBS process framework CBS engineering/design tools New CBS books Annual ICCBSS conference Traditional Approach “Waterfall” Required COTS Approach Simultaneous Definition and Tradeoffs System Context System Context Design & Architecture Implementation Build from Scratch Buy, Integrate, Continuously Refresh SM CURE is a service mark of Carnegie Mellon University

S. Cross’ USC CSE Presentation – 3/12/ page 19 © 2002 by Carnegie Mellon University Product Line Practice SEI POC: Jay Douglass, More Information: Key Ideas Reuse everything from similar systems (architecture, plans, components, requirements, etc.) Based on commercial industry’s best practices Involves business and technical practices along product and process dimensions Use and Status Organizations have realized 10x cycle-time reductions Book, courses, Product Line Practice Framework and Acquisition Companions all available Product Line Technical Probe: a diagnostic tool to support product line practice adoption and use Use a common asset base to manufacture Architecture Production Plan Business Case a related set of products

S. Cross’ USC CSE Presentation – 3/12/ page 20 © 2002 by Carnegie Mellon University Let Common Sense Prevail! Process Discipline Common Sense With thanks to Mark Paulk (SEI) and Sanjiv Ahuja (former President and COO of Telecordia Technologies) YesNo Yes No Quality Creative Chaos Mindless Bureaucracy Mindless Chaos

S. Cross’ USC CSE Presentation – 3/12/ page 21 © 2002 by Carnegie Mellon University Conclusion Today engineering organizations need to be agile, disciplined, and mature. CMMI provides a model for designing and improving an engineering organization (and the processes it can use to be successful in implementing a balanced product-process focus for different development contexts). PSP and TSP provide a rapid way to infuse each engineer and project team with software engineering skill and experience. SEI technical practices provide “how tos” for different development contexts. In addition, the SEI provides many ways for organizations and the entire community to share their experiences.

S. Cross’ USC CSE Presentation – 3/12/ page 22 © 2002 by Carnegie Mellon University Pointers to Related SEI Work Capability Maturity Modeling ® Personal Software Process and Team Software Process Architecture Tradeoff Analysis COTS-Based Systems Product Line Practice Community Services (SEIR, STR, etc.) ® Capability Maturity Modeling is a registered service mark of Carnegie Mellon University