oht 18.1 galin, sqa from theory to implementation © pearson education limited 2004 chapter 18...

OHT 18.1

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Chapter 18

Configuration Management

OHT 18.2


• “What is the correct version of the software module that I have to continue its coding?”

• “Who can provide me with an accurate copy of the last year’s version 4.1 of the TMY software package?”

• “What version of the design document matches the software version we are adapting to a new customer?”

• “What version of the software system is installed at ABC Industries?”• “What changes have been introduced in the version installed at the

ABC Industries’ site?”• “What changes have been introduced in the new version of the

software?”• “Where can I find the full list of customers that use version 6.8 of our

software?”• “Can we be sure that the version installed at Top Com Ltd. does not

include undocumented changes?” • “Where can I find the full list of customers that use version 6.8 of our

software?”• “Can we be sure that the version installed at Top Com Ltd does not

include undocumented changes and changes that have not been approved??

The Need for Configuration Management

OHT 18.3


Introduction• Typically, active software systems are always in a state of flux.

• Changes are the name of the game

• Often hundreds of changes (some small, some not) annually!

• Need to be able to answer aforementioned questions!

• Note: all users of your software may NOT be using the same version!

• Must have quality assurance of all changes.• Documented and released versions and installed versions by various

users.

• Recognize that software systems must be maintained over years!

• This is where companies make their money!

OHT 18.4


Introduction• Software Configuration Management (SCM) is a component

of SQA.• SCM deals with issues related to control of software changes,

proper documentation of changes, registering and storing the approved software versions, tracking registered versions and more throughout the software system’s life cycle.

• SCM is covered in ISO 9000-3 standards as well as in CMM Guidelines among other standards!

• We will spend time on CMM (Capability Maturity Model) and ISO (International Standards Organization).

OHT 18.5


Introduction• Upon completing this chapter, you should be able to:

• Define the concept software configuration version.

• Explain the objectives of software configuration management

• Explain the objectives of software change management

• Explain the difference between baseline and intermediate software configuration versions

• Explain the objectives of software configuration management plans

• Explain the nature of the tasks fulfilled by software configuration management audits.

• These are very important concepts to computing professionals!

OHT 18.6


Software Configuration Item (SCI) An approved unit of software code, a document or piece of

hardware that is designed for configuration management and treated as a distinct entity in the software configuration management process.

Software Configuration Item Version (SCI version)The approved state of an SCI at any given point of time during the

development or maintenance process Software Configuration VersionAn approved selected set of documented SCI versions, that

constitute a software system or document at a given point of time, where the activities to be performed are controlled by software configuration management procedures.

OHT 18.7


