Team:Groningen/Project Plan

From 2009.igem.org

Latest revision as of 21:43, 21 October 2009

	The Project The Project WholeSystem Applications Transport Accumulation Metal-sensitive Promoters Gas Vesicles	Modelling Modelling Detailed model Characterization Downloads	HumanPractice HumanPractice safety and security Ethics Vision Survey		Biobricks Biobricks Our registry Submitted Biobricks Used Biobricks	Project Plan UPEDU Project Plan Brainstorm Future Risklist	The Team The Team Pictures Videos contact Acknowledgements	Notebook April M T W T F S S     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 May M T W T F S S         1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 June M T W T F S S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 July M T W T F S S     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 August M T W T F S S           1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 September M T W T F S S   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 October M T W T F S S       1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 November M T W T F S S             1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30		Glossary Literature	[1] Protocols

Judges: Please note this section in particular.

The project plan (known in UPEDU as "Software Development Plan") is meant to hold all information necessary for the management of the project. This includes things like the planning, role assignments, information on resources, etc. This particular project plan applies to the 2009 iGEM project at the University of Groningen.

Project Overview

Project Purpose, Scope, and Objectives

The purpose of the 2009 iGEM Groningen project is to have a great summer, and have fun attending the Jamboree.

Assumptions and Constraints

This plan assumes that we can raise enough funds to acquire all the needed materials, and that the university will supply the necessary facilities (like lab space). These will have to be organized before the start of the summer, as both iGEM and our individual schedules require us to do most of the work during the summer. We assume that we can collect enough data during the summer labwork and modelling to be presented during the iGEM Jamboree in oct/nov 2009.

Our assumptions and constraints were defined in a list of wishes and demands as followed:

Demands

• Labwork is feasible in 3 month with 8 students.
• Modelling feasible in 3 months with 3 students.
• Everyone has to agree with the idea
• Financially feasible with a budget of 31.170,00 euro of which 8000 euros used for labwork.
• A new concept, not yet done before in this way, either the iGEM or in the synthetic biology
• Meets the criteria of iGEM
• Materials have to be attainable, either via the RuG or able to order in.
• Parameters for modelling have to be known, or available or attainable.
• Knowledge about the genes that we are using has to be available.

Wishes

• Not too complicated, not too many genes or gene clusters
• Has to have an application
• Using BioBricks that are easy to obtain, preferable available at the RuG.
• Preferably knowledge on the host, genes and/or end products has to be available at the RuG
• Some students in the team have experience working with the host.
• It is possible to find sponsoring for this project.

Project Deliverables

During the course of this project the following will be delivered:

• An initial idea for a new "machine" in the iGEM sense, including a preliminary feasibility study.
• A detailed specification of the requirements of this machine.
• A detailed design of this "machine", including an analysis of the usage scenarios and results of simulations of computer models of (parts of) this "machine".
• The actual "machine" (consisting of cells)
• A presentation for the jamboree in November.
• A poster for the jamboree in November
• A report of our findings

Planning and requirements for transporters

• Modelling:
  • Import speed
  • Amount
  • Max
• Lab:
  • HmtA
    • Zn/Cu alone
    • B-type ATPase (could be use if there is a ATP shortage?)
  • CitM (probably not used)
    • Divalent ions
    • Citrate around
    • Citrate can bind metals that are already bound.
  • Measurements (both for the "normal" cell and the cell with overexpression of the transporter)
    • Transporter, on/off mechanism, up to what concentration (in the cell) does it still have metal uptake.
    • Measure concentration of metal. difference between begin and end concentrations of metal outside the cell.
    • How fast does it transport metal in/out the cell.
      • Set up tests with (initial) extracellular concentrations of about ¹/₃K (25% of V_max), K (50% of V_max), 3K (75% of V_max) and 10mM (99.7% of V_max, corresponding to extremely polluted water), and a control with no arsenic. Obviously, more tests is better. In general a desired fraction of V_max at the initial concentration can be attained by using an initial concentration of x/(1-x) times K.
      • Determine "final" (steady-state) concentration of As(III) in the solution and in the cells. (Concentration over time is even better!)
      • This means that the total volume of the cells (and the solution) has to be determined. Possibly through looking at the dry weight (without arsenic!).
      • By manipulating the equation for the derivative of As(III) in equilibrium, As(III) can be expressed as a function of As(III)_ex (given the V and K constants). We can try to fill in the computed V and K constants for GlpF and then use a least squares fit to estimate the V and K constants for ArsB.
      • NOTE: Interestingly Kostal 2004 already did an experiment like this with cells that overexpressed ArsR. We're looking at analysing these results under the assumption that overexpressing ArsR only gives a constant factor more accumulation (for 1-100&microM As(III)), but it would be very nice to do this ourselves for unmodified cells to determine whether this is indeed true (and to determine the factor).

Evolution of the Project Plan

The project plan will be set up during the Inception phase and after each iteration the planning is updated to reflect the actual progress and give updated estimates. Other parts of the project plan are not scheduled to be updated after the Inception and will only be updated to fix errors, clarify the existing text or to reflect a change in circumstances.

Project Organization

