cs577a software engineering i dcr arb and package workshop
DESCRIPTION
CS577a Software Engineering I DCR ARB and Package Workshop. Supannika Koolmanojwong. 1. USC CS577 ARB Participants. • Project Team Everybody presents something • Reviewers Clients Instructors Industry participants. 3. ARB Session Outline. DCR similar format to FCR, different focus: - PowerPoint PPT PresentationTRANSCRIPT
University of Southern California
Center for Systems and Software Engineering
1
CS577a Software Engineering IDCR ARB and Package Workshop
Supannika Koolmanojwong
University of Southern California
Center for Systems and Software Engineering
MondayDec 2
TuesdayDec 3
WednesdayDec 4
ThursdayDec 5
FridayDec 6
8:40 – 10:00 T10 – Student Scheduling
T04 – LiveRiot
10:00 – 11:20 T02 – City of LA Personnel
T06 - Yanomamo
T09 – City of LA Public Safety
T11 – Surgery Assist
11:30 – 12:50 T01 – LA Commons
T16 - MedFRS T13 – Spherical Model
14:00 – 15:20 T14 - HKZ T12 – Online Wedding
T08 – Lose4Good
T05 - eLockbox
15:30 – 16:50 T03 – Mission Science
T07 - ThrdPlace
T15 - JEP
University of Southern California
Center for Systems and Software Engineering
3
USC CS577 ARB Participants
•Project TeamEverybody presents something
•ReviewersClientsInstructors Industry participants
University of Southern California
Center for Systems and Software Engineering
4
ARB Session Outline• DCR similar format to FCR, different focus:
Less time for OCD, PrototypeMore 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)
University of Southern California
Center for Systems and Software Engineering
4
ARB Review Success Criteria
FCR DCRFor 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 caseKey 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 PlanAll major risks resolved or
covered by risk management plan
Key stakeholders committed to support full life cycle
University of Southern California
Center for Systems and Software Engineering
Commitment Review Success CriteriaTRR / 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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
ARB Chartsmanship & Presentation
9
• 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
University of Southern California
Center for Systems and Software Engineering
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 & 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
(10,10) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong)
(5, 5) 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 or ? as appropriate; Include plans for Construction-Transition-Support initial cycle “Plans” during 2nd Foundations IterationTeam members’ roles & responsibilities in 577b, Iteration Plan
(5, 10) Feasibility Evidence. Refined business case; major risks; general discussion(5,5) Quality Focal Point – Metrics reporting, (Solved & Remaining)Technical Debt,
Traceability Matrix(10) Feedback from Instructors• Focus on changes (particularly new things) since FCR• You may vary from the above: please notify ARB board members IN ADVANCE
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, 5) Test Results. Test cases and results (if any)(5, 5) Transition Plan and Support Plan. HW/SW/Site preparation, support environment,
release strategy(5,5) Quality Focal Point – Metrics reporting, (Solved & Remaining)Technical Debt,
Traceability Matrix(10)Things done right; issues to address (Instructional staff)
• Focus on changes (particularly new things) since FCR• You may vary from the above: please notify ARB board members IN ADVANCE
University of Southern California
Center for Systems and Software Engineering
TRR Agenda10 min. Introduction
– Operational concept overview, TRR specific outline, transition objective & strategy
20 min. Demo of Initial Operational Capability (Product status demonstration)
5 min. Support Plan 5 min. Test Cases, Procedures and Results 5 min Quality Focal Point – Metrics reporting, (Solved &
Remaining)Technical Debt, Traceability Matrix25 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 ***
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
University of Southern California
Center for Systems and Software Engineering
Details for two Semester Projects• Dates & Activities for client• Planning expectations• Construction Working Set
University of Southern California
Center for Systems and Software Engineering
Project Schedule –Spring 2014Jan. - Feb. : Work with teams:
Rebaseline prototype, prioritize requirementsPlan for CS 577b specifics, including transition strategy, key risk itemsParticipate in RDCR ARB review
Feb 10 – Rebaselined DCR ARBFeb – May : Scheduled Weekly Meetings with Teams to:
Discuss status and plansProvide access to key transition people for strategy and readiness discussions March 26: Core Capability DrivethroughApr 14 - 18: Project Transition Readiness ARB ReviewsApr 21: Installation and TransitionInstall ProductExecute Transition Plan Apr 28: Operational Commitment Review for Initial Operational CapabilityMay 5: Client Evaluations
15
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 toWrite plansExecute plan activitiesPrepare for RDCR and TRR reviews, Core Capability DrivethruAnticipate and account for risksAllocate extra time for risky itemsExplicitly schedule critical contingency plansBe consistent with the class schedule
16
University of Southern California
Center for Systems and Software Engineering
Overall Summary: Example
17
Valuation Foundations DevelopmentConstruction Transition
Users Users 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
Clients Clients, 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.
University of Southern California
Center for Systems and Software Engineering
By Phase / StageFor 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
University of Southern California
Center for Systems and Software Engineering
Major milestones in 577b
19
University of Southern California
Center for Systems and Software Engineering
Major Activities in RDCR, Development Phase-Construction Iteration
University of Southern California
Center for Systems and Software Engineering
Major Activities in Development Phase-Transition Iteration
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 CasesAcceptance Test Procedures and ResultsRelease DescriptionIteration Assessment ReportIteration implementation (under CM)
Source code, compile-time files, executables, test drivers
As-built OCD, SSAD, FED, LCP
22
University of Southern California
Center for Systems and Software Engineering
Iteration Plan1.1 Capabilities to be implemented
Usually specified by listing requirements from SSRD1.2 Capabilities to be tested
“Verification” is via technique appropriate to the requirementUsually testing, but can be peer review, client agreement, …Consult the “measurable” attribute of the requirement
1.3 Capabilities not to be testedIdentify features which will not be tested this iteration and why.
2 Plan (for the iteration)Usual planning information: Tool Support, Schedule, Resources,
ResponsibilitiesIteration plan is input to the next iteration plan.
23
University of Southern California
Center for Systems and Software Engineering
Test Plan and CasesAcceptance Test Plan and CasesCovers specifying testing resources and planning
for their useHow many tests will be runHow long will each takeWhat kind(s) of platform(s) are needed to run testsTesting schedule
Specifies detailed test cases: specific inputs expected specific outputs (or how/where to observe)
24
University of Southern California
Center for Systems and Software Engineering
Test Identifier TC-01Completion 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 CaseTC-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 LevelThis test will be performed at the system software item level.Test ClassThis test will include both user functions and erroneous input tests.Test Completion Criteria
University of Southern California
Center for Systems and Software Engineering
Test Case number TC-01-01Test Item TC-01Test Priority M (Must have)Pre-conditions HW/SW ready, Internet and GPRS signal availabilityPost-conditions System operational state, no error condition not handled by the systemInput Specifications User 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 Criteria Validate 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.
Dependencies GPRS 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.
Traceability OC1, CR2
An Example of a Test Case
University of Southern California
Center for Systems and Software Engineering
Iteration Assessment ReportEach iteration is concluded by an iteration assessment
OverviewCapabilities implementedSummary of test results
Adherence to PlanExternal Changes OccurredSuggested Actions
27
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 releaseUpcoming Changes that will be incorporated in future releasesKnown Bugs and Limitations
28