Software Evolution and Maintenance

1
Topics covered

 Evolution processes
 Change processes for software systems
 Program evolution dynamics
 Understanding software evolution
 Software maintenance
 Making changes to operational software systems
 System re-engineering
 Re-writing legacy systems without change its functionality

2
Software change

 Software change is inevitable

 New requirements emerge when the software is used;
 The business environment changes;
 Errors must be repaired;
 New computers and equipment is added to the system;
 The performance or reliability of the system may have to be
improved.
 A key problem for all organizations is implementing and
managing change to their existing software systems.

3
 Types of changes

 Repair software faults

 Changing a system to correct deficiencies in the way meets
“Maintenance”

its requirements.
 Adapt software to a different operating environment
 Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initial
implementation.
“Evolution”

 Add to or modify the system’s functionality

 Modifying the system to satisfy new requirements.
“Reengineering”

 Improve the program structure and system

performance
 Rewriting all or parts of the system to make it more efficient
and maintainable.
4
Importance of evolution

 Organizations have huge investments in their software

systems - they are critical business assets.
 To maintain the value of these assets to the business,
they must be changed and updated.
 The majority of the software budget in large companies
is devoted to changing and evolving existing software
rather than developing new software.

5
A spiral model of development and evolution

6
Evolution processes

 Software evolution processes depend on

 The type of software being maintained;
 The development processes used;
 The skills and experience of the people involved.
 Proposals for change are the driver for system evolution.
 Should be linked with components that are affected by the
change, thus allowing the cost and impact of the change to be
estimated.
 Change identification and evolution continues throughout
the system lifetime.

7
Change identification and evolution processes

8
The software evolution process

9
Change implementation

 Iteration of the development process where the revisions

to the system are designed, implemented and tested.
 A critical difference is that the first stage of change
implementation may involve program understanding,
especially if the original system developers are not
responsible for the change implementation.
 During the program understanding phase, you have to
understand how the program is structured, how it
delivers functionality and how the proposed change
might affect the program.

10
Change implementation

11
Urgent change requests

 Urgent changes may have to be implemented without

going through all stages of the software engineering
process
 If a serious system fault has to be repaired to allow normal
operation to continue;
 If changes to the system’s environment (e.g. an OS upgrade)
have unexpected effects;
 If there are business changes that require a very rapid response
(e.g. the release of a competing product).

12
Agile methods and evolution

 Agile methods are based on incremental development so

the transition from development to evolution is a
seamless one.
 Evolution is simply a continuation of the development process
based on frequent system releases.
 Automated regression testing is particularly valuable
when changes are made to a system.
 Changes may be expressed as additional user stories.

13
Handover problems

 Where the development team have used an agile

approach but the evolution team is unfamiliar with agile
methods and prefer a plan-based approach.
 The evolution team may expect detailed documentation to
support evolution and this is not produced in agile processes.
 Where a plan-based approach has been used for
development but the evolution team prefer to use agile
methods.
 The evolution team may have to start from scratch developing
automated tests and the code in the system may not have been
refactored and simplified as is expected in agile development.

14
Change is inevitable

 The system requirements are likely to change while the

system is being developed because the environment is
changing. Therefore a delivered system won't meet its
requirements!
 Systems are tightly coupled with their environment. when
a system is installed in an environment it changes that
environment and therefore changes the system
requirements.
 Systems MUST be changed if they are to remain useful
in an environment.

15
Software maintenance

 Modifying a program after it has been put into use.

 The term is mostly used for changing custom software.
Generic software products are said to evolve to create
new versions.
 Maintenance does not normally involve major changes to
the system’s architecture.
 Changes are implemented by modifying existing
components and adding new components to the system.

16
Software maintenance

 Many people think

 only bad software products need maintenance.
 The opposite is true:
 bad products are thrown away,
 good products are maintained and used for a long
time.
 Software products need maintenance for three reasons:
 corrective
 adaptive
 perfective 17
Types of maintenance

 Maintenance to repair software faults

 Changing a system to correct deficiencies in the way meets its
requirements.
 Maintenance to adapt software to a different operating
environment
 Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation.
 Maintenance to add to or modify the system’s
functionality
 Modifying the system to satisfy new requirements.

18
Types of maintenance

 Corrective maintenance of a software product:

 to correct bugs observed while the system is in use.
 to enhance performance of the product.
 A software product needs adaptive maintenance
(porting) when customers:
 need the product to run on new platforms,
