"
Team:Groningen/Project Plan/Tools and Documentation
From 2009.igem.org
(Purpose and scope of the introduction.) |
m (→Introduction - NEW) |
||
| Line 2: | Line 2: | ||
[[Category:Team:Groningen/Roles/Configuration_Manager|Configuration_Management_Plan]] | [[Category:Team:Groningen/Roles/Configuration_Manager|Configuration_Management_Plan]] | ||
[[Category:Team:Groningen/Roles/Facility_Manager|Configuration_Management_Plan]] | [[Category:Team:Groningen/Roles/Facility_Manager|Configuration_Management_Plan]] | ||
| - | ==Introduction | + | ==Introduction== |
[[Team:Groningen|Our project]] produces [[Team:Groningen/Project_Plan#Deliverables|many artifacts]], this [http://www.upedu.org/upedu/process/artifact/ar_cmpln.htm Configuration Management Plan] details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it? | [[Team:Groningen|Our project]] produces [[Team:Groningen/Project_Plan#Deliverables|many artifacts]], this [http://www.upedu.org/upedu/process/artifact/ar_cmpln.htm Configuration Management Plan] details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it? | ||
Revision as of 10:45, 24 April 2009
Contents |
Introduction
Our project produces many artifacts, this [http://www.upedu.org/upedu/process/artifact/ar_cmpln.htm Configuration Management Plan] details what tools and processes we use to create these artifacts. Both for dry work and wet work. Do we use Matlab or Mathematica? What programming conventions do we use? Which lab space do we use? When do we use it?
References - NEW
[This subsection provides a complete list of all documents referenced elsewhere in the Configuration Management Plan. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]
Overview - NEW
[This subsection describes what the rest of the Configuration Management Plan contains and explains how the document is organized.]
Software Configuration Management - NEW
Organization, Responsibilities, and Interfaces - NEW
[Describe who is going to be responsible for performing the various Configuration Management (CM) activities described in the CM Process Discipline.]
Tools, Environment, and Infrastructure - NEW
[Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle.
Describe the tools and procedures required used to version control configuration items generated throughout the project or product lifecycle.
Issues involved in setting up the CM environment include:
- anticipated size of product data
- distribution of the product team
- physical location of servers and client machines]
The Configuration Management Program - NEW
Configuration Identification - NEW
Identification Methods - NEW
[Describe how project or product artifacts are to be named, marked, and numbered. The identification scheme needs to cover hardware, system software, Commercial-Off-The-Shelf (COTS) products, and all application development artifacts listed in the product directory structure; for example, plans, models, components, test software, results and data, executables, and so on. ]
Product directory structure (Project Repository) - NEW
[The Product Directory Structure serves a logically nested placeholder for all versionable product-related artifacts. The Product Directory Structure is a placeholder framework and provides a navigational map to all project related artifacts. Map your product directory structure using a structured text hierarchy or use a screenshot, if available, of your directories environment]
Workspaces - NEW
[Explain and describe how development and integration workspace will be created and managed in relation with the project repository. What are they, where are they, when are they created. Specify any details or conventions your project team will use.]
Project Baselines - NEW
[Baselines provide an official standard on which subsequent work is based and to which only authorized changes are made.
Describe at what points during the project or product lifecycle the baselines are to be established. The most common baselines would be at the end of each of the Inception, Elaboration, Construction, and Transition phases. Baselines could also be generated at the end of iterations within the various phases or even more frequently.
Describe who authorizes a baseline and what goes into it.]
Configuration and Change Control - NEW
Change Request Processing and Approval - NEW
[Describe the process by which problems and changes are submitted, reviewed, and dispositioned.]
Change Control Board (CCB) - NEW
[Describe the CCB membership and the procedures for processing change requests and approvals to be followed by the CCB.]
Configuration Status Accounting - NEW
Project Media Storage and Release Process - NEW
[Describe retention policies, and the back-up, disaster, and recovery plans. Also describe how the media is to be retained—online, offline, media type, and format.
Archives show their value in times of re-use or disaster. As such, archives need to be done regularly and at major and minor milestones. Describe your practices and approaches on how you ensure that project software and related assets (master documents) are backed-up, catalogued and transferred to designated storage sites
The release process describes what is in the release, who it is for, and whether there are any known problems and any installation instructions.]
Reports and Audits - NEW
[Describe the content, format, and purpose of the requested reports and configuration audits.
Reports are used to assess the “quality of the product” at any given time in the project or product lifecycle. Reporting on defects based on change requests may provide some useful quality indicators and, thereby, alert management and developers to particularly critical areas of development. Defects are often classified by criticality (high, medium, and low) and could be reported on the following basis:
- Aging (Time-based Reports): How long have defects of the various kinds been open? What is the “lag time’’ between when defects are found in the lifecycle and when they are fixed?
- Distribution (Count Based Reports): How many defects are there in the various categories by owner, priority or state of fix?
- Trend (Time-related and Count-related Reports): What is the cumulative number of defects found and fixed over time? What is the rate of defect discovery and fix? What is the “quality gap” in terms of open as opposed to closed defects? What is the average defect resolution time?]
Milestones - NEW
[Identify the internal and customer milestones related to the project or product CM effort. This section includes details on when the Configuration Management Plan itself is to be updated.]
Training and Resources - NEW
[Describe the software tools, personnel, and training required to implement the specified CM activities.]
6. External development environment [Describe how software developed outside of the project environment will be incorporated.]
