The use and development of Scientific Computing Software (SCS) has become commonplace in many fields. It is used to motivate decisions and support scientific research. Software Engineering (SE) practices have been shown to improve software quality in other domains, but these practices are not commonly used in Scientific Computing (SC). Previous studies have attributed the infrequent use of SE practices to the incompatibility of traditional SE with SC development. In this research, the SE development process, Document Driven Design (DDD), and SE tools were applied to SCS using case studies. Five SCS projects were redeveloped using DDD and SE best practices. Interviews with the code owners were conducted to assess the impact of the redevelopment. The interviews revealed that development practices and the use of SE varied between the code owners. After redevelopment, the code owners agreed that a systematic development process can be beneficial, and they had a positive or neutral response to the software artifacts produced during redevelopment. The code owners, however, felt that the documentation produced by the redevelopment process requires too great a time commitment. To promote the use of SE in SCS development, SE practices must integrate well with current development practices of SC developers and not disrupt their regular workflow. Further research in this field should encourage practices that are easy to adopt by SC developers and should minimize the effort required to produce documentation. / Thesis / Master of Science (MSc)

Scientific Computing (SC) software has significant societal impact due to its application in safety related domains, such as nuclear, aerospace, military, and medicine. Unfortunately, recent research has shown that SC software does not always achieve the desired software qualities, like maintainability, reusability, and reproducibility. Software Engineering (SE) practices have been shown to improve software qualities, but SC developers, who are often the scientists themselves, often fail to adopt SE practices because of the time commitment. To promote the application of SE in SC, we conducted a case study in which we developed new SC software. The software, we developed will be used in predicting the nature of solidification in a casting process to facilitate the reduction of expensive defects in parts. During the development process, we adopted SE practices and involved the scientists from the beginning. We interviewed the scientists before and after software development, to assess their attitude towards SE for SC. The interviews revealed a positive response towards SE for SC. In the post development interview, scientists had a change in their attitudes towards SE for SC and were willing to adopt all the SE approaches that we followed. However, when it comes to producing software artifacts, they felt overburdened and wanted more tools to reduce the time commitment and to reduce complexity. While contrasting our experience with the currently held perceptions of scientific software development, we had the following observations: a) Observations that agree with the existing literature: i) working on something that the scientists are interested in is not enough to promote SE practices, ii) maintainability is a secondary consideration for scientific partners, iii) scientists are hesitant to learn SE practices, iv) verification and validation are challenging in SC, v) scientists naturally follow agile methodologies, vi) common ground for communication has always been a problem, vii) an interdisciplinary team is essential, viii) scientists tend to choose programming language based on their familiarity, ix) scientists prefer to use plots to visualize, verify and understand their science, x) early identification of test cases is advantageous, xi) scientists have a positive attitude toward issue trackers, xii) SC software should be designed for change, xiii) faking a rational design process for documentation is advisable for SC, xiv) Scientists prefer informal, collegial knowledge transfer, to reading documentation, b) Observations that disagree with the existing literature: i) When unexpected results were obtained, our scientists chose to change the numerical algorithms, rather than question their scientific theories, ii) Documentation of up-front requirements is feasible for SC We present the requirement specification and design documentation for our software as an evidence that with proper abstraction and application of “faked rational design process”, it is possible to document up-front requirements and improve quality. / Thesis / Master of Science (MSc)