The document discusses managing changes, risks, and quality in software projects. It covers the importance of change control and configuration management to keep projects on scope as changes are inevitable. Change control establishes processes for approving or rejecting change requests while assessing impact. Configuration management establishes baselines and maintains coherence of a system over time through version control and change management. It allows retrieving past versions and configurations.

1. Managing Changes,
Risks, and Quality

2. spm - ©2014 adolfo villafiorita - introduction to software project management
Goals of the Unit
• Requests for changes and changes will occur in your
project
• The goal of this unit is understanding:
– The importance of keeping a project under scope
– How request for changes can positively or negatively influence
your project
– The techniques to manage changes
!2

3. spm - ©2014 adolfo villafiorita - introduction to software project management
The Framework
• The scope document formalizes the goals of a project
• Ideally, once the goals are fixed, the project should move
on to the design/implementation phase and achieve the
project goals, through a progressive refinement
• Any deviation from such course of action is a perturbation
(it changes goals, plans, costs, outputs, work to be
performed, …)
• Changes, however, are inevitable
• The goal of a sound project management, therefore, is
ensuring that the change process is properly managed
!3

4. spm - ©2014 adolfo villafiorita - introduction to software project management
Fundamental Concepts
• Change Control is the set of practices to ensure
request for changes are properly taken care of
• Configuration Management is the set of practices
to ensure project outputs remain coherent over time
!
• Change Control and Configuration Management span over the
lifecycle of the project outputs
• In software projects artifacts are extremely simple to change
(e.g., editing a file)
• In software projects, connection with bug reporting/bug lifecycle
!4

5. Initiate Plan Execute &
Monitor
Close
Develop
Monitor
Goals,
Cost
and
Schedule
Release
Change Control & Configuration Management
Quality Management
Human Resource Management
Kick Off
Activities
Formalize
Goals
Define
Schedule
Define Costs
Assess
Feasibility
Close
Collect
Outputs
[Obtain
Approval]
Risk Management

6. Change Control

7. spm - ©2014 adolfo villafiorita - introduction to software project management
Causes of Request for Changes
• Incompleteness or incoherencies in the project
requirements or in the description of work
• A better comprehension of the system to be
developed
• A technical opportunity
• A technical challenge
• A change in the external environment
• Non-compliance of a project deliverable
!7

8. spm - ©2014 adolfo villafiorita - introduction to software project management
Request
Check and
Formally
Record
Evaluate Impact
Approve
Reject
Change Request
(formally tracked)
Change Request Impact Assessment Directive
Action Items
Execute
Changes
Record and
Distribute
Artifacts
(updated)
A Change Control Process
!8
• It runs in parallel to the other PM activities
throughout the project

9. spm - ©2014 adolfo villafiorita - introduction to software project management
Comments
• A change control board might be appointed to
approve/reject changes
• The cost and risk of changes increase as the project
moves to the delivery
• The process ensures a formal record is kept and and a
clear procedure is set to evaluate the impact of
changes
• Change and change management is embraced by agile
methodologies (changes “treated” as requirements)
!9

10. Software Evolution
Models

11. spm - ©2014 adolfo villafiorita - introduction to software project management
What makes a Software System
• Software systems are made of many different artifacts
(sources, libraries, external libraries, documentation,
conversion scripts, databases)
• Software systems run in many different configurations
(e.g., base/pro, versions 1 and 2, Linux/OSX/Windows)
• Two sources of complexity need to be addressed to
develop or maintain a software product:
– Identification of the artifacts
– Evolution
!11

12. spm - ©2014 adolfo villafiorita - introduction to software project management
Linear Development Model
!12
Source Code
Version 1
Application
Version 1
Source
Code
Version 3
Application
Version 3
produces
Source
Code
Version 2
Application
Version 2
produces produces
replaces replaces

