ip_qualityassplan


	1. Objective
	The aim of the plan is to define the structure of the relationship/responsibilities between the partners, some relevant procedures to be adopted in the management of the project the communication protocols. The base principle of the quality control in the project is that each partner is responsible for the quality of its activities (local quality) and that the Co-ordination Committee is responsible for the co-ordination of the policy and for the global quality of the whole project (global quality). The source of the commitments of each partner in the project is the contract IN31018I signed with the European Commission (that embeds the WORKPLAN of the final report of the IN31018D contract, named the ‘Workplan’). The workplan outlines also the testing and validation activities and criteria that must be intended as a part of the quality assurance procedures.
	2. Structure of the responsibilities and of the relationship between the partners
	2.1. Coordination Committee
	Objective: to provide centralised management and coordination activities, including technical and financial management and reporting to the EC, to guarantee the harmonisation of the activities, the results and their quality and timelines. The Coordination Committee is defined with one representative from each Contractor in order to cooperate with the coordinator for this objective. Each member of the committee is responsible for the provision of cost and administrative information to the committee. The chairman of the committee comes from the project coordinator, ENEA; he is the contact point with EC and its representative and collects and supervises all the official documents that have to be sent to the EC. A person designated by each of the associated contractors is permanently invited to participate in the meetings of the committee. The Coordination Committee supervises that activities follow the defined workplan, verifies that Quality Assurance Procedures are applied, accepts the deliverables and to do this verifies the achievement of the obiectives takes decisions and updates workplans Any change in the workplan, resource allocation or intermediate objective and deliverables must be discussed and approved by this committee. The general meetings, that are meeting of the Coordination Committee, are already scheduled in the Workplan. From the report on the start-up meeting: "3.2.1 the co-ordination committee is defined De Sabbata, ENEA, coordinator Ludwig Fuchs, AlFerano, associated contractor Salvatore Angotti, Cad Modelling, associated contractor Gianpaolo Benatti, COIN, contractor Nancy Falasconi, HITMAN, contractor Denis Martin, Lectra, associated contractor Ana Isabel Correia, Neosis, contractor " Note that recently Mr Redaelli has substituted Ms Falasconi as Hitman’s representative in the project.
	2.2 Workpackage and activity leaders, Workpackage Management Group
	According with the Workplan each workpackage (the WP) has a partner that is responsible for it and each activity has its leader. The person designed by the workpackage leader partner has the responsibility to co-ordinate and harmonise the activities of the WP (according with the partners that are leaders of the activities ) and is the representative of the WP towards the Coordination Committee. The WP leader has the responsibility to prepare (with the contribution of he other participants) the deliverables that the workplan assign to the WP and to assure that they comply with the defined requirements and timing. The Workpackage Management Workgroup is the group of the persons that are responsible of each activity of the WP and co-operate with the WP leader to reach the target of the WP and to harmonise the activities. The group should be informed and involved about any relevant fact/decision regarding the WP.
	2.3 Company contact persons
	They are the people that each company (Contractor or Associated Contractor ) designate as representative in the project and that participate the Coordination Committee; they must prepare the six-monthly cost statements and activity reports of the company and send them to the coordinator.
	3. Procedures
	3.1 Validation of the deliverables
	Any deliverable (document or software) that is required from the workplan should be prepared with responsibility of the leader of the workpackage that owns it and then must follow this validation procedure: the WP leader prepares the last draft version of the deliverable; the workpackage management group evaluates (the test activity is performed according to the WP if required) and approves the deliverable (draft status); if appropriate the integration tests are performed; the deliverable (draft status) is sent to the coordinator that involves the Coordination Committee that evaluates it (and the results of the tests if any) and asks for any comment from all the partners and then approves; the coordinator sends the deliverable (final status) to the EC and make it available to all the WP leader that need it for their work
	3.2 Cost statement and activity reports to EC
	The validation of the six-months reports and cost statements are subjected to this procedure: each company contact person produce the cost statements for its company (using the appropriate template) and send it to the coordinator; each WP leader prepares the report about the activities performed in the period (activities and planned objectives, achieved objectives, encountered obstacles and changes in respect of the planned activities and timing, expected trend of activities for the next period) and send it to the coordinator; the coordinator supervises and suggests changes to harmonise all the documents; if the harmonisation is impossible the Coordination Committee is involved to solve the problem; the coordinator prepares a short document that presents the whole work and discusses it with the Coordination Committee the coordinator sends the documents to the EC; as soon as the coordinator receives the funds from the EC they will be directly transferred to the Contractors and Associated Contractors.
	3.3 Validation of the meeting reports
	After every significant meeting a report is written and sent to all the partners (Contractors and Associated Contractors) to assure that information circulate and everybody has a complete overview of the status of the activities. Note: this scheme uses UML graphic conventions to describe events and synchronisation meeting takes place, a participant (the author) is committed to write the report at the end; the report (draft status) is sent to all the participants by the author; the participants sends their comment to the author; the report is approved and the author sends it to all the partners of the project. During each of the main official meetings the partner that arranges the meeting has the opportunity to show its activities and facilities (laboratories, etc) and to present its own company to the other partners.
	3.4 Document diffusion
	The communications are sent via e-mail (using the Ishtar mailing list or a more appropriate set of addresses if the target are not all the partners). The documents are published on the web site of Ishtar (according with the restrictions due to the intellectual property rights protection); as default all the documents are available to all the partners of the project, restrictions must be explicitly asked.
	4. Communication and document exchange
	Objective: to simplify and to speed up the information exchanges between the partners, assuring that each partner knows all that he needs to know of the other activities and avoiding errors and misunderstandings. The Ishtar web site and the Ishtar mailing list support this objective of the quality assurance plan. Specifically the REPOSITORY of the web sites implements the management of the documents’ file (search, upload, read/write permissions, simplified workflow control, automatic registry numbering)
	4.1 Naming convention for the documents
	The naming convention for the documents is the following:TTWWW-NN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (author).doc TT = type of document WWW = workpackage that delivered it NN = progressive number of the document of specific for that WWW and TT xxxxx= descriptive title author= the company that edited the document (optional) for example: OF011-01 Quality assurance and communications procedures (Enea).doc Means OF= official report 011= task 1.1,project management 01 = first document about OR and task 1.1 Enea= is the author The next official report of the workpackage 1.1 will have the OF011-02 code.

