"
Team:Groningen/Project Plan
From 2009.igem.org
(→Introduction: List of Enclosed Artifacts (+ attempt at relative links)) |
m (→Enclosed artifacts: Absolute links) |
||
| Line 12: | Line 12: | ||
* [[Team:Groningen/Project_Plan/Risk_List|Risk List]] | * [[Team:Groningen/Project_Plan/Risk_List|Risk List]] | ||
* Iteration Plans: | * Iteration Plans: | ||
| - | **[[/Inception|Inception]] | + | **[[Team:Groningen/Project_Plan/Inception|Inception]] |
| - | ***[[/Inception/1|Iteration 1]] | + | ***[[Team:Groningen/Project_Plan/Inception/1|Iteration 1]] |
| - | ***[[/Inception/2|Iteration 2]] | + | ***[[Team:Groningen/Project_Plan/Inception/2|Iteration 2]] |
| - | **[[/Elaboration|Elaboration]] | + | **[[Team:Groningen/Project_Plan/Elaboration|Elaboration]] |
| - | ***[[/Elaboration/1|Elaboration 1]] | + | ***[[Team:Groningen/Project_Plan/Elaboration/1|Elaboration 1]] |
| - | ***[[/Elaboration/2|Elaboration 2]] | + | ***[[Team:Groningen/Project_Plan/Elaboration/2|Elaboration 2]] |
| - | **[[/Construction|Construction]] | + | **[[Team:Groningen/Project_Plan/Construction|Construction]] |
| - | ***[[/Construction/1|Construction 1]] | + | ***[[Team:Groningen/Project_Plan/Construction/1|Construction 1]] |
| - | ***[[/Construction/2|Construction 2]] | + | ***[[Team:Groningen/Project_Plan/Construction/2|Construction 2]] |
| - | ***[[/Construction/3|Construction 3]] | + | ***[[Team:Groningen/Project_Plan/Construction/3|Construction 3]] |
| - | **[[/Transition|Transition]] | + | **[[Team:Groningen/Project_Plan/Transition|Transition]] |
| - | ***[[/Transition/1|Transition 1]] | + | ***[[Team:Groningen/Project_Plan/Transition/1|Transition 1]] |
| - | ***[[/Transition/2|Transition 2]] | + | ***[[Team:Groningen/Project_Plan/Transition/2|Transition 2]] |
=={{anchor|ProjectOverview}} Project Overview== | =={{anchor|ProjectOverview}} Project Overview== | ||
Revision as of 20:22, 27 April 2009
[http://2009.igem.org/Team:Groningen http://2009.igem.org/wiki/images/f/f1/Igemhomelogo.png]
| Project Plan
|
|---|
Introduction
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.
Enclosed artifacts
- Risk List
- Iteration Plans:
Project Overview
Project Purpose, Scope, and Objectives - NEW
The purpose of the 2009 iGEM Groningen project is ...
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 okt/nov 2009.
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 11 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 | 20-04-09 | Narrow down ideas to about three ideas that should be investigated further. |
| Inception 2 | 11-05-09 | Choose idea we're going to work on. The most important requirements should be identified. |
| Elaboration 1 | 25-05-09 | 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.
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-okt) 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 report of these meetings will be available on the wiki (???)
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.
Refer to the Risk List Document (CCC-DDD-X.Y.doc) for detailed information.
Configuration Management
Also see the Configuration Management Plan.
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 [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).
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.
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.
