Spring 2004 EOSP
-
Upload
abdul-haney -
Category
Documents
-
view
43 -
download
2
description
Transcript of Spring 2004 EOSP
1
Spring 2004Spring 2004
EOSPEOSP2004. 5. 72004. 5. 7
Team GEOTeam GEO
2
AgendaAgenda
IntroductionProject PlanProcessesArchitectureSize EstimationRisk ManagementTest PlanNext PlanLessons LearnedQ&A
3
Team IntroductionTeam Introduction
Members & Roles
MentorsGil TaranCarol L. HooverHoJin Choi
JunSuk Oh YounBok Lee KwangChun Lee SoYoung Kim JungHee Jo (Lead) (Planning) (Support/Risk) (Development) (Process)
4
Project OverviewProject 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 PlanProject Plan
We are in the RUP Elaboration Phase
1st Iteration 2nd Iteration
Jan. Feb. Mar. Apr.
RequirementsRequirements
Analysis&
Design
Analysis&
Design
TestTest
ProjectManagement
ProjectManagement
SPMP Revision
Estimation
Risk Management
Use Case Model
SRS Revision
Define Architecture Establish Architecture
1st Use Case Realization2nd Use Case Realization
V&V Plan
1st Design Components2nd Design Components
6
ProcessesProcesses
Last Semester vs. This Semester
Last Semester(Existed Process)
This Semester(Added Process)
• Meeting Process• Configuration Management Process• Risk Management Process
• Requirement Change Process• Revised Risk Management Process• Timely Decision Making Process• Review Process
• Process Improvement Process
7
Key ProcessesKey Processes
Requirement Change ProcessWhy 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 doesn’t regard it as an important functionality
Purpose of this processEnsure changes are documented, reviewed, and mutually accepted by the GEO team and the client, KT.Develop a requirement change plan and a checklist for reviewMinimize the impact of the requirement change
8
Key ProcessesKey Processes
Timely Decision Making Process V1.0Why define?
Communication confliction problem occurred in every team meeting
– 4 members:1 member / 3 members :2 members
Meeting time always exceeds the planed time without decision makingNo one has authority to determine the decision
Purpose of this processAdapt majority ruleResolve team conflictionRemove the discordant factors among team membersAssign authority to team leader
9
Key ProcessesKey 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 notRevise the existing timely decision making process
Purpose of this processMonitoring the team decisionCompensate the evil of majority ruleContinuous improving of team decision
10
Key ProcessesKey Processes
Process Improvement ProcessWhy 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 processTo find out process problems and improvement ideasTo adapt process improvement idea formallyTo keep the history the process changing
11
Business Driver Business Driver
Web-based systemThe overall structure of system could be three-tier architecture.
Specific support for the organizationThe system architecture should reflect the unique business logic in the client’s organization
Multi language supportOur system should provide its services in multiple languages (e.g. Korean and English).
Development environmentOur system should be developed using Java technology.
ArchitectuArchitecturere
12
System ContextSystem Context
PMCenter
ConfigurationManagement
System
Data MiningSystem
Projectmanagement
Projectexecution
Configurationmanagement
Project data
Systemadministration
External System
SystemBoundary
X interacts with YX Y
Project Manager
Project Member
Administrator
Actor
ArchitectuArchitecturere
13
Efficient use (H,H) When project managers manipulate WBS
information, the activities should be supported on GUI so that they can easily do their jobs.
Modifiability
Confidentiality
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
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.
Cost of change
Utility TreeUtility Tree
Usability
Robustness (H,H) The system preserves the ongoing transaction and
data consistency if a server fails. Availability
Concurrency (H,M) While 300 users login to the system, up to 10
concurrent users can close tasks within 5 seconds at the same time
Performance Processing
Time
(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 .
(H,M)
Security(H,M)
ArchitectuArchitecturere
14
ATAM – PreparationATAM – Preparation
Key preparationBusiness presentation
Business driverUtility tree – quality attribute scenario
Architecture presentationContext view, run-time view, code view, and physical viewCandidate architectures
ATAM meeting (April 14th)8 persons attended (led by Tony Lattanze)3.5 hours long
ArchitectuArchitecturere
15
ATAM – What we obtained ATAM – What we obtained
Applied ScenarioWhile 300 users login to the system, up to 10 concurrent users can close tasks within 5 seconds at the same time
ATAM resultsRefined 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 stepNeed to determine technical frameworkNeed to make the ambiguities in architecture clear Apply ATAM to important scenarios on our team own
ArchitectuArchitecturere
16
ATAM – AfterwardATAM – Afterward
Benefit Loss
EJB Easy to handling concurrency
Availability
Hard to implementPerformance
Plain Java Class
Easy to implement, Performance
Hard to handle concurrency
Availability
Performed technical researchEJB vs. Plain Java Class
Java Application vs. Java Applet
Benefit Loss
Stand-alone Java Application
UsabilityPerformance
ModifiabilityHard to implement
Java Applet Easy to implementModifiability
PerformanceUsability
ArchitectuArchitecturere
17
Overall Architecture – Before Overall Architecture – Before ATAM ATAM
ArchitectuArchitecturere
DataBase Logic CommunicationServer
ClientApplication
Component Type
DataBase Logic CommunicationServer
ClientApplication
Client Side
WebBrowser
ClientApplication
Server Side
Data TierLogic Tier
WebServer
LanguageDB
App.Logic
ProjectDB
XMLP
rese
nta
tion
SocketServer
Data Access
Procedure Call
HTTP
Socket
Connector Type
Data Access
Procedure Call
HTTP
Socket
18
Overall Architecture - C&C View Overall Architecture - C&C View
Tier Layer UI Type
Client Tier Middle Tier
Presentation
Data Tier
Business Logic
HTMLpage
Applet
ArchitectuArchitecturere
19
Alternative Architecture 2 - Alternative Architecture 2 - Multi Language Multi Language SupportSupport
ScenarioLanguage conversion in user interface from Korean to English should be possible in less than 1 week with 1 person without changing other source code.
RisksThe challenge of unfamiliar technology - XML
Sensitivity pointsModifiability is increased because UI and source code can be separately maintained
Tradeoffs
Modifiability(+) Extensibility(+)Difficulty of
implementation(+)
Cost of change Support more language
Unfamiliar technology
ArchitectuArchitecturere
20
Alternative Architecture 1 -Alternative Architecture 1 - WBS WBS manipulationmanipulation
No restriction to implement (+) vs. Maintainability and Usability(-)
Client Tier Middle TierPresentation
Data Tier
Business Logic
Tier Layer
ArchitectuArchitecturere
21
Alternative Architecture 1 - Alternative Architecture 1 - WBS WBS manipulationmanipulation
ScenarioWhen project managers manipulate WBS information, the activities should be supported on GUI so that they can easily do their jobs.
RisksLack of skill of handling java GUI
Sensitivity pointsHaving two kinds of user interfaces to support WBS graphics
Tradeoffs Usability(+) Maintainability(+)
Difficulty of implementation(+)
Unified Client No need to install Restriction of applet
ArchitectuArchitecturere
22
Alternative Architecture 2 Alternative Architecture 2 - Multi Language - Multi Language SupportSupport
Easy to implement(+) vs Extensibility and Modifiability(-)Client Tier Middle Tier
Presentation
Data Tier
Business Logic
Tier Layer
ArchitectuArchitecturere
23
Overall Architecture – Overall Architecture – Final DecisionFinal Decision
Tier Layer UI Type
Client Tier Middle Tier
Presentation
Data Tier
Business Logic
HTMLpage
Applet
ArchitectuArchitecturere
24
Overall Architecture – Module ViewOverall Architecture – Module View
Application Layer
User Interface Layer
Access Control
Project Initiation
Project Execution System Admin
Project R
egistration
Project Planning
Project Control
Project Closing
My Page View
Project L
ist View
Team
Organization
WBS
Task M
anagement
Quality M
anagement
Issue M
anagement
Docu
ment M
anagement
Meeting M
anagement
Ann
ouncem
ent Managem
ent
Progress M
anagement
Gantt chart view
Issue M
etric
Project C
losing Registration
User M
anagement
Grou
p M
anagement
BBS M
anagement
Project G
roup R
egistration
Process T
emplate M
gt.
Data Layer
Main ViewLogin
Langu
age Manager
Data I/ O Manager
My P
age Manager
Module Layer A B A calls BLegend
Module Layer A B A calls BLegend
ArchitectuArchitecturere
25
Overall Architecture – Physical Overall Architecture – Physical View View
Internet Intranet
FirewallServer
PMCenterServer(with DBMS)
PMCenterClient
ClientComputer
IP Network FirewallServer
ServerComputer
IP NetworkConnector
Legend
PMCenterClient
InternetInternet IntranetIntranet
FirewallServer
PMCenterServer(with DBMS)
PMCenterClient
ClientComputer
IP Network FirewallServer
ServerComputer
IP NetworkConnector
Legend
PMCenterClient
ArchitectuArchitecturere
26
ATAM – What we learnedATAM – What we learned
Candidate architecture elicitationNeed to clarify the technical knowledge of candidate architecturesThe effect of technical decision to architecture
Scenario specificationBe specific as possibleObserve 6 part scenario specification
Scenario prioritizationLess meaningful to prioritize quality attributes themselvesShould prioritize quality attribute scenarios
Mini ATAM schedulingNeed to prepare more for proper evaluation within limited time
ArchitectuArchitecturere
27
Size EstimationSize 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 ProcessBased on the USC COCOMO Data Collection Program
Tailored to be fitted in MSE Program
Size Estimation Method LibraryEmpirical 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
EstimatioEstimationn
28
ICU Size Estimation D/B ProcessICU Size Estimation D/B ProcessEstimatioEstimationn
Project Registration
Estimation Strategy Setup
Report andUpdate D/B
ICU Size Estimation
D/B
Evaluate Performance
MethodsLibrary
History D/B Estimation
Estimate SizeEstimate Size
Goal Setting
29
Data SourcesData SourcesStudio Information
Studio team nameNumber of team membersStudio team ethnics( American/Asian/Indian/European/Spanish)Total software experiencesDescription of Projects
Development InformationDevelopment Type: New/Upgrade/MaintenanceDevelopment Process: Waterfall/RUP/XP/SpiralDevelopment Language: Java/.NET/C++
Client InformationApplication Area: Command and Control /MIS /Simulation /Communication …Client CMM Level: Level-1/Level-2/Level-3/Level-4/Level-5
Project InformationFall Semester
Total Lines of Code (Estimated)Total Number of Objects if Object-oriented (Estimated)
Spring SemesterTotal Lines of Code (Estimated)Total Number of Objects if Object-oriented (Estimated)
Summer SemesterTotal Lines of Code (Estimated)
Total Number of Objects if Object-oriented (Estimated)
Project EvaluationSuccess Rating for Project: Very Successful /Successful /Satisfactory /Unsatisfactory / Very UnsatisfactoryTotal Lines of Code (Actual)Total Number of Objects if Object-oriented (Actual)
EstimatioEstimationn
30
Estimation Method LibraryEstimation Method Library
Empirical Size EstimationWild Altogether Guess (WAG)Function Points
Parametric Size EstimationOrdinary Linear RegressionNon-linear RegressionRobust RegressionGeneralized Linear Regression
Theory-based EstimationSLIM: Rayleigh Distribution
Learning-Oriented EstimationNeural NetworkDecision Tree & Regression Tree
Composite EstimationA Bayesian approach: COCOMO II Calibration
NOTE: Black (Spring 2004)NOTE: Black (Spring 2004), , Red (Summer 2004)Red (Summer 2004)
EstimatioEstimationn
31
Risk Management FrameworkRisk Management Framework
RiskRisk
AccidentsAccidentsPolitical Political
RisksRisks……
Operational Operational RiskRisk
Studio Studio RiskRisk
Product Product RiskRisk
ProductEngineering
DevelopmentEnvironment
ProgramConstraints
RisRiskk
32
Risk Management FrameworkRisk Management Framework
Operational RiskThe risk of losses resulting from inadequate or failed internal processes, people and systems or from external events
Product Risk (TBQ)Product engineeringDevelopment environmentProgram Constraints
Studio Risk ManagementProgram specific risk
One year scheduleBalance between core courses and studio
RisRiskk
33
Risk Management vs. Problem Risk Management vs. Problem SolvingSolving
CRMCRM
Fogler, H. S. & LeBlanc, S. E. 1995. Strategies for Creative Problem Solving. Prentice-Hall
Problem SolvingProblem Solving
Ray Williams 2004. Continuous Risks Management Studio Presentation Master of Software Engineering CMU
• 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
ProblemSymptom
Activity FlowControl & FeedbackInformation
InterfaceSocial-TechnicalTechnical
FishboneFishbone
WHY?
WHY?
Why-Why DiagramWhy-Why Diagram
RisRiskk
34
Risk CategorizationRisk Categorization
Risk Category (D) Risk Category (D) Risk Category (C) Risk Category (C)
RisRiskk
35
Top 7 Risk ItemsTop 7 Risk Items
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 projectMismanaged task assignment; might lead to unbalanced work load among members.
TeamTeam
ProductProduct
RisRiskk
36
Test StrategyTest Strategy
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
Test Test PlanPlan
37
Test StrategyTest Strategy
Tools & TechniquesTools
Word processing (Microsoft Word)
Electronic mail system and messenger
Review reports
Checklists
JUnit
TechniquesReview
Inspection
White box testing
Black box testing
Automated testing
Test Test PlanPlan
38
Quality Attributes Test Quality Attributes Test
Usability focuses onHuman factorsAestheticsConsistency in the UI
Reliability focuses onExtreme workloadsUnavailable servicesMalicious user inputLimited shared resources
Performance focuses onBenchmark testLoad testContention test
Test Test PlanPlan
39
Test MetricsTest Metrics
Metric Purpose Sample measures/perspectives
Stability Convergence Number and type of changes (bug
versus enhancement; interface
versus implementation)
Amount of rework per iteration
Quality Iteration planning
Rework indicator
Release criterion
Number of errors
Defect discovery rate
Defect density
Maturity Test coverage/adequacy
Robustness for use
Test hours/failure and type of
failure
Test Test PlanPlan
40
AccomplishmentsAccomplishments
What we did (versus Original Plan)Project Management
SPMP (v 2.2)Size Estimation (v 1.0)Software Risk Evaluation & Mitigation PlanProcess Handbook (v 2.0)
RequirementsSRS (v 2.3)Use Case Model (v 1.2)
Analysis and DesignArchitecture (v 1.0)
TestVerification and Validation Plan (v 1.1)
What we postponed (versus Original Plan)Analysis and Design
Use Case RealizationDetail Design (partly done)
41
Effort MeasurementEffort Measurement
Time spent this semester
0
100
200
300
400
500
600
700
800
900
Wee
k1
Wee
k2
Wee
k3
Wee
k4
Wee
k5
Wee
k6
Wee
k7
Wee
k8
Wee
k9
Wee
k10
Wee
k11
Wee
k12
Wee
k13
Wee
k14
hou
rs (C
um
ula
tive
)
Plan
Actual
42
Next PlanNext Plan
Elaboration Phase (Continued): ~Early JuneUse Case RealizationDetail Design
Construction Phase: ~Mid JulyCoding & Test
Transition Phase: ~Early AugustSystem Integration TestSystem InstallUser Training
43
Lessons LearnedLessons Learned
TechniquesATAMSoftware Risk Evaluation
For better teamworkWithout respect, the team never maintains harmonious relationsTry to make a good meeting mode even if personal feeling is not good
44
Q & AQ & A
45
Appendix - Initial Component Appendix - Initial Component DesignDesign
Static modelingIdentify interface and component candidates