Change control during production

These may be on entirely separate servers, or different disk partitions, or by some other mechanism, but the goal is to make it physically clear which code is currently being revised, which code is currently being tested, and which code is currently regarded as completed and approved.

The developers create and modify routines in the development area, following the specifications and design documents created earlier in the process. As they make changes to a routine/module, the developers update a log file which contains the development history of the code segment. This will include information about who created it and when, who modified it, when, and why.

When developers believe a routine or module is complete, they submit that version for testing and go on to work on something else.

The testers will either approve the routine/module or return it to the development groups with problem reports.

If the routine/module passes the testers and is approved, then it is moved to the production area for the next release.

Many software development systems support tracking the state of different routines and modules in such a form, as well as supporting the logging of file modification information (again, who changed it, when, what changes were made, and why those changes were made).

Configuration management

The mechanics supporting integrity during change

• New versions of software systems are created as they evolve: for different operating systems, or machines, offering different functionality, tailored for particular user requirements.
• Configuration management (CM) is concerned with managing evolving software systems: system change is a team activity, CM aims to control the costs and effort involved in making changes to a system.

  Somehow, all modifications to the software system (including all documentation, data, and training material) must be identified, organized, and controlled.

• Involves the development and application of procedures and standards to manage an evolving software product.
• May be seen as part of a more general quality management process.
• Includes as general goals
  • The identification of changes
  • Control of changes - with respect to which changes are made, where they are applied and by who, and how we ensure the changes are implemented "properly"
  • Reporting of changes to others who may be affected by them
• When released to CM, software systems are sometimes called baselines as they are a starting point for further development (i.e. further change).

  The IEEE definition of a "baseline" is 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.

• The sequence of events for a change might look something like:
  1. Someone identifies a change they feel is needed (e.g. adaptive/corrective/enhancement maintenance) and generates a change request
  2. The request is evaluated by a member of the development group and generates a change report
  3. The change report is evaluated by the change control authority (e.g. project admin, or task leader), and either the requested change is denied (and the initiator informed) or is approved

     The rest of this sequence assumes the change request has been approved

  4. Individuals are assigned to those objects under configuration control which must be changed
  5. The individuals "check out" the objects (so no one else can alter the objects at the same time)
  6. The changes are applied
  7. The changes are reviewed/audited
  8. The objects are "checked in"
  9. The changes are tested
  10. The software is rebuilt if appropriate
  11. The cumulative set of changes to all the configuration objects is reviewed/audited
  12. The changes are included in the new version
  13. The new version is distributed
• Some of the items that may fall under formal change control include
  • The project plan
  • The requirements and specifications document(s)
  • The user manual(s)
  • The design specification document(s)
  • The source code listings
  • The test plan, test cases, and recorded results
  • The operation and installation manual(s)
  • The executable program
  • The database description document(s)
  • The bug reports, maintenance requests, and change orders
  • The standards and procedures documents
• Reviews/audits are geared towards the following
  • Ensuring the requested change has been made, and that only the requested change has been made
  • Ensuring a formal technical review has assessed the change
  • Ensuring that all the defined standards have been followed
  • Ensuring that the change has been clearly identified in the appropriate documentation and all appropriate configuration items updated
  • Ensuring that the change information (author, date, etc) has been properly recorded

• Configuration management planning
  • All products of the software process may have to be managed: specifications, designs, programs, test data, user manuals.
  • Thousands of separate documents are generated for a large software system.
  • Starts during the early phases of the project.
  • Must define the documents or document classes which are to be managed.
  • Documents which might be required for future system maintenance should be identified and specified as managed documents.

• Configuration item identification
  • 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.

• CM database
  • All CM information should be maintained in a CM database.
  • Should allow queries about configurations to be answered. 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 in version T?

• Derivation history
  • Record of changes applied to a document or code component.
  • Should record, in outline, the changes made, the rationale for the change, who made the change and when it was implemented.
  • May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically.

