Intland's free requirements, development and test management hosting.
This server hosts 100.000+ users on the cloud!
Tags: 

OMS Project Management Guidelines For Using Codebeamer

Purpose

The purpose of this document is to set forth guidelines for using CodeBeamer to manage the OMS Project workflow. The goal of these guidlines are to be as Einstein stated, Everything should be made as simple as possible, but not simpler. With this in mind, the guidlines should describe a workflow that is :
  1. Understandable: Clear, obvious, and easy to understand and follow,
  2. Not reduntant: Eliminates redundancy of work and data entry,
  3. Efficient: Minimizes the number of things that need to be done to order and manage the workflow,
  4. Useful: Helps to organize work efficiently in order to deliver product in a timely and predictable manner.
  5. This is number

OMS Work Groups

OMS Project Team
The OMS project team is made up of code developers, project managers and business representatives.
  • Olaf David - Senior software engineer and analyst - CSU
  • Ken Rojas - Acting OMS Project Manager - NRCS
  • Jim Ascough - Technical representative for CEAP - ARS
  • George Leavesley - Research hydrologist - CSU
  • Roland Viger - GIS Specialist - USGS
  • Wes Lloyd - Software developer (graduate student) - CSU
  • Dan Meyer - Science and Technology Liaison - NRCS
  • Jason Restad - Lead Application Architect - NRCS
  • David Butler - Lead Data Mangement Specialist - NRCS
  • Jack Carlson - ARS research collaborator
OMS Agency Management Team
The OMS Agency Management team is made of representatives from ARS, NRCS and USGS. Other agencies may be added in future depending level of agency contribution made to OMS. Contributions as defiend as either in-kind and monetary or both.
  • Frank Geter - IT Manager for the NRCS Information Technology Center, Fort Collins Colorado
  • Laj Ahuha - Research Leader for the ARS Agricultural Systems Research Unit (ASRU), Fort Collins Colorado
  • Vacant - Manager, USGS, Denver Colorado
OMS User Community
The OMS user community is made up of frequent and committed users of OMS that have the desire and ability to contribute to the direction of OMS. There are "first row users" who are using OMS in selected modeling projects
  • Dennis Flanagan - Hydraulic Engineer, ARS, West Lafayette Indiana
  • Jim Ascough - Agricultural Engineer, ARS, Fort Collins Colorado
  • Steve Markstrom - Hydrologist, USGS, Denver Colorado
  • George Leavesley - Research Hydrologist, CSU, Fort Collins, Colorado
  • Tom Pagano - Hydrologist, NRCS, Portland, Oregon

OMS Project Workflow Hierarchy

In CodeBeamer the OMS Project will have the following hierarchy of elements:
  • Milestones
      • Requests
      • Defects

All these elements are represented as Trackers. Establishing associations between them brings them into the hierarchical order shown above.

Element Definition

Milestones
A milestone is a deliverable product. In the OMS project context, a milestone is a software or document release that meets the desired requirementsand/or contains identifed bug fixes. A milestone is described by the requirements that it satisfies and/or bugs that it fixes therefore a milestone needs to be linked to one or more requirements and/or bugs in CodeBeamer. An example of milestone would be "Release version 1.2a of the OMS platform."
Defects
A defect is an identified, verifiable, and repeatable error in functionality of software or an error in documentation. An example would be, "Install of OMS on a CCE computer fails if the Virus Scanner is running". A bug is resolved by completing one or more work tasks therefore a bug needs to be linked to one or more work tasks in CodeBeamer. A bug should also be associated to a request if that is the original source where the the bug was identified.
Requests
A request is a informal description of features, enhancements, and/or bugs/errors in software or documentation. An example would be, "Add the ability to do iterative processing to converge upon a solution in OMS". An example of a bug releated request would be, "Everytime I hit enter on the compile button the system crashes!".

Workflow Description

The following describes who sets priorities for milestones, interconnectivity of the various hierarchical elements, how work assignments are made, and when items are resolved and closed. In general, milestones are defined by an identified list of requirements and bugs. Each requirement is defined by a list of one or more features and each feature is defined by a list of one or more work tasks. Bugs are defined by a list of one or more work tasks. Requests for changes, be they enhancements or bugs, are made to the request element. The OMS Project team takes these requests and formulates them into requirements or bugs and enters them into the appropriate place the OMS hierarchy. For detail workflow process for Defects and Requests see Defect/Request

Milestones
Milestones are agreed upon by the OMS Project Team, OMS User Community and OMS Agency Management Team. They must have a completion date and be linked to requirements and/or bugs in CodeBeamer that fully describe what is to be delivered. Milestones are resolved when all assocated work tasks via requirements, bugs and features have been committed to the SCM; however, milestones are not closed until all related work tasks have been independently verified as completed by the OMS project manageer.
Defects
Bugs are indentified and described by the OMS Project Team with input submitted by the OMS User Community and OMS Project Team to the OMS Requests element. Bugs become a priority when they are associated from a milestone. Bugs are resolved when all work tasks associated to the bug have been been committed to the SCM; however, bugs are not closed until all related work tasks have been independently verified as completed by the OMS project manageer.
Requests
Requests are submitted by the OMS User Community and OMS Project Team for features, enhancements or bug fixes. Requests are resolved when an associated requirement or bug has been been resolved and closed when an associated requirement or bug has been closed.
  • Nice to maintain, we should only have one installer.
  • Installation is platform independent.
  • Share these install elements, so Frank and I can help fill in the blanks in the screens.