The case studies showed that changes are processed in several process layers. The process models formulated during the first case study have two process layers: contractor level change process and subcontractor level process. These two layers were very clear, since the process standards and requirement used by the contractor were very different from the processes used internally by the sub- contractor. Therefore, the changes visible to the contractor were processed using very different processes compared with the changes which could be managed internally at the subcontractor level. The spiral-like change management process generated after the second case study includes four process cycles, each includ- ing the same main phases, but executed by different roles. The factor defining the process level was the role of the person who executed the change activities at that level. Two change process layers, product and project layer, were identi- fied in the third case study, although one of these was part of the requirements management process. These two layers were the clearest ones identified in the third case study, although there were indications of additional process layers. The following two process layers can be identified in all case organisations: 1. Product level changes. This change process generates new requirements for
the new products or new product releases. It also generates feature modifi- cation, addition and deletion requests for development projects. Examples of product level changes from the three case studies are presented in Table 12. These examples were identified in the case studies.
Table 12. Examples of product level changes. Example of product level change
Case one Adding or modifying the instruments in the station during the development time by the contractor of the whole project.
Case two Replacing components in operating product families with modern hardware components. The new hardware components require software to be changed accordingly.
Case three
Requirements for new features for new iterative development cycles.
2. Project-level changes. Project-level changes are initiated and managed in- ternally by the project. Some project-level changes are generated because of product-level changes, for example when the product-level change process requests a feature modification initiated by an external customer during the development project. Project-level change requests may also generate prod- uct level changes, for example when a project generates requirements for other, either ongoing or future projects. Examples of project-level changes identified in the three background case studies are listed in Table 13.
Table 13. Examples of project-level changes.
Example of project-level change
Case one A timing error in flight software caused by a pro- gramming error and identified in the unit testing phase.
Case two Re-writing part of the software reusing the behav- iour and concept of the software embedded in the old product. This is done because the old software has deteriorated during the long maintenance phase, and its structure and understandability has suffered from patch changes.
Case three A typographical error in a design document identi- fied in a design document review.
The main difference between the two change process layers is that the decisions related to product-level changes are done outside an individual software project, and the project-level changes are managed internally by the project within the constraints stated for the project. When the product-level changes are forwarded to the software project for implementation, they introduce changes to the initial
requirements set for the project. On the other hand, the project should be pre- pared to manage the project-level changes within the project constraints.
In addition to these two change process layers, the case studies indicated the existence of additional change process layers. For example, the third case study revealed that only a subset of unit testing errors are processed according to the project-level error management process (See Problem 16 in Case 3). This indi- cates the existence of a "personal change process", which is followed for changes in which the person managing the change does not forward the change to the project-level change process. The change processes can also scale up- wards from the product-level changes. For example, in the organisation studied in the third case study, the products were grouped into product families. One of the goals of the product family thinking was to share concepts and even compo- nents, both hardware and software, between products. Therefore, change man- agement on a product family level is necessary. The product family thinking was, however, a novel idea in the organisation, and therefore the product family change management level was not yet clearly recognised.
The process levels can be identified in both the development and maintenance phase of the software life cycle. The levels are also independent of the change type (see Figure 18). Different types of changes can be identified on all process levels.
The relationships between the product and project-level change management process layers are described in Figure 13.
Customers
Partners
Standards
Other sources
Feature
wishes
Errors
External sources for changes
Improvement
proposals
Change requests
Internal sources for changes
Marketing
Research
Product development project
Change
triggers
Change triggers
Change triggers
Other technology
projects
Software project
Errors Feature wishes Imprvm. props. Project level changes Product level changes Software items = data storage = organisational entity = grouping symbol = data flow = documentFigure 13. Relationships between the product change process and project change process.
The product and project level change processes were the most distinct and clear process levels identified in the case studies. These two change process layers are described in further detail in the following two subsections.
6.3.1 Product-level changes
When the nature of software development is evolutive, i.e. new products are based on the idea, components or a baseline of an old product, the product-level change process can be clearly distinguished from the project-level changes. In the beginning of a new evolutive development cycle, the product-level changes are change needs or ideas related to the old product version, which are refined into requirements for the new development cycle. After the product- level change process has forwarded the change requests to the development project as the requirements for the new development cycle, the project will manage them using a requirement management process, since they constitute the requirement specification of the project. If the product-level change process feeds the ongoing project with new change requests, those changes are managed as change requests to the requirement specification baseline. These changes cause additions, modifications or deletions to the requirement specification baseline of the ongoing development cycle.
From the project point of view, the changes initiated by the product-level change process always have an impact on the assumptions on which the project bases its project plans. Therefore, the impacts to project schedules, resources and other plans must be analysed and updated.
The project may also feed change proposals to the product-level change process. The ongoing development cycle may generate change needs or ideas which it cannot carry out within the constraints of the ongoing development cycle. The project will then feed the change proposal to the product-level change process, which will evaluate if the change proposal will be forwarded to another ongoing development cycle, or to a new development cycle to be started.
The new evolutive development cycle does not have to be organised as a proj- ect, although that was the case in the two case studies (case studies B and C) where the product-level change process could be clearly separated from the project-level change process.
When software development is based on an evolutive software development cycles, the starting point of the project is:
• a stable baseline of an old product, and
• a list of changes to be implemented during this development cycle. The changes can be any one of the following:
• new or modified features,
• corrections,
• adaptations to new environment, or
• improvement proposals.
This means that the nature of the system development is actually adapting an old system version to a new release. The nature of the software development work is carrying out changes in order to deliver a new release of the product.
6.3.2 Project-level changes
Project-level changes are iterations within the development process. They are managed internally by the development unit, which usually is a development or maintenance project. Project-level changes are included in the project plans and they are managed within the constraints of the project. The project should be prepared to manage the project-level changes within the constraints set for the project.
In some cases, project-level changes may have effects on the assumptions used as the basis for the project plans. However, this is not caused by external pres- sure, but the change need is initiated internally by the project, i.e. because the knowledge of the subject area increases as the design work progresses, and the initial assumptions prove to be inaccurate or incorrect.