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


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


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


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


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)


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


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


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


17

Overall Architecture – Before Overall Architecture – Before ATAM ATAM


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


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


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


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


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


23

Overall Architecture – Overall Architecture – Final DecisionFinal Decision

Tier Layer UI Type

Client Tier Middle Tier

Presentation

Data Tier

Business Logic

HTMLpage

Applet


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


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


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


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)


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)


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

spring 2004 eosp

Documents

process problems

process manager

geo team

team meeting4 members

team decisioncompensate

team membersassign authority

determined decision

decision makingno