1. University of Southern California Center for Systems and Software Engineering 1 CS577a Software Engineering I DCR ARB and Package Workshop Supannika Koolmanojwong

2. University of Southern California Center for Systems and Software Engineering ICSM – Software Engineering Class

3. University of Southern California Center for Systems and Software Engineering

4. University of Southern California Center for Systems and Software Engineering 4 USC CS577 ARB Participants Project Team Everybody presents something Reviewers Clients Instructors Industry participants

5. University of Southern California Center for Systems and Software Engineering 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)

6. University of Southern California Center for Systems and Software Engineering 4 ARB Review Success Criteria FCRDCR 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: 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

7. University of Southern California Center for Systems and Software Engineering Commitment Review Success Criteria TRR / OCR Show value Product works as expected (or not with noted exceptions) Product will help users do job Show quality development e.g. relevant parts of your IOC documentation Process Show sustainability e.g. support requirements/plans Transition plan & status Show confidence that product is/will be ready to be used e.g. Transition plan & status See also value Determine whether client needs anything further to ensure successful Transition and Operation Changes in priorities for remaining features? Changes being made to operational procedures? More materials needed for training? Changes in system data or environment we should prepare for? Anyone else who should experience CCD? CCD

8. University of Southern California Center for Systems and Software Engineering 8 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

9. University of Southern California Center for Systems and Software Engineering 9 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

10. University of Southern California Center for Systems and Software Engineering ARB Chartsmanship & Presentation 10 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. University of Southern California Center for Systems and Software Engineering 11 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) Requirements. 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.

12. University of Southern California Center for Systems and Software Engineering 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.

13. University of Southern California Center for Systems and Software Engineering TRR Agenda 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 ***

14. University of Southern California Center for Systems and Software Engineering TRR Presentation Summary Specific requirements for your presentation: –Your product! i.e., fully working IOC version –Salesman-like discussion of your project’s usefulness Base on your business case, etc Why is system going to be really great for customer –Transition issues & transition plan if you delivered your product how did it go? –(you should have by presentation) If not, when? –Support issues How will you support product, once deployed? –E.g. next term, for instance –OK to say that »You will never touch it ever again »Everything’s up to customer

15. University of Southern California Center for Systems and Software Engineering Details for two Semester Projects Dates & Activities for client Planning expectations Construction Working Set

16. University of Southern California Center for Systems and Software Engineering Project Schedule –Spring 2013 Jan. - Feb. : Work with teams: –Rebaseline prototype, prioritize requirements –Plan for CS 577b specifics, including transition strategy, key risk items –Participate in ARB review Feb – May : Scheduled Weekly Meetings with Teams to: –Discuss status and plans –Provide access to key transition people for strategy and readiness discussions Mar 27: Core Capability Drivethrough Apr 10 - 12: Project Transition Readiness ARB Reviews Apr 19: Installation and Transition –Install Product –Execute Transition Plan Apr 29: Operational Commitment Review for Initial Operational Capability May 7: Client Evaluations 16

17. University of Southern California Center for Systems and Software Engineering 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 17

18. University of Southern California Center for Systems and Software Engineering Overall Summary: Example 18 ValuationFoundations Development ConstructionTransition UsersUsers 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 ClientsClients, 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.

19. University of Southern California Center for Systems and Software Engineering 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. 19

20. University of Southern California Center for Systems and Software Engineering Major milestones in 577b 20

21. University of Southern California Center for Systems and Software Engineering Major Activities in RDCR, Development Phase-Construction Iteration

22. University of Southern California Center for Systems and Software Engineering Major Activities in Development Phase-Transition Iteration

23. University of Southern California Center for Systems and Software Engineering 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 23

24. University of Southern California Center for Systems and Software Engineering Iteration Plan 1.1Capabilities to be implemented –Usually specified by listing requirements from SSRD 1.2Capabilities 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. 2Plan (for the iteration) –Usual planning information: Tool Support, Schedule, Resources, Responsibilities Iteration plan is input to the next iteration plan. 24

25. University of Southern California Center for Systems and Software Engineering 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) 25

26. University of Southern California Center for Systems and Software Engineering Test IdentifierTC-01 Completion 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 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

27. University of Southern California Center for Systems and Software Engineering Test Case numberTC-01-01 Test ItemTC-01 Test PriorityM (Must have) Pre-conditionsHW/SW ready, Internet and GPRS signal availability Post-conditionsSystem operational state, no error condition not handled by the system Input SpecificationsUser 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 CriteriaValidate 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. DependenciesGPRS 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. TraceabilityOC1, CR2 An Example of a Test Case

28. University of Southern California Center for Systems and Software Engineering 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 28

29. University of Southern California Center for Systems and Software Engineering 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 29