SE351a: Software Project & Process Management -...

6 Dec., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management

W12: Software Configuration Management

6 Dec., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

SE351 RoadmapSE351 Roadmap

Introduction to Software Project Management

Project Management

Software Development Life Cycles

Requirements Engineering

Software Process & Project Metrics

Software Project Planning

Project Monitoring & Control

Risk Management

Software Quality Assurance

Software Configuration Management


CMM L2: Key Process AreasCMM L2: Key Process Areas

2.1 Requirements management

2.2 Software project planning & control

2.3 Software subcontract management

2.4 Software quality assurance

> 2.5 Software configuration management

Ad hoc

Project Management


The Software ConfigurationThe Software Configuration

programsprograms documentsdocuments

datadataThe artifactsThe artifacts

• Software configurationthe items that comprise all information producedas part of the software engineering process

Software configuration items (SCI) o artifacts produced during the process


Software Configuration ItemsSoftware Configuration Items

1. System specification

2. Software project plan

3. (i) software requirements specification(ii) prototype

4. Preliminary user manual

5. Design specification(i) Preliminary design(ii) Detail design

6. Source code listing

7. (i) Test plan and procedure(ii) Test cases and recorded results

8. Operation and installation manuals

9. Executable programs

10. As-built user manual

11. Maintenance documents(i) Software problem reports(ii) Maintenance requests(iii) Engineering change orders

12. Standards and proceduresfor software engineering


No matter where you are in the system lifecycle, the system will change, and

the desire to change it will persist throughout the lifecycle

No matterNo matter where you are in the system lifecycle, where you are in the system lifecycle, the system will the system will changechange, and , and

the desire to change it will persist the desire to change it will persist throughout throughout the the lifecyclelifecycle

Systems Engineering: The Systems Engineering: The ““First LawFirst Law””

BersoffBersoff, et al, 1980, et al, 1980


What are These Changes?What are These Changes?

changeschanges in in

changes in businessbusiness requirementsrequirements

changeschanges ininuser user requirementsrequirements

datadata

otherotherdocumentsdocuments

codecode

ProjectPlan

ProjectProjectPlanPlan

software modelssoftware modelssoftware models

TestTest

technical technical requirementsrequirements


System FamiliesSystem Families

• New “versions” of software systems are created as they changeOffering different functionality

Tailored for particular user requirements

For different machines/OS

• In a multi-person production of multi-version softwareWhat does this imply?

InitialSystem

HPVersion

SunVersion

PCVersion

NTVersion

LinuxVersion

DesktopVersion

ServerVersion


What can go What can go WrongWrong? ? Imagine yourself in any of the following situationsImagine yourself in any of the following situations……

• a developed and tested featuregoes “missing”

• a fully tested program suddenly doesn’t work

• two programmers are working simultaneously on a program; the second one to make changes destroys the work of the first

• a bug is fixed in code shared by several programmers; some of them aren’t notified

• a program is being developed in several concurrent versionsone in operation, one in test, one in development

a bug is fixed in one version but not the others


Software Configuration ManagementSoftware Configuration Management

• SCMa general quality management process applied to all phases of the software engineering process

or, a set of activities developed to manage change/evolution

o throughout the software lifecycle

aims to control the costs and effort involved in making changeschanges to a system

• software systems released to SCMare called baselines

o as they are a starting point for further development and evolving


SCM in the NutshellSCM in the Nutshell

Requirements/design/use

Establish/baseline

Validate baseline

Authorizechange

Initialdevelopment

Validatechange

Implementchange

Approvechange

Changes

Establish/update baseline

Baselines Project DB

Validate baseline

Baselines Project DB


SCM Main ActivitiesSCM Main Activities

• SCM PlanningPlanning

• SCM TasksTasksIdentification

change control

version control

auditing

reporting

construction


• SCM plan describes the standards and procedures to be followed Thousands of separate documents are generated for a large software system

• Starts during the early phases of the project

SCM PlanningSCM Planning


• Defines the types of documents to be managed

a document naming scheme

• Identifies who takes responsibility for the CM procedures

creation of baselines

• Defines policies forchange control

version management

• Describes the tools to be used in CM process

• Defines the CM database used to record configuration information

• Other information such as the CM of external software suppliers, process auditing, etc.

The SCM planThe SCM plan


• should allow queries about configurations to be answeredWho has a particular system version?

What platform is required for a particular version?

What versions are affected by a change to component-X?

How many reported faults in version-T?

