RELEASE AND DEPLOYMENT
MANAGEMENT
CSSSPEC6
SOFTWARE DEVELOPMENT
WITH QUALITY ASSURANCE
<<professor>>
SYSTEMS LIFECYCLE
Computer Science Department
Slide 2 of 49
APPLICATION MANAGEMENT TYPICAL PROBLEMS
• Inability to track and manage multiple projects affecting the same
or multiple systems with multiple end dates and multiple business
owners.
• Lack of predictability in delivery timeframes, costs, and support
requirements.
– IT: “You will get it next phase…” Business: “Yeah right…”
• Escalation management paradigm <squeaky wheel syndrome
followed by whiplash syndrome>.
• Total breakdown in business owner confidence and trust
(credibility) in IT’s ability to deliver.
• Risk to application uptime.
Computer Science Department
Slide 3 of 49
A MODEL OF PREDICTABILITY
Computer Science Department
Slide 4 of 49
WHAT IS RELEASE MANAGEMENT?
RELEASE MANAGEMENT (aka Release Train) can be defined as
a methodology for planning and implementing an integrated
set of functional components and processes in a controlled
manner.
– Date driven releases are scoped in order to meet prespecified delivery dates, the project management “Iron
Triangle” balanced on the schedule apex.
– Reversed planned start with your target implementation
dates and work backwards.
– Mechanized process should try to emulate a typical
factory operation.
Slide 5 of 49
WHAT IS RELEASE MANAGEMENT?
RELEASE MANAGEMENT (aka Release Train) can be defined as
a methodology for planning and implementing an integrated
set of functional components and processes in a controlled
manner.
– Forecasted schedules as well as functionality; force an
organization to strategize and plan in advance.
– Integrated and predictable; many business needs folded
into one release, and everyone knows the schedule.
– Uses standard system development lifecycle (SDLC) and
project management methodologies (PMBOK) and best
practices
Slide 6 of 49
BENEFITS OF RELEASE MANAGEMENT
Provides for an integrated (and transparent) view of both business and IT plans
– Open planning can provide a clear view of what is being developed, and
when the key milestone will be achieved.
Results in a more stable production system
– The introduction of an integrated release early in the development cycle
allows for more careful analysis and testing of impact to normal
operations.
Creates predictability in delivery timeframes, costs, and support requirements
– Release Management provides all corporate entities with a clear view of
the functionality being delivered and release scheduling, both in the
short and long run.
Allows for the utilization of corporate resources consistent with corporate
priorities
Used by many large organizations such as Cisco, Sun, etc.
Computer Science Department
Slide 7 of 49
RELEASE MANAGEMENT
RELEASE PLANNING
What are the systems? Is there a grouping of systems?
How many releases?
When to release?
How much overlap?
•
•
•
•
Q1 04
J
F
Q2 04
M
A
M
Q3 04
J
J
A
Q1 05
Q4 04
S
O
N
D
J
F
M
Release 1
Release 2
Release 3
Release 4
Computer Science Department
Slide 8 of 49
• Each release will have a lifecycle, with
phases.
Release Management
– i.e. Initiation, Planning, Build, Deployment and Close Out
• Identify withinRelease
each Lifecycle
phase a key
milestone(s).
• Manage each release to these milestones.
Q1 04
J
F
Q2 04
M
A
M
Requirements
Scope
Development
Quality Control
Freeze
Freeze
Freeze
Complete
Computer Science Department
J
Deployment
Slide 9 of 49
• Need to determine the duration of each
release.
Release
– i.e.
4 releases inManagement
a year, therefore each release
is 3 months.
Release Scheduling
• Determine the percentage of time each
Initiation
Planning
Build
Deployment
phase
will
occupy.
10%
20%
45%
25%
Percentage
• Choose your release
date(s) and reverse
Release Scope
Quality Control
Development Freeze Complete/Deployment
Key Milestones Requriements Freeze Freeze
plan the release.
Duration
(months) = 6
Schedule
0
1.2
2.7
1.5
26-Mar-05
7-May-05
30-Jul-05
15-Sep-05
Computer Science Department
Slide 10 of 49
RELEASE MANAGEMENT
Rigidity versus flexibility
• Rigidity of the release schedule is dependent upon the
organization implementing Release Management.
• Typically, there is a process for introducing “Hot Fixes” in
between release deployment dates.
– Constrained to only include Priority 1 system bugs, or
“Business Critical” enhancements.
– Exceptions and not the norm, otherwise the organization
risks losing the benefits.
– Determine, well in advance, the number and type of Hot
Fixes the RM team can absorb without putting the
release in jeopardy.
Computer Science Department
Slide 11 of 49
RELEASE MANAGEMENT
Rigidity versus flexibility
• To allow for some level of flexibility, the release dates can
be given a plus or minus factor.
– Allow the team to either expand or contract the
release schedule depending on different constraints.
– Changes to release dates will cascade down to
subsequent releases, therefore Change Management is
critical.
Computer Science Department
Slide 12 of 49
RELEASE MANAGEMENT
Multiple Systems/Multiple Business Requests
• Typically with an enterprise, there are a series of systems that may be
either tightly or loosely coupled.
– Groupings of systems; i.e. Provisioning Systems versus Operations
Systems
– Upstream versus downstream
• There may be any number of organizations with business requests
resulting in development on one or more of the systems.
– May or may not have shared needs or competing needs
– Need must be integrated
• Release planning sessions that include all appropriate organizations from
the lines of business and IT.
– Determine the critical scope or “Anchor Functionality” and the reserve
for unknown functionality.
– Rolling 12 month view of the release plan, therefore meet regularly.
Computer Science Department
Slide 13 of 49
RELEASE MANAGEMENT
Release Roadmap
Q1
J
Q2
F
M
A
Q3
M
Project 1a (OPS)
Project 2 (Strategy)
Unknown (5%)
J
Q2
M
S
O
Q1
N
D
A
Requirements
Scope
Freeze
Freeze
M
J
Development
A
Testing
F
M
Release Package 3
15-Apr-06
Q3
J
J
Project 1c (OPS)
Project 6 (Engineering)
Unknown (25%)
Release Package 2
15-Dec-05
Q1
F
A
Project 1b (OPS)
Project 3 (Engineering)
Project 5 (OPS)
Unknown (10%)
Release Package 1
15-Aug-05
J
J
Q4
Q4
S
O
Q1
N
D
J
F
M
Deploy
Requirements
Scope
Freeze
Freeze
Development
Testing
Deploy
Requirements
Scope
Freeze
Freeze
Development
Testing
Deploy
Slide 14 of 49
RELEASE MANAGEMENT
Integration Points
• Need to determine
where an
integration point
should be planned
within the RM
lifecycle.
• May be a
temptation to only
concentrate on
those functionalities
that appear, during
analysis phase, to be
interrelated.
Business
Request 1
Business
Request 2
Business
Request 3
The development
of all requests are
completed on or
near same date.
All move in uniform
fashion to
integrated testing
All business
requests are
scoped as one
release.
Requests are
gated prior to
deployment and
deployments are
coordinated to
include 1 to n
business requests.
All requirements
are reviewed in an
integrated fashion
No Release
management
Requirements
Scope
Development
Baseline
Baseline
Complete
Quality ControlDeployment
Complete
Computer Science Department
Slide 15 of 49
RELEASE MANAGEMENT
Make if official
• Use System Development Lifecycles (SDLC) such as the Waterfall or
Rational Unified Process (RUP) approaches.
• Use Project Management best practices, i.e. PMBOK.
– Each release could be viewed as a project.
• Formally document the policies and operating principles, such as:
– Scope Management
– Metrics Management
– Quality Management
– Change Management
– Strategic Release Planning
– Integrated Testing
– Risk Management
Computer Science Department
Slide 16 of 49
RELEASE MANAGEMENT
Roles
• Release Manager
– A project manager whom manages release.
• The release, the whole release and nothing but the release.
– Must be thick skinned!
• Business Project Manager
– Focused on the business needs.
– Natural tension with Release Manager.
• Development Manager
• Configuration Manager
• Environments Manager
• Testing Manager
Computer Science Department
Slide 17 of 49
RELEASE MANAGEMENT
Information Management Tools
• Release Management Planning and Deployment tool (RMPD)
– Tracking of multiple business requests, the associated software
deliverables of those requests, as well as release planning and
scheduling, and the association of software deliverables contained
within a release.
– Open-view of planned releases and the functionality for each
release.
– Automate additional Project Management tasks geared towards
the release.
– Integrated with other IT tools, such as Defect Tracking, Budgeting,
etc.
Computer Science Department
Slide 18 of 49
RELEASE MANAGEMENT
Information Management Tools
• There is not a strong suite of tools currently available for
managing the release management process.
– Maybe the Rational Suite
– MS Excel
– MS Project
– Homegrown
Computer Science Department
Slide 19 of 49
RELEASE MANAGEMENT
Summary
• IT organizations are losing credibility due to their inability to
provide predictability in software delivery timeframes, costs, and
support requirements. This is particularly evident during the
Application Management phase of a systems lifecycle.
• Release Management is a methodology that provides
predictability, stability and transparency to software delivery.
• Planning, planning, planning.
– A release in June might start in January
• Scope takes a back seat to schedule.
• Not a silver bullet, the implementing organization must truly
understanding the business objectives and the tradeoffs.
Computer Science Department
Slide 20 of 49
RELEASE AND DEPLOYMENT PLANS
The plan should define the: „
 Scope and content of the release „
 Risk assessment and risk profile for the release „
 Customers/users affected by the release „
 Team who will be responsible for the release „
 Delivery and deployment strategy „Resources for the
