DGC75 Status Chart - Revision history

Murray: /* [http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart GOTChA Chart] */

2005-06-21T21:14:04Z

[http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart GOTChA Chart]

← Older revision		Revision as of 21:14, 21 June 2005
Line 13:		Line 13:
	= CPMT Modules =		= CPMT Modules =

	== [~~http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart~~ GOTChA Chart] ==		== [[GOTChA Chart]] ==
	Need to copy over GOTChA chart info from TeamCaltech wiki.		Need to copy over GOTChA chart info from TeamCaltech wiki.

Murray: =Preparation for review=

2004-08-05T23:14:48Z

=Preparation for review=

← Older revision		Revision as of 23:14, 5 August 2004
Line 126:		Line 126:
	=== Preparation for review ===		=== Preparation for review ===
	* Ask each time to request the amount of time needed for their section, rather than using a fixed time for each team		* Ask each time to request the amount of time needed for their section, rather than using a fixed time for each team
			* Send read-ahead material on the project (documentation)

	=== Team presentation outline ===		=== Team presentation outline ===

Murray: /* Design Reviews */

2004-08-02T16:00:32Z

Design Reviews

← Older revision		Revision as of 16:00, 2 August 2004
Line 123:		Line 123:
	* Technical Work: technical work should be driven by design reviews and new actions from design reviews should be reflected in technical work		* 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.		* Wiki documentation: not sure what the link is here yet. Define or delete.

			=== Preparation for review ===
			* Ask each time to request the amount of time needed for their section, rather than using a fixed time for each team

	=== Team presentation outline ===		=== Team presentation outline ===

Murray: /* Design Reviews */

2004-07-29T04:33:41Z

Design Reviews

