| Page Tree Search |
|---|
| Page Tree |
|---|
Table of Contents minLevel 3
Meeting Minutes
This page contains links to minutes for GMAT's weekly team meeting. The minutes are stored as individual Google Documents. They are also collected into the GMAT Meeting Minutes shared folder.
Meetings
2012
- December 6
- November 29
- November 22 - no meeting
- November 15
- November 8
- November 1
- October 25
- October 18
- October 11
- October 4
- September 27 - no meeting
- September 20
- September 13
- September 6
- August 30
- August 23
- August 16
- August 9
- August 2
- July 26
- July 19
- July 12
- July 5
- June 28
- June 14
- June 7
- May 17
- May 10
- May 3
- April 26
- April 19
- April 12
- April 5
- March 29
- March 22
- March 15
- March 1
- February 23
- February 16
- February 9
- February 2
- January 27
- January 19
- January 12
- January 5
2011
Previous minutes are located at the GMAT Forums. The minutes were started based on this template, though generally each week is just copied over to the next. The template has not been kept up to date.
Minutes Workflow
The process of recording meeting minutes is as follows:
Meeting day
Send out an email to everyone with a link to the new document.
In the meeting
- Bring up the minutes on your laptop
- Record discussion and decisions for each item
- Submit tickets in JIRA for any action items
After the meeting
- Copy the previous week's minutes document and change the name to the new date.
- Change the sharing preferences to publicly-viewable and publicly-editable.
- Add a link to the top of the list above.
- Delete the following information from the new copy:
- Present column in the Attendees list
- Status, Discussion, and Decisions sections from the previous week
- Upcoming milestones that have passed
R2013a End Game QA Processes
See the System QA Tracking page for status tracking and links to the working documents
Overview, Goals, and Guiding Philosophy
We are in the end-game phase for GMAT v1.0 and our work product is R2013a (Production Release). To reach this goal, our primary work is to:
- Explore: Use GMAT and exercise your features
- Document: Describe final behavior in working specs and User Documentation
- Test: Complete critical system and beta testing
- Wrap up: Final inspections and migration
We've found that these activities are not necessarily sequential. As you test, you discover information that is useful to users and that should be included in specifications. When you document, you think of areas that could use extra exploratory or beta testing. You will probably make a few cycles through these activities or treat them as parallel activities.
GMAT has many, many tests. We are not starting from scratch, we are making a final pass. Beware of letting perfect be the enemy of good in your testing. It takes a disproportionate amount of time to find the last remaining bugs so balance value of testing with our schedule. Our documentation on the other hand, is not as thorough as our test coverage, and requires a lot of updating and expanding. Start from existing docs and consolidate and update when possible.
The sections below describe the work flow and deliverables for the Explore, Document, Test areas. The primary deliverables of this work are:
Explore
The first step is to simply explore the feature and document what you find. There is a placeholder in the "Explore" section of the feature spec to record a complete list of all known issues during the exploration phase. We use this list to do a pre-triage/sanity check to determine the state of the feature.
Explore
Track
Documentation
The goals of the documentation effort are:
- To provide working specs that define R2013a behavior
- To provide high quality end user docs
The basic workflow for documentation is illustrated below. Begin by consolidating existing material from old documents in working specifications and then update the specification for style and completeness. Completed draft specs are inspected by a developer, tester, and possibly another engineer. After all issues in the specs are resolved, the material relevant to users is included in end-user documentation and you can use the spec to evaluate existing test coverage.
Old Documentation
Historical and old documenation is currently listed in html help files and in a pdf file that we used to call "Quick Tables". While this information is not complete, it will provide a good start for completing specs described in the next section. Here are links to useful, but out of date, functional documentation:
Working Specs
In this section,we'll discuss how to write working specs that will be used to (1) define R2013a behavior, (2) evaluate existing test coverage, and (3) to write end-user documentation. We'll discuss each section of the working spec (Requirements, Functional Specifications, and Field Specifications) below. You'll need the following templates and historical documents for this work.
Requirements and Inspection
Move requirements from the GMAT Requirements spreadsheet show above into the appropriate section in the working spec. Inspect the requirements asking the following questions:
Send any issues found when reviewing to the SPH for CCB Analysis.
End-User Documentation
After specs are inspected and all issue are resolved, material relevant to the user is included in the User's Guide. We'll get to this later so I have not documented this step yet. -SPH
Test
Documentation
Other Links