CS577a Software Engineering I DCR ARB and Package Workshop

University of Southern California

Center for Systems and Software Engineering

11/20/2009 (c) 2000-2009 11

CS577a Software Engineering IDCR ARB and Package Workshop

A Winsor Brown11/20/09



11/20/2009 (c) 2000-2009 2

Instructional Incremental Commitment Model – Sw



11/20/2009 (c) 2000-2009 3

Packages: Instructional ICM-Sw

Too High, unaddressable

CCD-Core Capability Drivethrough; DCR- Development Commitment Review; ECR-Evaluation Commitment Review; FCR-Foundations Commitment Review;OCR- Operational Commitment Review; RDCR-Rebaselined Development Commitment Review; TRR-Transition Readiness Review; VCR-Valuation Commitment Review

Adjust Scope, priorities, or discontinue Adjust Scope, priorities, or discontinue

Too High, unaddressable

ExplorationExploration ValuationValuation FoundationsFoundations DevelopmentDevelopment

Team formed, project assigned

Start of FallSemester

Negligible

Acceptable

Risk?

High, butaddressable

Negligible

Acceptable

Risk?

High, butaddressable

Risk? Risk?

Semester Break

Risk?

Team reformed, project assigned

Risk? Risk?

Client Evaluation

Client Evaluation, Close Out

Report

End of Spring Semester

Project Release

OperationOperation

ConstructionConstruction TransitionTransition

Risk?

OCD, LCP, FED

OCD, LCP, FED

FCP-Level OCD, SSRD, SSAD, LCP, FED, SID, QMP*Prototype

FCP-Level OCD, SSRD, SSAD, LCP, FED, SID, QMP*Prototype

DCP-LevelOCD, SSRD, SSAD, LCP, FED, SID, QMP**, ATPC^, IP†, TP‡, Exec. Prototype

DCP-LevelOCD, SSRD, SSAD, LCP, FED, SID, QMP**, ATPC^, IP†, TP‡, Exec. Prototype

DCP-LevelOCD, SSRD, SSAD, LCP, FED, SID, QMP, ATPC, IP, TP, Exec. Prototype

DCP-LevelOCD, SSRD, SSAD, LCP, FED, SID, QMP, ATPC, IP, TP, Exec. Prototype

* Peer Review Strategy for Foundations; ** Peer Review and Test Strategy For Development; ^ at least one test case; † Skeletal for up through CCD; ‡ Team/Client tasks and dates identified* Peer Review Strategy for Foundations; ** Peer Review and Test Strategy For Development; ^ at least one test case; † Skeletal for up through CCD; ‡ Team/Client tasks and dates identified



11/20/2009 (c) 2000-2009 44

USC CS577 ARB Participants

•Project TeamEverybody presents something

•ReviewersClients

Instructors

Industry participants



11/20/2009 (c) 2000-2009 55

ARB Session Outline

• DCR similar format to FCR, different focus:Less time for OCD, PrototypeMore time for Architecture, Plans

• General rule on focus: emphasize your projects high risk areas– At FCR (in most cases) this will involve

establishing the operational concept (including system analysis)

– At DCR (in most cases) this will involve the system design and development plan (especially schedule)



11/20/2009 (c) 2000-2009 64

ARB Review Success Criteria

FCR DCRFor at least one architecture, a system built to arch. will:

• Support the Ops Concept

• Satisfy the Requirements

• Be faithful to the Prototype

• Be buildable within the budgets and schedules in the Plan

• Show viable business case

Key stakeholders committed to support Foundations Phase (to DCR)

For the selected architecture, a system built to the arch. will:

• Support the Ops Concept

• Satisfy the Requirements

• Be faithful to the Prototype

• Be buildable within the budgets and schedules in the Plan

All major risks resolved or covered by risk management plan

Key stakeholders committed to support full life cycle



11/20/2009 (c) 2000-2009 77

Development Commitment Review (DCR)

• More formal, with everything appropriate specifically tracing upward and downward

• No major unresolved issues or items, and closure mechanisms identified for any unresolved issues or items

• No more TBD's

