ABSTRACT
One argument against a document driven process is that scientists do not view rigid, process-heavy approaches, favorably [59]. As an example from a scientific software developer, Roache [99, p. 373] considers reports for each stage of software development as counterproductive. However, the reports are only counterproductive if the process used by the scientists has to follow the same waterfall as the documentation. This does not have to be the case. Given the exploratory nature of science, developers do not typically follow a waterfall process, but, as Parnas and Clements [95] point out, the most logical way to present the documentation is still to “fake” a rational design process. “Software manufacturers can define their own internal process as long as they can effectively map their products onto the ones that the much simpler, faked process requires” [88]. Reusability and maintainability are important qualities for scientific software. Documentation that follows a faked rationale design process is easier to maintain and reuse because the documentation is understandable and standardized. Understandability is improved because the faked documentation only includes the “best” version of any artifacts, with no need to incorporate confusing details around the history of their discovery [95]. Standardization on any process, with a rational process being a logical choice as a standard, facilitates design reviews, change management and the transfer (and modification) of ideas and software between projects [95].
