Spring 2004 EOSP

1
Spring 2004EOSP

• 2004. 5. 7
• Team GEO

2
Agenda

• Introduction
• Project Plan
• Processes
• Architecture
• Size Estimation
• Risk Management
• Test Plan
• Next Plan
• Lessons Learned
• QA

3
Team Introduction

• Members Roles
• Mentors
• Gil Taran
• Carol L. Hoover
• HoJin Choi

JunSuk Oh YounBok Lee
KwangChun Lee SoYoung Kim JungHee
Jo (Lead) (Planning)
(Support/Risk) (Development)
(Process)
4
Project Overview

• Project Name
• PMCenter (Project Management Center)
• Customer
• Korea Telecom
• Objective
• To make web-based software project management
  system customizable at any time
• Scope
• Support for overall project life cycle from
  project initiation to closing

5
Project Plan

• We are in the RUP Elaboration Phase

Project Management
SPMP Revision
Estimation
Risk Management
Requirements
Use Case Model
SRS Revision
Analysis Design
Define Architecture
Establish Architecture
1st Use Case Realization
2nd Use Case Realization
1st Design Components
2nd Design Components
Test
VV Plan
6
Processes

• Last Semester vs. This Semester

7
Key Processes

• Requirement Change Process
• Why define?
• GEO wants to remove data mining functionality
• It is hard to implement within August, 2004
• There is no expert about data mining among team
  members
• Client doesnt regard it as an important
  functionality
• Purpose of this process
• Ensure changes are documented, reviewed, and
  mutually accepted by the GEO team and the client,
  KT.
• Develop a requirement change plan and a checklist
  for review
• Minimize the impact of the requirement change

8
Key Processes

• Timely Decision Making Process V1.0
• Why define?
• Communication confliction problem occurred in
  every team meeting
• 4 members1 member / 3 members 2 members
• Meeting time always exceeds the planed time
  without decision making
• No one has authority to determine the decision
• Purpose of this process
• Adapt majority rule
• Resolve team confliction
• Remove the discordant factors among team members
• Assign authority to team leader

9
Key Processes

• Timely Decision Making Process V1.1
• Why define?
• Many times decision is made by 4 members
• 4 members 1 member
• One member suggest to insert monitoring step to
  track determined decision succeed or not
• Revise the existing timely decision making
  process
• Purpose of this process
• Monitoring the team decision
• Compensate the evil of majority rule
• Continuous improving of team decision

10
Key Processes

• Process Improvement Process
• Why define?
• While operating processes, some modification is
  needed
• Team members talk to process manager on the way
• Easy to forget the small change ideas
• Hard to control the change of process
• Formal process change is necessary
• Purpose of this process
• To find out process problems and improvement
  ideas
• To adapt process improvement idea formally
• To keep the history the process changing

11
Business Driver
Architecture

• Web-based system
• The overall structure of system could be
  three-tier architecture.
• Specific support for the organization
• The system architecture should reflect the unique
  business logic in the clients organization
• Multi language support
• Our system should provide its services in
  multiple languages (e.g. Korean and English).
• Development environment
• Our system should be developed using Java
  technology.

12
System Context
Architecture
PMCenter
Project management
Configuration management
Configuration Management System
Project Manager
Project execution
Project Member
Data Mining System
Project data
System administration
Administrator
External System
System Boundary
X interacts with Y
X
Y
Actor
13
Utility Tree
Architecture
When project managers manipulate WBS information,
the activities should be supported on GUI so that
they can easily do their jobs.
(H,H)
Efficient use
Usability
(H,H)
The system preserves the ongoing transaction and
data consistency if a server fails.
Robustness
Availability
(H,M)
While 300 users login to the system, up to 10
concurrent users can close tasks within 5 seconds
at the same time
Concurrency
Performance
(H,M)
When a user sends a retrieve request to the
system, the system can respond in less than 3
seconds while the system is under peak load .
Processing Time
(H,M)
Language conversion in user interface from Korean
to English should be possible in less than 1 week
with 1 person without changing other source code.
Modifiability
Cost of change
(H,M)
A member of team is allowed to see the
information of project she/he is working on and
the tasks assigned to her/him but no other
projects
Confidentiality
Security
14
ATAM Preparation
Architecture

• Key preparation
• Business presentation
• Business driver
• Utility tree quality attribute scenario
• Architecture presentation
• Context view, run-time view, code view, and
  physical view
