Server technologies ii
1 / 56

Server Technologies II - PowerPoint PPT Presentation

  • Uploaded on

Server Technologies II. Configuration Management INFO 321 Glenn Booker. Configuration Management (CM). Additional references include: Configuration Management Training Foundation International Society of Configuration Management

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Server Technologies II' - derek-decker

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Server technologies ii

Server Technologies II

Configuration Management

INFO 321

Glenn Booker

INFO321 Week 4

Configuration management cm
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

Configuration management cm1
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

Configuration management cm2
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

Configuration items
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

Configuration items1
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

    Configuration items2
    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

    Naming configuration items
    Naming Configuration Items

    • One naming convention for configuration items is the formaa-bb-cc

      Where aa is the CSCI numberbb is the CSC numbercc is the CSU number

    • Extremely complex systems might use multiple levels of CSCs (components)

    INFO321 Week 4

    Configuration structure excerpt
    Configuration Structure Excerpt

    CSUs ->

    INFO321 Week 4

    Configuration identification
    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

    Configuration identification1
    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

    Configuration identification2
    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

    Configuration identification3
    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

    Configuration identification4
    Configuration Identification

    • Configuration identifiers are basis for:

      • Baseline identification

      • Engineering release

      • Drawing repository

      • Document repository

      • Parts and inventory control

    INFO321 Week 4

    Configuration control
    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

    Configuration control1
    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

    Configuration control2
    Configuration Control

    • Establishes:

      • Interface management

      • Asset accountability

      • Change processes

      • Baseline control

      • Non-conformance tracking

      • Upgrade capability

    INFO321 Week 4

    Change types
    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

    Change types1
    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

    Configuration audits
    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

    Configuration audits1
    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

    Configuration audits2
    Configuration Audits

    • PCA immediately follows FCA - determines what the configuration is, and defines the first official Product Baseline

    INFO321 Week 4

    Internal audits
    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

    Internal audits1
    Internal Audits

    • CM internal audits should be performed by the QA organization

    • Results are published, and problems fixed

    INFO321 Week 4

    External audits
    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

    Configuration status accounting
    Configuration Status Accounting

    • Enables:

      • Traceability through configuration changes

      • Production of metrics

      • Integrated repository

      • Automated tool suites

      • Change chronology

    INFO321 Week 4

    Configuration status accounting1
    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

    Configuration status accounting2
    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

    Configuration status reports
    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

    Management s role in cm
    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

    Software specific cm
    Software-specific CM

    • Provides:

      • Version control

      • Software documentation

      • Workspace management

      • Media vaulting

      • Development library (reuse and other)

      • Project visibility

    INFO321 Week 4

    Baselines during product life cycle







    Concept Definition

    Requirements Definition

    Design, Code, and Test

    Production & Operation

    End of Life or Archive

    Functional Baseline

    SW Allocated Baseline

    Allocated Baseline

    Product Baseline

    SW Product Baseline

    Baselines During Product Life Cycle

    INFO321 Week 4

    Formal baselines
    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

    Formal baselines1
    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

    Formal baselines2
    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

    Formal baselines3
    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

    Formal baselines4
    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

    Formal baselines5
    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

    Formal baselines6
    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

    Formal baselines7
    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

    Software libraries
    Software Libraries

    • Need at least three levels of libraries:

      • Restricted access project archives of each version (CM control only)

      • Working copies of the current version for day-to-day development and testing, which are checked out to developers

      • Archive storage (disaster planning)

    INFO321 Week 4

    Library tasks
    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

    Software developmental configuration sdc
    Software Developmental Configuration (SDC)

    • Consists of all successfully tested and approved software, and approved documentation

    • Is stored in Software Development Library

    INFO321 Week 4

    Software developmental configuration sdc1
    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

    Software developmental configuration sdc2
    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

    Document control
    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

    Version control
    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

    Version description document
    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

    Software control drawing
    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

    Cm tools
    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

    Cm policies
    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

    Cm planning
    CM Planning

    • Describe:

      • The vision, mission, policy

      • CM risk analysis

      • The CM system

      • Project tailoring

      • Approach for process improvement

    INFO321 Week 4

    The cm plan
    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

    The cm plan1
    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

    Key cm considerations
    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

    Key cm considerations1
    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