Almost anything can be a software configuration item.These are ‘things’ we want to keep track of and control/Examples: (normally placed into classes of configured SCIs)Design documents (development plans, requirements doc, preliminary design,

interface design, database description, software test plan, software test procedures, software test reports, software user manuals, software maintenance manuals. Software installation plans, software change requests, software maintenance requests (including problem reports)

Software code * Source code * Object code * Prototype software Data files * Test cases and test scripts * Parameters, codes, etc.Software development tools (the versions applied in the development and

maintenance stages) * Compilers and debuggers * Application generators * CASE tools

OHT 18.8


SCI Version

PMT Version 6.0 January 6, 2002

SCI Version in the Release

PMT Version 7.0 January 22, 2003

SCI Version in the Release

SRD Ver. 1 Ver. 1

CDD Ver. 3 Ver. 4

STP Ver. 3 Ver. 4

SIP Ver. 2 Ver. 2

VDD Ver. 6 Ver. 7

Code Module 1 Ver. 3 Ver. 5



Test cases file Ver. 3 Ver. 4

CL compiler Ver. 5 Ver. 7

Software user manual Ver. 6 Ver. 7

Release and release date

Example of two softwre configuration versions and theSCIs included in each one.

Why do you think we have these various version that must be maintained, documented, configured, etc???

OHT 18.9


An SQA component responsible for applying (computerized and non-computerized) technical tools and administrative procedures that enable completion of the tasks required to maintain SCIs and software configuration versions.

OHT 18.10


Components used to control software configurations are usually divided into groups of software capabilities:

*** Control Software Change

*** Release of SCI and Software Configuration Versions

*** Provision of SCM Information Services

*** Verification of compliance to SCM procedures

OHT 18.11


Tasks of Software Configuration Management (more)

Let’s consider only Software Change Control as an example:

• grant approval to carry out changes

• control the changes and assure the quality of approved changes

• document the approved changes

• apply mechanisms that coordinate the changes made to the SCI by preventing more than one item from

simultaneously introducing changes into the same SCI

• Can readily see this is really software management!

OHT 18.12


So who oversees implementation of these tasks during software development and/or maintenance?

Usually assigned to senior people or a committee responsible for SCM issues.

Software Change Control is also usually done by committee, sometimes called a software change control board, or software change authority.

If during development, the project manager may be charged with authority to carry these things out.

OHT 18.13


Factors to be Considered as to whether to implement the Change:

* Expected contribution of the proposed change

* Urgency of the change * Effect of the proposed change on project

timetables, level of service, etc. * Efforts required in making the change

operational * Required software quality assurance efforts * Estimated required professional resources

and cost of performing the change

OHT 18.14


More FactsAbsolutely tru that once any baseline (or initial version) is installed,

changes will begin to flow rapidly!

To control change, we need a coordinated effort by an authorized body to ensure changes follow project or customer priorities

Those factors (previous slide) must be considered!

Despite perceived urgency, changes are not necessarily always approved!

Must ensure high quality of each changed SCI, and

Must ensure high quality of the entire new version that includes the changes SCIs.

OHT 18.15


So, why do we release new versions of software?

1. Defective SCIs2. Special features demanded by new customers3. Team’s initiatives to introduce SCI

improvements

OHT 18.16


Three Main Types of Releases:

1. Baseline versions

2. Intermediate versions, and

3. Revisions

They are all quite different and serve different needs.

OHT 18.17


Baseline Versions

• These are the bigges.

• Planned early

• Reviewed, tested, and approved with all their SCIs too.

• These are milestone in the software system’s life cycle.

• These are the major releases!

• Usually have major changes or upgrades or enhancements.

OHT 18.18


Intermediate Versions• Usually designed to address immediate problems as to correct

defects in an important SCI or to include an immediate adaptations for a new customer.

• This is an intermediate version of the software.

• May be done to serve only a small segment of the firm’s clients; perhaps for a limited period until a new baseline is developed.

• Does not receive the detailed attention of baselines.

• Realize that all clients may not be using the same version of software!! Oftentimes this is the case.

OHT 18.19


Revisions

• Minor changes and corrections.

• May include several small changes in a revision

• Sometimes we have several small revisions prior to a major baseline release..

• Examples: documentation errors; no show stoppers.

OHT 18.20


Numbering and Plans

• Major baselines (and major SCIs) have whole numbers, such as1.0 or 2.0.

• Note: SCIs have their own numbering system too.

• We have version and revision numbers, as in 2.3

OHT 18.21


Why needed? (Book)

Main objective of an SCMP is to plan ahead the schedule for baseline version releases and the required resources to carry out all the activities required for the software configuration releases.

An additional objective is to enable one to follow up the progress of activities involved in software version release.

SCMP are needed for development as well as operations (maintenance).

OHT 18.22


The plan includes:* A list of scheduled baseline version releases.* A list of SCIs (documents, code, etc.) to be included in each

version.*A table identifying the relationship of software development

project plans and maintenance plans to scheduled releases of new SCIs or SCI versions.

*A list of assumptions about the resources required to perform the SCMP.

* Estimates of the human resources and budget needed to perform the SCMP.

OHT 18.23


SCMP for Development• Based on the project plan, the SCMP sets the release dates of

baseline versions, which usually coincide with the conclusion of one or more of the following three events:• The design stage

• The coding stage

• The system test stage.

• All of the instructions and procedures necessary for performing SCM tasks at this stage are documented in the SCMP.

• The project manager is usually the person responsible for carrying out these tasks.

OHT 18.24


SCMP for Maintenance• During maintenance, further releases of baseline versions are

necessary to deploy imporved software versions after accumulation of SCI changes made during regular customer use.

• Often, the releases are annual, semi-annually, or according to the anticipated number of accumulated changes in SCIs.

• Periodic releases contain corrections as well as new versions of SCIs.• As in development plans, all the instructions and procedures for

performing SCM tsks during operations / maintenance are likewise documented in the respective SCMP.

• Maintenance SCMPs may be incorporated in the comprehensive SCMP for the system’s entire life cycle..

OHT 18.25


Documentation of Software Configuration Versions

• It is the responsibility of the project manager to ensure all of the documentation tasks are performed.

• This includes documentation of the SCI versions and documentation of the software configuration releases (versions and revisions)

• Lots of detailed information must be accommodated.

• Frame 18.5 in your book lists those documentation items required for SCIs.

• Frame 18.6 (next slides) presents those information items needed in software configuration releases.

• These are often referred to as Version Description Documents:

OHT 18.26


a. Identification and installations*Release version and revision number, including date* List of installations where the release was installed

b. Configuration of the released versionList of SCIs (including SCI’s version) in the released software version* List of hardware configuration items required for operating the specified version

List of interfacing software and hardware systems* Installation instructions for the new release

(Honeywell 6080s, 6060s, at different sites….)

OHT 18.27


C. Changes in the new version* Previous software configuration version* List of SCIs that have been changed, new SCIs, and deleted SCIs* Short description of introduced changes. (may be defects)* Operational and other implications of changes in the release.

D. Further development issues* List of software system problems that have not been solved in the new version.* List of delayed SCRs and proposals for development of the software system.

OHT 18.28


Need to provide information to professionals (developers and maintainers and customers who have requested the changes.

Information related to software change control:* Change request status information (decisions made)

* Change order progress information (order for changes, schedule, implementation progress and test results; info on delays too, perhaps)

OHT 18.29


Need to provide information to professionals (developers and maintainers and customers who have requested the changes.

Information about SCIs and software configuration versions:* Accurate copies of SCI versions (code SCIs, document SCIs, etc.) and entire software configuration versions.

* Full reports of changes between successive releases (versions and/or revisions) of code SCIs and between successive releases of other types of SCIs.

* Copies of SCI version documentation and software configuration version documentation (VDDs).

* Detailed version and revision history for SCIs and software configurations.

* Progress information about planned versions and releases

* Information correlated about versions installed at a given site and about the site itself.

* List where a given software configuration version is installed.

SCM Information Services

OHT 18.30


Audits and Accountability• It is all about accountability.

• There’s a great variety of tasks by the SCM authority and the Change Control Board (CCB)

• There will be audits to ensure SCM procedures have been followed and that internal quality issues have been adhered to.

• Samples of change requests, SCIs, and software configuration versions will be carefully audited.

• This is part of software development that developers and maintainers do not like, but it is necessary!

OHT 18.31


Some Sample Audit Items:

1. Percentage of unapproved changes introduced in the system during development

2. Percentage of SCOs not carried out according to instructions and not fully complying with procedures

3. Percentage of design reviews and softwre tests of changed SCIs that have not been performed according to the relevant procedures

4. Percentage of SCOs that have been completed on schedule.

5. Percentages of properly documented new SCIs and software configuration versions.

6. Percentage of cases of failure to transmit all version-related information to the customer

7. More

OHT 18.32


Homework – Chapter 18

Individually, you are to develop answers to the following questions and submit for grading via Blackboard Assignment.

Question 18.4

Question 18.6

OHT 18.33


Team Assignment

Question 18.2 (1) and (2)

Question 18.4

Question 18.6

oht 18.1 galin, sqa from theory to implementation © pearson education limited 2004 chapter 18...

Documents

software module

control of software

approved software versions

active software systems

tmy software package

configuration management

years version

new version