1. Tempus Software Maintenance and Evolution JMSE-SM&E Unit 3: Configuration and Change Management Prof. Mohammad A. Mikki Gaza, Palestine, 5.8.2014

2. Joint Master in Software Engineering “Software Maintenance and Evolution” Course Unit 3 Configuration and Change Management Software Maintenance and Evolution 2

3. Joint Master in Software Engineering Introduction  The objective of software configuration management is to establish and maintain the integrity of the software project throughout the project's software life cycle. This unit explains software configuration management, its definition, its tasks, its process, its plan.  Software configuration management tasks include change management and control, version control, auditing, and documentation.  Once you have completed this unit, you should be able to apply the Configuration Change Management process in the life cycle of software. Course Title 3

4. Joint Master in Software Engineering Course Title Objectives  To explain the importance of software configuration management  To describe key configuration management tasks such as planning, change management, version management and system building  To implement projects in configuration and change management  To analyse systems in regards to configuration and change management  To understand configuration identification  To understand configuration auditing  To generate code reports and documents  To understand configuration management tools 4

5. Joint Master in Software Engineering Course Title List of Topics  What is configuration management  Configuration management plan  Configuration identification  Change control  Version and release control  Configuration auditing  Software documentation  Configuration management tools 5

6. Joint Master in Software Engineering Course Title Introduction to Configuration Management (CM)  Software systems are subject to continual change requests: -From users -From developers -From market forces  New versions of software systems are created as they change: -For different machines/OS -Offering different functionality -Tailored for particular user requirements. 6

7. Joint Master in Software Engineering Course Title Introduction to Configuration Management (Cont.)  A software project produces many items such as: -programs -Documents -Data -Manuals, etc.  These items are subject to continual change  We need to keep track of the state of these items 7

8. Joint Master in Software Engineering Course Title Configuration Management Definition Configuration management is concerned with keeping track of software systems continual changes and ensuring that they are implemented in the most cost-effective way. 8

9. Joint Master in Software Engineering Course Title  Change is inevitable - Need to keep the inevitable change under control  Many developers contribute to build a software system, and many versions of the software could exist. -There could be bugs that need to be fixed -Changes need to be made to correct errors, provide enhancements, or reflect the continued refinement of the software system 9 Why Configuration Management?

10. Joint Master in Software Engineering Course Title  Configuration management tasks occur throughout the life cycle of the project (software development) 10 When to Make Configuration Management

11. Joint Master in Software Engineering Course Title  Users, developers, or market needs suggest required system changes  Software administration decides if changes should be included in the system  Stakeholders reporting their needs  Software to keep track of suggested changes and their status is required  Software support for managing changing system configurations and building new systems is needed 11 Configuration Management Requirements

12. Joint Master in Software Engineering Software Configuration Management Tasks  Identification: -tracking multiple versions to enable efficient changes -identifying software configuration items in a baseline  Version control: -control changes before and after release to customer  Change control: -authority to approve and prioritize changes  Configuration auditing: -ensure changes made properly -Validating the completeness of a product and that SCM procedures are being followed  Reporting: -tell others about changes made

13. Joint Master in Software Engineering Relation Between CM and Development Process Other Processes 13

14. Joint Master in Software Engineering  All CM information should be maintained in a configuration database.  CM database allows issuing queries about configuration -Who has a particular system version? -What platform is required for a particular version? -What versions are affected by a change to component X? -How many reported faults are in version X?  The CM database is linked to the software being managed. Configuration Management Database

15. Joint Master in Software Engineering Software Configuration Item Basics  Large projects typically produce thousands of entities such as: - Files - Documents - data  All these entities must be uniquely identified  Some items must be maintained for the lifetime of the software  Selecting the right configuration items is a skill that takes practice

16. Joint Master in Software Engineering Software Configuration Item Definition  A configuration item is: -a piece of software or work product which is subject to change. -an aggregation of hardware, software, or both, that is designated for configuration management  It is treated as a single entity in the configuration management process  Software consists of many such items