• There should no longer be any "possible" or "potential" elements (e.g., Entities, Components, …)

• Persistant Information Classes with proper multiplicities

• No more superfluous, unreferenced items: each element (e.g., Entities, Components, …) either should reference, or be referenced by another element. Items that are not referenced should be eliminated, or documented as irrelevant



11/20/2009 (c) 2000-2009 88

DCR ARB Session Overview

• Less time for OCD, Prototype• More time for Architecture, Plan • Fine-tuning based on FCR ARB experience • Focus on changes since FCR • Emphasize material that is relevant to 577B

(or to end of class) • Risk management still fundamental



11/20/2009 (c) 2000-2009 9

ARB Chartsmanship & Presentation

9

• Do not repeat the EPG or LeanMBASE Guidelines• Do not sweat the small stuff• Use audience-based terminology• NEVER read a slide’s contents

– Paraphrase or hit only the high points– Practice, so it flows well, BEFORE your dry run

• Assume 2 minutes presentation time per chart– After timed dry run practice

• Don’t repeat previous speakers’ material – OK to refer to it

• Do dry runs with at least one outsider



11/20/2009 (c) 2000-2009 1010

DCR ARBDCR ARB Session Outline(x,y): (presentation time, total time)(5, 5) Acceptance Test Plan and Cases; Team's strong and weak points + Shaping &

Overall Project Evaluation (DEN Remote Team member)(5, 5) OCD. System purpose; changes in current system and deficiencies,

proposed new system, system boundary, and desired capabilities and goals; top-level scenarios

(5,10) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong)

(5, 10) SSRD. ALL high priority or changes in requirements; rating for all others(10, 15) Architecture. Overall and detailed architecture; design if critical; COTS/reuse

selections (NOT JUST CHOICES)(10, 15) Life Cycle Plan. Focus on 577b (no history) or ? as appropriate; Include plans for CTS

initial cycle “Plans” during 2nd Foundations IterationTeam members’ roles & responsibilities in 577b.

(5, 10) Feasibility Rationale. Refined business case; major risks; general discussion(0, 5) Feedback from Instructors• Plan on 2 minutes per briefing chart, except title• Focus on changes (particularly new things) since FCR• You may vary from the above: please notify ARB board members IN ADVANCE• QFP & QMP not presented/discussed due to time constraints.



11/20/2009 (c) 2000-2009 11

ExplorationExploration ValuationValuation FoundationsFoundations DevelopmentDevelopment

Team formed, project assigned

Start of Fall Semester

Client Evaluation, Close Out Report

End of Fall Semester

Project Release

OperationOperation

ConstructionConstruction TransitionTransition

Typical ProjectMilestones

Draft DCPackage

11/21 12/0111/1410/2010/0609/2208/22

OCD, LCP, FED

OCD, LCP, FED

TP,SP, ATPR, UM

TP,SP, ATPR, UM

ATPC: Acceptance Test Plan & Cases; ATPR: Acceptance Test Procedure & Results; IP: Iteration Plan; TP: Transition Plan; SP: Support Plan; UM: User Manual * Document / Scope adjusted; All documents are based on minimal system capabilities; ? SSRD only if significant glue code

All developed artifacts All developed artifacts

Instructional ICM-Sw: One semester projects (NDI/NCES)

FCP-Level OCD,

SSRD?, SSAD*, LCP, FED*, SID*, QMP*, Prototype

FCP-Level OCD,

SSRD?, SSAD*, LCP, FED*, SID*, QMP*, Prototype

DCP-LevelOCD,

SSRD?, SSAD*, LCP, FED*, SID*, QMP, ATPC, IP, Prototypes

DCP-LevelOCD,

SSRD?, SSAD*, LCP, FED*, SID*, QMP, ATPC, IP, Prototypes

ARB

ARB

ARB

ARB

T OR or CR R

T OR or CR R

PTRR

PTRR



11/20/2009 (c) 2000-2009 12

TRR/OCR for One Semester Development Projects10 min. Introduction

– Operational concept overview, TRR specific outline, transition objective & strategy

