Post on 15-Dec-2015
1
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Digital Library Projects’ MBASE Experience
Dan Port
USC-CSE Annual Research Review
February, 2001
2
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Topics
• Overview of MBASE Experience
• Project Results
• Evolution of MBASE and Rationale
• Current Work and Future Needs
3
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Example: Some Best Practices
CS577a 2000 Team 1 – LCP 4.1.4, FRD 4 Risk
Weekly Ranking Risk I tems Current Previous No. Of
Weeks
Risk Resolution Progress
Schedule 1 1 11 Requirements have been prioritized and staged delivery approach has been used.
Personnel Shortfalls
2 4 11 The team members are being trained to gain some experience.
Performance & Quality
3 5 10 Design issues have been thoroughly addressed and reviews have been conducted.
Team Consistency
4 2 11 All the team members in CS 577a plan to take CS 577b as well.
Risk-02: Personnel Shortfalls
Description The development team may not be
experienced with the skill set required for developing the system.
Risk Exposure Potential Loss - High Probability - Medium The personnel shortfalls may affect the quality and the on schedule delivery of the project.
Risk Reduction Leverage The requirements have been prioritized and staged delivery approach has been used.
Actions to Mitigate Risk The development team members will undergo training to acquire the required skills.
Contingency Plan The remaining members of the team should share the burden.
8
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Example: Some Best PracticesCS577a 2000 Team 8 – FRD 2.2 Requirements Satisfaction
Operational Scenarios
System Requirements Architecture Support
SC-01, SC-02 [OCD 4.5.1]
RQ-1, RQ-2 [SSRD 3.2.1.1] COM-01, COM-03 and DCOM 01 [SSAD 2.1.1, 2.1.3 and 3.1.2.1]
SC-04 [OCD 4.5.1] ORQ -1[SSRD 3.2.2] COM-01 and DCOM-01 [SSAD 2.1.1 and 3.1.2.1]
SC-03 [OCD 4.5.1] RQ-2 [SSRD 3.2.1.1] COM-01 [SSAD 2.1.1]
SC-05, SC-06 [OCD 4.5.1]
RQ-3 [SSRD 3.2.1.2] COM-02 [SSAD 2.1.2]
SC-10 [OCD 4.5.1] ORQ-2 [SSRD 3.2.2] COM-02 [SSAD 2.1.2]
SC-7 RQ-4 [SSRD 3.2.1.2] COM-3 and DCOM-01 [SSAD 2.1.3, 3.1.2.1]
SC-11 [OCD 4.5.1] ORQ-3 [SSRD 3.2.2] COM-02 and DCOM-01 [SSAD 2.1.2, 3.1.2.1]
SC-08 [OCD 4.5.1] RQ-5, RQ-6 and RQ-7 [SSRD 3.2.1.2]
COM-03 and DCOM-01 [SSAD 2.1.3 and 3.1.2.1]
SC-09 [OCD4.5.1] RQ-8 [SSRD 3.2.1.2] COM-02 [SSAD 2.1.2]
SC-12 [OCD 4.5.1] ORQ-4 [SSRD 3.2.2] COM-02 [SSAD 2.1.2]
(also excellent conceptual integrity, see table 3)
9
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Topics
• Overview of MBASE Experience
• Project Results
• Evolution of MBASE and Rationale
• Current Work and Future Needs
12
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Summary of Results 1996-2000Metric USC
1996-97
USC 1997-98
USC 1998-99
USC 1999- 00
Columbia U-grad. S99
Columbia Grad. S99
Columbia U-grad. F99
Columbia Grad. F99
Fall Semester: LCA Package
Teams 15 16 19 22 20 13 10 7 Students 86 80 102 100 107 59 44 26 Applications 12 15 17 22 10 10 10 7 Teams failing LCO review
4 4 1 1 10 6 5 1
Teams failing LCA review
0 0 0 0 0 1 1 0
Pages, LCO package 160 103 114 - 124 116 107 95
Pages, LCA package Client
230 154 167 - 142 142 140 109
Evaluation (1-5, 5 best)
4.46 4.67 4.74 4.48 - - - -
Spring Semester: IOC Package
Teams 6 5 6 8 Students 28 23 28 35 Applications 8 5 6 8
Remained the same since projects were only one semester long
Teams failing IOC acceptance review
0 0 0 1 0 0 1 0
Applications satisfying clients (*teams)
5 5 6 7 20* 12* 10* 7*
Applications not overtaken by events
6 4 4 4 10 9 10 6
Applications continued 3 3 4 4 2 3 1 2 Applications used 1 3 3 5 10 5 7 3 Client evaluation - 4.15 4.3 4.75 4.44 4.21 3.9 4.38
13
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Topics
• Overview of MBASE Experience
• Project Results
• Evolution of MBASE and Rationale
• Current Work and Future Needs
14
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Operations Model`
Object Model
Capability Requirements
System Definition
Class Model
Project Requirements
Statement of Purpose
Project Goals
Organization Goals
System Capabilities
Component ModelOrganization Entities
Behavior Model
Enterprise model
Domain Description System Analysis System 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 CaliforniaCenter for Software EngineeringC S E
USC
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.3Librarian 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 CaliforniaCenter for Software EngineeringC S E
USC
Example: CTS A First Class DeliverableIteration Plans
Iteration Plan - 1 Quality Management Plan
Iteration Assessment Report - 1 Test Plan
Test Report ( HR Part ) - 1 Inspection Plan
Test Report ( Web Part ) - 1 TRANSITION SET
Release Description - 1 Transition Plan
Inspection Report - 1 User Manual
As-Built Specs - 1 SUPPORT SET
As-Built OCD - 1 Support Plan
As-Built SSRD - 1 Traning Materials
As-Built SSAD - 1 ( Summary Of Changes ) Regression Test Package
As-Built LCP - 1 Packaged Tools and Procedures
As-Built FRD - 1 ( Summary Of Changes )
As-Built Rose Models(MDL) Source Code ( HR Part ) ( Web Part )
18
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Evolution: Variance and InvarianceInvariants Variants
1. Defining and sustaining a stakeholder win-win relationship through the system's life-cycle.
2. Using the MBASE Model Integration
Framework. 3. Using the MBASE Process Integration
Framework. 4. Using the LCO, LCA, and IOC
Anchor Point milestones.
5. Ensuring that the content of MBASE artifacts and activities is risk-driven.
1. Use of particular success, process, product, or property models.
2. Choice of process or product
representation. 3. Degree of detail of process, product,
property, or success modeling. 4. Number of spiral cycles or builds
between anchor points. 5. Mapping of activities onto Inception-
Elaboration-Construction-Transition phases.
6. Mapping of staff levels onto activities.
19
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Example: MBASE Variation: (Schedule)
2.5
All teams formed
6
Initial WinWin
draft prototype
LCO ARB
10
LCO Due
LCA ARB
12 13
LCA DueIOC Due
14 15
IOC Demos
16
2
All teams formed
4.5
Initial WinWin
draft prototype
LCO ARB
7
LCO Due
LCA ARB
8 12.5
LCA DueIOC Due
11.5 14
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
14 15
LCA Re-baseline ARB
17
week
Draft prototype
USC
CU S99
CU F99
Re-team
21 28
Transition Readiness Review
IOC Delivery
week
week
20
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Example: Team 3 (Pathology image search engine) OCD 2.3 System Boundary and Environment
Users
1. Search of Pathology slides2. Addition and removal of web sites from search list3. UMLS integration4. On-line help
Administrator
MedWeb Web system
Digitized slides and
images from USC as well
as other schoolsDevelope
rs
Client
23
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 fortrade-offs for identifying and integrating COTS into you system
26
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
Example: COTS in Design Views GuidelinesDesign 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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Topics
• Overview of MBASE Experience
• Project Results
• Evolution of MBASE and Rationale
• Current Work and Future Needs
30
University of Southern CaliforniaCenter for Software EngineeringC S E
USC
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 CaliforniaCenter for Software EngineeringC S E
USC
Example: COTS Integration Spiral1. 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 CaliforniaCenter for Software EngineeringC S E
USC
Example: MBASE COTS Integration Spiral1. 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 CaliforniaCenter for Software EngineeringC S E
USC
Example: Effort Model Selection Matrix
MODEL \ Parameters
Analysis time Developer skill set
Project Volatility
Project Concept Integrity
Available Project metrics
Developer Experience
COTS Estimator Experience
Project precedence
Estimator Experience
Ad-Hoc LOW MED - HIGH
- - - - LOW MED-HIGH
MED-HIGH
HIGH
Productivity Extrapolation
from prototype
HIGH - LOW-MED HIGH HIGH - LOW MED-HIGH
- MED-HIGH
COCOMO MED - - - MED - LOW MED - MED
BROOKS EQN
MED - MED - MED - - - - MED
Group Consensus
MED - - HIGH - MED-HIGH
- MED - MED
Effort Analogy
LOW - LOW MED HIGH - - MED HIGH MED-HIGH
Statistical analogy
MED-HIGH
- LOW MED HIGH - - MED HIGH -
Stephen Jan 2000
“-” is any value