Dear FACIT-SME Partners!

It's a pleasure to present the first issue of the FACIT-SME project newsletter!
The FACIT-SME project RTD Partners would like to use this tool to establish a communication channel during the research project and to update end-user organisations on the results of the project, the status of deliverables, and recent/on-going/planned dissemination and exploitation actions.
It also contains a calendar, which gives an overview of past and future FACIT-SME research project events and meetings!
Please send any feedback or questions related to the content to the coordinator, Dr. Markus Rabe.
Thank you for your attention!

The FACIT-SME - RTD team

Finally Achieved a Contract - The Happy End of a Painful Procedure
Editorial notes from a slightly upset project manager

On the 6th June 2010, the FACIT SME project finally received the official grant agreement. Never in my life it has taken such a huge amount of time to bring a project finally into reality, and
never a project under my management has to take the risk to perform five months without a finally signed contract. Did we have so much disagreement in what the project should achieve? Or did the partners - as not fully unusual - have problems to agree on their consortium agreement?
Both would have been at least acceptable reasons, but things went different.
In fact, there was only minor discussion about goals, targets, and duties. After the negotiation meeting in Brussels on the 9th September 2009, we needed just 2 months to finalize the "description of work" (DoW), which was agreed by all partners and characterized as "the final draft" by the commission on 11th of November. This period is fully acceptable, and even shorter than it had been in some other projects.
So, partners could not find their cooperation rules? Not at all - I have rarely been so quick in finalizing the "consortium agreement" (CA). It took me some time to adapt Fraunhofer templates to our specific project (also we first focussed on the more critical DoW), but the first draft was submitted to the partners by 3rd of November - and it was agreed by 12th December. Honestly, this is a record in my career, no other project was that quick.
So - what has happened?
The European Commission, being faced with several complains on their weird contracting procedures, had decided to make a really huge step forward and install a new agency (REA) that is to conduct all the contracting and administration issues. Thus, all the procedures will be less costly (as synergies appear when they can do it for all programs), much more simple to use, quicker for the participants, and easier to access for small companies ...
We had to somehow deal with the results.
Honestly said, the REA officers dealing with our project really did their best, and even tried to remain friendly knowing about the gigantic trouble that they must have been faced to in the first months. However, the processes where obviously not consistent, responsibilities not in line with processes, and last but not least software interfaces not consistent and the implemented software still had the appealing of a first test version.
In the beginning, the assignment of privileges to add or change data was either arbitrary (in these cases it mostly worked quite well) or following not fully thought systematic. Just as a sample, when we have been asked by the Commission to make some specific changes in the system, partially there was only one (1) person in Fraunhofer that was entitled to conduct this. Imagine - what would you do if you receive e-mails regarding about 50-100 projects that you hardly know? Right, that's what happened. Meantime, everybody has learned, today the project manager is entitled to assign responsible persons for management, contracting, finance; so we can cleanly distribute the requests. In another project that I followed in spring 2010, things already went much better.
The most hard-ache-issue type of story was the company data. In good old times IPK compiled the required forms and sent them to the Commission. We repaired faults, answered requests, and everyone was happy and finally signed the accepted form.
Now, the computer supports all of us, and the small enterprises had to assign a "LEAR" (we knew before that "King Lear" is a tragedy, but now we will never forget it !!!!). All the companies had to fill a web form with their data and specific information, based on questions and acronyms where even IPK needed hours to understand what this could potentially mean. No real surprise that it frequently was faulty. The only surprise was that the web system accepted a significant part of this faulty (in content, in syntax, ....) information. As we will recognize later, this was a kind of time bomb.
After this procedure taking more time than all the negotiation about content, IPK "submitted" the forms (which in fact means pushing a button that alerts the commission and immediately excludes us from any further corrections). There were some weeks of silence, and then we got a long list of change requests. A few of them where obvious. But, several were quite funny, as the "partner type" (Research, SME, Association) was partially missing. Sandra and me would have been ready to swear that this information had already been in the system. We made a little search, found an old PDF printout of the system, and - voila!
So, we were the "good guys" but that helped just nothing. We had to re-enter the information. Note that there was only one person at Fraunhofer entitled ... OK, after some phone calls REA took the unsystematic but operational way and opened the system for us to change. Happily we added the information and tried the "store" button. Guess? It did not work. We got the time bomb back: some phone numbers were syntactically wrong (e.g. minus characters were not allowed). Nothing more simple, change the phone number and save? Forget it, the phone number is a protected field. Or, the country code in the phone number was missing. IPK is the coordinator, we are not entitled to change sensitive company data like the phone numbers (even if we only delete a minus and add a "+39"). We were near to ask official letters from our partners to REA that as an Italian company they herewith officially confirm that their phone numbers have Italian country codes, when a REA officer had pity with us and just changed the numbers. Similar case with the zip code of Joinet (that was wrong in the system, and thus in the contract offer). Guess, who has entered the correct code (yes, IPK!) and - more difficult - who entered the wrong one? The latter was REA, but they had a faulty confirmation of the Bologna chamber of commerce showing a non-existent combination of the right (new) street but the former (thus wrong) zip. Joinet obviously never recognized that, nor did anybody else, but REA did and they changed the information. Of course, without notifying Joinet or the coordinator. Again, we could after several e-mails convince an officer that there is really only one "Via brini" in Bologna, and there are plenty of systems in the internet that show that there is only one zip code for that ...
Everything solved? Stop being optimistic. When we re-submitted, we were told that the "partner type" of several partners was still missing (again!!). Now, this was a matter of honor for us! We made a careful analysis of the probable business processes at REA, and found the point. Obviously, they have two different databases for the companies and the projects. When they change the company database, they copy the related records also to the project database, in order to keep them consistent. Brilliant idea. They just forgot that there is additional information in the project database (especially the partner type). Consequently, each change in the company database destroys the related record in the project database. We wrote a careful error analysis, sent it to the helpdesk, never got any kind of feedback, but our officer finally manually changed the remaining information himself.
Long story? You might not believe me, but these have been just samples. We had a similar list of issues with all the financial data. This started from partners that by accident entered wrong data through the "LEAR" (fully understandable, as you need a specific education to understand the terms given in these forms). Consequently, the new consistent systems also changed all the data that we had (correctly) provided in (1) the proposal, (2) our forms, and (3) our version of the DoW. Now, there is probably no need to say that neither the partner nor the coordinator have been notified about his change. Of course, this had implication on the finance calculation, and we searched hours until we detected the source of the fault and more than a fortnight to bring back the change to the systems, in this case of course with a formal original signed letter from the partner.
Solved - but still wrong. After some additional hours we found that the web system's calculation procedure is not fully in line with the proposer's guideline (or, at least, it gives a specific interpretation) that leads to different rounding faults. In fact, following the web system we would have had to transfer fractions of cents to our partners, something that European banks won't really love to do (they really prefer to keep fractions for them ...). OK, we have been talking about forty four (44) Eurocents (yes, cents) and I would have loved to open my pocket and put them to the table. Unluckily, the web system had not table, was unwilling to accept my cash and continued to ask for the "correct" numbers. Thus, we finally somehow invented them, knowing that the probable shifts during the project are anyway more in the kilo-Euro range than in cents - and the finance was working!
In most programs, on this base we can get the contract. But, the SME program is special, and so are the rules. In early April we got an unsigned copy of the contract (which we immediately signed and returned to Brussels on the 15th of April). Then we had to get the "accession forms" signed in original by all partners (declaring that they access to a contract that in fact did not exist, as the Commission did not sign it). In former times, all partners signed the contract and "basta". Today, only the coordinator and the EC sign the contract, and the coordinator has to exchange the accession form with all partners that has to be signed in triplicate by both. I like the idea of simplifying things, but in this case neither me nor Verena or Sandra really understood the simplification ...
OK, we got all originals until the 7th of May (as a two partners sent their copies by snail mail) and immediately provided them to Brussels. After the usual two weeks of silence we - unbelievably - received the contract, and six weeks later the first portion on money.
Today, I would really like to thanks all partners, especially those never losing their confidence and working five months heavily on the project without a valid contract in their hands. I am sure that it was worth the effort, and today we can already see the first great project results on the horizon.
Do it again? Perhaps, but not that soon ...
Markus Rabe
Project Manager