15 min. Demo of IOC (Product status demonstration) 5 min. Support Plan10 min. Data Reporting & Archiving25 min. Summary of Transition Plan (as appropriate)

– HW, SW, site, staff preparation– Operational testing, training, & evaluation– Stakeholder roles & responsibilities– Milestone plan– Required resources– Software product elements (code, documentation, etc.)

15 min. Feedback

*** Times are approximate ***



11/20/2009 (c) 2000-2009 13

NDI/NCIS-intensive ARB Session Outline (x,y): (presentation time, total time)

(5 , 5) Remote Team Member(s) (jointly) Team’s strong points & weak points (operational view and technical view) concerns & possible solutions

(5, 5) OCD. System objectives; result/ benefit-chain diagram; system boundary diagram; project constraints; current processes; system capabilities; level of services; deployment diagram

(10,10) Prototype/ demo/ sample screenshots Most significant capabilities [buying information](especially those with high risk if gotten wrong)

(5, 10) SSAD. System Architecture; Info&Arctifacts (if RDB); Deployment;(5, 10) LCP. Overall strategy; milestones and schedule; deliverables; Risks(5, 10) FCP. Assessment approach, assessment results, evaluation criteria, business case,

conclusion(5, 10) SID. Traceability Matrix (5, 10) Test Results. Test cases and results(5, 5) Transition Plan and Support Plan. HW/SW/Site preparation, support environment,

release strategy(10) Things done right; issues to address (Instructional staff)• Plan on 2 minutes per briefing chart, except title• Each chart MUST have information SPECIFIC to your project



11/20/2009 (c) 2000-2009 14

Details for two Semester Projects• Dates & Activities for client

• Planning expectations

• Construction Working Set



11/20/2009 (c) 2000-2009 15

Example Project ScheduleUPDATED for 2010

Jan. 11 to Feb 1 - Re-form teamsFeb. 12 - Draft DCR-Rebaseline on WebFeb. 15-16 - DCR-Rebaseline ARB reviewsMar. 8 – Mar. 26 - Core Capability DemosApr. 13 - Draft Transition Package on WebApr. 14-15 - Transition Readiness ReviewsApr. 19 - Installation and TransitionMay 5-6? - Operational Commitment Review for IOC

OR ???May 7 - Client Evaluations

15



11/20/2009 (c) 2000-2009 1616

Example Summary of Client Activities – UpdatedJan. 11 – Feb 12: Work with teams:

– Rebaseline prototype, WikiWinWin, re-prioritized requirements– Plan for CS 577b specifics, including transition strategy, key risk items– Participate in ARB review of rebaselined Life Cycle Architecture Package

Jan. 4 - Apr 13: Nominal Weekly Meetings with Teams to:– Discuss status and plans– Provide access to key transition people for strategy and readiness

discussions

Mar. 8 – Mar. 26: Core Capability Demos (with TAs/Instructor)

Apr. 14-15: Project Transition Readiness Reviews

Apr. 19: Begin Installation and Transition– Install Product– Execute Transition Plan

May 5-6: Release Readiness Review for Product Release

May 7: Client Evaluations



11/20/2009 (c) 2000-2009 17

All Plans and Major Activities Should be Explicitly Planned

• Allocate effort and people (by name) in LCP to– Write plans– Execute plan activities– Prepare for RDCR and TRR reviews, Core Capability

Demo

• Anticipate and account for risks– Allocate extra time for risky items– Explicitly schedule critical contingency plans

• Be consistent with the class schedule

17



11/20/2009 (c) 2000-2009 18

Overall Summary: Example

18

Valuation Foundation Construction Transition

Users Users role and

functions subsumed by Clients

Users role and functions subsumed by

Clients.

(if any user is available else subsumed by

Clients) Review and test the system (or its

increment) in development

environment. Provide feedback about the

said system output and performance.

Review and test the system (or its increment) in operational

environment. Provide usage feedback to

Maintainer

Clients

Clients, NN and Keun Lee, impart

knowledge of Opportunity Tree, eBASE and DR,

Support definition and review of requirements specification,

operational concept and plan – accept or

reject options

