Abstract={The use of software is pervasive in all fields of science. Associated software development efforts may be very large, long lived, and complex, requiring the commitment of significant resources. However, several authors have argued that the ``gap'' or ``chasm'' between software engineering and scientific programming is a serious risk to the production of reliable scientific results, as demonstrated in a number of case studies. This article reviews the research that addresses the gap, exploring how both software engineering and research practice may need to evolve to accommodate the use of software in science.},
Acmid={3084225},
Address={New York, NY, USA},
Annote={- makes clear case (with examples) that software brings a variety of benefits to scientific research
- highlights SCS probs with scientific methd, esp repeatability and reproducibilty - examples of retractions
``There is a need to improve the transfer of existing practices and tools from other applications of software engineering to scientific programming. In addition, due to the specialised nature of scientific programming, there is a need for research to specifically develop methods and tools that are tailored to the domain.''},
Author={W. Spencer Smith and Thulasi Jegatheesan and Diane F. Kelly},
Booktitle={Proceedings of the Fourth International Workshop on Software Engineering for High Performance Computing in Computational Science and Engineering (SE-HPCCE)},
Date-Added={2017-11-20 03:50:08 +0000},
Date-Modified={2017-11-20 03:50:08 +0000},
Month={November},
Note={8 pp},
Title={Advantages, Disadvantages and Misunderstandings About Document Driven Design for Scientific Software},
Abstract={We present the design and implementation of a generative geometric kernel. The kernel generator is generic, type-safe, parametrized by many design-level choices and extensible. The resulting code has minimal traces of the design abstractions. We achieve genericity through a layered design deriving concepts from affine geometry, linear algebra and abstract algebra. We achieve parametrization and type-safety by using OCaml's module system, including higher order modules. The cost of abstraction is removed by using MetaOCaml's support for code generation coupled with some annotations atop the code type.},
Author={Jacques Carette and Mustafa ElSheikh and W. Spencer Smith},
Booktitle={ACM SIGPLAN 2011 Workshop on Partial Evaluation and Program Manipulation (PEPM'11)},
Annote={Apparently this article was never published in this form. It looks like it was published as Engineering Domains: Executable Commands as an Example.},
Author={David A. Cuka and David M. Weiss},
Date-Added={2017-09-14 20:49:28 +0000},
Date-Modified={2017-09-14 20:49:28 +0000},
Journal={Submitted to IEEE Transactions on Software Engineering},
Booktitle={Proceedings of the 2nd International Scientific Computing in Object-Oriented Parallel Environments ({ISCOPE}'98), Lecture Notes in Computer Science},
Abstract={This paper presents a documentation and development method to facilitate the certification of scientific computing software used in the safety analysis of nuclear facilities. To study the problems faced during quality assurance and certification activities, a case study was performed on legacy software used for thermal analysis of a fuelpin in a nuclear reactor. Although no errors were uncovered in the code, 27 issues of incompleteness and inconsistency were found with the documentation. This work proposes that software documentation follow a rational process, which includes a software requirements specification following a template that is reusable, maintainable, and understandable. To develop the design and implementation, this paper suggests literate programming as an alternative to traditional structured programming. Literate programming allows for documenting of numerical algorithms and code together in what is termed the literate programmer's manual. This manual is developed with explicit traceability to the software requirements specification. The traceability between the theory, numerical algorithms, and implementation facilitates achieving completeness and consistency, as well as simplifies the process of verification and the associated certification. },
Software produced for research, published and otherwise, suffers from a number of common problems that make it difficult or impossible to run outside the original institution or even off the primary developer's computer. We present ten simple rules to make such software robust enough to be run by anyone, anywhere, and thereby delight your users and collaborators.
[Author summary]
Many researchers have found out the hard way that there's a world of difference between '' works for me on my machine'' and '' works for other people on theirs.'' Many common challenges can be avoided by following a few simple rules; doing so not only improves reproducibility but can accelerate research.
[Excerpt]
[\n] [...]
Best practices in software engineering specifically aim to increase software robustness. However, most bioinformaticians learn what they know about software development on the job or otherwise informally [...]. Existing training programs and initiatives rarely have the time to cover software engineering in depth, especially since the field is so broad and developing so rapidly [...]. In addition, making software robust is not directly rewarded in science, and funding is difficult to come by [...]. Some proposed solutions to this problem include restructuring educational programs, hiring dedicated software engineers [...], partnering with private sector or grassroots organizations [...], or using specific technical tools like containerization or cloud computing [...]. Each of these requires time and, in some cases, institutional change.
[\n] The good news is you don't need to be a professionally trained programmer to write robust software. In fact, some of the best, most reliable pieces of software in many scientific communities are written by researchers [...] who have adopted strong software engineering approaches, have high standards of reproducibility, use good testing practices, and foster strong user bases through constantly evolving, clearly documented, useful, and useable software.
[...]
[\n] So what is '' robust'' software? We implied above that it is software that works for people other than the original author and on machines other than its creator's. More specifically, we mean that:
[::] it can be installed on more than one computer with relative ease,
[::] it works consistently as advertised, and
[::] it can be integrated with other tools.
[\n] Our rules are generic and can be applied to all languages, libraries, packages, documentation styles, and operating systems for both closed-source and open-source software. They are also necessary steps toward making computational research replicable and reproducible: after all, if your tools and libraries cannot be run by others, they cannot be used to verify your results or as a stepping stone for future work [...]
[::] Rule 1: Use version control [...]
[::] Rule 2: Document your code and usage [...]
[::] Rule 3: Make common operations easy to control [...]
[::] Rule 4: Version your releases [...]
[::] Rule 5: Reuse software (within reason) [...]
[::] Rule 6: Rely on build tools and package managers for installation [...]
[::] Rule 7: Do not require root or other special privileges to install or run [...]
[::] Rule 8: Eliminate hard-coded paths [...]
[::] Rule 9: Include a small test set that can be run to ensure the software is actually working [...]
[::] Rule 10: Produce identical results when given identical inputs [...]
Booktitle={Proceedings of the First International Workshop on Situational Requirements Engineering Processes -- Methods, Techniques and Tools to Support Situation-Specific Requirements Engineering Processes, SREP'05},
Date-Added={2017-09-05 02:21:52 +0000},
Date-Modified={2017-09-05 02:21:52 +0000},
Editor={J. Ralyt\'{e} and P. \.{A}gerfalk and N. Kraiem},
