Current Practice in Software Development for Computational Neuroscience and How to Improve It

Marc-Oliver Gewaltig
Public Library of Science, 2014
Article

Résumé

Almost all research work in computational neuroscience involves software. As researchers try to understand ever more complex systems, there is a continual need for software with new capabilities. Because of the wide range of questions being investigated, new software is often developed rapidly by individuals or small groups. In these cases, it can be hard to demonstrate that the software gives the right results. Software developers are often open about the code they produce and willing to share it, but there is little appreciation among potential users of the great diversity of software development practices and end results, and how this affects the suitability of software tools for use in research projects. To help clarify these issues, we have reviewed a range of software tools and asked how the culture and practice of software development affects their validity and trustworthiness. We identified four key questions that can be used to categorize software projects and correlate them with the type of product that results. The first question addresses what is being produced. The other three concern why, how, and by whom the work is done. The answers to these questions show strong correlations with the nature of the software being produced, and its suitability for particular purposes. Based on our findings, we suggest ways in which current software development practice in computational neuroscience can be improved and propose checklists to help developers, reviewers, and scientists to assess the quality of software and whether particular pieces of software are ready for use in research.

Official source

https://infoscience.epfl.ch/record/201089?ln=fr

À propos de ce résultat

Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.

Concepts associés

Chargement

Publications associées

Chargement

Marc-Oliver Gewaltig
Public Library of Science, 2014
Article

Résumé

Official source

https://infoscience.epfl.ch/record/201089?ln=fr

À propos de ce résultat

Concepts associés (11)

Concepts associés

Chargement

Publications associées (5)

Publications associées

Chargement

Engineering of software-intensive systems is concerned with the creation and evolution of systems that shall exhibit desired properties in their execution as well as development environment. In this context, the motivation of this thesis, derived from current development practice, was twofold. Firstly, software development methods are increasingly required to extend their scope of applicability towards systems engineering. As a consequence, their modeling approaches must be able to cope with a larger diversity of systems and consequently a larger diversity of properties. But these approaches still need to provide a smooth transition to software modeling. Secondly, non-functional properties, which are largely a result of this implicit systems scope, play a major role in the way we design our software-intensive systems. The conceptual aids of current development methods, however, are still less mature in their explicit support for non-functional properties compared with their ability to support functional ones. The principal objective of this thesis is to contribute toward an improved model-based treatment of non-functional properties in development methods. Because we cannot discuss properties independently of the objects they are ascribed to, this objective amounts to a progression from modeling of software and its properties to modeling of interrelated systems and their properties. To address this aim a philosophy of properties and systems is proposed. The philosophy is expressed as a holistic conceptual model of properties and/of systems. It is complemented with some basic rules, which we call tenets. Tenets formulate how we use the philosophical knowledge. The conceptual model offers the foundations for a more generalized understanding of those fundamentally different types of systems and different types of properties that are relevant in software-intensive systems engineering. The generality of our holistic model draws the benefits from our investigations in the areas of systems science, cognitive science, and basic philosophy. The model helps to scrutinize and make sense of the large amount of data in the literature about "non-functional" issues in software engineering. The model is applicable in the derivation of methodological building blocks that can be incorporated into development methods. The building blocks include (a) a general model to discover stakeholders and properties for a given system, (b) a principled manner to trace the fundamentally different types of properties through hierarchies of systems, and (c) a proposal for the representation of systems, their properties and property traces in the UML. The concrete application of the gained knowledge to software engineering results in a proposal for a context-sensitive, customizable quality attribute model. It also results in a proposal on how to structure quality descriptions of software components. In order for such descriptions to be standardized and possibly tool-automated, this thesis proposes to utilize the Reusable Asset Specification and suggests alternatives for its XML-based representation.

EPFL2004

Chargement

Seamlessness is a promise often used to promote object orientation, and the use of object orientation in the different domains and in the different stages of the software development process has brought great improvements in seamlessness. Where can we find seamlessness? And are there different kinds of seamlessness? In this paper we look at seamlessness starting with the different models found in large software developments. To give a common base for the discussion a model architecture is presented and different aspects of seamlessness are defined. We then show on a general level, where object orientation has already brought some seamlessness, where it will hopefully bring a higher degree of seamlessness in the future and where it cannot bring seamlessness due to restrictions inherent to the model architecture. The emphasis of the discussion is not to present a complete theoretical treatment but rather to help software developers to judge the many claims about seamlessness.

1994

Chargement

The Model Architecture Frame: Quality Managment in a Multi Method Environment

Most quality management systems (QMS) which integrate software development are based on a single software development method. This particular method is enforced on all projects. The resulting QMS has to fulfil the ISO 9000 standards [13] and enables the control of the projects and the improvement of the development process, supporting it with all necessary guidelines and providing one terminology for the whole company. However, using only one specific method is not necessarily the best solution for a company with very heterogeneous projects and products. Requirements of customers, existing experience and training in the teams, projects still using structured methods and newer ones using object-oriented methods, adaptation of methods for special circumstances, and evolving modelling techniques, all of these factors call for the coexistence of different modelling methods within one company. If a QMS is based on only a single method, many projects might run outside the quality management regulations, unless the QMS excludes the details of the software development process. This problem can be overcome by the use of model architectures and model architecture frames. A model architecture describes the models that are developed within one specific method or project. All the different model architectures are derived from the generic model architecture frame. Such a frame, and not just one specific method, becomes the basis for the company wide regulations. This paper describes reasons for having multiple methods and life cycle models within one QMS, explains the basic concepts of defining a QMS using model architectures and model architecture frames, and shows how this approach may be applied in a project.

1995

Chargement

EPFL2004