MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

MAXIMUS MAXimum fidelity Interactive Multi User Display Systems

Project Quality Plan

Title: Project Quality Plan Version: 1.0 Deliverable type: Report Deliverable Number: D3 Workpackage: WP9

Contractual Date of Delivery: 30.06.2008 Author(s): Daniel Danch, Thomas Gierlinger

Actual Date of Delivery: 31.08.2008 Reviewed by: Andr Stork Approved by: Andr Stork

Date: 31.08.2008

Date: 26.08.2008

Date: 26.08.2008

Summary: The Project Quality Plan identifies the procedures and activities that the consortium partners define, plan for, and execute to assure the quality of the project deliverables and project management. Responsible partner: Fraunhofer File name: D3_Project_Quality_Plan_20080831.doc Distribution list: Consortium and Project Officer

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

TABLE OF CONTENTS
1. 2. 3. EXECUTIVE SUMMARY ......................................................................................................................2 INTRODUCTION ..................................................................................................................................3 QUALITY EXPECTATIONS .................................................................................................................4

3.1 3.2
4. 5. 6.

QUALITY OF DELIVERABLES ................................................................................ 4 QUALITY OF PROJECT MANAGEMENT .................................................................. 5

QUALITY RESPONSIBILITIES ............................................................................................................6 STANDARDS AND TECHNOLOGIES .................................................................................................7 QUALITY ASSURANCE AND QUALITY CONTROL PROCESSES ...................................................8

6.1 6.2 6.3 6.4 6.5

7.

QUALITY ASSURANCE FOR DELIVERABLES........................................................... 8 QUALITY ASSURANCE FOR PROJECT MANAGEMENT ........................................... 10 QUALITY CONTROL OF DELIVERABLES .............................................................. 10 QUALITY CONTROL OF PROJECT MANAGEMENT ................................................. 11 LIST OF QUALITY CONTROL ACTIONS ................................................................ 11 CHANGE CONTROL .......................................................................................... 14 CONFIGURATION MANAGEMENT ........................................................................ 14 RISK IDENTIFICATION AND ANALYSIS .................................................................. 16 RISK MONITORING AND CONTROL ...................................................................... 16 PROJECT MANAGEMENT QUALITY ..................................................................... 18 SYSTEM QUALITY............................................................................................. 18
SUPPORTING DOCUMENTS ........................................................................................................19 REFERENCES ...............................................................................................................................20

CHANGE CONTROL AND CONFIGURATION MANAGEMENT PROCESSES................................14

7.1 7.2
8.

RISK MANAGEMENT ........................................................................................................................16

8.1 8.2
9.

QUALITY TOOLS...............................................................................................................................18

9.1 9.2
10. 11.

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

Document Log Version N 0.1 0.2 Date 14.07.2008 21.08.2008 Comments Initial draft version Authors Daniel Danch, Thomas Gierlinger

Revision including remarks from Daniel Danch Barco

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

1. EXECUTIVE SUMMARY
The Project Quality Plan is the third deliverable (D3) of the MAXIMUS project. It identifies the procedures and activities that the consortium partners define, plan, and execute to assure the quality of the project deliverables and project management. Its purpose is to define the minimum principles, requirements and processes to implement an effective quality assurance and control program. Compared to the Consortium Operating Procedures (D1), which is intended to be a short reference of the procedures to generate and validate deliverables, the project quality plan provides an in depth description of the quality expectations, the methods we will use to conform to these expectations and a list of supporting documents which specify the technical details of the implementations.

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

2. INTRODUCTION
The project quality plan formalizes the approach of the MAXIMUS consortium to assure the quality of the project outcome as well as the project management. In section 3 we define the quality expectations of the consortium regarding the project deliverables, i.e. the documents, software components and hardware components that we develop during the course of the project. The responsibilities of the involved parties and individuals regarding quality assurance are outlined in section 4. Section 5 lists the standards and technologies we adhere to and section 6 defines our strategies to assure the implementation of these standards. Our approach to change control (i.e. dealing with changes requested by the end users) is given in section 7 together with a description of our configuration management process (i.e. the procedure to handle the evolving prototypes of the MAXIMUS system). Details on our risk management are given in section 8. Section 9 lists the software tools we will use to facilitate the project management and software development process. The document concludes with an overview of the supporting documents (code styles guides etc.) in section 10.

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

