The Project Environment

The project environment artifacts evolve through three discrete states: the prototyping environment, the development environment, and the maintenance environment.

1. The prototyping environment includes an architecture testbed for prototyping project architectures to evaluate trade-offs during the inception and elaboration phases of the life cycle. This informal configuration of tools should be capable of supporting the following activities:

• Performance trade-offs and technical risk analyses

• Make/buy trade-offs and feasibility studies for commercial products

• Fault tolerance/dynamic reconfiguration trade-offs

• Analysis of the risks associated with transitioning to full-scale implementation

• Development of test scenarios, tools, and instrumentation suitable for analyzing the requirements

2. The development environment should include a full suite of development tools needed to support the various process workflows and to support round-trip engineering to the maximum extent possible.

3. The maintenance environment should typically coincide with a mature version of the development environment. In some cases, the maintenance environment may be a subset of the development environment delivered as one of the project's end products.

The transition to a mature software process introduces new challenges and opportunities for management control of concurrent activities and for assessment of tangible progress and quality. Real-world project experience has shown that a highly integrated environment is necessary both to facilitate and to enforce management control of the process. Toward this end, there are four important environment disciplines that are critical to the management context and the success of a modern iterative development process:

1. Tools must be integrated to maintain consistency and traceability. Round-trip engineering is the term used to describe this key requirement for environments that support iterative development.

2. Change management must be automated and enforced to manage multiple iterations and to enable change freedom. Change is the fundamental primitive of iterative development.

3. Organizational infrastructures enable project environments to be derived from a common base of processes and tools. A common infrastructure promotes interproject consistency, reuse of training, reuse of lessons learned, and other strategic improvements to the organization's metaprocess.

4. Extending automation support for stakeholder environments enables further support for paperless exchange of information and more effective review of engineering artifacts.

12.2.1 Round-Trip Engineering

As the software industry moves into maintaining different information sets for the engineering artifacts, more automation support is needed to ensure efficient and error-free transition of data from one artifact to another. Round-trip engineering is the environment support necessary to maintain consistency among the engineering artifacts.

Figure 12-2 depicts some important transitions between information repositories. The automated translation of design models to source code (both forward and reverse engineering) is fairly well established. The automated translation of design models to process (distribution) models is also becoming straightforward through technologies such as ActiveX and the Common Object Request Broker Architecture (CORBA).

Compilers and linkers have long provided automation of source code into executable code. As architectures start using heterogeneous components, platforms, and languages, the complexity of building, controlling, and maintaining large-scale webs of components introduces new needs for configuration control and automation of build management. However, today's environments do not support automation to the greatest extent possible. For example, automated test case construction from use case and scenario descriptions has not yet evolved to support anything except the most trivial examples, such as unit test scenarios.

The primary reason for round-trip engineering is to allow freedom in changing software engineering data sources. This configuration control of all the technical

Automated production -►

Traceability links

Forward engineering (source generation from models) Reverse engineering (models generation from source)

Forward engineering (source generation from models) Reverse engineering (models generation from source)

Portability among platforms and network topologies

Figure 12-2. Round-trip engineering artifacts is crucial to maintaining a consistent and error-free representation of the evolving product. It is not necessary, however, to have bi-directional transitions in all cases. For example, although we should be able to construct test cases for scenarios defined for a given logical set of objects, we cannot "reverse engineer" the objects solely from the test cases. Similarly, reverse engineering of poorly constructed legacy source code into an object-oriented design model may be counterproductive.

Translation from one data source to another may not provide 100% completeness. For example, translating design models into C++ source code may provide only the structural and declarative aspects of the source code representation. The code components may still need to be fleshed out with the specifics of certain object attributes or methods.

12.2.2 Change Management

Change management is as critical to iterative processes as planning. Tracking changes in the technical artifacts is crucial to understanding the true technical progress trends and quality trends toward 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 a 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—change 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 SCO shown in Figure 12-3 is a good starting point for describing a set of change 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, a 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 a 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 is 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 to resolve the problem. The breakage item quantifies the


Figure 12-3. The primitive components of a software change order

volume of change, and the 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 necessary to design and implement the resolution. The test item identifies the hours expended in testing the resolution, and the document item identifies all effort 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 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 either inspection, analysis, demonstration, or test. Where applicable, it should also reference all existing test cases and new test cases 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

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 a named collection of software components and supporting documentation that is subject to change management and is upgraded, maintained, tested, statused, 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 a 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 transient. The shorter its life cycle, the better. Figure 12-4 shows examples of some release name histories for two different situations.

Once software is placed in a controlled baseline, all changes are tracked. A distinction must be made for the cause of a change. Change categories are as 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 cases or to serious defects in secondary use cases that have a low probability of occurrence.

Typical project release sequence for a large-scale, one-of-a-kind project





Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment