Digital Library Projects’ MBASE Experience

1. Digital Library Projects’ MBASE Experience Dan Port USC-CSE Annual Research Review February, 2001

2. Topics • Overview of MBASE Experience • Project Results • Evolution of MBASE and Rationale • Current Work and Future Needs

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. 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. 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. 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. Example: Some Best PracticesCS577a 2000 Team 1 – LCP 4.1.4, FRD 4 Risk

8. Example: Some Best PracticesCS577a 2000 Team 8 – FRD 2.2 Requirements Satisfaction (also excellent conceptual integrity, see table 3)

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. 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. Topics • Overview of MBASE Experience • Project Results • Evolution of MBASE and Rationale • Current Work and Future Needs

12. Summary of Results 1996-2000

13. Topics • Overview of MBASE Experience • Project Results • Evolution of MBASE and Rationale • Current Work and Future Needs

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. Example: Coverage/Traceability of MBASE Product Models* Management & Implementation Domain Description System Analysis System Design Release Descriptions System Definition Statement of Purpose Organization Background Business Case Project Requirements Reqs. Satisfaction Project Goals Organization Goals Levels of Service Goals LOS Requirements LOS Tests Capability Requirements System Capabilities Capability Tests Organization Activities Operations Model` Behavior Model Methods/functions Component Model Object Model Organization Entities Data Structures Prototype Design Views Interaction Model Enterprise model Class Model Operational Concept Description (OCD) Construction,Transition,Support (CTS) External to MBASE System and Software Requirements Definition (SSRD) * Does not include all MBASE models System and Software Architecture Description (SSAD)

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

17. Example: CTS A First Class Deliverable

18. Evolution: Variance and Invariance

19. Example: MBASE Variation: (Schedule) All teams formed LCO ARB LCA ARB LCA Due Initial WinWin draft prototype LCO Due IOC Due CU S99 IOC Demos week 2.5 6 12 10 13 14 15 16 All teams formed LCO ARB LCA ARB Initial WinWin draft prototype LCA Due LCO Due IOC Due CU F99 IOC Demos week 2 4.5 7 8 11.5 12.5 14 15 577B All teams formed LCA ARB LCO ARB Re-team Transition Readiness Review Draft prototype LCA Due LCA Re-baseline ARB Initial WinWin IOC Delivery LCO Due USC week 2 6.5 9.5 5.5 10.5 14 15 17 21 28

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

22. Example: Team 3 (Pathology image search engine) OCD 2.3 System Boundary and Environment MedWeb Web system Users 1. Search of Pathology slides 2. Addition and removal of web sites from search list 3. UMLS integration 4. On-line help Administrator Digitized slides and images from USC as well as other schools Client Developers

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. Example: OCD 5. Prototyping outline 5. Prototyping 5.1 Objectives 5.2 Approach 5.2.1 Scope and Extent 5.2.2 Participants 5.2.3 Tools 5.2.4 Revision History 5.3 Initial Results 5.4 Conclusions

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. 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. 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. 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. Topics • Overview of MBASE Experience • Project Results • Evolution of MBASE and Rationale • Current Work and Future Needs

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. Identify next level system elements, objectives, and constraints Factor elements into system partitions Identify patterns Map patterns to COTS Reconcile architectural mismatches, constraint violations, establish COTS alternatives Evaluate trade-off considerations (e.g. integration effort) Evaluate COTS alternatives with respect to objectives and trade-off considerations Define next level system elements, objectives, constraints Validate COTS integration design Review system elements represented and objectives met Example: COTS Integration Spiral

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

33. Example: Effort Model Selection Matrix “-” is any value Stephen Jan 2000