3. QUALITY EXPECTATIONS
In this section we list our expectations regarding the quality of the MAXIMUS deliverables (documents, software and hardware) as well as the expectations concerning the project management.

3.1 Quality of Deliverables

The deliverables of the MAXIMUS project can be organized in four classes, namely documents, software components, hardware components and prototypes of the integrated MAXIMUS system. The common quality expectation of all deliverables is of course the timely delivery according to the project work plan. Further class-specific expectations are given below.

3.1.1 Quality of Documents

Deliverables which are documents should have a consistent and common format. The main issue is a common title page with the project logo. A common look will support the public awareness of the project since deliverables which are disseminated can be easily attributed to the MAXIMUS project. The common look should also be used for presentations at conferences for the same reason.

3.1.2 Quality of Software Components

First of all the software components must comply with the user requirements in terms of functionality, performance and stability. Their design should allow for extensibility and reusability to simplify the process of adding new features or adjusting functionality in a user centered design cycle. Another key aspect of the software quality is proper documentation. This includes English documentation in the source code to support the developers as well as user manuals to guide the end users. The source code should further conform to a common coding style in order to be easily readable.

3.1.3 Quality of Hardware Components

The hardware components must fulfill the user requirements. Those parts of the hardware that have to be operated by the end users (i.e. the projector prototypes) must be save (i.e. proper shielding of current and heat) and easy to setup. Such hardware prototypes will have to be equipped with a proper housing that provides protection against: Contact to primary voltage circuitry Hot components. High intensity UV light radiation
4

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

Moreover hardware prototypes will also be sufficiently grounded, and fuses will provide protection against short circuits. However, prototypes for use by other partners in this project can not be fully compliant to the CE label regulations, and for instance can have a higher EMC/EMI emittance. Instead they will be accompanied by a document from the engineering division with basic safety issue descriptions on the prototype and a warning regarding the non compliance to the CE label.

3.1.4 Quality of Integrated MAXIMUS System Prototypes

The main quality expectations for the integrated system prototypes, which consist of both, hardware and software, are correctness and usability. To this end they share most of the quality expectations of the software and hardware components: They must comply with the user requirements, be stable and have adequate documentation. Additionally installation and usage of the system should be as intuitive as possible.

3.2 Quality of Project Management

The project management is expected to be transparent as well as strict enough to keep the project progress in synchronization with the work plan. Quality aspects are the documentation of the project progress (both, financial and technical) and timely resolution of technical and financial issues. Furthermore the communication with the EC must be without unnecessary delays.

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

4. QUALITY RESPONSIBILITIES
We identified and categorized important deferred aspects of quality within the MAXIMUS project. The responsibilities to monitor the compliance with these aspects are assigned to different representatives according to their position and function in the management process. The Project Manager ensures that all documents handed out to the Commission conform to the documentation standards as proposed in this document and the Consortium Operating Procedures (D1). The quality aspects associated with the system design and system implementation will be monitored by the Technical Manager. The workpackage leaders assure the compliance with the quality standards applied in the individual workpackages of the project. Furthermore individual team members become the most effective way to implement quality into the MAXIMUS system efficiently and completely. The following Table 1 outlines the different aspects of quality and the responsible persons for ensuring and monitoring project quality.

Aspect of Quality General Project Documentation and Reports Code Documentation User Documentation System Design Standards Compliance System Evaluation and Testing Usability Quality Change Control Project Manager Developer

Monitored by

Workpackage Leaders / Technical Manager Workpackage Leaders / Technical Manager Workpackage Leaders Technical Manager / Workpackage Leaders Workpackage Leaders / Developer Workpackage Leaders / Technical Manager

Table 1: Quality responsibilities

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

5. STANDARDS AND TECHNOLOGIES

This chapter lists the standards and guidelines that the MAXIMUS project partners agreed to follow. Furthermore it names the fundamental technologies the consortium plans to utilize.