• or, on new operating systems,
 need the product to interface with new hardware or
software.

19
Types of maintenance

 Perfective maintenance:
 to support new features required by users.
 to change some functionality
of the system due to customer demands.

Perfective
Adaptive
Corrective

20
Maintenance effort distribution

21
Maintenance costs

 Usually greater than development costs (2* to 100*

depending on the application).
 Affected by both technical and non-technical factors.
 Increases as software is maintained. Maintenance
corrupts the software structure so makes further
maintenance more difficult.
 Ageing software can have high support costs (e.g. old
languages, compilers etc.).

22
Figure 9.9Development and maintenance costs

23
Causes of Maintenance

 During development:
 Software not anticipated to last very long (e.g., Y2K
problem).
 Rate of hardware obsolescence:
 immortality of software products
 maintenance necessary for software performing low-
level functions.

24
Causes of Maintenance

 Users want existing software to run on new platforms:

 to run in new environments,
 and/or with enhanced features.
 Whenever other software it works with change:
 maintenance is needed to cope up with the newer
interface.
 For instance, a software product may need
maintenance when the operating system changes.

25
Maintenance cost factors

 Team stability
 Maintenance costs are reduced if the same staff are involved
with them for some time.
 Contractual responsibility
 The developers of a system may have no contractual
responsibility for maintenance so there is no incentive to design
for future change.
 Staff skills
 Maintenance staff are often inexperienced and have limited
domain knowledge.
 Program age and structure
 As programs age, their structure is degraded and they become
harder to understand and change.
26
Maintenance prediction

 Maintenance prediction is concerned with assessing

which parts of the system may cause problems and have
high maintenance costs
 Change acceptance depends on the maintainability of the
components affected by the change;
 Implementing changes degrades the system and reduces its
maintainability;
 Maintenance costs depend on the number of changes and costs
of change depend on maintainability.

27
Law’s of Maintenance

 There will always be a lot of old software needing

maintenance.
 Good products are maintained, bad products are thrown
away.
 Lehman’s first Law:
 “Software products must change continuously, or
become progressively less useful.”
 Lehman’s Second Law
 “When software is maintained, its structure degrades,
 unless active efforts are made to avoid this
28
phenomenon.”
Law’s of Maintenance

 Lehman’s Third Law:

 “Over a program’s life time,
 its rate of development is approximately constant.”
 All large programs will undergo significant changes
during operation phase of their life cycle,
 regardless of apriori intentions.

29
Maintenance prediction

30
Change prediction

 Predicting the number of changes requires and

understanding of the relationships between a system
and its environment.
 Tightly coupled systems require changes whenever the
environment is changed.
 Factors influencing this relationship are
 Number and complexity of system interfaces;
 Number of inherently volatile system requirements;
 The business processes where the system is used.

31
System re-engineering

 Re-structuring or re-writing part or all of a legacy system

without changing its functionality.
 Applicable where some but not all sub-systems of a
larger system require frequent maintenance.
 Re-engineering involves adding effort to make them
easier to maintain. The system may be re-structured and
re-documented.

32
Advantages of reengineering

 Reduced risk
 There is a high risk in new software development. There may be
development problems, staffing problems and specification
problems.
 Reduced cost
 The cost of re-engineering is often significantly less than the
costs of developing new software.

33
The reengineering process

34
Reengineering process activities

 Source code translation

 Convert code to a new language.
 Reverse engineering
 Analyse the program to understand it;
 Program structure improvement
 Restructure automatically for understandability;
 Program modularisation
 Reorganise the program structure;
 Data reengineering
 Clean-up and restructure system data.

35
Figure 9.12 Reengineering approaches

36
Reengineering cost factors

 The quality of the software to be reengineered.

 The tool support available for reengineering.
 The extent of the data conversion which is required.
 The availability of expert staff for reengineering.
 This can be a problem with old systems based on technology
that is no longer widely used.

37
Preventative maintenance by refactoring

 Refactoring is the process of making improvements to a

program to slow down degradation through change.
 You can think of refactoring as ‘preventative
maintenance’ that reduces the problems of future
change.
 Refactoring involves modifying a program to improve its
structure, reduce its complexity or make it easier to
understand.
 When you refactor a program, you should not add
functionality but rather concentrate on program
improvement.
38
Refactoring and reengineering

 Re-engineering takes place after a system has been

maintained for some time and maintenance costs are
increasing. You use automated tools to process and re-
engineer a legacy system to create a new system that is
more maintainable.
 Refactoring is a continuous process of improvement