NN monitors progress at milestones, review designs, prototypes, plans and feasibility during ARB, help refine Opportunity Tree knowledge,

provide alternative/enhanced concepts, Keun Lee provides empirical

information

Mentioned clients monitor progress at milestones. Review

and test the system by means of usage.

Review the system performance. Keun

Lee provides empirical information

Named clients Monitor progress Review

system performance of the system and its capability when

deployed in real world environment.



11/20/2009 (c) 2000-2009 19

By Phase / Stage

• For each member of the 577b continuing development team, identify his/her role and his/her primary and secondary responsibility during the various phases of the development.

• For incomplete 577b teams, identify needed team members and skills.

19



11/20/2009 (c) 2000-2009 20

Construction Planning Activities, Milestones and Deliverables (Example; 2008)

20



11/20/2009 (c) 2000-2009 21

Iteration Activities, Milestones and Deliverables

21



11/20/2009 (c) 2000-2009 22

Construction Working Set(per iteration)

• QMP with Peer Review Plan and Test Strategy • Iteration Plan (from start of iteration)• Acceptance Test Plan and Cases• Acceptance Test Procedures and Results• Release Description• Iteration Assessment Report• Iteration implementation (under CM)

– Source code, compile-time files, executables, test drivers

• As-built OCD, SSRD, SSAD, FRD, LCP

22



11/20/2009 (c) 2000-2009 23

Iteration Plan1.1 Capabilities to be implemented

– Usually specified by listing requirements from SSRD

1.2 Capabilities to be tested – “Verification” is via technique appropriate to the requirement

• Usually testing, but can be peer review, client agreement, …• Consult the “measurable” attribute of the requirement

1.3 Capabilities not to be tested– Identify features which will not be tested this iteration and

why.

2 Plan (for the iteration)– Usual planning information: Tool Support, Schedule,

Resources, Responsibilities

Iteration plan is input to the next iteration plan.

23



11/20/2009 (c) 2000-2009 24

Peer Review Plan – In QMP1 Describes peer review techniques to be used during the

project (by reference)2 For RoleBased Peer review: identify participants & roles

– Also list specific artifacts to be team peer reviewed

3 For Agile Artifact Review– Also list specific artifacts to be reviewed by a peer

4 Peer review processes (by reference)– Cover protocols for peer review meeting

Process details (by reference)1 Defect Classification(s)2 Peer review forms

24



11/20/2009 (c) 2000-2009 25

Quality Management PlanDescribes plans for certain types of effort which increase the

likelihood that the system will satisfy stakeholders’ win conditions• Writing code so that it’s readable, it contains certain useful

information, and it avoids certain errorsCoding Guidelines

• Using peer reviews to catch defects earlyPeer Reviews (coordinate with Peer Review Plan)

• Seeing that all requirements are verified, in an appropriate wayRequirement VerificationTesting strategies and levels

• Ensuring that software changes are as agreed to by stakeholders and are as planned

• Describes plans for managing the testing process: What kinds of tests (5) with level/kind of documentation

• Identifies Configuration Management & CM system • Specifies project's Change Management?

25



11/20/2009 (c) 2000-2009 26

Test Plan and Cases

Acceptance Test Plan and Cases• Covers specifying testing resources and planning for

their use– How many tests will be run– How long will each take– What kind(s) of platform(s) are needed to run tests– Testing schedule

• Specifies detailed test cases: – specific inputs – expected specific outputs (or how/where to observe)

26



11/20/2009 (c) 2000-2009 27

Iteration Assessment Report

• Each iteration is concluded by an iteration assessment– Overview

• Capabilities implemented• Summary of test results

– Adherence to Plan– External Changes Occurred– Suggested Actions

27



11/20/2009 (c) 2000-2009 28

Release Description

• The purpose of the Release Description is to describe the release– New Features and Important Changes since

the previous release– Upcoming Changes that will be incorporated in

future releases– Known Bugs and Limitations

28

CS577a Software Engineering I DCR ARB and Package Workshop

Documents

Transcript of CS577a Software Engineering I DCR ARB and Package Workshop