The success of any large, and/or challenging software engineering project depends to a great extent on the use of a software development methodology. Using a well thought out methodology allows an ordered systematic development of the product. It creates a working environment in which each team member can communicate using a vocabulary defined by the methodology. It also facilitates the development in an ordered way with clearly defined stages which can be monitored communicated and managed to produce the end product robustly and efficiently.

There are numerous approaches and much debate about their effectiveness. I think of them as existing on a continuum of ‘agileness’ between Waterfall types, which are highly structured approaches and Agile methodologies, which are more flexible .but still provide a framework of meaningful steps. Although Waterfall is often discussed as a methodology in its own right I think of it as a family of methodologies which contrast those in the ‘Agile family’

Waterfall

Waterfall is regarded as a traditional approach. It divides the development cycle into rigidly defined steps, each of which must be completed before moving on to the the next step. The steps are carried out in strict sequence which is only departed from as a response to crises or problems.A typical sequence might be:

requirements analysis→ design → implementation → verification → maintenance.

Despite its poor reputation in today’s software development world, Waterfall can work well on projects with static requirements, where the end product is well understood.

We are not in this position. One of our products is a trust metric and as we have seen it is highly complex and nebulous idea which is the subject of a extensive body of academic research, which has yet to agree on a precise definition. No-one can be completely sure how it will work until it is implemented, tested and explored, so we must live with a lengthy beta period where requirements shift on a regular basis until we get it right, i.e. it works for everyone involved. We are also working on a separate (but synergistic) application that is trust dependant and so communication between and input from all the developers, users and stakeholders in the project is absolutely vital as is the ability to work in a way that can respond to this input. If we were to go with the Waterfall approach the development could get very muddled and become time consuming and costly. Our project will definitely run into problems and changes to requirements will be a regular feature as we learn more about the implementation of this complex idea.

Agile

To this end we will be adopting more agile methods which are less rigidly structured and better suited to small teams and rapidly shifting requirements. The Agile manifesto is a set of principles drawn up around 2001:

In short:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

• Our highest priority is to satisfy the customer through early and continuous delivery
  of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence
  and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

(from The Agile Manifesto: http://agilemanifesto.org/principles.html)

Agile methods depend on continuous contact with stakeholders, an understanding that even if the software is working it is not necessarily complete and must be tested and changed along with its requirement specifications. We need people to use the application to see what works and respond to their experience to get this right. As software developers we cannot fully comprehend this task and depend on our interactions with stakeholders in a continuous process of development, feedback, understanding and then more development. Agile gives us this mindset.

There are various methodologies that come under the Agile banner and one that provides a framework for excellent communication is Feature Driven Development an agile methodology originally devised by Peter Coad and Jeff de Lucas. For robust code, Test Driven Development is a de facto strategy and FDD is an excellent complement for this as the feature descriptors it depends on are useful for specifying acceptance, integration and unit tests

Here we give a simplified overview of our planned processes, which will be tailored to suite the needs of the development team members, but will run along FDD and agile principles. A more exhaustive treatment of FDD can be seen at http://www.featuredrivendevelopment.com/ or in Peter Coad’s book [1]

The process is started by a modelling of the application domain often in the form of UML, followed by a set of feature specifications of functions that fulfil a use case of a client (i.e. have value), but that are small enough to be completed within two weeks. Features are named using a template <action>the<result> <by | for | of | to> a(n) <object>[2]this is also often expressed as: <action> <result> <object>[1]. I prefer the first notation, which is more prescriptive and less open to interpretation and misunderstanding. The features are organised by grouping them into feature sets and management functions. Feature sets are expressed with the notation <action><-ing> a(n) <object>. Management functions further refine the categorisation and are expressed with the notation <object>management.

The features or feature sets, depending on the size of the team are then assigned to developers who build unit tests and code to implement the feature. Once all unit tests are passing the code is merged with the main codebase in the version control repository. The features list is then reviewed and the process repeated.

Our methodology will as we have said, be based on FDD with Test Driven Development (TDD), which will allow for a code base that can be robust enough to cope with change and refactoring. To this end,we plan to invest considerable effort in unit testing and will also conduct extensive acceptance and integration tests. The team will initially be quite small, but as the stakeholders and users increase software issues are likely to become increasingly complex and as more actors provide feedback and input so will the requirements. We have chosen our methodology carefully so that we have a combination of flexibility and robustness to cope with whatever this development journey throws at us.

[1] P. Coad, Java modeling in color with UML: enterprise components and process. Upper Saddle River, NJ: Prentice Hall PTR, 1999.