P O I N T

1
P O I N T
August 6, 2004 The End Of Semester
Presentation
2
AGENDA

• 1. Project Information
• Project Status
• Project Success Criteria
• What we tried what we learned
• Requirement Analysis
• Estimation
• Processes
• Architecture
• Design
• QA, CM, RM
• Test
• What we are proud of
• What would we do differently
• Demo
• Q A

3
Stakeholders
1. Project Information

• Customer
• Samsung SDS
• Team Members
• Mentors

HRYoun Design Mgr Team Builder Mgr
HJJoo Team Lead Customer Mgr
SHChoi Test Mgr Implement Mgr
JPKim Plan Mgr Quality Mgr
HCKim Support Mgr Process Mgr
DanHyung Lee ChoonBong Lim
Mel Rosso-Llopart
4
Project Information
1. Project Information
TSP Support Tool
Minimize Effort Maximize Data

• Team Software Process
• Set up Metric Based Process
• Improve Quality

5
Project Information(Cont.)
1. Project Information
SEPG 2003 Applying TSP to CBD Projects
6
Project Status
2. Project Status
Fall
Spring
Summer
960 hr
960 hr
960 hr
960 hr
960 hr
Requirement
Design
Test
Implement
Deploy
Implement
Implement
Aug 11
User Manual Install Delivery Acceptance
Test EOSP Korean Version
SOW SRS SPMP Architecture Test Plan
HLD DLD Source Code MOSP Unit Test Integration
Test System Test
SOW SRS SPMP
Aug 13
Aug 11
Aug 12
3 Times
2 Times July 10/ Aug 7
Legend
Semester
Hours
Plan
7
Project Success Criteria
3. Project Success Criteria
8
Requirement Analysis
4. What we tried learned

• Requirement Elicitation
• Reverse Engineering
• Analysis Excel based TSP system
• Regular TSP Seminars
• Every two weeks during fall spring semester
• Regular customer meeting
• Requirement Analysis
• Use case description
• Use case / Class / Sequence diagram
• Requirement list
• What we learned
• Maximize reverse engineering as requirement
  elicitation resource.
• At the same time, try to get vivid requirements
  from customer.
• Subscribe business logics in detail in written
  documents

9
Plan Estimation
4. What we tried learned

• LOC Estimation (Using FP COCOMOII) Except
  comments
• Time Estimation
• Full scope 5798 hrs (Point Resource 4800 hrs)
• Appropriate scope 82
• 2003 Fall 409(Actual) / 456(Plan) 0.89 (ADV)
• 2004 Spring 162(Actual) / 185(Plan) 0.87
  (ADV)
• Continuous revise Adjust Value
• We froze 9 use cases out of 16 (80 of Entire
  Scope)
• 2004 Summer 9 use cases are almost implemented.
• What we learned
• Correct adjust value continuous to use FP value
  in remain part of the project

ACUTAL EOSP 14904(80) 17884(100)
TIME RESULT
FP 2003 Fall 342
COCOMOII 2003 Fall 10912
JSP Java 2003 Fall 17050
PROTOTYPE 2004 Spring 16630
 
 
10
Processes(Team Software Process)
4. What we tried learned

• TSP Benefit
• Build Jelled Team by sharing teams goals
• Little time for making process.
• With relatively low cost, TSP let us make exact
  plan and know our project exact status
• Cost 310 hours (6 ) for TSP Launch and Data
  collection
• Role is well defined
• Experience of Process Improvement
• Launch time reduced from 100 hours ? 30 hours
• What we learned
• Appropriate launch interval is two month
• TSP does not give critical path
• PSP is absolutely required to apply TSP
• Putting buffer time is important to handle
  unexpected tasks
• Sometimes earned values does not tell exact
  status
• TSP team member should concern other teams
  performance

11
ARCHITECTURE
4. What we tried learned
12
Design
4. What we tried learned

• Design History
• 
  

• What we learned
• Verify Design by prototype
  
  implementation
• Follow one expert

