 |
 |
 |
|
 |
|||
| 8.5.1 Project Manual (PMa) |
 Contents
|
|
|---|
Introduction
The Project Manual comprises the project description, an overview of contract-relevant specifications (activities and products to be realized or deleted, products to be delivered, participation of the customer), the instructions for the realization of the project, i. e. the project-specific V-Model which is represented in four sections (SD, QA, CM and PM regulations), the specification of the project organization, the selected methods and tools, and the standards and regulations defined.
Document Index
1. General Information2. Project Description
3. Overview
4. Development Strategy
5. Project-Specific V-Model
5.1. SD Regulations
5.1.1. Activities
5.1.2. Products
5.2. QA Regulations
5.2.1. Activities
5.2.2. Products
5.3. CM Regulations
5.3.1. Activities
5.3.2. Products
5.4. PM Regulations
5.4.1. Activities
5.4.2. Products
6. Selection of Methods and Tools
7. Project Organization
7.1. Organizational Structure
7.2. Tasks and Responsibilities
7.3. External Interfaces
7.4. Reporting
7.5. Participation of Customer
8. Standards and Regulations
Document Structure
1. General Information
See schema 1. General Information.2. Project Description
The objective of the project is explained to the participants in the project in the form of a short and concise description.Information about the following project characteristics must also be included:
- product type (System, Segment, HW Unit or SW Unit) of product to be developed
- planned upgrades
- classification of the software (operational software, proof software, SWMM software, support software, training software, etc.)
- classifications of criticality and IT security levels
- desired quality and quality risks
- maintainability requirements
- marginal development requirements
- size of the project
- critical success factors
3. Overview
This chapter includes all essential project specifications relevant for the contract (see Table 8.1: Example for an Activity/Product Overview). The scope of performance and delivery in particular need to be explained.The scope of performance is determined by the tailoring of the V-Model where all activities and products of submodels SD, QA, CM and PM have to be listed, by stating the tailoring criteria (deletion reasons for deleted activities and technical deletion conditions for optional deletions during the project development). (For this, the overview illustrations on the last pages of the corresponding submodel in the generic V-Model can be used.) For the individual (sub-) activities and (sub-) products the possibly covered deletion conditions (reference "not applicable" by mentioning the reason for the deletion) or the relevant technical deletion conditions have to be documented. (Sub-) activities/(sub-) products for which no deletion conditions are listed have to be realized/generated in the project.
The specification of the objects to be assessed to which individual QA activities refer is realized in the QA Plan.
All products of the V-Model to be delivered (deliveries) are identified. Apart from the SD and QA products, the customer may also demand the delivery of CM and PM products.
The (sub-) activities and (sub-) products of the project-specific V-Model to be processed with the participation of the customer have to be documented. Further information about participation are defined in chapter 7.5. Participation of Customer.
| No. | Activity | Product | Type of Deletion |
not applicable, because (AT Reason) when (TT Condition) |
Customer Participation |
Delivery Object ... |
... |
|
|
|
|
| SD 4-SW |
Preliminary SW Design |
SW Architecture |
- |
- |
approval |
yes
| SD 4.1-SW |
SW Architecture Design |
|
- |
- |
- |
| SD 4.2-SW |
Design of Internal and External SW Interfaces |
Interface Description |
- |
- |
- |
yes
| SD 4.3-SW |
Specification of SW Integration |
SW Integration Plan |
TT |
not applicable, if integration is not complex |
- |
no
| SD 5-SW |
Detailed SW Design |
- |
- |
- |
- |
-
| SD 5.1-SW |
Description of SW Component/Module/ Database |
Data Dictionary |
SW Design AT |
never applicable for SW Modules and SW Components because the algorithm was sufficiently described in the SW Architecture |
- |
no
| SD 5.2-SW |
Analysis of Resources and Time Requirements |
SW Design |
AT |
never applicable because sufficient resources are available |
- |
no
| ... |
... |
|
|
|
|
| |
4. Development Strategy
The development strategy used as a basis for the V-Model is an incremental development. (The Scenarios manual of the Collection of Manuals, Part 3, lists possible application strategies, together with the corresponding effects on the planning and development activities.)This chapter has to list (in addition to the activity/product overview) the application of the planned development strategy (incremental, use of off-the-shelf-products, object-oriented, etc.) for the different project sections or upgrades. The effects of the selected development strategy (iteration of development activities) must be considered in the project planning (Project Plan).
If different scenarios are used for different system parts the use of several scenarios has to be illustrated.
5. Project-Specific V-Model
The project-specific V-Model is reached via the tailoring of the (generic) V-Model. To do so all those activity and product regulations are extracted from the generic V-Model for a specific project that will be used as binding work specifications during the project. Thus, only those regulations are contained in the Project Manual that will be applied in the respective project. These are the set of activities and products of the generic model, minus all (sub-) activities and (sub-) products that are not relevant.The activities and products can either be completely described here or they may be only listed as a reference to the V-Model activities and products.
5. 1. SD Regulations
5. 1. 1. Activities
5. 1. 2. Products
5. 2. QA Regulations
5. 2. 1. Activities
5. 2. 2. Products
5. 3. CM Regulations
5. 3. 1. Activities
5. 3. 2. Products
5. 4. PM Regulations
5. 4. 1. Activities
5. 4. 2. Products
6. Selection of Methods and Tools
Provided that the application of certain methods and tools has been agreed, this chapter includes the allocation of the methods and tools (see Table 8.2: Example for a Method/Tool Allocation) for the activities listed in chapter 5. Project-Specific V-Model of the Project Manual.| No. | Activity | Method | Tool
| SD 1.1 |
Recording of Actual Status and Analysis |
ER Modeling |
Data Flow Modeling Tool 1 | Tool 2 SD 1.5 |
User-Level System Structure |
Functional |
Decomposition Tool 3
| SD 2.1 |
Technical System Design |
Functional |
Decomposition Tool 3
| SD 3.3 |
Definition of Requirements for the Functionality |
Functional |
Decomposition Tool 3
| SD 4.1-SW |
SW Architecture Design |
Structured |
Design Tool 4
| ... |
... |
... |
...
| |
In addition, more detailed information for the selected methods and tools can be stated here.
7. Project Organization
This contains a description of the project's organizational structure. It is clarified which are the members of the project team (i. e. what departments, instances, it is made up), and also how tasks and responsibilities are to be distributed to these members, and which interfaces are included in the project.7. 1. Organizational Structure
This chapter lists the departments in charge of the realization of activities in the submodels (SD, QA, CM, PM).This contains an illustration of how the roles in the V-Model are mapped to the internal organizational units; furthermore, project-specific instances or teams (e. g. change control board) may have to be set up. It must be clarified to which extent the organizational model can cope with the role allocation specified in the V-Model.
The degree of independence of the organizational unit "quality assurance" and the relationships to the system generation, the configuration management, and the project management, as well as to the user and to the customer, must be documented.
7. 2. Tasks and Responsibilities
It is also necessary to enter into the project organization plan how tasks and responsibilities are distributed to the above listed organizational units. The instances for decisions and approvals must be minutely defined.- In this connection, QA and CM (e. g. internal quality assurance, quality approval instance) must also be defined (e. g. who is in charge of the quality assurance, which instance is entitled to release products internally or externally to be further used).
- Depending on the classification it is necessary to define which of the CM activities are to be realized by which instances.
- The control of the technical interfaces between Segments and SW Units/HW Units has to be given particular attention. The control of these interfaces requires particular attention for control, information, agreement and exchange measures because normally various instances or companies work with these interfaces. Even in one internal organizational unit, especially the development and agreement of SW-HW interfaces must be most minutely specified. Does one side change an interface then it must be guaranteed and controlled that necessary updates are realized on the other side. The required CM measures for these changes are allocated to the CM instances (e. g. Interface Control Working Group).
7. 3. External Interfaces
Communication and procedure interfaces with company-external instances (customer, subcontractors, partners, bodies and committees, admission boards) are defined here. It is documented who is getting which type and form of information (technical or administrative, in writing or verbally) when (set date, periodically, event-driven) by whom or to whom he is going to pass it on.Contacts must be named for the individual interfaces; also, it must be cleared up which activities these contacts must take care of or for which products they are responsible or in which fields they are competent.
This list should include the following information about every contact:
- name of contact
- complete address of contact
- department
- position in project, responsibility, subject field
- telephone/telefax number(s)
- communication address(es).
7. 4. Reporting
Communication and procedure interfaces with company-internal instances are defined here. It is documented who is getting which type and form of information (technical or administrative, in writing or verbally) when (set date, periodically, event-driven) by whom or to whom he is going to pass it on.Any other information listed in chapter 7.3. External Interfaces also applies to this chapter.
7. 5. Participation of Customer
The responsibilities of customer and contractor have to be defined by means of the allocation of tasks (activities of the V-Model) and responsibilities to customer and (sub-) contractors. The allocation to both sides, by taking into consideration the respective areas of responsibility, must be particularly specified for activities of QA, CM and PM.The participation of the customer in the project is subject to the customer's own decision. Activity/roles matrices of the V-Model must be adjusted to the plans of the customer.
8. Standards and Regulations
Standards and regulations are coding standards, document templates, and naming conventions. This Project Manual may contain either the description of the standards, regulations and guidelines, or a reference to an existing document which can be accessed by all participants in the project. Links to the V-Model Mailinglist
Mail 0629 - PM 1.4 - Wer akzeptiert das Projekthandbuch? (629)Mail 0628 - Re: Tailoring / Individuelle Anpassungen (628)
Mail 0608 - PHB sehr großer Projekte (608)
Mail 0595 - Re: Unterstützung der Betriebseinführung (595)
Mail 0593 - Re: Durchführungsentscheidung (593)
Mail 0566 - Projekthandbuch für Ausbildungssimulatoren (566)
Mail 0322 - KM 1.1: KM-Plan erstellen (322)
Mail 0240 - Re: PM Auftragnehmer (240)
Mail 0173 - Re: QS-Plan nach V-Modell 97 (173)
|
|
|
This page online • GDPA Online • Last Updated 05.Feb.2003 by C. Freericks |