CS577a Software Engineering I DCR ARB and Package Workshop

1. CS577a Software Engineering IDCR ARB and Package Workshop Supannika Koolmanojwong 1

2. ICSM – Software Engineering Class

4. USC CS577 ARB Participants •Project Team Everybody presents something •Reviewers Clients Instructors Industry participants 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) 5

6. ARB Review Success Criteria 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 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 8

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

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

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.

12. Tailored Presentation for Team 7 Analysis of Alternatives • (5) Executive Summary – Project Status, Risk and Mitigation Plan • 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 • FED – Tools Comparison and Business Case Analysis • (15) Discussion of Alternative selection

13. Details for two Semester Projects Dates & Activities for client Planning expectations Construction Working Set

14. Project Schedule –Spring 2011 Jan. 10 to 28 - Re-form teams Feb. 14 - Draft RDCR Feb. 16-18 - RDCR ARB Mar. 30- April 1 - Core Capability Drivethru Apr. 13 - Draft Transition Package on Web Apr. 13-15 - Transition Readiness Reviews Apr. 19 - Installation and Transition May 5 - Operational Commitment Review for IOC May 7 - Client Evaluations 14

15. Example Summary of Client Activities – Updated • Jan. 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 15

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

17. Overall Summary: Example 17

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

19. Major milestones in 577b 19

20. Major Activities in RDCR, Development Phase-Construction Iteration

21. Major Activities in Development Phase-Transition Iteration

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

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

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

25. An Example of a Test Case • TC-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 Level • This test will be performed at the system software item level. • Test Class • This test will include both user functions and erroneous input tests. • Test Completion Criteria

26. An Example of a Test Case

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

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