Upload
rodney-preston
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
www.ischool.drexel.edu1
Server Technologies II
Configuration Management
INFO 321
Glenn Booker
INFO321 Week 4
www.ischool.drexel.edu2
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
www.ischool.drexel.edu3
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
www.ischool.drexel.edu4
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
www.ischool.drexel.edu5
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
www.ischool.drexel.edu6
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
www.ischool.drexel.edu7
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
www.ischool.drexel.edu8
Naming Configuration Items
• One naming convention for configuration items is the form
aa-bb-ccWhere aa is the CSCI number
bb is the CSC numbercc is the CSU number
• Extremely complex systems might use multiple levels of CSCs (components)
INFO321 Week 4
www.ischool.drexel.edu9
Configuration Structure Excerpt
01 Application ServerCSCI
01-01 ControllerApplications
CSC
01-02 ExternalInterfaces
CSC
02-01 QueryApplications
CSC
02-01-01 PersonnelQuery
02-01-02 ProductQuery
01-02-02 HR SystemInterface
01-02-03 FDAInterface
01-02-01 FinanceSystem Interface
02 Database ServerCSCI
CSUs ->
INFO321 Week 4
www.ischool.drexel.edu10
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
www.ischool.drexel.edu11
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
www.ischool.drexel.edu12
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 XPINFO321 Week 4
www.ischool.drexel.edu13
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
www.ischool.drexel.edu14
Configuration Identification
• Configuration identifiers are basis for:– Baseline identification– Engineering release– Drawing repository– Document repository– Parts and inventory control
INFO321 Week 4
www.ischool.drexel.edu15
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
www.ischool.drexel.edu16
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
www.ischool.drexel.edu17
Configuration Control
• Establishes:– Interface management– Asset accountability– Change processes– Baseline control– Non-conformance tracking– Upgrade capability
INFO321 Week 4
www.ischool.drexel.edu18
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
www.ischool.drexel.edu19
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
www.ischool.drexel.edu20
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
www.ischool.drexel.edu21
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
www.ischool.drexel.edu22
Configuration Audits
• PCA immediately follows FCA - determines what the configuration is, and defines the first official Product Baseline
INFO321 Week 4
www.ischool.drexel.edu23
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 dust-catchers
INFO321 Week 4
www.ischool.drexel.edu24
Internal Audits
• CM internal audits should be performed by the QA organization
• Results are published, and problems fixed
INFO321 Week 4
www.ischool.drexel.edu25
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
www.ischool.drexel.edu26
Configuration Status Accounting
• Enables:– Traceability through configuration changes– Production of metrics– Integrated repository– Automated tool suites– Change chronology
INFO321 Week 4
www.ischool.drexel.edu27
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
www.ischool.drexel.edu28
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
www.ischool.drexel.edu29
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
www.ischool.drexel.edu30
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
www.ischool.drexel.edu31
Software-specific CM
• Provides:– Version control– Software documentation– Workspace management– Media vaulting– Development library (reuse and other)– Project visibility
INFO321 Week 4
www.ischool.drexel.edu32
Baselines During Product Life Cycle
Concept Definition
Requirements Definition
Design, Code, and Test
Production & Operation
End of Life or Archive
Need
Functional Baseline
SDR
SW Allocated Baseline Allocated
Baseline
Product Baseline
SW Product Baseline
SSR CDR FCA/PCA
Time
INFO321 Week 4
www.ischool.drexel.edu33
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
www.ischool.drexel.edu34
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
www.ischool.drexel.edu35
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
www.ischool.drexel.edu36
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
www.ischool.drexel.edu37
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
www.ischool.drexel.edu38
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
www.ischool.drexel.edu39
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
www.ischool.drexel.edu40
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
www.ischool.drexel.edu41
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
www.ischool.drexel.edu42
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
www.ischool.drexel.edu43
Software Developmental Configuration (SDC)
• Consists of all successfully tested and approved software, and approved documentation
• Is stored in Software Development Library
INFO321 Week 4
www.ischool.drexel.edu44
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
www.ischool.drexel.edu45
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
www.ischool.drexel.edu46
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
www.ischool.drexel.edu47
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
www.ischool.drexel.edu48
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
www.ischool.drexel.edu49
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
www.ischool.drexel.edu50
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
www.ischool.drexel.edu51
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
www.ischool.drexel.edu52
CM Planning
• Describe:– The vision, mission, policy– CM risk analysis– The CM system– Project tailoring– Approach for process improvement
INFO321 Week 4
www.ischool.drexel.edu53
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
www.ischool.drexel.edu54
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
www.ischool.drexel.edu55
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
www.ischool.drexel.edu56
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