1. CS577a Software Engineering I DCR ARB and Package Workshop
A Winsor Brown
11/20/09
11/20/2009
(c) 1

2. Instructional Incremental Commitment Model – Sw
11/20/2009
(c)

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
Exploration
Valuation
Foundations
Development
ECR
VCR
FCR
DCR
Team formed,
project assigned
Start of
Fall
Semester
Negligible
Acceptable
Risk?
High, but
addressable
Break
RDCR
Team reformed,
CCD
TRR 1
Client Evaluation
Client Evaluation, Close Out Report
End of Spring
Project Release
OCR
Operation
Construction
Transition 2
OCD, LCP, FED
FCP-Level OCD,
SSRD,
SSAD,
LCP, FED,
SID, QMP*
Prototype
DCP-Level
OCD, SSRD,
SSAD, LCP, FED, SID, QMP**, ATPC^, IP†, TP‡, Exec. Prototype
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
11/20/2009
(c)

4. USC CS577 ARB Participants
•Project Team
Everybody presents something
•Reviewers
Clients
Instructors
Industry participants
11/20/2009
(c) 4

5. ARB Session Outline DCR similar format to FCR, different focus:
Less time for OCD, Prototype
More 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) 5

6. ARB Review Success Criteria
FCR
DCR
For 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:
All major risks resolved or covered by risk management plan
Key stakeholders committed to support full life cycle
11/20/2009
(c) 4

7. 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) 7

8. 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) 8

9. ARB Chartsmanship & Presentation
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) 9

10. DCR ARB DCR 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 Iteration
Team 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) 10

11. Instructional ICM-Sw: One semester projects (NDI/NCES)
End of
Fall Semester
Start of
Fall Semester
Typical
Project
Milestones
Draft DC
Package
A R B
A R B
FCP-Level OCD,
SSRD?,
SSAD*,
LCP,
FED*,
SID*,
QMP*,
Prototype
DCP-Level
OCD,
SSRD?,
SSAD*,
LCP,
FED*,
SID*,
QMP,
ATPC, IP,
Prototypes
Team formed,
project assigned
Client Evaluation, Close Out Report
All developed artifacts
OCD, LCP, FED
Project
Release
TP,
SP,
ATPR, UM
08/22
09/22
10/06
10/20
11/14
11/21
12/01
T O R or C R R
ECR
VCR
FCR
DCR
CCD
P T R R
Exploration
Valuation
Foundations
Development
Operation
Construction
Transition
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
11/20/2009
(c) 11

12. TRR/OCR for One Semester Development Projects
10 min. Introduction
Operational concept overview, TRR specific outline, transition objective & strategy
15 min. Demo of IOC (Product status demonstration)
5 min. Support Plan
10 min. Data Reporting & Archiving
25 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)

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)

14. Details for two Semester Projects
Dates & Activities for client
Planning expectations
Construction Working Set
11/20/2009
(c)

15. Example Project Schedule UPDATED for 2010
Jan. 11 to Feb 1 - Re-form teams
Feb Draft DCR-Rebaseline on Web
Feb DCR-Rebaseline ARB reviews
Mar. 8 – Mar Core Capability Demos
Apr Draft Transition Package on Web
Apr Transition Readiness Reviews
Apr Installation and Transition
May 5-6? - Operational Commitment Review for IOC OR ???
May 7 - Client Evaluations
11/20/2009
(c) 15

16. Example Summary of Client Activities – Updated
Jan. 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 : 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) 16

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
11/20/2009
(c) 17

18. Overall Summary: Example
11/20/2009
(c) 18 18

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.
11/20/2009
(c) 19 19

20. Construction Planning Activities, Milestones and Deliverables (Example; 2008)
11/20/2009
(c) 20

21. Iteration Activities, Milestones and Deliverables
11/20/2009
(c) 21

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
11/20/2009
(c) 22

23. Iteration Plan 1.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.
11/20/2009
(c) 23

24. Peer Review Plan – In QMP
1 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
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)
Defect Classification(s)
Peer review forms
11/20/2009
(c) 24

25. Quality Management Plan
Describes 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 errors
Coding Guidelines
Using peer reviews to catch defects early
Peer Reviews (coordinate with Peer Review Plan)
Seeing that all requirements are verified, in an appropriate way
Requirement Verification
Testing 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?
11/20/2009
(c) 25

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)
11/20/2009
(c) 26

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
11/20/2009
(c) 27

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
11/20/2009
(c) 28