throughout the development and evolution process. It is
intended to avoid the structure and code degradation
that increases the costs and difficulties of maintaining a
system.

39
‘Bad smells’ in program code

 Duplicate code
 The same or very similar code may be included at different
places in a program. This can be removed and implemented as a
single method or function that is called as required.
 Long methods
 If a method is too long, it should be redesigned as a number of
shorter methods.
 Switch (case) statements
 These often involve duplication, where the switch depends on
the type of a value. The switch statements may be scattered
around a program. In object-oriented languages, you can often
use polymorphism to achieve the same thing.

40
‘Bad smells’ in program code

 Data clumping
 Data clumps occur when the same group of data items (fields in
classes, parameters in methods) re-occur in several places in a
program. These can often be replaced with an object that
encapsulates all of the data.
 Speculative generality
 This occurs when developers include generality in a program in
case it is required in the future. This can often simply be
removed.

41
Major Maintenance Problems

 Unstructured code (bad programs)

 Maintenance programmers have:
 insufficient knowledge of the system or the application
domain.
 Software maintenance has a bad image.
 Documentation absent, out of date, or insufficient.
 Maintenance team is usually different from development
team.
 even after reading all documents
• it is very difficult to understand why a thing was done in
a certain way.
 Also there is a limit to the rate at which a person can study
documents
• and extract relevant information 42
Maintenance Nightmares

 Use of gotos
 Lengthy procedures
 Poor and inconsistent naming
 Poor module structure
 Weak cohesion and high coupling
 Deeply nested conditional statements
 Functions having side effects

43
Maintenance activities

 Two types of activities:

 Productive activities:
• modification of analysis, design, coding, etc.
 Non-productive activities:
• understanding system design, code, etc

44
Software Maintenance Process Models

 Maintenance activities are not unique:

 depend on the extent of modifications required,
 also, depend on condition of the product:
• how structured it is,
• how well documented it is, etc.

45
Software Maintenance Process Model - 1

 When the required changes are small and simple:

 the code can be directly modified
 changes reflected in all relevant documents.
 more elaborate activities are required when required
changes are not trivial.
Gather Change Requirements

Analyze Change Requirements

Devise Code Change Strategies

Apply Code Change Strategies

Update Documents Integrate and Test 46

Software Maintenance Process Model - 2

 For complex maintenance projects, software

reengineering needed:
 a reverse engineering cycle followed by a forward
engineering cycle.
 with as much reuse as possible from existing code
and other documents.
 Preferable when:
 amount of rework is significant
 software has poor structure.
 Can be represented by a reverse engineering cycle:
 followed by a forward engineering cycle. 47
Software Reengineering Process Model

Change Requirements

Requirements New Requirements

Specification Specification

Design Design

Code Code

48
Software Reengineering

 Advantages of reengineering:
 produces better design than the original product,
 produces required documents,
 often results in higher efficiency.
 Efficiency improvements are brought about by better
design.
 However, this approach is more costly than the first
approach.
 An empirical study indicates:
 process 1 is preferable when amount of rework is no
more than 15%. 49
Software Reengineering

 Reengineering is preferable when:

 amount of rework is high,
 product exhibits high failure rate.
 product difficult to understand.

50
Activity: System evolution

 What is the most appropriate

strategy for evolving
systems (9,10) if off the shelf
system is available at a
reasonable cost is:
1. Scrap the system completely
2. Leave the system
unchanged and continue
with regular maintenance
3. Reengineer the system to
improve its maintainability
4. Replace all or part of the
system with new system

51
Key points

 Software development and evolution can be thought of

as an integrated, iterative process that can be
represented using a spiral model.
 For custom systems, the costs of software maintenance
usually exceed the software development costs.
 The process of software evolution is driven by requests
for changes and includes change impact analysis,
release planning and change implementation.
 There are 3 types of software maintenance, namely bug
fixing, modifying software to work in a new environment,
and implementing new or changed requirements.
52
Configuration Management

1
Topics covered

 Change management
 Version management
 System building
 Release management

2
Configuration management

 Because software changes frequently, systems, can be

thought of as a set of versions, each of which has to be
maintained and managed.
 Versions implement proposals for change, corrections of
faults, and adaptations for different hardware and
operating systems.
 Configuration management (CM) is concerned with the
policies, processes and tools for managing changing
software systems. You need CM because it is easy to
lose track of what changes and component versions
have been incorporated into each system version.

