contoh4. project quality plan

7/29/2019 Contoh4. Project Quality Plan

1/22

MAXIMUS FP7-ICT-2007-1-217039 Project Quality Plan

1

MAXIMUS MAXimum fidelity Interactive Multi User

Display Systems

Title: Project Quality Plan

Version: 1.0

Deliverable type: Report Deliverable Number: D3 Workpackage: WP9

Contractual Date of Delivery: 30.06.2008 Actual Date of Delivery: 31.08.2008

Author(s): Daniel Danch,

Thomas Gierlinger

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

Project Quality Plan


2/22


2

TABLE OF CONTENTS

1. EXECUTIVE SUMMARY ......................................................... ........................................................... ..22. INTRODUCTION ........................................................... ........................................................... ............33. QUALITY EXPECTATIONS .................................................... ........................................................... ..4

3.1 QUALITY OF DELIVERABLES................................................................................43.2 QUALITY OF PROJECT MANAGEMENT ..................................................................5

4. QUALITY RESPONSIBILITIES......................................................... ................................................... 65. STANDARDS AND TECHNOLOGIES ........................................................ ......................................... 76. QUALITY ASSURANCE AND QUALITY CONTROL PROCESSES ................................................... 8

6.1 QUALITY ASSURANCE FOR DELIVERABLES...........................................................86.2 QUALITY ASSURANCE FOR PROJECT MANAGEMENT...........................................106.3 QUALITY CONTROL OF DELIVERABLES ..............................................................106.4 QUALITY CONTROL OF PROJECT MANAGEMENT.................................................116.5 LIST OF QUALITY CONTROL ACTIONS ................................................................11

7. CHANGE CONTROL AND CONFIGURATION MANAGEMENT PROCESSES................................147.1 CHANGE CONTROL .......................................................................................... 147.2 CONFIGURATION MANAGEMENT........................................................................ 14

8. RISK MANAGEMENT ................................................... ........................................................... ..........168.1 RISK IDENTIFICATION AND ANALYSIS..................................................................168.2 RISK MONITORING AND CONTROL ...................................................................... 16

9. QUALITY TOOLS...............................................................................................................................189.1 PROJECT MANAGEMENT QUALITY ..................................................................... 189.2 SYSTEM QUALITY.............................................................................................18

10. SUPPORTING DOCUMENTS ....................................................... ................................................. 1911. REFERENCES .......................................................... ........................................................... ..........20


3/22


1

Document Log

Version N Date Comments Authors

0.1 14.07.2008 Initial draft version Daniel Danch,

Thomas Gierlinger

0.2 21.08.2008 Revision including remarks from

Barco

Daniel Danch


4/22


2

1. EXECUTIVE SUMMARY

The Project Quality Plan is the third deliverable (D3) of the MAXIMUS project. It identi-

fies the procedures and activities that the consortium partners define, plan, and exe-cute to assure the quality of the project deliverables and project management. Its pur-

pose is to define the minimum principles, requirements and processes to implement an

effective quality assurance and control program. Compared to the Consortium Operat-

ing 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 de-

scription of the quality expectations, the methods we will use to conform to these ex-

pectations and a list of supporting documents which specify the technical details of the

implementations.


5/22


3

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 as-

sure the implementation of these standards. Our approach to change control (i.e. deal-

ing with changes requested by the end users) is given in section 7 together with a de-

scription of our configuration management process (i.e. the procedure to handle the

evolving prototypes of the MAXIMUS system). Details on our risk management aregiven 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.


6/22


4

3. QUALITY EXPECTATIONS

In this section we list our expectations regarding the quality of the MAXIMUS deliver-

