Software Development Lifecycle

This document explains Arts Management Systems Software Development Life Cycle. This document is not intended to be all inclusive but rather a high level outline of our processes. Detailed processes are described in associated ‘living’ documents. This document is for internal use only and is not to be distributed.

Wikipedia presents 3 basic methodologies for software development as illustrated in this picture. There is another interesting description of other methodologies and variations on www.noop.nl if it is of interest.

The nature of Omnis Studio as a development tool lends best to the prototyping methodology which is more recently known as Agile Development

From Wikipidia, agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Agile Principles

Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Some of the principles behind the Agile Manifesto are:

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (days or weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Daily conversation is the best form of communication (co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

Source: Wikipidia

Contrasted with Waterfall Methodology

Agile development has little in common with the waterfall model. The Waterfall methodology is the most structured of the methods, stepping through requirements, analysis, design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.

Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early and continually improving it and/or adding further functionality throughout the life of the project. If a project being delivered under Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a huge resources bill. With Agile, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.

Release Definitions

Software Releases are typically comprised of new features and defect corrections. The number of features and / or defect corrections addressed in any release is dependent upon several factors including severity of the issue, timing, development effort required, competitive advantage, etc.

Using agile development, Arts Management Systems strives to be in the position of being able to release a new version at any time to respond to clients in an 'agile' manner. By definition, this means that small, incremental units of work are done at one time, checked in, QA'd and set aside for release. It involves coordination amongst the teams to defines what is working, and what is not, isolate the scope and do a build only on what we determine to be working, even if it does not meet the full intended scope. After all, some working software for the customer is better than none.

That being said, releases are generally of 3 types:

  • Development Release: this release typically addresses a very critical need for a specific customer.
  • Production Release: this release is made available to customers when an arbitrary number of work items have been completed that meet customer needs, however significant or insignificant in scope. There will generally be at least one functional release per month that will have comprehensive release notes and back-out strategies. Clients do not need to implement the functional release unless there are items of interest to them. Functional releases are alway cumulative so skipping one release and implementing the next always gives the client the cumulative effect of all functional releases.
  • Major Release (the major release number is incremented): this release is scheduled to coincide purely with PA DSS certification because the PCI standards council has decided in an arbitrary manner that applications can only increase the release number at the time of their PCI audit. For Arts Management, that will mean a new release number every three years.
The objective is to only include changes that affect PA-DSS Certification status in a Major Release and not more than once per year. A PA-DSS Checklist has been incorporated into our release process to assist in identifying impacts to our payment processes at the onset of a project and throughout the development cycle. Appropriate actions and decisions can be made based upon the assessment during the development cycle.

Release Process

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