Print this Page

On this page...

  1. 1. STAR's Agile Approach
    1. 1.1 Submitting Requirements to Enhance Existing Standards
    2. 1.2 Submitting Requirements to Create New Standards
    3. 1.3 Publication Timelines

1. STAR's Agile Approach

STAR follows agile techniques when developing its code-based standards as well as technical specifications:

  • Small development iterations
  • Process adaptability
  • Continuous integration
  • Unit testing

1.1 Submitting Requirements to Enhance Existing Standards

All STAR Members are eligible and are encouraged to submit their requirements back to STAR for inclusion in the STAR standards. There are many benefits to submitting requirements back to STAR the least of which being reduction of one-off implementations that have to be supported.

Here's how it works:

Step 1: Download and complete an XML Modification Request Form.

Step 2: Request an account for STAR's online issue tracking system.

Step 3: Report a new issue in the issue tracking system attaching your modification request form.

Step 4: STAR Data Architects will contact you to set up a workgroup session via conference call (maximum 1 hour) to review your modification request. Your request will also be posted into STAR's Member Community Portal Discussion Forum. This is where workgroups review modification requests, post and answer questions, comments, concerns, etc.

Step 5: Once the workgroup as agreed to the requirements, STAR Data Architects will modify the schema accordingly. This can be an iterative process of modifying and reviewing. Schema milestones complete with documentation are published on a bi-weekly basis, with nightly builds available upon request.

Depending on existing workload priorities and the level of effort required to complete the request, the modification request procedure can take as little as one to two weeks to complete or as long as 2 months.

1.2 Submitting Requirements to Create New Standards

In addition to submitting requirements to enhance existing standards, STAR Members are also eligible and encouraged to submit value statements to create new standards. The process is almost identical with a few slight differences.

Here's how it works:

Step 1: Download and complete an XML Value Statement Form.

Step 2: Request an account for STAR's online issue tracking system.

Step 3: Report a new issue in the issue tracking system attaching your value statement form.

Step 4: STAR Data Architects will contact you to set up a STAR Point of Contact (POC) Review session via conference call (maximum 1 hour) to review your value statement request. Your request will also be posted into STAR's Member Community Portal Discussion Forum. This is where workgroups review value statements, post and answer questions, comments, concerns, etc.

It is the responsibility of the STAR POCs and the STAR Steering Committee to determine the priorities of the organization and therefore what development projects the organization should take on.

Step 5: Once the POCs have approved the development efforts a workgroup will be set up for all of those STAR Members wishing to participate.

Step 6: Workgroup members will be asked to complete a use case template.

Step 7: Once a use case(s) and corresponding sequence diagrams have been agreed upon, workgroup members will be asked to complete a data requirements template.

Step 8: Once the workgroup as agreed to a set of consolidated data requirements, STAR Data Architects will develop the schema accordingly. This will be an iterative process of developing, reviewing and modifying. Schema milestones complete with documentation are published on a bi-weekly basis, with nightly builds available upon request.

Depending on existing workload priorities and the level of effort required to complete a new standard, the development process can take as little as 2 months.

1.3 Publication Timelines

STAR officially publishes an approved version of its schema repository once year to the public. However, throughout the development year STAR makes available to its STAR Members bi-weekly milestones, release candidates and three draft repositories. The schedule is published at the beginning of each development year.

Here's how it works:

  • Night Builds - provide to individuals on an as needed basis only and at the discretion of the STAR Data Architects. These builds are not official, subject to change and are recommended for testing purposes only.
  • Milestone Builds - Provided to the entire STAR Membership on a bi-weekly basis throughout each of the draft cycles. These builds are not official, subject to change and are recommended for testing purposes only.
  • Release Candidates - Provided to the entire STAR Membership at the end of the draft cycle. During the Release Candidate phase, the schema repository is in a code freeze accepting no modification request. The purpose of the Release Candidate phase is to fix bugs only. There are typically two release candidates prior to the draft release. As with the previous build types, the release candidates are subject to change and are recommended for testing purposes only.
  • Draft Releases - Provided to the entire STAR Membership four times per year. These builds are not official, subject to change and are recommended for testing purposes only.
  • Final Releases - Provided to the public once per year in the May timeframe with an effective date of July 4th. The Final Release is a culmination of all of the development work done throughout the year. The publication of the Final Release is contingent on the approval of the The STAR Membership.