1 / 28

CS577a Software Engineering I DCR ARB and Package Workshop

CS577a Software Engineering I DCR ARB and Package Workshop. A Winsor Brown 11/20/09. 1. Instructional Incremental Commitment Model – Sw. Packages: Instructional ICM-Sw. Start of Fall Semester. Semester Break. Team formed, project assigned. End of Spring Semester.

mauli
Télécharger la présentation

CS577a Software Engineering I DCR ARB and Package Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Instructional Incremental Commitment Model – Sw (c) 2000-2009

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

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

  6. ARB Review Success Criteria (c) 2000-2009 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 (c) 2000-2009 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 (c) 2000-2009 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 (c) 2000-2009 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. (c) 2000-2009 10

  11. Instructional ICM-Sw: One semester projects (NDI/NCES) End of Fall Semester Start of Fall Semester Typical Project Milestones Draft DC Package ARB ARB 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 OR or CR R PTRR CCD ECR VCR FCR DCR 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 (c) 2000-2009

  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 *** (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 (c) 2000-2009

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

  15. Example Project ScheduleUPDATED 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 (c) 2000-2009 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. 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 (c) 2000-2009 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 (c) 2000-2009 17

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

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

  21. Iteration Activities, Milestones and Deliverables (c) 2000-2009 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 (c) 2000-2009 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. (c) 2000-2009 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 (c) 2000-2009 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? (c) 2000-2009 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) (c) 2000-2009 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 (c) 2000-2009 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 (c) 2000-2009 28

More Related