13. spm - ©2014 adolfo villafiorita - introduction to software project management
Branching Development Model
!13
Source
Code
Version 1
Application
Version 1
Source
Code
Version 3
Application
Version 3
produces
Source
Code
Version 2
Application
Version 2
produces
replaces replaces
Source
Code
Version 1.1
Application
Version 1.1
Source
Code
Version 2.1
Source
Code
Version 2.1
Application
Version 2.1
produces
produces produces

14. spm - ©2014 adolfo villafiorita - introduction to software project management
Software Development Models
• Linear development:
– Only one version of an application is running at any given time
(Example: one-offs; many web applications are one-offs)
• Branching development:
– Various versions of an application are running at a given time
!14

15. Configuration
Management

16. spm - ©2014 adolfo villafiorita - introduction to software project management
Configuration Management
Configuration Management (CM) is a
set of activities running in parallel to
the development process, whose goal
is establishing and maintaining
system’s coherency over time
!
– Part of the project management plan
– Helps define project standards and best practices
!16

17. spm - ©2014 adolfo villafiorita - introduction to software project management
Configuration Management Main Goals
• Being able to build a system from a consistent set of
components
• Being able to retrieve a software component when
needed (consider: storage time, storage means)
• Being able to view the history of changes a system has
undergone
• Being able to retrieve a previous version of a system
!
• Remark: closely related to the change management
process
!17

18. spm - ©2014 adolfo villafiorita - introduction to software project management
Some Examples
• A bug is reported by a user on a COTS software we
have been selling for ten years.
• A client requests an enhancement to a one-off system
we sold in 2005.
• We need to reproduce/understand an odd behavior of
the control software of a space exploration probe which
is now orbiting Jupiter
!18

19. spm - ©2014 adolfo villafiorita - introduction to software project management
Steps and Tools: Establish Baseline
• The first step is “establishing what a product is”
• A good CM requires to:
– Clearly identify the items which constitute a product
– Identify the relationships among these items
– Choose an appropriate identification and numbering
scheme for versions
– Take “snapshots”: baseline records
!19

20. spm - ©2014 adolfo villafiorita - introduction to software project management
Steps and Tools: Manage Changes
• The second step is “maintaining coherency over time”
• A good CM process requires to:
– Define the “baseline record” (the starting point)
– Identify and approve requests for changes (see change
control)
– Formally record changes and history of each item
– Maintaining old versions
• For family of products there could be different
baselines. Changes might need to be applied to one
or more baseline (consider a security fix to a browser)
!20

21. spm - ©2014 adolfo villafiorita - introduction to software project management
Steps and Tools: Considerations
• For software development, a version control system
implements various of the functions described above
• Tools are not sufficient: an adequate process has to be
in place
• Semantic versioning is an example of numbering
schema
!21

22. spm - ©2014 adolfo villafiorita - introduction to software project management
Version Control Systems: Main Concepts
• Working version: the file (or set of files we are
currently editing)
• Repository: the storage where all versions of a file (or
set of files) are kept together with additional information
!22
Repository Repository'
a.each do |x|
puts x
end
#a.each do |x|
#puts x
#end
a.each do |x|
puts x
end
#a.each do |x|
#puts x
#end
commit checkout commit
a.each do |x|
puts x
end
#a.each do |
x|
#puts x
#end
History Log
Tags
Version N.
Files
a.each do |x|
puts x
end
#a.each do |
x|
#puts x
#end
History Log
Tags
Version N.
Files
a.each do |x|
puts x
end
#a.each do |
x|
#puts x
#end

23. spm - ©2014 adolfo villafiorita - introduction to software project management
Version Control Systems: Main Concepts
• In the simple case (early VCS) each file would have an
independent repository
• Coherence is kept by assigning the same tags to all
artifacts constituting a baseline
• More recent VCS manage sets of artifacts in an
integrated way
• Tagging is used to mark important baseline records
• A VCS typically support parallel access and editing of
artifacts
!23