Configuration Management Structured System Design II – 302 Lecture # 27 – The Last Lecture of the Course! M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University

2 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Configuration Management Planning Configuration Management Planning  Change Management Change Management  Version and Release Management Version and Release Management  System Building System Building  CASE Tools for Configuration Management CASE 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 change  For different machines/OS  Offering different functionality  Tailored for particular user requirements  Configuration management concerned with managing evolving software systems  System change a team activity  CM 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 to  Manage an evolving software product  Part of more general quality management process  When released to CM, software systems sometimes called baselines  Starting point for further development

6 Copyright © 2003 M. E. Kabay. All rights reserved. System Families

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 how  Items identified  Changes 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 model  New 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 components  By compiling and linking them  New version delivered for testing  Using pre-defined tests  Faults discovered during testing:  Document  Return to system developers

9 Copyright © 2003 M. E. Kabay. All rights reserved. Daily System Building  Continuous regression testing  Easier to find problems stemming from component interactions early in process  Encourages thorough unit testing  Developers under pressure not to ‘break build’  Stringent change management process  Keep 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 managed  Specifications  Designs  Programs  Test data  User 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 project  Formal 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 scheme  Who takes responsibility for CM procedures and creation of baselines  Policies for change control and version management  CM 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 use  CM database used to record configuration information  May 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

15 Copyright © 2003 M. E. Kabay. All rights reserved. Configuration Hierarchy

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 answered  Who 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 system  CASE tools may be integrated  Close relationship between CASE tools and CM tools  More commonly,  CM database maintained separately  Cheaper and more flexible

18 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Configuration Management Planning  Change Management  Version and Release Management  System Building  CASE Tools for Configuration Management

19 Copyright © 2003 M. E. Kabay. All rights reserved. Change Management  Software systems subject to continual change requests  From users  From developers  From market forces  Change management concerned with  Managing these changes  Ensuring cost-effective implementation

20 Copyright © 2003 M. E. Kabay. All rights reserved. Change Management Process

21 Copyright © 2003 M. E. Kabay. All rights reserved. Change-Request Form (1)  Records suggestion / request  Change required  Suggester of change  Reason for suggested change  Urgency of change  Records analysis / response  Change evaluation  Impact analysis  Change cost  Recommendations from suggester’s point of view from system maintenance staff point of view

22 Copyright © 2003 M. E. Kabay. All rights reserved. Change Request Form (2)

23 Copyright © 2003 M. E. Kabay. All rights reserved. Change Request Form (3)

24 Copyright © 2003 M. E. Kabay. All rights reserved. Change Request Form (4)

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 request  Automatically ensure change requests sent to right people at right time  Integrated with 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 staff  Independent of project  Responsible for system  Decide whether or not proposed changes are cost-effective  Strategic and organizational viewpoint  Rather than a technical viewpoint  Should 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 component  Change made  Rationale for change  Who made change  When it was implemented  May be included as a comment in code  Standard prologue style may be used for derivation history (see next slide)  Change-management tools can process automatically for reports

28 Copyright © 2003 M. E. Kabay. All rights reserved. Component Header Information

29 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Configuration Management Planning  Change Management  Version and Release Management  System Building  CASE 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  Version  Instance of a system functionally distinct in some way from other system instances  Variant  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 identification  Version numbering  Attribute-based identification  Change-oriented identification

33 Copyright © 2003 M. E. Kabay. All rights reserved. Version Numbering  Names (“Alpha”, “Cougar”) not meaningful  Hierarchical naming scheme may be better  Simple naming scheme uses a linear derivation  e.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 version  Examples of attributes  Date, Creator, Programming Language, Customer, Status etc.  More flexible than an explicit naming scheme for version retrieval  But can cause problems with uniqueness  Needs 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 =Java  platform = NT4  date = Jan 1999