Standards
ANSI Standard IEC 61947-1: Electronic Projection Measurement and documentation of key performance criteria Part 1: Fixed Resolution Projectors Barco Project Serial Command Protocol Description Document C++ Language Specification - ISO/IEC 14882:2003 DVi Specifications [3] EC FP7 Documentation Guidance Quality Management Systems -- Requirements - 9001:2000 Software Engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE ISO/IEC 25000:2005 ISO/IEC 13407 Human-Centered Design Processes for Interactive Systems IEEE Guide to Software Requirements Specification, ANSI/IEEE Std 830 Doxygen Guidelines [4] Fraunhofer IGD Software Quality Plan Fraunhofer IGD Software Design Guidelines Fraunhofer IGD C++ Programming Guidelines UML 2.0 Specification [5] XML Standard [6]

Technologies
ACE Framework [7] CUDA [8] OpenIVI OpenSG [9]

Note: All listed documents will be available on the project document server.

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

6. QUALITY ASSURANCE AND QUALITY CONTROL PROCESSES

In this section we describe the approaches we use to realize the quality expectations stated in section 3. The overall approach to quality assurance is the utilization of a user centered approach to requirements analysis and system design as outlined in the ISO norm 13407 [1]. The approach is depicted in Figure 1.

Figure 1: User Centered Design

Starting from an identification of the end users working environment and work flow we derive the user requirements. From the requirements specification we derive a preliminary system design which will be implemented in a first prototype system. This prototype is then evaluated in a user test and the results of the user test are utilized to refine the requirements and improve the prototype until it is accepted by the users. This approach is already formalized in the deliverables of the project which foresees two prototypes and user tests (D19, D23, D27, and D31). The fine-grained quality assurance mechanisms are given below. They are organized with respect to the different types of deliverables and the project management (i.e. according to the structure used to define the quality expectations)

6.1 Quality Assurance for Deliverables

The quality of deliverables is assured by providing templates and guidelines that demonstrate the expected quality aspects to the individuals working on different parts of the project.
8

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

6.1.1 Quality Assurance for Documents

To achieve a common look of deliverables which are documents we provide Word templates on our document server (see section 10). All documents that will be sent to the EC or released to the public will be generated using these templates. We also provide a PowerPoint template which will be used to prepare MAXIMUS presentations.

6.1.2 Quality Assurance for Software Components

The compliance of software components with the user requirements is assured by the aforementioned user centered design approach. To realize software which is extensible and reusable our software requirements specification will be guided by the IEEE 830 standard and we will take special care to define clear and unambiguous interfaces between the different software modules (rendering and interaction). The internal organization of the modules will be supported by using UML to properly separate the relevant concepts. Adequate documentation will be generated by enforcing the use of Doxygen for automated creation of developer documentation. Additionally we provide a C++ style guide to harmonize the code layout. Stability issues will be addressed by the implementation of unit testing which will result in early recognition of errors which may be introduced during the development process, especially if new functionality is added.

6.1.3 Quality Assurance for Hardware Components

The quality assurance for hardware components or prototypes in this project will be done by setting up a checklist against the requirements before providing the prototypes to other partners in the project. For a projector prototype this checklist will include optical checks like lumen output and contrast ratio, but also electronical tests (compatibility with the required signal) and Communications protocol tests (are the new commands for new features foreseen?). It is therefore important to agree on a requirement specification sheet specifically for the hardware prototypes early in the project.

6.1.4 Quality Assurance for Integrated MAXIMUS System Prototypes

For the integrated MAXIMUS prototype systems we assure the conformance to the user requirements by the user tests, which will be performed to evaluate the system. To minimize the integration effort at the software level we will share the code basis between the developing parties (INESC-ID and Fraunhofer). A source control system (Subversion) will be installed to support the collaborative development activities. Adequate end user documentation will be generated and kept up to date by integrating it with the source code documentation (related pages/tutorials in Doxygen).

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

6.2 Quality Assurance for Project Management

The project coordinator Fraunhofer-IGD is an ISO 9001 certified organization. It has a Quality Management System, which includes guidelines that describe the order of actions to be performed when executing the organization processes together with rules that are applied to assure the quality of the process outcome. One of these processes is the FhG-IGD Project which provides guidelines and imposes rules on how to execute and document a project. This process is applied to the MAXIMUS project and will assure that the quality expectations regarding project management will be met. Transparency of the management decisions and actions will be achieved by adequate communication of these issues on project meetings.

