 |
Software Best Practice (ESSI) |
| |
Software Best Practice (ESSI) |
ONE-STEP Evaluation
"Supporting the growth and the spread of the Information Society"
May 1997
This is a guide to the following Software Best Practice (ESSI) tasks:
Proposers who are new to Esprit are advised to refer first to the Introduction for Proposers and the Work Programme of Esprit.
All documents are available on request at the Esprit Information Desk:
Tel: +32 2 296.85.96 Fax: +32 2 296.83.88 E-mail: Esprit@dg3.cec.be
or from the Web
In order to obtain further information on ESPRIT or ESSI, please refer to section 5 of this document
All proposers are asked to help us with the planning of the evaluation by sending in the Expression of Interest, using the fax reply form of section 6.3, as soon as possible.
In addition, all readers of this Specific Information Document are encouraged to send us their views on the appropriateness, clarity and overall quality of this document, using the fax reply form of section 6.4.
Enterprises in all developed sectors of the economy — and not just the IT sector — are increasingly dependent on quality software-based IT systems. Such systems support management, production, and service functions in diverse organisations. Furthermore, the products and services now offered by the non-IT sectors, e.g., the automotive industry or the consumer electronics industry, increasingly contain a component of sophisticated software. For example, televisions require in excess of half a Mbyte of software code to provide the wide variety of functions we have come to expect from a domestic appliance. Similarly, the planning and execution of a cutting pattern in the garment industry is accomplished under software control, as are many safety-critical functions in the control of, e.g., aeroplanes, elevators, trains, and electricity generating plants. Today, approximately 70% of all software developed in Europe is developed in the non-IT sectors of the economy. This makes software a technological topic of considerable significance. As the information age develops, software will become even more pervasive and transparent. Consequently, the ability to produce software efficiently, effectively, and with consistently high quality will become increasingly important for all industries across Europe if they are to maintain and enhance their competitiveness.
The goal of the European Systems and Software Initiative (ESSI) is to promote improvements in the software development process in industry, through the take-up of well-founded and established — but insufficiently deployed — methods and technologies, so as to achieve greater efficiency, higher quality, and greater economy. In short, the adoption of Software Best Practice.
| The aim of the initiative is to ensure that European software developers in both user and vendor organisations continue to have the world class skills, the associated technology, and the improved practices necessary to build the increasingly complex and varied systems demanded by the market-place. The full impact of the initiative for Europe will be achieved through a multiplier effect, with the dissemination of results across national borders and across industrial sectors. |  |
To achieve the above objectives, actions are supported to:
| Any organisation in any sector of the economy which regards generation of software to be part of its operation may benefit from the adoption of Software Best Practice. Such a user organisation is often not necessarily classified as being in the software industry, but may well be an engineering or commercial organisation in which the generation of software has emerged as a significant component of its operation. Indeed as the majority of software is produced by organisations in the non-IT sector and by small and medium sized enterprises (SMEs), it is these two groups who are likely to benefit the most from this initiative. |  |
In addition to the user organisations participating directly in the initiative, software vendors and service providers also stand to benefit, as demand for their methodologies, tools and services is stimulated and valuable feedback is given on the strengths and weaknesses of their offerings.
Software Best Practice activities focus on the continuous and stepwise improvement of software development processes and practices. Software process improvement should not be seen as a goal in itself but must be clearly linked to the business goals of an organisation. Software process improvement starts with addressing the organisational issues. Experiences in the past have shown that before any investments are made in true technology upgrades (through products like tools and infrastructure computer support) some critical process issues need to be addressed and solved. They concern how software is actually developed: the methodology and methods, and, especially, the organisation of the process of development and maintenance of software.
Organisational issues are more important than methods and improving methods is, in turn, more important than introducing the techniques and tools to support them.
Finding the right organisational framework, the right process model, the right methodology, the right supporting methods and techniques and the right mix of skills for a development team is a difficult matter and a long-term goal of any process improvement activity. Nevertheless, it is a fundamental requirement for the establishment of a well defined and controlled software development process.
 |
Software development is a people process and due consideration should be given to all the players involved. Process improvement and implementation concerns people and needs to take into account all people related aspects (human factors). These are orthogonal to the technology and methodology driven approaches and are crucial to the success of adopting best practice. |
Successful management of change includes staff motivation, skilling and promotion of the positive contributions that staff can make.
The people aspects cover all the different groups which have an input to the software development process including Management, and Software Engineers.
In order to ensure an appropriate environment for the successful adherence to a total quality approach it is imperative that Senior Management are fully aware of all the issues. Their commitment and involvement are crucial to the successful implementation of the improvement process and it might be necessary to raise their awareness regarding this issue.
It is important to identify clear milestones that will enable the software developer to measure progress along the road of software improvement. Certification through schemes such as ISO 9000, while not an end in itself, can play a valuable role in marking and recognising this progress.
The objectives of Software Best Practice can be accomplished by understanding and applying the state-of-the-art in software engineering, in a wide range of industries and other sectors of the economy, taking into account moving targets and changing cultures in this rapidly evolving area. The full impact for Europe will then be achieved by a multiplier effect, with the dissemination of results across national borders and across industrial sectors.
The definition of best practice at the European level has three main advantages. Firstly, there is the matter of scale. Operating on a European-wide basis offers the possibility to harness the full range of software development experience that has been built up across the full spectrum of industry sectors in addition to offering exposure to the widest selection of specialist method and tool vendors. In the second place, it maximises the possibility to reduce duplication of effort. Finally, it offers the best possibility to reduce the present fragmentation of approaches and, at the same time, to provide a more coherent and homogeneous market for well-founded methods and tools.
Moreover, as we move towards the Information Society, we need to develop and build the technologies necessary to create the Information Infrastructure (such as is envisaged in the Commission White Paper on 'Growth, Competitiveness and Employment'); a dynamic infrastructure of underlying technologies and services to facilitate fast and efficient access to information, according to continually changing requirements. Within this context, software is seen as a major enabling technology and the way in which we develop software is becoming a key factor for industrial competitiveness and prosperity.
All of the above factors can be enhanced through the creation and use of standards, including de-facto standards for 'best practice' and, indeed, standards are vital in the long term. However, the proposed actions should not, at this stage of evolving standards, be restricted to one particular standard. Furthermore, the actions cannot wait for a full and accepted set to be established before being able to implement improvement. Nevertheless, a close look at the ISO-SPICE initiative and active contribution to it is suggested.
Following the revision of the ESPRIT Work programme in 1997, this remaining call for Software Best Practice in the Fourth Framework Programme includes three types of project:
 |
|
The two new ESSI tasks - 1.36 ESPINODEs and 1.37 ESBNETs - aim to continue and build upon the achievements of the initiative so far, but on a more regional basis. ESPINODEs aim with first priority to provide additional support to PIEs, whilst ESBNETs aim to integrate small-scale software best practice actions of different type implemented on a regional basis - with an emphasis on the non-PIE community.
By operating on a regional level, it is expected that ESPINODEs and ESBNETs will be able to tailor their actions to the local culture, delivering the message and operating in the most appropriate way for the region. Further, it is expected that such regional actions will be able to penetrate much more into the very corners of Europe, reaching a target audience which is much broader and probably less experienced in dealing with European initiatives. Such an approach should be of particular interest to SMEs and other organisations not in the traditional IT sector, for which it is perhaps difficult to deal directly with an organisation based in a different country, due to - for example - a lack of resources, cultural and language reasons.
As a result of previous ESSI calls - for the pilot phase in 1993 and then in 1995 and 1996 - ESSI has established a considerable portfolio of nearly 350 projects. This portfolio includes five types of project(1):
|
 |