• should preferably be linked to the software being managed

• might be in an integrated environment to support software developmentThe CM DB and the managed documents are all maintained on the same system

CASE tools may be integrated CM DB

o to provide close relationship between the CASE tools and the CM tools

usually, however, CM DB is maintained separately

as this is cheaper and more flexible

The CM DBThe CM DB


Typical SCM TasksTypical SCM Tasks

Software EngineeringSoftware Engineering

a TQM foundation

procedures

methods

tools

SCMSCM•• identificationidentification

•• version controlversion control•• change controlchange control

•• auditingauditing•• reportingreporting•• constructionconstruction


IdentificationIdentification

• Assure meaningful and consistent naming for all SCISCI type

o e.g., document, program, test case,...

SCI name

o e.g., Design Specification

Product ID

o Version number, Last release date

• Identification data can be maintained in an automated DBAutomated tools exist to aid in identification


Configuration HierarchyConfiguration Hierarchy

PCL-TOOLS

EDIT

STRUCTURES

BIND

FORM

COMPILE MAKE-GEN

HELP

DISPLAY QUERY

AST-INTERFACEFORM-SPECS FORM-IO

CODEOBJECTS TESTS




a TQM foundation

procedures

methods

tools





Change DesireChange Desire

Next Stage


Change ControlChange Control

Next Stage

STOPSTOP

ChangeChangeControlControl


• Software systems are subject to continual change requestsFrom users

From developers

From market forces

• Change management is concerned withmanaging changes

ensuring that they are implemented in the most cost-effective way

Change ManagementChange Management


Formal Change ControlFormal Change Control

Evaluation

Changerequest

generated

Need forchange

Change reportSubmitted to CCBCCB

CCBCCBdecision

Requesteris informed

ECOECO generated

Other SCMtasks

RejectReject ApproveApprove

MeritMeritSide effectsSide effects

CostCost

• CCB: a group of SW, HW engineers, client, users, support, marketing, …

takes a global view - assess impact of change beyond the SCI, including cost-effective from a strategic & organizational viewpoint. How will the change

o impact performance

o modify customers’ perception of the product

o affect product quality and reliability

• Engineering Change Order (ECO) generated for each approved change

Describes

o change to be made

o constraints

o criteria for review and audit


Change request formChange request form

Change Request Form Project: Proteus/PCL-Tools Number: 104/03 Change requester: J. Smith Date: 1/11/2003 Requested change: When a component is selected from the structure, display the name of the file where it is stored.

Change analyser: G. Dean Analysis date: 10/10/2003 Components affected: Display-Icon.Select, Display-Icon.Display Associated components: FileTable Change assessment: Relatively simple to implement as a file name table is available. Requires the design and implementation of a display field. No changes to associated components are required.

Change priority: Low Change implementation: Estimated effort: 0.5 days Date to CCB: 15/11/2003 CCB decision date: 30/11/2003 CCB decision: Accept change. Change to be implemented in Release 2.1. Change implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments


CheckCheck--inin--out Processout Process……

AccessControl

Check-in

ProjectDB

SCI(modified version)

Audit info

SCI(baseline version)

UnlockUpdate

Check-outSCI

(baseline version)

LockUpdateSCI

(extracted version)

OwnershipInfo


• A major problem in change management is tracking change statusChange tracking tools

o keep track the status of each change request

automatically ensure that change requests are sent to the right people at the right time

– integrated with e-mail systems allowing electronic change request distribution

Change management toolso Form editor to support processing the change request forms

o Workflow system

to define who does what, and

to automate information transfero Change database that manages change proposals and is linked to a version management

system

Change Tracking and Management ToolsChange Tracking and Management Tools




a TQM foundation

procedures

methods

tools





• VersionAn instance of a system which is functionally distinct in some way from other system instances

VariantAn instance of a system which is functionally identical but non-functionally distinct from other instances of a system

• ReleaseAn instance of a system which is distributed to users outside of the development team

Versions/Variants/ReleasesVersions/Variants/Releases


• Main activitiesInvent identification scheme for system versions

Plan when new system version is to be produced

Ensure that version management procedures and tools are properly applied

Plan and distribute new system releases

Version and Release ManagementVersion and Release Management


Version IdentificationVersion Identification

• Procedures for version identification should define an unambiguous way of identifying component versions

• Three basic techniques for component identification1. Version numbering

2. Attribute-based identification

3. Change-oriented identification


• Most commonly used

