SDIWG:Software Engineering At MAGNet - Revision history

Aris: /* Contact */

2007-05-19T22:38:07Z

Contact

Aris: /* Contact */

2007-05-19T22:35:51Z

Contact

Aris: /* Contact */

2007-05-19T22:35:37Z

Contact

Aris: /* Process */

2007-05-19T22:30:22Z

Process

Aris: /* Process */

2007-05-19T22:26:39Z

Process

Aris: /* Process */

2007-05-19T22:21:17Z

Process

Aris at 22:38, 18 May 2007

2007-05-18T22:38:07Z

Aris at 22:32, 18 May 2007

2007-05-18T22:32:42Z

New page

__TOC__
==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:
## '''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 at http://magnet.c2b2.columbia.edu/AnnualReport/Y2/CNKB_UC.pdf.
## '''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.
## '''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/.
## '''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.

==Contact==
The software engineering group at MAGNet is managed by [mailto:%66%6C%6F%72%61%74%6F%73%40%63%32%62%32%2E%63%6F%6C%75%6D%62%69%61%2E%65%64%75 Aris Floratos].

← Older revision		Revision as of 22:38, 19 May 2007
Line 16:		Line 16:

	==Contact==		==Contact==
−	The software engineering group at MAGNet is managed by Aris Floratos (~~floratos at c2b2 dot columbia dot edu~~).	+	The software engineering group at MAGNet is managed by Aris Floratos (floratos@c2b2.columbia.edu).

← Older revision		Revision as of 22:35, 19 May 2007
Line 16:		Line 16:

	==Contact==		==Contact==
−	The software engineering group at MAGNet is managed by Aris Floratos (floratos at c2b2 dot columbia dot edu.	+	The software engineering group at MAGNet is managed by Aris Floratos (floratos at c2b2 dot columbia dot edu).

← Older revision		Revision as of 22:35, 19 May 2007
Line 16:		Line 16:

	==Contact==		==Contact==
−	The software engineering group at MAGNet is managed by ~~[mailto:%66%6C%6F%72%61%74%6F%73%40%63%32%62%32%2E%63%6F%6C%75%6D%62%69%61%2E%65%64%75~~ Aris Floratos].	+	The software engineering group at MAGNet is managed by Aris Floratos (floratos at c2b2 dot columbia dot edu.

@@ 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.
 :# '''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.

@@ Line 5: / Line 5: @@
 * 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:
 :# '''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 at http://magnet.c2b2.columbia.edu/AnnualReport/Y2/CNKB_UC.pdf.
+:# '''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.
 :# '''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/.

@@ Line 4: / Line 4: @@
 * 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:
-## '''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 at http://magnet.c2b2.columbia.edu/AnnualReport/Y2/CNKB_UC.pdf.
+:# '''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 at http://magnet.c2b2.columbia.edu/AnnualReport/Y2/CNKB_UC.pdf.
-## '''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 (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.
-## '''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 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/.
-## '''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.
 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.

@@ Line 11: / Line 11: @@
 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.
 ==Contact==
 The software engineering group at MAGNet is managed by [mailto:%66%6C%6F%72%61%74%6F%73%40%63%32%62%32%2E%63%6F%6C%75%6D%62%69%61%2E%65%64%75 Aris Floratos].