Software Engineering with an Agile Development Framework/Whole process/Prototyping

System metaphor

An overview of the revolutionary prototyping methodology throughout process Specific questions Test logs and answers Discussion with client

In the traditional waterfall model, very little coding was performed the until the Implementation stage - a long way through the project. Such structured developments work best when:

- a set of high quality, stable user requirements exist

- the developers have previously built similar systems

- the project is not very complex

These characteristics are rare, especially in student projects.

In Rapid Application Development, on the other hand, coding starts almost on day one, the developed system is, by definition, used to describe its own requirements. This works well when the system is not very complex an incremental build is feasible, that is, each functional component can be added to the system without disruption.

We have already identified that the Agile Development Framework a compromise between structured and agile methods, here we do it again, and describe the ADF as a revolutionary prototyping methodology.

Three components: prototyping; methodology and revolutionary (OK, slightly different order).

Let’s start with what a prototype is not: it is not the name we give to a failed first attempt: a prototype is something we do on purpose in order to answer a specific question.

A prototype is defined by Sallis et al (1995) as a “working model”. This suggests a level of abstraction: the “working” suggests that the system functions - the “model” suggests that it doesn’t. Together this means that a prototype is a cutdown version, the bits we need are there, the bits we don’t - are cut away. Determining what it is that we need is determined by the question we are trying to answer.

This is a methodology, it is not hacking. A hacking approach is one where, given a problem, you sit down and start programming. This might work for tiny projects or for hobby development where it alright to figure out the specifications as you go and adapt the code. It does not work for more complex systems where the need to rework generates high costs at a late stage.

The prototyping model has several advantages;

- Ability to place a functioning and useful system in hands of users quickly

- Information requirements do not have to be completed before effort starts

- Ability to try out ideas without high risk or cost

- Increase in users’ interest and understanding in process

- Increase in users’ interest and satisfaction with final system.

The most important aspect of a prototype is that it adds to your knowledge. It should be developed with that in mind. This is where the rigour of prototyping comes in. There are several complete prototyping methodologies such as Dynamic Systems Development Method (DSDM) but we use a more tried and tested approach: scientific method.

Question: sometimes formulated into a hypothesis

Method: a carefully designed test to give an answer to that question (and nothing else, the notion of ‘barely sufficient’ applies here)

Evaluate answer

We also argue for an revolutionary approach to prototypes. This means that while we learn from each prototype, little, if any of their construction is carried forward. This is sometimes referred to as “throwaway prototypes”.

The concept of throwaway prototypes was applied to computing by Brooks in his famous search for a magical silver bullet in Mythical Man Month (1975) where he argued “plan to throw one any, you will anyhow”. While the book (and its advice) is still highly regarded, this quote is now regarded (including by Brooks) as bit simplistic. His argument assumed a standard waterfall model but where you have two tries at getting it right.

Throwaway prototypes avoid some of the potential disadvantages of prototypes:

- the danger of users being unwilling to give up the prototype is avoided. As prototypes are explicitly used in order to answer specific questions, the users know that from the outset that this is not “the” system. This means you are not put in the position of saying “you know that system we delivered a few months ago, well it turns out it was quite buggy so here’s a new one”.

- the danger of prototypes becoming a substitute for analysis is avoided as the prototypes are explicitly for the purpose of analysis and design.

- the danger of work arounds and quick fixes becoming entrenched in production code is avoided as ideas and techniques are pushed forward, not actual code. We do need to be careful to recognise the difference between prototype and production. A production system will have quality code, validation, backup, recovery etc, while a prototype might have none of these things.

Role throughout development process

The figure below shows the role of construction and prototyping throughout the development process.

Examples

Case study Familiarisation Tours

Group: Matthew Hamilton for Dunedin Visitor Centre Familtrack provides a platform for collation of familiarization tour experiences from the travel consultants. This system incorporates input screens, management reports and generation of webpages about visitor sites and experiences. Familtrack increases the available Visitor Centre resources; money spent on familiarisation tours is optimised by the availability of past familiarisation tour information. Matt describes his client centred prototyping approach: “ From the start our team wanted to include the client as much as we could in the development process. There is a risk that the client will not follow the development process. This could result in a misalignment of concepts ideas. We thought this would reduce the possible risks involved. To address this problem we implemented design and testing of the interface with the client. Some mock-ups wire frames were created. A simple web site was created to demonstrate the interactivity and actions of the application. This was received well by the client and actually brought about a redefinition of the application’s focus. A few of the interfaces were developed with the clients input. Looking back this was a very demonstrated to me when another project group was having difficulty with their client. The client was expecting something different from what was presented. ”

Force Sensors