Minutes of Review Board Meeting

IGSTK Review Board Meeting Minutes Year One Review Meeting Compiled by Kevin Cleary on 12 Nov 2005

Attendees

Included Polaris Vicra Tracker, Abdominal Phantom, and User Interface.
This was a big milestone for the project and showed we have working code
It was discussed that applications should drive the project in the future
The tracker code does support the foot pedal which will generate an event – Patrick should add this to the code for selecting the fiducial points – this is a very common feature in commercial image-guided systems
There was some discussion here – someone stated that the example applications with the state machine framework would be the outcome of the project (note later discussion on application framework)
It seemed like applications should be the goal of the project – a secondary goal would be to make the components reusable – David note that error handling would be more tied up at the application level
Stephen noted that it is important to have value added in the whole application – logging, error handling, validation, etc.
Kevin Gary suggested making an application side API
Peter noted that he liked the idea of a framework rather than a toolkit – will be easier to enforce the design

Categories of components
- Infrastructure: state machine, time stamp, pulse generator, events, transforms, logger
- Geometry and representations: spatial objects
- Viewers
- Trackers
- Images and readers
There are some issues with the pulse generator and timing – this was also discussed in the follow-up meeting on Friday
It was noted that we were not testing on any 64 bit machines and this should be addressed
We have good code coverage at above 90% (the goal is 100%) but it was suggested that we may want to look down into ITK and VTK coverage or add some tests for these
Question re dynamic analysis: should we get one copy of Purify?

Kevin presented the IGSTK Best Practices (we have eight – we definitely need two more for the book!)
Kevin noted that he is not convinced we are keeping up with requirements
Kevin presented three challenges
- FDA standards are high
- “Completing our homework�? on failure scenarios
- Ensuring our traceability links from requirements to code to validation are complete, consistent, and correct.
Kevin will continue to work on validation tools

Rick started helping with project management in July
Rick noted that we went to a 2 month iteration schedule and that seems to be working well
The iteration process was also documented with the help of Luis
There was some discussion about tagging and branching here – not sure if this was resolved or we need to discuss later
Stephen suggested renaming sandbox to “IGSTK sandbox�? since there is a NA-MIC sandbox and we don’t want to conflict

General agreement that the requirements process as on the Wiki is reasonable
The goal is to move the requirements process in tandem with the coding process
A bigger concern is the organization of requirements – there is no hierarchy
The question was “what are the requirements for?�?. They originally were perhaps for FDA approval, but that does not hold. Peter suggested the requirements are for the developers and not the end user. Kevin suggested that the requirements define the scope of the toolkit.
Julien suggested we do a PHP script to help organize the requirements
It was suggested we start with application requirements and map them onto components and see what is not fulfilled
Terry noted that our end users will dictate requirements in the long run – he also stated that we need a mechanism for requirements to die
Luis noted that good requirements should map to tests

State machine is clearly the defining future of IGSTK and the most difficult to implement
Luis presented some background on state machines, integration of state machines, request action methods, example state diagrams for tracker, pulse generator, and spatial object
For interactions between state machines Luis suggested all communication be by events – it was noted by someone that ITKCommandObservor can be very slow

David suggested a convention for method names (was discussed more on Friday)
There was some discussion of multi-threading and it was decided that we would be single threaded
David suggested using exceptions for error handling was a possibility --- Julien noted that catching these can be slow
Luis was OK with localized exceptions (within a component for example – was discussed more on Friday)
Patrick suggested the idea of pure virtual functions – for every event we preset a callback function in the class; you then have to subclass this class (did I get it right???)

Will noted that there was a lot of value in saying you are rigorously looking at the problem (i.e., the state machine formalism)
Terry suggested that we separate the things that are deterministic from those that are non-deterministic and find out what fits under the state machine model
Peter noted that having some structure in the application is good, but that just because we have this state machine hammer, not everything is a nail