6.3 Quality Control of Deliverables

The quality control will be mainly implemented through a review procedure where reviewers have to approve draft versions of the deliverable under consideration.

6.3.1 Quality Control of Documents

Documents have a work package leader assigned who is responsible for producing a draft version of the document. As already stated in the Consortium Operating Procedures (D1) this draft version will be distributed to the reviewers (other WP leaders, Technical Manager and Project Manager). The reviewers will send corrections and comments to the responsible partner within 10 working days who in turn will produce the final version of the document within the following 10 working days. This means, all draft versions have to be completed 20 working days prior to the estimated deadline.

6.3.2 Quality Control of Software Components

As with documents the quality control of software is based on reviews. This includes internal code reviews at the developing partner institution as well as reviews by other developing partners at technical meetings. To verify the functionality of the software we plan to utilize unit testing, i.e. we will generate test classes, which demonstrate the features of modules. These test classes will be part of the shared source code of the developing partners (INESC-ID and Fraunhofer) and will be part of each build of the software which will allow for early identification of bugs or inconsistencies that will arise during the development process.

6.3.3 Quality Control of Hardware Components

Quality control for hardware components will in the case of projector prototypes be managed by starting as much as possible from existing projector platforms, that have an established and tracked Bill Of Material (BOM), and by keeping a description of the

10

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

modifications performed to obtain the prototypes. The projector prototypes will undergo a basic hardware and firmware validation test procedure, in line with the developed checklist, before they will be provided to other partners in the project.

6.3.4 Quality Control of Integrated MAXIMUS System Prototypes

The main approach to quality control of the integrated system prototypes will be user testing. User tests will be conducted where representatives of the end users will be asked to perform a set of tasks in the evaluation scenarios we will define to assess the functionality of the integrated system. The results of the user tests will be used to identify problems in the functionality and usability of the system which will lead to refined user requirements that will guide the development of the next system prototype.

6.4 Quality Control of Project Management

The control of project management issues will be implemented through internal audits at the project manager (Fraunhofer) where the documentation and project progress will be assessed. The results of these audits will be documented in internal reports which will be added to the project documentation. The project management will keep track of a list of project disseminations. This includes sharing the dissemination if this is allowed and possible, and sharing a report to all project members on the conference or other event where the dissemination took place.

6.5 List of Quality Control Actions

Table 2 lists the quality control actions we will perform for each deliverable of the project.
Del. no. D1 D2 D3 D4 Deliverable name Consortium operating procedures Project website Project quality plan Use case and system design document 1st interaction prototype D5 1st hybrid rendering prototype 1st progress and assessment report on interaction techniques 1st progress and assessment report on hybrid rendering techniques 1st progress and assessment report on the HDR sensor Control Process Review by WP-Leaders. Conformity checking to documentation standards. Conformity testing to common web standards. Review by WP-Leaders. Conformity checking to documentation standards. Conformity checking to original project objectives. Review by WP-Leaders. Standard Evaluation and Usability testing. Conformity testing of prototype to original specifications. Conformity testing of prototype to original specifications. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards.

D6 D7 D8 D9

11

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

Del. no. D10 D11 D12 D13 D14 D15 D16

Deliverable name 1st progress and assessment report on HDR and extended color gamut display technologies 1st progress and assessment report on integration 1st report on the dissemination and exploitation plan 1st prototype of the 32bit-HDR sensor Prototype of HDR material scanner using the 32bit HDR-sensor Delivery of material samples Demonstration of a projector prototype with improved dynamic range adapted to the image content 1st integrated MAXIMUS prototype system

Control Process Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Conformity testing of prototype to original specifications. Conformity testing of prototype to original specifications Conformity testing to specified standards. Standard Evaluation and Usability testing. Conformity testing of prototype to original specifications. Standard Evaluation and Usability testing. Conformity testing of prototype to original specifications. Design and program inspections. Unit testing. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Standard Evaluation and Usability testing.

D17

D18 D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31

Manual and report on the 1st integrated MAXIMUS prototype system Evaluation plan for the 1st integrated MAXIMUS prototype system Demonstration of a projector prototype with improved color gamut