This naming convention is strictly implemented by the REPOSITORY of the WEB site.

Doctype	Typecode	Description
Official report	OF	Official reports to EC and deliverables (final or intermediate)
Management Doc	MG	Documents about project and tasks management (planning, cost statements, agenda,..)
Analysis and Design Doc	AD	Documents containing analysis, requirement, design and any other material necessary before the development
Test Doc	TS	Report or plan of the test activities
Program Doc	PR	Technical documentation, sources, executables…
User Doc	US	User documentation and error and update requests or warnings
Note	NN	Informal notes exchanged between the operators
Document Template	TP	Document template (WinWord 97 or higher)
Multimedia	MM	Image or other multimedia document
Forms	FO	Forms to be filled

Workpackage	Code	Description
WP1.1	011	Project management
WP2.1	021	Selection of technologies
WP2.2	022	Adapting available technologies
WP2.3	023	Customer and market requirements
WP2.4	024	System architecture and design
WP2.5	025	Construction of the prototype to process the order
WP2.6	026	Construction of the prototype for the retailers
WP2.7	027	Functional tests and integration tests
WP3.1	031	Actions and agreement dealing with IPR
WP4.1	041	Training at pilot sites
WP4.2	042	Adaptation at pilot sites (installation and feedbacks)
WP4.3	043	Trial activities and field tests, market feed back
WP5.1	051	Action to promote awareness and diffusion

	4.2 Document formats
	From the report on the start-up meeting: "3.2.3 Common background (protocols and procedures to work together) Documents will be exchanged using these formats: MS Office 97 (WinWord, Excel, PowerPoint), MS Project 98 A specific tool for diagrams and chart is not defined (they will be exchanged through Ms Office documents, PowerPoint). ENEA has sent a template of document (.dot model) for the Ishtar documents and reports. The mailing list to exchange documents is ‘ishtar@bologna.enea.it’ (please, use it!). The Ishtar WEB site is a renewed version of the definition phase web site at spring.bologna.enea.it/ishtar and contains a repository of documents and materials with a simple retrieval/management system. Informal documents between the partners should be sent to the repository, too; furthermore, e-mail ‘CC’ copies to ENEA are welcome; both are useful to facilitate the harmonisation of the activities (except when there is a reason of confidentiality regarding the internal know how of the partners). A common graphic language is proposed for all the diagrams and schemes in the documentation: UML (Unified Modelling Language); materials about it were sent to the partners." The analysis, the design and the documentation of the system, is realised according to methodologies like the Structured Analysis or UML (Unified Modelling Language) for process and software analysis. To draw up technical documentation for internal use, "structured" or "object-oriented" technologies are used. In particular, for documentation regarding modules that will remain a property of the accomplishing partner and will not need a data exchange with modules of other partners, each developer is expected to use its own internal standards. On the contrary, the modules that somehow become "common" among a group of partners, for which data and information exchanges are necessary an "object-oriented" standard methodology will be used. For this kind of documentation, the methodologies are based on the modelling language UML (Unified Modelling Language) through which also the phases of analysis and design of systems making use of software can be documented.
	4.3 Communication tools
	4.3.1 the web site http://spring.bologna.enea.it/ishtar The WEB site is organised with a two level architecture: a public access level, used to present and promote the project and a restricted access level containing documents to be exchanged (up/download) between the partners. The document Repository. The WEB site is the deposit of the official documents of the project and can be looked as a Project library. The WEB site’s document repository assures that any document is read or updated only by the authorised persons and offers tools to manage the life of the document from the first draft version until the last official one. When the documents are uploaded in the repository all the references in the web site pages are updated. Communication rules together with a clear definition of the workflow of information are defined through software procedures to produce documents, formats, rules of distribution for documents containing confidential information: when you upload a document, it must have an author, a name compliant with the naming conventions, and the read/write permissions are specified (by category –for example all partners- or by names –for example ’de sabbata’ or ‘benatti’-); when a document is updated, an e-mail could be sent to all the potential authors (to be implemented) when a document is downloaded to be changed nobody can upload (modify) it again and a warning is sent to the downloaders; the document are classified for type, activities, authors, keywords and WP The Agenda. The Agenda contains information (where, when, who, what, how to contact) about all the meetings involving different partners; each partner can add directly via Internet the future meetings and can retrieve both the future ones and the meeting that already took place. 4.3.2 The mailing list e-mail:Ishtar@bologna.enea.it The mailing list contains all the peoples that works on the project; a restricted version (coordination committee only) could be evaluated in the next future. Rules to use the mailing list: all the documents that are not strictly ASCII files should be attached the attached documents should be in one of the allowed format and compressed with a .zip tool.
	5. Standards in System design and development
	ISHTAR addresses the issue of portability of the software, for example using as possible programming languages C++ or JAVA, Applets or Javabeans, SQL and ODBC with the aim to reduce constraints, deriving from the dependencies to a specific Hw-Sw configuration, as soon as possible. For the same reason, worldwide accepted communication protocols like TCP-IP (Internet) in the connections between client and server, HTTP (World-Wide-Web) to exchange multimedia documents and HTML/ XML to build documents will be used.
	6. Available document templates and forms
	TP011-01 IshtarIDocTemplate.dot, it is a WinWord template for any document, the header should be completed with the author, revision and type of document information. The header already contains the macro for file name, last update and printing date. FO011-01CostStatementForms.doc, guideline and forms sent by the DGXIII to help us to write the periodical cost statements. These files are available on server1.pisa.enea.it/Ishtar/files/Forms.