1. University of Southern California Center for Software Engineering CSE USC 1 Digital Library Projects’ MBASE Experience Dan Port USC-CSE Annual Research Review February, 2001

2. University of Southern California Center for Software Engineering CSE USC 2 Topics Overview of MBASE Experience Project Results Evolution of MBASE and Rationale Current Work and Future Needs

3. University of Southern California Center for Software Engineering CSE USC 3 Overview: What’s Working Well Architecture Review Boards: LCO, LCA, RLCA, TRR Digital Library domain specific software engineering –Simplifiers and complicators –Top 10 risks and management techniques –Use of particular models (WinWin, Results Chain, …) –Client “Domain Experts” Integration of development tools via MBASE –Easy WinWin, Rose, MSProject, COCOMOII

4. University of Southern California Center for Software Engineering CSE USC 4 Overview: What’s Working Well (continued) Projects classified in advance according to expectations: –Fully transitioned, operational system in 24 weeks –Transition after 24 weeks –Advanced prototype after 12 or 24 weeks –Project feasibility assessment

5. University of Southern California Center for Software Engineering CSE USC 5 Overview: What’s Working Well (continued) Prototyping as first class deliverables –New MBASE section OCD 5. Prototyping –“Early and often” prototyping –Prototyping workshops, guidance in use of prototypes Requirements –Different kinds modeled in different ways E.g. Level of Service versus System Capabilities –Tighter integration with WinWin and prototypes –Evolution requirements Helps manages priories and future desired development “Conflict avoiders”

6. University of Southern California Center for Software Engineering CSE USC 6 Overview: What’s Working Well (continued) Variants and invariants –Project models and deliverables are scaling better Risk based development –Explicit models for identification analysis, mitigation, contingencies, impacts, risk-exposure, etc. FRD as first class deliverable –Business Case, reqs. satisfaction, process rationale Conceptual Integrity –Tighter integration between models –Fewer model clashes

7. University of Southern California Center for Software Engineering CSE USC 7 Example: Some Best Practices CS577a 2000 Team 1 – LCP 4.1.4, FRD 4 Risk

8. University of Southern California Center for Software Engineering CSE USC 8 Example: Some Best Practices CS577a 2000 Team 8 – FRD 2.2 Requirements Satisfaction (also excellent conceptual integrity, see table 3)

9. University of Southern California Center for Software Engineering CSE USC 9 Overview: What Needs Improvement Use of Rational Unified Process (RUP) –More coherent use in SSAD Component, Enterprise, Object, Class, design views –More cohesive use throughout OCD Activity, Entity, usage scenarios SSRD requirements use cases and scenarios COTS based systems Empirical techniques –Defect reporting and analysis –Metrics and control

10. University of Southern California Center for Software Engineering CSE USC 10 Overview: What Needs Improvement (continued) Transition –577 generally constrains transition to 99% “cold turkey” students leave project after class ends Clients typically do not have adequate support personal to dedicate –Short fuse Less than two weeks to complete transition Clients typically can’t allocate adequate resources in time –Little leeway Hard to get students to continue after class ends (some internships, but not common) No place to get additional time if there are problems Clients have sever budget constraints and bureaucratic issues

11. University of Southern California Center for Software Engineering CSE USC 11 Topics Overview of MBASE Experience Project Results Evolution of MBASE and Rationale Current Work and Future Needs

12. University of Southern California Center for Software Engineering CSE USC 12 Summary of Results 1996-2000

13. University of Southern California Center for Software Engineering CSE USC 13 Topics Overview of MBASE Experience Project Results Evolution of MBASE and Rationale Current Work and Future Needs

14. University of Southern California Center for Software Engineering CSE USC 14 Evolution: Tighter Model Integration Coverage mappings –Explicit tracing built in to many models –Trace maps CTS first class deliverable –Integrated into main MBASE models and process –References to and from OCD, SSRD, SSAD, LCP, FRD, Prototypes, WinWin, etc. –See MBASE Guidelines V.2.2