What SMEs really look for as project results?
In order to achieve the challenging goals of the FACIT-SME project, the RTD Partners collected and analysed the software engineering quality oriented requirements of SMEs in the IT industry. Réka Moksony, from Régens, interprets the major findings of the interviews.

In the first 3 months of the project Joinet, ESI and Régens conducted interview sessions with IT SMEs based on a questionnaire covering the following topics:
  • Software Engineering processes
  • Communication practices
  • Software Engineering tools and systems in place
  • Quality Models, standards and request for standardised procedures
  • Project knowledge base
  • Business goals, targets and recent SWOT analysis
In Hungary, IVSZ requested the involvement of two additional companies that are experts in Software Quality Management. Régens established a list of questions especially targeting those QA experts in order to better understand the quality issues from the "Clients" point of view. 8 companies in Hungary, Italy, and Spain have compiled the questionnaire. The RTD partners discussed the major findings in Berlin, May 2010. A preliminary list of requirements of IT SMEs was established. This list represents a common set of requirements of software developing SMEs that provide services and applications to different industry sectors.
  • All interviewed highlighted that communicating with clients and implementing good practices and tools to support clients' understanding are critical success factors of an IT development or product implementation project. Models and easy-to-use collaboration tools could support these processes.
  • SMEs prefer to invest as little effort as possible in documentation. This can be achieved with document templates, reuse of documents, links to document structures, access to sources, and references across documents - in this way avoiding double work.
  • There is a need for traceability of previous projects in terms of tasks, effort, and deadlines, to allow for better estimation practices for resources as well as plan and fact comparison.
  • Defect, error reduction as traceability of defects, transference of test scenarios for clients, clear acceptance tests, issue management, CMMI, ISO9000, IT-Mark, clear responsibility and role assignment, are all company goals that require higher testing efficiency (workflows/test procedures, roles and responsibilities).
  • Most companies would like to achieve cost savings via more efficient and controlled procedures. Reducing maintenance costs (defect reduction, acceptance test, etc.), modification risk (change management, approximation of modification costs and relationships with other systems, rollback procedures, etc.), and communication costs (communication with clients, tractability/tracking system, etc.) can lead to significant savings throughout the entire process.
  • These reductions are highly dependent on human resources, in particular knowledge management.