• Candidate architectures
• ATAM meeting (April 14th)
• 8 persons attended (led by Tony Lattanze)
• 3.5 hours long

15
ATAM What we obtained
Architecture

• Applied Scenario
• While 300 users login to the system, up to 10
  concurrent users can close tasks within 5 seconds
  at the same time
• ATAM results
• Refined and prioritized quality attributes
  scenarios
• Identified potential risks implying candidate
  architecture
• Not determined technical framework yet
• Make it difficult to analyze performance between
  alternatives
• Database and amount of data to be stored should
  be determined
• Make it difficult to analyze performance between
  alternatives
• Next step
• Need to determine technical framework
• Need to make the ambiguities in architecture
  clear
• Apply ATAM to important scenarios on our team own

16
ATAM Afterward
Architecture

• Performed technical research
• EJB vs. Plain Java Class
• Java Application vs. Java Applet

17
Overall Architecture Before ATAM
Architecture
18
Overall Architecture - CC View
Architecture
Client Tier
Middle Tier
Data Tier
Presentation
Business Logic
HTML page
Applet


Tier
Layer
UI Type
19
Alternative Architecture 2 - Multi Language
Support
Architecture

• Scenario
• Language conversion in user interface from Korean
  to English should be possible in less than 1 week
  with 1 person without changing other source code.
• Risks
• The challenge of unfamiliar technology - XML
• Sensitivity points
• Modifiability is increased because UI and source
  code can be separately maintained
• Tradeoffs

20
Alternative Architecture 1 - WBS manipulation
Architecture
No restriction to implement () vs.
Maintainability and Usability(-)
Client Tier
Middle Tier
Data Tier
Presentation
Business Logic


Tier
Layer
21
Alternative Architecture 1 - WBS manipulation
Architecture

• Scenario
• When project managers manipulate WBS information,
  the activities should be supported on GUI so that
  they can easily do their jobs.
• Risks
• Lack of skill of handling java GUI
• Sensitivity points
• Having two kinds of user interfaces to support
  WBS graphics
• Tradeoffs

22
Alternative Architecture 2 - Multi Language
Support
Architecture
Easy to implement() vs Extensibility and
Modifiability(-)
Client Tier
Middle Tier
Data Tier
Presentation
Business Logic


Tier
Layer
23
Overall Architecture Final Decision
Architecture
Client Tier
Middle Tier
Data Tier
Presentation
Business Logic
HTML page
Applet


Tier
Layer
UI Type
24
Overall Architecture Module View
Architecture
25
Overall Architecture Physical View
Architecture
26
ATAM What we learned
Architecture

• Candidate architecture elicitation
• Need to clarify the technical knowledge of
  candidate architectures
• The effect of technical decision to architecture
• Scenario specification
• Be specific as possible
• Observe 6 part scenario specification
• Scenario prioritization
• Less meaningful to prioritize quality attributes
  themselves
• Should prioritize quality attribute scenarios
• Mini ATAM scheduling
• Need to prepare more for proper evaluation within
  limited time

27
Size Estimation
Estimation

• Use two methods (MOSP)
• Function Points and Use Case Points
• ICU MSE Size Estimation D/B (EOSP)
• Motivation
• Difficulties from lack of historical data
• Define Data Collection Process
• Based on the USC COCOMO Data Collection Program
• Tailored to be fitted in MSE Program
• Size Estimation Method Library
• Empirical Size Estimation Methods (e.g. WAG,
  Delphi)
• Parametric Estimation Methods (e.g. Parametric
  Regression)
• Theory-based Estimation Methods (e.g. SLIM
  Norden-Rayleigh)
• Estimation Process and Database
• Re-Estimation (Next Semester)
• SRS 2.3 released at 1st May

28
ICU Size Estimation D/B Process
Estimation
29
Data Sources
Estimation

• Studio Information
• Studio team name
• Number of team members
• Studio team ethnics( American/Asian/Indian/Europea
  n/Spanish)
• Total software experiences
• Description of Projects
• Development Information
• Development Type New/Upgrade/Maintenance
• Development Process Waterfall/RUP/XP/Spiral
• Development Language Java/.NET/C
• Client Information
• Application Area Command and Control /MIS
  /Simulation /Communication
• Client CMM Level Level-1/Level-2/Level-3/Level-4/
  Level-5
• Project Information
• Fall Semester
• Total Lines of Code (Estimated)
• Total Number of Objects if Object-oriented
  (Estimated)
