6.6 Prototyping 125
1. Requirements capture
During requirements capture, a prototype is used to pin down and refine a user’s require- ments for the system. It can also be used during design to test the user interface – assessing
how well the user can use and navigate around the system. According to Knott and Dawson 1999: 42, ‘Prototyping provides an effective method for generating feedback
about what is good and what is bad about an idea and it is often the only really effective method for doing this’.
2. Experimental prototyping
Experimental prototyping is used when one is unsure about the technical solution to a problem. For example, if you are developing a new algorithm, working in an emerging
field, working on a new hardware platform, or using a new application or programming language, it is often useful to produce an experimental prototype to assess the feasibility of
your proposed solution. You might discover, for example, that you will need to re-design your proposed solution because it is inefficient and runs too slowly, or you might discover
that your assumptions about the system were incorrect and an alternative strategy needs to be undertaken. Alternatively you may discover you don’t have the technical ability to
use the programming language or the hardware platform or software application you are intending to employ.
There are two things you can do with a prototype once you have developed it. You can throw it away and start the development of the system from scratch throw-away prototyp-
ing , or you can develop evolve the prototype into the final system evolutionary
prototyping . These two approaches to prototyping are discussed in the following sections.
6.6.2 Throw-away prototyping
There are a number of approaches you can use to develop a throw-away prototype, depend- ing on what you want to achieve, explore with the user or experiment with. The following
are some ideas you might want to use in developing your own throw-away prototype.
n
The prototype need not be developed on the same hardware platform as the final system. For example, you could mock-up some sample screen designs using a word-processor or
drawing package. If you were going to develop a system for a Pocket PC or a mobile tele- phone, you might develop a mock-up using an emulator on a PC first.
n
You might develop a prototype in a different programming language. For example, if you wanted to develop an experimental prototype to evaluate a new algorithm you
might test out that algorithm by developing it quickly in C first. You might then throw this code away before re-coding the final system with a graphical user interface
in Visual C++™. Alternatively, you could develop a user interface for a multimedia product using a web-page editor.
Knott and Dawson 1999 discuss the following techniques for [throw-away] prototyping:
n
You could simplify the system by partitioning the program such that a prototype could be built for part of that system. For example, you could prototype the graphical
user interface first, leaving the underlying functionality until later.
126 Chapter 6
n Software development
n
Use a reduced database. You could quickly generate a test database for a system to provide an idea of how that system operates on particular data sets.
n
You can develop a much simpler version of the program that has simplified data han- dling and error checking – sacrificing quality and reliability. As the prototype is
merely intended to show the user what will happen when the right or wrong input is used, it need only handle one example of each for demonstration purposes.
n
You could use a modified version of another program or another system to illustrate your ideas. For example, if there is a commercial product that has some components that you
wish to incorporate into your own system, you could demonstrate this to your user and check what aspects of functionality they require and the type of interface they prefer.
Advantages
Throw-away prototyping has a number of advantages over conventional approaches. Knott and Dawson 1999 note the following:
n
Something tangible is produced quickly which keeps you and your user happy.
n
The tangible nature of the system helps the user to clarify their ideas and refine their requirements.
n
Misunderstandings, errors and omissions in the requirements can be sorted out.
n
It improves communication with the user. It is easier to look at a working model than a document.
n
The prototype can test the feasibility and usefulness of the product.
n
Alternatives can be compared using different prototypes.
Disadvantages things to be aware of
n
The throw-away prototype might look messy and unsophisticated and contain bugs. This might give a bad impression to the user.
n
The user might think your prototype is really good and may want you to develop it into the final system, even though you had intended to throw it away. As a conse-
quence you will end up building your final system on perhaps poorly structured code.
n
If you develop the throw-away prototype on a different system or in a different pro- gramming language you may not spot a technical issue that will be difficultimpossi-
ble to overcome on the target system.
It can take a lot of effort and commitment to develop something that you are eventually going to discard. For this reason students often prefer to use an evolutionary prototyping
approach to develop their systems. This approach is discussed in the following section.
6.6.3 Evolutionary prototyping
The evolutionary prototyping approach differs from the throw-away approach in that the prototype is not discarded but developed it evolves into the final product. At first
glance it might appear similar to the build-and-fix approach – something is built, assessed and modified until the final system is released. However, the evolutionary approach is
6.6 Prototyping 127
Figure 6.6
The evolutionary prototyping model
Source: Adapted from Ould 1999.
much more defined than the build-and-fix approach. An initial specification for the system must be investigated and produced, and the process must follow a planned series
of releases evolutions. You are also aware from the start that your program is going to evolve so it must be designed and structured logically from the outset with suitable
comments, variables, data structures and so on. This will ensure that changes can be incorporated ‘gracefully’ and you are not left with masses of ‘spaghetti code’ that you
have to unravel to make simple modifications.
Figure 6.6 adapted from Ould, 1999 illustrates the evolutionary process – in this case showing three releases of a system. Notice that you complete a preliminary requirements
capture for the system and pursue the remaining stages of the conventional process in order to develop the first prototype System Version 1. This works in much the same way as a
reduced version of a conventional waterfall-type approach. Following feedback on what is right, wrong or missing and could be improved or changed from the user on this prototype,
you can then go back and readdressadjust the requirements before developing evolving the second deliverable of the system System Version 2. In this way the system is seen to
evolve from an embryonic core into the final system. You might decide to focus each deliv- erable on different aspects of the system, investigating each component in turn, in a similar
fashion to the incremental approach. However, in this case you are explicitly looking to change the requirements and design of the system based on user feedback. The requirements
and design stages in Figure 6.6 are not as big as detailed in phases 2 and 3 of the process compared with phase 1 as the bulk of this work has been done during that first phase. Also,
the system is getting larger as it evolves in phases 2 and 3 and its functionality increases. Note that the evolutionary approach is sometimes referred to as iterative development.
The advantages and disadvantages of the evolutionary prototyping approach are simi- lar to those of the throw-away prototyping approach. However, in the evolutionary
model you do not lose code you may have spent a lot of effort developing. Contrary to the throw-away approach you must be careful to produce well structured and commented
code that can be evolved into the final system. This means that your first prototype must be well thought out and cannot be a ‘quick and dirty’ throw-away artefact.
128 Chapter 6
n Software development
•
6.7 Agile methods
The term agile methods was adopted in 2001 by a group of eminent software engineers at a meeting in Utah, USA. It refers to approaches to software development that reduce
risk by delivering software systems in short bursts or releases. In contrast to ‘heavy weight’ development approaches, such as the Waterfall Model in which the delivery of
a working system can take many months, if not years to be released, the concept behind agile methods is to release working systems to the user in a matter of weeks.
Although each iteration might not release a fully working system to the user at the end of each cycle, the aim is still to have an available release at the end of each iteration. The
evolutionary prototyping approach and incremental model introduced in the previous sections are, from a process point of view, agile methods.
The other main characteristics of agile methods that differentiate them from older, more conventional models include: their emphasis on smaller development teams
which are invariable working together in open plan offices; and face-to-face commu- nication with the users who are quite often based in the same working environment as
the developers.
Agile methods are well suited to projects that have unclear or rapidly changing require- ments; the project team is fairly small but highly competent and can be trusted; and close
interaction with the user must be possible. A number of key principles were established by the founding group – referred to as
the agile manifesto see http:www.agilemanifesto.org
. These principles include:
n
satisfying the customer through early and continuous delivery of valuable software;
n
welcoming changing requirements;
n
short iterative timescale of weeks;
n
close working relationship between developers and users;
n
face-to-face conversations rather than detailed documentation;
n
working software is the measure of progress;
n
teams are self-organizing;
n
teams reflect on how they might improve themselves regularly. Because of the reduced amount of documentation agile methods produce, they have
come in for some criticism. However, for smaller projects student projects, for exam- ple the principles can lead to the development of software that goes a long way to
meeting the users’ requirements.
•
6.8 Extreme programming XP
Extreme programming is a software development approach that encompasses many of the ideals of agile methods. It was introduced in the 1990s in an attempt to improve the way
in which software is developed. It is designed for teams of between two and 12 members, so it is ideally suited for student projects. For more information on this method you should
refer to the Extreme Programming web site at:
http:www.extremeprogramming.org .
6.9 Configuration management 129
Extreme programming is an approach that is well suited to projects in which the requirements are likely to change. The approach actively encourages the users to be
involved with the development process and anticipates the positive influence they will have on requirements capture. It emphasizes teamwork and, in the case of student
projects, encourages the users, supervisors and the project team to work together towards a common goal of developing quality software. According to Wells 2006,
extreme programming ‘improves a software project in four essential ways; communica- tion, simplicity, feedback and courage’. One of its principles is to deliver the software
early, obtain feedback on the system and implement any required changes. In some ways the approach is similar to that of evolutionary prototyping although there is much more
guidance on how the team should work together and how testing should be pre-planned than is provided by the evolutionary model.
Although the detail of this approach’s methodology is beyond the scope of this book, some if its guiding principles are worth remembering; involve the user in the project,
pre-plan testing before coding, deliver the system early and ensure strong communica- tion between all stakeholders.
•
6.9 Configuration management
One thing that you must be careful to control when pursuing an evolutionary or incre- mental approach, or in a team project when a number of people are working on differ-
ent parts of the system simultaneously, is the system’s configuration. Configuration management is used to control the different versions of a system that are produced
as the system develops. It is closely related to version control and revision control. In large industrial projects configuration management is an important activity and typically
involves four stages:
1. Configuration identification: identifying the attributes that define the item you
are hoping to control – what makes it as it is – and setting this as a baseline.
2. Change control: managing and approving changes to the item and adjusting the
baseline.
3. Status accounting: recording the configuration baselines.
4. Configuration audits: ensuring that changes to configuration do what they state
they will do and the system continues to satisfy the requirements it does not drift. For student projects a comprehensive configuration management system is unneces-
sary. However, as you develop and release new versions of the system you must make sure that you keep track of these versions; what changes have been made, who has made these
changes, who has received them, where they are savedbacked-up to, etc. If something goes wrong with a ‘release’ it is useful to be able to go back to the previous version to try
to determine what has gone wrong. Make sure that you date stamp each version of the program that you produce no matter how small the change that is made – perhaps
by including the date on a splash screen or main menu. You might also consider updating the version number too particularly for major changes. This will allow you to keep track
of the latest version of your system and, as you make frequent back-ups, which back-up is the most up-to-date. Also, for team projects, keep a note of which team members are
Kategori