Configuration Management

1
Lesson 8

• Configuration Management

2
Course Outline Day 2

• Object Oriented Design
• Risk Management
• Configuration Management
• Validation and Verification
• Review and Closing

3
Learning Objectives

• Define Configuration Management
• List the members of the Configuration Control
  Board
• List the benefits of configuration management

4
Crosscutting Activities
Systems Engineering Life Cycle Many Activities
Occur Throughout the Project
Tech. Mngmnt Risk Mngmnt. Configuration
Mngmnt. Validation Verification
Concept of Operations
Operations Maintenance
High Level Requirements
System Verification
Detailed Requirements
High Level Design
Subsystem Verification
Detailed Design
Integration Test
Implementation
Time
5
Configuration Management - 1st part of definition
A management process for establishing and
maintaining consistency of a products
performance, functional and physical attributes
with its Requirements, design, and operational
information throughout its life
ANSI/EIA 649 1998 National Consensus for
Configuration Management
5
6
Configuration Management - 2nd part of definition
A process intended to ensure that the system
performs as intended, and is documented to a
level of detail sufficient to meet needs for
operation, maintenance, repair and replacement
ANSI/EIA 649 1998 National Consensus for
Configuration Management
7
In other words.

• The primary goals of configuration management
  are
• Establish System and project product integrity
• Maintain this integrity throughout the lifecycle

8
Basic Configuration Management Activities

• Configuration Item Identification decision on
  identification and control of configuration items
• Status accounting Track changes, decision,
  actions
• Change control A configuration control board
  rules on all change actions.
• Audits Review of functional and physical
  configuration

9
Configuration Identification

• Configuration Items
• Requirements
• Design
• Software and Hardware,
• Test Plans
• Development Environment,
• Documentation

10
Configuration Management Who is Responsible?
11
CM if the Agency Has no Process
12
Why is Configuration Management Needed?

• Change is inevitable
• Even small changes, if not controlled, can have
  major effects
• Essential for an efficient development process
• Essential for maintenance

13
Configuration Management

• Controls the design as the system moves through
  its life cycle
• Establishes system baselines
• Controls how changes are made
• Communicates all approved changes

14
Whats a Baseline

• A starting point for defining current version
• All elements are included
• Hardware
• Interconnections
• Software
• Documentation
• Test procedures
• Other

15
Basic Configuration Management Activities

• Definition Baseline configuration
• Status accounting Track changes
• Change control Restrict changes to those that
  are essential and affordable
• Audits Double check the process

16
Identifying Hardware Items

• Hardware configuration can be tracked at the
  following levels
• Part
• Subassembly
• Assembly
• Unit
• Pick the level of control best suited to your
  project

17
Traffic Signal Controller Example

• Part
• Subassembly
• Assembly
• Unit

• Processor chip
• Printed Circuit Board
• Traffic signal controller
• Controller cabinet

18
Software Items

• Source code for application programs
• Executable application code
• Third party software
• Operating system (OS)
• Database management system (DBMS)
• Geographic information system (GIS)
• Development tools (compilers, CASE tools, test
  tools, etc.)
• Documentation

19
Other Elements of Configuration Management

• Communications interconnections
• Wide area networks
• Local area networks
• Wiring
• Cabinet wiring
• Control center wiring
• Numbering systems

20
Numbering Example
Large Screen Display
Graphical Symbol
Link
Detector No.
Back-panel Connector
DBMS
GUI
Field Cabinet
Communications
Comm. Driver
Wire/fiber Channel
Vehicle Detector
21
Types of Documents Controlled

• System requirements
• Interface control documents
• Design documents
• Hardware technical data packages
• User and maintenance manuals
• Test plans, test procedures, and test reports
• Training materials
• Distribution of documentation using a website is
  very useful

22
Traceability Pulls it All Together
Require
Specify
Implement
Test
Maintain
23
Traceability Example
Requirements 2.0 The system shall have the
ability to monitor traffic 2.1 The system shall
measure traffic volumes
Specification 3.83 System processing of volume
data shall be performed By summing the actuations
of each detector
Software modules 17.6.1 Detector data input
module 18.3.4 Volume summation module 2.4.5
Volume storage (DBMS interface)
Test 8.0 Compare calculated volume with actual
volume
24
Traceability Matrix Illustration
25
Specification Trees Another CM Tool

• A hierarchy of subsystem performance requirements
  
• Defines interrelationships between specifications
• Explicitly defines all performance requirements

26
Generic Specification Tree

• System spec 1234a (includes)
• Subsystem spec 876b (which includes)
• Hardware spec 3333
• Interface spec 5555
• Software spec 666
• Executable version 5478
• Subsystem spec 7689c (which includes)
• Hardware spec 3434
• Interface spec 676
• Software spec 789
• Executable version 4523

27
Status Accounting

• Involves keeping track of the status of
  configuration controlled items
• Physically
• In terms of completion
• In terms of approved changes
• Includes a reporting element

28
CM Audits

• CM verified through periodic audits.
• Audits performed by an independent organization
  (may be an independent unit of the developers
  organization)
• Audits should be performed at project milestones
  to ensure that CM control is adequate

29
Change Control is Important
50 change in Requirements
Change
50
25
Year 1
Year 2
Year 3
Year 4
Reference McConnell, Rapid Development
Taming Wild Software Projects, 1996
30
Configuration Control Board

• Reviews all proposed changes for impact on budget
  and schedule
• Prioritizes changes identifies changes that can
  be postponed for the future
• Limits Scope Creep

31
Whos on the Configuration Control Board?

• Project manager
• At least one key user representative
• Contractors project manager
• Senior manager with funding responsibility
• Configuration manager
• Quality control manager
• Systems engineer

32
Whats Involved in Change Control?

• Change Request submitted
• Impact Assessment performed
• Recommendation prepared
• Report submitted to CCB
• CCB deliberates and decides
• Approved changes are entered in the configuration
  management documentation
• Traceability matrices are updated

33
What Causes Change Requests?

• Errors in system components
• External factors (e.g., legislation)
• Advances in technology
• Upgrades
• Additional capabilities requested by users
• Improved solutions proposed by technical team

34
How Do You Control the Impact of Changes?

• Build the system in short increments six to
  nine months in duration max
• Defer changes for later versions whenever
  possible
• Force justification for all changes, even minor
  ones
• But DONT freeze the system arbitrarily

35
How Often Should the CCB Meet?

• Periodically, whenever there are enough changes
  to consider
• Enough changes can include
• A single significant change
• Multiple small changes

36
Configuration Management and the Timeline
Define Configuration
Configuration Control Traceability
Concept of Operations
Develop Deploy
Acceptance Test
Requirements
Design
Establish Configuration Control Board
CCB Meets
Time
37
Learning Objectives

• Define Configuration Management
• List the members of the Configuration Control
  Board
• List the benefits of configuration management

38
Crosscutting Activities
Systems Engineering Life Cycle Many Activities
Occur Throughout the Project
Tech. Mngmnt Risk Mngmnt. Configuration
Mngmnt. Validation Verification
Concept of Operations
Operations Maintenance
High Level Requirements
System Verification
Detailed Requirements
High Level Design
Subsystem Verification
Detailed Design
Integration Test
Implementation
Time