Services: Main | Consulting | Software Research Institute | CCC Shared Resource
SRI Principles
The Software Research Institutes (SRI) mission is to enable the design, implementation, and release of SRI software. The software produced through the SRI will maintain high priority in design, architecture, quality, documentation, and training. This software will meet and exceed current community standards for usability and quality in open source projects, while still remaining focused on interesting research domains relevant to BMI. In providing this type of software certain processes must be in place, which enable agile and rapid, yet high quality, software development. The SRI and its members will not only define, evolve, and embrace the best practices which enable these principles but will educate others on these methodologies.
Practices
One of the most critical aspects to producing useful systems software for biomedical research is the identification, curation, and observation of quality practices by the software's engineers. The Institute's practices will evolve over time, but the following is an initial set based on past experience.
click to show (+)
- Componentized design with plug and play pieces is critical in software systems where change is frequent. Designing against interfaces with formalized contracts enable these systems to be reconfigured and their individual components to be reused in other software systems.
- Continuous integration is a critical practice to quality software in which team members integrate their work daily, and automated builds and testing detect errors and integration failures quickly. learn more
- Automated testing of individual components (unit testing) and integrated components (system testing) in an on going basis throughout the design, development, and production (regression testing) of software are all critical components to providing software systems which are reliable, useful, and contain reusable quality components.
- Simplicity in design and implementation (the simplest design which solves the problem) is a primary goal. Scope creep, over architecting, and intricately complicated systems are more difficult to maintain, change, and reapply to other environments.
- Face to face, team based development works best. Developers should be collocated to the extent possible, leveraging BMI's labs. Project-oriented members not normally working in these areas should attempt to relocate for the duration of the effort.
- In general no member should be working on or more than 2 (or at most 3) projects at a time. While context switching and multi-tasking are crucial skills for members of the department, development of high quality software requires a focused and dedicated effort.
- Iterative development practices will help to enable the software systems to evolve over design, development, and use of a software system. Exhaustive upfront requirements definition is most often not possible when dealing with ongoing research projects as data types, analytical process, and research methodologies will evolve over the course of the project. When developing systems of this nature is it important to use methods of design and development which do not lock a system into hard requirements unless necessary. Developing systems in more agile ways will enable easy and time reducing ways to re-factor and retool a system so that it better suits the needs of its users and evolving research interests.
- Continuous awareness of evolving tools and practices in the community is critical keeping current with the environment which software will be used, and in maximizing the impact of development ('don't reinvent the wheel').
- Documentation is a critical component to creating usable and maintainable software. Technical and user-oriented guides as well as documented public APIs will aid in a software systems maintainability, usability, and ease of refactoring. The use of Wikis to enable public, fluid, and user/community driven documentation is a useful best practice when publishing and editing documentation.
- Use of Integrated Development Environments like Eclipse and IntelliJ are critical to being able to develop effectively in large multi-developer systems software projects. The use of these tools enables rapid refactoring, monitoring of changes in the software, and tools to enable testing and debugging.
- Team ownership of project software requires that all members of a development team are cognizant of all areas of a project and are comfortable modifying and maintaining multiple aspects of a project. Removing the sole ownership of components facilitates better overall understanding of the whole system and decreases the time necessary for multi-component changes.
- Frequent ad-hoc design sessions and code reviews aid in the development of high quality software and reduce the probability of bugs or inadequately scoped components.
Projects
Projects under the Institute may encompass a variety of scopes and durations. While the primary emphasis of the Institute is on the development of high priority infrastructure projects, other smaller research efforts may also be undertaken as long as an end goal of the effort is the release of high quality software. The Institute and its direction will adapt and work with these projects in the best way taking in all the considerations from the customers, departmental vision and direction, and staffing. At its outset, projects under the Institute will consist of only systems software projects. Some current project examples or grant projects with major system software components would be caGrid, CVRG, and IVI middleware. The Institute will provide consulting and training to application projects which wish to leverage the systems software developed by the Institutes. The Institute's projects come from major grant efforts where software is a core component of the set of deliverable.
Project Requirements
In addition to standardization on development practices, the Institute will curate a common set of requirements on the actual software it produces. These requirements will evolve over time, but the following is an initial set based on past experience. Projects wishing to be part of the Institute must follow these practices and have a compelling reason if they wish to use a different set of tools or technologies.
click to show (+)
-
Software Configuration Management (Revision control). Maintaining history of development artifacts over time is critical to successful development practices.
Current Tools: BMI Gforge, CVS, SVN, etc -
Automated build processAll projects must be automatically built with a small set of well-known and common system requirements; elaborate environment requirements are not allowed.
Current Tools: Ant, make, CMake, etc -
Automated testing. The software must be able to be automatically tested, without user interaction. This should be done on an ongoing basis throughout the lifecycle of a project and developers must be notified of failures.
Current Tools: Dart, Cruise Control, etc -
User mailing list. Each software release must have a public mailing list where users and interested parties can post questions. Project developers must monitor and engage participants on this list.
Current Tools: BMI Gforge -
User visible Formal bug/feature tracking. Each software release must have a public tracking system where bugs, issues, and feature requests can be submitted and monitored by users. Project developers must monitor and curate these lists.
Current Tools: BMI Gforge -
Web presence (on BMI site or external site). Each project must have a web presence which can be used to advertise the project to prospective communities and users.
Current Tools: BMI website