• Spring Semester
• Total Lines of Code (Estimated)

30
Estimation Method Library
Estimation

• Empirical Size Estimation
• Wild Altogether Guess (WAG)
• Function Points
• Parametric Size Estimation
• Ordinary Linear Regression
• Non-linear Regression
• Robust Regression
• Generalized Linear Regression
• Theory-based Estimation
• SLIM Rayleigh Distribution
• Learning-Oriented Estimation
• Neural Network
• Decision Tree Regression Tree
• Composite Estimation
• A Bayesian approach COCOMO II Calibration
• NOTE Black (Spring 2004), Red (Summer 2004)

31
Risk Management Framework
Risk
32
Risk Management Framework
Risk

• Operational Risk
• The risk of losses resulting from inadequate or
  failed internal processes, people and systems or
  from external events
• Product Risk (TBQ)
• Product engineering
• Development environment
• Program Constraints
• Studio Risk Management
• Program specific risk
• One year schedule
• Balance between core courses and studio

33
Risk Management vs. Problem Solving
Risk
CRM
Problem Solving

• Collect, analyze confirm Information
• Identify the root problem
• Determine if the problem should be solved
• Formulate the problem statement
• Generate possible solutions
• Select the best solution
• Devise a plan
• Carry out the plan
• Evaluate

Ray Williams 2004. Continuous Risks Management
Studio Presentation Master of Software
Engineering CMU
Fogler, H. S. LeBlanc, S. E. 1995. Strategies
for Creative Problem Solving. Prentice-Hall
34
Risk Categorization
Risk
Risk Category (D) ? Risk Category (C)
35
Top 7 Risk Items
Risk

• Lack of team morale due to interpersonal team
  problems may cause work to be less efficient and
  create extra work for team.
• Individual team members do not have enough
  self-control to spend adequate time on studio
  may cause the schedule slip and compromise the
  product quality.
• Poor communication between team members may lead
  to inefficiency, misunderstandings and rework.
• Team members have little experience with required
  domain knowledge (technology, process, teamwork
  skill) may cause the schedule slip.
• Not enough analysis of requirement might lead to
  incorrect design.
• Heavy load of other courses might not allow us
  to spend enough time to studio project
• Mismanaged task assignment might lead to
  unbalanced work load among members.

Team
Product
36
Test Strategy
Test Plan

• Role Responsibility
• Quality Assurance Manager
• Keeping track of the proper schedule for the
  review process
• Ensuring the appropriate planning and management
  of the review resources
• Test Manager
• Negotiating the ongoing purpose and deliverables
  of the test effort
• Ensuring the appropriate planning and management
  of the test resources
• Assessing the progress and effectiveness of the
  test effort

37
Test Strategy
Test Plan

• Tools Techniques
• Tools
• Word processing (Microsoft Word)
• Electronic mail system and messenger
• Review reports
• Checklists
• JUnit
• Techniques
• Review
• Inspection
• White box testing
• Black box testing
• Automated testing

38
Quality Attributes Test
Test Plan

• Usability focuses on
• Human factors
• Aesthetics
• Consistency in the UI
• Reliability focuses on
• Extreme workloads
• Unavailable services
• Malicious user input
• Limited shared resources
• Performance focuses on
• Benchmark test
• Load test
• Contention test

39
Test Metrics
Test Plan
40
Accomplishments

• What we did (versus Original Plan)
• Project Management
• SPMP (v 2.2)
• Size Estimation (v 1.0)
• Software Risk Evaluation Mitigation Plan
• Process Handbook (v 2.0)
• Requirements
• SRS (v 2.3)
• Use Case Model (v 1.2)
• Analysis and Design
• Architecture (v 1.0)
• Test
• Verification and Validation Plan (v 1.1)
• What we postponed (versus Original Plan)
• Analysis and Design
• Use Case Realization
• Detail Design (partly done)

41
Effort Measurement

• Time spent this semester

42
Next Plan

• Elaboration Phase (Continued) Early June
• Use Case Realization
• Detail Design
• Construction Phase Mid July
• Coding Test
• Transition Phase Early August
• System Integration Test
• System Install
• User Training

43
Lessons Learned

• Techniques
• ATAM
• Software Risk Evaluation
• For better teamwork
• Without respect, the team never maintains
  harmonious relations
• Try to make a good meeting mode even if personal
  feeling is not good

44
Q A
45
Appendix - Initial Component Design

• Static modeling
• Identify interface and component candidates