1. Core Capability Drive-Through Workshop
A Winsor Brown
CSCI 577b Spring 2010
[Base content by Ed Colbert and Pongtip Aroonvatanaporn]
02/24/2010
©USC-CSSE

2. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

3. ICM Process Timeline
02/24/2010
©USC-CSSE

4. CCD Purpose Improve likelihood of successful transition
Improve operational stakeholder communication & motivation
Sense of what they’ll be getting
Hands-on usage opportunity
Product will soon be theirs to manage
Determine whether developers are on right track
Use real operational scenarios (preferred)
02/24/2010
©USC-CSSE

5. CCD Purpose (cont.) Determin whether project is on track:
Ability to meet construction "cost" and schedule
Truly have "Core Capabilities" (re-prioritization needed?)
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?
Anyone else who should experience CCD?
02/24/2010
©USC-CSSE

6. Collaboration Problem
02/24/2010
©USC-CSSE

7. Solution: CCD
02/24/2010
©USC-CSSE

8. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

9. Developer Preparation
Determine date between March 22-26
Schedule drive–through time with client
60-90 minutes generally OK
Place: SAL [lab, TA office, 322]
Discuss with client
Agenda
Core Capabilities
Scenarios (acceptance test sub-set)
Drive–through users
Coordinate with 577b staff
schedule 3 days (at least) prior to CCD
Specify hardware/software required (if needed)
02/24/2010
©USC-CSSE

10. Developer Preparation
Acceptance Test Subsets
Prepare draft User’s Manual
Bring hard copies for clients & others
Minimally: describe how to use core capabilities
Outline form
1 high-level per capability
Sublevels describe steps to perform capability
Index cards
1-2 cards per capability
Steps to perform capability on cards
02/24/2010
©USC-CSSE

11. Developer Preparation
Prepare & dry run context presentation
Bring hard copies for clients & others
Concern Logs
Can be in any form
577 template OR
Your own
Included in the report
02/24/2010
©USC-CSSE

12. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

13. Client Preparation Communicate with client
Not just limited to client(s), but user(s) as well
Plan “user” test scenario(s) of core capabilities
High-level description of typical usage
Should exercise capabilities in way user would
May want to discuss with
Intended users
Acceptance Test developers
Data, usage scenarios, users, etc.
02/24/2010
©USC-CSSE

14. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

15. CCD Presentation: Baseline Agenda
Summary of Core Capability content
Prioritized capabilities
Review example Core Capability usage scenario
Hands-on client usage
Most of time should be spent here
Discussion of IOC priorities
Tailor agenda to your project
02/24/2010
©USC-CSSE

16. Client’s “Hands-on” Usage
Imagine the reality once software is delivered
Let the clients play with the system
Use of user’s guide/manual
DO NOT tell the clients what to do
Observe and listen
Usability
Reactions
Etc.
02/24/2010
©USC-CSSE

17. CCD Products Concern logs (include things customer liked)
Core capabilities
User’s Manual
Tutorial
Test Cases
As appropriate
Re–prioritized list of remaining features
List of changes
Operational procedures
System data or environment developers
02/24/2010
©USC-CSSE

18. CCD Report Gather and submit
As-Is user’s manual
Concern Logs
Record of demonstration as performed
Summarize Core Capabilities driven–through
Include suggestions and positive feedbacks
Be specific
Break down by capability
New risks, if any, and mitigation plans
Things that are Core Capabilities, but were NOT exercised: Mitigation = repeat CCD?
Core capabilities not ready: Mitigation = do afterwards, coordinated with Client
Changes in understanding
Reprioritized capabilities, if any
COCOMO Estimation + Code Count reports
Due 7 days after YOUR CCD, no later than April 05, 2010
02/24/2010
©USC-CSSE

19. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

20. Motivation Effort for remaining work More data for analysis
Past estimation
Overestimate?
Underestimate?
Analyze past estimations
02/24/2010
©USC-CSSE

21. Performing Estimation
Perform code count
Manual or Tool
Actual vs. estimated SLOC
Compare to initial estimation
Built + Remaining modules
Past estimations
Rationale on why over/under estimated
Compare to effort report
02/24/2010
©USC-CSSE

22. Estimation Report Initial estimation New estimation
Comparison between estimations
Effort
Drivers
Etc.
Rationale
Code count report
02/24/2010
©USC-CSSE

23. Outline Why a CCD? Developer Preparation Client Preparation
CCD Agenda, Products, & Report
COCOMO Estimation at CCD
Conclusion
02/24/2010
©USC-CSSE

24. CCD Summary CCD is an opportunity to Set customer expectations
Get positive feedbacks and suggestions
Validate core capabilities
Validate development directions and understandings
Ease transition
Identify new risks and mitigations
02/24/2010
©USC-CSSE

25. What Is Still To Do? Team Devel. Prep. Client Prep. 2 4 7 9 11
02/24/2010
©USC-CSSE

26. Questions?