Giáo trình Kỹ nghệ phần mềm - Quản lý cấu hình phần mềm

e properly applied.
• Plan and distribute new system releases.
Versions/variants/releases
• Version An instance of a system which is 
functionally distinct in some way from other 
system instances.
• Variant An instance of a system which is 
functionally identical but non-functionally 
distinct from other instances of a system.
• Release An instance of a system which is 
distributed to users outside of the 
development team.
Version identification
• Procedures for version identification should 
define an unambiguous way of identifying 
component versions.
• There are three basic techniques for 
component identification
– Version numbering;
– Attribute-based identification;
– Change-oriented identification.
Version numbering
• Simple naming scheme uses a linear 
derivation 
– V1, V1.1, V1.2, V2.1, V2.2 etc.
• The actual derivation structure is a tree or a 
network rather than a sequence.
• Names are not meaningful. 
• A hierarchical naming scheme leads to fewer 
errors in version identification. 
Version derivation structure
Attribute-based identification
• Attributes can be associated with a version with 
the combination of attributes identifying that 
version
– Examples of attributes are Date, Creator, 
Programming Language, Customer, Status etc.
• This is more flexible than an explicit naming scheme 
for version retrieval; However, it can cause problems 
with uniqueness - the set of attributes have to be 
chosen so that all versions can be uniquely identified.
• In practice, a version also needs an associated name 
for easy reference.
Attribute-based queries
• An important advantage of attribute-based 
identification is that it can support queries so 
that you can find ‘the most recent version in 
Java’ etc.
• The query selects a version depending on 
attribute values
– AC3D (language =Java, platform = XP, date = Jan 
2003).
Change-oriented identification
• Integrates versions and the changes made to create 
these versions.
• Used for systems rather than components.
• Each proposed change has a change set that 
describes changes made to implement that change.
• Change sets are applied in sequence so that, in 
principle, a version of the system that incorporates 
an arbitrary set of changes may be created.
Release management
• Releases must incorporate changes forced on 
the system by errors discovered by users and 
by hardware changes.
• They must also incorporate new system 
functionality.
• Release planning is concerned with when to 
issue a system version as a release.
System releases
• Not just a set of executable programs.
• May also include:
– Configuration files defining how the release is configured for a 
particular installation;
– Data files needed for system operation;
– An installation program or shell script to install the system on target 
hardware;
– Electronic and paper documentation;
– Packaging and associated publicity.
• Systems are now normally released on optical disks (CD or 
DVD) or as downloadable installation files from the web.
Release problems
• Customer may not want a new release of the 
system
– They may be happy with their current system as 
the new version may provide unwanted 
functionality. 
• Release management should not assume that 
all previous releases have been accepted. All 
files required for a release should be re-
created when a new release is installed.
Release decision making
• Preparing and distributing a system release is 
an expensive process.
• Factors such as the technical quality of the 
system, competition, marketing requirements 
and customer change requests should all 
influence the decision of when to issue a new 
system release.
System release strategy
Factor Description
Technical quality of
the system
If serious system faults are reported which affect the way in which
many customers use the system, it may be necessary to issue a fault
repair release. However, minor system faults may be repaired by issuing
patches (often 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
(see Chapter 21)
This suggests that the increment of functionality that is included in each
release is approximately constant. Therefore, if there has been a system
release with significant new functionality, then it may have to be
followed by a repair release.
Competition A new system release may be necessary because a competing product is
available.
Marketing
requirements
The marketing department of an organisation may have made a
commitment for releases to be available at a particular date.
Customer change
proposals
For customised systems, customers may have made and paid for a
specific set of system change proposals and they expect a system release
as soon as these have been implemented.
Release creation
• Release creation involves collecting all files 
and documentation required to create a 
system release.
• Configuration descriptions have to be written 
for different hardware and installation scripts 
have to be written.
• The specific release must be documented to 
record exactly what files were used to create 
it. This allows it to be re-created if necessary.
System building
• The process of compiling and linking software 
components into an executable system.
• Different systems are built from different 
combinations of components.
• This process is now always supported by 
automated tools that are driven by ‘build 
scripts’.
System building problems
• Do the build instructions include all required 
components?
– When there are many hundreds of components making up 
a system, it is easy to miss one out. This should normally 
be detected by the linker.
Is the appropriate component version •
specified?
– A more significant problem. A system built with the wrong 
version may work initially but fail after delivery.
• Are all data files available?
– The build should not rely on 'standard' data files. Standards 
vary from place to place.
System building problems
• Are data file references within components 
correct?
– Embedding absolute names in code almost always causes 
problems as naming conventions differ from place to place.
• Is the system being built for the right platform
– Sometimes you must build for a specific OS version or hardware 
configuration.
• Is the right version of the compiler and other 
software tools specified?
– Different compiler versions may actually generate different code and 
the compiled component will exhibit different behaviour.
System building
CASE tools for CM
• CM processes are standardised and involve 
applying pre-defined procedures.
• Large amounts of data must be managed.
• CASE tool support for CM is therefore 
essential.
• Mature CASE tools to support configuration 
management are available ranging from 
stand-alone tools to integrated CM 
workbenches.
CM workbenches
• Open workbenches
– Tools for each stage in the CM process are 
integrated through organisational procedures and 
scripts. Gives flexibility in tool selection.
• Integrated workbenches
– Provide whole-process, integrated support for 
configuration management. More tightly 
integrated tools so easier to use. However, the 
cost is less flexibility in the tools used.
Change management tools
• Change management is a procedural process so it can be 
modelled and integrated with a version management system.
• Change management tools
– Form editor to support processing the change request forms;
– Workflow system to define who does what and to automate 
information transfer;
– Change database that manages change proposals and is linked to a VM 
system;
– Change reporting system that generates management reports on the 
status of change requests.
Version management tools
• Version and release identification
– Systems assign identifiers automatically when a new version is submitted to 
the system.
• Storage management.
– System stores the differences between versions rather than all the version 
code.
• Change history recording
– Record reasons for version creation.
• Independent development 
– Only one version at a time may be checked out for change. Parallel working on 
different versions.
• Project support
– Can manage groups of files associated with a project rather than just single 
files.
Delta-based versioning
System building
• Building a large system is computationally 
expensive and may take several hours.
• Hundreds of files may be involved.
• System building tools may provide
– A dependency specification language and 
interpreter;
– Tool selection and instantiation support;
– Distributed compilation;
– Derived object management.
Component dependencies
Key points
• Configuration management is the management of 
system change to software products.
• A formal document naming scheme should be 
established and documents should be managed in a 
database.
• The configuration data base should record 
information about changes and change requests.
• A consistent scheme of version identification should 
be established using version numbers, attributes or 
change sets.
Key points
• System releases include executable code, data, 
configuration files and documentation.
• System building involves assembling components 
into a system.. 
• CASE tools are available to support all CM activities
• CASE tools may be stand-alone tools or may be 
integrated systems which integrate support for 
version management, system building and change 
management.
Bài tập về nhà
• Tìm một công cụ quản lý phiên bản và học
cách sử dụng các chức năng chính của nó
– Tham khảo
• 
control_software
–Mô tả cách sử dụng hai chức năng cơ bản: 
checkout, commit, update