You are here

Release Process

Subscribe to Syndicate
The agile development methodology is ideal for customer driven software delivery. It involves one or more iterations a feature under the principle that the first set of requirements can only address things we suppose to be correct. Quickly building a prototype and showing it to team members and customers leads to other requirements that may, or may not get included.

There are a number of development methodologies that can be used in agile development such as Extreme Programming or Scrum. The particular process that we use the most is the Agile Unified Process although, by definition, agile programming can draw from various methodologies as the need dictates.

General Principles of Agile Unified Process

The links will take you to the implementation of the process in our product development process

  • Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.
  • Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.
  • Test. Perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
  • Deployment. Plan for the delivery of the system and to execute the plan to make the system available to end users.
  • Configuration Management. Manage access to project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.
  • Project Management. Direct the activities that takes place within the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget. We use FogBugz to track development tasks in a particular development release iteration, status and additional notes about them.
  • Environment. Support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.
All stages above take into account PA-DSS requirements in the Product Development Process and the requirement to fill the PA-DSS worksheet if PA-DSS is impacted. However, by design, the only release could affect PA-DSS is the Major Release as design and product releases will take all pains to avoid such implications.

Philosophies

The Agile UP is based on the following philosophies:

  • The staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are interested, but doesn't force them upon you.
  • Simplicity. The Agile UP conforms to the values and principles of the agile software development and the Agile Alliance.
  • Focus on high-value activities. The focus is on the activities which actually count, not every possible thing that could happen to you on a project.
  • Tool independence. You can use any toolset that you want with the Agile UP. The recommendation is that you use the tools which are best suited for the job, which are often simple tools.
  • The AUP an be tailored as required to meet the needs of the development release iteration.

Releases

The Agile Unified Process distinguishes between two types of iterations. A Development Release Iteration results in a deployment to the Quality Assurance and/or Demo area. A Production Release Iteration results in a deployment to the Production area.

A development release iteration is tested manually and/or with automated software tests checked into the VCS and built for QA who verify it works as designed. Any development release iteration can be sent to a customer after QA testing but is not advertised and may not have release notes.

A succession of the development releases, that becomes the Production Release will have release notes, implementation notes, documented interactions, etc. as per the examples in Version Release Notes