This is covered by our team page and Google Docs for contact information (for privacy reasons).

Management Process

Project Estimates

The estimated costs for the project are as presented in the balance sheet (GoogleDocs). The estimated time for the project is 3-4 hours a week per person from march-july. Full-time (about 40 hours a week per person) during the summer (july-september). From september untill the jamboree on 30 okt another 3-4 hours a week per person (turned out to be a lot more full-time for most people).

Project Plan

This project recognizes the following phases and milestones (only broad descriptions of the milestones are given here):

• Inception: until 18 may, milestone: initial idea, including preliminary feasibility study.
• Elaboration: until the summer (1st of july), milestone: initial design and modelling.
• Construction: during the summer (1 july-30 august), milestone: the actual "product".
• Transition: after the summer (30 august-31 dec), milestone: the jamboree presentation and documentation for the next team.

Note that during the elaboration there should probably already be some lab work (if at all possible) to assist in modelling, and during the summer the modelling work will probably continue. Detailed planning of each of the iterations should be documented in iteration plans.

Project Monitoring and Control

Requirements Management

The requirements for this system are captured in the Vision document.

Quality Control

The Quality of the constructs developed by Labworkers should be conform the following quality control regulations

After transformation of the cells with Your Favorite Construct:

• Pick a few colonies.
  • Grow o/n culture of a single colony.
  • Continue with miniprep on o/n culture.
  • Check insert length by PCR and restriction analysis, as written in document: Quality control (Overdrachts document iGEM 2008).
    • For restriction analysis try to find a restriction enzyme which makes a single cut in the vector and a single cut in the insert, or a double digestion with one which cuts in the vector and one which cuts in the insert.
• Streak positive colony with inoculation eye out for single colonies.
  • Pick a single colony.
  • Grow o/n culture and make glycerol stock (put -80 position on Parts List) next day.
  • Miniprep and continue with cloning / checking insert length.

Reporting and Measurement

During the non-summer period (march-july, sept-oct) a meeting will be held on a weekly basis. During the meeting the progression of the project, finance, contact with other iGEM teams and organisation subjects will be discussed. Every other week the advisors are invited for this meeting. During the summer period (july-sept) a meeting will also be held on a weekly basis with the whole team.

Risk Management

Risks will be identified in Inception Phase using the steps identified in the RUP for Small Projects activity “Identify and Assess Risks”. Project risk is evaluated at least once per iteration and documented in this table (See Risk List).

Configuration Management

See Tools and Documentation.

Process Guidelines

This project attempts to follow a standardized process for software development (UPEDU), adapting it for use with iGEM. Where possible roles, activities, etc. are simply copied from UPEDU (and ultimately RUP). To cope with the difference between software development and genetic engineering we make the following changes:

• A new role "Modeller" for someone who models the design on a computer and attempts to verify the design before it is implemented in the lab.
• The "Implementer" role is changed to reflect lab work instead of programming.
• We also added some roles to take care of things like keeping minutes, doing PR and so on.

In practice we ignored most of UPEDU, because of a lack of experience with such approaches within the team (and a lack of time to make up for it), making it inefficient to use, but also because some features proved hard to implement, we specifically had trouble with:

• Using iterative development. In software development it is possible to make small changes quickly, allowing iterations as short as one or two weeks (much longer iterations would not have suited the time scale of iGEM). However, in synthetic biology it is more efficient to work on many things at once over a longer time frame (simply because each small change necessarily takes a certain amount of time). In practice this meant that a more waterfall-esque development process was used, where the construction phase consisted mostly of preparing everything for testing and analysis, leaving all testing, analysis and combination of results for the transition phase.
• Making a clear separation between requirements(, architecture), design, implementation and tests. With software it is possible to create pretty much anything you can define, so one starts by defining what the system should do (at least in part), then figures out how this could be implemented in an abstract way and only then actually implements it (tests can usually be developed in parallel). In part this approach can and should(!) be adopted in synthetic biology, but some things do make it hard to do this rigorously. For example, there is hardly any standard way to abstractly talk about system components yet. Hopefully parts and "devices" might help with this in the near future.

What did work for us to varying degrees:

• Identifying risks early on in the project. Without UPEDU we probably would not have done this and this could have led to severe problems. Luckily not that many of the risks actually materialized, but we did implement some of the mitigation strategies, leading to less nasty surprises. For example, we made an overview of everyone's availability early on in the project and tried to prevent having only one person work on a single part as much as possible.
• Using a standardized design process. Not specifically UPEDU, but it fits well within the framework and it helped us to structure our project selection process.
• Recognizing different phases in our development. This especially helped in the beginning by giving at least some structure to our planning and providing a vocabulary to talk about such things.
• Using iterations. Although we had definite problems in our use of iterations they did give some structure to the construction phase for example.
• Describing our Tools and Documentation. Although not always used consistently it did help us keep an overview what was stored where.
• Having specific Roles. Not all roles were used (consistently), but it did provide us with at least some structure to deal with eleven team members (it is not easy to do this "free-style").

Annexes

During the inception phase ideas were generated and selected using a design template. For selection of the ideas a list of demands and wishes was made.