Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
BRH  Homepage  
FAO.2 Matching FAO Requirements and the Regulations of the V-Model  

  BRH.2 Abgleich der BRH-Forderungen und der Regelungen des V-Modells

In the folllowing, the FAO requirements are matched with the regulations of the V-Model.

No. Chapter FAO Text Notes
1 1.4.1 Planning and use of the IT must be documented. The documentation comprises:
  • the overall planning for the IT application
  • the realization of IT enterprises
  • the operation of IT procedures
  • The overall planning for the IT application is mainly covered in the IT framework concept. The V-Model only contributes individual IT enterprises to the overall planning (compare (6)). The documentation of the realization of IT enterprises is a result of the V-Model products. The documentation of the operation of IT procedures in the V-Model is handled by the products Information for the User Manual and Other Application Information.
    2 1.4.2 The IT documentation must be complete and should not overlap. The documentation must be up to date, intelligible and correct; it must contain a list of all modifications. This represents a basic requirement for a lifecycle process model.

    On the one hand, the V-Model offers a complete and non-overlapping documentation. On the other hand, however, it does permit a flexible definition of the size of the required documentation by means of the tailoring. The requirement for a complete IT documentation stresses the importance of the tailoring procedure.

    3 1.4.3 For economic reasons, the generation, maintenance, and storage of the documentation ought to be supported by computers, if possible. It must be assured that the documentation can only be modified by authorized personnel. Chapter 1.4.3 is a requirement for a configuration management. In the V-Model, this is covered by submodel CM. The corresponding regulations for the configuration management can be found in the CM Plan where they can be mapped individually to the organizational structure in question.

    4 1.4.4 Those parts of the documentation required for completing the tasks must be made available in several copies to all departments and staff members participating in the realization of the IT enterprise and in the operation of IT procedures. That documentation must always be up to date. This requirement has to be met by means of organizational regulations, depending on the enterprise. In order to have a version of the documentation that is up to date, a functioning configuration management (submodel CM) is required.
    5 1.4.5 The individual details of the layout, the generation, and the content as well as of the distribution and storage of the documentation have to be sorted out in written form, and within the scope of the applying regulations. Generation and content of the documentation are regulated by the V-Model (activities and product descriptions). Details with regard to the layout of the documentation (e. g. documentation standard) have to be set up in the Project Manual.

    The distribution of the documentation is regulated in 7. 3. External Interfaces, and 7. 4. Reporting of the Project Manual.

    Details with regard to the storage of the documentation are set up in the CM Plan in chapters 2. 1. Product Library, and 4. Data Backup and Archiving.

    6 2 The application of the IT must be realized on the basis of an overall planning. Depending on the planning and development stage, the overall plan should include:
    • organization, existing IT procedures and technical installations, as well as the professional staff members employed,
    • general representation and foreseeable development of the tasks that are to be completed with the help of the IT,
    • areas of contact and overlaps between these tasks and other tasks and task fields,
    • objectives of the planned IT application,
    • IT enterprises being planned and being worked on, including its priorities and its organizational and personnel impacts,
    • time required for the realization of the IT enterprises,
    • implementation strategies and training,
    • planning and measures for the security of IT applications,
    • statements with regard to profitability,
    • required budget resources.
    The overall planning must take into consideration norms, standards, and applying regulations. The overall planning must be checked and updated on a regular basis.

    By means of the overall planning and practical coordination it is to be guaranteed in particular that

    • multiple development of IT procedures for similar tasks will be prevented,
    • uniform procedures will be used, integrated solutions will be the goal, and
    • resources in the IT field will be economically utilized.
    The V-Model always refers to only one IT enterprise. For each individual IT enterprise, the V-Model makes contributions for the following items of the overall planning: Demands and requirements for all projects are met by the IT framework concept.
    7 3.1.1 IT enterprises include conception, development, introduction and essential IT modifications. This statement conforms with the objective and the application of the V-Model.
    8 3.1.2 The principles with regard to the guarantee for a uniform and systematic procedure to realize IT enterprises, including the generation of proper sections with adequate subgoals, have to be set up in writing. In this connection, it is important to organize practical means to control and supervise the planning, and to set up rules for the use of standardized procedures and techniques (methods and tools). The above listed requirements represent a basic requirement for the application of a lifecycle process model. The requirement for controlling and supervising the enterprise is specially met with submodel project management. The use of standardized procedures and techniques has to be regulated in the IT framework concept, considering internal standards. Any rules or regulations with regard to the project-specific use of standardized procedures and techniques (methods and tools) are documented in the Project Manual.
    9 3.2.1 Responsibilities and procedure must be set up at the beginning of an IT enterprise. In case several departments are in charge, rules have to be set up individually with regard to participation and responsibility. Responsibilities and procedure are set up in the Project Manual. The time schedules are listed in the Project Plan. Any special rules regarding CM and QA are also documented in the CM Plan or the QA Plan.

    The cooperation with several contractors is described in section How to use the V-Model of the Coordinating the V-Model in its Environment manual. Rules that were agreed on are documented in one or possibly several of the Project Manuals.

    10 3.2.2 The overall IT plan is the basis for an IT enterprise. Basically, an IT enterprise should include the following:
  • preliminary and final investigation and
  • realization of the enterprise.
  • The above mentioned requirement is met by a phase model (e. g. phase model according to BVB [future EVB], GD 220).
    11 3.3.1 Prior to the realization of an IT enterprise it is necessary to carry out a preliminary and a final investigation. The above mentioned requirement is met by a phase model (e. g. phase model according to BVB [future EVB], GD 220).
    12 3.3.2 It is the purpose of the preliminary investigation to find out if, and if yes, by which solution version, the IT can be applied to fulfill a task at user-level and technically, and if this is practical and profitable. On this basis it must be decided if and for which solution version final investigations will be justified. This requirement is met by the activities SD1.7 - Realization of Requirements Controlling and SD2.3 - Investigation of Feasibility.
    13 3.3.3 It is the purpose of the final investigation to carry out detailed investigations, i. e. on the basis of the results of the preliminary investigation. The above mentioned requirement is met by a phase model (e. g. phase model according to BVB [future EVB], GD 220).
    14 3.3.4 Preliminary and final investigation reports should include the following information, either in a rough or more detailed form:
    • name of enterprise, staff member or team,
    • objectives, content and size of enterprise,
    • actual state analysis, with both a description and an evaluation of the actual structure and process organization from a technical and organizational point of view,
    • representation of the alternatives for the arrangement, by taking into consideration the use of available procedures or parts thereof, as well as standard or third-party software and the possible use of available data stocks,
    • projected suggestion with a draft of the new structure and process organization, the rules to be observed or to be modified, the description of the technical system concept and the requirements with regard to the hardware configuration and the system and application software, the design of the database (e. g. data organization, quantity listing), the data flow, and the relationship between information,
    • representation of the measures deviated from a risk analysis, in order to guarantee the correctness and security of the procedure,
    • time, personnel, and resources required for the realization of the enterprise, including training, office equipment, also for possibly required rebuilding, and for the operation,
    • profitability check, and, where appropriate, cost/benefit analysis.
    The activities SD1 - System Requirements Analysis, SD2 - System Design, PM1 - Project Initialization, PM4 - Detailed Planning, and PM5 - Cost/Benefit Analysis in particular are contributing to these reports.
    15 3.3.5 Both the preliminary and the final investigations can-in as far as this is operationally and technically justified-be combined, if the reasons for this are put down in writing. This statement is not a requirement.
    16 3.3.6 The results of the preliminary and final investigations must be documented in a report. These reports conclude with a suggestion for the decision. The decision has to be put down in writing. The above mentioned requirement is met by a phase model (e. g. phase model according to BVB [future EVB], GD 220).
    17 Based on the result of the final investigation, a decision must be made about the realization of an IT enterprise. The realization includes the following:
    procurement of hardware and software, for appropriate regulations see activity PM2 - Placement/ Procurement
    the placing of development orders and/or development of procedures, including the programming, for appropriate regulations see activity PM2 - Placement/ Procurement.
    In case external contractors participate in the development, further rules can be found in the QA Plan, chapter 5.2, "Controlling Subcontractors". If the job is completely placed externally the Project Manual is to be considered as object of the contract.
    test and release as well as pertinent agreements are defined in the QA Plan, chapters 4, Quality Assurance during Development, and 5.3, Software Unit Exit Control)
    introduction of the procedure pertinent regulation is defined in activity SD9 - Transition to Utilization)
    18 All details of the realization of an IT project have to be documented. The entire documentation of the realization of an IT project is regulated in the V-Model. The information defining which documents are relevant for a certain procedure can be found in the Project Manual.
    19 3.4.2 Procurement of Hardware and Software

    With regard to the hardware, the best configuration and procurement method (purchase, rent, leasing) has to be selected, under the aspects of profitability. The system consisting of hardware and software should have the proper dimension and it should be possible to upgrade this system easily. Any dependence from individual manufacturers should be avoided, as far as this is possible. The parts of the system consisting of hardware and software should be compatible with each other and with other components and procedures that are already available.

    The above mentioned requirements are covered in activity PM2 - Placement/ Procurement, and the scenario Application of Off-the-Shelf Products, described in the Scenarios manual.
    20 3.4.3 Placing of Development Orders

    Development jobs are only to be placed externally when internal staff are not available for a proper realization of the enterprise, or when the external placement of jobs seems advisable for particular reasons. In case IT enterprises, in particular the development of software, are placed externally, it is necessary to basically observe these minimum requirements. Projects of this kind have to be kept under appropriate supervision.

    The above mentioned requirements do not refer to the regulations in the V-Model. However, they have to be observed when handling the activities PM1.5 - Generation of Preliminary Plan and PM4 - Detailed Planning.

    Furthermore, the above mentioned requirements refer to the statements with regard to how to use the V-Model (basis for contracts, instruction), which are listed in the "ENV" manual. The application as "basis for contracts" is used for the control and supervision of IT enterprises that have been realized by external contractors. Since the tailored V-Model has been used as the basis for contracts it is possible to precisely regulate the procedures and the deliveries. Therefore, the minimum requirements can be met and observed.

    21 It is necessary to set up rules for the generation of programs and for the use of programming languages that help to simplify and standardize both the programming and the programs. The application of the V-Model helps to standardize the development of software. Further regulations, such as the definition of the programming language, the methods, etc., must be specified within the scope of the internal standards in the IT framework concept and also in the Project Manual for each individual project. The above mentioned requirement must therefore be observed while writing the Project Manual.
    22 Programs should be generated in compliance with the regulations, with regard to security and profitability, as well as with regard to maintenance and operation; they should include independent program parts that can easily be modified and tested, and have defined interfaces. The programs have to be developed according to the requirements so they can easily be continued by other programmers. The above mentioned requirement is met by using the V-Model, which helps to standardize the procedure. This way, a dependence on the individual ways of particular persons can be prevented, and new persons can easily take over their jobs.
    23 The user-friendliness of the IT deserves special attention. Regulations have to be observed or, respectively, to be set up, with regard to:
    • design schema of masks,
    • generally valid function keys and commands,
    • messages for users and operating personnel,
    • error handling,
    • help functions, and
    • design schema of print output.
    The demanded requirements have to be met within the scope of the activities of the V-Model (submodel SD). The individual demanded features have to be defined with the User Requirements and the Technical Requirements.
    24 The process documentation must prove all process functions, in particular those of the programs, in a way that can be easily reconstructed. The process documentation includes, among other things:
    • definition of order and task,
    • lists of characteristic numbers, keys, symbols, and abbreviations,
    • description of files and, if required, databases, up to the data field level, with information about the structure and a description of measures for the protection and archiving of data,
    • directories of programs or of program parts, in their last valid version,
    • a representation of all programmed and organized checks,
    • representation of the program flow and the data flow, if necessary, also a listing of the source programs with program compilation,
    • description of the masks, lists, and forms,
    • representation of the embedding into the technical environment and the technical areas of contact to other procedures and descriptions of exporting the programs into other technical environments,
    • Service, handling and operating instructions as well as Change Orders and change proofs.
    The required documentation for the procedure corresponds to the products to be generated according to the V-Model.
    25 Prior to its release, all functions of IT procedures have to be tested with regard to their functionality, in complex procedures they have to be tested on a step-by-step basis while the programs are being generated. Special attention has to be paid to interfaces to other procedures and the later organizational integration into the operation. It also has to be checked with the help of the tests that each program only meets the required functions which have to be defined, and that none of the programs has any undesirable side effects. All tests must be realized by taking into consideration all of the hardware and software components so the process operation will not be impaired. The above mentioned requirements are met by the submodel quality assurance of the V-Model. The V-Model does not include methods, however, and therefore does not refer to the method "Test" but to "Assessment of the Content" instead.

    With regard to quality assurance, the regulations of the V-Model go far beyond the minimum IT requirements. Therefore the above mentioned requirements only refer to the quality assurance of programs, while the V-Model also includes a quality assurance of the entire documentation of an enterprise, i. e. e. g. it also includes the requirements documents.

    26 Tests must be realized on the basis of test cases; input and expected output must be defined in advance. The results of the final test have to be checked, assessed and accepted by the departments participating in the enterprise, with the participation of the data processing department. The responsible departments must generate test cases that have to be completed with regard to the technical operation of the data processing department. It should be possible to reuse test cases. The above mentioned requirements are met by the submodel quality assurance of the V-Model.

    Test cases are documented in product Assessment Specification (activity QA2.3 - Definition of Test Cases); the evaluation of the test results is documented in Assessment Reports (activity QA4.2 - Assessment of the Content of the Product).

    For the processing of activities, the V-Model provides roles. It must be defined for each project to what extent these roles can be allocated to staff members of the data processing department or of the participating departments.

    27 The test results have to be documented. The documentation of the final test as part of the process documentation should include:
    • the user-level and technical background for the test (e. g. introduction of a new procedure, error correction, essential changes),
    • the description of the test environment (tested programs with information about version, tested process, connected files and databases, hardware and software environment with identified version),
    • the test cases with input and expected output data,
    • the test results including the system behavior and the system messages, together with the user-level and technical assessments of the test results by the departments participating in the test, and
    • the statement of acceptance of the participating departments.
    With the exception of the statement of acceptance, the above mentioned requirements are met by the submodel quality assurance of the V-Model.

    Test cases are documented in product Assessment Specification. The description of the test environment is included in the Assessment Plan. References to versions are defined in the Configuration Identification Document (CID). Test results are documented in Assessment Reports.

    28 The competent department, normally a department that is technically responsible, releases the procedure for the final testing, on the basis of the statement of acceptance. Then this department takes over the overall responsibility for the correctness and security of the procedure. The release of procedures is not regulated in the V-Model.
    29 The release certificate is part of the procedure documentation. It must include the following:
    • name of the procedure,
    • reason for test and release,
    • time, when respective procedure version was first used,
    • exact name of released programs, together with version numbers,
    • acknowledgment that the required assessments have been carried out, and
    • release statement.
    The release of procedures is not regulated in the V-Model.
    30 In principle, a procedure must only be released after the documents have been handed in completely. The release of procedures is not regulated in the V-Model. The decision about the completeness of the documentation is guaranteed by the correct use of the tailoring procedure.

    On top of that, submodel project management includes so-called phase reviews (activity PM6 - Phase Review). The objective of the phase review is, among other things, to assess the completeness of the documents.

    31 Even procedures that were not internally developed have to be tested and properly released prior to being utilized. This requirement is met by activity QA4 - Product Assessment. The requirements with regard to assessments that were not developed internally are defined in chapter 5.1 of the QA Plan, "Entry Control of Off-the-Shelf Products".
    32 Details about the assessment and release procedure must be set up in writing. Regulations of test methods are laid down in the QA Plan (chapter 4, Quality Assurance during Development, and 5.1, Entry Control of Off-the-Shelf ProductsAssessment Specifications and Assessment Procedures.

    The release of procedures is not regulated in the V-Model.

    33 After the release it must be guaranteed that no further modifications will be undertaken until the product is integrated into the production environment. The configuration management will make sure that this requirement is met.
    34 After the integration of process software into the production environment, unauthorized modifications must no longer be possible. A computer-generated protocol should be made of the integration into the process. This must only be done by specially authorized staff members. An orderly administration of program versions must be guaranteed. The regulations of the configuration management will make sure that this requirement is met. Procedures for changes are defined in chapter 3, Change Management of the CM Plan.
    35 In order to introduce a procedure, the following must be guaranteed:
    setting up the hardware and software environment for the operation, definitions are found in the Project Manual
    in as far as required, to take over the data stocks of a procedure to be replaced, and pertinent regulations are found in activity SD9.3 - Putting into Operation
    staff training (pertinent regulations are found in activity SD9.1 - Contribution to Support for Introduction).
    36 It is necessary to make sure of a continuing consulting and training even after the introduction of the procedure. Consulting and training after the introduction of the procedure is not regulated by the V-Model. However, the Operational Information from activity SD8.3 - Product Supply may be made used, if required.
    37 3.5.1 While maintaining the procedure, the correct application and its adoption to changed requirements has to be guaranteed. In as far as changes become necessary the procedure should be the same as in a new IT enterprise. Corresponding regulations have to be set up for other changes. Basically, a new final assessment and release is required for whenever a procedure is changed. The above mentioned requirements match the intention of the V-Model. Special regulations with regard to procedure changes are found in the CM Plan. The realization itself is defined in activity CM3 - Change Management (Configuration Control).
    38 3.5.2 In case of deviating procedures, regulations have to be set up in writing so errors can be corrected more speedily; the cooperation of the responsible departments must be guaranteed. Deviating procedures which make a fast correction of errors possible have to be set up in the CM Plan.
    39 3.5.3 Hardware modifications and modifications of the process-related software have to be made within the scope of a regulated procedure. At the same time, it must be assured that matching modifications are realized completely, and that malfunctions or interruptions of the procedure itself are prevented on the basis of further changes. The principles with regard to test and release described for the realization of an IT enterprise should be applied correspondingly. All measures in connection with modifications have to be documented. The "regulated procedure required for changes" is guaranteed by the configuration management (activity CM3 - Change Management (Configuration Control). The project-specific procedures have to be described in the CM Plan.
    40 4 Operation of IT Procedures. The operation of IT procedures is not regulated in the V-Model.
    41 5 Success Control. The control of the success of an IT procedure is not regulated in the V-Model.
    42 6.1 The procedure development and operation have to be continually controlled and assessed with regard to the constant observance of defined rules, procedures and techniques (methods and tools). Control and assessment are to be realized on quality standards to be set up in advance. In case of deviations from these rules, appropriate measures have to be taken.

    The "observance of defined rules" is guaranteed by activity QA3 - Process Assessment of Activites.

    43 6.2 It must be checked in reasonable time intervals if procedures have been correctly applied and if there are any weak points that should be eliminated. The result of those checks as well as the measures taken have to be documented. Activity PM6 - Phase Review will make sure that this requirement is met. The results are set down in form of a Protocol.
    44 7.2.1 All measures suitable for maintaining the security must be deviated from a (threat and) risk analysis; the necessary measures taken have to be represented in a security concept. In activity SD1.6 - Threat and Risk Analysis, a threat analysis is demanded to find out about all objects to be protected, while a risk analysis is demanded to detect the probability that such a threat is likely to occur. The IT security concept is set up within the scope of activity SD2.1 - Technical System Design, and, if required, a formal IT security model as well.
    45 7.2.2 Based on the risk analysis and the security concept, technical and organizational measures have to be defined as required. These measures must be adjusted to each other. The V-Model contains technical instructions with which to meet the required security level. Organizational measures can be found in the IT framework concept as well.

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks