Download primitive components of a software change order

SCO database formulation and maintenance

Change management is a critical to iterative process as planning. Tracking changes in the technical artifacts is crucial to understanding the true technical progress trend and quality trends towards delivering an acceptable end product or interim release. In conventional software management processes, baseline configuration management techniques for technical artifacts were predominantly a late life-cycle activity. In modern process- in which requirements, design, and implementation set

Artifacts are captured in rigorous notations early in the life cycle and are evolved through multiple generations- changes management has become fundamental to all phases and almost all activities.

Software Change Orders

The atomic unit of software work that is authorized to create, modify, or obsolesce components within a configuration baseline is called a software change order (SCO). Software change orders are a key mechanism for partitioning, allocating, and scheduling software work against an established software baseline and for assessing progress and quality. The example in figure 2.3.1 shows a good starting point for describing a set of primitives. It shows the level of detail required to achieve the metrics and change management rigor necessary for a modern software process. By automating data entry and maintaining change records on-line, the change management bureaucracy associated with metrics reporting activities can also be automated.

The level at which an SCO is written is always an issue. What is a discrete change? Is it a change to a program unit or to a component, a file, or a subsystem? Is it a new feature, defect resolution, or a performance enhancement? Within most projects, the atomic unit of the SCO tends to be easily accepted. In general, an SCO should be written against a single component so that it is easily allocated to single individual. If resolution requires two people on two different teams, two discrete SCOs should be written.

The basic fields of the SCO are title, description, metrics, resolution, assessment, and disposition.

Title. The title is suggested by the originator and finalized upon acceptance by the configuration control board (CCB). This field should include a reference to an external software problem report if the change was initiated by an external person (such as a user).

Description. The problem description includes the name of the originator, date of origination, CCB-assigned SCO identifier, and relevant version identifiers of related support software. The textual problem description should provide as much detail as possible, along with attached code excerpts, display snapshots, error messages, and any other data that may help to isolate the problem or describe the change needed.

Metrics. The metrics collected for each SCO are important for planning, for scheduling, and for assessing quality improvement. Change categories are type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3 (new feature), and type 4 (other), as described later in this section. Upon acceptance of the SCO, initial estimates are made of the amount of breakage and the effort required resolving the problem. The breakage item quantifies the volume of change, and rework item quantifies the complexity of change. Upon resolution, the actual breakage is noted, and the actual rework effort is further elaborated, the analysis item identifies the number of staff hours expended in understanding the required change (re-creating, isolating, and debugging the problem if the change is type 0 or 1; analysis and prototyping alternative solutions if it is type 2 or 3). The implement item identifies the staff hours expended in updating other artifacts such as the user manual or release description. Breakage quantifies the extent of change and can be defined in units of SLOC, function points, files, components, or classes. In the case of SLOC, a source file comparison program that quantifies differences may provide a simple estimate of breakage. In general, the precision of breakage numbers is relatively unimportant. Changes between 0 and 100 lines should be accurate to the nearest 10, changes between 100 and 1,000 to the nearest 100, and so forth.

Resolution. This field includes the name of the person responsible for implementing the change, the components changed, the actual metrics, and a description of the change. Although the level of Components changed the actual metrics, and a description of the change. Although the level of component fidelity with which a project tracks change references can be tailored, in general, the lowest level of component references should be kept at approximately the level of allocation to an individual. For example, a "component" that is allocated to a team is not a sufficiently detailed reference.

Assessment. This field describes the assessment technique as inspection, analysis, demonstration, or test where applicable, it should also reference all existing test cases and new test case executed, and it should identify all different test configurations, such as platforms, topologies, and compilers.

Disposition. The SCO is assigned one of the following states by the CCB:

. Proposed: written, pending CCB review

. Accepted: CCB-approved for resolution

. Rejected: closed, with rationale, such as not a problem, duplicate, obsolete change, resolved by another SCO

. Archived: accepted but postponed until a later release

. In progress: assigned and actively being resolved by the development organization

. In assessment: resolved by the development organization; being assessed by a test organization

. Closed: completely resolved, with the concurrence of all CCB members of all CCB members

A priority and release identifier can also be assigned by the CCB to guide the prioritization and organization of concurrent development activities.

Configuration Baseline

A configuration baseline is named collection of software components and supporting documentation that is subject to change management and is upgraded, maintained, tested, stat used, and obsolesced as a unit. With complex configuration management systems, there are many desirable project-specific and domain-specific standards.

There are generally two classes of baselines: external product releases and internal testing releases. A configuration baseline is a named collection of components that is treated as unit. It is controlled formally because it is a packaged exchange between groups. For example, the development organization may release a configuration baseline to the test organization or even to itself. A project may release a configuration baseline to the user community for beta testing.

Generally, three levels of baseline releases are required for most systems: major, minor, and interim. Each level corresponds to a numbered identifier such as N.M.X where N is the major release number, M is the minor release number, and X is the interim release identifier. A major release represents a new generation of the product or project, while a minor release represents the same basic product but with enhanced features, performance, or quality. Major and minor releases are intended to be external product releases that are persistent and supported for a period of time. An Interim release corresponds to a developmental configuration that is intended to be trendier the shorter its life cycles the better.

Once software is placed in a controlled baseline, all changes are tracked. A distinction must be made for the cause of a change categories are follows:

. Type 0: critical failures, which are defects that are nearly always fixed before any external release. In general, these sorts of changes represent showstoppers that have an impact on the usability of the software in its critical use cases.

. Type 1: a bug or defect that either does not impair the usefulness of the system or can be worked around. Such errors tend to correlate to nuisances in critical use case or to serious defects in secondary use cases that have a low probability of occurrence.

. Type 2: a change that is an enhancement rather than a response to a defect, its purpose is typically to improve performance, testability, usability, or some other aspect of quality that represents good value engineering.

. Type 3: a change that is necessitated by an update to the requirements. This could be new features or capabilities that are outside the scope of the current vision and business case.

. Type 4: changes that are not accommodated by the other categories. Examples include documentation only or a version upgrade to commercial components.

Configuration Control Board

A CCB is a team of people that functions as the decision authority on the content of configuration baselines. A CCB usually includes the software manager, software architecture manager, software development manager, software assessment manager, and other stakeholders (customer, software project manager, systems engineer, and user) who are integral to the maintenance of a controlled software delivery system. While CCBs typically take action through board meetings, on-line distribution, concurrence, and approval of CCB actions may make sense under many project circumstances.

The operational concept of an iterative development process must include comprehensive and rigorous change management of the evolving software baselines. The fundamental process for controlling the software development and maintenance activities is described through the sequence of states traversed by an SCO. The [bracketed] words constitute the state of an SCO transitioning through the process.

. [Proposed]. A proposed change is drafted and submitted to the CCB. The proposed change must include a technical description of the problem and an estimate of the resolution effort.

. [Accepted, archived, or rejected]. The CCB assigns a unique identifier and accepts, archives, or rejects each proposed change. Acceptance includes the change for resolution in the next release; archiving accepts the change but postpones it for resolution in a future release; and rejection judges the change to be without merit, redundant with other proposed changes, or out of scope. The CCB verifies that all SCO fields are appropriate and accurate before accepting the SCO, then assigns the SCO to a responsible person in the development organization for resolution.

. [In progress]. The responsible person analyzes, implements, and tests a solution to satisfy the SCO. This task includes updating documentation, release notes, and SCO metrics actual, and submitting new SCOs, if necessary, upon achieving a complete solution, the responsible person completes the resolution section of the SCO and submits it to the independent test team for assessment.

. [In assessment]. The independent test team assesses whether the SCO is completely resolved. When the independent test team deems the change to be satisfactorily resolved, the SCO is submitted to the CCB for final disposition and closure.

. [Closed]. When the development organization, independent test organization, and CCB concur that the SCO is resolved, it is transitioned to a closed status.

THIS PORTION OF PAGE IS INENTIONALY LEFT BLANK

Download primitive components of a software change order