Software development process

From IGSTK

Outline

1. Introduction
   1. Motivate need and use of lightweight methods.
   2. Highlight safety-critical nature of the application domain.
2. IGSTK Best Practices
   1. Use our top 10 list as a means of describing our philosophy up front
   2. Intro rest of chapter. We have a collection of practices you must use if you are an IGSTK component developer, and should use if you are an IGSTK applications developer.
   3. You are only as safe and robust as your weakest component.
3. Developer Practices
   1. Code conventions
      1. Source documentation using Doxygen
      2. Conventions document should go in an appendix
      3. Describe use of kwStyle
   2. Requirements Traceability - refer to BB's chapter
   3. Code Reviews
   4. Communication - perhaps this should go at the end?
      1. Wiki
      2. Mailing list
4. Configuration Management (CM) practices
   1. Establishing a codeline policy
   2. Whether to use a sandbox
5. Build and Release Management - Q: do we expect app developers to put code in the IGSTK tree or in their own tree and use CMake to refer to IGSTK?
   1. IGSTK Release Cycle
   2. use of CMake
   3. Dependencies on ITK, VTK, etc. - did we ever build in compile-time safety against the proper version?
   4. Deploying IGSTK
      1. emphasis on compile-time safety over run-time configuration options
      2. How to read an IGSTK logfile
6. Continuous Testing
   1. Brief intro on philosophy
      1. pseudo test-driven development (TDD) approach of IGSTK
      2. emphasis on code coverage
   2. use of DART - Q: how will application developers use DART? do we recommend they set up their own?
      1. Goal of 100 percent code coverage
      2. Use of valgrind dynamic analysis
      3. Importance of portability Q: what if they are not portable? compile-time checks?
      4. Validation of state machine (if used by app)