release and deployment
Computer Science Department
Slide 21 of 49
BUILD AND TEST PRIOR TO DEPLOYMENT INTO
PRODUCTION/LIVE ENVIRONMENT
The activities include:
 Developing build plans from the service design package, design
specifications and environment configuration requirements „
 Establishing the logistics, lead times and build times to set up the
environments „
 Testing the build and related procedures „Scheduling the build
and test activities „
 Assigning resources, roles and responsibilities to perform key
activities „
 Preparing build and test environments „
 Managing test databases and test data „Software license
management
Computer Science Department
Slide 22 of 49
PLANNING PILOTS
PILOTS are useful for testing the service with a small part
of the user base before rolling it out to the whole
business/ organization. It is important to determining the
appropriate scope of a pilot (how much of the service is to
be included in the pilot, size of department or user base).
Computer Science Department
Slide 23 of 49
PILOT SHOULD INCLUDE STEPS TO COLLECT FEEDBACK ON
THE EFFECTIVENESS OF THE DEPLOYMENT PLAN.
Surveying views and satisfaction from: „
 End users „
 Customers „
 Suppliers „
 Service desk and other support staff „
 Network management „
 Data and knowledge management – statistics on use and
effectiveness „
 Analysing statistics from service desk calls, suppliers,
capacity and availability
Computer Science Department
Slide 24 of 49
LOGISTICS AND DELIVERY PLANNING
These plans deal with aspects such as:
 „
