3 Part 3: V-Modell Reference Tailoring
3.5 Project Type Variants
3.5.5 Project (Acquirer/Supplier) Including Development, Enhancement or Migration
|
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 Development, Enhancement or Migration 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 Development, Enhancement or Migration is based on the fundamental idea that the user requirements are relatively clear at the beginning of the project. After the Requirements have been defined in the decision gate »Requirements Specified, subsequent changes of the Requirements can only be executed via the problem and change management and the »Decision Gate »Iteration Scheduled. The system will be designed, realized and delivered in individual stages, which are also referred to as »Increment. Each stage will be accepted individually. The System Developer may execute several internal iterations before delivering an increment.
In this »Project Execution Strategy, changes within one increment should be avoided and included by the Change Management into the following increment. Important changes, which could - for example - influence the system architecture significantly, should be forwarded as early as possible. This procedure has the advantage of providing the User with a prestage, which already realizes the system's most important basic functionalities at an early time.
The project type variant »Project (Acquirer/Supplier) Including Development, Enhancement or Migration is not only suitable for the development of new systems. During the enhancement of legacy systems, the new System Requirements, which will be included in the enhancement process, are documented. The enhancement or migration of a system in maintenance is indicated if System Requirements would entail effects on the system architecture.
If the system is migrated to a new enviroment, e.g. a new hardware platform or a new running time environment, the Requirements will be based on other features. These may include the existing functionalities as determined by the Overall System Specification (»System Specified) within the scope of the »Legacy System Analysis, Requirements of the change status list, and new Requirements of the User. A complete migration is not always necessary. In case of a partial migration, parts of the legacy system remain on their original platform while the access to the new system is provided by integration technologies.
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, Prototype Development
Activity Flow
Figure 17: Project type variant Project (Acquirer/Supplier) Including Development, Enhancement or Migration
The decision gates and the sequence of the project type variant »Project (Acquirer/Supplier) Including Development, Enhancement or Migration are shown in figure Figure 17. This project type variant permits the application of different development strategies:
The decision for a development strategy is always made after the decision gate »Iteration Scheduled has been scheduled. If there are, for example, high realization risks, it is possible to execute an early iteration by means of a prototypic development.
In the following, the sequence 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 Elements Realized (prototypical development)'
After the iteration has been planned, the realization of the individual software units of the system and the enabling systems will begin. Of course, this requires a basic understanding of the system architecture and the information which system elements should be realized. However, this is not reflected in a decision gate, since the agile system development permits the architecture and additional design decisions to be changed without problems during the implementation. At this point, the evaluation reports are used in order to check whether the individual system elements were realized in accordance with the acquirer requirements. The realization finally leads to the decision gate »System Elements Realized.
From 'Iteration Scheduled' to 'System Specified (component based development)'
In the project, the requirements planned will be evaluated, 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 Specified (incremental development)'
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.
Possible transitions based on 'System Elements Realized (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'System Elements Realized (prototypical development)' to 'Detailed Design Completed (prototypical development)'
The specification and documentation of the elements can be prepared based on the realized system elements. The correctness of the specifications will be examined at the decision gate »Detailed Design Completed.
Possible transitions based on 'Detailed Design Completed (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'Detailed Design Completed (prototypical development)' to 'System Elements Realized (prototypical development)'
After the detailed designed has been specified, software elements can be realized anew. This provides a possibility for planning internal iterations in the software development. These activities are intended to reach the decision gate »System Elements Realized.
From 'Detailed Design Completed (prototypical development)' to 'System Integrated (prototypical development)'
After specification of the detailed design, the elements will be integrated, and the correct functionality of the system will be examined based on the evaluation reports of the system. If there are separate suborders, their results will now be integrated. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'System Integrated (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'System Integrated (prototypical development)' to 'System Designed (prototypical development)'
If the integrated systems and enabling systems are available, the architecture of the systems and enabling systems can be specified. The capacity of these architectures will be examined. These activities are intended to reach the decision gate »System Designed.
Possible transitions based on 'System Designed (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'System Designed (prototypical development)' 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 'System Designed (prototypical development)' to 'System Elements Realized (prototypical development)'
The system design is the prerequisite for executing an additional realization iteration before the overall system is specified. For this purpose, software elements already realized will be developed further or components not yet processed will be implemented. These activities are intended to reach the decision gate »System Elements Realized.
From 'System Designed (prototypical development)' to 'System Specified (prototypical development)'
After the decision gate »System Designed has been reached and all internal iterations have been completed, the specification for the developed overall system will be prepared, taking into account all systems and enabling systems which have been realized and designed up to now. Afterwards, the correctness of the »Overall System Specification will be rechecked. These activities are intended to reach the decision gate »System Specified.
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 Integrated (prototypical development)'
After specification of the detailed design, the elements will be integrated, and the correct functionality of the system will be examined based on the evaluation reports of the system. If there are separate suborders, their results will now be integrated. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'System Specified (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'System Specified (prototypical development)' to 'Delivery Conducted (prototypical development)'
After the overall system developed in an agile manner has been specified it will be checked whether a delivery is possible. In case of a positive decision, the current version of the system will be delivered to the acquirer, and the decision gate »Delivery Conducted is reached.
Possible transitions based on 'Delivery Conducted (prototypical development)' (Ablaufbaustein Prototypical System Development)
From 'Delivery Conducted (prototypical development)' 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 'System Specified (component based development)' (Ablaufbaustein Component-Based System Development)
From 'System Specified (component based development)' to 'System Designed (component based development)'
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.
From 'System Specified (component based development)' to 'Detailed Design Completed'
After the decision gate »System Specified has been reached, the work on the detailed design may begin, which will happen simultaneously with the preparation of the system design at the Decision Gate System Designed. At this decision gate, the system is developed top-down, i.e., from the system down to the units, based on the »Overall System Specification. In the project execution strategy »Component-based System Development (Supplier), not only the »Overall System Specification, but also the specifications for external software/hardware modules are available. In order to integrate these modules into the system design, the detailed design for the modules will be prepared bottom-up, i.e., from modules to units. If system design and detailed design are developed in parallel, it must be ensured, that the common interfaces, i.e., »Software Unit, »Hardware Units and »External Unit, reflect the design coherently. In addition, the development process and test strategy will be specified, and external software/hardware specifications for any suborders will be prepared as required. These activities are intended develop the system design in parallel to the detailed design and to reach the decision gate »Detailed Design Completed.
Possible transitions based on 'System Designed (component based development)' (Ablaufbaustein Component-Based System Development)
From 'System Designed (component based development)' 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 'System Designed (component based development)' to 'System Integraded (component based development)'
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. In order to ensure the integration capability of the different units, the process aims at the Decision Gate System Integrated while awarding contracts for external units and providing for the project-own realization of units. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'Detailed Design Completed' (Ablaufbaustein Component-Based System Development)
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' (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 Elements Realized'
After acceptance, the units will be integrated into the project.
Possible transitions based on 'System Elements Realized' (Ablaufbaustein Component-Based System Development)
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 Integraded (component based development)'
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. In order to ensure the integration capability of the different units, the process aims at the Decision Gate System Integrated while awarding contracts for external units and providing for the project-own realization of units. 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 Integraded (component based development)'
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. In order to ensure the integration capability of the different units, the process aims at the Decision Gate System Integrated while awarding contracts for external units and providing for the project-own realization of units. These activities are intended to reach the decision gate »System Integrated.
Possible transitions based on 'System Integraded (component based development)' (Ablaufbaustein Component-Based System Development)
From 'System Integraded (component based development)' to 'System Specified (component based development)'
Since internal iterations can be executed in this project execution strategy, a new internal iteration may be planned. For this purpose, a transition to the Decision Gate »System Specified can be established by extending the »Overall System Specification. These activities are intended to reach the decision gate »System Designed.
From 'System Integraded (component based development)' to 'Delivery Conducted (component based development)'
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 (component based development)' (Ablaufbaustein Component-Based System Development)
From 'Delivery Conducted (component based development)' 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 'System Specified (incremental development)' (Ablaufbaustein Incremental System Development)
From 'System Specified (incremental development)' to 'System Designed (incremental development)'
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 (incremental development)' (Ablaufbaustein Incremental System Development)
From 'System Designed (incremental development)' 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 (incremental development)' 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' (Ablaufbaustein Incremental System Development)
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' (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 Elements Realized'
After acceptance, the units will be integrated into the project.
Possible transitions based on 'System Elements Realized' (Ablaufbaustein Incremental System Development)
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 (incremental development)'
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 (incremental development)'
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 (incremental development)' (Ablaufbaustein Incremental System Development)
From 'System Integrated (incremental development)' to 'System Designed (incremental development)'
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 (incremental development)' to 'Delivery Conducted (incremental development)'
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.
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 (incremental development)' (Ablaufbaustein Incremental System Development)
From 'Delivery Conducted (incremental development)' 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.