1. University of Southern California Center for Systems and Software Engineering Simplifiers & Complicators and IICM-Sw Barry Boehm & A Winsor Brown CS 577a September 4, 2009

2. University of Southern California Center for Systems and Software Engineering The WinWin Approach The win-win approach is a set of principles, practices, and tools, that enable a set of interdependent stakeholders to work out a mutually satisfactory (win-win) set of shared commitments. 09/08/08©USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering Formulating Reasonable Win Conditions Can Be Hard: Two Cultures 09/08/08©USC-CSSE3 Customers Developers - No idea of the relative cost and difficulty of satisfying win conditions. -Likely to insist on infeasible win conditions as statements of need. -Likely to refrain from suggesting win conditions which they think are difficult to implement, but may be easy. - Golden rule: Do unto others as you would have others do unto you. -Don’t understand customer’s workflow - Build a system friendly to the programmers.

4. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE4 Conflicts in Win Conditions and Expectations Hard things for software people “If you can do queries with all those ands, ors, synonyms, data ranges, etc., it should be easy to do natural language queries.” “If you can scan the document and digitize the text, it should be easy to digitize the figures too.” Hard things for librarians “It was nice that you could add this access feature, but it overly (centralizes, decentralizes) control of our intellectual property rights.” “It was nice that you could extend the system to serve the medical people, but they haven’t agreed to live with our usage guidelines.”

5. University of Southern California Center for Systems and Software Engineering Simplifiers & Complicators: A Method for Dealing With Two-Cultures Problem Identify appropriate domain and System Boundary Diagram for project –Helps set context and acts as communication tool between clients and developers? Generate/refine high-level architecture ("Element Relationship Diagram" AKA Component & Connector diagram; more later ) for project –Acts as “context diagram” Map initial requirements (win conditions) to WinWin Taxonomy –These will be used later as a requirements outline (SSRD §2, 3 and 4) Top-n risk identification –This will be managed for your actual project using DART (later lecture) Identify simplifiers and complicators –For both developers and clients –First general then specific Note: These activities may be concurrent and iterative. 09/08/08©USC-CSSE5

6. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE6 S&C Subdomain (General) Type of Application System Boundary Diagram Multimedia Archive * Assets * … Archive Use standard query languages Use standard or COTS search engine Uniform media format Developer Simplifiers Developer Complicators Natural language processing Automated cataloging or indexing Digitizing large archives Digitizing complex or fragile artifact Rapid access to large archives Access to heterogeneous media collections Automated annotation, description or meanings to digital assets Integration of legacy systems

7. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE7 SimplifiersRisks and Trade-offs Generic Uniform Media Formats Specific All video clips are stored using an open file format for video/audio (e.g., MPEG). All film stills are stored using an open image file format (e.g., JPEG). The inverse complicator is to store film clips using streaming video technologies This means that we may have to convert existing digital assets or digitize the original media, which may be costly. A unique file format limits the user base to those who have viewers for that particular file format The chosen file format may not be the most efficient for the various types of media (in terms of compression rates, quality, etc...) Generic Use Standard Query Languages Specific Organize catalog and archive relationally so that queries will be limited to standard search formats,: match exactly by value on any of the fields with or without using boolean combinations (AND, OR, NOT, etc...), or using pattern matching (SQL LIKE keyword) May not be as effective for "discovering" assets in the archive: users must know what they're looking for, in order to search for it Generic Use Standard COTS Specific Use a standard Relational Database Management System (RDBMS) that supports storing multi-media assets A Relational Database Management System may not be most suited for archival of multi-media assets. A Relational Database Management System may have a high initial cost, high implementation, and high administration cost (requires specialized knowledge skills) S&C Developer-Side Simplifiers

8. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE8 ComplicatorsRisks and Trade-offs Generic Natural Language Processing Specific Store the information only in one language (e.g., English) and provide dynamic translation into Chinese, Japanese and Korean. The inverse simplifier is to store the same information in 4 different languages (English, Chinese, Japanese and Korean). The first approach is a complex, error-prone, expensive natural language processing issue The second approach will require more storage space, in addition to acquiring the translations Generic Digitizing Large Archives Specific Digitizing film clips from the entire collection of films (which grows at a very fast rate of 800 films per year for Indian films alone) If each film clip requires around 10 MB, then the rate of growth of the database will be of 8GB a year (exclusive of catalog information) Generic Integration of "Legacy" Systems Specific Do not require Real-Video plug-in for Web browsers to allow users to view streamed film clips We cannot use more effective multi-media formats, which are becoming standard technologies S&C Developer-Side Complicators