17. Joint Master in Software Engineering Configuration Item Examples  Computer programs: both source code and executable  Database descriptions  Documentation: code documents, software test documents, maintenance documents  Data: within a program or external to it  Manuals: both developer, and user manuals  System configurations (e.g. version of compiler used)

18. Joint Master in Software Engineering  Product concept specification  Software project plans  Software requirements specifications  Software design descriptions  SCM procedures  Software release processes Configuration Item Examples (Cont.)

19. Joint Master in Software Engineering Configuration Items Tracking Changes to configuration items are tracked  Periodically, system is built using these items and baselines are established Other Processes 19

20. Joint Master in Software Engineering What is a Baseline A baseline is  A reference point of the system  A logical state of the system and all its items IEEE Definition: a baseline is a specification or product that has been formally reviewed and agreed upon, and that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures [1]. Other Processes 20

21. Joint Master in Software Engineering Baseline Management It is a milestone in the development of software and is marked by the delivery of one or more computer software configuration items (CSCIs) that have been approved as a consequence of a formal technical review [2]. Other Processes 21

22. Joint Master in Software Engineering Baseline Management (Cont.)  Define baselines that need to be managed -Typically aligned with major milestones -Applies to documents as well as code  What information is required to process a change to a baseline? - A description of the proposed changes - Reasons for making the changes - List of other items affected by the changes

23. Joint Master in Software Engineering Baseline Management (Cont.)  What tools, resources, and training are required to perform baseline management? - A fully featured SCM tool - On large projects a separate SCM group may be needed - SCM training is required for all involved in the process

24. Joint Master in Software Engineering Baseline Examples [3]  Baseline A: All the API have completely been defined; the bodies of the methods are empty.  Baseline B: All data access methods are implemented and tested.  Baseline C: The GUI is implemented.

25. Joint Master in Software Engineering Baselines Properties  A work product becomes a baseline only after it is reviewed and approved.  A baseline is a milestone in software development that is marked by the delivery of one or more configuration items.  Once a baseline is established each change request must be evaluated and verified by a formal procedure before it is processed.

26. Joint Master in Software Engineering 26 Baselining Process [4] 1.A series of software engineering tasks produces a CSCI (computer software configuration item) 2.The CSCI is reviewed and possibly approved 3.The approved CSCI is given a new version number and placed in a project database (i.e., software repository) 4.A copy of the CSCI is taken from the project database and examined/modified by a software engineer 5.The baselining of the modified CSCI goes back to Step #2

27. Joint Master in Software Engineering The plan defines:  Configuration management tasks and procedures that implement configuration management activities  Schedule and cost of configuration management tasks  Roles and responsibilities of team members, who takes responsibility for the CM procedures and creation of baselines  Policies for change control and version management.  All types of documents to be managed and a document naming scheme What is Configuration Management Plan

28. Joint Master in Software Engineering The plan defines:  Items to be placed under configuration management  Baselining  Backup and disaster recovery plans and procedures  Training plan  tools which should be used to assist the CM process  configuration management database used to store configuration information  The CM records which must be maintained What is Configuration Management Plan (Cont.)

29. Joint Master in Software Engineering  Software configuration management planning phase starts during the early phases of software project  The result/outcome of the software configuration management planning phase is the software Configuration Management Plan (SCMP) When to Use Configuration Management Plan

30. Joint Master in Software Engineering The SCMP can either follow:  A public standard like 828-2012 - IEEE Standard for Configuration Management in Systems and Software Engineering), or  An internal (e.g. company specific) standard. Software Configuration Management Plan Standard

31. Joint Master in Software Engineering  This standard establishes the minimum requirements for processes for Configuration Management (CM) in systems and software engineering.  The application of this standard applies to any form, class, or type of software or system.  This revision of the standard expands the previous version to explain CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. Course Title 31 828-2012 - IEEE Standard for Configuration Management in Systems and Software Engineering [5]

32. Joint Master in Software Engineering  Its predecessor defined only the contents of a software configuration management plan.  This standard addresses what CM activities are to be done, when they are to happen in the life cycle, and what planning and resources are required.  It also describes the content areas for a CM Plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939TM Course Title 32 828-2012 - IEEE Standard for Configuration Management in Systems and Software Engineering [5]

33. Joint Master in Software Engineering Configuration Identification  Define configuration items (CI) of interest -Name CIs (identification scheme, product units/groups (lots)) -Determine CI interdependencies -Control CIs (change control)  Define product structure  Identify and control interfaces  Establish baselines (e.g., “as-required”, “as-designed”, “as-built”)

34. Joint Master in Software Engineering Course Title 34  Large projects typically produce thousands of documents which must be uniquely identified  Some of these documents must be maintained for the lifetime of the software  Document naming scheme should be defined so that related documents have related names.  A hierarchical scheme with multi-level names is probably the most flexible approach Motivation for Configuration Identification

35. Joint Master in Software Engineering  Once software product configuration is approved and baselined, changes to product configuration must be managed  Change is initiated by a change request (CR)  Change is implemented via a change order (CO) or change notice (CN)  Change is verified in order to be consistent with product configuration information Change Control

36. Joint Master in Software Engineering Change control is concerned with keeping track of changes made to software projects/systems and ensuring that they are implemented in the most cost-effective way Change Control Definition

37. Joint Master in Software Engineering Changes to software projects are inevitable:  People make mistakes  customers need changes  the environment in which the product operates evolves  Requirements change at any time during the development  market forces push for change  Developers constantly develop their knowledge of the problem and their ability to solve it Change Control Motivation

38. Joint Master in Software Engineering  Uncontrolled changes can have a huge bad impact on project in cost and schedule Changes have to be allowed, but in a controlled manner  Approved changes must be properly implemented  After changes are made all affected parties must be notified Change Control Motivation (Cont.)

39. Joint Master in Software Engineering Change control is initiated by an event:  Need for code modification  Finding something wrong during usage of the configuration item.  A wrong formulation found during the review of a document  A coding mistake found during a walk-through of a piece of source code  An enhancement request arising from a new idea from the customer during work on the project Change Control Input

40. Joint Master in Software Engineering Change control is initiated by an event:  A mistake found in the integration test  A requested enhancement of the finished product, arising once the product is in operation  An inquiry to a helpdesk about a problem in connection with usage of a system  A change required in the code because of an upgrade to a new version Change Control Input (Cont.)

41. Joint Master in Software Engineering  Change control output includes: -documented events that initiated the change control process -change requests derived from these events.  Both should be stored in a secure place (e.g., a database) so that relationships between change requests and configuration items can be maintained. Change Control Output

42. Joint Master in Software Engineering  Change is often triggered by change request -From users -From developers -Etc.  Change request log keeps a record of requests  Perform impact analysis on the work products and items  The impact of changes on the project is reviewed to decide whether to accept or reject the proposed change  changes are often tracked Other Processes 42 Change Management Process

43. Joint Master in Software Engineering Change Management Process (Cont.) [6]

44. Joint Master in Software Engineering  Change management tools may be: -stand-alone tools or -may be integrated systems which integrate support for change control, version management, system building and change management. Change Control Tools

45. Joint Master in Software Engineering  Form editor: supports processing the change request forms  Workflow system: defines who does what and to automate information transfer  Change database: manages change proposals and is linked to a CM system  Change reporting system: generates management reports on the status of change requests Change Control Tools (Cont.)

46. Joint Master in Software Engineering  There is a need for tracking change status  Change tracking tools track the status of each change request  Change tracking tools ensure that change requests are sent to the right people at the right time  Change tracking tools are integrated with e-mail systems to allow electronic change request distribution  Change tracking is major problem in change management Change Tracking Tools

47. Joint Master in Software Engineering Course Title 47 Change Control Phases 1.Creation of the event registration: The event registration is created, and the event is described 2.Analysis of the event registration: Configuration item(s) affected by possible changes are determined, and the extensiveness of these changes is estimated. 3.Rejection or acceptance of the event registration: If the event registration is accepted, a change request is created for each configuration item affected 4.The change request initiates a new configuration item: A new configuration item is identified and created, and the change is implemented. In the course of accepting the new item and placing it in storage, feedback is given to the configuration control board

