 |
 |
 |
|
 |
|
 |
|
|
SC.7 Maintenance and Modification |
|
SZ.7 Pflege und Änderung
Maintenance/modification (MM) includes the realization of maintenance and modification measures while the System is used. The task of system maintenance is the maintenance of the functionality, i. e. the elimination of faults and malfunctions and the realization of optimizations without the necessity of modifying the User Requirements, the System Architecture or the Technical Requirements. System modifications, however, always include modifications of the above mentioned documents (further development of the System).
System modifications are reported by Change Request/Problem Report.
On the one hand, incoming change requests/problem reports may lead to an independent maintenance/modification project (i. e. a project must be initialized in accordance with the regulations of the V-Model); on the other hand, they might be processed within the scope of the change management (activity CM3 - Change Management (Configuration Control)) of an already handled MM project.
The situation, that activities to be realized are based on already existing products, is characteristic for MM projects.
When modifying products, two procedures are generally possible:
- modification in the product
result: a new product
- modification in an additional product connected with the original product
result: product with supplement
In both cases, a new version of the product is created. The procedure selected for the MM product must be specified in the CM Plan. Figure SC.7 illustrates the two possibilities to update products.
The sequence of SD activities during a maintenance/modification task is illustrated in Figure SC.8.
Figure SC.7: Procedure during Product Update
Figure SC.8: Sequence of SD Activities during the Realization of Maintenance/Modification
Preliminary Remarks:
- Next, it is shown how to handle a change request. Normally, it is quite possible to handle several change requests at the same time.
- It is expected that the change request includes the modification of the development of an additional functionality and the integration of the modification/update into the existing System.
- The following scenario illustrates the realization of the change request in several increments (incremental procedure).
Time T 0-Start
Initialization of the MM project and the beginning of the realization of the maintenance/modification measures in submodel SD. These are based on the documentation of the existing System obtained from the development project. The SD activities to be realized according to the change request are identified in the change request.
Time T 1-First Increment
The User Requirements are updated and available in version 2. The "overall horizon" of the required modification has been considered in the preliminary system description. For those parts that are to be realized in a first increment (field 3) the user-level requirements have all been specified. System architecture and Technical Requirements are completed and available in a second version.
After being realized and integrated, the first increment is transferred into the existing System at time T 1.
Time T 2-Completion of Maintenance/Modification
The additional User Requirements caused by the change request are completely realized and the new System has been put into use. Thus, the change request has been completed. Another change request was considered within the scope of this second increment, this resulted in an update/addition to the field 3 realized during the first increment.
The activities of submodel PM must be realized both in a MM project and in a development project. The specifications of the SWMM Concept (e. g. for the project organization) have to be considered during the project initialization.
The specifications with regard to methods and tools as well as standards and rules in the project manual of the development project must be applied for the MM project. If necessary, adjustment/completion must be realized (activity PM1.4 - Toolset Management).
In case several change requests/problem messages have to be processed in the MM project, submodel PM is in charge of planning and control for the activities identified in the change requests.
The products modified within the scope of the MM project must be assessed in submodel QA. The assessment specifications and assessment procedures of the development project may be used as basis documents, but must be adjusted with regard to the changed SD products.
The integration of SD products from the development project into the MM project is subject to the configuration management (activity CM1.2 - Setting up CM). Apart from the SD products, this includes also the products of submodels QA, CM, and PM.
The procedure with regard to the modification of products is regulated in the CM Plan.
The system configuration already in use is administered by the CM.
The configuration management is used as a sort of central depot for all incoming change requests/problem reports. Change proposal and change order are generated in activity CM3 - Change Management (Configuration Control). The change order is the basis of the activities to be realized in submodel SD.
If necessary, the known change and error messages are collected and maintained by the CM in a report document meant for the support of the user.
The scenario is to be applied, when change requests/problem messages are to be processed while a System is being used. The following requirements are expected:
- the system development has been completed, i. e. the System is already being used,
- the SWMM Concept is available,
- availability of all relevant products of the development project in a current and consistent form.