9. University of Southern California Center for Systems and Software Engineering Benefits of S&C Method Too Many early CS577a Projects Failed LCO/FCR Review -1996: 4 out of 16 (25%) -1997: 4 out of 15 (27%) LCO/FCR success criteria –Describes at least one feasible architecture –Satisfying requirements within cost/schedule/resource constraints –Viable cost-effective business case –Stakeholder concurrence on key system parameters Using S&C’s has reduced LCO/FCR review failure rate –1998: 1 out of 20 (5%), 1999: 1 out of 22 (4%) –40% of early student critiques cite S&C’s as helpful 09/08/08©USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Outline: IICM-Sw P 3 S Motivation: Model Clashes IICM-Sw P 3 S –Integration Framework –Process Framework –Anchor Point Milestones –Feasibility Evidence –Additional Documentation Examples of Successful Use of [ I]ICM-Sw –Over 50 Digital Library and eServices projects –TRW CCPDS-R project 09/08/08©USC-CSSE10

11. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE11 Understanding the Tar Pit: Model Clashes Model Clash: An incompatibility among the underlying assumptions of a set of model instantiations –Often unrecognized –Produces conflicts, confusion, mistrust, frustration, rework, throwaway systems

12. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE12 Examples of Model Clashes Design-to-schedule process, unprioritized requirements, and tightly-coupled architecture COTS-driven product and Waterfall process Firm Requirements and COTS-intensive project Risk-based process and spec-based progress payments Evolutionary development without architecture foundation Golden Rule(s) and stakeholder win-win Spec-based product/process and IKIWISI success model –I’ll know it when I see it

13. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE13 The Model-Clash Spider Web: Master Net } P3S Model Abbrev. Note Line Colors: Inherent | Master Net Specific

14. University of Southern California Center for Systems and Software Engineering ICM & IICM-Sw P 3 S Integration Framework 09/08/08©USC-CSSE14 Process models Life cycle anchor points Risk management Key practices Success models Business case IKIWISI Stakeholder win-win Property models Cost Schedule Performance Reliability Product models Domain model Requirements Architecture Code Documentation Planning and control Milestone content Evaluation and analysis Process entry/exit criteria Product evaluation criteria

15. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE15 IPM 1 guide progress in selecting, and serve and satisfy … reify … … intermediate … Product Models are refinements of impose constraints on provide parameters for set context for identify, prioritize Stakeholders Success Models Property Models Process Models Domain/ Environment Models Conceptual Product Models Reified Product Models IPM n enablesatisficing among determine the relevance of provide parameters for Provideevaluations for reifying WinWin Spiral Process Life Cycle Architecture Package Plan in LCA/DC Package IICM-Sw Process Framework

16. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE16 Success Models Drive Other Model Choices Success Model Key Stake- holders Key Property Models Process Model Product Model Demo agent-based E- commerce system at COMDEX in 9 months Entrepreneurs, venture capitalists, customers Schedule estimation Design-to-schedule Domain constrained by schedule; architected for ease in dropping features to meet schedule Safe air traffic control system Controllers, Govt. agencies, developers Safety models Initial spiral to risk-manage COTS, etc.; Final "waterfall" to verify safety provisions Architected for fault tolerance, ease of safety verification

17. University of Southern California Center for Systems and Software Engineering Life Cycle Anchor Points Common System/Software stakeholder commitment points –Defined in concert with Government, industry affiliates –Coordinated with Rational’s Unified Software Development Process Foundations Commitment Review [ Life Cycle Objectives] (FCR [LCO]) –Stakeholders’ commitment to support system architecting –Like getting engaged Development Commitment Review [Life Cycle Architecture] (DCR [LCA]) –Stakeholders’ commitment to support full life cycle –Like getting married Initial Operational Capability (IOC) –Stakeholders’ commitment to support operations –Like having your first child 09/08/08©USC-CSSE17

18. University of Southern California Center for Systems and Software Engineering 06/24/08©USC-CSSE18 Elements of Critical Front End Milestones (Risk-driven level of detail for each element) Milestone ElementFoundations Commitment ReviewDevelopment Commitment Review Definition of Operational Concept Top-level system objectives and scope - System boundary - Environment parameters and assumptions - Evolution parameters Operational concept - Operations and maintenance scenarios and parameters - Organizational life-cycle responsibilities (stakeholders) Elaboration of system objectives and scope of increment Elaboration of operational concept by increment Top-level functions, interfaces, quality attribute levels, including: - Growth vectors and priorities - Prototypes Stakeholders’ concurrence on essentials Elaboration of functions, interfaces, quality attributes, and prototypes by increment - Identification of TBD’s( (to-be-determined items) Stakeholders’ concurrence on their priority concerns Top-level definition of at least one feasible architecture - Physical and logical elements and relationships - Choices of NDI and reusable software elements Identification of infeasible architecture options Choice of architecture and elaboration by increment - Physical and logical components, connectors, configurations, constraints - NDI, reuse choices - Domain-architecture and architectural style choices Architecture evolution parameters Elaboration of WWWWWHH* for Initial Operational Capability (IOC) - Partial elaboration, identification of key TBD’s for later increments Assurance of consistency among elements above All major risks resolved or covered by risk management plan Identification of life-cycle stakeholders - Users, customers, developers, maintainers, interoperators, general public, others Identification of life-cycle process model - Top-level stages, increments Top-level WWWWWHH* by stage Assurance of consistency among elements above - via analysis, measurement, prototyping, simulation, etc. - Business case analysis for requirements, feasible architectures Definition of System Requirements Definition of System and Software Architecture Definition of Life- Cycle Plan Feasibility Evidence *WWWWWHH: Why, What, When, Who, Where, How, How Much System Prototype(s) Exercise key usage scenarios Resolve critical risks Exercise range of usage scenarios Resolve major outstanding risks

19. University of Southern California Center for Systems and Software Engineering Pass/Fail Feasibility Rationales Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will –Satisfy the requirements: capability, interfaces, level of service, AND evolution –Support the operational concept –Be buildable within the budges and schedules in the plan –Generate a viable return on investment –Generate satisfaction outcomes for all of the success- critical stakeholders All major risks resolved or covered by risk management plans Serves as basis for stakeholders’ commitment to proceed 09/08/08©USC-CSSE19

20. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE20 Post IOC Activities [Transition] Software preparation –Operational and support software –Data preparation, COTS licenses –Operational readiness testing Site preparation –Facilities, equipment, supplies, vendor support User, operator, and maintainer preparation –Selection, teambuilding, training

21. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE21 Anchor Points: Rational U[SD]P Phases and IICM-Sw Engineering Stage Manufacturing Stage InceptionElaborationConstructionTransition Feasibility Iterations Architecture Iterations Usable Iterations Product Releases Management REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP REQREQ DESDES IMPIMP DEPDEP LCOLCA IOC RATIONAL S o f t w a r e C o r p o r a t i o n ValuationFoundations ConstructionTransition FCRDCR IOC Development RUP ICM

22. University of Southern California Center for Systems and Software Engineering Outline: IICM-Sw P 3 S Motivation: Model Clashes IICM-Sw P 3 S –Integration Framework –Process Framework –Anchor Point Milestones –Feasibility Evidence –Additional Documentation Examples of Successful Use of IICM-Sw –Over 50 Digital Library and eServices projects –TRW CCPDS-R project 09/08/08©USC-CSSE22

23. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE23 The Early Digital Library Challenge 15 Digital Library Applications –2 sentence problem statements –Librarian clients 86 Graduate Students –30% with industry experience –Largely unfamiliar with each other or Library operations *Develop LCA packages in 11 weeks Re-form teams from 30 continuing students *Develop IOC packages in 12 more weeks –Including 2-week beta test and transition

24. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE24 Problem Statement #4: Medieval Manuscripts Ruth Wallach, Reference Center, Doheny Memorial Library I am interested in the problem of scanning medieval manuscripts in such a way that a researcher would be able to both read the content, but also study the scribe’s hand, special markings, etc. A related issue is that of transmitting such images over the network.

25. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE25 IICM-Sw Model Integration: LCO/FCR Stage determines content of Domain Model WinWin Taxonomy Basic Concept of Operation Frequent Risks, Architecture Options Stakeholders, Primary win conditions WinWin Negotiation Model IKIWISI Prototypes, Properties Models, Process Framework Environment Models WinWin Agreements Viable Architecture Options Updated Concept of Operation Life Cycle Plan elements Outstanding LCO/ FCR risks Requirements Description LCO/FCR Rationale Life Cycle Objectives/Foundations Commitment Review (LCO/FCR) Package Anchor Point Model determines identifies determines serves as table of contents for situatesexercise focus use of focus use of determines guides determination of validate inputs for provides initializeadoptidentify update achieveiterate to feasibility, consistency determines exit criteria for validates readiness of initializesinitializes

26. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE26 University of Southern California Center for Software Engineering CSE USC

27. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE27 Case Study: CCPDS-R Project Overview Characteristic Domain Size/language Average number of people Schedule Process/standards Contractor Customer Current status Environment CCPDS-R Ground based C3 development 1.15M SLOC Ada 75 75 months DOD-STD-2167A Iterative development Rational host DEC host DEC VMS targets TRW USAF Delivered On-budget, On-schedule RATIONAL S o f t w a r e C o r p o r a t I o n

28. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE28 CCPDS-R ICM P 3 S Models Success Models –Reinterpreted DOD-STD-2167a; users involved –Award fee flowdown to performers Product Models –Domain model and architecture –Message-passing middleware (UNAS) Process Models –Ada process model and toolset –Incremental builds; early delivery Property Models –COCOMO cost & schedule –UNAS - based performance modeling –Extensive progress and quality metrics tools

29. University of Southern California Center for Systems and Software Engineering 09/08/08©USC-CSSE29 Common Subsystem Macroprocess Development Life Cycle ConstructionElaboration Inception Competitive design phase: Architectural prototypes Planning Requirements analysis Contract award Architecture baseline under change control Early delivery of “alpha” capability to user Architecture IterationsRelease Iterations SSRIPDRPDRCDR 0 5 10 15 20 25 RATIONAL S o f t w a r e C o r p o r a t I o n (LCA/DCR) (LCO/FCR)