Managing design variety, process variety and engineering change: a case study of two capital good firms

Many capital good firms deliver products that are not strictly one-off, but instead share a certain degree of similarity with other deliveries. In the delivery of the product, they aim to balance stability and variety in their product design and processes. The issue of engineering change plays an important in how they manage to do so. Our aim is to gain more understanding into how capital good firms manage engineering change, design variety and process variety, and into the role of the product delivery strategies they thereby use. Product delivery strategies are defined as the type of engineering work that is done independent of an order and the specification freedom the customer has in the remaining part of the design. Based on the within-case and cross-case analysis of two capital good firms several mechanisms for managing engineering change, design variety and process variety are distilled. It was found that there exist different ways of (1) managing generic design information, (2) isolating large engineering changes, (3) managing process variety, (4) designing and executing engineering change processes. Together with different product delivery strategies these mechanisms can be placed within an archetypes framework of engineering change management. On one side of the spectrum capital good firms operate according to open product delivery strategies, have some practices in place to investigate design reuse potential, isolate discontinuous engineering changes into the first deliveries of the product, employ ‘probe and learn’ process management principles in order to allow evolving insights to be accurately executed and have informal engineering change processes. On the other side of the spectrum capital good firms operate according to a closed product delivery strategy, focus on prevention of engineering changes based on design standards, need no isolation mechanisms for discontinuous engineering changes, have formal process management practices in place and make use of closed and formal engineering change procedures. The framework should help managers to (1) analyze existing configurations of product delivery strategies, product and process designs and engineering change management and (2) reconfigure any of these elements according to a ‘misfit’ derived from the framework. Since this is one of the few in-depth empirical studies into engineering change management in the capital good sector, our work adds to the understanding on the various ways in which engineering change can be dealt with

Taking advantage of hybrid systems for sparse direct solvers via task-based runtimes

The ongoing hardware evolution exhibits an escalation in the number, as well as in the heterogeneity, of computing resources. The pressure to maintain reasonable levels of performance and portability forces application developers to leave the traditional programming paradigms and explore alternative solutions. PaStiX is a parallel sparse direct solver, based on a dynamic scheduler for modern hierarchical manycore architectures. In this paper, we study the benefits and limits of replacing the highly specialized internal scheduler of the PaStiX solver with two generic runtime systems: PaRSEC and StarPU. The tasks graph of the factorization step is made available to the two runtimes, providing them the opportunity to process and optimize its traversal in order to maximize the algorithm efficiency for the targeted hardware platform. A comparative study of the performance of the PaStiX solver on top of its native internal scheduler, PaRSEC, and StarPU frameworks, on different execution environments, is performed. The analysis highlights that these generic task-based runtimes achieve comparable results to the application-optimized embedded scheduler on homogeneous platforms. Furthermore, they are able to significantly speed up the solver on heterogeneous environments by taking advantage of the accelerators while hiding the complexity of their efficient manipulation from the programmer.Comment: Heterogeneity in Computing Workshop (2014

What Does Aspect-Oriented Programming Mean for Functional Programmers?

Aspect-Oriented Programming (AOP) aims at modularising crosscutting concerns that show up in software. The success of AOP has been almost viral and nearly all areas in Software Engineering and Programming Languages have become "infected" by the AOP bug in one way or another. Interestingly the functional programming community (and, in particular, the pure functional programming community) seems to be resistant to the pandemic. The goal of this paper is to debate the possible causes of the functional programming community's resistance and to raise awareness and interest by showcasing the benefits that could be gained from having a functional AOP language. At the same time, we identify the main challenges and explore the possible design-space

Automating the design of scientific computing software

SINAPSE is a domain-specific software design system that generates code from specifications of equations and algorithm methods. This paper describes the system's design techniques (planning in a space of knowledge-based refinement and optimization rules), user interaction style (user has option to control decision making), and representation of knowledge (rules and objects). It also summarizes how the system knowledge has evolved over time and suggests some issues in building software design systems to facilitate reuse