• Simple naming scheme uses a linear derivation e.g. V1, V1.1, V1.2, V2.1, V2.2 etc.

However, version derivation structureo a tree or a network rather than a sequence

• Requires information management to keep track of the differences between versions

Hierarchical naming scheme may be better

Version NumberingVersion Numbering

V1.0 V1.1

V1.1b V1.1.1

V1.1a

V1.2 V2.0 V2.1 V2.2


• In addition to the explicit attributes identifying a version Other attributes reflect the relationships between versions

o e.g., Date, Creator, Programming Language, Customer, Status etc.

e.g., AC3D (language, platform, date)

• More flexible than an explicit naming scheme for version retrievalHowever, can cause problems with uniqueness

Needs an associated name for easy reference

• An important advantage is that it can support querieso so that you can find ‘the most recent version in Java’ etc.

o e.g., AC3D (language =Java, platform = NT4, date = Nov. 2001)

• Becoming more commonly,Built on top of hidden version naming scheme

CM DB maintains the links between identifying attributes and versions

AttributeAttribute--based Identificationbased Identification


• Releases must incorporate changes, forced on the systemo by errors discovered by users

o by hardware changes

they must also incorporate new system functionality

• Not just a set of executable programs, may also includeo Configuration files

defining how the release is configured for a particular installation

o Data files

needed for system operation

o An installation program or shell script

to install the system on target hardware

o documentation

hardcopy or softcopy

o Packaging and associated publicity

Release ManagementRelease Management


Release Decision MakingRelease Decision Making

• Release planning is concerned with when to issue a system version as a release

• Preparing and distributing a system release is an expensive process

Factors such as o the technical quality of the system

o competition

o marketing requirements and

o customer change requests

should all influence the decision ofo when to issue a new system release


Release Decision MakingRelease Decision Making(Cont.)(Cont.)

FACTOR DESCRIPTION Technical quality of the system

If serious system defects are reported which affect the way in which many customers use the system, it may be necessary to issue a defect repair release. However, minor system defects may be repaired by issuing patches (often distributed over the Internet) that can be applied to the current release of the system.

Competition A new system release may be necessary because a competing product is available

Marketing requirements

The marketing department of an organization may have made a commitment for releases to be available at a particular date.

Customer change proposals

For customized 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


Version Management ToolsVersion Management Tools

• Version and release identificationSystems assign identifiers automatically when a new version is submitted to the system

• Storage managementSystem stores the differences between versions rather than all the version code

• Change history recordingRecord reasons for version creation

• Independent development Only one version at a time may be checked out for change. Parallel working on different versions




a TQM foundation

procedures

methods

tools



•• auditingauditing•• reportingreporting


Configuration AuditConfiguration Audit

• Ensure that the change has been properly implemented

• Formal technical reviewfocuses on the technical correctness of the modified SCI

Complementary software configuration audit that addresses:o Has the change specified in the ECO been made?

o Has SCI ID been changed?

o Have SCM procedures been followed?

o Have related SCIs been updated?

SCIsSCIs

SCM AuditSCM Audit

ChangeChangeRequestsRequests

SQASQA

FormalFormalreviewreview


Configuration Status Reporting (CSR)Configuration Status Reporting (CSR)

• CSR, or Status Accountinganswers:

o What happened

o who did it

o when did it happen

o what else will be affected

• A CSR entry is made anytime an SCI is assigned a new or updated ID

each time a configuration audit is conducted

• CSR outputs can be put into an automated database

help improve communications on large projects

ChangeChangeRequestsRequests

Change Change ReportsReports ECOsECOs

Status AccountingStatus Accounting

ReportingReporting

SCIsSCIs


CM standardsCM standards

• CM should always be based on a set of standards which are applied within an organization

Standards may be based on external CM standardso e.g., IEEE 1028-1988 standard for CM

Existing standards are based on a waterfall process model

However, new standards are needed for spiral/evolutionary models

• Standards should define how items are identified

how changes are controlled

how new versions are managed


CASE Tools for CMCASE Tools for CM

• CM processes are standardized 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


SE351 RoadmapSE351 Roadmap

Introduction to Software Project Management

Project Management

Software Development Life Cycles

Requirements Engineering

Software Process & Project Metrics

Software Project Planning

Project Monitoring & Control

Risk Management

Software Quality Assurance

Software Configuration Management


I wish you the best in Your Exams!

The End!The End!

SE351a: Software Project & Process Management -...

Documents

Transcript of SE351a: Software Project & Process Management -...