IGSTK: Development Process and Project Management Best Practices for an Open Source Software Toolkit for Image-Guided Surgery Applications

Please use this identifier to cite or link to this publication: http://hdl.handle.net/1926/19
Open source technologies are increasing in popularity for software development. Many open source projects rely on skilled development teams whose members are distributed throughout the world. Often, agile development methods are employed by these teams, as the focus is on concurrent development and fast production over requirements management and quality assurance. The image-guided surgery toolkit (IGSTK) is an open source development project that relies on the collaboration of a skilled and distributed development team, yet addresses a domain that demands managing requirements as well as implementing a high degree of robustness and addressing safety concerns. Due to this unique cross-section of open source technology and the surgical domain, the IGSTK team has developed a set of best practices and requirements techniques to augment commonly applied agile methods. This paper presents the lessons we have learned as we have engaged in the software development process.
Data
minus 1 File (62Kb)
Code
There is no code review at this time.

Reviews
minus Interesting by Tina Kapur on 09-17-2005 for revision #1
starstarstarstarstar expertise: 5 sensitivity: 4.5
yellow
Summary:
This paper describes the software development process for IGSTK, an open source image guided surgery toolkit whose architecture is described in a separate paper in this issue of the journal. It points out that in contrast to most open source projects, IGSTK needs to closely document the traceability of each requirement specification to its software implementation and testing in order to be compliant with the FDA (Food and Drug Administration) standards for medical devices. In particular, it details a collaborative method used in the project for capturing its evolving requirements.

Hypothesis
A hypothesis is that it is faster/cheaper/better to capture requirements with the proposed method than it is to manually update the requirements documentation.

Evidence
It is still early in the project to determine this.

Comments
- Some of the IGSTK team members have carried over best practices from their participation in other open source projects to IGSTK, which is a good way to propagate these through the medical image analysis research community.
- Note on the term “best practice”: it is usually used to describe a practice that is deemed “best” because it helped make an aspect of a project successful. Since IGSTK is still in its infancy, and its practice of capturing requirements collaboratively for traceability purposes has not yet been proven one way or another, it might be too early to knight it.
- As another reviewer pointed out, a trace matrix would be useful since it is a commonly used format to demonstrate traceability for FDA review. Such a three column matrix contains one row for each requirement of the project and lists (1) the requirement text (2) the sections of the code that implement it, and (3) the sections of the code that test it.
- I think that the automatic generation of updates to requirements documents (and potentially trace matrices) is appealing for commercial medical device development, and could be a useful tool in its own right.
minus The Importance of Requirements by Peter Kazanzides on 09-09-2005 for revision #1
starstarstarstarstar expertise: 4 sensitivity: 4.5
yellow
Summary:
This paper presents some best practices and a method for requirements capture during agile software development of the IGSTK toolkit.

Hypothesis:
One hypothesis is that requirements for a medical software toolkit can be captured during development (as they emerge).

Evidence:
Not applicable

Open Science:
The paper adheres to the concept of open science quite well. IGSTK source code is freely available. Some of the developer documentation requires a login and password. The nightly generated requirements are also freely available on the web site. I would have liked to see the guidelines for defining requirements (for example, why is a requirement numbered REQ 06.02.13?) as well as the scripts that are used for extracting the requirements from the bug tracker. If done well, this could be as useful to the community as the IGSTK software itself (for example, CMake was developed to support ITK development and is a useful tool on its own).

Reproducibility:
Not really applicable. It should be possible to reproduce the requirements generation if the scripts were publically available.

Use of Open Source Software:
Yes, the authors use quite a bit of open source software packages (ITK, VTK, FLTK) and development tools (CMake, Dart, CVS, PHPBugTracker) and extoll their virtues appropriately.

Open Source Contributions:
IGSTK is a work in process, so I have not yet tried it though I plan to use it in the future. I am not sure if I will use the requirements capture method -- that depends on how much it evolves.

Code Quality:
Not applicable. This paper was not about the code, but about the best practices and requirements definition.

Applicability to other problems:
The development process identified in this paper is applicable to nearly every medical software development effort, especially if clinical use is anticipated.

Suggestions for future work:
The problem of capturing requirements and maintaining traceability (and consistency) between requirements, software implementation and testing is of critical importance. The current solution of using the bug tracker is a good start, but much more could be done. The nightly-generated requirements document is just a sorted list (based on the requirement number, which is somehow assigned by the programmer) and is not as easy to read as a typical manually-created requirements document. In my opinion, it would be nice to have a hyperlinked traceability matrix in which you can easily navigate between requirement, source code implementation, test procedure and test result.

Requests for additional information from authors:
I would like more information about the way in which the requirements are numbered.

Additional Comments:
I am an advisor to this project and am listed in the Acknowledgments.
Add a new review
Quick Comments


Resources
backyellow
Download All

Statistics more
backyellow
Global rating: starstarstarstarstar
Review rating: starstarstarstarstar [review]
Code rating:
Paper Quality: plus minus

Information more
backyellow
Export citation:

Share
backyellow
Share

Linked Publications more
backyellow
Confidence Connected Segmentation of the Lateral Ventricles Confidence Connected Segmentation of the Lateral Ventricles
by Radin P.
An Architecture Validation Toolset for Ensuring Patient Safety in an Open Source Software Toolkit... An Architecture Validation Toolset for Ensuring Patient Safety in an Open Source Software Toolkit...
by Gary K., Kokoori S., David B., Otoom M., Blake M.B., Cleary K.

View license
Loading license...

Send a message to the author
main_flat
ISSN 2327-770X
Powered by Midas