2nd progress and assessment report on interaction techniques 2nd progress and assessment report on hybrid rendering techniques Progress and assessment report on the HDR sensor and the integration into a material scanner and a spherical camera 2nd progress and assessment report on HDR and extended color gamut display technologies 2nd progress and assessment report on integration Evaluation report on the 1st integrated MAXIMUS prototype system 2nd report on the dissemination and exploitation plan Delivery of light field samples Demonstration of a high-resolution active stereo projector prototype

Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Conformity testing to specified standards. Standard Evaluation and Usability testing. Conformity testing of prototype to specifications. Conformity testing of system to specifications. Standard Evaluation and Usability testing. Conformity testing of prototype to specifications. Standard Evaluation and Usability testing. Conformity testing of prototype to specifications. Standard Evaluation and Usability testing. Conformity testing of prototype to specifications. Review by WP-Leaders. Conformity checking to documentation standards.

Final 32bit HDR sensor Final interaction prototype

Final hybrid rendering prototype D32 Final integrated MAXIMUS prototype system - ready for final evaluation D33 Manual and report on the final integrated MAXIMUS prototype system

D34

12

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

Del. no. D35 D36 D37 D38 D39 D40 D41 D42 D43 D44

Deliverable name Evaluation plan for the final integrated MAXIMUS prototype system Report on the final HDR sensor Report on the final interaction prototype Report on final hybrid rendering prototype Final report on HDR and extended color gamut display technologies Report on the integration of the final MAXIMUS prototype system Evaluation report on the final integrated MAXIMUS prototype system Final report on the dissemination activities Final exploitation plan Final report

Control Process Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards. Review by WP-Leaders. Conformity checking to documentation standards.

Table 2: Quality control actions per deliverable

13

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

7. CHANGE CONTROL AND CONFIGURATION MANAGEMENT PROCESSES

7.1 Change Control
During the development of the MAXIMUS system, it might be necessary to deal with changes in the user requirements as well as with changes in the technology used to realize these requirements. This section describes our approach to handle these kinds of changes as well as the methods we will use to organize the resulting software configurations.

7.1.1 Change Control for User Requirements

We will be careful to identify adequate user requirements at the beginning of the MAXIMUS project which will be formalized in the Use Case and System Design document (D4). However, experience has shown that changes to these initial user requirements are likely to show up during user tests of the first system prototype. If changes to the basic functionality of the system are requested by the end users we will discuss them during the following project meeting and decide whether this new functionality is in the scope of the project and should be implemented or not. Since the consortium is rather small (seven partners) we expect these discussions to end up with consensus. However, if consensus is not achievable for some reason we have already agreed on a voting structure as defined in the consortium agreement which will then come into effect.

7.1.2 Change Control for Technical Aspects

The developing partners have outlined their approaches to the realization of the technical aspects of the project in the Description of Work. It might be possible that changes of these approaches are necessary, most likely due to new technical developments outside the project. If this situation occurs, a change request will be sent to the Technical Manager who will bilaterally discuss the implication of such a change with the developing partner. If the necessity of a major change in the technical approach to part of the system is agreed, the proposed change will be discussed and approved during the next project meeting. If the requested change is rated as substantial, it will be reported to the Project Officer through the coordinator.

7.2 Configuration Management

The purpose of configuration management is to keep track of the different versions of the system in terms of functionality (keep previous versions operable) and documentation. We will do this by installing a common source code server based on the subver14

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

sion source control system [10]. This source code server will be used by all software developing partners. For the relevant versions of the code, we will create tags (mark the current version of all source code files with a name so that it can be checked out of the repository at a later point in time using this name). The tag name will conform to the following naming convention: MAXIMUS_prototype_yyyymmdd where yyyymmdd is the date when the tag was created, (the format is four digits year, two digits month and two digits day). To keep track of different versions of deliverables, which are documents, we also apply a naming convention as stated in the Consortium Operating Procedures (D1): DX_Name_of_the_deliverable_yyyymmdd.doc with DX as the number of the deliverable, followed by the name of the deliverable with white spaces substituted by underscores and a date field of the same format we use for tags of the source code.

15

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

8. RISK MANAGEMENT
The risk management within the MAXIMUS project addresses issues that could endanger achievement of critical objectives. Effective risk management has to consider sources for cost, schedule and performance risks as well as other risks and specify practices to systematically plan, anticipate and mitigate these risks in order to minimize their impact on the project. In this section, we describe the risk management processes to identify and analyze risks and handle them efficiently.