48. Joint Master in Software Engineering Course Title 48 Change Control Phases (Cont.) 5. Closing of the change request: The change request can be closed when the change has been implemented and accepted 6. Closing of the event registration: The event registration can be closed when all corresponding change requests are closed

49. Joint Master in Software Engineering Version and Release Control Terminology [7] Course Title 49 Version:  The initial release or a new release of a configuration item associated with a complete compilation or of the item. Different versions have different functionality.  An instance of a system which is functionally distinct in some way from other system instances Revision:  Change to a version that corrects only errors in the code, but does not affect the documented functionality. Release:  The formal distribution of an approved version.  An instance of a system which is distributed to users outside of the development team Variant :  An instance of a system which is functionally identical but non-functionally distinct from other instances of a system

50. Joint Master in Software Engineering  Releases incorporate changes forced on the system by errors discovered by users and by hardware changes  They also incorporate new system functionality Version and Release Control Motivation

51. Joint Master in Software Engineering  Release planning is concerned with when to issue a system version as a release When to Apply Version and Release Control

52. Joint Master in Software Engineering System Release Components  A set of executable programs  Configuration files defining how the release is configured for a particular installation  Data files needed for system operation  An installation program or shell script to install the system on target hardware  documentation  Packaging and associated publicity

53. Joint Master in Software Engineering System Releases Media Systems are now normally released  on optical disks (CD or DVD) or  as downloadable installation files from the web.

54. Joint Master in Software Engineering  Generally both version and release control done through CM tools  Tools limit access to specified people - formal check in, check out procedures  Automatic versioning done when a changed file is checked-in  Check-in, check-out control may - be restricted to a few people in a project - Require successful compile/build cycle Other Processes 54 Version and Release Control Basics

55. Joint Master in Software Engineering  Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes.  They must also incorporate new system functionality.  Release planning is concerned with when to issue a system version as a release. Version and Release Control Basics (Cont.)

56. Joint Master in Software Engineering Release Creation  Release creation involves collecting all files and documentation required to create a system release  Configuration descriptions have to be written for different hardware and installation scripts have to be written  The specific release must be documented to record exactly what files were used to create it - This allows it to be re-created if necessary

57. Joint Master in Software Engineering  Invent identification scheme for system versions  Plan when new system version is to be produced  Ensure that version management procedures and tools are properly applied  Plan and distribute new system releases Version and Release Control Steps

58. Joint Master in Software Engineering Version Identification  Procedures for version identification should define an unambiguous way of identifying component versions

59. Joint Master in Software Engineering Version Identification Example [6]

60. Joint Master in Software Engineering Version Management Tools  Version and release identification: Systems assign identifiers automatically when a new version is submitted to the system.  Storage management.: System stores the differences between versions rather than all the version code.  Change history recording: Record reasons for version creation.  Independent development : Only one version at a time may be checked out for change. Parallel working on different versions.  Parallel working on different versions: Several versions at a time may be checked out for change  Project support: Can manage groups of files associated with a project rather than just single files.

61. Joint Master in Software Engineering  During project execution CM procedures have to be followed (e.g. moving items between directories, naming, following change procedures, …)  Process audit has to be done  CM audit can also check if items are where they should be Other Processes 61 Configuration Auditing

62. Joint Master in Software Engineering Configuration Auditing Definition  Configuration auditing is a CM activity that helps to ensure that quality is maintained as changes are made Course Title 62

63. Joint Master in Software Engineering Configuration Auditing Characteristics Configuration auditing ensures that:  a product conforms to its requirements and product configuration information  The correct CSCIs (by version) have been incorporated into a specific build  All documentation is up-to-date and consistent with the version that has been built Course Title 63

64. Joint Master in Software Engineering 64 Configuration auditing addresses the following questions:  Has the change specified in the change request been made?  Have any additional modifications been incorporated?  Has a formal technical review been conducted to assess technical correctness?  Has the software process been followed, and have software engineering standards been properly applied?  Has the change been "highlighted" and "documented" in the CSCI?  Have the change data and change author been specified?  Do the attributes of the configuration object reflect the change?  Have SCM procedures for noting the change, recording it, and reporting it been followed?  Have all related CSCIs been properly updated? Configuration Auditing Characteristics (Cont.)

