Difference between revisions of "DGC75 Status Chart"
From Murray Wiki
Jump to navigationJump to search
(=Wiki Documentation=) |
(added new modules) |
||
| Line 4: | Line 4: | ||
<center>[[Image:CPMT_Status_2004-06-19.jpg]]</center> | <center>[[Image:CPMT_Status_2004-06-19.jpg]]</center> | ||
= CPMT Modules = | |||
== | |||
== [[DGC75_GOTChA_Description|GOTChA Chart]] == | == [[DGC75_GOTChA_Description|GOTChA Chart]] == | ||
| Line 55: | Line 38: | ||
---- | ---- | ||
== [[ | == [[DGC75_Bugzilla_Description|Bugzilla Task Lists]] == | ||
Fairly well defined process here. Need to copy over information on how to use Bugzilla from Team Caltech Wiki | |||
Interfaces | |||
* Status chart: products specified by teams, components specified by status chart blocks | |||
* Project/team meetings: use Bugzilla in team meetings to look at critical and blocker tasks. Team and project meeting action items should get entered into bugzilla by note taker | |||
* Design reviews: record design review action items in bugzilla | |||
* Demos/tests: record actions from demos and tests in bugzilla | |||
---- | |||
== [[DGC75_Documentation_Description|Wiki Documentation]] == | |||
Need to write down how the Wiki is supposed to be structured and used. Can copy a lot of this from TeamCaltech site. | |||
Interfaces | |||
* Technical work: only documented work will be graded | |||
* Design reviews: all work presented at reviewes should be documented | |||
* Tests/demos: all results from tests should be documented | |||
= CPMT Activities = | |||
== [[DGC75_Meetings_Description|Project/Team Meetings]] == | |||
We have a pretty good template in place for these: goals, agenda, notetaker. Need to create a document for proper meeting practices. | |||
Interfaces | |||
* GOTChA charts: Meetings should start and end with GOTChA charts | |||
* Status charts: Meeting status updates should use status chart to organize discussion | |||
* Bugzilla: Meetings should review blocker items in bugzilla and new actions should be recorded in bugzilla | |||
---- | |||
== [[DGC75_ProgressReports_Description|Weekly Progress Reports]] == | |||
---- | |||
== [[DGC75_DesignReviews_Description|Design Reviews]] == | |||
Need to figure out how design reviews should be held. Probably having a couple of different types: working meetings, preliminary design review, critical design review. | Need to figure out how design reviews should be held. Probably having a couple of different types: working meetings, preliminary design review, critical design review. | ||
| Line 72: | Line 89: | ||
* Bugzilla task lists: action items from demos should be entered in Bugzilla | * Bugzilla task lists: action items from demos should be entered in Bugzilla | ||
* Technical work: technical work should be driven by demo milestones | * Technical work: technical work should be driven by demo milestones | ||
= CPTM Interfaces = | |||
== [[DGC75_Selection_Description|Project Selection]] == | |||
---- | |||
== [[DGC75_DesignSpec_Description|Design Specification]] == | |||
Don't currently have any formal way of specifying system requirements or propogating them through the design. Need to think through how requirements will be specified at both project and team level. | |||
Interfaces: | |||
* GOTChA chart: requirements should be reflected in objectives | |||
* Design reviews: reviews should demonstrate requirements are met | |||
---- | ---- | ||
== [[ | == [[DGC75_Courses_Description|Course Projects]] == | ||
---- | |||
== [[DGC75_SURF_Description|SURF Projects]] == | |||
---- | |||
== [[DGC75_Industry_Description|Industry Interaction]] == | |||
---- | ---- | ||
== [[ | == [[DGC75_Volunteer_Description|Volunteer Interaction]] == | ||
---- | |||
== [[DGC75_Competition_Description|Final Competition]] == | |||
Revision as of 23:21, 19 June 2004
Caltech Project Management Toolset (CPMT) Status Chart
Updated: 19 Jun 04
CPMT Modules
GOTChA Chart
Need to copy over GOTChA chart info from TeamCaltech wiki.
Interfaces
- Design Specification: objectives should reflect level 1 specifications
- Status Chart: approach should correspond to status chart
- Timeline Chart: objectives/approach should be reflected on timeline chart
- Design Reviews: GOTChA charts for the basis for design review presentations
Status Chart
Need to write a description for what a status chart is and how to use it.
Interfaces
- GOTChA chart: approach should be reflected on this chart
- Timeline chart: status should be relative to timeline (milestones)
- Bugzilla task lists: subsystem blocks should be represented as components in bugzilla.
- Project/team meetings: status chart should be used in team meetings to guide discussion of current status
Timeline Chart
Need to create description of timeline chart. Should link to project meetings.
Interfaces:
- GOTChA chart: approach should be reflected in timeline
- Project/team meetings: missing
- Status chart: status should be reflected in timeline; arrow may be one way?
Bugzilla Task Lists
Fairly well defined process here. Need to copy over information on how to use Bugzilla from Team Caltech Wiki
Interfaces
- Status chart: products specified by teams, components specified by status chart blocks
- Project/team meetings: use Bugzilla in team meetings to look at critical and blocker tasks. Team and project meeting action items should get entered into bugzilla by note taker
- Design reviews: record design review action items in bugzilla
- Demos/tests: record actions from demos and tests in bugzilla
Wiki Documentation
Need to write down how the Wiki is supposed to be structured and used. Can copy a lot of this from TeamCaltech site.
Interfaces
- Technical work: only documented work will be graded
- Design reviews: all work presented at reviewes should be documented
- Tests/demos: all results from tests should be documented
CPMT Activities
Project/Team Meetings
We have a pretty good template in place for these: goals, agenda, notetaker. Need to create a document for proper meeting practices.
Interfaces
- GOTChA charts: Meetings should start and end with GOTChA charts
- Status charts: Meeting status updates should use status chart to organize discussion
- Bugzilla: Meetings should review blocker items in bugzilla and new actions should be recorded in bugzilla
Weekly Progress Reports
Design Reviews
Need to figure out how design reviews should be held. Probably having a couple of different types: working meetings, preliminary design review, critical design review.
Interfaces:
- Design specification: design specs should be the basis for the review
- Technical Work: technical work should be driven by design reviews and new actions from design reviews should be reflected in technical work
- Wiki documentation: not sure what the link is here yet. Define or delete.
Tests/Demos
Need to define some processes around tests and (field) demonstrations. These include pre-demo checklists, test matrices, test manager, etc.
Interfaces:
- Wiki Documentation: results of demos should be documented
- Bugzilla task lists: action items from demos should be entered in Bugzilla
- Technical work: technical work should be driven by demo milestones
CPTM Interfaces
Project Selection
Design Specification
Don't currently have any formal way of specifying system requirements or propogating them through the design. Need to think through how requirements will be specified at both project and team level.
Interfaces:
- GOTChA chart: requirements should be reflected in objectives
- Design reviews: reviews should demonstrate requirements are met