3
CM activities

 Change management
 Keeping track of requests for changes to the software from customers
and developers, working out the costs and impact of changes, and
deciding the changes should be implemented.
 Version management
 Keeping track of the multiple versions of system components and
ensuring that changes made to components by different developers do
not interfere with each other.
 System building
 The process of assembling program components, data and libraries,
then compiling these to create an executable system.
 Release management
 Preparing software for external release and keeping track of the system
versions that have been released for customer use.
4
Configuration management activities

5
CM terminology

Term Explanation

Configuration item or Anything associated with a software project (design, code, test data,
software configuration document, etc.) that has been placed under configuration control. There are
item (SCI) often different versions of a configuration item. Configuration items have a
unique name.
Configuration control The process of ensuring that versions of systems and components are
recorded and maintained so that changes are managed and all versions of
components are identified and stored for the lifetime of the system.
Version An instance of a configuration item that differs, in some way, from other
instances of that item. Versions always have a unique identifier, which is
often composed of the configuration item name plus a version number.
Baseline A baseline is a collection of component versions that make up a system.
Baselines are controlled, which means that the versions of the components
making up the system cannot be changed. This means that it should
always be possible to recreate a baseline from its constituent components.
Codeline A codeline is a set of versions of a software component and other
configuration items on which that component depends.

6
CM terminology

Term Explanation
Mainline A sequence of baselines representing different versions of a
system.
Release A version of a system that has been released to customers (or
other users in an organization) for use.
Workspace A private work area where software can be modified without
affecting other developers who may be using or modifying that
software.
Branching The creation of a new codeline from a version in an existing
codeline. The new codeline and the existing codeline may then
develop independently.
Merging The creation of a new version of a software component by merging
separate versions in different codelines. These codelines may have
been created by a previous branch of one of the codelines
involved.
System building The creation of an executable system version by compiling and
linking the appropriate versions of the components and libraries
making up the system.
7
Change management

 Organizational needs and requirements change during

the lifetime of a system, bugs have to be repaired and
systems have to adapt to changes in their environment.
 Change management is intended to ensure that system
evolution is a managed process and that priority is given
to the most urgent and cost-effective changes.
 The change management process is concerned with
analyzing the costs and benefits of proposed changes,
approving those changes that are worthwhile and
tracking which components in the system have been
changed.

8
The change management process

9
A partially completed change request form (a)

Change Request Form

Project: SICSA/AppProcessingNumber: 23/02

Change requester: I. SommervilleDate: 20/01/09
Requested change: The status of applicants (rejected, accepted, etc.) should be
shown visually in the displayed list of applicants.

Change analyzer: R. LooekAnalysis date: 25/01/09

Components affected: ApplicantListDisplay, StatusUpdater

Associated components: StudentDatabase

10
A partially completed change request form (b)

Change Request Form

Change assessment: Relatively simple to implement by changing the display

color according to status. A table must be added to relate status to colors. No
changes to associated components are required.

Change priority: Medium

Change implementation:
Estimated effort: 2 hours
Date to SGA app. team: 28/01/09 CCB decision date: 30/01/09
Decision: Accept change. Change to be implemented in Release 1.2
Change implementor: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments:

11
Factors in change analysis

 The consequences of not making the change

 The benefits of the change
 The number of users affected by the change
 The costs of making the change
 The product release cycle

12
Change management and agile methods

 In some agile methods, customers are directly involved

in change management.
 The propose a change to the requirements and work
with the team to assess its impact and decide whether
the change should take priority over the features planned
for the next increment of the system.
 Changes to improve the software improvement are
decided by the programmers working on the system.
 Refactoring, where the software is continually improved,
is not seen as an overhead but as a necessary part of
the development process.
13
Derivation history

// SICSA project (XEP 6087)

//
// APP-SYSTEM/AUTH/RBAC/USER_ROLE
//
// Object: currentRole
// Author: R. Looek
// Creation date: 13/11/2009
//
// © St Andrews University 2009
//
// Modification history
// Version Modifier Date Change Reason
// 1.0 J. Jones 11/11/2009 Add header Submitted to CM
// 1.1 R. Looek 13/11/2009 New field Change req. R07/02

14
Version management

 Version management (VM) is the process of keeping

track of different versions of software components or
configuration items and the systems in which these
components are used.
 It also involves ensuring that changes made by different
developers to these versions do not interfere with each
other.
 Therefore version management can be thought of as the
process of managing codelines and baselines.

