Common use of Software engineering, quality assurance and certification Clause in Contracts

Software engineering, quality assurance and certification. Most of the software development activities in the grid domain in Europe in the past several years have relied on projects of a very distributed nature, typical of major open source initiatives, where software developers were tasked with developing services and components starting from minimal specifications rapidly changing and evolving in time as the user requirements became clearer and better understood. By their nature, most of these projects employ developers with different degrees of expertise and different technical and cultural backgrounds. Although all grid and distributed middleware development share a strong basis of common principles like the adoption of a Service Oriented Architecture, different projects and even different Institutes within the same project usually adopt software development technologies of their own choice and in some cases develop new processes and methods. Several projects in the past years have devised collaboration processes and techniques suitable for heavily distributed software engineering activities. The first EGEE project in 2004-2006 had a central integration and testing team responsible to define overall guidelines and deploy and maintain common continuous integration tools (originally based on CruiseControl). At the end of EGEE I, the ETICS project was created with the specific objective of defining, implementing and maintaining a collaborative distributed environment for the continuous integration and testing of the software developed by projects like EGEE II (gLite), DILIGENT, OMII-Europe, 18 Open Grid Forum (OGF). Web site: xxxx://xxx.xxx.xxx 19 OASIS Consortium. Web site: xxxx://xxx.xxxxx-xxxx.xxx D4Science, UNICORE, EDGES and others. The ETICS project and its current follow-up, ETICS 2, have established an infrastructure and developed tools that allow developers using different programming languages and different engineering technologies to manage large software system with common APIs, web-based configuration and management tools and share and preserve the software they produce. Currently the use of continuous integration and testing methods is adopted in many cases as an additional activity on top of the actual software development activities, but it is not always considered an integral part of the development process driving the release management criteria. The major issues preventing a more correct adoption of agile methodologies and the use of rapid prototyping methodologies based on continuous integration and testing tools are a lack of common methodologies in the different development teams; the difficulty of implementing automated tests due to lack of support in the middleware and lack of effort; and finally the lack of enforcement of corrective actions based on monitoring of metrics and results from the applied software methodology. EMI will adopt, from the start, a tight integration of software quality assurance methodologies in the development process with an explicit commitment to use the results and metrics collected to drive the certification process and establish the acceptance and rejection criteria used to define the negotiated Service Level Agreements. An important role of the quality assurance activities in EMI is the implementation of the Continual Improvement Process as defined by ITIL, whereby the results of the process application are monitored and used to refine the metrics and the process itself. Another important point where the EMI project improves over the existing state of the art is the establishment of continuous functional and regression testing with a high degree of automation. Although this concept is far from being new in software engineering, its application has been very limited in grid development projects so far, due to the complexity of the middleware and a tendency to under-emphasize the development of test suites as something to be added after the development is finished, rather than a tool to help the development from its beginning. In order to transition from the current software engineering models used by different projects and middleware consortia converging into EMI, the concept of a Product Team will be adopted. A Product Team essentially represents the ‗self-organizing‘ team recommended by Agile methodologies like Scrum and is responsible for the entire lifecycle of individual products or small groups of tightly coupled products, including the development of test-suites to be peer- reviewed within the overall certification process. The explicit application of this concept in the software engineering procedures will allow EMI to have a better control on the efficiency of distributed teams using a common QA framework (the common cultural and technical background required by Agile methods to work), but operationally independent in their execution and at the same time fully accountable for achieving the agreed results. More detailed information about the structure and roles of the EMI project and the concepts of Services, Product Teams and Continual Improvement Process is given in section B1.3.1. In the field of software engineering, the EMI project will also rely on existing standards. The Quality Assurance activities will use existing ISO standards for the definition of the common terminology and software lifecycle phases and will follow the guidelines of the good-practice methodologies described in CMMi and ITIL. The certification method will be based on the A- QCM (Automated Quality Certification Model) defined by the ETICS project, which is fully compliant with ISO 9126 and is being presented to the international ISO Committee for validation