How and when release units and service components will
be delivered „
 What the typical lead times are; what happens if there is a
delay „
 How to track progress of the delivery and obtain
confirmation of delivery „
 Metrics for monitoring and determining success of the
release deployment effort
Computer Science Department
Slide 25 of 49
BUILD AND TEST OF RELEASES
Key aspects that need to be managed during the activities
to build and test a service are: „
 Usage of the build and test environments „
 Recording the complete record of the build so that it can
be rebuilt if required „
 Maintaining evidence of testing, e.g. test results and test
report „
 Checking that security requirements are met „
 Verification activities, e.g. prerequisites are met before a
build or test begins
Computer Science Department
Slide 26 of 49
RELEASE PACKAGING
Build management procedures, methodologies, tools and
checklists should be applied to ensure that the release
package is built in a standard and controlled way in line
with the solution design defined in the service design
package. As a release package progresses towards
production it may need to be rebuilt.
For example, if a newer version needs to be incorporated
quickly to fix errors; or if the documentation needs to be
updated.
Computer Science Department
Slide 27 of 49
THE KEY ACTIVITIES TO BUILD A RELEASE
PACKAGE ARE:
 Assemble and integrate the release components in a
controlled manner „
 Create the build and release documentation including:
build, installation and test plans, procedures and scripts „
 Monitor and check the quality of the release and how to
