FACULTY OF SCIENCES

Name Student Number

Yancy V Nthakomwa N0198789M
Donald Maziva N0198074X
Philani Mkhwananzi N0199106M
Onele Mabhena N0199164Y
Basildon Shumba N0196321C

Course code: SCS2104

Course Name: Structured Systems Analysis and Design
Program: Computer Science
Part: 2.1
Academic Year: 2020/2021
PROTOTYPE MODEL: ADVANTAGES
AND DISADVANTAGES
What is Prototyping Model SDLC?
Lets discuss what is prototyping model in Software Development is. Here, a
prototype is made first and based on it final product is developed. A prototype is a
model or a program which is not based on strict planning, but is an early
approximation of the final product or software system. A prototype acts as a
sample to test the process. From this sample we learn and try to build a better final
product. Please note that this prototype may or may not be completely different
from the final system we are trying to develop.
Need of Prototyping Model
This type of System Development Method is employed when it is very difficult to
obtain exact requirements from the customer(unlike waterfall model, where
requirements are clear). While making the model, user keeps giving feedbacks
from time to time and based on it, a prototype is made. Completely built sample
model is shown to user and based on his feedback, the SRS(System Requirements
Specifications) document is prepared. After completion of this, a more accurate
SRS is prepared, and now development work can start using Waterfall Model.
Advantages of prototyping

