Change Control Process

 

The change control process manages the acquisition, verification, approval, and execution of externally identified issues The issue management process for this project is restricted to those issues identified by outside parties (reviewers, testers, end-users, etc.) as opposed to those identified by members of the development team. Externally identified issues are either defect reports or enhancement requests. (enhancement requests or defect reports) identified during application development and/or production operations. The change control workflow consists of four actors and four phases:

 

 

Actors

The actors associated with change control include:

 

  1. Submitters, who are generally end users, reviewers or testers,

  2. The project PER and PDR acting in concert to perform verification and validation of new issues,

  3. The project CCB, which controls the assignment of issues to SDLC iterations, and

  4. The project development team, which performs issue analysis and executes the SDLC iteration.

Phases

Each issue flows through four phases:

 

  1. Discovery, where new issues identified during production or SDLC iterations enter the workflow and are validated,

  2. Analysis, where the effort associated with the resolution of each issue is researched,

  3. Authorization, where the CCB assigns verified issues to specific SDLC iterations for resolution, and

  4. Iteration, where the development team develops and/or modifies the documentation and code as necessary to resolve each issue.

Discovery Phase

Issues may be discovered by end users during production operations or by members of the development team during software development. New issues are submitted via email, written reports, or telephone conversations, and stored in a repository as described in the project SPMP. In any case, each new issue is eventually received by the PER and PDR for validation. To validate an issue, the PER and/or PDR:

 

  1. Determines the issue is not associated with an infrastructure element, such as network access,

  2. Determines the issue is not a duplicate, and

  3. Reproduces the issue in the case of a defect report.

 

New issues that fail to meet the above validation criteria are placed in an archive of invalid issues. New issues that pass the criteria are sent to the development team for analysis.

Analysis Phase

Valid new issues are examined by appropriate members of the development team to identify the root cause of the issue, as well as the configuration items that would have to be changed, and how they would be changed in order to close the issue. The development team members then estimate the level of effort required to make the defined changes. This information is added to the issue, which is then passed back to the PER and PDR for verification. During verification, the PER and PDR assign a priority level to the issue based on the severity of the defect or the desirability of the enhancement. The issue is then assigned a status of “Open” and stored for review by the CCB.

Authorization Phase

The CCB evaluates open issues to determine the SDLC iteration, or product release, that will address the development effort needed to close the issue. Issues can be assigned to the next iteration, a future iteration, or left in an unassigned state as determined by the needs of the end user community, the resources available from the development team, and the funding available from the project sponsor. Issues with a status of “Assigned” are also tagged with the iteration (also known as the target release version) of the software in which they are to be addressed.

Iteration Phase

Each iteration of the SDLC is focused on the accomplishment of a specific set of goals, for either the application or for a specific component. The CCB authorizes the initiation of an SDLC iteration. At this point, the planning stage of the SDLC is kicked off and the SPMP or CIP (as applicable) is developed and approved.

New Issues

During design and development, the team may identify additional issues. As the scope of work is fixed for the current iteration, these additional issues are submitted as “New” issues to be addressed in later iterations. The project team may resolve a new issue in the current iteration, but this is an unusual action requiring concurrence of the CCB and will generally be recorded as a stage reversion.

Abandoned Issues

As the team moves through the iteration, certain issues may be acknowledged as unworkable given the current resource and/or schedule constraints. With the permission of the CCB, these issues are abandoned. The scope of work is removed from the iteration, and the issue is returned for verification by the PER and PDR. Note that issue abandonment may also result in a stage reversion. Refer to the SDLC for a discussion of stage reversion.

Closed Issues

The normal conclusion of this process is the completion of the iteration, resulting in the closure of all remaining issues assigned to the iteration.