Software Conﬁguration Management - University of Kansashossein/811/Papers/scm-teams.pdf ·...

Software Engineering Courses (University of Kansas, Spring 2005) Slide 1

Software Configuration Management

• Software Configuration: All items that constitute the

software while under the development (e.g., programs, data,

documents such as the software requirements specification,

test cases, etc.); they are referred to as Software

Configuration Items or SCIs

• Most (or all) SCIs change during the development; such

changes must be effectively controlled

For exclusive use of Professor Saiedian’s students



(continued)

Software Configuration Management (SCM) is the process of

identifying and defining the SCIs in the system and coordinating

the changes made to these items. A formal definition:

“SCM is the process of identifying and defining the items in the

system, controlling the change of these items throughout their

life cycle, recording and reporting the status of items and

change requests, and verifying the completeness and

correctness of items” IEEE 1987




(continued)

SCM provides for systematic evolution of a software under

development and provides for:

• visibility

• controlled change

• traceability

• monitoring



CMM on Software Configuration

Management

SCM and the CMM. Goals of Level 2 SCM KPA:

• Goal 1: Software configuration management activities are

planned

• Goal 2: Selected software work products are identified,

controlled, and available

• Goal 3: Changes to identified software work products are

controlled

• Goal 4: Affected groups and individuals are informed of the

status and content of software baselines



Configuration Management

Primary Task: To manage change

....

Configuration Management

Baseline Baseline

Phase 2Phase 1 Phase n

Baseline. “A specification or product that has been formally reviewed

and agreed upon, that thereafter serves as the basis for further

development, and that can be changed only through formal change

control procedure.” IEEE 1990



Components of the SCM

Major components of the SCM:

• Software Configuration identification

• Change Control

• Configuration Status Accounting

• Configuration Audit



Software Configuration

Identification

First Step in SCM: Identification of the SCIsNo fast rules: once a SCI has been identified, it should be givenan identification name

Examples of the SCIs:

• The entire product of a software development phase (e.g., arequirements document)

• Chapters or sections of a document

• A separately compilable module

• A file consisting of a number of modules

• A file consisting of module definitions



Baselines of a Typical Development

Life Cycle

• Phase/Discipline: Requirements AnalysisBaseline: Software Requirements Specification

• Phase/Discipline: Software DesignBaseline: Design Specification

• Phase/Discipline: Coding and ImplementationBaseline: Source Code

• Phase/Discipline: Testing and IntegrationBaseline: Test Plans and Data

• Phase/Discipline: Acceptance Testing/ReleaseBaseline: Operational Software



Change Control

• Change control is the process of controlling the changes to

the SCIs. A formal definition:

“An element of configuration management, consisting of the

evaluation, coordination, approval or disapproval, and

implementation of changes to configuration items after

formal establishment of their configuration identification.”

IEEE 1990



Change Control Process

Decision making process is carried out by the Configuration

Control Board (CCB) which consists of one or more individuals

led by the Configuration Manager (CM), responsible for

configuration management

The process is as follows:

(1) While a SCI is under development (working state), it can

changed freely since it is not under SCM yet

(2) When a SCI is in a stable condition, it is submitted to the CM

for review (under review state)



Change Control Process (continued)

(3) While under review, the SCI is considered “frozen”

(4) Once the SCI is reviewed (for satisfactory quality) and

approved, it is entered into a library - the SCI is now formally

under SCM:

Working Under Review Under SCMapproved

disapproved

(5) Once in the library (i.e., under the SCM), the SCI cannot be

changed unless the change is approved by the CCB




(6) Request for change must be formally initiated via a Change

Request (CR) form. A CR form has three components:

6.1 Change Request Proposal

• Proposer information

• Description of change

• Reason for the change

• SCIs affected by the change

• Priority of the change (fault error?)




6.2 CCB’s Decision (completed by CM)

• CCB’s approval/disapproval decision (based on cost/benefit

analysis, quality issues, scheduling)

• CCB assigned unique number to the proposed change for

future references

• Actions recommended by the CM (e.g., no action, change

the SCI, changes to programs, changes to the documents)

6.3 Implementation of Change. A change log by the change

implementation (e.g., status of change); complementary

comments




(7) Check-In, Check-Out Process: Once the change has been

approved, the SCI has to be checked-out from the library for

change; once the change has been implemented, the SCI must

be checked-in to the library



Configuration Status Accounting

Implementing a change may take a long time

The objective of Configuration Status Accounting is to answerquestion such as:

• What is the status of a CR?

• What is the status of an approved CR?

– Scheduled/not scheduled? Active? Completed?

• Who is in charge of implementing an approved CR?

• What is the average time to process a CR?

• What is the average efforts needed to process a CR?

• What is the number of CRs per SCI?

• Have all related SCIs been properly updated?



Configuration Status Accounting

(continued)

Configuration status accounting plays an important role in the

success of large software projects where a large number of

individuals are involved on the same project; the status

accounting helps improving communication between those

individuals involved



Configuration Auditing

• Configuration Auditing Objective: to verify compliance with

configuration control standards

• Configuration auditing is performed by auditors (external to

the development team) who are in charge of determining if

the defined processes are being followed and to ensure that

the SCM goals are satisfied

• For example, it will determine whether software engineering

