Spelling suggestions: "subject:"document ariven 1design"" "subject:"document ariven 22design""
1 |
Case Studies in Document Driven Design of Scientific Computing SoftwareJegatheesan, Thulasi January 2016 (has links)
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)
|
2 |
INVESTIGATING COMMON PERCEPTIONS OF SOFTWARE ENGINEERING METHODS APPLIED TO SCIENTIFIC COMPUTING SOFTWARESrinivasan, Malavika January 2018 (has links)
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)
|
Page generated in 0.0698 seconds