15
Codelines and baselines

 A codelineis a sequence of versions of source code with

later versions in the sequence derived from earlier
versions.
 Codelinesnormally apply to components of systems so
that there are different versions of each component.
 A baseline is a definition of a specific system.
 The baseline therefore specifies the component versions
that are included in the system plus a specification of the
libraries used, configuration files, etc.

16
Codelinesand baselines

17
Baselines

 Baselines may be specified using a configuration

language, which allows you to define what components
are included in a version of a particular system.
 Baselines are important because you often have to
recreate a specific version of a complete system.
 For example, a product line may be instantiated so that there are
individual system versions for different customers. You may have
to recreate the version delivered to a specific customer if, for
example, that customer reports bugs in their system that have to
be repaired.

18
Version management systems

 Version and release identification

 Managed versions are assigned identifiers when they are
submitted to the system.
 Storage management
 To reduce the storage space required by multiple versions of
components that differ only slightly, version management
systems usually provide storage management facilities.
 Change history recording
 All of the changes made to the code of a system or component
are recorded and listed.

19
Version management systems

 Independent development
 The version management system keeps track of components
that have been checked out for editing and ensures that changes
made to a component by different developers do not interfere.
 Project support
 A version management system may support the development of
several projects, which share components.

20
Storage management using deltas

21
Check-in and check-out from a version
repository

22
Codeline branches

 Rather than a linear sequence of versions that reflect

changes to the component over time, there may be
several independent sequences.
 This is normal in system development, where different
developers work independently on different versions of the
source code and so change it in different ways.
 At some stage, it may be necessary to merge codeline
branches to create a new version of a component that
includes all changes that have been made.
 If the changes made involve different parts of the code, the
component versions may be merged automatically by combining
the deltas that apply to the code.

23
Branching and merging

24
System building

 System building is the process of creating a complete,

executable system by compiling and linking the system
components, external libraries, configuration files, etc.
 System building tools and version management tools
must communicate as the build process involves
checking out component versions from the repository
managed by the version management system.
 The configuration description used to identify a baseline
is also used by the system building tool.

25
Build platforms

 The development system, which includes development

tools such as compilers, source code editors, etc.
 Developers check out code from the version management
system into a private workspace before making changes to the
system.
 The build server, which is used to build definitive,
executable versions of the system.
 Developers check-in code to the version management system
before it is built. The system build may rely on external libraries
that are not included in the version management system.
 The target environment, which is the platform on which
the system executes.
26
Development, build, and target platforms

27
Reserve and Restore Operation in CC

28
SCCS and RCS

 Source Code Control System (SCCS) and Revision

Control System (RCS) are two popular configuration
management tools available on most UNIX systems.
 SCCS or RCS can be used for controlling and managing
different versions of text files.
 SCCS and RCS do not handle binary files (i.e.
executable files, documents, files containing diagrams,
etc.)
 SCCS and RCS provide an efficient way of storing
versions that minimizes the amount of occupied disk
space.
29
SCCS and RCS

 Suppose, a module MOD is present in three versions

MOD1.1, MOD1.2, and MOD1.3.
 Then, SCCS and RCS stores the original module
MOD1.1 together with changes needed to transform
MOD1.1 into MOD1.2 and MOD1.2 to MOD1.3.
 The changes needed to transform each base lined file to
the next version are stored and are called deltas.
 The main reason behind storing the deltas rather than
storing the full version files is to save disk space.

30
System building

31
Build system functionality

 Build script generation

 Version management system integration
 Minimal re-compilation
 Executable system creation
 Test automation
 Reporting
 Documentation generation

32
Minimizing recompilation

 Tools to support system building are usually designed to

minimize the amount of compilation that is required.
 They do this by checking if a compiled version of a
component is available. If so, there is no need to
recompile that component.
 A unique signature identifies each source and object
code version and is changed when the source code is
edited.
 By comparing the signatures on the source and object
code files, it is possible to decide if the source code was
used to generate the object code component.
33
File identification

 Modification timestamps
 The signature on the source code file is the time and date when
that file was modified. If the source code file of a component has
been modified after the related object code file, then the system
assumes that recompilation to create a new object code file is
necessary.
 Source code checksums
 The signature on the source code file is a checksum calculated
from data in the file. A checksum function calculates a unique
number using the source text as input. If you change the source
code (even by 1 character), this will generate a different
checksum. You can therefore be confident that source code files
with different checksums are actually different.

34
Timestamps vs checksums

 Timestamps
 Because source and object files are linked by name rather than