Select UML
HLD
DLD
Validation problem
Architecture Modification
Expert As advice
Revise DLD
Revise HLD
Expert Bs advice
Revise HLD
13
Quality Assurance Activities
4. What we tried learned

• Review Activity
• Personal Review all artifacts before Inspection
• Inspection Requirement Specification, HLD, and
  DLD document
• Requirement Specification 68 (Major4, Minor 64)
• HLD 23 (Major 12, Minor 11)
• DLD 19 (Major11, Minor8)
• We save 27 5 hours 135 hours (1 week)
• Pair programming for partial source code
• Quality Assurance Audit Activities are planned
  and conducted
• TSP Data checking every week
• Review Teams quality performance every week
• What we learned
• Quality Manager should have less programming job
  than other team member
• We need process for watching watchdog
• Motivation for quality work is important for
  quality of product

14
Risk Management
4. What we tried learned

• Risk Elicitation
• Fall 18 risks / 9 risks mitigated
• Spring 23 risks / 8 risks mitigated
• Summer 14 risks / 9 risks mitigated
• Concentrate on high priority risks
• Check 35 high risks every status meeting
• Assign charger and establish mitigation plan
• Adopt new risks or drop mitigated risks every
  week
• Run parallel with issue management
• What we learned
• (ex) Delay schedule gt Continuous Tracking
• Reduce the EV gap gradually
• It is better to manage just critical risks
  issues

15
Configuration Management
4. What we tried learned

• What we did for CM
• We used Microsoft Visual Source Safe by comparing
  among several
• We made CM Process
• Configuration Items
• Baseline
• CM Procedure
• We have an experience
• that all artifacts were lost by accident and were
  recovered from VSS.
• that different versions of a source code were
  going around at the same time.
• What we learned
• By using VSS, we could
• Trace every changed contents
• Protect artifacts from disasters
• Reduce developing time when IDE support combining
  development tools and CM tools
• But, need to know how to use the tool exactly

16
Test Plan Result
4. What we tried learned
Aug
May
June
July
Iteration I
Iteration II
Deploy
Re-plan Test (5.31)
System Test (6.07 6.29)
System Test (7.26 7.30)
Integration Test II (7.12 7.14)
Acceptance Test (8.02 8.04)
Integration Test I (6.01 6.03)
Integration Test III (7.19 7.21)
Iteration I
Iteration II
Deploy
Integration Test I (7.07 7.08)
Re-plan Test (6.08)
Integration Test II (7.28 7.30)
Acceptance Test (8.09 8.11)
Integration Test III (8.03 8.04)
System Test (7.08 7.10)
Plan
System Test (8.02 8.07)
Actual
17
Test Plan Result
4. What we tried learned

• eValid (http//www.soft.com/eValid/index.html)
• We need
• lots of repeated same test
• logs what we tested
• reports from the result
• performance analysis
• With eValid we can
• do the same test again automatically
• reduce test time and focus on developing

18
Test Plan Result
4. What we tried learned
19
Pride
5. What we are proud of

• Excellent Teamwork
• Air to love to work with, Good Productivity,
  Effective Meeting Time
• Clear Role Definition Trust
• TSP
• Test Automation using eValid
• Various tries and study
  for better system
  architecture
• Struts, Model 1 2, MVC
• Configuration Management

2004 Summer Semester "Building a jelled team"
tracking result
20
What would we do differently
6. What would we do differently

• Spend more time and effort to Requirement
  Analysis
• Finish UI in the first semester
• Have more time to talk with clients (a meeting
  /week is too insufficient)
• Use a phone-calls rather than e-mails
• Figure out Stakeholders
• Bi-lingual support
• Freeze the scope of the project as soon as
  possible
• Keep in mind getting feedback from clients takes
  time
• For prototyping, select riskiest and the most
  significant use cases rather than easy ones to do
• Assign Nagger for reminding timing
• Not just plan, keep it
• Offer Motivation to follow processes
• Not just good processes, follow it

21
Demo
22
Questions Comments