recognize and react to problems „
 Procedures to back out release units or remediate a
change should a release fail „
Computer Science Department
Slide 28 of 49
THE KEY ACTIVITIES TO BUILD A RELEASE
PACKAGE ARE:
 The automated or manual processes and procedures
required to distribute, deploy and install the release into
the target environment (or remove it as necessary) „
 Procedures for tracking and managing software licenses „
Install and verify the release package „
 Baseline the contents of the release package „
 Send a notification to relevant parties that the release
package is available for installation and use
Computer Science Department
Slide 29 of 49
WHEN REVIEWING A DEPLOYMENT THE
FOLLOWING ACTIVITIES SHOULD BE INCLUDED:
 Capture experiences and feedback on customer, user and
service provider satisfaction with the deployment
example: through feedback surveys „
 Review quality criteria that were not met „
 Check that any actions, necessary fixes and changes are
complete „
 Review performance targets and achievements, including
resource use and capacity such as user accesses,
transactions and data volumes „management
Computer Science Department
Slide 30 of 49
WHEN REVIEWING A DEPLOYMENT THE
FOLLOWING ACTIVITIES SHOULD BE INCLUDED:
 Make sure there are no capability, resource, capacity or
performance issues at the end of the deployment „
 Check that any problems, known errors and workarounds
are documented and accepted by the customers/ business
and/or suppliers „
 Incident and problems caused by deployment „
 Deployment is completed with a handover of the support
for the deployment group or target environment to
service operations „
 A post implementation review of a deployment is