an explicit source file signature, it is not usually possible to build
different versions of a source code component into the same
directory at the same time, as these would generate object files
with the same name.
 Checksums
 When you recompile a component, it does not overwrite the
object code, as would normally be the case when the timestamp
is used. Rather, it generates a new object code file and tags it
with the source code signature. Parallel compilation is possible
and different versions of a component may be compiled at the
same time.

35
Agile building

 Check out the mainline system from the version

management system into the developer’s private
workspace.
 Build the system and run automated tests to ensure that
the built system passes all tests. If not, the build is
broken and you should inform whoever checked in the
last baseline system. They are responsible for repairing
the problem.
 Make the changes to the system components.
 Build the system in the private workspace and rerun
system tests. If the tests fail, continue editing.
36
Agile building

 Once the system has passed its tests, check it into the
build system but do not commit it as a new system
baseline.
 Build the system on the build server and run the tests.
You need to do this in case others have modified
components since you checked out the system. If this is
the case, check out the components that have failed and
edit these so that tests pass on your private workspace.
 If the system passes its tests on the build system, then
commit the changes you have made as a new baseline
in the system mainline.

37
Continuous integration

38
Daily building

 The development organization sets a delivery time (say

2 p.m.) for system components.
 If developers have new versions of the components that they are
writing, they must deliver them by that time.
 A new version of the system is built from these components by
compiling and linking them to form a complete system.
 This system is then delivered to the testing team, which carries
out a set of predefined system tests
 Faults that are discovered during system testing are documented
and returned to the system developers. They repair these faults
in a subsequent version of the component.

39
Release management

 A system release is a version of a software system that

is distributed to customers.
 For mass market software, it is usually possible to
identify two types of release: major releases which
deliver significant new functionality, and minor releases,
which repair bugs and fix customer problems that have
been reported.
 For custom software or software product lines, releases
of the system may have to be produced for each
customer and individual customers may be running
several different releases of the system at the same
time.
40
Release tracking

 In the event of a problem, it may be necessary to

reproduce exactly the software that has been delivered
to a particular customer.
 When a system release is produced, it must be
documented to ensure that it can be re-created exactly in
the future.
 This is particularly important for customized, long-lifetime
embedded systems, such as those that control complex
machines.
 Customers may use a single release of these systems for many
years and may require specific changes to a particular software
system long after its original release date.
41
Release reproduction

 To document a release, you have to record the specific

versions of the source code components that were used
to create the executable code.
 You must keep copies of the source code files,
corresponding executables and all data and
configuration files.
 You should also record the versions of the operating
system, libraries, compilers and other tools used to build
the software.

42
Release planning

 As well as the technical work involved in creating a

release distribution, advertising and publicity material
have to be prepared and marketing strategies put in
place to convince customers to buy the new release of
the system.
 Release timing
 If releases are too frequent or require hardware upgrades,
customers may not move to the new release, especially if they
have to pay for it.
 If system releases are too infrequent, market share may be lost
as customers move to alternative systems.

43
Release components

 As well as the the executable code of the system, a

release may also include:
 configuration files defining how the release should be configured
for particular installations;
 data files, such as files of error messages, that are needed for
successful system operation;
 an installation program that is used to help install the system on
target hardware;
 electronic and paper documentation describing the system;
 packaging and associated publicitythat have been designed for
that release.

44
Factors influencing system release planning

Factor Description
Technical quality of If serious system faults are reported which affect the way in
the system which many customers use the system, it may be
necessary to issue a fault repair release. Minor system
faults may be repaired by issuing patches (usually
distributed over the Internet) that can be applied to the
current release of the system.
Platform changes You may have to create a new release of a software
application when a new version of the operating system
platform is released.
Lehman’s fifth law This ‘law’ suggests that if you add a lot of new functionality
(see Chapter 9) to a system; you will also introduce bugs that will limit the
amount of functionality that may be included in the next
release. Therefore, a system release with significant new
functionality may have to be followed by a release that
focuses on repairing problems and improving performance.

45
Factors influencing system release planning

Factor Description
Competition For mass-market software, a new system release may be
necessary because a competing product has introduced
new features and market share may be lost if these are not
provided to existing customers.
Marketing The marketing department of an organization may have
requirements made a commitment for releases to be available at a
particular date.
Customer change For custom systems, customers may have made and paid
proposals for a specific set of system change proposals, and they
expect a system release as soon as these have been
implemented.

46