configuration management structured system design ii – 302 lecture # 27 – 2003-04-28 the last...
TRANSCRIPT
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]
2 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management
3 Copyright © 2003 M. E. Kabay. All rights reserved.
Configuration Management
Managing products of system change
4 Copyright © 2003 M. E. Kabay. All rights reserved.
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
5 Copyright © 2003 M. E. Kabay. All rights reserved.
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
7 Copyright © 2003 M. E. Kabay. All rights reserved.
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
8 Copyright © 2003 M. E. Kabay. All rights reserved.
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
9 Copyright © 2003 M. E. Kabay. All rights reserved.
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
10 Copyright © 2003 M. E. Kabay. All rights reserved.
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
11 Copyright © 2003 M. E. Kabay. All rights reserved.
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
12 Copyright © 2003 M. E. Kabay. All rights reserved.
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
13 Copyright © 2003 M. E. Kabay. All rights reserved.
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.
14 Copyright © 2003 M. E. Kabay. All rights reserved.
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
16 Copyright © 2003 M. E. Kabay. All rights reserved.
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)
17 Copyright © 2003 M. E. Kabay. All rights reserved.
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
18 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management
19 Copyright © 2003 M. E. Kabay. All rights reserved.
Change Management
Software systems subject to continual change requestsFrom usersFrom developersFrom market forces
Change management concerned with Managing these changes Ensuring cost-effective implementation
21 Copyright © 2003 M. E. Kabay. All rights reserved.
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
25 Copyright © 2003 M. E. Kabay. All rights reserved.
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
26 Copyright © 2003 M. E. Kabay. All rights reserved.
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
27 Copyright © 2003 M. E. Kabay. All rights reserved.
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
29 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management
30 Copyright © 2003 M. E. Kabay. All rights reserved.
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
31 Copyright © 2003 M. E. Kabay. All rights reserved.
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
32 Copyright © 2003 M. E. Kabay. All rights reserved.
Version Identification
Unambiguous way of identifying component versions
Three basic techniques for component identificationVersion numberingAttribute-based identificationChange-oriented identification
33 Copyright © 2003 M. E. Kabay. All rights reserved.
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
34 Copyright © 2003 M. E. Kabay. All rights reserved.
Version Derivation Structure
Don’t make assumptions about origins
based on version numbers
35 Copyright © 2003 M. E. Kabay. All rights reserved.
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
36 Copyright © 2003 M. E. Kabay. All rights reserved.
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
37 Copyright © 2003 M. E. Kabay. All rights reserved.
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
38 Copyright © 2003 M. E. Kabay. All rights reserved.
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
39 Copyright © 2003 M. E. Kabay. All rights reserved.
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
40 Copyright © 2003 M. E. Kabay. All rights reserved.
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
41 Copyright © 2003 M. E. Kabay. All rights reserved.
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
43 Copyright © 2003 M. E. Kabay. All rights reserved.
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
44 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management
45 Copyright © 2003 M. E. Kabay. All rights reserved.
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’
46 Copyright © 2003 M. E. Kabay. All rights reserved.
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
47 Copyright © 2003 M. E. Kabay. All rights reserved.
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
49 Copyright © 2003 M. E. Kabay. All rights reserved.
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
50 Copyright © 2003 M. E. Kabay. All rights reserved.
Topics
Configuration Management PlanningChange ManagementVersion and Release ManagementSystem BuildingCASE Tools for Configuration Management
51 Copyright © 2003 M. E. Kabay. All rights reserved.
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
52 Copyright © 2003 M. E. Kabay. All rights reserved.
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
53 Copyright © 2003 M. E. Kabay. All rights reserved.
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
55 Copyright © 2003 M. E. Kabay. All rights reserved.
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
56 Copyright © 2003 M. E. Kabay. All rights reserved.
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 …
57 Copyright © 2003 M. E. Kabay. All rights reserved.
Component DependenciesProgra
mObject
modules
Source code
modules
Declarations file
58 Copyright © 2003 M. E. Kabay. All rights reserved.
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
59 Copyright © 2003 M. E. Kabay. All rights reserved.
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
60 Copyright © 2003 M. E. Kabay. All rights reserved.
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
61 Copyright © 2003 M. E. Kabay. All rights reserved.
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