← Older revision		Revision as of 04:33, 29 July 2004
Line 117:		Line 117:

	== [[DGC75_DesignReviews_Description\|Design Reviews]] ==		== [[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. Use MVWT II review on 28 July for RFA, assessment templates.

	Interfaces:		Interfaces:

Murray: /* Design Reviews */ Added team presentation outline

2004-07-29T04:32:14Z

Design Reviews: Added team presentation outline

@@ Line 123: / Line 123: @@
 * 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.
 ----

Murray: /* Caltech Project Management Toolset (CPMT) Status Chart */

2004-06-27T05:47:36Z

Caltech Project Management Toolset (CPMT) Status Chart

← Older revision		Revision as of 05:47, 27 June 2004
Line 9:		Line 9:
	* Red: not well defined and/or implemented		* Red: not well defined and/or implemented

	The sections below give the current status of the component. Clink on the component title for a description of the component.		The sections below give the current status of the component. Clink on the component title for a description of the component. <b>Note: need to transfer descriptive text to information pages</b>

	= CPMT Modules =		= CPMT Modules =

Dvangogh: =Project/Team Meetings=

2004-06-23T20:54:06Z

=Project/Team Meetings=

← Older revision		Revision as of 20:54, 23 June 2004
Line 81:		Line 81:
	** a brief description, and		** a brief description, and
	** the name of the speaker(s).		** the name of the speaker(s).

	The agenda should include		The agenda should include
			* GOTChA chart presentation and discussion (beginning and end)
			* Status updates with status chart
			* Review of blocker items in Bugzilla
			* Review of timeline with upcoming events highlighted.

	The following are best practices for meetings:		The following are best practices for meetings:
Line 94:		Line 99:
	* The driver hands out copies of the notes or slides to everyone in the meeting.		* The driver hands out copies of the notes or slides to everyone in the meeting.
	* The driver puts up a prepared slide with the goals and agenda listed (or writes the goals and agenda on a white board).		* The driver puts up a prepared slide with the goals and agenda listed (or writes the goals and agenda on a white board).
	* The driver presents the GOTChA chart for the team. The driver verifies that all attending agree with the GOTChA chart, and leads the discussion in case of disagreement.
	* The driver walks through each of the agenda items, making sure the meeting ends on time.		* The driver walks through each of the agenda items, making sure the meeting ends on time.
	* At the end of the meeting, the driver presents the GOTChA chart.

	After the meeting		After the meeting

Dvangogh: =Project/Team Meetings=

2004-06-23T20:50:02Z

=Project/Team Meetings=

← Older revision		Revision as of 20:50, 23 June 2004
Line 76:		Line 76:
	Project meetings are typically held once a week. The content of these meetings varies from week to week, but two items are always covered:		Project meetings are typically held once a week. The content of these meetings varies from week to week, but two items are always covered:

	1. Goals		* '''Goals:''' what is to be acheived during the timeframe of the meeting (e.g., decide on next steps, create test plan, present system architecture options).
	~~2. Agenda~~		* '''Agenda:''' a sequential, prioritized list of tasks that will be covered during the meeting. The most important item should be covered first. Each agenda item lists
			** a starting and ending time,
	~~The goals of the meeting state~~ what is to be acheived during the timeframe of the meeting. ~~The agenda is~~ a sequential list of tasks that will be covered during the meeting.		** a brief description, and
			** the name of the speaker(s).
			The agenda should include

	The following are best practices for meetings:		The following are best practices for meetings:
Line 92:		Line 94:
	* The driver hands out copies of the notes or slides to everyone in the meeting.		* The driver hands out copies of the notes or slides to everyone in the meeting.
	* The driver puts up a prepared slide with the goals and agenda listed (or writes the goals and agenda on a white board).		* The driver puts up a prepared slide with the goals and agenda listed (or writes the goals and agenda on a white board).
	** The goals are those tasks that are to be accomplished by the end of the meeting (e.g., decide on next steps, create test plan, present system architecture options).
	** The agenda is a prioritized list of activities that will occur during the meeting (i.e., the most important item should be covered first). Each agenda item lists
	*** a starting and ending time,
	*** a brief description, and
	*** the name of the speaker(s).
	~~The agenda should include:~~
	*** this
	*** that
	* The driver presents the GOTChA chart for the team. The driver verifies that all attending agree with the GOTChA chart, and leads the discussion in case of disagreement.		* The driver presents the GOTChA chart for the team. The driver verifies that all attending agree with the GOTChA chart, and leads the discussion in case of disagreement.
	* The driver walks through each of the agenda items, making sure the meeting ends on time.		* The driver walks through each of the agenda items, making sure the meeting ends on time.

Dvangogh: =Project/Team Meetings=

2004-06-23T20:45:25Z

=Project/Team Meetings=

@@ Line 74: / Line 74: @@
 = 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.
+Project meetings are typically held once a week.  The content of these meetings varies from week to week, but two items are always covered:
 Interfaces

Dvangogh: =Status Chart=

2004-06-23T18:37:04Z

=Status Chart=

← Older revision		Revision as of 18:37, 23 June 2004
Line 29:		Line 29:
	[[Image:EmbsysStatus2Mar04-small.JPG]]		[[Image:EmbsysStatus2Mar04-small.JPG]]

	In this example, each of the components of the embedded systems architecture is drawn as a block. Each block has assigned to it a color which designates the status of that component~~. In addition, there are arrows between many of the blocks. This indicates the interfaces between components. Their status is also color-coded~~. Red means "this component is in trouble - need help!". Green means "everything is ok - nothing to be done here" and yellow is somewhere inbetween.		On a status chart, the entire system architecture is depicted. Each component of the architecture is drawn as a block, with arrows between the blocks indicating the interfaces. In this example, the "vehicle" and "path planning" architectures are drawn as single blocks to simplify the chart (their architectures are detailed on separate status charts). For this status chart, each of the components (hardware and software) of the embedded systems architecture is drawn as a block. Each block (component) and arrow (interface) has assigned to it a color which designates the status of that component/interface. Red means "this component is in trouble - need help!". Green means "everything is ok - nothing to be done here" and yellow is somewhere inbetween.

	Each block and interface is also assigned an owner (indicated by the small white boxes with the owner's initials in it). Cross-hatched blocks denote a block that is not a high priority at the moment.		Each block and interface is also assigned an owner (indicated by the small white boxes with the owner's initials in it). Cross-hatched blocks denote a block that is not a high priority at the moment.