1
Software Life Cycles and
Configuration ManagementLecture 11
David Broman
Department of Computer and Information Science
Linköping University, Sweden
Software Engineering
TDDC88/TDDC93
autumn 2008
2
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Theory Lecture Plan
L1 - Course Introduction and Overview
L2 - Project Management
L3 - Requirements
L4 - Acceptance Testing and Quality Factors
L5 - UML
L6 – Design Patterns
L7 – System design and architecture
L8 - Testing Theory
L9 - Testing in Practice
L10 - Inspection
L11 - Software Life Cycles and Configuration Management
L12 - Software Quality Management
L13 - Course Summary, Exam examples, Questions
L11 - Software Life Cycles and Configuration Management
3
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
A Software Life-cycle Model
Which part will we talk about today?
Requirements
System Design(Architecture,
High-level Design)
Module Design(Program Design,
Detailed Design)
Implementationof Units (classes, procedures,
functions)
Unit testing
Module Testing(Integration testing of units)
System Testing(Integration testing of modules)
Acceptance Test(Release testing)
Validate Requirements, Verify Specification
Verify System Design
Verify Module Design
Verify Implementation
Project Management, Software Quality Assurance (SQA), Supporting Tools, Education
Maintenance
4
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Agenda - What will you learn today?
Part I
Life Cycles and Process Models
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software
Configuration Management
2
5
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Part I
Life Cycles and Process Models
6
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Project vs. Process
Start and stop Goal An orderer
A budget A single-time
occurrence
Activity 1 Activity 2 Activity 3
Process
Project
Ordered set of activities
Each activity has entry/exit
criteria and input/output.Goal of each activity
Constraints
Processes are
reoccurring
May contain
subprocesses
7
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Software life-cycle model (Repetiotion L1)
Idea Software Product
Software
Life-Cycle
Model
Stockholm Subway Map
A software
life-cycle model
Very
Complex
Software
Process
(Software Engineering
Process)
(Software Engineering
Process Model)
8
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Time
Model of a life-cycle (a Process Model)
Abstraction
Carolthe customer
Dianathe developer
3
9
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Verify System Design
A familiar model?
Requirements Acceptance Test(Release testing)
Validate Requirements, Verify Specification
System Design(Architecture,
High-level Design)
Module Design(Program Design,
Detailed Design)
System Testing(Integration testing of modules)
Implementationof Units (classes, procedures,
functions)
Unit testing
Verify Implementation
Module Testing(Integration testing of units)
Verify Module Design
Time
Maintenance
10
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Requirements Acceptance Test(Release testing)
System Design(Architecture,
High-level Design)
Module Design(Program Design,
Detailed Design)
System Testing(Integration testing of modules)
Module Testing(Integration testing of units)
Unit testingImplementation
of Units (classes, procedures,
functions)
Verify Design
The V-model
Validate Requirements, Verify Specification
Time
Implementation
Integration
Testing
System Testing
Acceptance Test
Program Design
System Design
Requirements
Feedback and iterations
are possible
Maintenance
Maintenance
11
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Another model...
Time
Implementation
Integration
Testing
System Testing
Acceptance Test
Program Design
System Design
Requirements
Maintenance
12
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
The Waterfall model
Time
Implementation
Integration
Testing
System Testing
Acceptance Test
Program Design
System Design
Requirements
� One of the first life-cycle models (Royce, 1970)
� Very common, very criticized
Why is the waterfall model
so criticized?
Which are the problems?
Can it be useful sometimes?
Milestone and deliverable at
each step. (Artifacts such as Design
document, Req. Specification. etc.).Maintenance
Finish each phase
before continue
to next.
4
13
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
The Waterfall model - some arguments
Pros
� Simple, manageable and easy to understand
� Fits to common project management practices
(milestones, deliverables etc.)
� Focus on requirements and design at
beginning, save money and time at the end
� Can be suitable for short projects (some
weeks)
� Can be suitable for "stable" projects, where
requirements do not change
� Focus on documents, saves knowledge which
can be reused by other people.
� Widely used, e.g. US Department of Defense
� Can be suitable for fixed-price contracts
14
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
The Waterfall model - some arguments
Cons
� Software requirements change,
hard to sign-off on a SRS.
� Early commitment. Changes at the end, large
impact.
� Feedback is needed to understand a phase.
E.g. implementation is needed to understand
some design.
� Difficult to estimate time and cost for the
phases.
� Handling risks are not part of the model.
Pushes the risks forward.
� Software "is not" developed in such a way. It
evolves when problems are more understood.
Little room for problem solving.
15
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Can we improve the model?
Implementation
Integration
Testing
System Testing
Acceptance Test
Program Design
System Design
Requirements
MaintenanceDanger! E.g. a performance
problem can result in a
major requirements change.
Very expensive rollback...
Iteration back to previous phase
16
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Do it twice?
Implementation
Integration
Testing
System Testing
Acceptance Test
Program Design
System Design
Requirements
Maintenance
First round, a
prototype
Second round, do it right.
Input to the phases
in the second
round
The original paper is actually
misunderstood!
(Royce, 1970) includes
� Iteration of phases
� "Do it twice" prototype
5
17
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Is overlapping phases a solution?
Time
requirements
design
implementation
test
When do we "sign-off",
e.g. when do we have all requirements?
What if a major design flaw is
discovered at the testing
phase?
Release!
18
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Is overlapping phases a solution?
Time
deployment
What kind of structure have we actually
achieved? No sign-off. How does this
help us?
requirements
design
implementation
test
Release!
19
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What should be built?
Time
deployment
design
implementation
test
Release!
How? By delivering
several releases?
”The hardest single part of building a software
system is deciding precisely what to build”
(Frederick P. Brooks)
20
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Iterative Development
Time
deployment
design
implementation
test
Final Release!R1R2
Iteration 1 Iteration 2 Iteration 3
Customer Feedback Customer Feedback
When should the releases take
place?
Time-boxing - The time period is
fixed for each iteration.
What should be included in the
release?
Prioritized functionality - Do the
most important parts first.
6
21
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Dependent project parameters (revisited)
Project
Calendar TimeResources
Features Quality
Calendar time and
resources are fixed
Select the most
important
functionsSelect quality.
E.g. how general
should we be?
22
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Prioritization - some matrices
Development Effort
Customer
Benefit
HighLow
High
Low
Sweet Spot
Avoid
Urgency
Importance
HighLow
High
Low
Sweet Spot
Avoid
23
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Iterative vs. Incremental Development
Time
deployment
design
implementation
testIteration 1 Iteration 2 Iteration 3
Incremental DevelopmentAdd a new "part" at each increment
Iterative DevelopmentImprove a "working system" at each iteration
Working
System v0.1
Working
System v0.2
Working
System v0.3
Note. Both concepts are often
combined and sometimes
misleading called just
iterative development.
24
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Spiral Model
Determine goals,
alternatives, and
constrains
Evaluate
Alternatives
and risks
Develop
and Test
Plan Next Phase
RA
RA
RA
RA
P1
RA = Risk Analysis
P1 = Prototype 1
P2 P3 P4
Req. plan CO
CO = Concepts of operation
BAC
BAC = Budget, Alteranatives, Constraints
BAC
BAC
Validate
req.
SW.
req.SW.
design
verify
design
Dev.
planIntegration
and test plan
Detailed
Design
Code
Unit test
System
testAcceptance
test
Main feature:
RISKS
7
25
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Iterative Development - Cons
Time
deployment
design
implementation
test
Final Release!R1R2
Iteration 1 Iteration 2 Iteration 3
Customer Feedback
Is iterative development the
silver bullet?
� Problem with current business
contracts, especially fixed-price
contracts.
� With small iterations, can be hard to
map customer requirements to
iterations.
Customer Feedback
26
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Iterative Development - Pros
Pros
� Misunderstandings and inconsistency are made
clear early (e.g. between requirement, design,
and implementation)
� Encourage to use feedback -> elicit the real
requirements
� Forced to focus on the most critical issues
� Continuous testing offers a project assessment
� Workload is spread out over time (especially test)
� The team can get "lesson learned" and
continuously improve the process
� Stakeholders gets concrete evidence of progress
27
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Part II
Methodologies and Processes -
RUP, XP, and Scrum
28
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
We are using an iterative process!
Time
Define a plan with 1..N iterations. We do not have to
care about plans...
Harrythe hacker
Is this a good iterative process?
Methodologies
and defined
Processes
Of course not. We need some structure!
Now, let's hack!
8
29
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Processes, Models, Methodologies...
Methodologies
and defined
Processes
Process Models
Waterfall
model
V- model Spiral model
Prototype model
"what" at a high level
of abstaction
"what" and to a certain
level "how"
Rational Unified
Process (RUP)
Extreme Programming (XP)
Scrum
agile methods
Which is the "best"
approach?
30
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Processes, Models, Methodologies...
Methodologies
and defined
Processes
Process Models
Waterfall
model
V- model Spiral model
Prototype model
"what" at a high level
of abstaction
"what" and to a certain
level "how"
Rational Unified
Process (RUP)
Extreme Programming (XP)
Scrum
agile methods
Question:
What is the difference between a methodologist
and a terrorist?
Answer:
You can negotiate with a terrorist.
31
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Goals with a software development process
� Guidance about order and content
of team activities.
� Specify when and which artifact
that should be produced.
� Direct individual developers' tasks
and the team as a whole
� Give criteria for monitoring and
measuring activities and generated
products.
32
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What is Rational Unified Process (RUP)?
A software engineering process
A disciplined approach to produce high quality software
A process product
� A software (web based) offered by IBM (earlier Rational)
� OpenUP/Basic, an lightweight open source variant
A process framework
� Adapted and extended to suit a specific organization
9
33
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP - Elements of the Process
Roles: the who
e.g. system analyst, designer, test designerActivities: the how
is assigned to a ►
Artifact: the what
e.g. use-case models, source code, documents
(same as deliverable)
creates,
modifies,
controls ►
Workflows: the when
Core workflow to each discipline
34
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Disciplines
The "container" for the four elements: roles, activities, artifacts and workflows
Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment
Change & Config. Mgm.
Project Mgm.
Environment.
Core
Technical
Disciplines
Core
Supporting
Disciplines
35
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP- Phases and Milestones
Time
Inception
(10%) Transition
Inception
� Formulate scope
� Capture most important requirements
� Plan, risk, staffing, project plan
� Synthesize a candidate architecture
� The project may be cancelled after this phase
similar to a "Pre-study"
Life-cycle objective milestone
Phase
Milestone
36
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP- Phases and Milestones
Time
Inception
(10%) TransitionElaboration
(30%)
Elaboration
� Define architecture
� Specify requirements more precisely
� Executable architecture prototype
� Define project plan
Life-cycle architecture milestone
10
37
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP- Phases and Milestones
Time
Inception
(10%) TransitionElaboration
(30%)
Construction
(50%)
Construction
� Resource management and control
� Design, Implementation, and Testing
� Output (software + documentation) ready
for users.
Initial Operational Capability
milestone (beta-release)
38
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP- Phases and Milestones
Time
Inception
(10%) TransitionElaboration
(30%)
Construction
(50%)
Transition
(10%)
Transition
� Transition of the product to users
� Beta-testing
� Training of users and maintainers
� Rollout of the product to operational environment
Product release
milestone
39
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
RUP- Phases and Milestones
Time
Inception
(10%) TransitionElaboration
(30%)
Construction
(50%)
Transition
(10%)
Was not RUP iterative???
I5 I6 I7I3 I4I2I1 I8 I9 I10 I11
Iterations within phasesInternal milestones and
releases
40
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Disciplines and Phases
Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment
Change & Config. Mgm.
Project Mgm.
Environment.
Core
Technical
Disciplines
Core
Supporting
Disciplines
Inception Elaboration Construction Transition
11
41
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Agile Approaches - Agile Alliance
Manifesto for Agile Software development
Favor
� Individuals and interactions over processes and tools
� Working software over comprehensive documentation
� Customer collaboration over contract negotiation
� Responding to change over following a plan
(http://agilemanifesto.org, 2001)
Lightweight approaches to satisfy the customers with
"early and continuous delivery of valuable software"
42
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Extreme Programming - Values and Principles
A lightweight methodology for vague or rapidly changing requirements
Values
Communication
Simplicity
Feedback
Changes need
feedback
Courage
"If you know what the problem
is, do something"
Respect
Practices
Principles
Mutual benefit
"win-win", automated
testing
Reflection
"How" and "why"
are we
working
Redundancy
If it fails. E.g. pair
programming.
Baby steps
"What is the least that you can do
that can be shown to be in
the right direction?"
43
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Extreme Programming - Some Practices
Pair Programming
� Focus on task
� Clarify ideas
� Rotate frequently
Stories
� "requirements", but not
mandatory
� Name + short story
� On index cards (paper)
Continuous Integration
� Integrate and test often
� Automated build system
� Automated regression tests
(e.g. JUnit)
Test-First Programming
� Create tests before code
� Focus on interface and
"what is needed"
� Gets tests for free
Refactoring
� Behavior preserving
transformation
� Tool support, e.g. Eclipse
44
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Scrum
Approach public in 1996 at OOPSLA
(Ken Schwaber, Jeff Sutherland)
"Scrum" strategy used in rugby for getting
and out-of-play ball back into play.
12
45
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Scrum Overview
Product backlog
� All requirements
� Prioritized only by
product owner
� Never finalized
� From anyone (users,
customers, sales)
Daily Scrum
� Short (15 min)
� done since last meeting,
todo, problems
� Pick from sprint backlog
Sprint
� 30 - days iteration
� product increment
Sprint backlog
� What to do in one
sprint
Scrum Master
� Enforce scrum practices
Sprint planning meeting
� Plan what to do in the
next sprint
(sprint = one iteration)
Executable Product Increment
46
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Part III
Software Configuration Management
47
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What is configuration management?
SCM
Configuration Item
Identification
� Source code modules
� Test scripts
� Design documents
� Build systems
48
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What is configuration management?
File A
v.03
File B
v0.1
File C
v.3.3
File A
v.03
File B
v0.1
File C
v.3.4
File A
v.03
File B
v0.11
File C
v.3.3
Baseline - a "snap-shot" of
configuration items.
Normally reviews in
some way.
Change Change
How do we control
changes?
13
49
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What is configuration management?
SCM
Configuration Item
Identification
� Source code modules
� Test scripts
� Design documents
� Build systems
Configuration control
� Only authorized people
may make changes
� Larger changes -
change requests
CHANGE REQUEST
Project:__________
Classification:_____
Priority:__________
Date: __________
Change Description:
Change Control Board (CCB)
� Make change decisions.
� Only large changes (e.g. new
major requirements)
50
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
What is configuration management?
SCM
Configuration Item
Identification
� Source code modules
� Test scripts
� Design documents
� Build systems
Configuration control
� Larger changes -
change requests
Status accounting
� Document and report
changes to those involved.
Auditing
� Ensure that the items are
complete and consistent.
� Make sure that the
configuration is tested and
meets requirements.
51
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
SCM tools
Change
Management
Workflow systems
� Define processes for change
requests
Change report system
� Bug-tracking
� New features
� Change request
(e.g free alternatives: Bugzilla, Trac)
Tool examples:
� Clear Case,
� Visual Source safe
� Perforce,
� CVS
� Subversion
Commit - add comments
SCM ToolsHistory - Find where the fault was added
Blame -Who added a certain code line
Diff -What has changed between two versions?
Locked checkout / no locks
What is a bug / what is a
feature?
52
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Version handling example
v1.0.23Trunk v1.0.24 v1.0.25
v1.1.24.1Development
Branch(s)
v1.1.24.2
Merge
v1.0.26
Test
v1.2.24Release Branch(s)
14
53
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Sync- and Stabilize (e.g. Microsoft)
Commit to SCM repository
Daily build
(automatic compile and link)
Smoke test
(automatic test of system)
Implement new
stuff
Fail? Success?
(Report via e-
mail, red-
lamp etc.) Stub-out e.g. user
interfaces and databasesAutomatic blame :-)
54
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Summary - What have we learned today?
Part I
Life Cycles and Process Models
Part II
Methodologies and Processes -
Part III
Software
Configuration Management
� Waterfall model
� V-Model
� Iterative models
� Spiral model
� RUP
� Agile
� XP
� Scrum
� Identification
� Control
� Status accounting
� Auditing
55
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Further reading (Books)
Rational Unified Process (RUP)
� Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition, ISBN
0321197704, Addison-Wesley Professional, USA, 2003
� Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A
Practitioner's Guide to the RUP, ISBN: 0321166094, Addison-Wesley Professional,
USA, 2003
Agile, Extreme Programming, Scrum
� Kent Beck and Cynthia Andres, Extreme Programming Explained: Embrace Change,
Second Edition, ISBN 0321278658, Addison-Wesley Professional, USA, 2004
� Ken Schwaber and Mike Beedle, Agile Software Development with Scrum, ISBN
0130676349, Prentice Hall, NJ, USA, 2002
� Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile
Toolkit, ISBN 0321150783, Addison-Wesley Professional, USA, 2003
Configuration Management
� Alexis Leon, Software Configuration Handbook, Second Edition, ISBN 1580538827,
Artech House Publishers, MA, USA, 2005
56
Part I
Life Cycles and
Process Models
David Broman
Part II
Methodologies and Processes -
RUP, XP, and Scrum
Part III
Software Configuration
Management
Further reading (Web)
Extreme Programming
� Extreme Programming, a gentle introduction
http://www.extremeprogramming.org/