Team:Groningen/Project Plan

From 2009.igem.org

(Difference between revisions)
(Quality Control - NEW)
({{anchor|Deliverables}} Project Deliverables)
 
(15 intermediate revisions not shown)
Line 6: Line 6:
.wetwork { color: green; }
.wetwork { color: green; }
</style></html>
</style></html>
 +
 +
'''Judges:''' Please note [[Team:Groningen/Project_Plan#UPEDU|this section]] in particular.
The project plan (known in [http://www.upedu.org/ UPEDU] as "[http://www.upedu.org/upedu/process/artifact/ar_sdp.htm 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.
The project plan (known in [http://www.upedu.org/ UPEDU] as "[http://www.upedu.org/upedu/process/artifact/ar_sdp.htm 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.
-
Note that sections marked with NEW still have to be filled with some relevant information (or discarded), while sections marked with TODO are simply unfinished.
+
<div style="float:left" >{{linkedImage|GroningenPrevious.png|Team:Groningen/Parts/Used_Parts}}</div>
 +
<div title="Arsie Says UP TO ACCUMULATION" style="float:right" >{{linkedImage|Next.JPG|Team:Groningen/Project_Plan#UPEDU}}</div>
=={{anchor|ProjectOverview}} Project Overview==
=={{anchor|ProjectOverview}} Project Overview==
-
===Project Purpose, Scope, and Objectives - NEW===
+
===Project Purpose, Scope, and Objectives===
The purpose of the 2009 iGEM Groningen project is [https://2009.igem.org/Judging/Judging_Criteria to have a great summer, and have fun attending the Jamboree].
The purpose of the 2009 iGEM Groningen project is [https://2009.igem.org/Judging/Judging_Criteria to have a great summer, and have fun attending the Jamboree].
-
===Assumptions and Constraints - TODO===
+
===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.  
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.  
Line 39: Line 42:
:*It is possible to find sponsoring for this project.
:*It is possible to find sponsoring for this project.
-
TODO: What other assumptions and constraints apply?
+
==={{anchor|Deliverables}} Project Deliverables===
-
 
+
-
==={{anchor|Deliverables}} Project Deliverables - TODO===
+
-
[A list of the artifacts to be created during the project, including target delivery dates. The text below is provided as an example.]
+
-
 
+
During the course of this project the following will be delivered:
During the course of this project the following will be delivered:
Line 54: Line 53:
*A report of our findings
*A report of our findings
-
TODO: More detail
+
====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 <sup>1</sup>/<sub>3</sub>K (25% of V<sub>max</sub>), K (50% of V<sub>max</sub>), 3K (75% of V<sub>max</sub>) and 10mM (99.7% of V<sub>max</sub>, corresponding to extremely polluted water), and a control with no arsenic. Obviously, more tests is better. In general a desired fraction of V<sub>max</sub> 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)<sub>ex</sub> (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 [[Team:Groningen/Literature#Kostal2004|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===
===Evolution of the Project Plan===
Line 63: Line 84:
=={{anchor|ManagementProcess}} Management Process==
=={{anchor|ManagementProcess}} Management Process==
-
===Project Estimates - NEW===
+
===Project Estimates===
-
The estimated costs for the project are as presented in the [[Team:Groningen/Project_Plan/BalanceSheet|balance sheet]]. 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. A more detailed schedule can be found in the Project Plan.
+
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).
-
 
+
-
[Provide the estimated cost and schedule for the project, as well as the basis for those estimates, and the points and circumstances in the project when re-estimation will occur.]
+
-
 
+
-
==={{anchor|ProjectPlan}} Project Plan - TODO===
+
-
[This section contains the schedule and resources for the project.]
+
 +
==={{anchor|ProjectPlan}} Project Plan===
This project recognizes the following [http://www.upedu.org/upedu/process/itrwkfls/iwf_iwfs.htm phases and milestones] (only broad descriptions of the milestones are given here):
This project recognizes the following [http://www.upedu.org/upedu/process/itrwkfls/iwf_iwfs.htm phases and milestones] (only broad descriptions of the milestones are given here):
Line 76: Line 93:
*[[Team:Groningen/Project_Plan/Elaboration|Elaboration]]: until the summer (1st of july), milestone: initial design and modelling.
*[[Team:Groningen/Project_Plan/Elaboration|Elaboration]]: until the summer (1st of july), milestone: initial design and modelling.
*[[Team:Groningen/Project_Plan/Construction|Construction]]: during the summer (1 july-30 august), milestone: the actual "product".
*[[Team:Groningen/Project_Plan/Construction|Construction]]: during the summer (1 july-30 august), milestone: the actual "product".
-
*[[Team:Groningen/Project_Plan/Transition|Transition]]: after the summer (30 august-30 okt), milestone: the jamboree presentation (and documentation for the next team?)
+
*[[Team:Groningen/Project_Plan/Transition|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 (and design?) work will probably continue. Detailed planning of each of the iterations is (should be) documented in iteration plans.
+
-
 
+
-
TODO: Fill in dates and determine how waterfall-esque it should be. That is, to what extent can the design be adjusted after the lab work has begun? And to what extent is it possible to begin lab work before the summer? And if it is possible, what is most useful? (The last question is probably something that can only be answered after having chosen the "idea".)
+
-
[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]
+
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.
{| border="1"
{| border="1"
Line 126: Line 139:
|}
|}
-
[Identify the numbers and type of staff required here, including any special skills or experience, scheduled by project phase or iteration.
+
===Project Monitoring and Control===
-
List any special training project team members will require, with target dates for when this training should be completed.]
+
====Requirements Management====
 +
The requirements for this system are captured in [[Team:Groningen/Vision|the Vision document]].
-
===Project Monitoring and Control - TODO===
+
====Quality Control====
-
[The following is a checklist of items to consider:
+
The '''Quality of the constructs''' developed by Labworkers should be conform the following quality control regulations
-
*Requirements Management: Specify the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements.
+
After transformation of the cells with Your Favorite Construct:
-
 
+
-
*Quality Control: Describe the timing and methods to be used to control the quality of the project deliverables and how to take corrective action when required. Include techniques, metrics, criteria, and procedures used for evaluation— this will include walkthroughs, inspections, and reviews. Note that this is in addition to the Test Plan, which is not enclosed in the Software Development Plan.
+
-
 
+
-
*Reporting and Measurement: Describe reports to be generated. Specify which metrics should be collected and why. OR if available, refer to the Project Measurements and Project Measurements document
+
-
 
+
-
*Risk Management: Describe the approach that will be used to identify, analyze, prioritize, monitor and mitigate risks. If available, refer to the Risk List document.
+
-
 
+
-
*Configuration Management: Describe the process by which problems and changes are submitted, reviewed, and dispositioned. Describe how project or product artifacts are to be named, marked, and numbered, including system software, plans, models, components, test software, results and data, executables, and so on. Describe retention policies, and the back-up, disaster, and recovery plans. OR if Available, Refer to the Configuration Management Plan document]
+
-
 
+
-
====Requirements Management - NEW====
+
-
The requirements for this system are captured in [[Team:Groningen/Vision| the Vision document]]. Requested changes to requirements are captured in Change Requests, and are approved as part of the Configuration Management process.
+
-
 
+
-
====Quality Control - NEW====
+
-
Defects will be recorded and tracked as Change Requests, and defect metrics will be gathered (see [[Team:Groningen/Project_Plan#Reporting_and_Measurement_-_NEW| Reporting and Measurement]] below).
+
-
 
+
-
All deliverables are required to go through the appropriate review process, as described in the Development Case. The review is required to ensure that each deliverable is of acceptable quality, using guidelines and checklists.
+
-
 
+
-
<span class="wetwork">The '''Quality of the constructs''' developed by Labworkers should be conform the following quality control regulations
+
-
 
+
-
<span class="wetwork">After transformation of the cells with Your Favorite Construct:
+
*Pick a few colonies.
*Pick a few colonies.
-
**<span class="wetwork">Grow o/n culture of a single colony.
+
**Grow o/n culture of a single colony.
-
**<span class="wetwork">Continue with miniprep on o/n culture.
+
**Continue with miniprep on o/n culture.
-
**<span class="wetwork">Check insert length by PCR and restriction analysis, as written in document: Quality control (Overdrachts document iGEM 2008).
+
**Check insert length by PCR and restriction analysis, as written in document: Quality control (Overdrachts document iGEM 2008).
-
***<span class="wetwork"> 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.
+
***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.
*Streak positive colony with inoculation eye out for single colonies.
-
**<span class="wetwork">Pick a single colony.
+
**Pick a single colony.
-
**<span class="wetwork">Grow o/n culture and make glycerol stock (put -80 position on [https://2009.igem.org/Team:Groningen/Parts Parts List]) next day.  
+
**Grow o/n culture and make glycerol stock (put -80 position on [https://2009.igem.org/Team:Groningen/Parts Parts List]) next day.  
-
**<span class="wetwork">Miniprep and continue with cloning / checking insert length.
+
**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.
-
Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.
+
====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 [[Team:Groningen/Project_Plan/Risk_List|Risk List]]).
-
====Reporting and Measurement - NEW====
+
===={{anchor|ConfigurationManagement}} Configuration Management====
-
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. Also next to that the labwork team and the modelling team will have a meeting to specifically discuss the progression of the labwork or modelling and what should be done the coming week. A short summary of these meetings will be available on the wiki Notebook.
+
See [[Team:Groningen/Project_Plan/Tools and Documentation|Tools and Documentation]].
-
Updated schedule estimates, and metrics summary reports, will be generated at the end of each iteration.
 
-
The Minimal Set of Metrics, as described in the RUP Guidelines: Metrics will be gathered on a weekly basis. These include:
+
<div title="Arsie Says UP TO ACCUMULATION" style="float:right" >{{linkedImage|Next.JPG|Team:Groningen/Project_Plan/Risk_List}}</div>
-
Earned value for completed tasks. This is used to re-estimate the schedule and budget for the remainder of the project, and/or to identify need for scope changes.
+
<div style="float:left" >{{linkedImage|GroningenPrevious.png|Team:Groningen/Project_Plan}}</div>
-
 
+
=={{anchor|Process_Guidelines}}{{anchor|UPEDU}} Process Guidelines==
-
Total defects open and closed – shown as a trend graph. This is used to help estimate the effort remaining to correct defects.
+
-
 
+
-
Acceptance test cases passing – shown as a trend graph. This is used to demonstrate progress to stakeholders.
+
-
 
+
-
 
+
-
 
+
-
Refer to the Project Measurements Document (AAA-BBB-X.Y.doc) for detailed information.
+
-
 
+
-
====Risk Management - NEW====
+
-
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 [https://2009.igem.org/Team:Groningen/Project_Plan/Risk_List Risk List]).
+
-
 
+
-
Refer to the [https://2009.igem.org/Team:Groningen/Project_Plan/Risk_List Risk List] for detailed information(CCC-DDD-X.Y.doc).
+
-
 
+
-
===={{anchor|ConfigurationManagement}} Configuration Management====
+
-
See [[Team:Groningen/Project_Plan/Tools and Documentation|Tools and Documentation]].
+
-
 
+
-
=={{anchor|Process_Guidelines}} Process Guidelines - TODO==
+
This project attempts to follow a standardized process for software development ([http://www.upedu.org/ 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:
This project attempts to follow a standardized process for software development ([http://www.upedu.org/ 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 "[[:Category:Team:Groningen/Roles/Modeller|Modeller]]" for someone who models the design on a computer and attempts to verify the design before it is implemented in the lab.
*A new role "[[:Category:Team:Groningen/Roles/Modeller|Modeller]]" for someone who models the design on a computer and attempts to verify the design before it is implemented in the lab.
-
*The "[[:Category:Team:Groningen/Roles/Implementer|Implementer]]" role is changed to reflect lab work instead of programming. TODO: How?
+
*The "[[:Category:Team:Groningen/Roles/Implementer|Implementer]]" role is changed to reflect lab work instead of programming.
-
*TODO: more???
+
*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:
-
=={{anchor|Annexes}} Annexes - NEW==
+
*'''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.
-
During the inception phase ideas were generated and selected using a [[Team:Groningen/methodischontwerpen|design template]]. For selection of the ideas a [[Team:Groningen/Project_Plan#Assumptions_and_Constraints_-_TODO|list of demands and wishes]] was made.
+
*'''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.
-
[Additional material of use to the reader of the Software Development Plan. Reference or include any project technical standards and plans which apply to this project. This typically includes the Programming Guidelines, Design Guidelines, and other process guidelines. The text that follows is provided as an example.
+
What did work for us to varying degrees:
-
It would be entirely acceptable to remove the annexes section as such and replace it with the corresponding sections.]
+
*'''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 [[Team:Groningen/methodischontwerpen|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").
-
The project will follow the UPEDU process.
+
=={{anchor|Annexes}} Annexes==
 +
During the inception phase ideas were generated and selected using a [[Team:Groningen/methodischontwerpen|design template]]. For selection of the ideas a [[Team:Groningen/Project_Plan#Assumptions_and_Constraints|list of demands and wishes]] was made.
-
Other applicable process plans are listed in the references section, including Programming Guidelines.
+
{{Team:Groningen/Project_Plan/Footer}}

Latest revision as of 21:43, 21 October 2009

[http://2009.igem.org/Team:Groningen http://2009.igem.org/wiki/images/f/f1/Igemhomelogo.png]
Project Plan
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

Judges: Please note this section in particular.

The project plan (known in [http://www.upedu.org/ UPEDU] as "[http://www.upedu.org/upedu/process/artifact/ar_sdp.htm 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.

[http://2009.igem.org/Team:Groningen/Parts/Used_Parts http://2009.igem.org/wiki/images/1/1f/GroningenPrevious.png]
[http://2009.igem.org/Team:Groningen/Project_Plan#UPEDU http://2009.igem.org/wiki/images/d/dd/Next.JPG]

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 1/3K (25% of Vmax), K (50% of Vmax), 3K (75% of Vmax) and 10mM (99.7% of Vmax, corresponding to extremely polluted water), and a control with no arsenic. Obviously, more tests is better. In general a desired fraction of Vmax 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 [http://www.upedu.org/upedu/process/itrwkfls/iwf_iwfs.htm 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.

Iteration End date Objectives
Inception 1 2009-04-20 Narrow down ideas to about three ideas that should be investigated further.
Inception 2 2009-05-18 Choose idea we're going to work on. The most important requirements should be identified.
Elaboration 1 2009-06-01 The initial design should be made, the requirements refined. Some initial model prototypes should be made to gain experience in modelling.
Elaboration 2 2009-06-30 Models of our design should be made and verified, the design refined. And if possible some things may have to be verified and or tried out in the lab.
Construction 1 2009-07-21 All necessary equipment and materials should be known and in the lab.
Construction 2 2009-08-11 A checkup if the system works, including all parts, should be able to be done.
Construction 3 2009-09-01 Everything (in the lab) finished :)
Transition 1 15-10-09 Presentation for the jamboree and the wiki should be (made and) polished.
Transition 2 31-12-09 Our documentation should be prepared for and transferred to the next team.

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.


[http://2009.igem.org/Team:Groningen/Project_Plan/Risk_List http://2009.igem.org/wiki/images/d/dd/Next.JPG]
[http://2009.igem.org/Team:Groningen/Project_Plan http://2009.igem.org/wiki/images/1/1f/GroningenPrevious.png]

Process Guidelines

This project attempts to follow a standardized process for software development ([http://www.upedu.org/ 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.

                    
[http://2009.igem.org/Team:Groningen http://2009.igem.org/wiki/images/0/01/LogoIGEMGroningenBar.png]
                    
            [http://www.cityoftalent.nl/en The City of Talent]