Team:Groningen/Project Plan/Tools and Documentation

From 2009.igem.org

Revision as of 08:56, 5 August 2009 by Jaspervdg (Talk | contribs)

Igemhomelogo.png
Our project produces many artifacts, this 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?

Configuration Management

Organization, Responsibilities, and Interfaces

We have the following Configuration (and Change) Management related activities:

Basically this means that anyone may change anything at any time for any reason, and that 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) for lab-specific parts).

At this moment we don't have an Integrator, and it is not certain we will need baselines.

Tools, Environment, and Infrastructure

Modeling

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:
    • Archives: Binders for primer sheets, Articles on the subprojects
    • Databases used are OpenWetWare, Part, Sandbox(and others?)

The Configuration Management Program

Configuration Identification

Identification Methods

[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 project plan.

TODO: Perhaps put the information here, to get a more coherent document.

Master of Lists

[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]

TODO: Anything missing? Wrong?

TODO: Something about programming code should be added.

DONE: Anything about lab stuff (TODO 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.
    • 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.
  • Y-drive
    • The transfer documents.
    • Literature?
    • Miscellaneous files