an organizational standards (e.g., documentation standards,

coding conventions) been properly followed?



Resources for Configuration Control

Traditional tools:

• make utility - operates on a makefile (includes a definition of theSCIs and their dependencies and a procedure for re-building thesystem if any of the components of the system has changed sincethe last built)

Originally for the UNIX; migrated to the PC environments

• SCCS utility - administration programs for Source Code ControlSystem (SCCS)

• RCS utility - a revision control that creates new revision controlfiles or changes attributes of existing ones. An RCS file containsmultiple revisions of text, an access list, A change log, descriptivetext, and some control attributes.

• Many other similar tools, e.g., diff



WWW Resources for Configuration

Control

Comprehensive list of free and commercial products:

www.cmtoday.com/yp/configuration management.html



Configuration Control/Request

Change Samples

• Standards

– ANSI/IEEE Std 828 SCM Plans

– ANSI/IEEE Std 1042 Guide to SCM



An Outline of a CM Plan

1. Introduction: Purpose, Scope, Definition, Acronyms

2. Management: organization of the project and baselines,

SCM responsibilities, who does what

3. CM activities: how the organization will perform the CM

activities (identification, control, status accounting, audit)

4. Tools, Techniques and Methodologies: technical details of

implementing CM

5. Supplier Control (sub-contractor software; vendor software)

6. Records Collection and Retention



Software Engineering Teams

Managing Software Engineering Teams. Managing software

engineers is more difficult; the following characteristics are more

prevalent among software engineers and programmers:

• logical

• artistic

• possessive

• temperamental

• diverse productivity ratio (as much as 20:1)

Software projects organized as teams; each team responsible for a

specific function

Project manager must form the teams



Team Work Goals

• Volunteers are better than draftees

• Creating and sustaining an environment that fosters cooperation;team leadership must inspire growth

• Share common goals; committed to achieving the goals

• Mutual respect and common code of conduct

• Sense of enjoyment; desire to do what is needed to succeed

• Sharing a common reward; equitable compensation; selectiverewards only for extraordinary work

• Team spirit: team needs are more important than personal needs

• Recognition for team achievements

• Clear definition of team vision and objectives; consensus on goalsand individual responsibilities - develop organization structure



A Minimal Team Structure

Project Manager

Deputy ManagerProject Secretary

Configuration ControlSystem EngineerQuality Assurance

DevelopmentTeam

Development Team

DevelopmentTeam

DevelopmentTeam

DevelopmentTeam



Is it Really a Team?Positive indicators:

• collaborative climate

• free flow of information

• positive interpersonal interaction

• high energy

• high morale; fun to come to work

Negative indicators:

• suspicious and un-trusting climate

• information is withheld

• finger-pointing prevails

• defensiveness and counterproductive cliques form

• no fun to workFor exclusive use of Professor Saiedian’s students


Team Organization

Chief Programmer Teams: team leader is both a technical

mentor and the team’s coordinator; team coordination may take

as much as 50% of team leader’s time to

• assign tasks to the team members

• provide advice and guidance

• supervise the work of team members

• coordinate activities

All team members report to the team leader; the leader must be

very good at making decisions



Team Organization (continued)

Democratic Teams: no team leader per se; the team leader

mostly in charge of coordination

• technical decisions made by the whole team

• ideal for experienced software developers; not so ideal for

junior developers

• leads to ego-less programming: everyone is equally

responsible



Developing High Performance

Teams

• Small team size

• Result-driven structure

• Effective communication

• Mutual trust

• A sense of autonomy and empowerment



Physical Facilities are Important

• Work and conference rooms

• Lighting and physical comfort

• Minimal noise areas (private office vs cubicles)

• Access to hardware and equipment (e.g., printers, copymachine, fax, white boards, flip charts)

• Minimums of a productive environment (McConnell 1996)

– 80 SF per developer; 15 SF of desk space; 15 SF ofbookshelves space

– Means of stopping phone interruption

– Means of stopping in-persona interruption

– Means of stopping unwanted noise

– Convenient access to other team membersFor exclusive use of Professor Saiedian’s students


Benefits of Workspace Improvement

A number of studies have shown that productivity will improve

(as much as 11% - an IBM research) with well designed

workspaces



Effective Team and Project Meetings

Project status meetings should be held periodically and to be

Attended by key project members

• Well-defined agenda

• Participants must be prepared

• 2-Hour duration; Begin on time; End on time

• Document and distributes the outcome (minutes):

– Date and name of the meeting

– List of participants

– Major decisions and items discussed

– Action items and completion dates



New Ideas

• Pair-Programming

“PairProgramming requires two engineers to participate in one

development effort at one workstation. Each member performs

the action the other is not currently doing: While one types in

UnitTests the other thinks about the class that will satisfy the test,

for example. Studies have shown that, after training for the

‘PeopleSkills’ involved two programmers are more than twice as

productive as one for a given task”

• L. Williams, R. Kessler, W. Cunningham, and R. Jeffries,

Strengthening the Case for Pair-Programming, IEEE Software,

July/Aug 2000.

• PairProgramming.com


Software Conﬁguration Management - University of Kansashossein/811/Papers/scm-teams.pdf ·...

Documents

Transcript of Software Conﬁguration Management - University of Kansashossein/811/Papers/scm-teams.pdf ·...