• Version and release management
  • CM should allow a user to specify a variety of possible configurations of the software by selecting from different available versions - each supported by all the appropriate tools and documentation.
  • 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/variants/releases
  • Version: an instance of a system which is functionally distinct in some way from other system instances.
  • Variant: an instance of a system which is functionally identical but non-functionally distinct from other instances of a system.
  • Release: an instance of a system which is distributed to users outside of the development team.

• Attributed version identification
  • Attributes can be associated with a version with the combination of attributes identifying that version.
  • Examples of attributes: Date, Creator, Programming Language, Customer, Status, etc.
  • More flexible than an explicit naming scheme for version retrieval, can cause problems with uniqueness.
  • Needs an associated name for easy reference.

• System building
  • Involves taking all system components and combining them into a single executable system.
  • Different systems are built from different component combinations.
  • May take several days for large systems if all components are compiled and linked at the same time.
  • Ideally, when something changes we only want to recompile material directly dependent on the change
  • Different development interfaces supply differing degrees of automation for this process (e.g. to use unix makefiles you must specify the dependencies manually once, after that the appropriate files can be rebuilt automatically with a single make command, on the other hand full-fledged software development/maintenance environments usually track and compile these dependencies without user specification/intervention)
  • Generally, systems recompile based on either
    • changes to a file: the changed file must be recompiled as must all files dependent on in (e.g. those that #include it in C/C++)
    • changes to an object or logical module: the changed object/module must be recompiled, as must all objects/modules dependent on it
  • the latter option gives better compilation times, but requires a more sophisticated development environment

  Change tools available for small projects

  RCS on csciun1	CVS on csciun1
  RCS - Revision Control System Relatively old system but still widely used. Basic concepts: checkout (co command) a file when you want to work on it, when you're finished check it back in again (ci command). On check in enter a log message. Can view logs and check out any version at any time. (See man rcsintro on engr.) need a directory named RCS to work in co filename to check out a file for reading co -l filename to check out a file for editing ci filename to check it back in rcsdiff filename to get a summary of the changes you made ci -r2.1 filename to check out version 2.1 of the file (RCS automatically tracks all the different versions created) Minimises the disk requirements by only storing differences (deltas) from a base version. Applies deltas to the latest release to recreate earlier system versions. Allows any named version or release to be generated. Allows independent development of different releases by allowing version tree to be forked and merged again later. Limitations: Designed as a code control system therefore intended for use with ASCII text. Cannot be used to manage object code or other documents with non-ASCII representations (e.g., multimedia files). Text-based user interface, version browsing is difficult. Mitigated by good interactions with other systems like emacs for viewing and modifying files with automatic checkin and checkout. Version retrieval based on the name rather than the version attributes.	CVS a slightly modernized version of RCS (see data on the left) info cvs - gives documentation/help on the system .cvsrc - configuration file to set up default options cvs globaloptions command commandoptions arguments - general format of a cvs command cvs checkout module - used to checkout files for revision, e.g. cvs checkout somemodule - gets/creates a copy of the module (in a directory of the same name) cvs checkout -D yesterday somemodule - gets/creates a copy of the module as it looked yesterday checkout assumes read-write unless you supply the -r option for read only cvs commit files - used to save revisions cvs release directory - indicate that a directory is no longer in use, effectively cancelling a checkout without saving the results. Note that you must move out of a directory before releasing it, for example: cvs checkout somemodule .... make some alterations then change your mind .... cd .. cvs release -d somemodule cvs update files - updates the specified files in the main/central copy to match the version you've been working on cvs diff -u | less - shows you the changes you've made in the current revision cvs log filename - shows the logfiles associated with a particular file (i.e. the revision history)
  Google Docs for Windows	Jedi VCS for Windows
  free service available at docs.google.com allows a small team (up to 10 people) to collaborate on windows documents, spreadsheets, and presentations. The creator of a document controls who else can edit it, and can grant read access to additional users. assumes you have a gmail address gives you notification when more than one of you are simultaneously editing a document, and allows you to view revisions made assumes you can coordinate with your collaborators via gmail or gchat	this is an open source CVS-like system targetted at windows platforms available at jedivcs.sourceforge.net provides both client and servers, using an SQL database to store revision information