An approach to control collaborative processes in PLM systems

Companies that collaborate within the product development processes need to implement an effective management of their collaborative activities. Despite the implementation of a PLM system, the collaborative activities are not efficient as it might be expected. This paper presents an analysis of the problems related to the collaborative work using a PLM system. From this analysis, we propose an approach for improving collaborative processes within a PLM system, based on monitoring indicators. This approach leads to identify and therefore to mitigate the brakes of the collaborative work

Metamodel for Tracing Concerns across the Life Cycle

Several aspect-oriented approaches have been proposed to specify aspects at different phases in the software life cycle. Aspects can appear within a phase, be refined or mapped to other aspects in later phases, or even disappear.\ud Tracing aspects is necessary to support understandability and maintainability of software systems. Although several approaches have been introduced to address traceability of aspects, two important limitations can be observed. First, tracing is not yet tackled for the entire life cycle. Second, the traceability model that is applied usually refers to elements of specific aspect languages, thereby limiting the reusability of the adopted traceability model.We propose the concern traceability metamodel (CTM) that enables traceability of concerns throughout the life cycle, and which is independent from the aspect languages that are used. CTM can be enhanced to provide additional properties for tracing, and be instantiated to define\ud customized traceability models with respect to the required aspect languages. We have implemented CTM in the tool M-Trace, that uses XML-based representations of the models and XQuery queries to represent tracing information. CTM and M-Trace are illustrated for a Concurrent Versioning System to trace aspects from the requirements level to architecture design level and the implementation

On Evidence-based Risk Management in Requirements Engineering

Background: The sensitivity of Requirements Engineering (RE) to the context makes it difficult to efficiently control problems therein, thus, hampering an effective risk management devoted to allow for early corrective or even preventive measures. Problem: There is still little empirical knowledge about context-specific RE phenomena which would be necessary for an effective context- sensitive risk management in RE. Goal: We propose and validate an evidence-based approach to assess risks in RE using cross-company data about problems, causes and effects. Research Method: We use survey data from 228 companies and build a probabilistic network that supports the forecast of context-specific RE phenomena. We implement this approach using spreadsheets to support a light-weight risk assessment. Results: Our results from an initial validation in 6 companies strengthen our confidence that the approach increases the awareness for individual risk factors in RE, and the feedback further allows for disseminating our approach into practice.Comment: 20 pages, submitted to 10th Software Quality Days conference, 201

Identifying common problems in the acquisition and deployment of large-scale software projects in the US and UK healthcare systems

Public and private organizations are investing increasing amounts into the development of healthcare information technology. These applications are perceived to offer numerous benefits. Software systems can improve the exchange of information between healthcare facilities. They support standardised procedures that can help to increase consistency between different service providers. Electronic patient records ensure minimum standards across the trajectory of care when patients move between different specializations. Healthcare information systems also offer economic benefits through efficiency savings; for example by providing the data that helps to identify potential bottlenecks in the provision and administration of care. However, a number of high-profile failures reveal the problems that arise when staff must cope with the loss of these applications. In particular, teams have to retrieve paper based records that often lack the detail on electronic systems. Individuals who have only used electronic information systems face particular problems in learning how to apply paper-based fallbacks. The following pages compare two different failures of Healthcare Information Systems in the UK and North America. The intention is to ensure that future initiatives to extend the integration of electronic patient records will build on the ‘lessons learned’ from previous systems

The natural history of bugs: using formal methods to analyse software related failures in space missions

Space missions force engineers to make complex trade-offs between many different constraints including cost, mass, power, functionality and reliability. These constraints create a continual need to innovate. Many advances rely upon software, for instance to control and monitor the next generation ‘electron cyclotron resonance’ ion-drives for deep space missions.Programmers face numerous challenges. It is extremely difficult to conduct valid ground-based tests for the code used in space missions. Abstract models and simulations of satellites can be misleading. These issues are compounded by the use of ‘band-aid’ software to fix design mistakes and compromises in other aspects of space systems engineering. Programmers must often re-code missions in flight. This introduces considerable risks. It should, therefore, not be a surprise that so many space missions fail to achieve their objectives. The costs of failure are considerable. Small launch vehicles, such as the U.S. Pegasus system, cost around $18 million. Payloads range from$4 million up to $1 billion for security related satellites. These costs do not include consequent business losses. In 2005, Intelsat wrote off$73 million from the failure of a single uninsured satellite. It is clearly important that we learn as much as possible from those failures that do occur. The following pages examine the roles that formal methods might play in the analysis of software failures in space missions