Server Technologies II
Configuration Management
INFO 321
Glenn Booker
INFO321 Week 4
1
www.ischool.drexel.edu
Configuration Management
(CM)
• Additional references include:
– Configuration Management Training
Foundation
– International Society of Configuration
Management
– IEEE standards (replaced military standards),
such as IEEE 828 (Configuration
Management Plans)
INFO321 Week 4
2
www.ischool.drexel.edu
Configuration Management
(CM)
• Need Configuration Management
in order:
– To define what the product is
– To track changes to the product
– To help control product integration
– (and to meet ISO and CMM standards)
• Helps deliver the product 1) on schedule,
2) within budget, and 3) according to the
stated requirements
INFO321 Week 4
3
www.ischool.drexel.edu
Configuration Management
(CM)
• Main functions of CM are:
– Configuration Identification
– Configuration Control
– Configuration Audits
– Configuration Status Accounting
• Done properly, CM is almost invisible!
• CM mistakes are often far too visible
INFO321 Week 4
4
www.ischool.drexel.edu
Configuration Items
• Systems are divided into configuration items
• Formal name of major software configuration items
may be a “Computer Software Configuration Item”
(CSCI)
– Scope of each CSCI is selected during high level design
based on: criticality, complexity, interfaces, maintenance
needs, functions, source (supplier), and documentation
needs
INFO321 Week 4
5
www.ischool.drexel.edu
Configuration Items
– CSCIs may be very broad, such as Software,
Hardware, Network, or Documentation
• Computer Software Components (CSCs)
are often major functions, such as User
Interface, or Application Software
INFO321 Week 4
6
www.ischool.drexel.edu
Configuration Items
• Computer Software Units (CSUs) are
single functions, which may still consist of
one or more closely-related modules of
code
INFO321 Week 4
7
www.ischool.drexel.edu
Naming Configuration Items
• One naming convention for configuration
items is the form
aa-bb-cc
Where
aa is the CSCI number
bb is the CSC number
cc is the CSU number
• Extremely complex systems might use
multiple levels of CSCs (components)
INFO321 Week 4
8
www.ischool.drexel.edu
Configuration Structure Excerpt
01 Application Server
CSCI
01-01 Controller
Applications
CSC
CSUs ->
02 Database Server
CSCI
01-02 External
Interfaces
CSC
02-01 Query
Applications
CSC
01-02-01 Finance
System Interface
02-01-01 Personnel
Query
01-02-02 HR System
Interface
02-01-02 Product
Query
01-02-03 FDA
Interface
INFO321 Week 4
9
www.ischool.drexel.edu
Configuration Identification
• What is the smallest thing controlled
and tracked?
– Important to define for maintenance
• Answer is called the “Lowest Replaceable
Unit (LRU)”
– Software: could be a CSU, module, script, etc.
– Hardware: chip (CPU), board (motherboard),
box (rack element), or unit level (entire rack)
INFO321 Week 4
10
www.ischool.drexel.edu
Configuration Identification
• Clarify revision, variation, and version
• Revisions (revised copy of a CI) include
changes to the CI due to:
– Added functions (new features)
– Performance improvement (redesign)
– Reduced bugs (bug fix)
– Other directed changes
INFO321 Week 4
11
www.ischool.drexel.edu
Configuration Identification
• Variations - alternate configurations to
meet different requirements
– Are generally named differently, not
just renumbered
– E.g. if different installation sites need
variations on some CIs
• “Version” is a major step in a CI’s
evolution
– At the product level, Word 2000 versus
Word XP
INFO321 Week 4
12
www.ischool.drexel.edu
Configuration Identification
• Each CI is given a unique identifier, and
tracked by a version number (2.0) and/or
revision letter (A, B, …)
• Old copies are kept:
– In case you need “the last version that
worked”
– To recreate bugs
– To develop metrics for future projects
INFO321 Week 4
13
www.ischool.drexel.edu
Configuration Identification
• Configuration identifiers are basis for:
– Baseline identification
– Engineering release
– Drawing repository
– Document repository
– Parts and inventory control
INFO321 Week 4
14
www.ischool.drexel.edu
Configuration Control
• Scope of controlled CIs includes:
– Support software (system build files,
compilers, operating system, linkers
and loaders, procedure languages,
shell scripts)
– Object code
– CASE elements, third party tools
– Libraries
– Project plans...
INFO321 Week 4
15
www.ischool.drexel.edu
Configuration Control
– Test plans and procedures
– Test data
– Documentation
– Software Development Folders
(including source code)
– CM plans, procedures, and reports
– HW platform interfaces
– Problem reports
INFO321 Week 4
16
www.ischool.drexel.edu
Configuration Control
• Establishes:
– Interface management
– Asset accountability
– Change processes
– Baseline control
– Non-conformance tracking
– Upgrade capability
INFO321 Week 4
17
www.ischool.drexel.edu
Change Types
• Class I - changes to the product’s form, fit,
or function (big changes)
• Class II - minor changes
• Why make this distinction?
– Might have more extensive review process for
Class I changes, such as cost analysis, expert
review, interface impact analysis, etc.
INFO321 Week 4
18
www.ischool.drexel.edu
Change Types
• Can also distinguish between changes to
fix the existing system (break/fix) versus
changes to implement new features (meet
new requirements)
• See sample change control process
here and a discussion of possible
change relationships
INFO321 Week 4
19
www.ischool.drexel.edu
Configuration Audits
• Audits can be formal or informal, internal
or external (e.g. contractual or legal):
– Product buy-off (approve first article
off production line)
– Assessment (internal audit)
– Subcontractor reviews (external)
– Functional Configuration Audit (FCA)
– Physical Configuration Audit (PCA)
INFO321 Week 4
20
www.ischool.drexel.edu
Configuration Audits
• Often conduct audits when transitioning
from informal to formal control
• FCA is done after product has completed
certification testing - determines if product
is acceptable to the customer
INFO321 Week 4
21
www.ischool.drexel.edu
Configuration Audits
• PCA immediately follows FCA determines what the configuration is, and
defines the first official Product Baseline
INFO321 Week 4
22
www.ischool.drexel.edu
Internal Audits
• Review compliance with internal
procedures, work flow, and spot checking
physical inventory
• Determines whether your CM processes
are really being used, or serve as dustcatchers
INFO321 Week 4
23
www.ischool.drexel.edu
Internal Audits
• CM internal audits should be performed by
the QA organization
• Results are published, and problems fixed
INFO321 Week 4
24
www.ischool.drexel.edu
External Audits
• External audits may be performed for
several reasons:
– To prove the quality of your processes
(e.g. ISO 9000, CMM)
– To provide legal proof of activities (cost
audits, tax audits)
– To prove to the world you really know
what’s going on!
– To meet customer requirements
INFO321 Week 4
25
www.ischool.drexel.edu
Configuration Status Accounting
• Enables:
– Traceability through configuration changes
– Production of metrics
– Integrated repository
– Automated tool suites
– Change chronology
INFO321 Week 4
26
www.ischool.drexel.edu
Configuration Status Accounting
• Purpose is to convey output of the other
CM processes
• Establishes a configuration record
• Provides management metrics
• Tracks proposed changes through
implementation
INFO321 Week 4
27
www.ischool.drexel.edu
Configuration Status Accounting
• Must be able to:
– Identify the current configuration
– Report status of all proposed
engineering changes
– Report status of all configuration audits
– Provide traceability among configurations
– Track specific configuration identifiers
(e.g. serial numbers)
INFO321 Week 4
28
www.ischool.drexel.edu
Configuration Status Reports
• Baseline Configuration Report
• Software Structure Diagram
• Periodic reports:
– Project library and media contents
– Outstanding software
– Change Request status
– Change Summary report
INFO321 Week 4
29
www.ischool.drexel.edu
Management’s Role in CM
• Define organization
• Assign roles and responsibilities
• Identify management representative
from CM
• Identify training needs
• Act as conflict resolution authority
INFO321 Week 4
30
www.ischool.drexel.edu
Software-specific CM
• Provides:
– Version control
– Software documentation
– Workspace management
– Media vaulting
– Development library (reuse and other)
– Project visibility
INFO321 Week 4
31
www.ischool.drexel.edu
Baselines During Product Life Cycle
Time
Need
Concept
Definition
SSR CDR
FCA/PCA
SDR
Requirements
Design, Code,
Production &
Definition
Functional
SW Allocated
Baseline
Baseline
and Test
Operation
End of Life
or Archive
Allocated
Baseline
Product
Baseline
INFO321 Week 4
SW Product
Baseline
32
www.ischool.drexel.edu
Formal Baselines
1) Functional Baseline - describes the key
performance and functions of
the product - what will it do?
– Completed by the end of concept definition,
after successful Software
(or System) Design Review (SDR)
– What must this product do in order
to be successful?
INFO321 Week 4
33
www.ischool.drexel.edu
Formal Baselines
2) Software Allocated Baseline (SAB) - consists of the
Software Requirements Specification (SRS) and
Interface Requirements Specification (IRS!)
– After the requirements for the product have been defined,
the SAB is released as a result
of the Software Specification Review (SSR)
– Full development of the software follows,
based on the SAB
INFO321 Week 4
34
www.ischool.drexel.edu
Formal Baselines
• “Allocated” in this context refers to the
product’s requirements being allocated, or
assigned, to specific parts of the software
or system
– This defines which functions must be
performed by each portion of the software or
system
INFO321 Week 4
35
www.ischool.drexel.edu
Formal Baselines
3) Allocated Baseline - describes how the
functional baseline applies to each major
area of the product; What does each part
of the product do? How do they interact?
– Allocated Baseline follows a successful
Critical Design Review (CDR) (well after the
SSR)
– Before the CDR, there can be one or more
Preliminary Design Reviews (PDR)
INFO321 Week 4
36
www.ischool.drexel.edu
Formal Baselines
• The Allocated Baseline forms the foundation for the
remainder of detailed product design and
development
– If a life cycle model is being used which breaks into
subprojects or stages, that break generally occurs after the
Allocated Baseline is defined and approved
• Allocated Baseline essentially marks the end of high
level design
INFO321 Week 4
37
www.ischool.drexel.edu
Formal Baselines
4) Product Baseline - describes the final
product, including end user, design,
and maintenance information
– Is first released after development
has been completed, as the product
goes into production
– Generally defined at the end of FCA/PCA
INFO321 Week 4
38
www.ischool.drexel.edu
Formal Baselines
5) Software Product Baseline - includes
software product specification, Version
Description Document (VDD), and the
actual software
– Is established just after the Product
Baseline and FCA/PCA
– Consists of the software-related parts
of the Product
INFO321 Week 4
39
www.ischool.drexel.edu
Formal Baselines
• All of the Baselines will evolve throughout
the life of the product
– All changes to the system must check for
changes to baselined documentation too
• Software-only projects (no hardware) will
simplify to three baselines
– Functional, Allocated, and Product
INFO321 Week 4
40
www.ischool.drexel.edu
Software Libraries
•
Need at least three levels of libraries:
1. Restricted access project archives of each
version (CM control only)
2. Working copies of the current version for
day-to-day development and testing, which
are checked out to developers
3. Archive storage (disaster planning)
INFO321 Week 4
41
www.ischool.drexel.edu
Library Tasks
• “Check in” software - accept software
and documentation
• Store software in a known location
• “Check out” software to authorized users
• Use of check in and check out prevents
two people from changing one piece of
code at the same time
INFO321 Week 4
42
www.ischool.drexel.edu
Software Developmental
Configuration (SDC)
• Consists of all successfully tested
and approved software, and
approved documentation
• Is stored in Software Development
Library
INFO321 Week 4
43
www.ischool.drexel.edu
Software Developmental
Configuration (SDC)
• Is controlled manually, or with a
CM tool
– MS SourceSafe, Rational Clearcase,
QVCS, Metrowerks, CVS
• Contains the product baseline at
selected moments in time
INFO321 Week 4
44
www.ischool.drexel.edu
Software Developmental
Configuration (SDC)
• Has restricted access, and sealed media
• Changes only by approval of the
Configuration Control Board (or
equivalent)
– A critical CM concept is to require approval of
all changes to anything which has been
baselined (put under CM control)
INFO321 Week 4
45
www.ischool.drexel.edu
Document Control
• A “Release” means that a document is
ready for its intended use
• The release process, which is part of
Document Control, includes reviewing,
validating, storing, maintaining, archiving,
and communicating controlled
design information
INFO321 Week 4
46
www.ischool.drexel.edu
Version Control
• Tracks initial versions, changes to code,
and derived relationships (code splits or
merges)
• Version control is needed to define,
construct, and manage software
configurations; and control product
releases
• Each software release is a collection of
programs, data, and documents on
magnetic media
INFO321 Week 4
47
www.ischool.drexel.edu
Version Description Document
• Describes the software to be released
• Describes approved changes since the
last release
• Describes approved changes NOT in
this release
• Identifies each software release and
its documentation
INFO321 Week 4
48
www.ischool.drexel.edu
Software Control Drawing
• Describes characteristics of executable
software, such as the structure of a CSCI,
or the relationship between CSCI’s and
hardware, e.g.
– Interface flow charts
– Entity-Relationship Diagrams
– Class diagrams
– Network diagrams
INFO321 Week 4
49
www.ischool.drexel.edu
CM Tools
• Source Code Control System
• Revision Control System
• Build Management
– “Make” tools (to compile software)
• Might include the entire Software
Engineering Environment!
INFO321 Week 4
50
www.ischool.drexel.edu
CM Policies
• A Software Standards Manual (SSM)
describes the policies and guidelines
used by an entire organization
• A Software CM Plan (SCMP) describes
how the SSM is implemented on a
particular project
INFO321 Week 4
51
www.ischool.drexel.edu
CM Planning
• Describe:
– The vision, mission, policy
– CM risk analysis
– The CM system
– Project tailoring
– Approach for process improvement
INFO321 Week 4
52
www.ischool.drexel.edu
The CM Plan
• CM Plan should define who, how,
and when to:
– Conduct CM assessments and audits
– Assign configuration identifiers
– Conduct configuration audits
– Control the baselines
– Establish & manage the SDL and software
archive (how to check software in and out)...
INFO321 Week 4
53
www.ischool.drexel.edu
The CM Plan
• CM Plan should define:
– Engineering change processes, both for
software improvements (requirements
management) and for quality improvement
(defect removal)
– Documentation flow and reports
INFO321 Week 4
54
www.ischool.drexel.edu
Key CM Considerations
•
•
•
•
Develop and use a CM Plan
How will configuration items be identified?
How will configuration items be controlled?
How will the software and documentation
libraries be created and managed?
INFO321 Week 4
55
www.ischool.drexel.edu
Key CM Considerations
• How and when will audits be performed?
• What kind of reports will be prepared?
• How and when will be baselines
be defined?
• How will changes to the baselines be
controlled? (see Change Control Process)
INFO321 Week 4
56
www.ischool.drexel.edu