server technologies ii
Download
Skip this Video
Download Presentation
Server Technologies II

Loading in 2 Seconds...

play fullscreen
1 / 56

Server Technologies II - PowerPoint PPT Presentation


  • 109 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

Time

Need

SSR

CDR

FCA/PCA

SDR

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

ad