1. When prototype is shown to the user, he gets a proper clarity and feel of the functionality of the
software and he can suggest changes and modifications
2. This type of approach of developing the software is used for non-IT-Literate people. They usually
are not good at specifying their requirements nor can tell properly about what they except from
the software
3. When client is not confident about the developer`s capabilities of developer
4. Sometimes it helps to demonstrate the concept to prospective investors to get funding for
project
5. It reduces risk of failure, as potential risks can be identified early and mitigation steps can be
taken
6. Iteration between development team and client provides a very good and conductive
environment during project
7. Time required to complete the project after getting the SRS reduces since the developer has a
better idea about how he should approach the project

Disadvantages

1. Prototyping is usually done at cost of the developer. So it should be done using minimal
resources. It can be done using RAD tools
2. Once we get proper requirements from clients showing prototype model it may be of no use
that is why sometimes we refer to the prototype as Throw away prototype
 3. It is slow process
4. Too much involvement of client is not always preferred by the developer
5. Too many changes can disturb the rhythm of the development team

Rapid-application development (RAD) is both a general term, used to refer to adaptive

software development approaches, as well as the name for James Martin's approach to rapid
development. In general, RAD approaches to software development put less emphasis on
planning and more emphasis on an adaptive process. Prototypes are often used in addition to or
sometimes even in place of design specifications.

RAD is especially well suited for (although not limited to) developing software that is driven by
user interface requirements. Graphical user interface builders are often called rapid application
development tools. Other approaches to rapid development include the adaptive, agile, spiral,
and unified models.

Rapid application development was a response to plan-driven waterfall processes, developed

in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM).
One of the problems with these methods is that they were based on a traditional engineering
model used to design and build things like bridges and buildings. Software is an inherently
different kind of artifact. Software can radically change the entire process used to solve a
problem. As a result, knowledge gained from the development process itself can feed back to the
requirements and design of the solution.[1] Plan-driven approaches attempt to rigidly define the
requirements, the solution, and the plan to implement it, and have a process that discourage
changes. RAD approaches, on the other hand, recognize that software development is a
knowledge intensive process and provide flexible processes that help take advantage of
knowledge gained during the project to improve or adapt the solution.

The first such RAD alternative was developed by Barry Boehm and was known as the spiral
model. Boehm and other subsequent RAD approaches emphasized developing prototypes as well
as or instead of rigorous design specifications. Prototypes had several advantages over traditional
specifications:

 Risk reduction. A prototype could test some of the most difficult potential parts of the
system early on in the life-cycle. This can provide valuable information as to the
feasibility of a design and can prevent the team from pursuing solutions that turn out to
be too complex or time consuming to implement. This benefit of finding problems earlier
in the life-cycle rather than later was a key benefit of the RAD approach. The earlier a
problem can be found the cheaper it is to address.
 Users are better at using and reacting than at creating specifications. In the waterfall
model it was common for a user to sign off on a set of requirements but then when
presented with an implemented system to suddenly realize that a given design lacked
some critical features or was too complex. In general most users give much more useful
feedback when they can experience a prototype of the running system rather than
abstractly define what that system should be.
  Prototypes can be usable and can evolve into the completed product. One approach used
in some RAD methods was to build the system as a series of prototypes that evolve from
minimal functionality to moderately useful to the final completed system. The advantage
of this besides the two advantages above was that the users could get useful business
functionality much earlier in the process.[2]

Starting with the ideas of Barry Boehm and others, James Martin developed the rapid application
development approach during the 1980s at IBM and finally formalized it by publishing a book in
1991, Rapid Application Development. This has resulted in some confusion over the term RAD
even among IT professionals. It is important to distinguish between RAD as a general alternative
to the waterfall model and RAD as the specific method created by Martin. The Martin method
was tailored toward knowledge intensive and UI intensive business systems.

These ideas were further developed and improved upon by RAD pioneers like James Kerr and
Richard Hunter, who together wrote the seminal book on the subject, Inside RAD,[3] which
followed the journey of a RAD project manager as he drove and refined the RAD Methodology
in real-time on an actual RAD project. These practitioners, and those like them, helped RAD
gain popularity as an alternative to traditional systems project life cycle approaches.

The RAD approach also matured during the period of peak interest in business re-engineering.
The idea of business process re-engineering was to radically rethink core business processes such
as sales and customer support with the new capabilities of Information Technology in mind.
RAD was often an essential part of larger business re engineering programs. The rapid
prototyping approach of RAD was a key tool to help users and analysts "think out of the box"
about innovative ways that technology might radically reinvent a core business process.

The James Martin RAD method

Phases in the James Martin approach to RAD

The James Martin approach to RAD divides the process into four distinct phases:

1. Requirements planning phase – combines elements of the system planning and systems
analysis phases of the Systems Development Life Cycle (SDLC). Users, managers, and
IT staff members discuss and agree on business needs, project scope, constraints, and
 system requirements. It ends when the team agrees on the key issues and obtains
management authorization to continue.
2. User design phase – during this phase, users interact with systems analysts and develop
models and prototypes that represent all system processes, inputs, and outputs. The RAD
groups or subgroups typically use a combination of Joint Application Development
(JAD) techniques and CASE tools to translate user needs into working models. User
Design is a continuous interactive process that allows users to understand, modify, and
eventually approve a working model of the system that meets their needs.
3. Construction phase – focuses on program and application development task similar to
the SDLC. In RAD, however, users continue to participate and can still suggest changes
or improvements as actual screens or reports are developed. Its tasks are programming
and application development, coding, unit-integration and system testing.
4. Cutover phase – resembles the final tasks in the SDLC implementation phase, including
data conversion, testing, changeover to the new system, and user training. Compared with
traditional methods, the entire process is compressed. As a result, the new system is built,
delivered, and placed in operation much sooner.

Pros and cons of rapid application development

In modern Information Technology environments, many systems are now built using some
degree of Rapid Application Development (not necessarily the James Martin approach). In
addition to Martin's method, Agile methods and the Rational Unified Process are often used for
RAD development.

The advantages of RAD include:

 Better quality. By having users interact with evolving prototypes the business
functionality from a RAD project can often be much higher than that achieved via a
waterfall model. The software can be more usable and has a better chance to focus on
business problems that are critical to end users rather than technical problems of interest
to developers.
 Risk control. Although much of the literature on RAD focuses on speed and user
involvement a critical feature of RAD done correctly is risk mitigation. It's worth
remembering that Boehm initially characterized the spiral model as a risk based
approach. A RAD approach can focus in early on the key risk factors and adjust to them
based on empirical evidence collected in the early part of the process. E.g., the
complexity of prototyping some of the most complex parts of the system.
 More projects completed on time and within budget. By focusing on the development of
incremental units the chances for catastrophic failures that have dogged large waterfall
projects is reduced. In the Waterfall model it was common to come to a realization after
six months or more of analysis and development that required a radical rethinking of the
entire system. With RAD this kind of information can be discovered and acted upon
earlier in the process.

The disadvantages of RAD include:

  The risk of a new approach. For most IT shops RAD was a new approach that required
experienced professionals to rethink the way they worked. Humans are virtually always
averse to change and any project undertaken with new tools or methods will be more
likely to fail the first time simply due to the requirement for the team to learn.
 Requires time of scarce resources. One thing virtually all approaches to RAD have in
common is that there is much more interaction throughout the entire life-cycle between
users and developers. In the waterfall model, users would define requirements and then
mostly go away as developers created the system. In RAD users are involved from the
beginning and through virtually the entire project. This requires that the business is
willing to invest the time of application domain experts. The paradox is that the better the
expert, the more they are familiar with their domain, the more they are required to
actually run the business and it may be difficult to convince their supervisors to invest
their time. Without such commitments RAD projects will not succeed.
 Less control. One of the advantages of RAD is that it provides a flexible adaptable
process. The ideal is to be able to adapt quickly to both problems and opportunities.
There is an inevitable trade-off between flexibility and control, more of one means less of
the other. If a project values control more than agility RAD is not appropriate.
 Poor design. The focus on prototypes can be taken too far in some cases resulting in a
"hack and test" methodology where developers are constantly making minor changes to
individual components and ignoring system architecture issues that could result in a
better overall design. This can especially be an issue for methodologies such as Martin's
that focus so heavily on the user interface of the system]
 Lack of scalability. RAD typically focuses on small to medium-sized project teams. The
other issues cited above (less design and control) present special challenges when using a
RAD approach for very large scale systems

Jackson System Development

Overview

Jackson System Development (JSD) is a method of system development that covers the
software life cycle either directly or, by providing a framework into which more specialized
techniques can fit. Jackson System Development can start from the stage in a project when there
is only a general statement of requirements. However, many projects that have used Jackson
System Development actually started slightly later in the life cycle, doing the first steps largely
from existing documents rather than directly with the users. The later steps of JSD produce the
code of the final system. Jackson’s first method, Jackson Structured Programming (JSP), is used
to produce the final code. The output of the earlier steps of JSD are a set of program design
problems, the design of which is the subject matter of JSP. Maintenance is also addressed by
reworking whichever of the earlier steps are appropriate.

From the technical point of view there are three major stages in Jackson System Development,
each divided into steps and sub-steps. From a manager's point of view there are a number of
ways of organizing this technical work. In this overview we first describe the three major
technical stages and then discuss JSD project planning, the variation between plans, and the
reasons for choosing one rather than another.
JSD: The Modeling Stage

In the modeling stage the developers make a description of the aspects of the business or
organization that the system will be concerned with. To make this a description they must
analyze their business, choosing what is relevant and ignoring what is not. They have to consider
the organization as it will be, not as it is now.

The model description is written very precisely. This precision forces the developer to ask
detailed questions. It encourages good communication and understanding between developers,
users, and everyone else involved with the new system.

The model description consists of actions, entities and related information. An action is an event,
usually in the external reality, that is relevant to the system and whose occurrence the system
must record. In implementation terms, actions might cause database updates. We start Jackson
System Development by making a list of actions with definitions and associated attributes.
Diagrams describe ordering relationships between actions. The diagrams describe the entities,
people or, things that the system is concerned with.

The data that is to be stored for each entity is then defined. In effect we are choosing what is to
be remembered by each entity about the actions that affect it. The full definition of this data
includes an elaboration of the entity diagram to show in detail the update rules.

The result of the modeling stage is a set of tables, definitions and diagrams that describe:

 in user terms exactly what happens in the organization and what has to be recorded about what
happens, and
 in implementation terms, the contents of the database, the integrity constraints and the update
rules.

JSD: The Network Stage

In the network stage we build up a precise description of what the system has to do, including the
outputs that are to be produced and the way the system is to appear to the user. This description
is in terms of a network of programs. More precisely, it is a network of Communicating
Sequential Processes (CSP), a concept developed by Tony Haoare. We start this network by
making one program for each of the entities that was defined during the modeling stage. The
network is then built up incrementally by adding new programs and connecting them up to the
existing network. New programs are added for the following reasons:

 To collect inputs for actions, check them for errors, and pass them to the entity programs. In this
way entity programs are kept up-to-date with what's happening outside;
 To generate inputs for actions that do not correspond to external events. Such actions are
substitutes for real world events, perhaps because those events cannot be detected;
 To calculate and produce outputs.

There are two means of connecting programs in the network. These are by data streams
(represented on our network diagram of circles) and by state vector inspection (represented on
our network diagrams by diamonds). Whatever kind of connection is appropriate, the entity
programs play a pivotal role in the construction of the network. Most of the new programs can be
connected directly to the entity programs.

We draw a whole set of network diagrams to describe the system. Different networks usually
only have entity programs in common. The complete system is represented by the overlay of all
the diagrams.

The diagrams are supported by textual information describing the contents of the data streams
and state vector connections. The new programs that are added to the network are defined using
the same diagrammatic notation used to describe the ordering of actions. These new programs
are designed using the JSP (Jackson Structured Programming) method, which is now a subset of
JSD.

JSD: The Implementation Stage

The result of the implementation stage is the final system. This stage is the only one directly
concerned with the machine and the associated software on which the system is to run.
Therefore, as well as producing and testing code, the implementation stage covers physical
design issues. In particular it covers:

 physical data design, and

 reconfiguring the network by combining programs.

Physical data design is about the design of files or databases. The details of database design
depend on the particular DBMS being used. However, the necessary information about the
application is all available from the network stage. The most important is the data defined for
each entity and the high volume accessing of that data as defined by the frequently used state
vector connections.

The result of the network stage is a highly distributed network of programs. Often, for
convenience or efficiency, we convert programs into subroutines, in effect combining several
programs into one, so that a fragment of the network is implemented as a single program. The
network is reconfigured from a form appropriate for specification into a form appropriate for
implementation.

JSD: Projects and Plans

We have presented the three stages of JSD as a simple linear progression. On a project, however,
the stages overlap to a greater or lesser degree, and not just because people make mistakes that
have to be corrected later. The stages and substages are nevertheless important because they
classify and organize the technical work, they clarify the choices open to a project manager, and
illuminate the risks when a decision has to be taken out of order.

The following are some examples of the overlap of the stages:

  We can start adding programs to the network before the model is complete.
 The detail designed of many of the simpler programs in the network can be done at the same
time they are implemented.
 The physical data designed can be started before the low frequency programs have been added
to the network.
 We may do a little each of model, network and implementation as the basis of a feasibility
study.
 On a large project the model-network-implementation of one release may overlap with that of
the next.

The Software Prototyping refers to building software application prototypes which

display the
functionality of the product under development but may not actually hold the exact
logic of the
original software.
Software prototyping is becoming very popular as a software development model, as it
enables to
understand customer requirements at an early stage of development. It helps get
valuable
feedback from the customer and helps software designers and developers understand
about what
exactly is expected from the product under development.
What is Software Prototyping?
Prototype is a working model of software with some limited functionality.
The prototype does not always hold the exact logic used in the actual software
application
and is an extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out
before
implementation.
It also helps understand the requirements which are user specific and may not have
been
considered by the developer during product design.
Following is the stepwise approach to design a software prototype:
Basic Requirement Identification: This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details of
the
internal design and external aspects like performance and security can be ignored at
this
stage.
Developing the initial Prototype: The initial Prototype is developed in this stage, where
the very basic requirements are showcased and user interfaces are provided. These
features
may not exactly work in the same manner internally in the actual software developed
and
the workarounds are used to give the same look and feel to the customer in the
prototype
developed.
Review of the Prototype:The prototype developed is then presented to the customer and
the other important stakeholders in the project. The feedback is collected in an
organized
manner and used for further enhancements in the product under development.
Revise and enhance the Prototype: The feedback and the review comments are
discussed during this stage and some negotiations happen with the customer based on
factors like , time and budget constraints and technical feasibility of actual
implementation.
The changes accepted are again incorporated in the new Prototype developed and the
cycle
repeats until customer expectations are met.
Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the
user
interface for the product and gives a broader view of the entire system, without
concentrating on
internal functions. A vertical prototype on the other side is a detailed elaboration of a
specific
function or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes
are used
to get more information on the user interface level and the business requirements. It
can even be
presented in the sales demos to get business in the market. Vertical prototypes are
technical in
nature and are used to get details of the exact functioning of the sub systems. For
example,
database requirements, interaction and data processing loads in a given sub system.
Software Prototyping Types
There are different types of software prototypes used in the industry. Following are the
major
software prototyping types used widely:
Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close
ended prototyping. This type of prototyping uses very little efforts with minimum
requirement
analysis to build a prototype. Once the actual requirements are understood, the
prototype is
discarded and the actual system is developed with a much clear understanding of user
requirements.
Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping
is based on building actual functional prototypes with minimal functionality in the
beginning.
The prototype developed forms the heart of the future prototypes on top of which the
entire
system is built. Using evolutionary prototyping only well understood requirements are
included in the prototype and the requirements are added as and when they are
understood.
Incremental Prototyping: Incremental prototyping refers to building multiple functional
prototypes of the various sub systems and then integrating all the available prototypes
to
form a complete system.
Extreme Prototyping : Extreme prototyping is used in the web development domain. It
consists of three sequential phases. First, a basic prototype with all the existing pages is
presented in the html format. Then the data processing is simulated using a prototype
services layer. Finally the services are implemented and integrated to the final
prototype.
This process is called Extreme Prototyping used to draw attention to the second phase
of the
process, where a fully functional UI is developed with very little regard to the actual
services.
Software Prototyping Application
Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go
through
various screens before data is processed can use prototyping very effectively to give
the exact
look and feel even before the actual software is developed.
Software that involves too much of data processing and most of the functionality is
internal with
very little user interface does not usually benefit from prototyping. Prototype
development could
be an extra overhead in such projects and may need lot of extra efforts.
Software Prototyping Pros and Cons
Software prototyping is used in typical cases and the decision should be taken very
carefully so
that the efforts spent in building the prototype add considerable value to the final
software
developed. The model has its own pros and cons discussed as below.
Following table lists out the pros and cons of Big Bang Model:
Pros Cons
 Increased user involvement in the Risk of insufficient requirement analysis
 product even before owing to too much dependency on
implementation prototype
 Since a working model of the Users may get confused in the
system is prototypes and actual systems.
 displayed, the users get a better Practically, this methodology may
 understanding of the system being increase the complexity of the system as
scope of the system may expand beyond
 developed.
original plans.
 Reduces time and cost as the
Developers may try to reuse the existing
defects can prototypes to build the actual system,
 be detected much earlier. even when its not technically feasible
 Quicker user feedback is available The effort invested in building prototypes
 leading to better solutions. may be too much if not monitored
 Missing functionality can be properly
identified
 easily
 Confusing or difficult functions can
be
 identified