View article

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 …