Extreme Programming Modified: Embrace Requirements Engineering Practices - PowerPoint PPT Presentation

About This Presentation
Title:

Extreme Programming Modified: Embrace Requirements Engineering Practices

Description:

Poznan University of Technology, Poznan, Poland. IEEE Joint ... Sommerville-Sawyer Model. Defined 85 Basic & 40 Interm. Adv. Repeatable 55 Basic ... – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 29
Provided by: csPutP
Category:

less

Transcript and Presenter's Notes

Title: Extreme Programming Modified: Embrace Requirements Engineering Practices


1
Extreme Programming ModifiedEmbrace
Requirements Engineering Practices
IEEE Joint International Conference
on Requirements Engineering 9-13 September 2002,
Essen, Germany
  • J. Nawrocki, M. Jasinski, B. Walter,
    A.Wojciechowski
  • Poznan University of Technology, Poznan, Poland

2
Introduction
"XP is the most important movement in our field
today."
3
Introduction
  • Interesting practices of XP
  • strong customer orientation
  • increments short releases
  • test-first coding
  • planning game etc.

4
Introduction
  • Weaknesses of XP
  • lack of documentation
  • one (on-site) customer
  • too short planning perspective

How to solve those problems and preserve
agility?
5
Contents
1. Introduction 2. Reconciling XP with
documentation 3. Multiple customer
representatives 4. Modifying the XP lifecycle 5.
Early evaluation results 6. Conclusions
6
Reconciling XP with documentation
Travel light.
7
Reconciling XP with documentation
Travel light. What you need is just code and test
cases.
IEEE Standard 830
UML
8
Reconciling XP with documentation
Travel light. What you need is just code and test
cases.
Oral communication is preferred as the written
and e-mail communications (..) are error-prone.
But people sometimes forget!
Why did I decide to ..
9
Reconciling XP with documentation
To be agile does not mean that you have to throw
away the (requirements) documentation.
10
Reconciling XP with documentation
To be agile does not mean that you have to throw
away the (requirements) documentation.
11
Reconciling XP with documentation
To be agile does not mean that you have to throw
away the requirements documentation.
In XP tester is responsible for helping the
customer choose and write functional tests. --
Kent Beck
  • XP roles
  • Customer
  • Developer
  • Coach
  • Tracker
  • Tester

Tester-analyst (product manager)
is responsible for writing and managing usage
scenarios, requirements, and acceptance tests.
Tools Rational RequisitePro, Rational Robot,
xUnit
12
Contents
1. Introduction 2. Reconciling XP with
documentation 3. Multiple customer
representatives 4. Modifying the XP lifecycle 5.
Early evaluation results 6. Conclusions
13
Weaknesses of XP
One on-site customer
If there are many it is assumed they speak one
voice.
Sometimes they dont.
We need a new car.
No! We need a new furniture.
14
Multiple customer representatives
15
Multiple customer representatives
16
Multiple customer representatives
20 hours for you ..
Customers
6 h
9 h
More func.
More colors
How to choose the scope?
17
Contents
1. Introduction 2. Reconciling XP with
documentation 3. Multiple customer
representatives 4. Modifying the XP lifecycle 5.
Early evaluation results 6. Conclusions
18
Modifying the XP Lifecycle
Design for today, not for tomorrow.
Short planning perspective (one release)
One release is sometimes not enough.
19
Modifying the XP Lifecycle
Design for today, not for tomorrow.
Short planning perspective (one release)
One release is sometimes not enough.
Technical risk
Utility
20
Modifying the XP Lifecycle
0. Initial Project Statement (subject,
stakeholders etc.) 1. Usage scenarios (problems
visions) 2. Requirements specification 3. Project
presentation selection of developers 4. Project
planning (and risk exploration)
5. Release 1 (2 iterations, each takes 3
weeks) 6. Release 2 (2 iterations)
21
Contents
1. Introduction 2. Reconciling XP with
documentation 3. Multiple customer
representatives 4. Modifying the XP lifecycle 5.
Early evaluation results 6. Conclusions
22
Software Development Studio A team structure
23
Experiment at PUT
Software Development Studio 2000/01
CMM Level 2
eXtremme Programming
24
Experiment at PUT
Software Development Studio 2001/02
Modified eXtremme Programming
25
Sommerville-Sawyer Model
RE Practices
  • Interm.
  • ...
  • ...
  • Advanced
  • ...
  • ...
  • Basic
  • ...
  • ...

Defined gt 85 Basic gt 40 Interm. Adv.
Repeatable gt 55 Basic
26
Sommerville-Sawyer Model
Basic IntAdv
TJam 69 31
Harpo 71 32
Predictor 70 30
Kex 68 35
EdTool 71 27
ASM 64 29
Defined gt 85 Basic gt 40 Interm. Adv.
Repeatable gt 55 Basic
27
Summary
  • Tester-analyst is responsible for documenting and
    managing requirements.
  • Modified Planning Game tries to solve conflicts
    between multiple customers.
  • Modified life-cycle emphasises requirements
    engineering and risk management.
  • There is a need for user training.
  • Early results are promising.

At last!
28
Questions?
?
Write a Comment
User Comments (0)
About PowerShow.com