Summary of D 2.1 - major results of 1-6 project months!
The RTD partners' work was subdivided into work packages to fulfil the research requests of SME AGs and SMEs. They create deliverables identified by numbers. The project included more than 20 deliverables. The main outcome of the project's first phase is the publically available D2.1 summary, in which Frank-Walter Jaekel from IPK presents major findings.

The results of the questionnaire (see previous chapter) have been used as a guideline for the development of the Open Reference Model (ORM). The ORM serves as a knowledge backbone in terms of procedures, documents, tools and deployment methods in the software engineering process. The public deliverable D2.1 describes architecture and meta-model of the ORM. It also contains a collection of engineering methodologies, tools and quality models to use as the initial content of the ORM. The focal point within the ORM is the enterprise process which is usually expressed within an enterprise model (Fig. 1):
  • The software engineering methods promise instructions for the detailed implementation of development processes,
  • The quality models confine the process by requirements in order to deliver an adequate quality to customers and to enable certifications,
  • The tools are resources supporting the software engineering process by providing required functionalities,
  • The deployment methods provide instruction for the detailed implementation of the deployment and IT service processes.

UML and also accepted enterprise modelling methods such as IEM (Integrated Enterprise Modelling), EPC (Event-driven process chain) and IDEF (Integration definition) exist. However, different standardisation approaches create their own modelling methods independent from each other e.g. SPEM (Software & Systems Process Engineering Meta-Model Specification). Therefore, ORM will be open in terms of modelling technology by providing open interfaces and using meta-models such as POP* which provides an approach for the exchange between different modelling languages and tools. In terms of available resources, IEM will be used as an initial modelling method in FACIT-SME.
Taking into account the discussions with IT SMEs and the results from the questionnaire a standardisation of the workflow is expected to support better quality, consistent communication with clients, improvement of documentations and reduction on the period of vocational adjustment.
Therefore, ORM will provide libraries with model fragments, engineering methods and quality models which can be configured on demand of a specific project. The list below exemplifies considered methods:
  • Project management ⇒ Prince2,
  • Quality management ⇒ ISO9001, IT-MARK
  • Development ⇒ Waterfall, Scrum, V-Model
  • Service provision ⇒ ITIL
Anyway, the target is the support of the software engineering processes in relation with the enterprise processes. Fig. 2 illustrates an example of the involvement of the client via inquiry, offer, order and additional demands. After the software production via requirement collection, development and testing the product is delivered to the client. With FACIT-SME the enterprise processes will be supported by enterprise-specific standards for the process and organisational structure as well as by workflow management, document management and communication services. Also the management of knowledge regarding lessons learnt in the project for future projects will be considered. article1

The realisation of the ORM functionality is defined by the ORM Application Components. They are described in detail within D2.1 and cover
  • the ORM repository implementing the ORM meta-model,
  • ORM library providing fragments of the reference model,
  • Enterprise modelling and model integration facilities,
  • Filtering and specialisation system to derive enterprise and project specific models.