conducted through change management
Computer Science Department
Slide 31 of 49
SOFTWARE QUALITY MANAGEMENT
Concerned with ensuring that the required level of quality is achieved
in a software product.
THREE PRINCIPAL CONCERNS:
• At the organizational level, quality management is concerned with
establishing a framework of organizational processes and standards
that will lead to high-quality software.
• At the project level, quality management involves the application of
specific quality processes and checking that these planned
processes have been followed.
• At the project level, quality management is also concerned with
establishing a quality plan for a project. The quality plan should set
out the quality goals for the project and define what processes and
standards are to be used.
Computer Science Department
Slide 32 of 49
QUALITY MANAGEMENT ACTIVITIES
• Quality management provides an independent check
on the software development process.
• The quality management process checks the project
deliverables to ensure that they are consistent with
organizational standards and goals
• The quality team should be independent from the
development team so that they can take an objective
view of the software. This allows them to report on
software quality without being influenced by
software development issues.
Computer Science Department
Slide 33 of 49
QUALITY PLANS
Quality plan structure
– Product introduction;
– Product plans;
– Process descriptions;
– Quality goals;
– Risks and risk management.
Quality plans should be short, succinct documents
– If they are too long, no-one will read them.
Computer Science Department
Slide 34 of 49
SCOPE OF QUALITY MANAGEMENT
• Quality management is particularly important for large,
complex systems. The quality documentation is a record
of progress and supports continuity of development as
the development team changes.
• For smaller systems, quality management needs less
documentation and should focus on establishing a
quality culture.
Computer Science Department
Slide 35 of 49
SOFTWARE QUALITY
Quality, simplistically, means that a product should meet its
specification.
• This is problematical for software systems
– There is a tension between customer quality requirements
(efficiency, reliability, etc.) and developer quality requirements
(maintainability, reusability, etc.);
– Some quality requirements are difficult to specify in an
unambiguous way;
– Software specifications are usually incomplete and often
inconsistent.
• The focus may be ‘fitness for purpose’ rather than specification
conformance.
Computer Science Department
Slide 36 of 49
SOFTWARE FITNESS FOR PURPOSE
• Have programming and documentation standards
been followed in the development process?
• Has the software been properly tested?
• Is the software sufficiently dependable to be put into
use?
• Is the performance of the software acceptable for
normal use?
• Is the software usable?
• Is the software well-structured and understandable?
Computer Science Department
Slide 37 of 49
Software quality management is split
into THREE main activities:
• QUALITY ASSURANCE. The development of a framework
of organizational procedures and standards that lead to
high quality software.
• QUALITY PLANNING. The selection of appropriate
procedures and standards from this framework and
adapt for a specific software project.
• QUALITY CONTROL. Definition of processes ensuring
that software development follows the quality
procedures and standards.
Computer Science Department
Slide 38 of 49
PROCESS AND PRODUCT QUALITY
• It is general, that the quality of the development process
directly affects the quality of delivered products. The
quality of the product can be measured and the process
is improved until the proper quality level is achieved.
Computer Science Department
Slide 39 of 49
PROCESS AND PRODUCT QUALITY
Process quality management includes the following
activities:
• Defining process standards.
• Monitoring the development process.
• Reporting the software.
Computer Science Department
Slide 40 of 49
QUALITY ASSURANCE AND STANDARDS
QUALITY ASSURANCE is the process of defining how
software quality can be achieved and how the
development organization knows that the software has the
required level of quality.
The main activity of the quality assurance process is the
selection and definition of standards that are applied to
the software development process or software product.
Computer Science Department
Slide 41 of 49
QUALITY ASSURANCE AND STANDARDS
There are TWO MAIN TYPES of standards.
The product standards are applied to the software
product,
example: output of the software process.
The process standards define the processes that
should be followed during software development.
The software standards are based on best practices and
they provide a framework for implementing the quality
assurance process.
Computer Science Department
Slide 42 of 49
QUALITY PLANNING
QUALITY PLANNING is the process of developing a quality plan
for a project. The quality plan defines the quality requirements
of software and describes how these are to be assessed. The
quality plan selects those organizational standards that are
appropriate to a particular product and development process.
Quality plan has the following parts:
• Introduction of product.
• Product plans.
• Process descriptions.
• Quality goals.
• Risks and risk management.
Computer Science Department
Slide 43 of 49
QUALITY CONTROL
QUALITY CONTROL provides monitoring the software
development process to ensure that quality assurance
procedures and standards are being followed. The
deliverables from the software development process are
checked against the defined project standards in the
quality control process. The quality of software project
deliverables can be checked by regular quality reviews
and/or automated software assessment.
Computer Science Department
Slide 44 of 49
QUALITY REVIEWS
QUALITY REVIEWS are the most widely used method of
validating the quality of a process or product. They involve
a group of people examining part or all of a software
process, system, or its associated documentation to
discover potential problems. The conclusions of the review
are formally recorded and passed to the author for
correcting the discovered problems.
Computer Science Department
Slide 45 of 49
QUALITY REVIEWS
QUALITY REVIEWS are the most widely used method of
validating the quality of a process or product. They involve
a group of people examining part or all of a software
process, system, or its associated documentation to
discover potential problems. The conclusions of the review
are formally recorded and passed to the author for
correcting the discovered problems.
Computer Science Department
Slide 46 of 49
QUALITY STANDARDS
• Key to effective quality management
• Product standards define the characteristics exhibited
by all components (e.g. programming style issues)
• Process standards describe how a software process is to
be implemented
• Should encapsulate best practices - this helps avoid
repeating past mistakes
• Provide continuity by giving new team members a
means to understand the organizational priorities
Computer Science Department
Slide 47 of 49
PROCESS AND PRODUCT STANDARDS
PRODUCT STANDARDS
Design review form
Document naming standards
Function prototype format
Programming style standards
Project plan format
Change request form
PROCESS STANDARDS
Design review guidelines
Document submission procedures
Version release process
Project plan approval procedure
Change control process
Test data recording procedures
Computer Science Department
Slide 48 of 49
SOFTWARE QUALITY ATTRIBUTES
•
•
•
•
•
•
•
•
Safety
Security
Reliability
Resilience
Robustness
Understandability
Testability
Adaptability
•
•
•
•
•
•
•
•
Modularity
Complexity
Portability
Usability
Accessibility
Reusability
Efficiency
Learnability
Computer Science Department
Slide 49 of 49