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

Instructional Incremental Commitment Model – Sw 11/20/2009 (c) 2000-2009

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) 2000-2009

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

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) 2000-2009 5

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) 2000-2009 4

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 7

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 8

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) 2000-2009 9

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) 2000-2009 10

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) 2000-2009 11

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) 2000-2009

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

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

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

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. 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 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 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) 2000-2009 17

Overall Summary: Example 11/20/2009 (c) 2000-2009 18 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. 11/20/2009 (c) 2000-2009 19 19

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

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

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) 2000-2009 22

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) 2000-2009 23

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) 2000-2009 24

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) 2000-2009 25

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) 2000-2009 26

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) 2000-2009 27

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) 2000-2009 28