Page 231 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 11: Coding Process

Prototyping Notes
Prototyping is usually regarded as the building of a small system (or two) before building the
big one. The knowledge gained in either building or using the prototype is then used in building
the ‘real’ system. A good description of the prototyping approach, combined with risk analysis.

‘Rapid prototyping’ is used to describe the building of systems using software tools such as
code generators, report generators, or Fourth Generation Languages (4GL’s).

Prototypes are used to reduce risk in the applications area (a novel design, function or
performance), or to reduce risk in the user interface area. (The users should then recognise the
final system as what they had approved as a prototype.)
However, in a long development timescale, with several years between deliveries of prototypes,
the requirements may change extensively, so that it is difficult to relate new requirements to the
old prototypes. New hardware capacity, newer user interface styles and graphical capabilities
seen on personal computers can make a prototyped user interface seem very old-fashioned.
• Throw-Away Prototype
• Incorporated Prototype

• Incremental Prototype

The first programming languages were developed in the late 1950s.

11.2 Test Driven

Test Driven, also known as test first programming or test first development as a new move toward
to software development where the programmer have to first write a test that fails before writing
any functional code. This practice became popular with the birth of extreme programming (XP).
Test driven development is a programming technique which is applied by following a series
of steps repetitively. The first step is to quickly add a test, basically just enough code to fail.
next, the tests are run, often the complete test suite although for sake of speed only a subset of
the test suite may be chosen, to ensure that the new test does in detail fail. Then the functional
code is updated to make it pass the new tests. The next step is running the tests again. If they
fail, the functional code needs to be updated to pass the tests. Once the tests pass the next step
is to start over.

11.2.1 Test Driven Development Methodology
Test Driven Development (TDD) is a very simple methodology that relies on two main concepts:
unit tests and refactoring. TDD is basically composed of the following steps:
• Writing a test that defines how a small part of the software should act.

• Making the test run as easily and quickly as possible. Design of the code is not a concern;
the sole aim is just getting it to work.

• Cleaning up the code. A step back is taken and any duplication or any other problems
that were introduced to get the test to run is refectories and removed.
The TDD is an iterative process, and these steps are repeated a number of times until satisfaction
with the new code are achieved. TDD does not rely on a lot of up-front design to determine
how the software is structured. The way TDD works is that requirements, or use cases, are
decomposed into a set of behaviour that are needed to fulfill the requirement. For each behaviour
of the system, the first obsession done is to write a unit test that will test this behaviour. The unit

LOVELY PROFESSIONAL UNIVERSITY 225