ables (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 inte-

grated 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 eas-

ily attributed to the MAXIMUS project. The common look should also be used for pres-

entations 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 hard-

ware 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


7/22


5

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 com-

pliance 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 mustcomply with the user requirements, be stable and have adequate documentation. Addi-

tionally 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 resolu-

tion of technical and financial issues. Furthermore the communication with the EC must

be without unnecessary delays.


8/22


6

4. QUALITY RESPONSIBILITIES

We identified and categorized important deferred aspects of quality within the MAXI-

MUS project. The responsibilities to monitor the compliance with these aspects areassigned 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 con-

form 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 per-

sons for ensuring and monitoring project quality.

Aspect of Quality Monitored by

General Project Documentation and Reports Project Manager

Code Documentation Developer

User Documentation Workpackage Leaders / Technical Manager

System Design Workpackage Leaders / Technical Manager

Standards Compliance Workpackage Leaders

System Evaluation and Testing Technical Manager / Workpackage Leaders

Usability Quality Workpackage Leaders / Developer

Change Control Workpackage Leaders / Technical Manager

Table 1: Quality responsibilities


9/22


7

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 consortiumplans to utilize.

Standards

- ANSI Standard IEC 61947-1: Electronic Projection Measurement and docu-

mentation 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.


10/22


8

6. QUALITY ASSURANCE AND QUALITY CONTROL PROC-

ESSES

In this section we describe the approaches we use to realize the quality expectationsstated 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 prelimi-

nary system design which will be implemented in a first prototype system. This proto-

type 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 ap-

proach is already formalized in the deliverables of the project which foresees two proto-

types 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. ac-

cording 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 dem-

onstrate the expected quality aspects to the individuals working on different parts of the

project.


11/22


9

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 pro-

vide 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 be-

tween the different software modules (rendering and interaction). The internal organiza-

tion of the modules will be supported by using UML to properly separate the relevantconcepts. 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 im-

plementation 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 opti-

cal 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. Ade-

quate end user documentation will be generated and kept up to date by integrating it

with the source code documentation (related pages/tutorials in Doxygen).


12/22


10

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 ac-

tions 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 exe-

cute 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. Trans-

parency of the management decisions and actions will be achieved by adequate com-

munication of these issues on project meetings.

6.3 Quality Control of Deliverables

The quality control will be mainly implemented through a review procedure where re-viewers 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 Proce-

dures (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 fea-

tures of modules. These test classes will be part of the shared source code of the de-veloping partners (INESC-ID and Fraunhofer) and will be part of each build of the soft-

ware 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


13/22


11

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 iden-

tify 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 pro-

ject.

Del.

no.Deliverable name Control Process

D1Consortium operating procedures Review by WP-Leaders. Conformity checking

to documentation standards.

D2 Project website Conformity testing to common web standards.

D3Project quality plan Review by WP-Leaders. Conformity checking


D4Use case and system design document Conformity checking to original project objec-

tives. Review by WP-Leaders.

D51st interaction prototype Standard Evaluation and Usability testing.

Conformity testing of prototype to originalspecifications.

D61st hybrid rendering prototype Conformity testing of prototype to original

specifications.

D71st progress and assessment report on interaction techniques Review by WP-Leaders. Conformity checking


D81st progress and assessment report on hybrid rendering techniques Review by WP-Leaders. Conformity checking


D91st progress and assessment report on the HDR sensor Review by WP-Leaders. Conformity checking



14/22


12

Del.


D101st progress and assessment report on HDR and extended color gamutdisplay technologies

Review by WP-Leaders. Conformity checkingto documentation standards.

D111st progress and assessment report on integration Review by WP-Leaders. Conformity checking


D121st report on the dissemination and exploitation plan Review by WP-Leaders. Conformity checking


D131st prototype of the 32bit-HDR sensor Conformity testing of prototype to original

specifications.

D14Prototype of HDR material scanner using the 32bit HDR-sensor Conformity testing of prototype to original

specifications

D15 Delivery of material samples Conformity testing to specified standards.

D16

Demonstration of a projector prototype with improved dynamic rangeadapted to the image content

Standard Evaluation and Usability testing.Conformity testing of prototype to original

specifications.

D17

1st integrated MAXIMUS prototype system Standard Evaluation and Usability testing.Conformity testing of prototype to original

specifications. Design and program inspec-tions. Unit testing.

D18Manual and report on the 1st integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D19Evaluation plan for the 1st integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D20Demonstration of a projector prototype with improved color gamut Standard Evaluation and Usability testing.

D212nd progress and assessment report on interaction techniques Review by WP-Leaders. Conformity checking


D222nd progress and assessment report on hybrid rendering techniques Review by WP-Leaders. Conformity checking


D23 Progress and assessment report on the HDR sensor and the integrationinto a material scanner and a spherical camera


D242nd progress and assessment report on HDR and extended color gamutdisplay technologies


D252nd progress and assessment report on integration Review by WP-Leaders. Conformity checking


D26Evaluation report on the 1st integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D272nd report on the dissemination and exploitation plan Review by WP-Leaders. Conformity checking


D28 Delivery of light field samples Conformity testing to specified standards.

D29

Demonstration of a high-resolution active stereo projector prototype Standard Evaluation and Usability testing.

Conformity testing of prototype to specifica-tions.

D30 Final 32bit HDR sensor Conformity testing of system to specifications.

D31

Final interaction prototype Standard Evaluation and Usability testing.Conformity testing of prototype to specifica-

tions.

D32

Final hybrid rendering prototype Standard Evaluation and Usability testing.Conformity testing of prototype to specifica-

tions.

D33

Final integrated MAXIMUS prototype system - ready for final evaluation Standard Evaluation and Usability testing.Conformity testing of prototype to specifica-

tions.

D34Manual and report on the final integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking



15/22


13

Del.


D35Evaluation plan for the final integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D36Report on the final HDR sensor Review by WP-Leaders. Conformity checking


D37Report on the final interaction prototype Review by WP-Leaders. Conformity checking


D38Report on final hybrid rendering prototype Review by WP-Leaders. Conformity checking


D39Final report on HDR and extended color gamut display technologies Review by WP-Leaders. Conformity checking


D40Report on the integration of the final MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D41Evaluation report on the final integrated MAXIMUS prototype system Review by WP-Leaders. Conformity checking


D42Final report on the dissemination activities Review by WP-Leaders. Conformity checking


D43Final exploitation plan Review by WP-Leaders. Conformity checking


D44Final report Review by WP-Leaders. Conformity checking


Table 2: Quality control actions per deliverable


16/22


14

7. CHANGE CONTROL AND CONFIGURATION MANAGE-

MENT 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 con-

figurations.

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 docu-

ment (D4). However, experience has shown that changes to these initial user require-

ments 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 ef-

fect.

7.1.2 Change Control for Technical Aspects

The developing partners have outlined their approaches to the realization of the techni-

cal 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 Techni-

cal Manager who will bilaterally discuss the implication of such a change with the de-veloping 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 documenta-

tion. We will do this by installing a common source code server based on the subver-


17/22


15

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 fortags of the source code.


18/22


16

8. RISK MANAGEMENT

The risk management within the MAXIMUS project addresses issues that could endan-

ger achievement of critical objectives. Effective risk management has to considersources 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 part-

ners 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 po-

tential 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 reexam-ine 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 Man-

agement 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


19/22


17

judged as negligible to development and implementation of risk mitigation plans for

risks, which become unacceptable. The responsibility for development and implemen-

tation 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 ofopen 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 contin-

gency plan. The resulting contingency plan will be executed by the responsible project

partner and monitored by the Project Management Board.


20/22


18

9. QUALITY TOOLS

In order to facilitate the project management, system development processes and as-

sure overall quality, all consortium partners will adapt a number of fundamental tools aslisted below. In addition each partner may employ other expedient tools in its day-to-

day 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)


21/22


19

10. SUPPORTING DOCUMENTS

Document name Location

Word template for deliverables Document Server:

/Templates/WordTemplate_20080714.ppt

PowerPoint template for presenta-

tions

Document Server:

/Templates/PowerPointTemplate_20080714.ppt

Word template for meeting minutes Document Server:

/Templates//MinutesTemplate_20080714.ppt


22/22


20

11. REFERENCES

[1] ISO/IEC 13407 Human-Centered Design Processes for Interactive Systems,

ISO/IEC 13407:1999, 1999[2] MAXIMUS Annex I - Description of Work, Document Server: /Description Of

Work/Maximus_Annex1_revised_final.pdf

[3] http://www.ddwg.org/lib/dvi_10.pdf

[4] http://www.doxygen.org

[5] http://www.uml.org

[6] http://www.w3.org/XML/

[7] http://www.cse.wustl.edu/~schmidt/ACE.html

[8] http://www.nvidia.com/object/cuda_home.html

[9] http://www.opensg.org

[10] http://subversion.tigris.org/