37 Copyright © 2003 M. E. Kabay. All rights reserved. Change-Oriented Identification  Integrates versions and changes made to create these versions  Used for systems rather than components  Each proposed change assigned to a change set  Applied in sequence to a baseline version  Any version of system incorporating any arbitrary set of changes may be created  Similar in concept to change-log for insurance policies Can 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 system  Errors discovered by users  Operating system changes  Hardware changes  New 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 programs  May also include  Configuration files defining how release configured for particular installation  Data files needed for system operation  An installation program or shell script to install system on target hardware  Electronic and paper documentation  Packaging 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 system  Current system may be adequate / stable  New version may provide unwanted functionality  New versions may have bad reputation for poor quality assurance  What 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 release  Customer change requests  Technical quality Of existing system (consider legal liability for execrable code) Of new version  Competition  Marketing requirements

42 Copyright © 2003 M. E. Kabay. All rights reserved. System Release Strategy

43 Copyright © 2003 M. E. Kabay. All rights reserved. Release Creation  Release creation  Collect all files and documentation required to create a system release  Configuration descriptions  Write for different hardware  Write installation scripts  Specific release must be documented  Exactly what files used to create it  Allows it to be re-created if necessary

44 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Configuration Management Planning  Change Management  Version and Release Management  System Building  CASE 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 one  Should normally be detected by linker  Appropriate component version specified?  More significant problem  System built with wrong version may work initially but fail after delivery  All data files available?  Do not rely on ‘standard’ data files  Standards 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 code  Compiled component will exhibit different behavior under different compilers

48 Copyright © 2003 M. E. Kabay. All rights reserved. System Building

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 tools  Dependencies between these described to building tools  But programmers can lose track of which objects stored in which files – cause errors  System 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 Planning  Change Management  Version and Release Management  System Building  CASE Tools for Configuration Management

51 Copyright © 2003 M. E. Kabay. All rights reserved. CASE Tools for Configuration Management  CM processes standardized and involve applying pre-defined procedures  Large amounts of data must be managed  CASE tool support for CM therefore essential  Mature CASE tools to support configuration management available ranging from  Stand-alone tools to  Integrated CM workbenches

52 Copyright © 2003 M. E. Kabay. All rights reserved. Change-Management Tools  Change management a procedural process  Can be modeled and integrated with a version- management system  Change-management tools  Form editor Support processing of change-request forms  Workflow system Define who does what Automate information transfer  Change database Manages change proposals Linked to version-management system

53 Copyright © 2003 M. E. Kabay. All rights reserved. Version-Management Tools  Version and release identification  Assign identifiers automatically when a new version submitted to system  Storage management  Stores differences between versions  Allows recovery of previous versions  Change-history  Record reasons for version creation  Independent development  Only one version of specific component may be checked out for change – prevent trashing  Supports parallel work on different versions See next slide

54 Copyright © 2003 M. E. Kabay. All rights reserved. Delta-Based Versioning

55 Copyright © 2003 M. E. Kabay. All rights reserved. System Building  Building a large system computationally expensive – may take several hours  Hundreds of files may be involved  System building tools may provide  A dependency-specification language and interpreter  Tool selection and instantiation support  Distributed compilation  Derived 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 ComponentParentChild A-B BAC CB- ComponentAttributes A… B… C…

57 Copyright © 2003 M. E. Kabay. All rights reserved. Component Dependencies Progra m Object modules Source code modules Declaration s file

58 Copyright © 2003 M. E. Kabay. All rights reserved. Tool Selection and Instantiation Support  May need different compilers for different modules  C++, C, Pascal, Forth, Ada, Fortan, Cobol…  Different versions of compilers  May require specific libraries for particular modules  Standard I/O libraries  GUI functions  Statistical routines  Can keep track of requirements & activate as needed

59 Copyright © 2003 M. E. Kabay. All rights reserved. Distributed Compilation  Parallel processing  Use available processors on network  Initiate and control parallel compilations on different computers  Assemble 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 recompiled  Don’t recompile modules without changes  Don’t re-link objects unless some of components have changed  Methods for identifying changes  Date of last modification But this may have nothing to do with actual change in source  Tags 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 points  29.7 for 5 points (5 1 point each)  29.8 for 4 points (2 2 points each)  OPTIONAL: by Wednesday 30 April (at the Business & Mgmt office by noon) – any of  2 points  10 points  2 points  1 point

62 Copyright © 2003 M. E. Kabay. All rights reserved. DISCUSSION