|
|
|
The RAISER / RESET SDLC
Figure 7.1: The RAISER / RESET methodology for the development of research based software
IntroductionThe process of conducting computer science research and the process of developing a product that makes that research accessible have very different requirements. This chapter summarises the requirements and describes an approach that might be used to enable both computer science research and the spread and reuse of that knowledge. It is designed to reconcile the conflicting interests as described in the discussion section. Two methods will be introduced, RAISER designed for the research cycle and RESET designed to convert research into a stable product that can be used as a framework for further research or released publicly as a product. The development process does not contain computer science research, however it may be the basis of software engineering research as new design patterns emerge. Research or DevelopmentComputer science research, as explained in "CS and SE", is the study of the field involving solving problems with the aid of computers. This can involve new abstract data types, new algorithms or an adaptation of methods to a new uses. It also involves more theoretical research such as information theory with new concepts of information and its properties. What ever flavour of computer science research is being undertaken, there must be the element of `discovery'. Most research attempts, if compare to their initial ideas would be considered failures, however research grows with knowledge and the basic concepts and ideas in the researchers mind are constantly subject to change. A development process for software that embodies an algorithm, data type or other concept must likewise be able to change rapidly and should assist with this change and provide feedback for future usages and changes. As the real value is the conceptual idea, the burden of implementation must be minimized as much as possible. Development is the ongoing maintenance phase of the overall research project. New algorithms and functionality (i.e. new research ideas) should not be added in the development cycle. The development cycle is a restructuring and documenting phase. It aims to provide the research product with strong cohesion and loose coupling. It cleans up the code and leaves it ready for a new team of researcher to work on. It may also recreate the interface, add user documentation and make the product useable as a tool by other researchers or the public. The critical path1 Initial ResearchAll research starts out as an idea. For the computer scientist it is natural to convert that idea into an algorithm in pseudo-code or in a programming language they are comfortable with. This ideas is coded up, thought about, changed, recoded etc. and eventually the research comes to a close and papers are published. Evidence presented in the interview results section suggests that at this point most projects are only half done. Completing the projects will usually not produce more papers, although it may have an impact on the life time of the current piece of software (in many cases the life time will end with the publication of the paper). Our results in the Survey Results section suggest that projects that continue running produce more papers as well as more valuable software. After the initial research of the project development work is needed to clean up the code produced by exploratory programming and produce design and user documentation. This makes not only makes the work more usable, it also lowers the barrier to a new research continuing with the project. What is needed before new development takes place is a stable platform as discussed in "the problems addressed" section.2 A Stable PlatformWork on the project may now continue in the development phase. While one or more researchers may still take part in development, they are there as advisers to ensure the scientific integrity of the altered product, and to answers questions and clarify what any obscure parts of their code may be doing. As a result of the research process much of the research code may be difficult to follow. There may even be code that is called but does nothing. The critical factor when developing this sort of code is access to the researchers. The development phase aims to remove these issues and leave readable, documented, modular and reusable code. It does this between research projects and does not add a significant additional burden to the researchers.3 Follow on ResearchFollow on research is that which is based on the initial research. It may involve the development of a new algorithm to replace part of the existing code and reduce its computational complexity. It may involve redoing the research but for a different type of data, e.g. from continuous to discrete data as happened with early version of CaMML. It may add new functionality to compliment the existing research. Regardless of what type of follow on research is conducted, the researcher should work with a stable platform rather then the initial research. This makes their task easier. Large amounts of time are wasted trying to understand other researchers code, but well structured, readable code and a decent level of documentation can greatly reduce this time.4 Further developmentNew initial research may be incorporated into existing projects during the development phase. Follow on research may also be based on past follow-on research, however this should not be done directly, instead the new research should wait until the `initial' follow-on research has been through a development cycle and been incorporated into the stable platform. Alternatively follow on projects that are closely related and being researched at the same time may be regarded as one follow on project, in this case the research should be located in close proximity to each other and while this will add overhead for the researchers (compared with a serial implementation) use of the RAISER method may help limit it.RAISERSurvey results from the US show that for many research projects, time spent on detailed design documents may have a negative impact on the number of publications. In the Australian survey Figure E.12 (see extended results) show that detailed design documents are correlated with a reduced number of higher degree by research students involved in the project. Interviews and case studies suggest this is because these detailed forms of design require time. This time would need to be taken away from the research which is people motivation for being there. The aim of RAISER, Reactive Assisted Information Science Enabled Research, is to reduce the burden of design work to a level where it does not interfere with the research, yet still raise the design properties of the research to a higher level than where it would be with no methodology or process. For example where it is commonly at now. 1 ReactiveRAISER is a reactive process rather than a proactive one. Design and restructuring occurs regularly and concurrently with either design (e.g. pseudo-code, informal diagrams) or coding. Changes to the ideas or algorithm will result in a change in code and / or approach. Many tools can be used under RAISER and the exact choice will depends on the project. As the project changes, so too may the tools.2 AssistedThe code and methodology are there to assist the research not burden it.3 Information Science EnabledThis stresses the theoretical research that is behind the software development. It is thought by some experts to be a more meaningful name than Computer Science. Research that is not enabled by theoretical information science may in fact belong in the development phase.4 ResearchContributing new knowledge, as explained in Research or Development above.RESETAs software using the RESET method is based on research software it will differ somewhat from the usual development cycle. The key difference is that there will always be a prototype system available. There should also be access to the one or more of the developers of the prototype. The software itself is likely to have certain characteristics, the result of exploratory research and experimentation. The RAISER process may also have an impact. 1 Research EnabledAs the software is based on a research prototype there is a large chance that it does not fit any common design patterns. There is opportunity for software engineering research to abstract from this prototype and design new patterns. The work is also likely to be challenging and vary greatly project to project.2 Software EngineeringThe development task is largely one of software engineering. The prototype must be cleaned up and remoulded. The existing functionality should not need to be rewritten, rather the code may need to be restructured and have the interface and robustness improved. The software may also be more thoroughly tested and debugged. Regression testing may be configured for future use. Finally, a finished design document may be produced for future developers (be they software engineers integrating new components or computer scientists trying to develop new components).3 Task / Techniques / TacticsDepending on the level of RAISER techniques used the RESET process may involve a conversion technique, or if the code presented has not used a RAISER process or been written for readability it may involve a tactical attack on the code. Research code can be the most difficult to work with when future developers have not been considered. RESET may also refer to the tasks involved in the process, these will be described below.Elements of RAISER
Elements of RESET
7.5 ImplementationIt is recommended that a permanent reset group be set up in university departments using this method. The department should employ a small number of full time, perhaps recent graduates that have a desire to work on development rather than research. Research staff should be allowed to take a year's sabbatical every few years to work in the RESET center. This will improve their own coding proficiency and provide time for them to keep these skills up to date (something many lament they no longer have time for). An additional bonus to quality is achieved by having an "in house" research scientist heavily involved in the process. The research gain the added advantage of intimate knowledge of their colleges work. This can assist with their own general breadth of knowledge and the forging of new research links. |
