Software Development Methodology

The challenge

We do not have a statement of requirements, so we need an agile spirit. We also have a development team who are scattered at a number of different locations, so we need some formal methods.

... distributed code assembling introduces a new layer of complexity: Two teams are now working on a single code base. Such shared data or source repositories require a more coordinated management style. Coordination of releases becomes more complex. Testing becomes more complex. Little things like design standards, coding standards, style guides, defined life-cycle processes, crisp documented specifications, and well-documented requirements all become the center of a common ethos that keep development possible.

from Distributed Development: Lessons Learned by Michael Turnlund. This article is useful background on our choices for methodology.

Elicitation of requirements

A complete requirements document contains all the information developers need to code the system. Not unusually, this project has started without one. A requirements document will still be a big asset for the project, even if it is only finished at the same time as the code. See A Rational Design Process: How and Why to Fake It by Parnas and Clements for background discussion on this.

The data model provides a description of the application domain. To complete the requirements we will document use cases as described in Structuring Use Cases with Goals by Alistair Cockburn. This article is part of our methodology. The scientific goals have been specified by the customers, and we will develop use cases partly by asking users to elaborate them based on the goals.

Life cycle

As urgent requirements are identified, we will agree sets of functionality for incremental delivery. This will allow us to also determine use cases bottom up, in conversation with end users who have particular pressing needs. Version 0.1 of PIMS will be planned to lay the foundations of this, by creating a common framework allowing independent development of different components.

The benefits of incremental delivery are:

• It means we know clearly which features are complete.
• It helps show the need for for quality assurance, because the features under development are going to be in use soon.
• It keeps a constant reality check, from customer feedback.
• The delivered facilities give a basis for discussion of further requirements, where specification from a blank screen is difficult.
• It may help maintain the alliance between stakeholders, by ensuring that each has some benefits coming.
• It makes explicit the process of negotiation between different stakeholders over the next deliverable.

The costs of incremental delivery are:

• It sometimes means prioritising urgent work above important work.
• When a feature is implemented for early delivery, some of the work has to be redone later.

Criteria to use when choosing features for a deliverable are

• meeting users' most urgent needs
• resolving the greatest risks early
• avoiding doing work which will mostly have to be repeated

One force that works against incremental delivery is that past experience of failed projects makes users suspect that features that are postponed now may never be delivered. We can only counter this by delivering reliably.

See Operational Prototyping: A New Development Approach by Alan M. Davis, IEEE Software vol 9 part 5 pp70-78 (1992). This article is part of our methodology.

Metrics

PIMS source code will include comments with links to the requirements documentation of each use case scenario it implements, and test code will have similar comments.

In order to track the progress of the project, we will count the number of:

• use case scenarios documented
• use case scenarios which are implemented and have test cases
• unit tests (this will be our main measure of code size)
• lines of code (for comparability with other projects)
• defects found
• defects found and not yet fixed

Estimation

Choosing the use cases to be implemented in each release of PIMS, and agreeing the final scope of PIMS, relies on the development team being able to report an estimate of the work required by a particular use case.

We will keep a record of use cases implemented and the time it took, in order to help us make future estimates. This information cannot validly be used to evaluate individual developers' performance for a number of reasons, including the known large impact of office accomodation, sysadmin support, local mentoring, and other workplace issues. We will prevent it being misused by explaining these reasons, and also by not providing a facility to agregate results for a particular developer.

Communication within development team

The development team will be distributed at several sites. This makes communication very important, and is part of the reason why a written requirements document should be developed. The quality assurance procedure should help identify communication problems early.

We will also use some software tools to help communication:

• Source control: Subversion
• Email archive: eyebrowse
• Issue tracker: Roundup