Objetivo
In the aerospace market, mastering the development effort with respect to the desired reliability level allows a sharp commitment toward the final customers needs.
The project is aimed at achieving a process improvement on software development in safety-critical domains with special regard to better qualification of the software reliability of the final product through:
better efficiency and rigorous statistic measurements on the software testing process;
development of intrinsic low-defective software (Cleanroom).
Measurable objectives shall be identified among process metrics related to time and efforts spent to detect single defects as well as time and efforts spent to design, execute and report tests. Also product metrics related to code physical properties like resulting complexity and size shall be considered and correlated to failure severity classes. With reference to the actual process some yardsticks are considered.
THE EXPERIMENT
Context of the Experiment.
The experiment shall be performed in the context of the European Photon Imaging Camera (EPIC) Project to be flown in the next XMM/ESA spacecraft. The software for OnBoard Data Handling units is considered the Application Experiment.
Description of the Baseline project.
The software for the OnBoard Data Handling shall assure the telecommand and telemetry link between the payload low-level controller and the spacecraft central data handling. As the payload is intended for an operational life of at least 2 years with extension up to 10 years, the requirement for high reliability is very important for the software as well.
In compliance to PSS-05, the software process is ruled by a Software Project Management Plan (SPMP), referring to a Software Quality Assurance Plan (SQAP), both appointed by ESA. Accordingly, a Waterfall Process is set up through 4 main phases: SW Requirement phase (SR), Architectural Design phase (AD), Detailed Design phase (DD) and Production, Transfer phase (TR). Incremental deliveries are not explicitly stated, though several issues on EM, EQM, and FM are planned. Different levels of testing are planned but not by means of a separate Validation Team, although reviews are managed by Q.A. Personnel separated from the Development Team.
Process Improvement Experiment Steps.
Introduction of a Cleanroom Process implies many impacts on a traditional software development area as Engineering Process, Quality Assurance methods and Configuration Management, which shall be set as a rigorous, but not heavy-weight, process tool.
Beside a first assessment and a final results evaluation, two main steps shall be performed by the experiment:
Introduction of a Cleanroom Process in the software development where the Software Life cycle shall be thought for incremental development and followed by a suitable Quality Assurance Reviews plan, able to support the increasing complexity of the released software. Metrics shall be introduced to monitor progresses
Cleanroom Experimentation Software is incrementally developed starting from the most critical components as kernel or operating system, in order to achieve an early control on the trending reliability and a monitored reliability growth from the software releases for EQM up to the last release for Flight Model (FM).
EXPECTED IMPACT AND EXPERIENCE
At the end of the P.I.E results shall be matched with the traditional software process by means of quantitative metrics on both product and process. Impacts are expected in the following process area:
Software testing:
reduction of the 25% with respect to the development process;
testing coverage measured and focused on the most critical modules;
Code Validation:
MTTF equals to mission extent
Statistical 95% confidence level on the software correctness;
Product and Process Quality:
usual monitoring of process and product metrics
variance on committed delivery time: +- 1 month
People Issues and future plans:
at the end of the Experiment, the software development process shall be provided with organisation-wide quality procedures for a cleanroom development able to target the required reliability level of the final product with reference to the level of safety of each project. Project managers shall be able to use data coming from other similar projects to make more accurate predictions on resulting reliability level and needed resources.
Ámbito científico (EuroSciVoc)
CORDIS clasifica los proyectos con EuroSciVoc, una taxonomía plurilingüe de ámbitos científicos, mediante un proceso semiautomático basado en técnicas de procesamiento del lenguaje natural. Véas: El vocabulario científico europeo..
CORDIS clasifica los proyectos con EuroSciVoc, una taxonomía plurilingüe de ámbitos científicos, mediante un proceso semiautomático basado en técnicas de procesamiento del lenguaje natural. Véas: El vocabulario científico europeo..
- ingeniería y tecnología ingeniería mecánica ingeniería de vehículos ingeniería aeroespacial ingeniería aeroespacial vehículo espacial
- ciencias naturales informática y ciencias de la información software software de aplicación software de sistemas sistema operativo
- humanidades artes diseño arquitectónico
- ingeniería y tecnología ingeniería eléctrica, ingeniería electrónica, ingeniería de la información ingeniería electrónica sensores sensores ópticos
- ciencias naturales informática y ciencias de la información software desarrollo de software
Para utilizar esta función, debe iniciar sesión o registrarse
Programa(s)
Programas de financiación plurianuales que definen las prioridades de la UE en materia de investigación e innovación.
Programas de financiación plurianuales que definen las prioridades de la UE en materia de investigación e innovación.
Tema(s)
Las convocatorias de propuestas se dividen en temas. Un tema define una materia o área específica para la que los solicitantes pueden presentar propuestas. La descripción de un tema comprende su alcance específico y la repercusión prevista del proyecto financiado.
Las convocatorias de propuestas se dividen en temas. Un tema define una materia o área específica para la que los solicitantes pueden presentar propuestas. La descripción de un tema comprende su alcance específico y la repercusión prevista del proyecto financiado.
Convocatoria de propuestas
Procedimiento para invitar a los solicitantes a presentar propuestas de proyectos con el objetivo de obtener financiación de la UE.
Datos no disponibles
Procedimiento para invitar a los solicitantes a presentar propuestas de proyectos con el objetivo de obtener financiación de la UE.
Régimen de financiación
Régimen de financiación (o «Tipo de acción») dentro de un programa con características comunes. Especifica: el alcance de lo que se financia; el porcentaje de reembolso; los criterios específicos de evaluación para optar a la financiación; y el uso de formas simplificadas de costes como los importes a tanto alzado.
Régimen de financiación (o «Tipo de acción») dentro de un programa con características comunes. Especifica: el alcance de lo que se financia; el porcentaje de reembolso; los criterios específicos de evaluación para optar a la financiación; y el uso de formas simplificadas de costes como los importes a tanto alzado.
Coordinador
20090 Vimodrone
Italia
Los costes totales en que ha incurrido esta organización para participar en el proyecto, incluidos los costes directos e indirectos. Este importe es un subconjunto del presupuesto total del proyecto.