Software Configuration Management These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The “First Law” No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Bersoff, et al, 1980 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

What Are These Changes? (SWE 27.1) changes in product Requirements or business rules changes in user requirements changes in organization other documents changes in budget or schedule software models Project Plan data Test code These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The Software Configuration programs documents The pieces data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The Software Configuration Software Process Output is divided into three categories Computer Programs (PROGRAMS) Work products that describe the computer programs (DOCUMENTS) Data (within the program or external to it) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Baselines (SWE 27.1.3) The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. a baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration items and the approval of these SCIs that is obtained through a formal technical review These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Baselines These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Software Configuration Objects (SWE 27.1.4) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The SCM Process The SCM process defines a series of tasks that have the following primary objectives: Identify all items that collectively defines the software configuration. Manage changes to one or more of these items. Facilitate the construction of different versions of an application. Ensure that software quality is maintained as the configuration evolves over time. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The SCM Process Addresses the following questions … How does a software team identify the discrete elements of a software configuration? How does an organization manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently? How does an organization control changes before and after software is released to a customer? Who has responsibility for approving and ranking changes? How can we ensure that changes have been made properly? What mechanism is used to appraise others of changes that are made? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

The SCM Process (SCM Tasks) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Version Control Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process A version control system implements or is directly integrated with four major capabilities: a project database (repository) that stores all relevant configuration objects a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions); a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Version Control Some version control systems establish a change set, that includes A collection of all changes to some baseline configuration that are required to create a specific version. All changes to all files in the configuration along with reason for changes. Details of who made the changes and when. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Change Control STOP These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Change Control We face a balancing act: Too much change control  we create problems Too little change control  we create other problems These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Change Control Process—I need for change is recognized change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed change control process—II These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Change Control Process-II assign people to SCIs check-out SCIs make the change review/audit the change establish a “baseline” for testing change control process—III These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Change Control Process-III perform SQA and testing activities check-in the changed SCIs promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Auditing SCM Audit Change Requests SQA Plan SCIs These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

Auditing Complement the formal technical review by addressing the following questions: Has the change specified in the ECO (Engineering Change Order) been made? Have additional modifications been incorporated? Has a formal technical review been followed to assess technical correctness? Has the software process been followed, and have software engineering standards been properly applied? Has the change been highlighted in the SCI? Have the change date 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 SCIs been properly updated? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

SCM Standards (SWE, Info page 797) IEEE standards IEEE 828 Software Configuration Management plans IEEE 1042 Software Configuration Management ISO standards ISO 10007-1995 Quality Management, Guidance for CM ISO/IEC 12207 Information Technology, Software Life Cycle Processes ISO/IEC TR 15271 Guide for ISO/IEC 12207 EIA (Electronic Industrial Alliance) standards U.S. Military standards …. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005