3 Part 3: V-Modell Reference Tailoring
3.5 Project Type Variants
3.5.6 Project (Acquirer/Supplier) Including System Maintenance
|
Extended project type: |
Descriptions
As already described in Part 1: "»Fundamentals of the V-Modell", the V-Model provides specific project type variants, which are adapted to the different »Project Types. The project type variant »Project (Acquirer/Supplier) Including System Maintenance can only be applied to the project type »System Development Project (Acquirer/Supplier), i.e. if it is not necessary to subdivide a system development project into two separate projects - one for the side of the Acquirer and one for the side of the Supplier. This is possible, if the system development project is executed within one organization or if several organizations, which deliberately cooperate closely in one project, participate in the project. As distinguished from a separate »System Development Project (Acquirer) und »System Development Project (Supplier), the Request for Proposals and Contracting and the dual project organization with two Project Leaders are not required.
The project type variant »Project (Acquirer/Supplier) Including System Maintenance»Project (Acquirer) Including System Maintenance is based on the situation that a system in use must be adapted or changed, e.g. by correcting faults, introducing new technologies, improving the fulfilment of non-functional requirements or modifying or extending functionalities. These "change requirements" will be specified by the Acquirer at the beginning of the project. Additional change requirements, which arise during project execution, can only be managed by the »Problem and Change Management. The System Developer analyses the change requirements, executes the required system changes and delivers the modified system normally in several iterations. Each iteration will be accepted individually by the User.
Process Modules to be used
Due to the project type: Specification of Requirements, Configuration Management, Delivery and Acceptance (Acquirer), Delivery and Acceptance (Supplier), Problem and Change Management, Project Management, Quality Assurance, System Development
Project characteristics to be determined during tailoring
Due to the project type: Security (Supplier), Life Cycle Cost Management, Project Measures, Off-the-Shelf Products, User Interface, Subject of the Project
Due to the project type variant: Subcontract, Legacy System
Activity Flow
Figure 18: Project type variant Project (Acquirer/Supplier) Including System Maintenance
The decision gates and the sequence of the project type variant »Project (Acquirer/Supplier) Including System Maintenance are shown in figure Figure 18. The sequence differs significantly from that of the project type variant »Project (Acquirer/Supplier) Including Development, Enhancement or Migration by the different system development entry points, which depend on the scope of the system changes to be executed. It may affect the Overall System Specification, the System Design or the Detail Design. In the following, the sequence of a System Maintenance »Iteration will be described by means of the decision gates carried out.
Possible transitions based on 'Projektstart'
From 'Project beginning' to 'Project Approved'
The potential acquirer, operating under the custodianship of a sponsor, prepares a »Project Proposal which includes all information required for deciding on the implementation of the proposal in form of a project. A sponsor is defined as person or department providing a budget for project acquisition. The project proposal is discussed in the decision gate »Project Approved, which ends with the decision as to whether or not the project should be started.
Possible transitions based on 'Project Approved'
From 'Project Approved' to 'Project Defined'
In case of a positive decision, a Project Manual and a QA Manual will be prepared, which will be examined in order to determine if they are suitable for project execution on side of the acquirer. These activities are intended to reach the decision gate »Project Defined.
Possible transitions based on 'Project Defined'
From 'Project Defined' to 'Requirements Specified'
After project definition, the user requirements will be prepared and subjected to a »Requirements Evaluation. The user will examine the requirements for completeness and correctness. In case of a positive assessment, the acquirer specifies and prioritizes the requirements in form of the »Requirements Specification. In addition, an »RFP Concept will be prepared in order to ensure that the contract award law will be observed during the request for proposal. These activities are intended to reach the decision gate »Requirements Specified.
Possible transitions based on 'Requirements Specified'
From 'Requirements Specified' to 'Iteration Scheduled'
If the product Requirements Specification includes functional requirements, the scope of the requirements implemented in the respective iteration will be planned. In addition, it will be examined whether the products »Project Manual and »QA Manual are appropriate for the project. If necessary, these products must be adapted to the requirements. These activities are intended to reach the decision gate »Iteration Scheduled.
Possible transitions based on 'Iteration Scheduled'
From 'Iteration Scheduled' to 'System Specified'
In the project, the requirements planned at the decision gate »Iteration Scheduled will be evaluated in cooperation with the acquirer, and a first preliminary design will be prepared. Requirements and preliminary design will be documented in the »Overall System Specification, which is the basis for the further development of the system. If the project includes the enhancement or migration of a legacy system, a »Legacy System Analysis will be prepared together with the Overall System Specification. These activities are intended to reach the decision gate »System Specified.
From 'Iteration Scheduled' to 'System Designed'
If the changes planned at the decision gate »Iteration Scheduled influence the system design, but do not affect the »Overall System Specification , the system design will be changed. The effects on the system and all identified enabling systems will be designed. This process may be executed independently for the system and each enabling system. These activities are intended to reach the decision gate »System Designed for the system and each enabling system.
From 'Iteration Scheduled' to 'Detailed Design Completed'
If the changes planned at the decision gate »Iteration Scheduled influence the detailed design, but do not affect the Overall System Specification and the system design, the detailed design will be changed. For this purpose the architectures of hardware and software units will be subdivided into components and modules. These activities are intended to reach the decision gate »Detailed Design Completed.
Possible transitions based on 'System Specified'
From 'System Specified' to 'System Designed'
Based on the preliminary design, architectures will be designed for the system and all identifiable »Enabling Systems . The architectures will define the »Segment s down to the level of hardware and software units. The requirements will be specified and assigned to system elements. Development process and evaluation strategy will be specified. The following decision gates to be executed until the project is delivered can be planned independently and executed simultaneously for the system and the various enabling systems. These activities are intended to reach the decision gate »System Designed for the system and every enabling system.
Possible transitions based on 'System Designed'
From 'System Designed' to 'Detailed Design Completed'
After the decision gate »System Designed has been reached, the work on the detailed design may begin. For the detailed design, the architectures of the hardware and software units will be developed into components and process modules, and external software/hardware specifications will be prepared as required. The requirements will be assigned to the hardware and software elements. Development process and test strategy will be specified. On the way towards the integration of realized system elements, it is possible to plan and conduct the design of hardware and software units simultaneously with the realization of other hardware and software units. These activities are intended to reach the decision gate »Detailed Design Completed for every workflow. Due to possible parallel workflows, it is possible that the decision gate »Detailed Design Completed has been reached in some segments - and the realization may begin - while the detailed design for other segments is not yet completed.
From 'System Designed' to 'Request for Proposal Released'
If External Units are identified within the scope of the system design (decision gate »System Designed), the supplier shall execute a sub-project (acquirer). At first, a »Request for Proposal (Acquirer) is conducted, and the first target of the suborder is the decision gate »Request for Proposal Released. The decision gates of the suborder are executed like the respective decision gates in the Project Execution Strategy »Project (Acquirer) with One Supplier.
Based on the specification of requirements, the »Request for Proposal will be prepared. For this purpose, the RFP documents will be prepared based on the »RFP Concept specified in the decision gate »Requirements Specified, and a »Criteria Catalog for Assessment of Offers will be developed. Afterwards, it will be examined if the request for proposal can be released. In case of a positive decision, the request for proposal will be published in accordance with the procedures specified in the RFP concept. These activities are intended to reach the decision gate »Request for Proposal Released.
Possible transitions based on 'Detailed Design Completed'
From 'Detailed Design Completed' to 'Request for Proposal Released'
If External Units are identified within the scope of the system design (decision gate »System Designed), the supplier shall execute a sub-project (acquirer). At first, a »Request for Proposal (Acquirer) is conducted, and the first target of the suborder is the decision gate »Request for Proposal Released. The decision gates of the suborder are executed like the respective decision gates in the Project Execution Strategy »Project (Acquirer) with One Supplier.
Based on the specification of requirements, the »Request for Proposal will be prepared. For this purpose, the RFP documents will be prepared based on the »RFP Concept specified in the decision gate »Requirements Specified, and a »Criteria Catalog for Assessment of Offers will be developed. Afterwards, it will be examined if the request for proposal can be released. In case of a positive decision, the request for proposal will be published in accordance with the procedures specified in the RFP concept. These activities are intended to reach the decision gate »Request for Proposal Released.
From 'Detailed Design Completed' to 'System Elements Realized'
All hardware and software elements identified in the detailed design will be realized and evaluated in accordance with the requirements. In this context, also an iterative approach is possible, extending the detailed design after some system elements of the detailed design have been realized. If an External Hardware/Software Module Specifications were prepared during the detailed design, subcontracts may be awarded for the development of the software/hardware modules. If no subcontracts are awarded, all hardware and software elements identified in the detailed design will be realized and evaluated in accordance with the requirements.
Possible transitions based on 'Request for Proposal Released' (Ablaufbaustein Subcontract)
From 'Request for Proposal Released' to 'Contract Awarded'
The »Offers received after the »Request for Proposal will be evaluated in accordance with the »Criteria Catalog for Assessment of Offers. A provider with whom negotiations will be conducted will be selected. The acquirer decides - based on the assessment of the offers and the result of the contract negotiations - if the offer of the selected provider should be accepted. In case of a positive decision, a »Contract will be concluded between acquirer and supplier. In case of public acquirers and suppliers, contract negotiations are only possible under strict conditions. The public acquirer employs the »Offer Assessment in order to decide which offer is the most economical offer. The contract award commits the supplier to execute the project for the acquirer in accordance with the contractual agreements. These activities are intended to reach the decision gate »Contract Awarded.
Possible transitions based on 'Contract Awarded' (Ablaufbaustein Subcontract)
From 'Contract Awarded' to 'Iteration Scheduled'
After a »Contract has been concluded, the system development process, i.e., the decision gates to be achieved and the extent of the requirements to be implemented, will be planned. In addition, it will be examined if the products »Project Manual and »QA Manual still correctly reflect the project. Otherwise these products will be adapted. These activities are intended to reach the decision gate »Iteration Scheduled.
Possible transitions based on 'Iteration Scheduled' (Ablaufbaustein Subcontract)
From 'Iteration Scheduled' to 'Project Progress Revised'
Then the acquirer is then tasked with supporting the execution of the supplier's project at the current »Project Stage in accordance with the specifications made in the contract. This is intended to ensure the success of the project and is a decisive acquirer task in this project execution strategy. The supplier will submit a Project Status Report (Supplier) for controlling the project progress. This report will determine which results have been achieved at the agreed project milestones. For this purpose, the acquirer will prepare a Project Status Report of his/her own. These activities are intended to reach the decision gate »Project Progress Revised.
Possible transitions based on 'Project Progress Revised' (Ablaufbaustein Subcontract)
From 'Project Progress Revised' to 'Project Progress Revised'
The supplier will submit the Project Status Report to the acquirer at regular intervals, which may be adapted to the sequence of the supplier's Project Progress Decisions. At these points, the acquirer will also prepare a Project Status Report. These activities are intended to reach the decision gate »Project Progress Revised.
From 'Project Progress Revised' to 'Acceptance Completed'
If the supplier has achieved a specified system development status, the acquirer will receive the contractually agreed deliveries. The acquirer examines whether the »Delivery (Supplier) meets the requirements. This leads to the project progress decision of the decision gate »Acceptance Completed.
Possible transitions based on 'Acceptance Completed' (Ablaufbaustein Subcontract)
From 'Acceptance Completed' to 'Iteration Scheduled'
In order to plan a new iteration after the acceptance, the acquirer will check the open change requests of the »Change Status List in cooperation with the supplier. At the decision gate »Iteration Scheduled, this list is used for deciding which change requests will be included into the new iteration and which will be postponed for the time being. In addition, it will be specified, which of the components that have not yet been implemented will be taken into account in the new iteration. The change requests and the open requirements are the basis for a new development cycle. Again, it will be examined if the products »Project Manual and »QA Manual still correctly reflect the project. These activities are intended to reach the decision gate »Iteration Scheduled.
From 'Acceptance Completed' to 'Contract Awarded'
If acquirer and supplier have determined previously that one or a few iterations will first be implemented before the overall scope is fixed contractually, a new »Contract will possibly be concluded after the acceptance has been completed. If necessary, a »Contract Addendum will be agreed with the supplier. These activities are intended to reach the decision gate »Contract Awarded.
From 'Acceptance Completed' to 'System Elements Realized'
After acceptance, the units will be integrated into the project.
Possible transitions based on 'System Elements Realized'
From 'System Elements Realized' to 'Detailed Design Completed'
In order to permit an iterative execution of detailed design and realization, it is possible to go back to the preparation of the detailed design after the realization. In this step, hardware and software units, which have not been included into the detailed design process during the previous iteration, will be designed in detail. These activities are intended to reach decision gate »Detailed Design Completed.
From 'System Elements Realized' to 'System Integrated'
All realized hardware and software elements and External Units, which were developed within the scope of suborders, will be integrated into system elements and finally into a system or enabling system. The integrated elements will be tested. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'Request for Proposal Released' (Ablaufbaustein Subcontract)
»From 'Request for Proposal Released' to 'Contract Awarded' (see above)
Possible transitions based on 'Contract Awarded' (Ablaufbaustein Subcontract)
»From 'Contract Awarded' to 'Iteration Scheduled' (see above)
Possible transitions based on 'Iteration Scheduled' (Ablaufbaustein Subcontract)
»From 'Iteration Scheduled' to 'Project Progress Revised' (see above)
Possible transitions based on 'Project Progress Revised' (Ablaufbaustein Subcontract)
»From 'Project Progress Revised' to 'Project Progress Revised' (see above)
»From 'Project Progress Revised' to 'Acceptance Completed' (see above)
Possible transitions based on 'Acceptance Completed' (Ablaufbaustein Subcontract)
»From 'Acceptance Completed' to 'Iteration Scheduled' (see above)
»From 'Acceptance Completed' to 'Contract Awarded' (see above)
From 'Acceptance Completed' to 'System Integrated'
All realized hardware and software elements and External Units, which were developed within the scope of suborders, will be integrated into system elements and finally into a system or enabling system. The integrated elements will be tested. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'System Integrated'
From 'System Integrated' to 'System Designed'
Since not only detailed design and realization, but also system design and integration can be executed in an iterative manner, a new internal iteration may be planned for system design. In the architectures, system elements not yet implemented are identified down to the level of hardware and software units. These activities are intended to reach the decision gate »System Designed.
From 'System Integrated' to 'Delivery Conducted'
The overall system to be delivered will be assorted for delivery in accordance with the requirements. A delivery includes the system, any enabling systems and documentation. At the decision gate »Delivery Conducted, the results will be examined, and it will be decided whether the delivery will be sent to the acquirer for acceptance.
Possible transitions based on 'Delivery Conducted'
From 'Delivery Conducted' to 'Acceptance Completed'
The acquirer tests the »Delivery in order to determine if the requirements are fulfilled. At the decision gate »Acceptance Completed, the acquirer will examine the results and decide whether corrective actions are required. These activities are intended to reach the decision gate »Acceptance Completed .
Possible transitions based on 'Acceptance Completed'
From 'Acceptance Completed' to 'Iteration Scheduled'
If the system development includes several increments, the detailed planning of the following iteration may be initiated after the acceptance of the previous iteration. In order to plan a new iteration, all unfinished »Problem Report / Change Request s and the »Change Status List will be examined in cooperation with the acquirer. At the decision gate Iteration Planned, this list will be used in order to decide which change requests should be integrated into the new iteration and which requests can be deferred for the time being. In addition, it will be specified which of the components that have not yet been implemented shall be included into the new iteration. The change requests and any unfinished requests concerning the »Overall System Specification are the basis for a new development cycle. In addition, it will be examined whether the products »Project Manual and »QA Manual are appropriate for the project. These activities are intended to reach the decision gate »Iteration Scheduled.
From 'Acceptance Completed' to 'Requirements Specified'
After project definition, the user requirements will be prepared and subjected to a »Requirements Evaluation. The user will examine the requirements for completeness and correctness. In case of a positive assessment, the acquirer specifies and prioritizes the requirements in form of the »Requirements Specification. In addition, an »RFP Concept will be prepared in order to ensure that the contract award law will be observed during the request for proposal. These activities are intended to reach the decision gate »Requirements Specified.
From 'Acceptance Completed' to 'Project Completed'
If all requirements have been taken into account and all change requests are completed, it will be decided to finish the project. A »Final Project Report will be prepared and submitted to the acquirer. These activities are intended to reach the decision gate »Project Completed.