University of Southern California Center for Software Engineering CSE USC 1 Digital Library...

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


USC

Topics

• Overview of MBASE Experience

• Project Results

• Evolution of MBASE and Rationale

• Current Work and Future Needs

3


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


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


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


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


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


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


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


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


USC

Topics


• Project Results



12


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


USC

Topics


• Project Results



14


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


USC

Topics


• Project Results



30


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


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


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


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

University of Southern California Center for Software Engineering CSE USC 1 Digital Library...

Documents

Transcript of University of Southern California Center for Software Engineering CSE USC 1 Digital Library...