Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

 

Page Tree Search

Page Tree

 

toc 

minLevel3

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.

Table of Contents
maxLevel3

Meetings

2012

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:
- High quality features -  Updated working specs - Missing critical tests - User documentation

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

- Eat our dog food.  Use the feature for "real" analysis or work. - Enter a sample mission, or tests from the test repo through the GUI then create variations and explore the maturity of the implementation. - Look for failing regression tests in nightly reports and check in bugs if they are not already tracked. - Document all known issues at the beginning of the feature finalization in the feature spec and pre-triage with team input

Track

- Check in new bugs in our bug tracker using the policy described here - Use the JIRA ticket named after your feature to track minor to-do and discussions. For example, for Report File use GMT-2653 - For "large" or "significant" issues, create separate tickets

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:

- Does every requirement map to a completed feature? - Does every feature map to a requirement? - Are the requirements clear? - Are the requirements testable?

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

Command template for user's guide Resource template for user's guide

Test

Documentation

 

Other Links