15. University of Southern California Center for Software Engineering CSE USC 15 Operations Model` Object Model Capability Requirements System Definition Class Model Project Requirements Statement of Purpose Project Goals Organization Goals System Capabilities Component Model Organization Entities Behavior Model Enterprise model Domain DescriptionSystem AnalysisSystem Design Operational Concept Description (OCD) System and Software Requirements Definition (SSRD) System and Software Architecture Description (SSAD) Organization Background Organization Activities Interaction Model Levels of Service Goals LOS Requirements Example: Coverage/Traceability of MBASE Product Models* * Does not include all MBASE models Release Descriptions Reqs. Satisfaction Capability Tests Data Structures Methods/functions LOS Tests Management & Implementation Construction,Transition,Support (CTS) External to MBASE Business Case Prototype Design Views

16. University of Southern California Center for Software Engineering CSE USC 16 Example: Trace Map The USC Leavy Library maintains research books and periodicals for use by the USC community. OCD 3.1 Book OCD 3.5 Librarian OCD 3.5 USC Patron OCD 3.5 Manage lending of books to patrons OCD 3.3 This system manages book checkout, check-in, and overdue notifications for the Leavy Library. OCD 4.1 Library Card OCD 4.5.2 Handle book lending for library card OCD 4.3 Librarian checkout interface SSAD 2.1 Checkout Input Panel SSAD 3.2 Checkout Input Panel Controller SSAD 3.2 Checkout book from patron with library card number SSRD 3.2 This system provides an automated interface for Leavy Librarians for manging book lending for walk-in patrons. SSRD 3.1 Book Checkout Table (Oracle) Implementation Panel Controller class (Java) Implementation Checkout books SSAD 2.2 Verify library card SSAD 3.3 Store book in checkout table SSAD 3.3

17. University of Southern California Center for Software Engineering CSE USC 17 Example: CTS A First Class Deliverable

18. University of Southern California Center for Software Engineering CSE USC 18 Evolution: Variance and Invariance

19. University of Southern California Center for Software Engineering CSE USC 19 Example: MBASE Variation: (Schedule) 2.5 All teams formed 6 Initial WinWin draft prototype LCO ARB 10 LCO Due LCA ARB 12 13 LCA Due IOC Due 1415 IOC Demos 16 2 All teams formed 4.5 Initial WinWin draft prototype LCO ARB 7 LCO Due LCA ARB 812.5 LCA Due IOC Due 11.514 IOC Demos 15 2 All teams formed 6.5 Initial WinWin LCO ARB 5.5 LCO Due LCA ARB 9.5 10.5 LCA Due 577B 1415 LCA Re-baseline ARB 17 week Draft prototype USC CU S99 CU F99 Re-team 2128 Transition Readiness Review IOC Delivery week

20. University of Southern California Center for Software Engineering CSE USC 20 Example: OCD Shared Vision (inspired by The Information Paradox) 2. Shared Vision (SS) 2.1 System Capability Description (SS) 2.1.1 Benefits Realized 2.1.2 Results Chain 2.2 Key Stakeholders (PY) 2.3 System Boundary and Environment (PD) 2.4 Major Project Constraints (PY) 2.5 Top-Level Business Case (SS) 2.6 Inception Phase Plan and Required Resources (PY) 2.7 Initial Spiral Objectives, Constraints, Alternatives, and Risks (SS, PY)

21. University of Southern California Center for Software Engineering CSE USC 21 Example: Team 17 (Web Mail) OCD 2.1.2 Results Chain Design and implement a Web mail system Communication services are vital to quality academic life. Make email services easier to access and use. Creation of infrastructure for future Web- based services. Improve academic life at USC. Design and implement more advanced Web-based tools. Make graphical email available from any computer with web access. Create web- based basis for communication infrastructure. Create other systems integrated with Web mail system. Allow better communication between students, faculty, and staff. Provide better access to academic information and services. INITIATIVES CONTRIBUTIONS OUTCOMES ASSUMPTION

22. University of Southern California Center for Software Engineering CSE USC 22 Example: Team 3 (Pathology image search engine) OCD 2.3 System Boundary and Environment Users 1. Search of Pathology slides 2. Addition and removal of web sites from search list 3. UMLS integration 4. On-line help Administrat or MedWeb Web system Digitized slides and images from USC as well as other schools Developer s Client

23. University of Southern California Center for Software Engineering CSE USC 23 Evolution: More Explicit Use of Prototypes, COTS, and Tools OCD 5. Prototyping COTS Integration process, FRD, SSAD Design Views, Requirements support –Increasing numbers of 577 projects are largely or entirely COTS based 1998: 5 of 20 1999: 8 of 21 2000: 13 of 23 –More explicit MBASE COTS/Prototype integration guidelines Rose, MSProject, CVS/ClearCase, … Prototyping workshops –Early prototype reviews –Prototype integral part of ARB’s

24. University of Southern California Center for Software Engineering CSE USC 24 Example: OCD 5. Prototyping outline 5. Prototyping 5.1Objectives 5.2Approach 5.2.1Scope and Extent 5.2.2Participants 5.2.3Tools 5.2.4Revision History 5.3Initial Results 5.4Conclusions

25. University of Southern California Center for Software Engineering CSE USC 25 Example: Component Design Views and COTS guidelines Since Components are often a simple object + mechanism, many COTS products have been developed to handle common situations (patterns) reducing complex, tedious, repetitive, or unnecessary implementation details The Component model (SSAD 2.1) helps you identify and analyze architectural patterns for your system independent of technology implementation details e.g. information self service, distributed services The design views (SSAD 3.1) help you identify design patterns e.g. publish and subscribe, client-server COTS often exist to implement, partially implement, or assist in implementing design patterns! Warning: You must carefully and explicitly account for trade-offs for identifying and integrating COTS into you system

26. University of Southern California Center for Software Engineering CSE USC 26 Example: COTS in Design Views Guidelines Design Views are a natural place to match COTS to design patterns: Topology (SSAD 3.1.1) –Connectors and layers in are often associated with COTS Design Components (SSAD 3.1.2) –Typically COTS will exist for common complex patterns in Component model. Watch for applications and object libraries Frameworks (SSAD 3.1.3) –Frameworks are constructed to deal with common design needs and thus often are COTS Deployments (SSAD 3.1.4) –Legacy systems, common hardware and operating systems usually have COTS Logical Blocks (SSAD 3.1.5) –Many common block patterns, often these imply COTS

27. University of Southern California Center for Software Engineering CSE USC 27 Example: Prototypes and Design Views Guidelines Prototypes directly explore design issues –Design views help connect system analysis to design and thus to prototypes –Care should be taken to ensure prototypes do not drive the system analysis e.g. do not choose components or capabilities based on prototypes, use for risk reduction Topology (SSAD 3.1.1) –Prototypes explore component connectivity Design Components (SSAD 3.1.2) –Prototypes explore utility and feasibility of COTS for design use Frameworks (SSAD 3.1.3) –Prototypes often make extensive use of frameworks that imply design (watch for risk factors here) Deployments (SSAD 3.1.4) –Prototypes and final system often have similar deployment elements Logical Blocks (SSAD 3.1.5) –Prototypes must relate to logical system elements, helps with design

28. University of Southern California Center for Software Engineering CSE USC 28 Example: COTS and Prototypes Guidelines Prototypes are also a natural place to map patterns to COTS –Often use COTS in prototypes that imply use in design COTS often have competition that may be more suitable for the final product e.g. MS Access  Oracle, MySQL, MS SQL –Common to use prototyping to establish COTS trade- off factors (integration effort, L.O.S. qualities, etc.) Good planning can help make this proactive, advanced prototyping may still be required to resolve details –Design Views identify what COTS need prototyping

29. University of Southern California Center for Software Engineering CSE USC 29 Topics Overview of MBASE Experience Project Results Evolution of MBASE and Rationale Current Work and Future Needs

30. University of Southern California Center for Software Engineering CSE USC 30 Current Work Model Clash Analysis MBASE COTS Integration Spiral Patterns, Domain Specific Patterns MBASE variants (in particular MBASE for Construction, Transition, Support (CTS) Empirical Techniques –Reading –ODC –Student COCOMO Decision Tables –Lifecycle process –Effort model selection –Risk Management Trade-off –Transition and Support process selection

31. University of Southern California Center for Software Engineering CSE USC 31 Example: COTS Integration Spiral 1.Identify next level system elements, objectives, and constraints 2.Factor elements into system partitions 3.Identify patterns 4.Map patterns to COTS 5.Reconcile architectural mismatches, constraint violations, establish COTS alternatives 6.Evaluate trade-off considerations (e.g. integration effort) 7.Evaluate COTS alternatives with respect to objectives and trade-off considerations 8.Define next level system elements, objectives, constraints 9.Validate COTS integration design 10.Review system elements represented and objectives met

32. University of Southern California Center for Software Engineering CSE USC 32 Example: MBASE COTS Integration Spiral 1.Identify next level system capabilities (OCD 4.3), goals and constraints (OCD 4.2), and L.O.S. (OCD 4.4) 2.Factor system capabilities and requirements into system components and objects (SSAD 2.1, 3.1, 3.2) 3.Identify architectural patterns and design patterns (from component model SSAD 2.1, design views SSAD 3.1, and object model SSAD 3.2 4.Map patterns to COTS 5.Reconcile architectural mismatches, constraint violations, establish COTS alternatives (FRD 2.2, 5.2) 6.Evaluate trade-off and risk considerations (OCD 5, FRD 2.1, 2.2, 4, 5) 7.Evaluate COTS alternatives with respect to objectives and trade-off considerations (OCD 5.3, FRD 5) 8.Define next level system elements, objectives, constraints 9.Validate COTS integration design (prototypes, FRD 2.2, CTS Test Description and Results) 10.Review system elements represented and objectives met

33. University of Southern California Center for Software Engineering CSE USC 33 Example: Effort Model Selection Matrix Stephen Jan 2000 “-” is any value