L Issler1, C Spreckelsen, C Wessel. 1. University of Leipzig, Institute for Medical Informatics, Statistics and Epidemiology, Haertelstr. 16-18, 04107 Leipzig, Germany. lutz.issler@imise.uni-leipzig.de
Abstract
OBJECTIVES: Due to the non-commercial, research-oriented context, software in medical informatics research projects is often developed by researchers as a proof-of-concept without applying structured software development process models. A guideline for software development can bring sufficient structure to the development process while avoiding the complexity of industry-standard methods. METHODS: We adapted the common evidence-based guideline development process from medicine to build a guideline for software development in our medical informatics teaching and research project. RESULTS: Our guideline development used the six steps of problem identification, first proposal, review, revision, gaining consensus and periodic guideline review. Since the developers had taken part in guideline development, our guideline clearly states the consensus of the development team over critical topics. The guideline improved the quality of our source code in structure and understandability. CONCLUSIONS: A software development guideline that is developed following a consensus panel approach is a good instrument for basic software quality assurance in domains where complex, industry-standard software development methods cannot be applied. This is especially the case in non-commercial, research-oriented medical informatics projects where mainly non-software engineers like students do the development work.
OBJECTIVES: Due to the non-commercial, research-oriented context, software in medical informatics research projects is often developed by researchers as a proof-of-concept without applying structured software development process models. A guideline for software development can bring sufficient structure to the development process while avoiding the complexity of industry-standard methods. METHODS: We adapted the common evidence-based guideline development process from medicine to build a guideline for software development in our medical informatics teaching and research project. RESULTS: Our guideline development used the six steps of problem identification, first proposal, review, revision, gaining consensus and periodic guideline review. Since the developers had taken part in guideline development, our guideline clearly states the consensus of the development team over critical topics. The guideline improved the quality of our source code in structure and understandability. CONCLUSIONS: A software development guideline that is developed following a consensus panel approach is a good instrument for basic software quality assurance in domains where complex, industry-standard software development methods cannot be applied. This is especially the case in non-commercial, research-oriented medical informatics projects where mainly non-software engineers like students do the development work.