Team:Groningen/Project Plan/Tools and Documentation

From 2009.igem.org

(Difference between revisions)
(Referred to project plan.)
(Human Practice)
 
(31 intermediate revisions not shown)
Line 1: Line 1:
-
[[Category:Team:Groningen/Disciplines/Configuration_and_Change_Management|Configuration_Management_Plan]]
+
{{Team:Groningen/Project_Plan/Header}}
-
[[Category:Team:Groningen/Roles/Configuration_Manager|Configuration_Management_Plan]]
+
[[Category:Team:Groningen/Disciplines/Configuration_and_Change_Management|Tools and Documentation]]
-
[[Category:Team:Groningen/Roles/Facility_Manager|Configuration_Management_Plan]]
+
[[Category:Team:Groningen/Roles/Configuration_Manager|Tools and Documentation]]
-
==Introduction==
+
[[Category:Team:Groningen/Roles/Facility_Manager|Tools and Documentation]]
-
[[Team:Groningen|Our project]] produces [[Team:Groningen/Project_Plan#Deliverables|many artifacts]], this [http://www.upedu.org/upedu/process/artifact/ar_cmpln.htm Configuration Management Plan] details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it?
+
-
===References - NEW===
+
[[Team:Groningen|Our project]] produces [[Team:Groningen/Project_Plan#Deliverables|many artifacts]], this [http://www.upedu.org/upedu/process/artifact/ar_cmpln.htm Configuration Management Plan] (called Tools and Documentation to avoid a lot of jargon) details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it?
-
[This subsection provides a complete list of all documents referenced elsewhere in the Configuration Management Plan. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
+
-
===Overview - NEW===
+
Basically anyone may change anything at any time for any reason, and the Configuration Manager keeps an eye on how (and how much) the Wiki and the SVN repository are used. He also writes this document (assisted by the Facility Manager(s) and others for lab-specific parts).
-
[This subsection describes what the rest of the Configuration Management Plan contains and explains how the document is organized.]
+
-
==Configuration Management==
+
<html><style type="text/css">
-
===Organization, Responsibilities, and Interfaces - TODO===
+
.wetwork { color: green; }
-
[Describe who is going to be responsible for performing the various Configuration Management (CM) activities described in the CM Process Discipline.]
+
</style></html>
-
We have the following [[:Category:Team:Groningen/Disciplines/Configuration_and_Change_Management|Configuration (and Change) Management]] related activities:
+
==Tools, Environment, and Infrastructure==
-
 
+
===Modelling===
-
*Write Configuration Management Plan: [[:Category:Team:Groningen/Roles/Configuration_Manager|Configuration Manager]]
+
<blockquote>
-
*Monitor and Report Configuration Status: [[:Category:Team:Groningen/Roles/Configuration_Manager|Configuration Manager]]
+
Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle.
-
*Change and Deliver Configuration Items
+
-
**Make Changes: [[:Category:Team:Groningen/Roles|Any Role]]
+
-
**Create Workspaces: [[:Category:Team:Groningen/Roles|Any Role]], [[:Category:Team:Groningen/Roles/Integrator|Integrator]]
+
-
**Create Baselines: [[:Category:Team:Groningen/Roles/Integrator|Integrator]]
+
-
*Manage Change Requests
+
-
**Submit/update Change Request: [[:Category:Team:Groningen/Roles|Any Role]]
+
-
**Review Change Request: [[:Category:Team:Groningen/Roles/Change_Control_Manager|Change Control Manager]]
+
-
**Confirm Duplicate/Rejected Change Request: [[:Category:Team:Groningen/Roles/Change_Control_Manager|Change Control Manager]]
+
-
 
+
-
TODO: Verify and detail activities. Add links to activities/concepts (workspaces, baselines, change requests).
+
-
 
+
-
===Tools, Environment, and Infrastructure - NEW===
+
-
[Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle.
+
Describe the tools and procedures required used to version control configuration items generated throughout the project or product lifecycle.
Describe the tools and procedures required used to version control configuration items generated throughout the project or product lifecycle.
Line 39: Line 23:
*anticipated size of product data
*anticipated size of product data
*distribution of the product team
*distribution of the product team
-
*physical location of servers and client machines]
+
*physical location of servers and client machines
-
 
+
</blockquote>
-
TODO: For dry work
+
-
 
+
-
TODO: For wet work
+
-
 
+
-
==The Configuration Management Program - NEW==
+
-
===Configuration Identification - NEW===
+
-
====Identification Methods - TODO====
+
-
[Describe how project or product artifacts are to be named, marked, and numbered. The identification scheme needs to cover hardware, system software, Commercial-Off-The-Shelf (COTS) products, and all application development artifacts listed in the product directory structure; for example, plans, models, components, test software, results and data, executables, and so on. ]
+
-
 
+
-
Currently covered in the [[Team:Groningen/Project_Plan#ConfigurationManagement|project plan]].
+
-
 
+
-
TODO: Perhaps put the information here, to get a more coherent document.
+
-
 
+
-
====Product directory structure (Project Repository) - NEW====
+
-
[The Product Directory Structure serves a logically nested placeholder for all versionable product-related artifacts.  The Product Directory Structure is a placeholder framework and provides a navigational map to all project related artifacts.  Map your product directory structure using a structured text hierarchy or use a screenshot, if available, of your directories environment]
+
-
====Workspaces - NEW====
+
Most documents are created on the Wiki, which has built-in version control features (a revision history, including comments). For Google Docs the same is true. Our network drive does NOT have version control and should not be used for documents that have to be modified (much). For storing/exchanging Matlab code we will use [http://subversion.tigris.org/ Subversion] in combination with [http://code.google.com/ Google Code]. All team members wishing to alter models/write matlab code should follow the following steps to get set up (focusses on Windows):
-
[Explain and describe how development and integration workspace will be created and managed in relation with the project repository.  What are they, where are they, when are they created. Specify any details or conventions your project team will use.]
+
-
====Project Baselines - NEW====
+
# Download and install Matlab R2009a. (Login and click on My Account, both in the upper-right corner, then click on "My Products / Get Licensed Products and Updates".)
-
[Baselines provide an official standard on which subsequent work is based and to which only authorized changes are made.
+
# Download and install TortoiseSVN: http://tortoisesvn.net/downloads
 +
# Checkout the URL https://igemgroningen.googlecode.com/svn/trunk/ using TortoiseSVN by right-clicking in your iGEM directory (in Windows Explorer) and choosing SVN Checkout. Note that you will have to supply the password that can be found on http://code.google.com/hosting/settings.
-
Describe at what points during the project or product lifecycle the baselines are to be established. The most common baselines would be at the end of each of the Inception, Elaboration, Construction, and Transition phases. Baselines could also be generated at the end of iterations within the various phases or even more frequently.
+
Whenever you want to make changes to some of the files in the repository, first update all files by choosing SVN Update from the right-click menu in Windows Explorer (this will download any new changes from others), then make your changes, and finish by committing (again through the right-click menu). Do not forget to supply a commit message explaining the changes.
-
Describe who authorizes a baseline and what goes into it.]
+
Also, in case of conflicts in a Simbiology project you are in trouble (this happens when two people update/change/commit a file at the same time). Unfortunately Mathworks chose to save their projects as one big compressed file, which makes it extremely hard to compare two versions of a project, let alone resolve conflicts. Using [http://winmerge.org/ WinMerge] (with the 7-Zip plugin) these project files can be compared, but you still can't resolve conflicts. So, please stick to one model per project and try to avoid conflicts. If a conflict does occur, contact Jasper for help in resolving it.
-
===Configuration and Change Control - NEW===
+
A list of programs that support SBML and there respective capabilities are here [http://sbml.org/SBML_Software_Guide]./SBML_Software_Matrix
-
====Change Request Processing and Approval - NEW====
+
-
[Describe the process by which problems and changes are submitted, reviewed, and dispositioned.]
+
-
====Change Control Board (CCB) - NEW====
+
Finally, team members that do '''NOT''' write code can checkout the models using TortoiseSVN in the same way as described above and file issues in the [http://code.google.com/p/igemgroningen/issues/list issue list].
-
[Describe the CCB membership and the procedures for processing change requests and approvals to be followed by the CCB.]
+
-
===Configuration Status Accounting - NEW===
+
===Wet Work===
-
====Project Media Storage and Release Process - NEW====
+
*Tools:
-
[Describe retention policies, and the back-up, disaster, and recovery plans. Also describe how the media is to be retained—online, offline, media type, and format.
+
**Ligation ratio: Cloning Tool 6.0 (ask Frans/Sven)
 +
**List of used lab tools (and from whom we got them) can be found on GoogleDocs (in Dutch): Lab benodigdheden
 +
*Environment:
 +
**Lab room D113 in Haren
 +
*Infrastructure:
 +
**Archives: Binders for primer sheets, Articles on the subprojects
 +
**Databases used are [http://openwetware.org/wiki/Main_Page OpenWetWare], [http://www.partsregistry.org/Main_Page Part], [http://partsregistry.org/cgi/partsdb/pgroup.cgi?pgroup=iGEM2009&group=Groningen Sandbox],[http://www.ncbi.nlm.nih.gov/pubmed/ Pubmed]
-
Archives show their value in times of re-use or disaster. As such, archives need to be done regularly and at major and minor milestones. Describe your practices and approaches on how you ensure that project software and related assets (master documents) are backed-up, catalogued and transferred to designated storage sites
+
===Human Practice===
 +
A survey was made and executed. The consideration and results can be found [https://2009.igem.org/Team:Groningen/Ethics/Survey here]
-
The release process describes what is in the release, who it is for, and whether there are any known problems and any installation instructions.]
+
==Documentation==
 +
====Identification Methods====
 +
Private files are stored in a central repository (currently the Y-drive or Google Docs). Agendas and minutes are stored in their respective folders under the date of the meeting in yyyy-mm-dd format to enable easy sorting. Other documents should be named according to the UPEDU standard as much as possible and prefixed by a short abbreviation in brackets (which makes it easy to reference them), for example [PP] for this document.
-
====Reports and Audits - NEW====
+
All documents that are not necessarily private should be placed on the Wiki under the name of the [http://www.upedu.org/upedu/process/artifact/ovu_arts.htm relevant artifact] (also see the [http://www.upedu.org/upedu/process/artifact/tmpl_cs/ovu_tmplcs.htm list of templates]), always prefixed by Team:Groningen (for example [[Team:Groningen/Vision]]). Images can also be uploaded to the Wiki to accompany texts, but the Wiki should not be used as a general means of exchanging files (for this the Y-drive, Google Docs or Google Groups are more suitable).
-
[Describe the content, format, and purpose of the requested reports and configuration audits.
+
-
Reports are used to assess the “quality of the product” at any given time in the project or product lifecycle. Reporting on defects based on change requests may provide some useful quality indicators and, thereby, alert management and developers to particularly critical areas of development. Defects are often classified by criticality (high, medium, and low) and could be reported on the following basis:
+
Finally note that any changes to documents on the Wiki should make use of the Summary field below the large edit text box to describe the change (it would be nice if you tick the "This is a minor edit" checkbox if you're making small tweaks, like correcting a spelling mistake). These descriptions can be long, or as short as one word, depending on the situation. Afterwards it should be possible to reasonably easily get an overview of how the document evolved, and to look up specific changes. For documents not on the Wiki a Revision History should be present at the top of the document.
-
*Aging (Time-based Reports): How long have defects of the various kinds been open? What is the “lag time’’ between when defects are found in the lifecycle and when they are fixed?
+
===={{anchor|DirectoryStructure}} Master of Lists====
-
*Distribution (Count Based Reports): How many defects are there in the various categories by owner, priority or state of fix?
+
{{done}}: Anything about lab stuff (in green!)
-
*Trend (Time-related and Count-related Reports): What is the cumulative number of defects found and fixed over time? What is the rate of defect discovery and fix? What is the “quality gap” in terms of open as opposed to closed defects? What is the average defect resolution time?]
+
-
==Milestones - NEW==
+
*Our wiki
-
[Identify the internal and customer milestones related to the project or product CM effort. This section includes details on when the Configuration Management Plan itself is to be updated.]
+
**[[:Category:Team:Groningen]] contains all our categories (corresponding to some of the UPEDU disciplines).
 +
***[[:Category:Team:Groningen/Disciplines]] contains all our disciplines.
 +
***[[:Category:Team:Groningen/Roles]] contains all our roles.
 +
**[[Team:Groningen]] is our main page, http://www.igemgroningen.com/ redirects to this.
 +
***All our documents are on the Wiki, where possible. Each document is a subpage of the main page, unless it is itself part of another document, then it is a subpage of that document. For example: [[Team:Groningen/Project_Plan]] and [[Team:Groningen/Project_Plan/Risk_List]].
 +
***Note that each document should be preceded by a list of related categories (see this document for example).
 +
**User:... (see, for example, [[User:Verhoeven1981|Michael's user page]])
 +
***Some basic information
 +
***Optionally a photograph
 +
***Categories for each of the roles he/she has.
 +
**Any JavaScript on the Wiki should (as much as possible/desirable) be written in a separate page and included using a script tag with a href attribute referencing the raw version of the page (see [[:Template:Team:Groningen/Header]] for an example), this avoids problems with ampersands, keeps the pages a bit cleaner and makes it possible for browsers to cache long scripts. When it makes sense the page should be a subpage of the page it is used in.
 +
**[https://2009.igem.org/Team:Groningen/Parts Parts list]: <span class="wetwork">List of glycerol stocks in -80 freezer C from MolGen, also the Quality control by PCR and Restriction analysis should be filled in here.</span>
-
==Training and Resources - NEW==
+
*Subversion repository
-
[Describe the software tools, personnel, and training required to implement the specified CM activities.]
+
**The trunk is at https://igemgroningen.googlecode.com/svn/trunk/
 +
**[https://igemgroningen.googlecode.com/svn/trunk/glucose/ /trunk/glucose/]
 +
***The models for the glucose sensing idea (which we're not pursuing any further).
 +
**[https://igemgroningen.googlecode.com/svn/trunk/buoyant/ /trunk/buoyant/]
 +
***[[Team:Groningen/Modelling|Models]] (mostly .sbproj files) for the [[Team:Groningen/Vision|buoyant bacteria]].
-
6.                 External development environment
+
*Google Docs
-
[Describe how software developed outside of the project environment will be incorporated.]
+
**Unfortunately Google Docs does not allow sharing of a directory structure.
 +
**Contact Information for 3rd parties.
 +
**Minutes and agendas.
 +
**Availability of team members.
 +
**Balance sheet: estimated costs for tickets, hotel, lab etc and estimated sponsoring.
 +
**<span class="wetwork">Primers: list with ordering date and concentration of the primers when they did arrive (also for oligo's).
 +
**<span class="wetwork">Chemicals / Materials taken from MolGen: list with all chemicals, materials, enzymes taken from MolGen
 +
**<span class="wetwork">Fridge/Freezer Stock list: list with different sheets for general stocks in the fridge and freeze, additionally a sheet for -20 freezer stocks of all labworkers.
 +
**<span class="wetwork">Lab tools: list of all the stuff (machines, pipettes, etc) we use from microbiology and practicum pool (Labbenodigdheden).
 +
*Y-drive
 +
**The transfer documents.
 +
**Literature?
 +
**Miscellaneous files
 +
{{Team:Groningen/Project_Plan/Footer}}

Latest revision as of 18:45, 21 October 2009

Igemhomelogo.png
Risk List Tools and Documentation Inception Elaboration Construction Transition
1 2 1 2 1 2 3 1 2
apr. 20 may 18 jun. 01 27 28 29 30 31 32 33 34 35 okt. 15
Our project produces many artifacts, this Configuration Management Plan (called Tools and Documentation to avoid a lot of jargon) details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it?

Basically anyone may change anything at any time for any reason, and the Configuration Manager keeps an eye on how (and how much) the Wiki and the SVN repository are used. He also writes this document (assisted by the Facility Manager(s) and others for lab-specific parts).

Tools, Environment, and Infrastructure

Modelling

Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle. Describe the tools and procedures required used to version control configuration items generated throughout the project or product lifecycle. Issues involved in setting up the CM environment include:
  • anticipated size of product data
  • distribution of the product team
  • physical location of servers and client machines

Most documents are created on the Wiki, which has built-in version control features (a revision history, including comments). For Google Docs the same is true. Our network drive does NOT have version control and should not be used for documents that have to be modified (much). For storing/exchanging Matlab code we will use Subversion in combination with Google Code. All team members wishing to alter models/write matlab code should follow the following steps to get set up (focusses on Windows):

  1. Download and install Matlab R2009a. (Login and click on My Account, both in the upper-right corner, then click on "My Products / Get Licensed Products and Updates".)
  2. Download and install TortoiseSVN: http://tortoisesvn.net/downloads
  3. Checkout the URL https://igemgroningen.googlecode.com/svn/trunk/ using TortoiseSVN by right-clicking in your iGEM directory (in Windows Explorer) and choosing SVN Checkout. Note that you will have to supply the password that can be found on http://code.google.com/hosting/settings.

Whenever you want to make changes to some of the files in the repository, first update all files by choosing SVN Update from the right-click menu in Windows Explorer (this will download any new changes from others), then make your changes, and finish by committing (again through the right-click menu). Do not forget to supply a commit message explaining the changes.

Also, in case of conflicts in a Simbiology project you are in trouble (this happens when two people update/change/commit a file at the same time). Unfortunately Mathworks chose to save their projects as one big compressed file, which makes it extremely hard to compare two versions of a project, let alone resolve conflicts. Using WinMerge (with the 7-Zip plugin) these project files can be compared, but you still can't resolve conflicts. So, please stick to one model per project and try to avoid conflicts. If a conflict does occur, contact Jasper for help in resolving it.

A list of programs that support SBML and there respective capabilities are here [2]./SBML_Software_Matrix

Finally, team members that do NOT write code can checkout the models using TortoiseSVN in the same way as described above and file issues in the issue list.

Wet Work

  • Tools:
    • Ligation ratio: Cloning Tool 6.0 (ask Frans/Sven)
    • List of used lab tools (and from whom we got them) can be found on GoogleDocs (in Dutch): Lab benodigdheden
  • Environment:
    • Lab room D113 in Haren
  • Infrastructure:

Human Practice

A survey was made and executed. The consideration and results can be found here

Documentation

Identification Methods

Private files are stored in a central repository (currently the Y-drive or Google Docs). Agendas and minutes are stored in their respective folders under the date of the meeting in yyyy-mm-dd format to enable easy sorting. Other documents should be named according to the UPEDU standard as much as possible and prefixed by a short abbreviation in brackets (which makes it easy to reference them), for example [PP] for this document.

All documents that are not necessarily private should be placed on the Wiki under the name of the relevant artifact (also see the list of templates), always prefixed by Team:Groningen (for example Team:Groningen/Vision). Images can also be uploaded to the Wiki to accompany texts, but the Wiki should not be used as a general means of exchanging files (for this the Y-drive, Google Docs or Google Groups are more suitable).

Finally note that any changes to documents on the Wiki should make use of the Summary field below the large edit text box to describe the change (it would be nice if you tick the "This is a minor edit" checkbox if you're making small tweaks, like correcting a spelling mistake). These descriptions can be long, or as short as one word, depending on the situation. Afterwards it should be possible to reasonably easily get an overview of how the document evolved, and to look up specific changes. For documents not on the Wiki a Revision History should be present at the top of the document.

Master of Lists

DONE: Anything about lab stuff (in green!)

  • Our wiki
    • Category:Team:Groningen contains all our categories (corresponding to some of the UPEDU disciplines).
    • Team:Groningen is our main page, http://www.igemgroningen.com/ redirects to this.
      • All our documents are on the Wiki, where possible. Each document is a subpage of the main page, unless it is itself part of another document, then it is a subpage of that document. For example: Team:Groningen/Project_Plan and Team:Groningen/Project_Plan/Risk_List.
      • Note that each document should be preceded by a list of related categories (see this document for example).
    • User:... (see, for example, Michael's user page)
      • Some basic information
      • Optionally a photograph
      • Categories for each of the roles he/she has.
    • Any JavaScript on the Wiki should (as much as possible/desirable) be written in a separate page and included using a script tag with a href attribute referencing the raw version of the page (see Template:Team:Groningen/Header for an example), this avoids problems with ampersands, keeps the pages a bit cleaner and makes it possible for browsers to cache long scripts. When it makes sense the page should be a subpage of the page it is used in.
    • Parts list: List of glycerol stocks in -80 freezer C from MolGen, also the Quality control by PCR and Restriction analysis should be filled in here.
  • Google Docs
    • Unfortunately Google Docs does not allow sharing of a directory structure.
    • Contact Information for 3rd parties.
    • Minutes and agendas.
    • Availability of team members.
    • Balance sheet: estimated costs for tickets, hotel, lab etc and estimated sponsoring.
    • Primers: list with ordering date and concentration of the primers when they did arrive (also for oligo's).
    • Chemicals / Materials taken from MolGen: list with all chemicals, materials, enzymes taken from MolGen
    • Fridge/Freezer Stock list: list with different sheets for general stocks in the fridge and freeze, additionally a sheet for -20 freezer stocks of all labworkers.
    • Lab tools: list of all the stuff (machines, pipettes, etc) we use from microbiology and practicum pool (Labbenodigdheden).
  • Y-drive
    • The transfer documents.
    • Literature?
    • Miscellaneous files
                    
LogoIGEMGroningenBar.png
                    
            The City of Talent