Unified Process versus

Extreme Programming

Outline

Compare and contrast UP and XP Processes / Disciplines Management Artefacts

Risk management – some thoughts

Disciplines

Disciplines

Unified Process

Process Disciplines

Requirements Specification (Kravspesifikasjon) System Analysis (Systemanalyse) Design Implementation Testing Deployment (iverksetting)

Maintenance (Vedlikehold)

Supporting Disciplines

Configuration management Change management Environment Project management

Time Risk Priorities Estimation Status Tracking / Follow up

XP key practices

Customer is Team Member User Stories Short Time Boxed Iterations Pair Programming Test-Driven Development Collective Code Ownership Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor (Coding standards)

UP Disciplines vs XP Practices

UP Disciplines Requirements Specification System Analysis Design Implementation Testing Deployment Configuration management Change management Environment Project management

Time Risk Status tracking

XP Practices Customer in Team User Stories Short Time Boxed Iterations Pair Programming Test-Driven Development Collective Code Ownership Sustainable Pace Open Workspace The Planning Game Simple Design Refactoring Metaphor

Business modelling

UP Processes

Process map Use Cases

Domain Domain model ? Glossary ?

XP None?

Requirements Specification

UP Use Cases UML artefacts

Domain model Dynamic models

Non-functional requirement

XP User stories Metaphores (?) UML Model schetches

Non-functional requirements

System Analysis

UP Subtasks More detailed Use Case UML Domain model Prototypes?

XP Subtasks UML model schetches Acceptance tests Working code

Design

UP UML design model

Class Interaction Packages / Modules

Base Architecture Prototypes

XP UML schetches Simplest possible

design Incremental code

development Refactoring

Implementation

UP Integrated, executable

code after each iteration

XP Integrated, executable

code after each iteration

Test suites – automatic tests

Testing

UP No particular demand

for test method Types

Unit tests Integration tests Acceptance tests (Regression

testing) Test first can be used

XP Test first Automatic testing Acceptance Testing

Deployment

UP Deployed system

XP Deployed system

Configuration Management

UP Version Control Iteration releases

XP Collective Ownership Refactoring Integrated, testable code Iteration releases

Change management

UP Requirements tracking Change requests

XP ”Embrace change” Planning game Refactoring

Environment

UP No particular demands

for working environment

Artifacts important for communication

XP Pair Programming Test-Driven

Development Collective Code

Ownership Sustainable Pace Open Workspace

Risk and priority

UP Identify and manage

risk High risk tasks first Prototypes Base architecture

Prioritize use cases High priority first ”Use Case driven”

XP Identify risk High risk tasks early,

but only if useful for current user stories

Prioritize user stories High priority first ”User driven” – user in

team

Managing time

UP Time boxing:

2 – 6 weeks No particular method

XP Time boxing:

1 – 4 weeks Estimate on basis of

experience - velocity Velocity increases

Project management (1)

UP (Release planning) Iteration planning Follow up

Finished tasks Unfinished tasks Used time Remaining time

”Manager driven”?

XP Release planning Iteration planning Task planning Follow up

Finished tasks Unfinished tasks Velocity

”Developer driven”?

Project management (2)

UP Course plan for future

iterations Detailed plan for next

iteration Users prioritize Use Cases Developers estimate tasks

XP Developers continuously

involved in estimation Weekly plan stable Overall plan changes

continuously

Risk – some thoughts

Risk in the waterfall model Risk in iterative development Managing risk

Risk in the waterfall model

RISK

T I M E

Implement.

Testing

Design

Analysis

Req.Spec

Deployment

Risk in iterative development

T I M E

Iteration 1

RISK

Iteration 2 Iteration 3

Risk iterativeRisk waterfall

Risk factors (1)

Resources Lack of people Lack of money

Competence Lack of knowledge Misunderstanding requirements Missing important requirements

Communication Bad coordination Misunderstandings “Bad chemistry”

Risk factors (2)

”Technical risk” Uncertain solution method Uncertain requirements Uncertain performance

Identify uncertain subtasks Difficult Uncertain of difficult Uncertain extent

Deadlines Illness Underestimated size of task Partners not delivering on time

Reducing risk

Manage risks Identify risks Assess Seriousness and Probability Get an idea how to handle a risk if it occurs

Prioritize work according to risk level High risk tasks in early iterations Prototypes Basic functionality used by many components Consider high risk issues in early iterations

E.g.: Many simultaneous users

Discussion themes

MDD vs XP // CASE tools vs XP Model is source vs Code is source

Non-functional requirements in XP Have XP sufficient focus? Have users sufficient focus?

Is XP downplaying software architecture? When is overall architecture introduced? Can refactoring lead to good architecture?

Is XP too dependant on good people? Very little written documents – need good memory Need helpful team members

Takk for oppmerksomheten!