The FACIT-SME meta-model for the ORM relies on existing knowledge from software engineering methods and quality models as well as existing meta-models such as SPEM 2.0, SysML, POP*, ISO19440, etc.. The meta-model is structured in different parts: the core and the packages related to the core. The parts of the FACIT meta-model are described below:
  • FACIT-SME Meta-model Core: The core covers the most generic classes which are required for the ORM. It also represents the bridge between the different meta-model packages of the ORM.
  • FACIT-SME Meta-model package of Constructs for Enterprise Modelling: This package covers the meta-classes for enterprise models required by the ORM and also covers the aspect of model libraries covering methods, best practises, model fragments. This package relies mostly on POP*/ISO19440 and defines a model library approach on top of POP*.
  • FACIT-SME Meta-model package for Quality Models: This package covers the meta-classes for the description of certification requirements and the required aspects from the quality models.
  • FACIT-SME Meta-model package for Software Engineering methods: The package defines classes and mechanism to represent software engineering approaches. Therefore it relies mostly on SPEM 2.0 and it analyses the relation to the process descriptions.
  • FACIT-SME Meta-model package for project management: In the current meta-model the aspect of project management is included in the software engineering package. In terms of parameters and indicators it will be further elaborated.
  • FACIT-SME Meta-model package for tools: The ORM should be able to provide information about available software engineering tools. Therefore a meta-model package has been introduced to store the required information such as provider, licence aspects, constrains, provide functionality etc.
  • FACIT-SME Meta-model package for deployment: The package "Deployment" deals with aspects of deploying and service provision. It relies on previous work done on the basis of ITIL (Information Technology Infrastructure Library).
The initial content of the ORM is provided by selections and surveys about engineering methods, tools, quality models and IT enterprise processes which are described in D2.1.
First dissemination activities were performed at the IESA2010 in UK and will be addressed at the end of September during the ICT Event in Brussels.
Outlook on the expected FACIT-SME solution space:
The "FACIT-SME Solution Concept" defines a set of so called "execution services". These services are concerned with the execution of processes previously defined in ORM and OSES. Therefore the "execution services" only cover:
  • Task management
  • Document management
  • Messaging
The "Task management" might be realised also by a workflow system.
However, the "execution services" are not the only parts of the "FACIT-SME Solution Concept" (Fig. 3) which are executed. Also the modelling, filtering, customising, search aspects, adaptation and instantiation functionalities of ORM/OSES are executable components of the whole system. A recommendation feature will be realised which proposes suitable process and organisational structures as well as related tools for a specific enterprise or project. The ORM repository will be able to store data of available tools, quality models and software engineering approaches as a common entry point for IT SMEs. Furthermore the solution space will also provide certification support features. Nevertheless, it will also support an open interface for "execution services".
During the first half-year of the project the consortium aimed to communicate the existence of FACIT SME and to inform industry players of what was involved in this research project. The consortium has since enhanced its main actions and future plans for communicating to a wider audience. Let's see what IVSZ in Hungary achieved!

IVSZ (SME AG) and Régens have been actively introducing FACIT-SME in Hungary since January. IVSZ has posted the project's scope and goals on its website, sent this information to 1,600 newsletter contacts, and integrated the project's description in their annual report and organisation leaflet. One of Hungary's most recognized professional magazines, the IT Business, has published a short article about the project based on an interview conducted with Klara Heilingbrunner and Reka Moksony (http://rgurl.net/km). IVSZ will present the project at the MENTA Conference September 2010 and intends to present FACIT in more detail to the Software Quality Working Group in December. IVSZ's further plans for 2010 are to disseminate the project's results at the following events: Business Academy, Government CIO seminars.

In the next issue we provide dissemination information from all other AG Partners! To be continued!
FACIT SME events agenda - 2010
Past events:
  • General Assembly meeting, and project kick-off / Modena, Italy/ 13-15. January 2010
  • Workmeeting for RTD Partners/Berlin, Germany/10-12.May 2010
  • Workmeeting for RTD Partners/Budapest, Hungary/16-18. June 2010
  • Workmeeting for RTD Partners and SME end-users in Italy/Bologna,
    Italy/ 27-29. July 2010
Upcoming events:
  • General Assembly meeting/Bilbao, Spain/ 23-24. September 2010
  • Workmeeting for RTD Partners/Berlin, Germany/3-4 December 2010
All rigths reserved by FACIT-SME Consortium 2010.
Coordinator contact: Markus Rabe    Fraunhofer IPK-Berlin    markus.rabe@ipk.fhg.de
This project is co-financed by the European Comission.

Confidentiality notice: this message, together with its annexes, contains information to be deemed strictly confidential and is destined only to the addressee(s) identified above who only may use, copy and, under his/their responsibility, further disseminate it. If anyone received this message by mistake or reads it without entitlement is forewarned that keeping, copying, disseminating or distributing this message to persons other than the addressee(s) is strictly forbidden and is asked to transmit it immediately to the sender and to destroy any paper and electronic one.