65. Joint Master in Software Engineering  Functional configuration audit: -A formal evaluation to verify that a CI is controlled and has achieved the functional and performance characteristics specified in its product configuration information -Example: verification (test, analysis, inspection, demonstration)  Physical configuration audit: -A formal evaluation to verify that a CI has achieved the physical characteristics specified in its product configuration information -Example: comparing the as-built CIs are built as designed; differences need to be accounted for Course Title 65 Types of Configuration Auditing

66. Joint Master in Software Engineering Configuration Audit Plan For each audit/review the plan has to define:  Objective  The configuration items under review  The schedule for the review  Procedures for conducting the review  Participants by job title  Required documentation  Procedure for recording deficiencies and how to correct them  Approval criteria

67. Joint Master in Software Engineering 67 Requirements of software documentation  Should provide for communication among team members  Should act as an information repository to be used by maintenance engineers  Should provide enough information to management to allow them to perform all program management related activities  Should describe to users how to operate and administer the system  In all software projects some amount of documentation should be created prior to any code being written  Documentation should continue after the code has been completed - User’s manuals, etc. Software Documentation

68. Joint Master in Software Engineering (c) 2007 Mauro Pezzè & Michal Young Ch 24, slide 68 Major Categories of Documents  Planning documents -Describe the organization of the quality process -Include organization strategies and project plans  Specification documents - Describe test suites and test cases - Test design specifications, test case specification, checklists, analysis procedure specifications  Reporting documents - Detail and summarize analysis and test results

69. Joint Master in Software Engineering Document Structure  All documents for a given product should have a similar structure  The IEEE Standard for User Documentation lists such a structure - It is a superset of what most documents need  The best practices are: 1.Put a cover page on all documents 2.Divide documents into chapters with sections and subsections 3.Add an index if there is lots of reference information 4.Add a glossary to define ambiguous terms

70. Joint Master in Software Engineering Configuration Management Tools CASE tools  Computer-Aided Software Engineering (CASE)  CASE is basically the use of computer-based support by developers to develop and maintain software, especially on larger scale, or for more complex projects  Tool support for CM is essential.  CASE tools are used to support configuration management  CASE tools are available ranging from stand-alone tools to integrated CM workbenches.

71. Joint Master in Software Engineering CASE tools are classified into:  Upper CASE tools, and  Lower CASE tools. CASE Tools Classification

72. Joint Master in Software Engineering  Focus on the beginning stages of system development, such as planning, objective, and goals.  The information necessary is gathered, and through upper CASE tools, is then presented in an organized way. The Upper Case Tools

73. Joint Master in Software Engineering  Focus on later parts of system development, such as designing, coding, testing the software for defects and functionality, implementation and maintaining the software.  These latter stages are often not what we think of when we think of software design, but testing and maintaining in fact play a huge role in software development. Lower CASE Tools

74. Joint Master in Software Engineering References [1] Taz Daughtrey, Editor, Fundamental Concepts for the Software Quality Engineer, ASQ Quality Press, 2002 [2] Ashima Wadhwa, Software Configuration Management, https://lesexploreit.files.wordpress.com/2015/12/configuration-management- introduction.pdf [3] Addindum zu Kapitel, Software Configuration Management, Department of Informatics, University of Zurich, https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/software_engineering_ hs07/folien/ch23-SCM-addendum.pdf [4] Pressman R., Software Engineering: A Practitioner’s Approach. Chapter 27: Change Management, McGraw-Hill, 2005 [5] Software & Systems Engineering Standards Committee, IEEE Standard for Configuration Management in Systems and Software Engineering, IEEE Computer Society, 16 March 2012 Course Title 74

75. Joint Master in Software Engineering References [6] Ian Sommerville, Software Engineering, sixth Edition, Chapter 29: Configuration Management, Addison Wesley Publishing Company, 2000 [7] Bernd Bruegge and Allen Duttoit, Object-Oriented Software Engineering Using UML, Patterns and Java, Chapter 13: Configuration Management, Third Edition, Prentice Hall, 2013. Course Title 75

76. Tempus Thank you for your attention.