CS577a Software Engineering I DCR ARB and Package Workshop

University of Southern California

Center for Systems and Software Engineering

11/22/2010 11

CS577a Software Engineering IDCR ARB and Package Workshop

Supannika Koolmanojwong



11/22/2010 2

ICSM – Software Engineering Class



11/22/2010 3



11/22/2010 44

USC CS577 ARB Participants

•Project TeamEverybody presents something

•ReviewersClients

Instructors

Industry participants



11/22/2010 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/22/2010 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/22/2010 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/22/2010 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/22/2010 9

ARB Chartsmanship & Presentation

9

• Do not repeat the EPG • 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/22/2010 1010

DCR ARB – Architected Agile Teams(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, Iteration Plan

(5, 10) Feasibility Evidence. 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/22/2010 11

DCR ARB – NDI/NCS Teams (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 objectives; result/ benefit-chain diagram; system boundary diagram;

project constraints; current processes; system capabilities; level of services(10,15) Prototype/ demo/ sample screenshots Most significant capabilities [buying

information](especially those with high risk if gotten wrong)(5, 10) SSAD. System Architecture; Info& Artifacts (If possible) Deployment;(5, 15) LCP. Focus on 577b (no history) or ? as appropriate; Include plans for CTS initial

cycle “Plans” during 2nd Foundations Iteration, Iteration Plan(5, 10) FED. Assessment approach, assessment results, evaluation criteria, business case,

conclusion(5, 10) SID. Traceability Matrix (5, 5) Test Results. Test cases and results (if any)(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• 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/22/2010 12

Tailored Presentation for Team 7 Analysis of Alternatives

(5) Executive Summary – Project Status, Risk and Mitigation Plan(10) WinWin Agreements – List all agreements, and agreements

tracing to each tool(15) Prototype – Main functionalities from each alternative(5) OCD - Boundary Diagram, Element Relationship diagram(10) SSAD – Use Case Diagrams, Deployment Diagrams(10) LCP – Tasks, resources and alternative plan(10) FED – Tools Comparison and Business Case Analysis

(15) Discussion of Alternative selection



11/22/2010 13

Details for two Semester Projects• Dates & Activities for client

• Planning expectations

• Construction Working Set



11/22/2010 14

Project Schedule –Spring 2011

Jan. 10 to 28 - Re-form teamsFeb. 14 - Draft RDCRFeb. 16-18 - RDCR ARBMar. 30- April 1 - Core Capability DrivethruApr. 13 - Draft Transition Package on WebApr. 13-15 - Transition Readiness ReviewsApr. 19 - Installation and TransitionMay 5 - Operational Commitment Review for IOCMay 7 - Client Evaluations

14



11/22/2010 1515

Example Summary of Client Activities – UpdatedJan. 10 – Feb 11: 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. 10 - Apr 11: Nominal Weekly Meetings with Teams to:– Discuss status and plans– Provide access to key transition people for strategy and readiness

discussions

Mar. 30 – Apr 1: Core Capability Demos (with TAs/Instructor)

Apr. 13-15: Project Transition Readiness Reviews

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

May 2-4: Release Readiness Review for Product Release

May 6: Client Evaluations



11/22/2010 16

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

Drivethru

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

• Be consistent with the class schedule

16



11/22/2010 17

Overall Summary: Example

17

Valuation Foundations DevelopmentConstruction 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,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/22/2010 18

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.

18



11/22/2010 19

Major milestones in 577b

19



11/22/2010 20

Major Activities in RDCR, Development Phase-Construction Iteration



11/22/2010 21

Major Activities in Development Phase-Transition Iteration



11/22/2010 22

Construction Working Set(per iteration)

• 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, FED, LCP

22



11/22/2010 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/22/2010 24

Test Plan and CasesAcceptance 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)

24



11/22/2010 25

Test Identifier TC-01Completion Criteria

- User is able to access the online record plant service system by typing system URL at the address of web browser from handheld device through the internet - User is able to properly login in to the system from handheld device through the internet. - User is able to check-in to the system by using barcode number.- Plant condition information is filled properly while user performs plant maintenance in each location via web browser using handheld device.- Inputs plant information is saved properly after a user hits “Save” button via web browser using handheld device.- Inputs plant information is submitted completely after a user hits “Submit” button via web browser using handheld device.

An Example of a Test CaseTC-01 Website Worker Role

Test Case 01 covers the features of the online record plant service system using by workers related to the web interface on the handheld device. This test includes test cases covering user log in to the system via the website, check-in at working location using the handheld device, provide plant conditions and comments, save and submit plant information to the server.

Test LevelThis test will be performed at the system software item level.

Test ClassThis test will include both user functions and erroneous input tests.

Test Completion Criteria



11/22/2010 26

Test Case number TC-01-01Test Item TC-01Test Priority M (Must have)Pre-conditions HW/SW ready, Internet and GPRS signal availabilityPost-conditions System operational state, no error condition not handled by the systemInput Specifications User will attempt to access the online record plant service system by typing

system URL (http://seacliff.usc.edu:9008/) at the address of web browser from handheld device through the internet.

Expected Output Specification

Worker Login page of online record plant service system displays at user screen.

Pass/Fail Criteria Validate whether system shows correct Worker Login page or not by checking the document title. Pass if it is “Worker Login”. Otherwise, fail.

Assumptions and Constraints

Connectivity between user’s handheld device and server must available and properly configured. GPRS signal is strong enough to connect to service provider. BlackBerry browser must be used.

Dependencies GPRS signal is strong enough to connect to service provider. Internet connection must be available and properly configured on both the server and handheld device. Website IP address/DNS settings are correct.

Traceability OC1, CR2

An Example of a Test Case



11/22/2010 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/22/2010 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

Documents

CS577a Software Engineering I DCR ARB and Package Workshop