Configuration Management Structured System Design II – 302 Lecture # 27 – 2003-04-28 The Last...

Configuration

ManagementStructured System Design II – 302

Lecture # 27 – 2003-04-28The Last Lecture of the Course!

M. E. Kabay, PhD, CISSPDept of Computer Information Systems

Norwich University [email protected]

mailto:[email protected]

2 Copyright © 2003 M. E. Kabay. All rights reserved.

Topics

Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management


Configuration Management

Managing products of system change


Configuration Management (1)

New versions of software systems created as they changeFor different machines/OSOffering different functionalityTailored for particular user requirements

Configuration management concerned with managing evolving software systemsSystem change a team activityCM aims to control costs and effort

involved in making changes to a system


Configuration Management (2)

Development and application of Procedures and standards toManage an evolving software product

Part of more general quality management process

When released to CM, software systems sometimes called baselinesStarting point for further development


System Families


CM Standards

CM should always be based on set of standards applied within an organization

Standards should define howItems identifiedChanges controlled and New versions managed

Standards may be based on external CM standards (e.g. IEEE standard for CM)

Existing standards based on a waterfall process modelNew standards needed for evolutionary

development


Concurrent Development and Testing

Agree on time for delivery of system components

Build new version of system From these componentsBy compiling and linking them

New version delivered for testing Using pre-defined tests

Faults discovered during testing:DocumentReturn to system developers


Daily System Building

Continuous regression testingEasier to find problems stemming from

component interactions early in processEncourages thorough unit testing

Developers under pressure not to ‘break build’

Stringent change management processKeep track of problems that have been

discovered and repaired


Configuration Management Planning (1)

All products of software process may have to be managedSpecificationsDesignsProgramsTest dataUser manuals

Thousands of separate documents generated for a large software system


CM Planning (2)

Starts during early phases of projectFormal documents

Define documents or document classes which are to be managed

Include documents for future system maintenance


CM Plan: Definition Phase

Types of documents to be managed Document naming schemeWho takes responsibility for CM procedures

and creation of baselinesPolicies for change control and version

managementCM records which must be maintained


CM Plan: Tools

Describes tools which should be used to assist CM process Including any limitations on their use

Defines Process of tool useCM database used to record configuration

informationMay include information such as

CM of external software, process auditing, etc.


Configuration Item Identification

Large projects typically produce thousands of documents which must be uniquely identified

Some of these documents must be maintained for lifetime of software

Document-naming scheme should be defined so related documents have related names.

A hierarchical scheme with multi-level names probably most flexible approach


Configuration Hierarchy


Configuration Database

All CM information should be maintained in a configuration database

Should allow queries about configurations to be answeredWho has a particular system version?What platform required for a particular

version?What versions affected by a change to

specific component?How many reported faults in version?

CM database should preferably be linked to software being managed (see next slide)


CM Database Implementation

May be part of an integrated environment to support software development. CM database and managed documents all

maintained on same systemCASE tools may be integrated

Close relationship between CASE tools and CM tools

More commonly, CM database maintained separatelyCheaper and more flexible


Topics



Change Management

Software systems subject to continual change requestsFrom usersFrom developersFrom market forces

Change management concerned with Managing these changes Ensuring cost-effective implementation


Change Management Process


Change-Request Form (1)Records suggestion / request

Change requiredSuggester of changeReason for suggested changeUrgency of change

Records analysis / responseChange evaluationImpact analysisChange costRecommendations

from suggester’s point of view

from system maintenance staff point of

view


Change Request Form (2)






Change-Tracking Tools

Tracking change status How far along is a particular change

request?Major problem in change management

Change-tracking tools Keep track of status of each change

requestAutomatically ensure change requests

sent to right people at right time Integrated with E-mail systems

Electronic change-request distribution


Change-Control Board

External group May include representatives from client

and contractor staffIndependent of project Responsible for system

Decide whether or not proposed changes are cost-effective Strategic and organizational viewpoint Rather than a technical viewpointShould it be done, not just can it be done


Derivation History

Record of changes applied to a document or code componentChange madeRationale for changeWho made changeWhen it was implemented

May be included as a comment in codeStandard prologue style may be used for

derivation history (see next slide)Change-management tools can process

automatically for reports


Component Header Information


Topics



Version and Release Management

Invent identification scheme for system versions

Plan when new system version to be produced

Ensure version management procedures and tools properly applied

Plan and distribute new system releases


Versions/Variants/Releases

VersionInstance of a system functionally distinct

in some way from other system instancesVariant

Functionally identical but non-functionally distinct from other instances of a system

Release Distributed to users outside of

development team


Version Identification

Unambiguous way of identifying component versions

Three basic techniques for component identificationVersion numberingAttribute-based identificationChange-oriented identification


Version Numbering

Names (“Alpha”, “Cougar”) not meaningfulHierarchical naming scheme may be betterSimple naming scheme uses a linear

derivatione.g. V1, V1.1, V1.2, V2.1, V2.2 etc.

Actual derivation structure a tree or a network rather than a sequence


Version Derivation Structure

Don’t make assumptions about origins

based on version numbers


Attribute-Based Identification

Attributes can be associated with a version Combination of attributes identifies

versionExamples of attributes

Date, Creator, Programming Language, Customer, Status etc.

More flexible than an explicit naming scheme for version retrieval

But can cause problems with uniquenessNeeds an associated name for easy reference


Attribute-Based Queries

Important advantage of attribute-based identification:Can support queries Can find ‘ most recent version in Java’ etc.