Feedback from industry on ESSI has been particularly valuable and proposers may find the following summary of their key observations to be useful when preparing proposals:
Perhaps one of the strongest features of the previous ESSI calls was the manner in which the benefits individual organisations obtained were multiplied across the Community. This was accomplished both by the Dissemination Actions and by the creation of communities of interest. It is intended that this aspect will be developed further in the present call, through the ESPINODEs and ESBNETs.
The ESSI Dissemination Actions (DAs), and in particular the project 24119 VASIE II, are establishing a Software Best Practice Library of dissemination material. VASIE provides on-line access to Software Best Practice information properly packaged according to the needs of different audiences.
The library is "virtually" centralised and supported on paper, electronic media, multimedia and hyperlink pointers. DAs and other actions are populating it with their dissemination material and a Dissemination Board ensures co-ordination and high quality standards.
For example, it includes: experiences from PIEs, world-wide information, hyperlinks to relevant sources, calendar of events, news, new material available, material produced by ESSI actions, information about ESSI, press releases, etc.
For further information, including the Final Reports from completed ESSI projects, please refer to the VASIE world-wide web server: project 24119 VASIE II
The purpose of the questionnaire which accompanies this Information Document (i.e. the 'Software Best Practice Questionnaire') is to collect information on the maturity(2) of European industry with regard to software development. The questionnaire will provide a snapshot of the situation and the results will be analysed at the European level to provide an overall picture for Europe.
It should be stressed that the information in the questionnaire will be treated in the strictest of confidence. Whilst a completed questionnaire is mandatory for all proposers of task 1.28 (Process Improvement Experiments),the contents of the questionnaire will be stored and processed anonymously and will not influence the proposal evaluation in any way.
All organisations involved in software development -whether or not they are proposers- are encouraged to complete the questionnaire and to send it to the address given in Chapter 4.
Process Improvement Experiments (PIEs) form the bulk of the Software Best Practice initiative. Their aim is to demonstrate the benefits of improving the software development process through user experimentation. The results will be disseminated both internally within the user organisations to improve software production and externally to the wider community to stimulate adoption of process improvement at a European level.
The emphasis is on continuous improvement through small, stepped actions. During a PIE, a user organisation undertakes one process improvement step, as a controlled, limited experiment, based on an underlying baseline project. The baseline project is a typical software project undertaken by the user organisation as part of its normal business and the results of the experiment should therefore be replicable.
| The introduction of a Configuration Management System, improvements to the documentation system, the application of new project management methods and techniques, the use of a Computer Aided Software Engineering (CASE) tool, the application of Object Oriented methods and techniques, the introduction of a library for software re-use, the use of new testing methods and tools, the introduction of metrics, improvement of quality assurance, etc. are some examples of possible improvement steps for Software Best Practice, and each single example may serve as the focus of a PIE. |  |
Conversely, an application development, a business process improvement or a tool redevelopment cannot be considered as valid activities for a PIE.
It is expected that a PIE will be carried out as part of a larger movement within the user organisation towards process improvement. Proposers are expected to have already considered their strengths and weaknesses, and have at least an idea of the general actions and improvement steps required. They will also need to demonstrate that they are aware of quality issues and are considering the organisational and people aspects of their actions.
Dissemination of the results of the experiment, from a software engineering and business point of view, to the wider community, will be an essential aspect of a PIE and may be undertaken with the support of the Software Best Practice Dissemination Actions already in place.
Any single organisation in any industrial/economical sector which regards generation of software to be part of its operation may propose a PIE (see section 2.1). Such a user organisation is often not necessarily classified as being in the software industry, but may well be an engineering or commercial organisation in which software has emerged as a significant component of its operation. As the majority of software is produced by organisations in the non-IT sector and by small and medium sized enterprises (SMEs), it is these two groups who are likely to benefit the most from this initiative.
In addition to the user organisations participating directly in the PIE, software vendors and service providers also stand to benefit from the experiments, as demand for their methodologies, tools and services is stimulated and valuable feedback is given on the strengths and weaknesses of their offerings.
In undertaking a PIE, the user organisation will be agreeing to carry out the following:
There are a few differences with respect to the previous calls for PIE proposals of 1995 and 1996. The major ones are listed here below, but you are anyway advised to read carefully this whole document:
Further information on participation, financial and contractual arrangements is given in section 2.
Since the pilot phase of ESSI in 1993, a considerable number of Process Improvement Experiments (PIEs) have been supported by the Commission through ESSI. Indeed at the time of this call, some 200 PIEs are running and a further 100 have completed their work.
To-date most of these PIEs have executed their software process activities. Feedback received from the organisations involved(3) reflects a strong desire to exchange information and experience on a more regular basis than in the past. What is important for the PIEs is access to directly usable and practical information; not theoretical solutions in books and papers. Furthermore, the PIEs would benefit from additional, just-in-time support to help them in their day to day project business - support which is relevant to specific topics of their experiment (technical, organisational or administrative). Unfortunately, due to lack of information and/or resources, they often do not know where to get such support and expertise. Indeed, feedback from the PIEs indicates that no easy, appropriate and cost effective mechanisms are available, at present, for facilitating information and experience exchange - mechanisms that they would like to see available locally, in the region where they are located.
On the other hand, a lot of relevant expertise, practical information and know-how on software best practice related matters is available across Europe - including know-how and experience built-up within the PIE community itself. Although the ESSI Dissemination Actions are going a long way to making this information more generally available, what are still missing are appropriate and effective links between the PIEs, and between the PIEs and organisations having the know-how and competencies to support them on a day to day basis. Currently, the community of PIEs is missing experience exchange facilitators, know-how transfer agents as well as information brokers - on a regional level. Clearly more could be done to transfer know-how between PIEs, and between PIEs and other organisations. And it is exactly this gap that ESPINODEs will fill.
| It is in the above context that the primary objective of an ESPINODE is to provide support and assistance, on a regional basis, to a set of PIEs in order to stimulate, support, and co-ordinate activities. ESPINODEs act closely with local industry and are particularly aimed at helping to facilitate exchange of practical information and experience between PIEs, to provide project assistance, technical and administrative support, and to exploit synergies. |  |
On a regional level, an ESPINODE will provide a useful interface between the PIEs themselves, and between the PIEs and local industry. This includes improving and facilitating access to information on ESSI/PIE results, and raising interest and awareness of local companies (notably SMEs) to the technical and business benefits resulting from software process improvement conducted in the PIEs.
At the European level, an ESPINODE will exchange information and experience with other ESPINODEs, in order to benefit from the transfer of technology, skills and know-how; from economies of scale and from synergies in general - thus creating a European network of PIE communities.
The primary target audience of an ESPINODE will be the PIEs in its region, local industry, and the wider European ESSI community (i.e. other ESPINODEs, the ESBNETs, Dissemination Actions and Training Actions).
The region does not have to be restricted to a particular country, but could cut across national borders to bring together populations of similar language, culture and business needs.
As regards the specific needs of the PIEs are concerned, an industrial consultation was performed by the Commission, and the results of this consultation are available in a public report, via the ESSI home page of the CORDIS world-wide web: /esprit/src/stessi.htm, or alternatively by sending an email request to essi@dg3.cec.be, quoting your return email address.
As regards the needs and requirements of local industry, it is a prerequisite for an ESPINODE that it demonstrates a good understanding of local industry with regard to software developing organisations in its region.
To achieve its objectives, the primary role of an ESPINODE will be that of an information broker and co-ordinator - servicing the needs of the PIEs, in relation to local industry, in a pro-active and efficient way. The ESPINODEs must add value to the work of the PIEs, supporting them and helping them as required, and must not add burden or bureaucracy.
As well as the already ongoing or completed PIEs within the region - which will act as good sources of experience and information - there will be the new PIEs resulting from this call (refer to section 1.2). These are the PIEs which will be attached to the ESPINODEs (at least 5 initially) and their specific needs should be the prevailing factor in the choice of activities undertaken. Overall the ESPINODEs will have responsibilities towards several distinct groups: PIEs ongoing or completed but not attached to the ESPINODE; new PIEs attached to the ESPINODE; local industry; and other ESPINODEs and the wider ESSI community. The responsibilities to each of these groups will now be considered.
The regional PIE community (attached and unattached PIEs)
The supporter task of an ESPINODE for the PIEs is manifold and requires a number of complementary activities and mechanisms which must aim at:
For the attached PIEs
The attached PIEs will be provided with additional support:
For the region and its local industry as a whole
The ESPINODE will act as competence centre, information broker and know-how transfer agent for local industry:
Other ESPINODEs and the wider ESSI community
ESPINODEs will co-operate with each other:
Who can participate?
An ESPINODE will be a single organisation which operates under the control of the Commission on a regional level, and establishes a close working relationship with other ESPINODEs on a European level (refer to section 2.1).
Any organisation capable of reaching and addressing the target audience, and having the following competencies and background may participate: the organisation has technical and business expertise on software process improvement and software best practice related issues, has established project management and co-ordination skills, has established information brokerage and know-how transfer skills, and has a good understanding of relevant local industry needs.
Further information on participation, financial and contractual arrangements is given in section 2.
As quoted in the green paper on innovation(4): "the local or regional level is in fact the best level for contacting enterprises and providing them with the necessary support for the external skills they need. At community level, actions should be launched to facilitate the dissemination of good practices, especially by strengthening inter-regional co-operation networks". Regional actions, serving local needs in a tailored and appropriate way, combined with co-operation at a European level, can improve the competitiveness of the European industry.
It is within this context that the objective of an ESBNET is to implement small scale software best practice related activities on a regional basis, but within the context of a European network(5). By operating on a regional level, it is expected that the specific needs of a targeted audience will be better addressed. The regional level will be complemented by actions at European level, to exploit synergies and bring cross-fertilisation between participants and their target audiences.
The proposed network is expected to have a well defined focus, rather than being just a framework for conducting a set of unrelated, regional software best practice activities. This focus, which will define the identity of the network, should be the driving force for undertaking any activity. For example, a network may consider focusing on a particular common problem encountered by the selected target audiences or it could consider focusing on a particular business and/or technical theme.
It has been recognised in several surveys conducted at the European level, that the benefits of software best practice are still not well understood by many software developing organisations. An ESBNET, therefore, should be seen as an enabler to remove the barriers which prevent the adoption of Software Best Practice and to stimulate its adoption. It is expected that the regional dimension of the ESBNETs will allow information on software best practice to penetrate to the very corners of Europe, and in particular the non PIE community. Attention should be paid to:
It is essential that ESBNET proposers identify each of the individual regional audiences for which software best practice support is envisaged. Clearly, commonalities between the different targeted regional audiences should exist and should be compatible with the main focus of the network.
An ESBNET will result in activities that will be performed at two levels:
In making software best practice material available across regional borders, the ESBNET will facilitate an effective transfer of knowledge and practice between the regions and will achieve significant economies of scale - ultimately aiming at reducing the fragmentation of the European software industry.
Typically, ESBNET activities, could be an integrated set of the following example activities:
This list is not exhaustive and the ESBNET should provide the mechanisms for implementing software best practice activities which are most relevant to the specific local needs and the focus of the network.
Any group of organisations, based in at least two participating countries, may submit a proposal for an ESBNET (see section 2.1). Such organisations, however, must demonstrate their established skills and ability to deliver actions similar to those proposed. In particular proposers should demonstrate their knowledge in software best practice, in particular relating to the proposed focus of the ESBNET, and their understanding of the needs of the selected target audience(s).
It is expected that the network (ie the organisations active in the project, the supporting infrastructure and working practices, etc) is already in place or is in a position to be established quickly at the start of the project.
Priority will be given to ESBNET proposals which can clearly demonstrate that their activities will act as a catalyst for further actions continuing beyond the life of the proposed project.
Further information on participation, financial and contractual arrangements is given in section 2.
PIE (task 1.28) and ESPINODE (task 1.36) proposals must be from a single organisation only. They do not need to contain organisations from more than one country, as the European added value of the proposal is ensured by the guarantee to be given by the organisations that their experiences will be transferable to other organisations throughout Europe (in the case of PIEs) or that they will co-operate with the other ESSI participants at a European level as part of their implementation (in the case of ESPINODEs).
ESBNET proposals (task 1.37) must contain, as a minimum, at least two non-affiliated participants from different EU member states, or from one EU member state and one state associated and financially contributing to the Programme.
The programme is open to all legal entities - i.e. people and organisations - established in the Member States of the European Union (industrial firms both large and small enterprises aimed at bringing products and services to the market - universities, higher education institutes, research organisations, etc.), and to the Joint Research Centre of the EC.
Participation in this programme, with financial contribution from the EU, is open to any legal entity established and carrying out RTD activities in a third country associated with and contributing financially to the implementation of this Programme.
These are currently: Iceland, Israel, Liechtenstein and Norway.
Legal entities established and carrying out RTD activities in other European countries or in countries who have concluded an S&T; agreement with the EU (not financially contributing as described above) may participate in the programme on condition that:
These states are at printing date: Albania, Armenia, Azerbaijan, Belarus, Bulgaria, Cyprus, Czech Republic, Estonia, Georgia, Hungary, Latvia, Lithuania, Malta, Moldavia, Poland, Romania, Russia, Slovakia, Slovenia, Turkey and Ukraine, for which financial support by the EU, would in the case of acceptance of the proposal, normally be provided from funds other than the ESPRIT budget (an explicit request for such funding has to accompany the proposal).
Swiss, Australian and Canadian organisations may participate under the above conditions, but without funding from the EC. It is expected that agreement with South Africa will be reached in early 1997, so that organisations from South Africa may from then on also participate under the above conditions without EC funding.
Legal entities established in states other than above listed, may participate on condition that:
Organisations from Japan, Korea, New Zealand, Taiwan and the USA are not eligible for funding from the EU.
For organisations from other countries, financial support by the EU may be provided from funds other than the ESPRIT budget. An explicit request for such funding has to accompany the proposal.
International Organisations may participate on condition that:
Financial support from the Esprit Programme may be provided to international organisations situated in Europe on a case by case basis. An explicit request for such funding has to accompany the proposal.
If your proposal is successful in the evaluation and is selected for further negotiation, the Commission services will contact you for finalisation of the Project Programme(6) and budgetary aspects.
The Project Officer assigned to be the responsible Commission official will provide you with the necessary documentation. The time needed in this phase depends on the complexity and evaluators' comments, but normally negotiations would take between 4 and 8 weeks if the work is well planned.
Every proposal must have an organisation which will take responsibility for co-ordinating the project, should it be selected for support, and for liaison with the Commission - the co-ordinator (see section 4). In the case of PIEs and ESPINODEs, involving only one organisation, then this organisation is the co-ordinator.
ESSI proposer(s) may wish to engage professional support from outside contractors - known as subcontractors. In this case, the proposer(s) would need to justify and define the scope of the work to be carried out by the subcontractor and respect the guidelines given in section 2.2.2.
Specific Contractual Arrangement for PIEs
For PIEs, the Commission will have a single contract with the co-ordinator (ie proposer). Nevertheless, to stimulate and establish co-operation and exchange of experience among different organisations, the Commission will group successful proposers, according to their geographical location, and attach them to their regional ESPINODE (if a suitable one is available).
The duration of a PIE is expected to be no more than 18 months.
Specific Contractual Arrangement for ESPINODEs
For ESPINODEs, the Commission will have a single contract directly with the co-ordinator (ie proposer). The Commission will group successful PIE proposers, according to their geographical location, and attach them to the ESPINODE (as appropriate).
The duration of an ESPINODE is expected to be 24 months.
Specific Contractual Arrangement for ESBNETs
For ESBNETs, the Commission will have a single contract directly with the co-ordinator. All other proposers in the project (ie partners) will have an associated contract with the co-ordinator. These contracts will be the responsibility of the contracting parties and will not involve the Commission(7).
The duration of an ESBNET is expected to be no more than 24 months.
100% of the actual costs associated with the project can be charged under the agreed contract. Costs in this context are defined to be the actual expenditures which a contractor incurs in the execution of the project and which are solely attributable to the execution of the project. It does not include overhead on labour, nor infrastructural costs of the organisation, nor profit. These costs are incurred in addition to the current on-going work in the organisation.
Normally, allowable costs are restricted to justifiable labour costs (e.g. effort associated with technical work, monitoring, supervising, analysis of results, reporting, disseminating, etc.), travel and meeting costs, license fees for software required for the project, and costs associated with the acquisition of expert advice.
Labour cost must only include actual salaries and social charges. Contribution to general company overheads and profits are not allowable.
Hardware costs are excluded from all ESSI projects.
Further Guidance for PIE Proposers
For PIE projects, costs are restricted to those relating to the experiment only (which may include the cost of third-party training). Costs associated with the underlying baseline project, including labour, are not reimbursable and remain the concern of the contractor.
The level of support for an individual PIE must not exceed 300 KECU. In addition, it is suggested that proposers take into account the following recommendations for typical PIE costs, provided as an indication of the priorities associated with the different experiment activities:
|
 |
