Murray Wiki - User contributions [en]

Group Hiking Trip

2006-07-30T01:25:56Z

Dvangogh: /* Backpacking Trip */

= Backpacking Trip =
Mary and Zhipu are organizing Murray's Group backpacking trip this year. They tried to narrow down the details according to Richard's "Devil" schedule and other tradeoffs. A tremendous response were received from group members and other friends. The trip will happen on August 3 - August 6, 2006. The trail is Rainbow Mtn. - Sawtooth Pass (near Mineral King, in south part of Sequoia National Park). A permit for 15 people has been reserved. Please contact Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu) to confirm your participation.

= Be Prepared =
* Start working out and keep yourself fit
* What to Bring: [[Packing List]]
* Menu Ideas: [[Trip Food]]
* Wilderness trip planning guide: [http://www.nps.gov/seki/bc_basic/bc_basics.htm Backcountry Basics]

= Details =

=== Dates ===
* ''' August 3 (Thursday) - August 6 (Sunday), 2006'''

=== Trail Description ===
* '''Rainbow Mtn. - Sawtooth Pass'''
* Nearby City: [http://www.nps.gov/seki/mkvc.htm Mineral King], CA (South Part of Sequoia National Park)
* Length: about 30 miles
* Trail Type: Loop
* Skill Level: Moderate/Hard
* Duration: Arrive Mineral King at Wed. night and use 4 days to finish the loop
* Maps: [[Media: pdf]]
* Driving Time: 5.5 hours
* What the Guidebook Says: "Two scenic passes over the Great Western Divide, forested canyons and beautiful lakes with excellent fishing make this Sequoia National Park's most popular loop from Mineral King."

=== Trip Itinerary ===

* Day 0 (Aug. 2, Wed.): Driving down to Mineral King in the afternoon and stay in Cold Spring camping site.
* Day 1 (Aug. 3, Thu.): Mineral King to Lower Franklin Lake. 6 miles, 2480 ft ascent
* Day 2 (Aug. 4, Fri.): Lower Franklin Lake to Little Claire Lake. 7 miles, 1480 ascent, 1350 descent. Early in the day go over Franklin Pass (11,800 ft)
* Day 3 (Aug. 5, Sat.): Little Claire Lake to Upper Lost Canyon. 9 miles, 1400 ft ascent, 1200 ft descent
* Day 4 (Aug. 6, Sun.): Upper Lost Canyon to Mineral King. 8 miles, 1400 ft ascent, 3760 ft descent. Go over Sawtooth Pass (11,600 ft)

= Participants =

The following people have send their responses:
* Mary Dunlop ('''Confirmed''') - Prefer D1, D2, T2
* Zhipu Jin ('''Confirmed''') - Prefer D1, D2
* Richard Murray ('''Confirmed''') - I like the Mineral King option, if it is available (less driving, more hiking). Prefer T2
* Domitilla Del Vecchio ('''Confirmed''') - Prefer D2
* Jean Charles Delvenne ('''Confirmed''') - Prefer D3
* Henrik Sandberg ('''Confirmed''') - Prefer D3, D2
* Ziad Fares ('''Confirmed''') - Prefer D1, D2
* Elisa Franco (with Stefano) ('''Confirmed''')- Prefer D2, T2
* Lars Cremean ('''Confirmed''')- Prefer T2
* Sawyer Fuller ('''Confirmed''')- Prefer T2
* Dave van Gogh ('''Confirmed''')- Prefer D2, T2
** Has: stove (whisper lite), 3-man tent (pretty heavy), compass, water jug, trowel
** Eats: anything
** Sleeps: anywhere (tarp is fine)
** Drives: pickup truck - seats 2 + lots o' gear. Lars and I are driving up Wed @ 5pm from Chatsworth. I can come to Pasadena Tuesday night to pick up gear if needed.

If your name isn't on this list and you still want to join us, please send an e-mail to Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu).

Group Hiking Trip

2006-07-30T01:24:43Z

Dvangogh: /* Participants */

= Backpacking Trip =
Mary and Zhipu are organizing Murray's Group backpacking trip this year. They tried to narrow down the details according to Richard's "Devil" schedule and other tradeoffs. A tremendous response were received from group members and other friends. The trip will happen on August 3 - August 6, 2006. The trail is Rainbow Mtn. - Sawtooth Pass (near Mineral King, in south part of Sequoia National Park). A permit for 15 people has been reserved. Please contract Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu) to confirm your participation.

= Be Prepared =
* Start working out and keep yourself fit
* What to Bring: [[Packing List]]
* Menu Ideas: [[Trip Food]]
* Wilderness trip planning guide: [http://www.nps.gov/seki/bc_basic/bc_basics.htm Backcountry Basics]

= Details =

=== Dates ===
* ''' August 3 (Thursday) - August 6 (Sunday), 2006'''

=== Trail Description ===
* '''Rainbow Mtn. - Sawtooth Pass'''
* Nearby City: [http://www.nps.gov/seki/mkvc.htm Mineral King], CA (South Part of Sequoia National Park)
* Length: about 30 miles
* Trail Type: Loop
* Skill Level: Moderate/Hard
* Duration: Arrive Mineral King at Wed. night and use 4 days to finish the loop
* Maps: [[Media: pdf]]
* Driving Time: 5.5 hours
* What the Guidebook Says: "Two scenic passes over the Great Western Divide, forested canyons and beautiful lakes with excellent fishing make this Sequoia National Park's most popular loop from Mineral King."

=== Trip Itinerary ===

* Day 0 (Aug. 2, Wed.): Driving down to Mineral King in the afternoon and stay in Cold Spring camping site.
* Day 1 (Aug. 3, Thu.): Mineral King to Lower Franklin Lake. 6 miles, 2480 ft ascent
* Day 2 (Aug. 4, Fri.): Lower Franklin Lake to Little Claire Lake. 7 miles, 1480 ascent, 1350 descent. Early in the day go over Franklin Pass (11,800 ft)
* Day 3 (Aug. 5, Sat.): Little Claire Lake to Upper Lost Canyon. 9 miles, 1400 ft ascent, 1200 ft descent
* Day 4 (Aug. 6, Sun.): Upper Lost Canyon to Mineral King. 8 miles, 1400 ft ascent, 3760 ft descent. Go over Sawtooth Pass (11,600 ft)

= Participants =

The following people have send their responses:
* Mary Dunlop ('''Confirmed''') - Prefer D1, D2, T2
* Zhipu Jin ('''Confirmed''') - Prefer D1, D2
* Richard Murray ('''Confirmed''') - I like the Mineral King option, if it is available (less driving, more hiking). Prefer T2
* Domitilla Del Vecchio ('''Confirmed''') - Prefer D2
* Jean Charles Delvenne ('''Confirmed''') - Prefer D3
* Henrik Sandberg ('''Confirmed''') - Prefer D3, D2
* Ziad Fares ('''Confirmed''') - Prefer D1, D2
* Elisa Franco (with Stefano) ('''Confirmed''')- Prefer D2, T2
* Lars Cremean ('''Confirmed''')- Prefer T2
* Sawyer Fuller ('''Confirmed''')- Prefer T2
* Dave van Gogh ('''Confirmed''')- Prefer D2, T2
** Has: stove (whisper lite), 3-man tent (pretty heavy), compass, water jug, trowel
** Eats: anything
** Sleeps: anywhere (tarp is fine)
** Drives: pickup truck - seats 2 + lots o' gear. Lars and I are driving up Wed @ 5pm from Chatsworth. I can come to Pasadena Tuesday night to pick up gear if needed.

If your name isn't on this list and you still want to join us, please send an e-mail to Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu).

Group Hiking Trip

2006-07-28T20:02:28Z

Dvangogh: /* Participants */

= Backpacking Trip =
Mary and Zhipu are organizing Murray's Group backpacking trip this year. They tried to narrow down the details according to Richard's "Devil" schedule and other tradeoffs. A tremendous response were received from group members and other friends. The trip will happen on August 3 - August 6, 2006. The trail is Rainbow Mtn. - Sawtooth Pass (near Mineral King, in south part of Sequoia National Park). A permit for 15 people has been reserved. Please contract Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu) to confirm your participation.

= Be Prepared =
* Start working out and keep yourself fit
* What to Bring: [[Packing List]]
* Menu Ideas: [[Trip Food]]
* Wilderness trip planning guide: [http://www.nps.gov/seki/bc_basic/bc_basics.htm Backcountry Basics]

= Details =

=== Dates ===
* ''' August 3 (Thursday) - August 6 (Sunday), 2006'''

=== Trail Description ===
* '''Rainbow Mtn. - Sawtooth Pass'''
* Nearby City: [http://www.nps.gov/seki/mkvc.htm Mineral King], CA (South Part of Sequoia National Park)
* Length: about 30 miles
* Trail Type: Loop
* Skill Level: Moderate/Hard
* Duration: Arrive Mineral King at Wed. night and use 4 days to finish the loop
* Maps: [[Media: pdf]]
* Driving Time: 5.5 hours
* What the Guidebook Says: "Two scenic passes over the Great Western Divide, forested canyons and beautiful lakes with excellent fishing make this Sequoia National Park's most popular loop from Mineral King."

=== Trip Itinerary ===

* Day 0 (Aug. 2, Wed.): Driving down to Mineral King in the afternoon and stay in Cold Spring camping site.
* Day 1 (Aug. 3, Thu.): Mineral King to Lower Franklin Lake. 6 miles, 2480 ft ascent
* Day 2 (Aug. 4, Fri.): Lower Franklin Lake to Little Claire Lake. 7 miles, 1480 ascent, 1350 descent. Early in the day go over Franklin Pass (11,800 ft)
* Day 3 (Aug. 5, Sat.): Little Claire Lake to Upper Lost Canyon. 9 miles, 1400 ft ascent, 1200 ft descent
* Day 4 (Aug. 6, Sun.): Upper Lost Canyon to Mineral King. 8 miles, 1400 ft ascent, 3760 ft descent. Go over Sawtooth Pass (11,600 ft)

= Participants =

The following people have send their responses:
* Mary Dunlop ('''Confirmed''') - Prefer D1, D2, T2
* Zhipu Jin ('''Confirmed''') - Prefer D1, D2
* Richard Murray ('''Confirmed''') - I like the Mineral King option, if it is available (less driving, more hiking). Prefer T2
* Clancy Rowley - Prefer D1(with his wife), D3
* Domitilla Del Vecchio ('''Confirmed''') - Prefer D2
* Fei Wang - Prefer D1, D2, T1 (with Chunhui)
* Michael Epstein - Prefer D2, D3
* Jean Charles Delvenne ('''Confirmed''') - Prefer D3
* John Carson - Prefer D2, D3
* Henrik Sandberg ('''Confirmed''') - Prefer D3, D2
* Ziad Fares ('''Confirmed''') - Prefer D1, D2
* Elisa Franco (with Stefano) ('''Confirmed''')- Prefer D2, T2
* Sean Humbert - Prefer D1, D2, T2
* Lars Cremean ('''Confirmed''')- Prefer T2
* Sawyer Fuller ('''Confirmed''')- Prefer T2
* Ben Shapiro - Prefer D2, then D3
* Dave van Gogh ('''Confirmed''')- Prefer D2, T2
** Has: stove (whisper lite), 3-man tent (pretty heavy)
** Eats: anything
** Sleeps: anywhere (tarp is fine)
** Drives: pickup truck - seats 2 + lots o' gear. Lars and I are driving up Wed @ 5pm from Chatsworth. I can come to Pasadena Tuesday night to pick up gear if needed.

If your name isn't on this list and you still want to join us, please send an e-mail to Zhipu (jzp@caltech.edu) or Mary (mjdunlop@caltech.edu).

DGC75 Status Chart

2004-06-23T20:54:06Z

Dvangogh: =Project/Team Meetings=

= Caltech Project Management Toolset (CPMT) Status Chart =
The chart below shows the status of the tools and processes that are being developed for CS/EE/ME 75.

<center>[[Image:CPMT_Status_2004-06-19.jpg]]</center>

Color code:
* Green: well defined, documented, and implemented.
* Yellow: available, but needs work. Documentation may be missing.
* 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.

= CPMT Modules =

== [http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart 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

----

== [[DGC75_Status_Description|Status Chart]] ==
The status chart serves several purposes. It documents the system architecture, defines interfaces, assigns responsibilities, sets priorities, and communicates this information in an easy-to-read format. It's a simple idea, but very effective. Here's an example of a status chart used for the 2004 DARPA Grand Challenge.

[[Image:EmbsysStatus2Mar04-small.JPG]]

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.

Note the creative use of colors (yellow + red is not exactly yellow and not exactly red, but something in between), and the presence of the “Vehicle” and “Path Planning” blocks (which were detailed on separate status charts for those teams).

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

----

== [[DGC75_Timeline_Description|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?

----

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

* '''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).
* '''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,
** a brief description, and
** the name of the speaker(s).

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:

Before the meeting
* One person (the driver) is assigned to drive the meeting. They reserve the meeting place and send out an e-mail (at least 8 hours before the start of the meeting) to all participants including the meeting time (starting and ending), goals, and agenda.
* The driver ensures all tools needed for the meeting are in working order (e.g., whiteboard, dry erase markers, laptop projector, etc.) prior to the start of the meeting.
* The driver assigns a notetaker. This is preferably done before the meeting so the notetaker can come prepared (e.g., with a laptop). The best way to take notes is to create the wiki page during the meeting (if it exists for a particular project). The next best options are to create non-wiki webpage, type the notes in an e-mail, or hand-write the notes and transcribe them to an e-mail.
* The driver makes copies of notes or slides prepared for the meeting, enough for everyone attending.

During 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 walks through each of the agenda items, making sure the meeting ends on time.

After the meeting
* All presenters (including the driver) notifies the notetaker where to find the meeting slides and other prepared material. It is the notetaker's responsibility to obtain these materials (in case the presenters forget).
* The notetaker publishes the notes (preferably on wiki) and the presenters' slides (also on wiki, along with the notes) and sends an e-mail to all interested parties. All published material should be in either .pdf or ASCII format. The same material in two formats (e.g., .pdf and .ppt) is ideal.

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.

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.

----

== [[DGC75_Test_Description|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 =

== [[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]] ==

DGC75 Status Chart

2004-06-23T20:50:02Z

Dvangogh: =Project/Team Meetings=

= Caltech Project Management Toolset (CPMT) Status Chart =
The chart below shows the status of the tools and processes that are being developed for CS/EE/ME 75.

<center>[[Image:CPMT_Status_2004-06-19.jpg]]</center>

Color code:
* Green: well defined, documented, and implemented.
* Yellow: available, but needs work. Documentation may be missing.
* 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.

= CPMT Modules =

== [http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart 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

----

== [[DGC75_Status_Description|Status Chart]] ==
The status chart serves several purposes. It documents the system architecture, defines interfaces, assigns responsibilities, sets priorities, and communicates this information in an easy-to-read format. It's a simple idea, but very effective. Here's an example of a status chart used for the 2004 DARPA Grand Challenge.

[[Image:EmbsysStatus2Mar04-small.JPG]]

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.

Note the creative use of colors (yellow + red is not exactly yellow and not exactly red, but something in between), and the presence of the “Vehicle” and “Path Planning” blocks (which were detailed on separate status charts for those teams).

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

----

== [[DGC75_Timeline_Description|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?

----

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

* '''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).
* '''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,
** a brief description, and
** the name of the speaker(s).
The agenda should include

The following are best practices for meetings:

Before the meeting
* One person (the driver) is assigned to drive the meeting. They reserve the meeting place and send out an e-mail (at least 8 hours before the start of the meeting) to all participants including the meeting time (starting and ending), goals, and agenda.
* The driver ensures all tools needed for the meeting are in working order (e.g., whiteboard, dry erase markers, laptop projector, etc.) prior to the start of the meeting.
* The driver assigns a notetaker. This is preferably done before the meeting so the notetaker can come prepared (e.g., with a laptop). The best way to take notes is to create the wiki page during the meeting (if it exists for a particular project). The next best options are to create non-wiki webpage, type the notes in an e-mail, or hand-write the notes and transcribe them to an e-mail.
* The driver makes copies of notes or slides prepared for the meeting, enough for everyone attending.

During 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 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.
* At the end of the meeting, the driver presents the GOTChA chart.

After the meeting
* All presenters (including the driver) notifies the notetaker where to find the meeting slides and other prepared material. It is the notetaker's responsibility to obtain these materials (in case the presenters forget).
* The notetaker publishes the notes (preferably on wiki) and the presenters' slides (also on wiki, along with the notes) and sends an e-mail to all interested parties. All published material should be in either .pdf or ASCII format. The same material in two formats (e.g., .pdf and .ppt) is ideal.

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.

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.

----

== [[DGC75_Test_Description|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 =

== [[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]] ==

DGC75 Status Chart

2004-06-23T20:45:25Z

Dvangogh: =Project/Team Meetings=

= Caltech Project Management Toolset (CPMT) Status Chart =
The chart below shows the status of the tools and processes that are being developed for CS/EE/ME 75.

<center>[[Image:CPMT_Status_2004-06-19.jpg]]</center>

Color code:
* Green: well defined, documented, and implemented.
* Yellow: available, but needs work. Documentation may be missing.
* 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.

= CPMT Modules =

== [http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart 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

----

== [[DGC75_Status_Description|Status Chart]] ==
The status chart serves several purposes. It documents the system architecture, defines interfaces, assigns responsibilities, sets priorities, and communicates this information in an easy-to-read format. It's a simple idea, but very effective. Here's an example of a status chart used for the 2004 DARPA Grand Challenge.

[[Image:EmbsysStatus2Mar04-small.JPG]]

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.

Note the creative use of colors (yellow + red is not exactly yellow and not exactly red, but something in between), and the presence of the “Vehicle” and “Path Planning” blocks (which were detailed on separate status charts for those teams).

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

----

== [[DGC75_Timeline_Description|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?

----

== [[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]] ==
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
2. Agenda

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.

The following are best practices for meetings:

Before the meeting
* One person (the driver) is assigned to drive the meeting. They reserve the meeting place and send out an e-mail (at least 8 hours before the start of the meeting) to all participants including the meeting time (starting and ending), goals, and agenda.
* The driver ensures all tools needed for the meeting are in working order (e.g., whiteboard, dry erase markers, laptop projector, etc.) prior to the start of the meeting.
* The driver assigns a notetaker. This is preferably done before the meeting so the notetaker can come prepared (e.g., with a laptop). The best way to take notes is to create the wiki page during the meeting (if it exists for a particular project). The next best options are to create non-wiki webpage, type the notes in an e-mail, or hand-write the notes and transcribe them to an e-mail.
* The driver makes copies of notes or slides prepared for the meeting, enough for everyone attending.

During 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 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 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
* All presenters (including the driver) notifies the notetaker where to find the meeting slides and other prepared material. It is the notetaker's responsibility to obtain these materials (in case the presenters forget).
* The notetaker publishes the notes (preferably on wiki) and the presenters' slides (also on wiki, along with the notes) and sends an e-mail to all interested parties. All published material should be in either .pdf or ASCII format. The same material in two formats (e.g., .pdf and .ppt) is ideal.

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.

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.

----

== [[DGC75_Test_Description|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 =

== [[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]] ==

DGC75 Status Chart

2004-06-23T18:37:04Z

Dvangogh: =Status Chart=

= Caltech Project Management Toolset (CPMT) Status Chart =
The chart below shows the status of the tools and processes that are being developed for CS/EE/ME 75.

<center>[[Image:CPMT_Status_2004-06-19.jpg]]</center>

Color code:
* Green: well defined, documented, and implemented.
* Yellow: available, but needs work. Documentation may be missing.
* 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.

= CPMT Modules =

== [http://grandchallenge.caltech.edu/wiki/index.php/GOTChA_Chart 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

----

== [[DGC75_Status_Description|Status Chart]] ==
The status chart serves several purposes. It documents the system architecture, defines interfaces, assigns responsibilities, sets priorities, and communicates this information in an easy-to-read format. It's a simple idea, but very effective. Here's an example of a status chart used for the 2004 DARPA Grand Challenge.

[[Image:EmbsysStatus2Mar04-small.JPG]]

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.

Note the creative use of colors (yellow + red is not exactly yellow and not exactly red, but something in between), and the presence of the “Vehicle” and “Path Planning” blocks (which were detailed on separate status charts for those teams).

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

----

== [[DGC75_Timeline_Description|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?

----

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

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.

----

== [[DGC75_Test_Description|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 =

== [[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]] ==

DGC75 Status Chart

2004-06-23T18:28:48Z

Dvangogh: =Status Chart=

DGC75 Status Chart

2004-06-23T18:26:13Z

Dvangogh: =Status Chart=

DGC75 Status Chart

2004-06-23T18:25:34Z

Dvangogh: =Status Chart=

File:EmbsysStatus2Mar04-small.JPG

2004-06-23T18:22:06Z

Dvangogh: Status Chart - embedded systems March 2004

Status Chart - embedded systems March 2004