"
Team:Groningen/Project Plan
From 2009.igem.org
(→Reporting and Measurement - NEW) |
(Updated link to configuration management plan.) |
||
| Line 186: | Line 186: | ||
===={{anchor|ConfigurationManagement}} Configuration Management==== | ===={{anchor|ConfigurationManagement}} Configuration Management==== | ||
| - | + | See [[Team:Groningen/Project_Plan/Tools and Documentation|Tools and Documentation]]. | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
=={{anchor|Process_Guidelines}} Process Guidelines - TODO== | =={{anchor|Process_Guidelines}} Process Guidelines - TODO== | ||
Revision as of 09:16, 5 August 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 | ||||||||||
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.
Project Overview
Project Purpose, Scope, and Objectives - NEW
The purpose of the 2009 iGEM Groningen project is to have a great summer, and have fun attending the Jamboree.
Assumptions and Constraints - TODO
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.
TODO: What other assumptions and constraints apply?
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:
- 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
TODO: More detail
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 - NEW
The estimated costs for the project are as presented in the 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.
[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.]
Project Plan - TODO
[This section contains the schedule and resources for the project.]
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-30 okt), 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.]
| 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. |
[Identify the numbers and type of staff required here, including any special skills or experience, scheduled by project phase or iteration.
List any special training project team members will require, with target dates for when this training should be completed.]
Project Monitoring and Control - TODO
[The following is a checklist of items to consider:
- Requirements Management: Specify the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements.
- 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 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 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.
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.
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.
Reporting and Measurement - NEW
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.
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:
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.
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 Risk List).
Refer to the Risk List for detailed information(CCC-DDD-X.Y.doc).
Configuration Management
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:
- 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. TODO: How?
- TODO: more???
Annexes - NEW
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.
[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.
It would be entirely acceptable to remove the annexes section as such and replace it with the corresponding sections.]
The project will follow the UPEDU process.
Other applicable process plans are listed in the references section, including Programming Guidelines.
