Figure 12-4. Example release histories for a typical project and a typical product

Upgrade release 4.2

Figure 12-4. Example release histories for a typical project and a typical product

• 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.

Table 12-1 provides examples of these changes in the context of two different project domains: a large-scale, reliable air traffic control system and a packaged software development tool.

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, user)

Table 12-1. Representative examples of changes at opposite ends of the project spectrum

change type

air traffic control project

packaged visual modeling tool

Type 0

Control deadlock and loss of flight data

Loss of user data

Type 1

Display response time that exceeds the requirement by 0.5 second

Browser expands but does not collapse displayed entries

Type 2

Add internal message field for response time instrumentation

Use of color to differentiate updates from previous version of visual model

Type 3

Increase air traffic management capacity from 1,200 to 2,400 simultaneous flights

Port to new platform such as WinNT

Type 4

Upgrade from Oracle 7 to Oracle 8 to improve query performance

Exception raised when interfacing to MSExcel 5.0 due to Windows resource management bug

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 actuals, and submitting new SCOs, if neces sary. 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.

12.2.3 Infrastructures

From a process automation perspective, the organization's infrastructure provides the organization's capital assets, including two key artifacts: a policy that captures the standards for project software development processes, and an environment that captures an inventory of tools. These tools are the automation building blocks from which project environments can be configured efficiently and economically.

Organization Policy

The organization policy is usually packaged as a handbook that defines the life cycle and the process primitives (major milestones, intermediate artifacts, engineering repositories, metrics, roles and responsibilities). The handbook provides a general framework for answering the following questions:

• What gets done? (activities and artifacts)

• When does it get done? (mapping to the life-cycle phases and milestones)

• Who does it? (team roles and responsibilities)

• How do we know that it is adequate? (checkpoints, metrics, and standards of performance)

The need for balance is an important consideration in defining organizational policy. Too often, organizations end up at one of two extremes: no institutionalized process, or too much standardization and bureaucracy. Effective organizational policies have several recurring themes:

• They are concise and avoid policy statements that fill 6-inch-thick documents.

• They confine the policies to the real sballs, then enforce them.

• They avoid using the word should in policy statements. Rather than a menu of options (shoulds), policies need a concise set of mandatory standards (shalls).

• Waivers are the exception, not the rule.

• Appropriate policy is written at the appropriate level.

The last point deserves further discussion. There are many different organizational structures throughout the software development industry. Most software-inten-sive companies have three distinct levels of organization, with a different policy focus at each level:

• Highest organization level: standards that promote (1) strategic and long-term process improvements, (2) general technology insertion and education, (3) comparability of project and business unit performance, and (4) mandatory quality control

• Intermediate line-of-business level: standards that promote (1) tactical and short-term process improvement, (2) domain-specific technology insertion and training, (3) reuse of components, processes, training, tools, and personnel experience, and (4) compliance with organizational standards

• Lowest project level: standards that promote (1) efficiency in achieving quality, schedule, and cost targets, (2) project-specific training, (3) compliance with customer requirements, and (4) compliance with organizational/ business unit standards

Standardization should generally focus on line-of-business units, not on the top-level organization or the projects. Leverage from standardization is generally most effective at the business unit level, where there is the most commonality and reuse across projects, processes, and tools. Standardization of software development techniques and tools across lines of business has proven to be difficult, because the process priorities, tools, techniques, methods, and stakeholder cultures can be very different. Attempting to standardize across domains that have little commonality results in either a highly diluted policy statement or a waiver process that is used too frequently. Standardizing at too high a level is problematic; so is standardizing at too low a level. If all project teams are left to their own devices, every project process and environment will be locally optimized. Over time, the organization's infrastructure for process improvement and growth will erode.

The organization policy is the defining document for the organization's software policies. In any process assessment, this is the tangible artifact that says what you do. From this document, reviewers should be able to question and review projects and

Was this article helpful?

0 0
Homeowners Guide To Landscaping

Homeowners Guide To Landscaping

How would you like to save a ton of money and increase the value of your home by as much as thirty percent! If your homes landscape is designed properly it will be a source of enjoyment for your entire family, it will enhance your community and add to the resale value of your property. Landscape design involves much more than placing trees, shrubs and other plants on the property. It is an art which deals with conscious arrangement or organization of outdoor space for human satisfaction and enjoyment.

Get My Free Ebook

Post a comment