8.1 Risk identification and analysis

As stated in the Description of Work document we determined general risk categories according to the phases of the MAXIMUS project lifecycle. These categories are: Analysis and system design stage Implementation stage Software Quality Assurance Dissemination and exploitation development Project management

Project risks have been identified in the proposal phase based on expert interviewing, the examination of design specifications as well as the experience of consortium partners from former projects and documented appropriately. They have been evaluated, classified in accordance with defined risk parameters and categorized according to the defined categories to facilitate risk handling. Furthermore, mitigation plans for each category have been specified by the partners to avoid occurrence or reduce their potential impact on the project. For a detailed description of identified risks we refer to the Description of Work document [2].

8.2 Risk monitoring and control

The risk status will be reviewed periodically during the consortium meetings to reexamine possible sources of risks, changing specifications and management decisions to uncover risks overlooked or nonexistent in the project planning phase and reassess already identified risks. The work package leaders are responsible for identifying and evaluating new risks and communicating them to the other partners. Risk identification and analysis have to be performed according to the approaches identified during the project planning phase. Depending on the reassigned priority and consequences of each risk, the Project Management Board decides on further risk handling when monitored risks become critical. Risk handling may range from simple acceptance and monitoring in case a risk is

16

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

judged as negligible to development and implementation of risk mitigation plans for risks, which become unacceptable. The responsibility for development and implementation of a mitigation plan as needed to reduce the risk to an acceptable level lies with the associated work package leader. Risk mitigation plans will address the following issues: Development of alternative courses of action Workarounds Fallback positions Schedule or period of performance for each risk handling activity Performance measures on the risk-handling activities Recommended course of action

After a risk mitigation plan is initiated, the risk will still be monitored and the progress of open actions will be tracked to closure. Despite all attempts to mitigate a risk, some risks may be unavoidable and become a problem that affects the project. To deal with a potential impact of risk occurrence extra project meetings will be convened. In these meetings, appropriate response actions will be defined and documented in a contingency plan. The resulting contingency plan will be executed by the responsible project partner and monitored by the Project Management Board.

17

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

9. QUALITY TOOLS
In order to facilitate the project management, system development processes and assure overall quality, all consortium partners will adapt a number of fundamental tools as listed below. In addition each partner may employ other expedient tools in its day-today workflow not specified by this document, but has to ensure that communication and integration processes will not be affected decisively.

9.1 Project Management Quality

Instant Messaging, E-Mail for day-to-day communication OWL Document Repository for document management GanttProject for project scheduling and management Microsoft Office for documentation, budgetary and presentation purposes Macromedia Dreamweaver for development and maintenance of the project website Face-to-Face communication during consortium meetings

9.2 System Quality

Subversion for version management Microsoft .NET Framework for testing .NET related components Enterprise Architect for creating UML diagrams Perl XML Parser for validation of XML documents CppUnit for c++ source code unit testing Microsoft Visual Studio Debugger for debugging purposes Doxygen for code documentation generation Nvidia PerfKit for CUDA related code testing MKS for projector embedded firmware & FPGA version management (currently planning for a migration towards Subversion)

18

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

10. SUPPORTING DOCUMENTS

Document name Word template for deliverables Document Server: /Templates/WordTemplate_20080714.ppt PowerPoint template for presenta- Document Server: tions /Templates/PowerPointTemplate_20080714.ppt Word template for meeting minutes Document Server: /Templates//MinutesTemplate_20080714.ppt Location

19

MAXIMUS FP7-ICT-2007-1-217039

Project Quality Plan

11. REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ISO/IEC 13407 Human-Centered Design Processes for Interactive Systems, ISO/IEC 13407:1999, 1999 MAXIMUS Annex I - Description of Work, Document Server: /Description Of Work/Maximus_Annex1_revised_final.pdf http://www.ddwg.org/lib/dvi_10.pdf http://www.doxygen.org http://www.uml.org http://www.w3.org/XML/ http://www.cse.wustl.edu/~schmidt/ACE.html http://www.nvidia.com/object/cuda_home.html http://www.opensg.org http://subversion.tigris.org/

20