Difference between revisions of "SDIWG:Software Engineering At MAGNet"

From NAMIC Wiki
Jump to: navigation, search
Line 6: Line 6:
 
:# '''Collection of business requirements''': an initial meeting is arranged with the investigator whose prototype is slated for integration. During the meeting high level requirements are collected, outlining the intended functionality of the integrated component. Such a meeting usually involves (i) a demo of geWorkbench, (ii) an overview presentation outlining the science behind the investigator's prototype, (iii) a demo of the prototype, and (iv) a brainstorming session aimed at identifying the most meaningful manner to integrate the prototype into geWorkbench so that the prototype leverages as much as possible of the functionality already present in geWorkbench.
 
:# '''Collection of business requirements''': an initial meeting is arranged with the investigator whose prototype is slated for integration. During the meeting high level requirements are collected, outlining the intended functionality of the integrated component. Such a meeting usually involves (i) a demo of geWorkbench, (ii) an overview presentation outlining the science behind the investigator's prototype, (iii) a demo of the prototype, and (iv) a brainstorming session aimed at identifying the most meaningful manner to integrate the prototype into geWorkbench so that the prototype leverages as much as possible of the functionality already present in geWorkbench.
 
:# '''Development of Use case document''':  based on the information collected at the investigator meeting a detailed Use Case requirements document is developed which describes precisely what the user interface will look like and how users will interact with it. The Use Case document is subject to review and approval by the investigator. An example of such a document can be found [[Media:CNKB_UC.pdf | here]].
 
:# '''Development of Use case document''':  based on the information collected at the investigator meeting a detailed Use Case requirements document is developed which describes precisely what the user interface will look like and how users will interact with it. The Use Case document is subject to review and approval by the investigator. An example of such a document can be found [[Media:CNKB_UC.pdf | here]].
:# '''Development of user interface/computational service''': based on the requirements laid out in the use case document, the development team (a) develops the user interface for the integrated version of the investigator tool, and (2) ports any associated computate server to the grid-enabled server framework used by geWorkbench (which is based on the caGrid software, https://cabig.nci.nih.gov/workspaces/Architecture/caGrid, a grid middleware layer developed by the caBIG initiative). Unit tests are an integral part of the development process and are run automatically on a nightly basis.
+
:# '''Development of user interface/computational service''': based on the requirements laid out in the use case document, the development team (i) develops the user interface for the integrated version of the investigator tool, and (ii) ports any associated compute server to the grid-enabled server framework used by geWorkbench (which is based on the caGrid software, https://cabig.nci.nih.gov/workspaces/Architecture/caGrid, a grid middleware layer developed in the context of the caBIG initiative). Unit tests are an integral part of the development process and are run automatically on a nightly basis.
:# '''System Testing''': After the prototype in integrated a formal integration and system testing cycle ensues. Our group uses a formal testing process based on detailed test scripts whose execution status is tracked in a custom database we have developed for this purpose. In this database, failed scripts are linked to their associated defect reports within our defect management system, http://wiki.c2b2.columbia.edu/mantis/.
+
:# '''System Testing''': After the prototype in integrated, an integration and system testing cycle is performed. Our group uses a formal testing process based on detailed test scripts whose execution status is tracked in a custom database we have developed for this purpose. In this database, failed scripts are linked to their associated defect reports within our defect management system, http://wiki.c2b2.columbia.edu/mantis/.
 
:# '''Documentation''': The final step in the development process is the generation of detailed end-user documentation, in the form of on-line help, tutorials, end-user guides and training slides. Links to these materials are available at: http://wiki.c2b2.columbia.edu/workbench/index.php/Project_Documentation.  
 
:# '''Documentation''': The final step in the development process is the generation of detailed end-user documentation, in the form of on-line help, tutorials, end-user guides and training slides. Links to these materials are available at: http://wiki.c2b2.columbia.edu/workbench/index.php/Project_Documentation.  
  

Revision as of 22:30, 19 May 2007

Home < SDIWG:Software Engineering At MAGNet

Process

The software development process in MAGNet typically takes place in 2 phases:

  • Prototype tools are developed and field-tested at various investigator labs in the context of Core 1, 2 and 3 activities. These tools are usually command line versions, coded in an assortment of languages (C, C++, Perl, etc) and/or computational environments (MATLAB, R). In the majority of cases, analysis results are represented as text files that are either inspected with text editors or are transformed (through custom programs) to properly formatted inputs for downstream analysis/visualization tools.
  • When prototypes have reached a satisfactory level of maturity the software engineering group takes over the task of integrating them into the Center's bioinformatics platform, geWorkbench, http://www.geworkbench.org. Operationally, each integration activity is carried out following a number of steps deriving from a standard software life cycle process:
  1. Collection of business requirements: an initial meeting is arranged with the investigator whose prototype is slated for integration. During the meeting high level requirements are collected, outlining the intended functionality of the integrated component. Such a meeting usually involves (i) a demo of geWorkbench, (ii) an overview presentation outlining the science behind the investigator's prototype, (iii) a demo of the prototype, and (iv) a brainstorming session aimed at identifying the most meaningful manner to integrate the prototype into geWorkbench so that the prototype leverages as much as possible of the functionality already present in geWorkbench.
  2. Development of Use case document: based on the information collected at the investigator meeting a detailed Use Case requirements document is developed which describes precisely what the user interface will look like and how users will interact with it. The Use Case document is subject to review and approval by the investigator. An example of such a document can be found here.
  3. Development of user interface/computational service: based on the requirements laid out in the use case document, the development team (i) develops the user interface for the integrated version of the investigator tool, and (ii) ports any associated compute server to the grid-enabled server framework used by geWorkbench (which is based on the caGrid software, https://cabig.nci.nih.gov/workspaces/Architecture/caGrid, a grid middleware layer developed in the context of the caBIG initiative). Unit tests are an integral part of the development process and are run automatically on a nightly basis.
  4. System Testing: After the prototype in integrated, an integration and system testing cycle is performed. Our group uses a formal testing process based on detailed test scripts whose execution status is tracked in a custom database we have developed for this purpose. In this database, failed scripts are linked to their associated defect reports within our defect management system, http://wiki.c2b2.columbia.edu/mantis/.
  5. Documentation: The final step in the development process is the generation of detailed end-user documentation, in the form of on-line help, tutorials, end-user guides and training slides. Links to these materials are available at: http://wiki.c2b2.columbia.edu/workbench/index.php/Project_Documentation.

geWorkbench is an open-source platform and we encourage and welcome code contributions by the community. To facilitate such contributions we have made the entire code base freely available to everyone through our community development project site, http://gforge.nci.nih.gov/projects/geworkbench/, registered with the NCI GForge project. This site enables us to leverage the infrastructure support that GForge offers to collaborative development projects, including access to a CVS server, streamlined setup of mailing lists and user-forums, posting software releases, etc.

License

At present, geWorkbench in made available under the licensing terms stated at http://wiki.c2b2.columbia.edu/workbench/index.php/GeWorkbench_License. We are currently in the process of modularizing our licensing , in order to accommodate the needs of different labs/tools.

Contact

The software engineering group at MAGNet is managed by Aris Floratos.