Clear justification needs to be given in cases where cost categories exceed the limits indicated above.
It is expected that consultancy costs will be expressed as normal commercial fee rates. Labour costs and other costs between affiliated organisations(8) are expected not to exceed internal rates.
Further Guidance for ESPINODE Proposers
100% of the actual expenditure that the proposer incurs in implementing the ESPINODE activities are chargeable. These costs must be solely attributable to the ESPINODE and in addition to the normal business of the proposer.
The level of financial support for an individual ESPINODE is expected not to exceed 150 KECU for a duration of 24 months (covering monitoring, co-ordination and support for up to 5 attached PIEs, which will start their work and finish within this period).
At least 10% of an ESPINODE's budget must be reserved for co-operation with other ESPINODEs.
Should the Commission wish to attach more than 5 PIEs to one ESPINODE, then an extra 10 KECU per additional PIE may be taken as a reasonable additional budget.
For the planning of resources, it is important to note that co-ordination and monitoring of a group of attached PIEs will be conducted in close liaison with the Commission, and that selected ESPINODEs are expected to support the Commission in reviewing the mandatory deliverables of these PIEs(9).
As regards the project specific assistance for the attached PIEs, the requested financial support (basic funding) of an ESPINODE is expected to include some 50 hours effort for technical helpdesk/hands-on services/coaching for each individual PIE attached to the node.
Costs associated with additional project specific technical consultancy or training for a PIE (or indeed any other organisation) are not chargeable to the ESPINODE. Such services, if justified, must be paid for directly by the organisations requesting them (for PIEs this may be an allowable cost, chargeable to their project budget).
The PIEs may select the node, or other third party, as a service provider, according to their requirements. However, in the case where the ESPINODE is contracted to offer additional services (consultancy, training, etc) to the PIEs, then the ESPINODE will need to demonstrate impartiality, supplying - when appropriate - details on similar services offered by other service providers in the region.
An ESPINODE must not subcontract any of its main ESPINODE work to third parties. Subcontracts may be used, however, to provide additional skills and expertise when it can be demonstrated that they are required to serve an established need of the PIEs and are not available within the ESPINODE organisation itself. Such contracts are expected to be at normally commercial rates which, nevertheless, clearly demonstrate value for money.
Allowable costs can include, for example justifiable labour and travel costs for the proposers; costs associated with the acquisition of services, licence fees, purchase of software, purchase of existing software best practice material, use of telecommunication services, cost of postage, printing and publication; rental costs for external meeting rooms or conference rooms.
Further Guidance for ESBNET Proposers
100% of the actual expenditure that the proposers incur in organising the network and implementing the activities are chargeable. These costs must be solely attributable to the network and in addition to the normal business of the proposers.
Allowable costs can include, for example justifiable labour and travel costs for the proposers; costs associated with the acquisition of services, licence fees, purchase of software, purchase of existing software best practice material, use of telecommunication services, cost of postage, printing and publication; rental costs for external meeting rooms or conference rooms.
Service costs could include subcontracting professional experts in software best practice who could assist in meeting the needs of a selected audience for which a particular expertise is needed but not available among the partners.
The ESPRIT programme has procedures for both single and two step proposal submission and evaluation.
The submission and evaluation of the proposals as described in this information package will be done in a single step. Proposers must submit a full proposal before any evaluation takes place.
All proposals are evaluated by a panel of specially selected experts who are all bound by a confidentiality agreement and a code of conduct to avoid conflicts of interest. The evaluation will be exclusively based on the criteria set out in this section and will include assessment of the conformity of the work with the objectives and topics as stated in section 1 of this Specific Information Document. The evaluation will be carried out under the responsibility and co-ordination of the Commission who will also interact with associate Programmes, e.g. Telematics Applications, ACTS, IMT.
It is important to note that if your proposal is eventually selected for funding, there will follow a period of negotiation with the Commission to agree upon the Project Programme(10). The contract itself will be a standard one used by the Commission for all such projects and as such is not negotiable. The Project Programme will be based upon the proposal submitted to the call, modified to address the weaknesses identified during the evaluation. The final maximum budget to be allocated to the project will be confirmed during the negotiation, following close examination of the work to be performed, the allowable costs, the justifiable labour rates and the commercial terms for subcontractors.
In this section we will specify the recommended structure of, and the evaluation criteria which need to be satisfied by, proposals.
A proposal is comprised of two parts :
You may submit proposals in any official language of the EC. However, it is appreciated to supply at least the summary in English as this will assist the speedy evaluation of proposals.
The description of the proposal structure given below, includes the criteria which have to be addressed in each of the sections. Certain criteria might be addressed in several sections. In such cases it is advised to refer in the relevant section to other places in the proposal which should be taken into account for assessment.
The format of Part I of the proposal is the same for all three types of ESSI proposal and is described as follows (with the exception of an additional form giving the characteristics for a PIE).
To complete Part 1 of the proposal you need to complete all the forms as given in Annex 1. You can obtain an electronic version of this Information Document, including these forms, from the Esprit Web pages (see section 5), or by sending an email request to essi@dg3.cec.be - quoting the document name and your return email address.
Please follow carefully the detailed instructions.
A complete Part 1 comprises :
| Form | Title | Maximum length (pages) |
| Part I of Proposal | ||
| 1 | I.1 Proposal Administrative Summary | 1 |
| including the Project Synopsis | 1000 char | |
| 2 | I.2 Individual Participant Profile | 1 * |
| 3 | I.3 Individual Participant Costs | 1 * |
| 4 | I.4 PIE Project Characteristics (PIEs only) | 1 |
* ESBNETs: 1 page for each participant
The duly completed forms 1a, 1b, 2, 3 and 4 (PIEs only) as given in the Annex 6.1.
Form 1a must include the signed declaration of the co-ordinator concerning possible involvement of his organisation in other related or similar proposals in the same or other Calls, in Esprit or other EC programmes.
Form 1a must also contain a short (max. 1,000 characters) project synopsis. This will be used by both programme staff and external evaluators during the evaluation and will be copied on the evaluation reports provided to the Member State Committee. It should state what is covered in the proposed project, its rationale and importance (it may be considered as a précis of what is given in the Project Summary of Part II of the proposal).
Please note that the Commission will not edit or reduce the synopsis in any way. If the synopsis is longer than 1,000 characters, all characters above this will be lost automatically.
Form 1b must present the proposal resource breakdown per partner as well as other administrative information concerning the proposal.
Form 2 must be completed by each participant, including associate partners (ESBNETs only), and present the individual participant profiles.
Form 3 must be completed by each participant, including associate partners (ESBNETs only), and present a breakdown of the anticipated actual costs
Form 4 - to be completed for task 1.28 (PIE) proposals only - must give the characteristics of the Process Improvement Experiment
A written statement of each participating organisation, signed by a representative of the organisation duly empowered to do so, and authorising its participation.
The format of Part 2 (your project description) is specific to the type of proposal and is described in the following sections. In all cases, Part II is free-format text (i.e. there are no forms).
Proposal Structure and Contents
| Form | Title | Maximum length (pages) |
| Part II of Proposal | ||
| Free Format | II.1. Project Summary | 1 |
| Free Format | II.1. Project Objectives | 1 |
| Free Format | II.1. Main Business of Participant and Motivation for PIE | 0.5 |
| Free Format | II.1. Current Status of Software Engineering Practice/ Software Process and Required Corrective Actions | 2 |
| Free Format | II.1. Definition of the Baseline Project | 0.5 |
| Free Format | II.1. Definition of Experiment (in Context of Baseline Project) | 2 |
| Free Format | II.1. Anticipated Benefits and Commercial Impact | 1 |
| Free Format | II.1. Measurement of Results | 1 |
| Free Format | II.1. Transferability of Experience and Dissemination Activities | 1.5 |
| Free Format | II.1. Phased Workplan | 3 + charts |
| Free Format | II.1. Subcontracts and other Cost Clarification | 1 |
| Questionnaire (see Section 1.1) |
II.1. Project Summary - a one page description capturing the essence of the proposal by answering the questions: (i) Why is the proposed work needed? (in terms of motivation, business relevance and needs of target audience), (ii) What does it deliver? (in terms of objectives and expected results); (iii) Who does the work? (the proposer and subcontractors, if any); (iv) How is the work performed? (in terms of strategy and approach). It is expected that this section expands upon the Project synopsis presented in Form 1.a of Part I.
II.2. Project Objectives - gives the objectives of the experiment - from the business and technical point of view - and their relation to the business needs and goals of the proposer.
II.3. Main Business of Participant and Motivation for PIE - a brief description of the proposer's main business and its motivation for the proposed experiment, particularly from the business point of view.
II.4. Current Status of Software Engineering Practice/Software Process and Required Corrective Actions - demonstrates that the proposer has analysed its current practices and has identified corrective actions for process improvement. For larger organisations this may be more specifically the software producing unit that is proposing the PIE.
Proposing organisations will vary in the maturity of their understanding of the software development process. Some may have assessed their current software engineering practices thoroughly(11) and have formulated a plan of the improvements necessary. Other less advanced organisations may just be starting to consider process improvement. In either case, proposers need to demonstrate that they have considered their current practices in terms of weaknesses and strengths, and have at least an idea of the general actions and steps necessary for process improvement.
Although quality assurance may not be the major focus of the experiment, proposers are asked to show that quality is an issue and state what Quality Assurance is for them.
Finally, those organisations which have already participated in an ESSI Application Experiment or in a PIE (either as proposer or associated partner) are expected to explain the results of such participation, how they have been used and how they have affected the overall software development process of the company. In cases where the PIE is still running, they should indicate how the expected results effect the software development process and what influence they will have on the proposed new PIE.
II.1. Definition of Baseline Project - gives a good definition of the baseline project (underlying application). It shows how it fits into the company business strategy, and describes its expected duration and effort.
If it is not possible to define the specific baseline project at this stage, then the detailed criteria that will be used to choose the baseline project should be given in terms of, for example, business area, technical domain, relative size (e.g. in terms of efforts allocated), etc.
II.1. Definition of Experiment in Context of Baseline Project- gives a tight definition of the scope of the experiment (i.e. how to achieve the objectives) and its relation to the baseline project, described in the previous section.
The proposed experiment is expected to clearly relate and contribute to the corrective actions required and to have a well defined focus (rather than being a set of widespread activities). It is expected that the experiment is one step in a company plan for stepwise and continuous improvement.
The uptake of Software Best Practice is not just a technological issue; it often means a considerable change to the skills of the professionals involved and their way of working. Since Software Best Practice also embraces organisational and people issues, proposers are expected to show how these issues will be addressed in the experiment.
II.1. Anticipated Benefits and Commercial Impact - indicates the anticipated benefits of the proposed action and the commercial impact for the proposing organisation, and also the anticipated benefits for the wider community.
The proposer is expected to clearly formulate the specific benefits that it expects to obtain by undertaking the experiment, both from the software engineering and commercial point of view.
As the introduction of new technology is expected to be driven by improvements in current processes, which in turn are driven by the business needs of the organisation involved, proposers are particularly asked to indicate how the proposed experiment and the expected benefits contribute to the overall business goals of their organisation and the likely impact on their business.
Finally, this section should give an outline how the results of the experiment will provide benefits for the wider European community.
II.1. Measurement of Results - includes the measurable goals for the experiment (clearly linked to the overall objectives) and indicates the continuous, specific steps that will be taken to measure the results of the project, judge the success of the completed actions and ensure that the project is on course to achieve the objectives given in section II.2 and realise the benefits indicated in section II.7. This may be achieved, for example, by introducing metrics in the experiment, together with activities for the collection and evaluation of the resulting data.
Given that the real benefits from process improvement may only become apparent 6 to 12 months after the completion of the experiment, proposers should indicate the measures that will be taken to assess the benefits in the longer term.
In general it is suggested that an evaluation of performance and a cost/benefit analysis should be considered as necessary on-going activities, in order to make a final evaluation of the PIE results.
II.1. Transferability of Experience and Dissemination Activities - as the transferability of experience is a cornerstone of Software Best Practice, PIE proposals are expected to demonstrate that the experiment being undertaken can later be replicated throughout the organisations involved and within the wider European community. In particular, proposers should describe how the results achieved and lessons learnt from the experiment (including key competencies acquired, deficiencies removed, lasting changes) will be used internally within the company and what decisions may be taken upon successful completion of the experiment (e.g. post experiment decisions and activities to promote further process improvement). To achieve this goal, proposing organisations will have an outline plan on how the experiment results and the lessons learnt will be disseminated internally within their own organisations.
With regard to the potential for replication outside their own company, proposers should substantiate that the problem addressed in the experiment is a common problem shared by a wider community and that the experiences achieved can be later transferred to the wider community. It is anticipated that the proposers will commit themselves to participate and present results and achievements of the project, at least, at two external international events (may be identified during the course of the project). In addition to this external dissemination required by the Commission, proposers may wish to undertake additional activities for external dissemination. These additional activities should be clearly indicated, together with the target audience.
The following table should be used as a starting point for presenting the planned dissemination activities:
| Activity | Type | Target audience | Planned date |
| 1st presentation at international event | presentation | software practitioners | Mid-term |
| 2nd presentation at international event | presentation | software practitioners | End |
| other internal dissemination activities .... |
|||
| other external dissemination activities ..... |
II.1. Phased Workplan - describes the main workpackages of the experiment including their output (deliverables), their timing and the related effort estimates. These workpackages, including training, reporting and dissemination, should be clearly defined (per work package in terms of objective, the approach to be followed, deliverables) and scheduled.
Interdependencies should be identified and the contribution of the involved organisations (proposer and subcontractors) should be clearly stated (their technical contribution and commitment of effort to each task). Some details on the relation between experiment and baseline project activities would be welcome (e.g. in terms of timing of tasks/work packages and efforts), and it is recommended to clearly distinguish between experiment and baseline project activities.
For the output of the work packages (deliverables), the form of the deliverable (paper report, conference, etc.), its reference (e.g. D1.1), its expected date and its intended audience (internal, external, Commission, etc.) should be indicated.
The breakdown of effort should be given in person-days (per work package, per proposer and/or subcontractor). Effort expended should be commensurate with the total amount of work to be done and with the cost.
The following table should be used as a starting point for the workplan presentation:
| Workpackage reference |
Start date | End date | Effort in (person-days) | Deliverable reference | ||
| Proposer | Sub-contractor(s) | Total | ||||
For the timing it is recommended that proposers include a bar chart of activities against elapsed time (a 1 page Gantt Chart).
II.1. Subcontracts and other Cost Clarification - substantiates the budget for each of the cost categories given in form 3 of Part I and/or explains the basis of the calculation for their estimates.
This particularly should include the labour rates used for personnel (which must exclude overheads and profit), the basis of the calculation for the software costs (e.g. product name or generic description of any software to be purchased, number of licences and expected costs), and for the training costs (e.g. subject of training, estimated number of participants, expected costs).
Clear justification for the use of subcontractors should be provided - including (i) why, (ii) who (or a generic description of type of subcontractor), (iii) what (nature of work under subcontract) and (iv) estimated costs per subcontractor. It would be welcome if their estimated daily labour rates could also be given.
Evaluation Criteria for PIEs
Proposals will be evaluated on the basis of the following criteria:
Note that the above criteria are not listed in any particular order of importance.
Proposal Structure and Contents
| Form | Title | Maximum length (pages) |
| Part II of Proposal | ||
| Free Format | II.1. Project Summary | 1 |
| Free Format | II.1. Geographical Region and Needs of Target Audience | 1 |
| Free Format | II.1. Project Objectives | 1 |
| Free Format | II.1. Strategy for Implementation - Activities and Mechanisms | 3 |
| Free Format | II.1. Software Best Practice Material | 1 |
| Free Format | II.1. Expected Benefits, Impact and Measurement of Actions | 1 |
| Free Format | II.1. Workplan | 3 |
| Free Format | II.1. The Proposer and their Suitability | 1 |
| Free Format | II.1. Cost Justification | 1 |
II.1 Summary - a one page description capturing the essence of the proposal by answering the questions: (i) Why is the proposed work needed? (in terms of motivation, business relevance and needs of target audience), (ii) What does it deliver? (in terms of objectives and expected results); (iii) Who does the work? (the proposer and subcontractors, if any); (iv) How is the work performed? (in terms of strategy and approach). It is expected that this section expands upon the Project synopsis presented in Form 1.a of Part I.
II.2 Geographical Region and Needs of Target Audience - identifies clearly the geographical region covered by the proposed action, the needs of PIEs as understood by the proposer and the needs of local industry involved with software development. If proposers believe that PIEs in this region do have quite specific requirements (e.g. based on information they themselves have already obtained), then this should also be indicated.
II.3 Objectives - clarifies the basic rationale for the project, in particular gives a precise statement of the measurable project objectives, as regards (i) the support of the regional PIEs, (ii) activities targeting wider local industry, and (iii) operation on a European level (through co-operation with other ESPINODEs), and how these relate to the requirements of the target audience.
II.4 Strategy for Implementation of Action - gives the strategic approach for implementing the project in order to achieve the objectives and satisfying the needs of the target audience, particularly the activities undertaken and the mechanisms used - according to the different roles, responsibilities and tasks of an ESPINODE.
II.5 Software Best Practice Material - gives a clear identification of material (paper and/or electronic format) resulting from the different types of actions, and indicates what type of material will be used for which portion of the target audience (e.g. for regional PIE cluster, local industry, wider ESSI community through other ESPINODEs). Possible contributions to the ESSI Software Best Practice Library (see section 1.1) should also be described.
II.6 Expected Benefits, Impact and Measurement of Action - gives an analysis of the expected business and technical benefits of the proposed action for the target audience (distinguishing PIE cluster, region, wider European community), including realistic targets for achieving these benefits. It also provides a practical scheme for measuring success of the action, and explains how the effectiveness of the used mechanisms is assessed.
II.7 Workplan - gives a phased schedule of work, described by workpackages with effort estimates, together with a list of deliverables and milestones as well as bar and pert chart to illustrate sequence and dependencies of the planned work.
II.8 The Proposer and its Suitability - starts with a brief description of the main business of the proposer, its motivation for the proposed action and the business relevance. It should then describe the current technical and business competencies (in particular the number of staff already involved in software best practice activities) relevant for the task of an ESPINODE, demonstrating the suitability of the proposer. If external organisations and experts will be involved, then these should be named and brief details on their competencies should be given . The latter applies also for key staff of the proposer.
If the proposer was or is involved in other ESSI projects, then this should be mentioned here (including an indication of the relevant project(s) and its role therein).
In view of the co-operation with other ESPINODEs - which may include e.g. the organisation of theme based working groups at European level - it would also be useful to know in which software best practice relevant business and technical areas the proposer has particular expertise.
Overall this section should provide the reader with confidence as to the ability of the proposer to perform the role of an ESPINODE.
II.9 Cost Justification - substantiates and justifies the budget for each of the cost categories given in Form 3 of Part I. This justification should include labour rates used for personnel (which must exclude overheads and profit).
Evaluation Criteria for ESPINODEs
Proposals will be evaluated according to the following criteria:
The above criteria are not in any specific order of importance. A balanced set of proposals - quite likely in terms of geographical coverage - will be selected from those which best match the above criteria.
Proposal Structure and Contents
| Form | Title | Maximum length (pages) |
| Part II of Proposal | ||
| Free Format | II.1. Project Summary | 1 |
| Free Format | II.1. Geographical Region and Needs of Target Audience | 1 |
| Free Format | II.1. Project Objectives | 1 |
| Free Format | II.1. Strategy for Implementation - Activities and Mechanisms | 3 |
| Free Format | II.1. Software Best Practice Material | 1 |
| Free Format | II.1. Expected Benefits, Impact and Measurement of Actions | 1 |
| Free Format | II.1. Workplan | 3 |
| Free Format | II.1. The Proposers and their Suitability | 1 per proposer |
| Free Format | II.1. Cost Justification | 1 per proposer |
II.1 Summary - should be a one page description capturing the essence of the proposal by answering the questions: (i) Why is the proposed work needed? (in terms of motivation, business relevance and needs of target audience), (ii) What does it deliver? (in terms of objectives and expected results); (iii) Who does the work? (the proposer and subcontractors, if any); (iv) How is the work performed? (in terms of strategy and approach). It is expected that this section expands upon the Project synopsis presented in Form 1.a of Part I.
II.2. Geographical Regions and Needs of the Target Audiences - a clear identification of the geographical regions and, for each of them, the target audience for which software best practice support is envisaged. This section should provide the motivation for this selection. The specific needs and requirement of each target audience should be described, as well as an explanation on how these needs and requirements were established.
II.3 Measurable Objectives - the focus of the network should be described and explained. A precise statement of the objectives of the project, in measurable terms and how they relate to the needs and requirements of the target audiences.
II.4 Strategy for Implementation - Activities and Mechanisms - a description of the strategy and the proposed approach in satisfying the needs of the target audiences. The mechanisms to be used for performing the proposed set of integrated Software Best Practice activities, should be clearly described.
In addition, this section should provide a description of the strategy, approach and mechanisms to facilitate, and cross-fertilise the different activities, across the regions (i.e. at a European level). The proposer should describe in concrete terms the added value of conducting the action at a European level and the benefits expected from co-operation between partners.
II.5 Software Best Practice Material - a description of the software best practice material (in paper and/or electronic form) to be used or produced within the frame of the action. In particular, information which will be produced and exchanged as part of the cross fertilisation between the different regions, should be identified.
The proposers should also plan for co-operation with the other running ESSI projects (dissemination and training); in particular, any foreseen contribution to the ESSI Software Best Practice Library (see section 1.1) should also be described.
II.6 Expected Benefits, Impact and Measurement of the Action - provides an analysis of the expected business and technical benefits of the proposed action for each target audience, for the regions and for the wider European software community. Realistic targets for achieving these benefits should be given together with a practical measurement scheme for assessing the effectiveness of the proposed mechanisms in achieving these targets.
II.7 Workplan - a phased schedule of work, described by workpackages with effort estimates, together with a list of deliverables and milestones as well as bar and pert chart to illustrate sequence and dependencies of the planned work.
II.8 The Proposers and their Suitability - a brief description of the main business of the proposers, their motivation for the proposed action and the relevance of this action to their business. It should describe the current technical and business competencies (in particular the number of staff already involved in software best practice activities) relevant for an ESBNET, demonstrating the suitability of the proposers. Finally, a brief description of the role of each partner in the project, and a list of key staff in the project.
If the proposer was or is involved in other ESSI projects, then this should be mentioned here (including an indication of the relevant project(s) and its role therein).
Overall this section should provide the reader with confidence as to the ability of the proposers to implement the proposed ESBNET activities.
II.10 Cost Justifications - substantiates and justifies the budget for each of the cost categories given in Form 3 of Part I. This justification should include labour rates used for personnel (which must exclude overheads and profit).
Evaluation Criteria for ESBNETs
Proposals will be evaluated according to the following criteria:
Note that the above criteria are not listed in any particular order of importance. It should be mentioned that preference will be given to proposals addressing innovative, new actions which complement - rather than repeat - previously funded ESSI actions.
Each proposal must have a co-ordinating proposer, the co-ordinator(12), and this section of the information package is primarily directed at this organisation.
Proposals should be submitted by you, the co-ordinator, and you will be responsible for liaison with the Commission.
You should submit one full original of each proposal, plus 6 copies, following the requirements of section 3.2 and using the forms as required. Any additional information will be ignored during the evaluation.
It is your responsibility to assemble the proposal and you should submit it in one parcel.
It is also your responsibility to ensure that the proposal is delivered at the appropriate address before expiration of the deadline.
All proposers are asked to help us with the planning of the evaluation by sending in the Expression of Interest, using the fax reply form of section 6.3, as soon as possible. This is not a pre-condition for submitting a proposal and will in no way effect the evaluation.
Your proposal should be sent by courier or postal services or delivered by hand to:
IT Programme Office
Boulevard du Souverain, 191-197
B-1160 Brussels
Belgium
You must clearly mark on the parcel:
'Confidential: Proposal for the programme for
RTD in Information Technologies (Esprit)'
Important note
Do not send proposals by fax or E-mail. Do not announce by fax or telephone that the proposals are in the mail. Faxes and telephone calls of this nature hinder the operation of the Commission in handling proposals, and will not be acknowledged. Until two weeks have elapsed, do not telephone or fax to enquire whether your proposal has been received.
Do not send or deliver your proposal to Esprit Commission Offices. This would create considerable delays. The only correct address is the one mentioned above.
The deadline for submission of the proposal is normally three months after the date of the Call for Proposals. The precise information is given in each call and should be carefully checked and adhered to. Proposals which are received after the deadline are not eligible.
You should include – in the parcel in which the proposal is delivered - a separate envelope containing the official 'Acknowledgement of Receipt' form as given in the Annex. On this you – the co-ordinator - must put your organisation's name and address and the title of the proposed project. This will ensure that the acknowledgement is returned to you correctly addressed.
Before it is returned, however, the Commission's reception staff will record the date of receipt and a unique reference number on the form. This reference number must be used in all subsequent correspondence relating to the proposal.
You should ensure that all proposers are given the proposal reference number and use it in all contacts with the Commission.
If you do not receive an 'Acknowledgement of receipt' within two weeks after the closing date of the Call, or the date of submission in case of a continuous Call, you should send a fax to the IT Programme office (Fax: + 32 2 6637200), indicating the acronym, title, domain, type of action and name of co-ordinator. You will receive an answer by fax within one week. You are strongly advised to retain proof of dispatch if the proposal is mailed or sent by courier.
You are advised to submit proposals only once and to not send proposals which are essentially the same to different domains of the ESPRIT Programme or different programmes.
If the proposal is related to other Esprit domains or to other Community programmes you are advised to indicate this in the proposal itself or in an attached covering letter.
In any case you should give details on similar proposals onform 1a and sign the declaration.
The IT programme will take your comments in account and when appropriate involve the other domains or other programmes in the evaluation.
The IT programme reserves the right to redirect the proposals to another domain than indicated by the proposers or to another programme if EC staff or evaluators indicate that that would be more appropriate.
If there are further questions on the content of this Specific Information Document or if there is a need for further clarification in matters relating to the call, please contact:
| ESSI Information Desk (N105 3/43) European Commission DGIII/F4 Rue de la Loi 200 B1049 Brussels, Belgium. |
fax: +32.2.296.83.64 email: essi@dg3.cec.be |
For on-line details of the Work Programme and Specific Information Documents proposers should use the ESPRIT Web pages.
In particular, for up-to-date general information on ESSI, please consult the ESSI Webpage:
For information on past and current ESSI projects, including public Final Reports, please consult the ESSI Dissemination Action Webpage on:
project 24119 VASIE II
Part I - administrative and financial data
| FORM 1a : PROPOSAL ADMINISTRATIVE SUMMARY | |||||||
|
Programme Name: Esprit / ESSI |
Acronym:(max 10 chars) | ||||||
| Proposal Title: (Max 160 chars) | |||||||
| Contact Person during the Proposal Evaluation | |||||||
| First Name: | Family Name: | ||||||
| Organisation Name: | |||||||
| Department Name: | |||||||
| Street Name: | Street No: | ||||||
| Post Code | City | Country: | |||||
| Telephone: | Fax: | ||||||
| E-mail: | |||||||
| Project synopsis (maximum 1000 characters) | |||||||
|
| |||||||
| Please sign your answer to the following question | |||||||
|
To the best of your knowledge, has this proposal, or a proposal that is similar in content, with your involvement or with the involvement of any of the partners in your consortium, been submitted to any other domain of Esprit or EU research programme? Yes / No If your answer is Yes, please give details (title of proposal, coordinator, name of programme, when submitted). Signature of Contact Person............................................................................................ | |||||||
| FORM 1B : PROPOSAL ADMINISTRATIVE SUMMARY (continued) | |||||||
| Proposal resources breakdown | |||||||
|
Programme Name: Esprit / ESSI |
Action Type: SBP | Acronym (max 10 char): | |||||
| Proposal Title (max 160 char): | |||||||
| Work Programme Tasks (c): | |||||||
| 1st Choice: |
2nd Choice: | 3rd Choice: | Duration (in months) | ||||
| List of participants | |||||||
|
No |
Organisation Names (d) |
Country (b) |
Admin.Role (b) (C/P/A) |
Org. Type (b) |
Funding Regime (e) (S/A) |
Global Costs in ECU (f) |
|
| A | |||||||
| A | |||||||
| A | |||||||
| A | |||||||
| A | |||||||
| A | |||||||
| A | |||||||
| A | |||||||
| Total Costs: | |||||||
|
Please copy this form if more space is needed to list the participants. The participation in the Proposal of all the Partners and Associated Partners, and at the levels indicated above, must be formally sanctioned by representatives of the said organisations in letters accompanying the proposal. | |||||||
|
(b) A list of codes is supplied in this Annex. (c) See Work programme : task 1.28 (PIE), 1.36 (ESPINODE) or 1.37 (ESBNET) (d) Short name for participants that use such a name in Form 2, and legal name if such a short name does not exist. (e) 'A' indicates costs funded at 100% of anticipated Actual Costs; refer to section 2.2 for an explanation of this term. (f) Please specify 100% of anticipated Actual Costs. | |||||||
|
| |||||||
| FORM 2 : INDIVIDUAL PARTICIPANT PROFILE | |||||||
| Programme Name: Esprit / ESSI | Acronym: | ||||||
| Proposal Title: | |||||||
| Legal identification of the Participating Organisation | |||||||
| Short name (h): | Legal Status (i): | Organisation Type(l): | |||||
| Company Registration No: | VAT No: | ||||||
| Legal Name (j): | |||||||
| Department Name (if applicable): | |||||||
| Legal address of the Participating Organisation | |||||||
| Street Name: | Street Number: | ||||||
| Post Code: | City: | Country : | |||||
| Telephone No: | Fax No: | ||||||
| Organisation's role in the proposal | |||||||
| Administrative role (l) (C/A): | Functional role(l) (S/U): | Relevant industrial sector (l): | |||||
| Organisation details (if applicable) | |||||||
| Number of employees: | Is the participant an SME (Y/N)? (k) | ||||||
| Is your organisation affiliated to any other participant(s) in the proposal (Y/N)? (k): | |||||||
| If the answer is Y, please indicate the participant(s) name(s): | |||||||
|
(h) A Short name should be included only if it is in common use outside the organisation (max. 20 char.). (i) e.g. SA, Ltd, GmbH, AG, EEIG, etc. (j) The legal name is the one used in contracts. (k) For definition see glossary. (l) A list of codes is supplied in this Annex. | |||||||
| 1. Action Types | |||||
| SBP | Software Best Practice | ||||
| 2. COUNTRY | |||||
| Code | Name | Code | Name | Code | Name |
| A | Austria | FL | Liechtenstein | N | Norway |
| B | Belgium | GR | Greece | NL | Netherlands |
| CH | Switzerland | ISR | Israel | P | Portugal |
| D | Germany | I | Italy | S | Sweden |
| DK | Denmark | IRL | Ireland | SF | Finland |
| E | Spain | ISL | Iceland | UK | United Kingdom |
| F | France | L | Luxembourg | ||
| Other according to standard ISO list | |||||
| 3. ADMINISTRATIVE ROLE | |||||
| C | Coordinator | A | Associate Partner | ||
| 4. ORGANISATION TYPE | |||||
| U | University | A | Public Administration | R | Research Institute |
| I | Industry | O | Other | ||
| 5. FUNCTIONAL ROLE | |||||
| S | Supplier | U | User | ||
| Please note that this relates to the specific role that your organisation has in this proposal with respect to its expected results. If both apply please choose the one most relevant in this project. | |||||
| 6. INDUSTRIAL SECTORS | |||||
| Identify the relevant industrial sector of the organisation in the proposal and include the corresponding code in the appropriate space on Form 2 | |||||
| Code | |||||
| Business | |||||
| Finance and Insurance | FI | ||||
| Business, legal and management consultancy; holdings | BC | ||||
| Publishing, printing and reproduction of recorded media | PP | ||||
| Real estate activities | RE | ||||
| Renting and leasing | RL | ||||
| Lodging and restaurants | LR | ||||
| Technical testing and analysis | TA | ||||
| Wholesale and retail trade; repair of goods | WR | ||||
| Community activities | |||||
| Community service activities | CS | ||||
| Education | ED | ||||
| Energy production and distribution; gas and water supply | EN | ||||
| Health and social work | HS | ||||
| Recreational, cultural and sporting activities | RC | ||||
| Recycling | CY | ||||
| Post and telecommunications | PT | ||||
| Transportation services | TS | ||||
| Engineering (other than software engineering) | |||||
| Electrical engineering and related technical consultancy | EE | ||||
| Mechanical engineering and related technical consultancy | ME | ||||
| IT activities | |||||
| Audiovisual consumer electronics | IA | ||||
| Electronic components | IC | ||||
| Electronic engineering and related technical consultancy | IE | ||||
| Industrial process control systems | IP | ||||
| Office machinery and computers | IM | ||||
| Software consultancy and supply, data processing and related Services | IS | ||||
| Manufacturing | |||||
| Aircraft and spacecraft | AS | ||||
| Metals and alloys | MA | ||||
| Chemical products | CP | ||||
| Fabricated metal products, except machinery and equipment | FM | ||||
| Food products and beverages | FB | ||||
| Furniture | FV | ||||
| Leather and leather products | LL | ||||
| Machinery, electrical and electrical instruments | EQ | ||||
| Medical, precision and optical instruments | IN | ||||
| Non-metallic mineral products | MP | ||||
| Pharmaceuticals, medicinal chemicals and botanical products | PH | ||||
| Pulp, paper and paper products | PA | ||||
| Rubber and plastic products | RU | ||||
| Textile and textile products | TE | ||||
| Vehicles for land transportation | VL | ||||
| Vehicles for sea transportation | VS | ||||
| Wood and wood products | WW | ||||
| Other activites | |||||
| Agriculture and forestry | AF | ||||
| Construction and building | CB | ||||
| Fishing | FS | ||||
| Mining and quarrying | MQ | ||||
| Telecom products | IT | ||||
| Activity code not provided above | NN | ||||
| Form 3: INDIVIDUAL PARTICIPANT COSTS | |||
| Programme Name : Esprit / ESSI | Acronym : | ||
| Proposal Title : | |||
| Short Name (m) : | Administrative role (n) (C/A) : | ||
| Country : | Duration (in months) : | ||
| Anticipated Actual Costs (o) of Participating Organisation | |||
| Description of actual costs | Costs in ECU | ||
| Justifiable additional labour (please specify effort in persondays and labour rate per day) (p) | |||
| Subcontracts (please specify estimated effort and costs per subcontract) (q) | |||
| Travel and subsistence | |||
| Training - pies only - (q) | |||
| Dissemination and reporting (q) | |||
| Purchase of software/Licence fees (q) | |||
| Others (please specify) | |||
| Total Anticipated Actual Costs | |||
|
(m) Short name for participants that use such a name in Form 2, and legal name if such a short name does not exist. (n) A list of codes is supplied in this Annex. (o) Refer to section 2.2. for an explanation of this term. (p) General company overheads and profits are not allowable. (q) Payable to third parties. | |||
| Form 4: PIE project characteristics | |||||
| Programme Name: Esprit / ESSI | Acronym: | ||||
| Proposal Title: | |||||
| Short name (r): | Administrative role (s) (C/A): | Industrial sector (t): | |||
| The number / percentage of employees involved in software engineering: ........... / .............% | |||||
| Has your organisation already participated in ESSI? (Yes / No) | |||||
| If the answer is 'Yes', please indicate the project number, type and the (expected) termination date. | number | type(u) | end date | ||
| 1. Systems Point of view - Baseline Project (v) | |||||
| Business Oriented Systems | Technically Oriented Systems | Embedded Control Systems | |||
| 2. Application Domain/Attributes of Baseline Project(w): | 3. Reference Technology used in the Experiment (x): | ||||
| EDP (electronic data processing) | Formal Methods | ||||
| MIS (management information systems) | Groupware | ||||
| Manufacturing/Production Systems | Metrication | ||||
| Control Systems | Object Oriented | ||||
| Transaction Processing | Process Improvement models | ||||
| Multimedia Systems | Prototyping | ||||
| Decision Support Systems | RAD | ||||
| Knowledge Based Systems | Re-engineering | ||||
| Safety Critical Systems | Reuse | ||||
| Geographic/Technical Information Systems | Reverse engineering | ||||
| Distributed Systems | Technologies for testing | ||||
| Graphical User Interfaces | Workflow | ||||
| Development of Software Tools | Other (please specify): ... | ||||
| Distributed Systems | 4. Category of Methods / Tools used in Experiment for process improvement (y) | ||||
| Database Applications | |||||
| Client/Server Applications | 1.a) | ||||
| Real Time Systems | b) | ||||
| Other (please specify): ... | 2.a) | ||||
| b) | |||||
| 5. Process point of view - major focus of the experiment (z) | |||||
| Engineering Category | Customer-Supplier Category | ||||
| Develop system requirements and design | Acquire software | ||||
| Develop software requirements | Manage customer needs | ||||
| Develop software design | Supply software | ||||
| Implement software design | Operate software | ||||
| Integrate and test software | Provide customer service | ||||
| Integrate and test system | Organisation Category | ||||
| Maintain system and software | Engineer the business | ||||
| Support Category | Define the process | ||||
| Develop documentation | Improve the process | ||||
| Perform configuration management | Provide skilled human resources | ||||
| Perform quality assurance | Provide software engineering infrastructure | ||||
| Perform work product verification | Management Category | ||||
| Perform work product validation | Manage the project | ||||
| Perform joint reviews | Manage quality | ||||
| Perform audits | Manage risks | ||||
| Perform problem resolution | |||||
| Other (please specify):.. | |||||
|
(r) Short name for participants that use such a name in Form 2, and legal name if such a short name does not exist. (s) A list of administrative role codes is supplied with Form 2. (t) A list of industrial sector codes is supplied with Form 2. (u) Type of project: AS (assessment), PIE (Process Improvement Experiment or Application Experiment), DA (Dissemination Action), TRA (Training Action) or NET (Experience/User Network) (v) Just tick one area (according to the underlying Baseline Project). 'Business Orientated Systems' would e.g. include the software process of all traditional MIS and EDP systems, found in banks, insurance, industry and public administration; for instance sales and marketing support systems, personnel management and administration systems, financial information systems, reservation systems, office automation systems, etc. 'Technically Orientated Systems' would e.g. include the development of systems aimed at engineering professionals, which may be used in a business or control environment; for instance computer aided design/manufacturing systems, computer aided software engineering tools, geographic information systems, simulation systems, document image processing systems, etc. 'Embedded and Control Systems' would e.g. include all software applications which are embedded within systems, which the user may or may not be aware of their existence; for instance in industrial automation and process control systems, signal processing systems, telecommunications systems, consumer products, etc. (w) Just tick one area according to the main focus of your Baseline Project (if several areas apply, indicate priorities: priority 1 = most important). (x) Just tick one area according to the main technology used as reference in your Experiment (if several areas apply, indicate priorities: priority 1 = most important). (y) Please specify according to the main focus of your Experiment: a) the category of method/tool used in Experiment (e.g. configuration management tool, testing tool, prototyping method, etc.), and b) the name of the product (if known). If several categories of methods/tools are used, list them all. (z) Please specify according to the main process area affected by your Experiment (if several areas apply, indicate priorities: priority 1 = most important). | |||||
European Commission
Directorate General III: Industry
RTD: Information Technologies
|
Please write the name and address to |
|
|
VERY IMPORTANT We may ask the representatives of proposers to attend meetings and/or provide further information at any time after the closing date and especially in the first two months after this date. In your own interest please ensure that representatives are available at short notice during this period. | |
|
To be completed by Coordinating Partner | |
|
Reference : | |
|
Proposal Title : | |
|
Acronym : | |
|
Domain : | |
|
To be completed by Esprit Evaluation Coordinator | |
|
We are pleased to acknowledge receipt of your proposal above on :..................................................................
Yours sincerely, | |
| Affiliated Organisation | Two organisations are affiliated if either one directly or indirectly controls the other or if both are directly or indirectly controlled by the same parent organisation. Organisation A is considered as controlling B if:
|
| CORDIS | Community Research and Development Information Service (see Section 5 in Introductory Booklet) |
| EC | European Commission |
| EU | European Union |
| EEA | European Economic Area, includes the EU, Iceland and Norway. The EEA agreement is not in force for Liechtenstein at the time of printing this document |
| EEIG | European Economic Interest Grouping. A legal entity consisting of several European organisations which could participate as such in a project under an EU programme. A guide to the role of EEIGs in RTD can be obtained from the IT Programme Information Desk (see section 5 in Introductory Booklet) and more detailed documentation is also available from Directorate General XV (Financial Institutions and Company Law) |
| EFTA | European Free Trade Association, includes Iceland, Liechtenstein, Norway and Switzerland |
| ESSI | European Software Systems Initiative, a best practice activity in ST |
| HPCN | High Performance Computing and Networking: one of the four focused clusters in the IT work programme |
| ICT | Information and Communication Technologies |
| IiM | Integration in manufacturing: one of the four focused clusters in the IT programme |
| IT | Information technology |
| IPR | Intellectual property rights |
| JRC | Joint Research Centre of the EC |
| LTR | Long term research: one of the domains in the IT work programme |
| MS | Multimedia systems: one of the three domains of underpinning technologies in the IT work programme |
| OMI | Open microprocessor systems initiative: one of the four focused clusters in the IT work programme |
| RTD | Research and technological development, including demonstration |
| SME | Small/medium sized enterprise. For SME Exploratory Awards, enterprises will be eligible if they satisfy simultaneously the following three criteria:
|
| ST | Software technologies: one of the three domains of underpinning technologies in the IT work programme |
| TBP | Technologies for business processes: one of the four focused clusters in the IT work programme |
| TCS | Technologies for components and subsystems: one of the three domains of underpinning technologies in the IT work programme |
|
EXPRESSION OF INTEREST IN SUBMITTING A PROPOSAL For Software Best practice (ESSI) | |||
F A C S I M I L E | |||
|
To : |
ESSI Information Desk (J Bacquet) |
Fax nr |
+32 2 296.8364 |
| From : | Fax nr | ||
| Organisation: | Tel nr | ||
| Address | |||
| Expected Proposal Title : | |||
| task for which you expect to submit a proposal |
PROCESS IMPROVEMENT EXPERIMENT (PIE) - task 1.28 ESSI PIE NODE (ESPINODE) - Task 1.36 PROACTIVE SOFTWARE BEST PRACTICE NETWORK (ESBNET) - task 1.37 | ||
|
ESPRIT Specific Information Document - Software Best Practice (ESSI) Reader's feedback | |||
F A C S I M I L E | |||
|
To : |
ESSI Information Desk (B Holmes) |
Fax nr |
+32 2 296.8364 |
| From : | Fax nr | ||
| Organisation: | Tel nr | ||
| Address | |||
| Please score your satisfaction with this document, using the following headings (mark your chosen score): | |||
|
Unsatisfactory ....................................... Good Clarity..........1...........2...........3...........4 Ease of use..........1...........2...........3...........4 Completeness..........1...........2...........3...........4 Consistency..........1...........2...........3...........4 Number of errors..........1...........2...........3...........4 If you have read other, previous versions of the information document for ESSI (known as the Information Package [1996 and 1995]), how would you compare this version ? I prefer this version / I prefer the previous version(s) (please delete the incorrect choice) Comments and recommendations for the future: | |||
National Contact Points will help if you have any questions about the Programme and the preparation of proposals.
A list of National Contact Points is available for consultation.
(1) It should be noted that the 1997 edition of the ESPRIT Work Programme contains only PIEs (task 1.28) from the previous editions of the Work Programme (used for previous calls). PIEs together with the two new tasks, ESPINODEs and ESBNETs, are the subject of this call - no other type of ESSI project (tasks 1.27, or 1.29 to 1.31 in previous editions of the Work Programme) is being called for.
(2) 'maturity is used throughout this document to indicate the extent to which an organisation is producing high quality software, regularly, efficiently and economically, according to recognised standards.
(3) Refer to the report of an industrial consultation conducted by the Commission in early 1997 - see section entitled "Addressing the needs of the target audience"
(4) Route of action 12, green paper on innovation, supplement 4/95 bulletin of the European Union
(5) A network in this context is simply a group of organisations, based in different countries, operating together to implement an ESBNET project, according to an established plan of action, using appropriate methods, technologies and other appropriate support.
(6) The Project Programme - an integral part of the contract which details the objectives of the project, the work to be performed and the associated budget.
(7) Associated contracts - there is a requirement, however, that associated contracts pass on the same rights and obligations to the associated contractor as exist in the main contract between the co-ordinator and the Commission.
(8)For definition see the Glossary in section 6.
(9) For more information on the deliverables of PIEs, refer to section 1.2
(10) The Project Programme - an integral part of the contract which details the objectives of the project, the work to be performed and the associated budget.
(11)They may have conducted a thorough self assessment or had an external assessment according to one of the recognised and established assessment methods.
(12) In the case of projects involving only one organisation, this organisation is the co-ordinator.
The purpose of the questionnaire which accompanies this Information Document (i.e. the 'Software Best Practice Questionnaire') is to collect information on the maturity(2) of European industry with regard to software development. The questionnaire will provide a snapshot of the situation and the results will be analysed at the European level to provide an overall picture for Europe.
It should be stressed that the information in the questionnaire will be treated in the strictest of confidence. Whilst a completed questionnaire is mandatory for all proposers of task 1.28 (Process Improvement Experiments),the contents of the questionnaire will be stored and processed anonymously and will not influence the proposal evaluation in any way.
All organisations involved in software development -whether or not they are proposers- are encouraged to complete the questionnaire and to send it to the address given in Chapter 4.
| Software Best Practice : ESSI (1997 Version) | ||
| Browse the document below or download a version from here | ||
| ESSI Infopack - Word 6 version (670.7 Kb) | ESSI Questionnaire - Word 6 version (22 Kb) | ESSI Infopack and Questionnaire - Zipped Word 6 version |
The URL of this document is /esprit/src/essi.htm
It was last updated on 22 May 1997 and is maintained by Susan Panter