Example: AC3D language =Javaplatform = NT4date = Jan 1999


Change-Oriented Identification Integrates versions and changes made to

create these versionsUsed for systems rather than componentsEach proposed change assigned to a change

setApplied in sequence to a baseline versionAny version of system incorporating any

arbitrary set of changes may be createdSimilar in concept to change-log for

insurance policiesCan reconstitute policy at any time by

implementing changes one by one


Release Management

Releases incorporate changes forced on systemErrors discovered by usersOperating system changesHardware changesNew system functionality

Release planning concerned with when to issue a system version as a release


System Releases

Not just a set of executable programsMay also include

Configuration files defining how release configured for particular installation

Data files needed for system operationAn installation program or shell script to

install system on target hardwareElectronic and paper documentationPackaging and associated publicity

Systems now normally released on CD-ROM or as downloadable installation files from Web


Release Problems

Customer may not want a new release of systemCurrent system may be adequate / stableNew version may provide unwanted

functionalityNew versions may have bad reputation for

poor quality assuranceWhat is the baseline for installing new version?

Not all previous releases may have been installed

Release should be self-contained: all needed files re-created when a new release installed


Release Decision-Making

Preparing and distributing a system release an expensive process

Factors influencing decision of when to issue a new system releaseCustomer change requestsTechnical quality

Of existing system (consider legal liability for execrable code)

Of new versionCompetitionMarketing requirements


System Release Strategy


Release Creation

Release creation Collect all files and documentation

required to create a system releaseConfiguration descriptions

Write for different hardwareWrite installation scripts

Specific release must be documentedExactly what files used to create itAllows it to be re-created if necessary


Topics



System Building

Process of compiling and linking software components into an executable system

Different systems built from different combinations of components

Invariably supported by automated tools driven by ‘build scripts’


System-Building Problems (1)Do build instructions include all required

components?When there many hundreds of components

making up a system, easy to miss oneShould normally be detected by linker

Appropriate component version specified?More significant problemSystem built with wrong version may work

initially but fail after deliveryAll data files available?

Do not rely on ‘standard’ data filesStandards vary from place to place


System-Building Problems (2)Data file references within components correct?

Embedding absolute names in code almost always causes problems

File-naming conventions differ from place to place

System being built for right platform?Specific OS version or hardware configuration

Right version of compiler and other software tools specified?Different compiler versions may generate

different codeCompiled component will exhibit different

behavior under different compilers


System Building


System Representation

Where are the components for the build? Usually specifying file name to be processed

by building toolsDependencies between these described to

building toolsBut programmers can lose track of which

objects stored in which files – cause errorsSystem modeling language addresses problem

Uses logical rather than physical system representation; e.g., input_module_source instead of input_module.c

Map to a database which translates self-describing names into specific files automatically


Topics



CASE Tools for Configuration ManagementCM processes standardized and involve

applying pre-defined proceduresLarge amounts of data must be managedCASE tool support for CM therefore essentialMature CASE tools to support configuration

management available ranging fromStand-alone tools to Integrated CM workbenches


Change-Management Tools

Change management a procedural processCan be modeled and integrated with a version-

management systemChange-management tools

Form editorSupport processing of change-request forms

Workflow systemDefine who does whatAutomate information transfer

Change databaseManages change proposalsLinked to version-management system


Version-Management Tools

Version and release identificationAssign identifiers automatically when a new

version submitted to systemStorage management

Stores differences between versions Allows recovery of previous versions

Change-historyRecord reasons for version creation

Independent developmentOnly one version of specific component may

be checked out for change – prevent trashingSupports parallel work on different versions

See next slide


Delta-Based Versioning


System Building

Building a large system computationally expensive – may take several hoursHundreds of files may be involved

System building tools may provideA dependency-specification language and

interpreterTool selection and instantiation supportDistributed compilationDerived object management


Dependency-Specification Language and Interpreter

Keep track of all relationships among components

Database models recursion

Component Parent Child

A - B

B A C

C B -

Component Attributes

A …

B …

C …


Component DependenciesProgra

mObject

modules

Source code

modules

Declarations file


Tool Selection and Instantiation Support

May need different compilers for different modulesC++, C, Pascal, Forth, Ada, Fortan, Cobol…Different versions of compilers

May require specific libraries for particular modulesStandard I/O librariesGUI functionsStatistical routines

Can keep track of requirements & activate as needed


Distributed Compilation

Parallel processingUse available processors on networkInitiate and control parallel compilations

on different computersAssemble results

Can be much faster than relying on a single processor


Derived Object Management

For every component, identify whether it needs to be recompiledDon’t recompile modules without changesDon’t re-link objects unless some of

components have changedMethods for identifying changes

Date of last modificationBut this may have nothing to do with

actual change in sourceTags relating to real changes in source

code


Homework

REQUIRED: by Monday 28 April (at the Business & Mgmt office by noon)Exercise 29.3 for 10 points29.7 for 5 points (5 factors @ 1 point each)29.8 for 4 points (2 ways @ 2 points each)

OPTIONAL: by Wednesday 30 April (at the Business & Mgmt office by noon) – any of 29.1 @ 2 points29.2 @ 10 points29.4 @ 2 points29.5 @ 1 point


DISCUSSION

Date post:	13-Dec-2015
Category:	Documents
Upload:	georgiana-harrison
View:	216 times
Download:	2 times

Configuration Management Structured System Design II – 302 Lecture # 27 – 2003-04-28 The Last...

Documents