Team:Groningen/Project Plan

From 2009.igem.org

(Difference between revisions)

Revision as of 13:05, 21 April 2009

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.

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.

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??? (A bacterium?)
A presentation for the jamboree in November.
???

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.

Management Process

Project Estimates - NEW

[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 ???, milestone: initial idea, including preliminary feasibility study.
Elaboration: until the summer(???), milestone: initial design and modelling.
Construction: during the summer, milestone: the actual "product".
Transition: after the summer, 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	???	Narrow down ideas to about three ideas that should be investigated further.
Inception 2	???	Choose idea we're going to work on. The most important requirements should be identified.
Elaboration 1	???	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
Construction 2	2009-08-11
Construction 3	2009-09-01	Everything (in the lab) finished :)
Transition 1	???	Presentation for the jamboree and the wiki should be (made and) polished.
Transition 2	???	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

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

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).

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

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

@@ Line 145: / Line 145: @@
 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 "[[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 "[[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 "[[Team:Groningen/Roles#Implementer|Implementer]]" role is changed to reflect lab work instead of programming. TODO: How?
+*The "[[Team:Groningen/Roles/Implementer|Implementer]]" role is changed to reflect lab work instead of programming. TODO: How?
 *TODO: more???