Lecture Five

5.1 Introduction
Welcome to the fifth lecture on system development. In this lecture we shall discuss the
techniques in information systems development.

Specific objectives

Identify different techniques used in system development

Relate the different techniques to its related methods

3.3 Lecture Outline

5.3 Lecture Outline

5.3.1 Introduction
5.3.2. Holistic Techniques
5.3.3 Data Techniques
5.3.4 Process Techniques
5.3.5 Object Oriented Techniques
5.3.6 Project Management Techniques

5.3.1 Introduction
There are various types of techniques that may be used during system development. These
techniques can be classified into different categories. Each technique uses its own notations and
presents a different view or perspective of that system.

5.3.2. Holistic Techniques

Soft Systems Methodology (SSM for short) was developed by Peter Checkland and colleagues at
the University of Lancaster. It is based upon systems theory, which provides an antidote to
conventional, 'reductionist' scientific enquiry – with its tendency to 'reduce' phenomena into
smaller and smaller components in order to study and understand them. Systems theory attempts
to study the whole picture; the relation of component parts to each other, and to the wider picture
- it is 'holistic.' SSM helps formulate and structure thinking about problems in complex, human
situations. Its core is the construction of conceptual models and the comparison of those models
with the real world. This process can greatly clarify those multifaceted problems with many
conflicting potential solutions, or no obvious way forward. It uses rich pictures , conceptual
models and root definitions.

1. Rich Pictures

 Help to understand the problem situation in general at beginning of a project

 It is a pictorial caricature of an organization
 It is a tool for helping to explain what the organization is about
 It helps people to visualize and discuss their roles
 It can show the worries of individuals, potential conflict, and political issues

2. Root Definitions
This a short textual definition of the aims and means of the system to be modelled. It can be used
to define two things that are otherwise both vague and difficult: problems and systems. A
concise verbal description of the system which captures its essential nature of Who is doing what
for whom, and to whom are they answerable, what assumptions are being made, and in what
environment is this happening? or “A system to do X, by (means of) Y, in order to Z”
We identify this description using C(lient) A(ctor) T(ransformation) W(eltanschuung) O(wner)
E(nvironment): CATWOE
Customers the victims or beneficiaries of T
Actors those who do T
Transformation process input into output
Weltanschauung the worldview that makes the T meaningful in context
Owners those with the power to stop T
Environmental constraints elements outside the system which are taken as given,but
nevertheless affect its behavior.

5.3.2.2 Conceptual Models

Conceptual models demonstrate potential activities and their logical dependencies. The
activities, which must be expressed in a verb noun phrase are placed in rough, hand drawn
bubbles. The bubbles may be joined by arrows indicating dependence: - that one activity is
consequent upon another - it cannot be performed, unless the other has been performed, or that it
will be done poorly if the other is done poorly. activities usually makes for a reasonably
understandable model. If more detail or complexity is required, then the system may be modelled
at a higher level of resolution. (This is equivalent to levelling in a data flow diagram). Any
activity in a conceptual model may be taken to represent a system in its own right.

5.3.2.4 Cognitive Mapping

This is a model of the system concepts used to communicate the nature of a problem and the
concepts are related to others through an action orientation. The maps show short statements
relating to the problem situation linked by arrows showing how one idea might lead to or have
implications for another. It is seen as a formal modeling technique with rules for its
development.
5.3.3 Data Techniques
5.3.3.1 Data-driven modelling
Many business systems are data-processing systems that are primarily driven by data. They are
controlled by the data input to the system, with relatively little external event processing. Data-
driven models show the sequence of actions involved in processing input data and generating an
associated output. They are particularly useful during the analysis of requirements as they can be
used to show end-to-end processing in a system.

1. Entity Modelling
An entity-relationship diagram (ERD) is a graphical representation of an information system that
shows the relationship between people, objects, places, concepts or events within that system.
An ERD is a data modeling technique that can help define business processes and can be used as
the foundation for a relational database.
While useful for organizing data that can be represented by a relational structure, an entity-
relationship diagram can't sufficiently represent semi-structured or unstructured data, and an
ERD is unlikely to be helpful on its own in integrating data into a pre-existing information
system.
Three main components of an ERD are the entities, which are objects or concepts that can have
data stored about them, the relationship between those entities, and the cardinality, which defines
that relationship in terms of numbers. For example, an ER diagram representing the information
system for a company's sales department might start with graphical representations of entities
such as the sales representative, the customer, the customer's address, the customer's order, the
product and the warehouse. Then lines or other symbols can be used to represent the relationship
between entities, and text can be used to label the relationships.

list regist er for make paymen t in to

SPO R T ME MB E R

play as
be played books
on available to
belon g to paid by

ME MB E R ’S AC CO U N T
SPO RT EN TR Y

play as
GU E ST

used for
be be
CO U RT play in OT H E R
PL A Y E R
have daily
booked by
have n om in a ted
CO U R T
be prepared for SLO T
2. Normalisation
Database Normalisation is a technique of organizing the data in the database. Normalization is a
systematic approach of decomposing tables to eliminate data redundancy and undesirable
characteristics like Insertion, Update and Deletion. It is a multi-step process that puts data into
tabular form by removing duplicated data from the relation tables. Normalization is used for
mainly two purpose.
1. Eliminating redundant data.
2. Ensuring data dependencies make sense i.e data is logically stored.
Normalization rule are divided into following normal form.
1. First Normal Form
2. Second Normal Form
3. Third Normal Form

First Normal Form, no two Rows of data must contain repeating group of information i.e each
set of column must have a unique value, such that multiple columns cannot be used to fetch the
same row. Each table should be organized into rows, and each row should have a primary key
that distinguishes it as unique.
The Primary key is usually a single column, but sometimes more than one column can be
combined to create a single primary key. For example consider a table which is not in First
normal form
Second Normal Form there must not be any partial dependency of any column on primary key.
It means that for a table that has concatenated primary key, each column in the table that is not
part of the primary key must depend upon the entire concatenated key for its existence. If any
column depends only on one part of the concatenated key, then the table fails Second normal
form.
Third Normal form applies that every non-prime attribute of table must be dependent on
primary key, or we can say that, there should not be the case that a non-prime attribute is
determined by another non-prime attribute. So this transitive functional dependency should be
removed from the table and also the table must be in Second Normal form
5.3.4 Process Techniques
Process models reveal how the system being developed is used in broader business processes.
Data flow models may be used to show the processes and the flow of information from one
process to another.

1. Data Flow Diagrams

It provides the key means of achieving one of structured systems. They provide the analyst with
the ability to specify a system at the logical level. They represent logical information, not the
physical aspects. They have the following characteristics
 Illustrate processing steps in a system

 Tracking and documenting how the data associated with a particular process moves
through the system

 Helps analysts and designers understand what is going on

 Simple and intuitive

 Possible to explain them to potential system users who can then participate in validating
the model

 Focus on system functions

 Do not recognize system objects (therefore, data flow models not included in UML)

 Similar to activity diagrams in UML 2.0 (data-driven systems are common in business)
2. Elementary process description
Once a DFD is obtained the next step is to precisely specify the process. The methods available
for documenting and analyzing the logic of structured decisions include structured English,
decision tables, and decision trees. Process specifications are created for primitive processes and
some higher level processes on a data flow diagram. They are also are called elementary process
diagrams. Structured English, Decision tables and Decision Trees are used to describe processes.
Decision tables are used when the process is logically complex involving large number of
conditions and alternate solutions. Decision trees are used when conditions to be tested must
follow a strict time sequence.

i) Structured English: Structured English is based on structured logic. Simple English

statements such as add, multiply, move, and so on. It is an appropriate technique for analyzing
the system when structured decisions are not complex. Structured English is similar to a
programming language. It does not have strict syntax rules as in programming languages as the
intention is only to give precise description of a process. The structured English description
should be understandable to the user. The following steps are needed:
 Express all logic in terms of sequential structures, decision structures, case structures, or
iterations
 Use and capitalize accepted keywords such as IF, THEN, ELSE, DO, and PERFORM
 Indent blocks of statements to show their hierarchy (nesting) clearly
 Underline words or phrases used have been defined in a data dictionary to signify that
they have a specialized, reserved meaning
 Be careful when using "and" and "or"
 Avoid confusion when using logical comparisons such as "greater than" and "greater than
or equal to”

ii) Decision Table: Decision tables provide a way to examine, describe, and document
decisions using a table. They are used to:
1. Describe the conditions
2. Identify possible decision alternatives
3. Indicate actions should be performed, and describe actions
Decision tables help analysts ensure completeness and accuracy. The four main problems
that can occur in developing decision tables are: Incompleteness, Impossible situations,
Contradictions and Redundancy
 iii) Decision trees: Decision trees are used when complex branching occurs in a
structured decision process. Trees are also useful when it is essential to keep a string of
decisions in a particular sequence. To draw decision trees:
 First, identify all conditions and actions and the order and timing of these (if they
are critical)
 Second, begin building the tree from left to right while making sure you are
complete in listing all possible alternatives before moving over to the right.

5.3.4.2 Guidelines for choosing EPD

 Use structured English when there are many repetitious actions or when
communication to end users is important
 Use decision tables when complex combination of conditions, actions, and
rules are found or you require a method that effectively avoids impossible
situations, redundancies, and contradictions
 Use decision trees when the sequence of conditions and actions is critical or
when not every condition is relevant to every action (the branches are
different)

5.3.5 Object Oriented Techniques

In the object-oriented design approach, the system is viewed as collection of objects. The state is
decentralized among the objects and each object manages its own state information. The
functions defined for one object cannot refer or change data of other objects. Objects have their
own internal data which define their state. Similar objects constitute a class. In other words, each
object is a member of some class. Classes may inherit features from super class. Conceptually,
objects communicate by message passing.
5.3.5.1 Origin of UML
In the late 1980s and early 1990s, there was a proliferation of object-oriented design techniques
and notations. Different software development houses were using different notations to
document their object-oriented designs. These diverse notations gave rise to a lot of confusion.
UML was developed to standardize the large number of object-oriented modelling notations that
existed and were used extensively in the early 1990s.
UML,(Unified Modelling Language) as the name implies, is a modeling language. It may be
used to visualize, specify, construct, and document the artifacts of a software system. It provides
a set of notations to create a visual model of the system. Like any other language, UML has its
own syntax and semantics .Also, we should clearly understand that UML is not a system design
or development methodology, but can be used to document object-oriented and analysis results
obtained using some methodology.

1. Use case modeling

Use cases were developed originally to support requirements elicitation and now incorporated
into the UML. They are used to model interactions between a system and external actors (users,
other systems). It gives a fairly simple overview of an interaction and is used to support
requirements elicitation. However you have to provide more detail to understand what is
involved: textual description, structured description in a table, sequence diagram. Each use case
represents a discrete task that involves external interaction with a system. Actors in a use case
may be people or other systems. It is represented diagramatically to provide an overview of the
use case and in a more detailed textual form.
Use case:
 Represents a discrete task (involves external interaction with a system)
 Shown as an ellipse with the actors involved in the use case
 Key elements often involved in use cases: actors, description, data, stimulus, response, comments

2 Sequence diagrams
Sequence diagrams are part of the UML and are used to model the interactions between
the actors and the objects within a system. A sequence diagram shows the sequence of
interactions that take place during a particular use case or use case instance.
 Objects and actors involved are listed along the top of the diagram
 Interactions between objects are indicated by annotated arrows
 Rectangle on the dotted lines indicates the lifeline of the object concerned
  Read the sequence of interactions from top to bottom
 Annotations on the arrows indicate the calls to the objects, their parameters and
the return values
 Include every interaction in sequence diagrams for code generation or detailed
documentation

3. Structural models
Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships. The models may be static
models, which show the structure of the system design, or dynamic models, which show
the organization of the system when it is executing. You create structural models of a
system when you are discussing and designing the system architecture.

4. Class diagrams
Class diagrams are used when developing an object-oriented system model to show the
classes in a system and the associations between these classes. An object class can be
thought of as a general definition of one kind of system object. An association is a link
between classes that indicates that there is some relationship between these classes. Each
class may have some knowledge of its associated class. They are expressed at different
levels of detail. The types of relationship: 1 to 1, m to 1, m to n.
5. State diagrams (UML):
They show system states and events that cause transitions from one state to another
and o not show the flow of data within the system. It may include additional
information on the computations carried out in each state .
 Rounded rectangles: represent system states (may include a brief description
of the actions taken in that state).
 Labeled arrows: represent stimuli that force a transition
 Optional: start and end states using filled circles (see activity diagrams)

6. UML activity diagrams: They show the activities that make up a system process and the
flow of control from one activity to another .
 Start of process: indicated by a filled circle
 End of process: filled circle inside another circle
 Activities: rectangles with round corners
  Arrows represent the flow of work from one activity to another
 Arrows annotated with guards: indicate the condition when that flow is taken
 Solid bar: indicate activity coordination

5.3.6 Project Management Techniques

Project Management techniques describe the ways that we gather information, communicate, and
generally get things done in the most efficient and effective way.

1. Scheduling Techniques
Project scheduling is concerned with attaching a timescale and sequence to the activities to be
conducted within the project. Materials and people needed at each stage of the project are
determined and the time each is to take will be set. Project managers have a variety of techniques
to develop a project schedule - from the relatively simple process of action planning for small
projects, to use of Gantt Charts and Network

2. Gantt Chart
A Gantt chart, commonly used in project management, is one of the most popular and useful
ways of showing activities (tasks or events) displayed against time. On the left of the chart is a
list of the activities and along the top is a suitable time scale. Each activity is represented by a
bar; the position and length of the bar reflects the start date, duration and end date of the activity.
DURATION (weeks)
ACTIVITY 1 2 3 4 5 6 7 8 9 10 11 12 13
A
B
C
D
E
F
G
H
3. Resource Allocation
This is used to allocate resources in the project. The bar chart shows the resource allocation
over time.

4. PERT Diagram
A PERT chart is a project management tool used to schedule, organize, and coordinate tasks
within a project. PERT stands for Program Evaluation Review Technique, A PERT chart
presents a graphic illustration of a project as a network diagram consisting of numbered
nodes (either circles or rectangles) representing events, or milestones in the project linked by
labelled vectors (directional lines) representing tasks in the project. The direction of the
arrows on the lines indicates the sequence of tasks.
5.4 Activities
Read the following topics from the book Information Systems Development:
Methodologies, Techniques and Tools by Avison and Fitzgerald and answer the
questions below
Topics
1. Organisational Techniques
2. People Techniques
3. Techniques in context

Questions
1. Describe the term lateral thinking
2. Distinguish between JAD and Stakeholder analysis
3. Describe the potential benefits and the potential blocks to problem cognition when
using techniques in system development

.
5.5 Summary
 There are various types of techniques that may be used during system development.
These techniques can be classified into different categories. Each technique uses its
own notations and presents a different view or perspective of that system.
 Holistic techniques are based upon systems theory, which provides an antidote to
conventional, 'reductionist' scientific enquiry – with its tendency to 'reduce'
phenomena into smaller and smaller components in order to study and understand
them.
 Data-driven models show the sequence of actions involved in processing input data
and generating an associated output. They are particularly useful during the analysis of
requirements as they can be used to show end-to-end processing in a system
 Process models reveal how the system being developed is used in broader business
processes. Data flow models may be used to show the processes and the flow of
information from one process to another
 In the object-oriented design approach, the system is viewed as collection of objects.
The state is decentralized among the objects and each object manages its own state
information.
 Project Management techniques describe the ways that we gather information,
communicate, and generally get things done in the most efficient and effective way.

Suggestion for further reading

Extracted from
Information Systems Development: Methodologies, Techniques and Tools by
Avison and Fitzgerald

Project Management techniques by Margret Rouse

http://www.studytonight.com/dbms/database-normalization.php
Lecture Six
6.1 Introduction
Welcome to the sixth lecture on system development. In this lecture we shall discuss the system
development methodologies.

Specific objectives

6.3 Lecture Outline

6.3 Lecture Outline

6.3 Lecture Outline

6.3.1 Classical waterfall model.
6.3.2 Spiral Model
6.3.3 Prototyping Model.
6.3.4 Evolutionary Model.
6.3.5 Incremental Model.

6.3.1 The classical waterfall model

The waterfall model is a sequential design process, often used in software development processes,
in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of
Feasibility Study, Requirements Analysis and Specification, Design, Coding and Unit
Testing, Integration and System Testing and Maintenance.
The classical waterfall model is the most obvious way to develop software. This model can be
considered to be a theoretical way of developing software, but all other life cycle models are
essentially derived from the classical waterfall model.
In order to be able to appreciate other life cycle models it is necessary to learn the classical
waterfall model.
Classical waterfall model divides the life cycle into the following phases:
1. Feasibility Study
2. Requirements Analysis and Specification
3. Design
4. Coding and Unit Testing
5. Integration and System Testing
6. Maintenance

Phases of water fall model

1. Feasibility study
The main aim of feasibility study is to determine whether it would be financially and technically
feasible to develop the product. The project managers or team leaders try to understand what is
required to be done by visiting the client side. They study different input data to the system and
output data to be produced by the system. They study what kind of processing is needed to be done
on these data and they look at the various constraints on the behavior of the system. When they
have an overall understanding of the problem they investigate the different solutions that are
possible. Then they examine each of the solutions in terms of what kind of resources required, what
would be the cost of development and what would be the development time for each solution.
Based on this analysis they select the best solution and determine whether the customer budget
would meet the cost of the product and whether they have sufficient technical expertise in the area
of development.

2. Requirement Analysis and Specification

The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of two distinct
activities, namely
 Requirements gathering and analysis
 Requirements specification

The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed. This is done so as to clearly understand the
customer requirements so that incompleteness and inconsistencies are removed.
 The requirements analysis activity is begins with collecting all relevant data regarding the product t
be developed from the users of the product and from the customer .For example, to perform the
requirements analysis of a business accounting software required by an organization, the analyst
might interview all the accountants of the organization to ascertain their requirements. The data
collected from such a group of users usually contains several contradictions and ambiguities, since
each user has only a partial and incomplete view of the system. It is therefore necessary to identify
all ambiguities and contradictions in the requirements and resolve them through further discussions
with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved
and the requirements properly understood, the requirements specification activity can begin.
During specification, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document. The customer requirements identified during the
requirements gathering and analysis activity are organized into a SRS document. The important
components of this document are functional requirements, the nonfunctional requirements, and the
goals of implementation.

3. System design
The design phase is to transform the requirements specified from the SRS document into a design
that is suitable for implementation in some programming language. During the design phase the
software architecture is derived from the SRS document. Two distinctly different approaches are
available: the traditional design approach and the object-oriented design approach.

i. Traditional design approach

Traditional design consists of two different activities; first a structured analysis of the requirements
specification is carried out where the detailed structure of the problem is examined. This is followed
by a structured design activity. During structured design, the results of structured analysis are
transformed into the software design.

ii. Object-oriented design approach

In this technique, various objects that occur in the problem domain and the solution domain are first
identified, and the different relationships that exist among these objects are identified. The object
structure is further refined to obtain the detailed design.

4. Coding and unit testing:-

The coding and unit testing phase (sometimes referred to implementation phase because the design
is implemented) of software development involves translating the software design into source code
using a programming language. Each component of the design is implemented as a program
module. The end-product of this phase is a set of program modules that have been tested
individually.
During this phase, each module is tested to determine that it works correctly. It involves testing
each module in isolation as this is the most efficient way to debug the errors identified at this stage.

5. Integration and system testing

Integration of different modules is undertaken once they have been coded and unit tested. During
the integration and system testing phase, the modules are integrated based on the system design.
The different modules rarely integrated all at one instead integration is normally carried out
incrementally over a number of steps. During each integration step, the partially integrated system
is tested and a set of previously planned modules are added to it. Finally, when all the modules have
been successfully integrated and tested, system testing is carried out. The goal of system testing is
to ensure that the developed system conforms to its requirements laid out in the SRS document.
System testing usually consists of three different kinds of testing activities:
1. Alpha – testing: system testing performed by the development team.
2. Beta– testing: system testing performed by a friendly set of customers.
3. Acceptance testing: system testing performed by the customer himself after the product
delivery to determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan
document. The system test plan identifies all testing related activities that must be performed,
specifies the schedule of testing and allocates required resources. It also lists all the test cases and
the expected outputs for each test case.

6. Maintenance
Maintenance of software products requires a lot more effort than to develop the product itself.
Many studies carried out in the past confirm this and indicate that the relative effort of development
of a typical software product to its maintenance effort is roughly in the 40:60 ratio. Maintenance
involves performing any one or more of the following three kinds of activities:
i. Corrective Maintenance: correcting errors that were not discovered during the product
development phase.
ii. Perfective maintenance: Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s requirements.
iii. Adaptive maintenance: migrating the software to work in a new environment. For example,
moving the software to work with a new operating system.
.
Advantages of waterfall model:
i. Simple and easy to understand and use.
ii. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a
review process.
iii. Phases are processed and completed one at a time.
iv. Works well for smaller projects where requirements are very well understood.

Disadvantages of waterfall model:

i. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
ii. No working software is produced until late during the life cycle.
iii. High amounts of risk and uncertainty.
iv. Not a good model for complex and object-oriented projects.
v. Poor model for long and ongoing projects.
vi. Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

i. Requirements are very well known, clear and fixed.
ii. Product definition is stable.
iii. Technology is understood.
 iv. There are no ambiguous requirements
v. Ample resources with required expertise are available freely
vi. The project is short.

6.3.2 Spiral model

Many projects are risk driven. The process model proposed by Professor Barry Boehm aims to
control and manage project risks during the course of development and provide opportunities for
understanding the problem domain throughout the development and for building the system
incrementally. The spiral model begins with an initial plan for development, evaluate risks, perhaps
do some prototyping to evaluate alternatives at the system level, and produces a concept of
operations document which describes how the system should work at a high level. From the
concept of operations, a set of requirements for the system is extracted and this should be as
complete as possible. The spiral model then uses to iteration to complete the development. Each
iteration typically involves risk analysis, prototyping to determine the feasibility and desirability of
various alternatives and then design, coding and testing.
It allows for a complete re-evaluation of the project direction after each spiral, and the requirements
can be re-evaluated. However we need to ensure that new insights, which lead to new requirements
are consistent with prior requirements and with the what has been built thus far

The Spiral model of software development is shown above .The diagrammatic representation of this
model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed.
Each loop of the spiral represents a phase of the software process. For example, the innermost loop
might be concerned with feasibility study the next loop with requirements specification and so on.
Each phase in this model is split into four sectors (or quadrants). The following activities are carried
out during each phase of a spiral model.
1. First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.
2. Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.
3. Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified risks.
4. Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration around the spiral.
• Progressively more complete version of the software gets built with each iteration around the
spiral.

Advantages of Spiral model:

i. High amount of risk analysis hence, avoidance of Risk is enhanced.
ii. Good for large and mission-critical projects.
iii. Strong approval and documentation control.
iv. Additional Functionality can be added at a later date.
v. Software is produced early in the software life cycle.

Disadvantages of Spiral model:

i. Can be a costly model to use.
ii. Risk analysis requires highly specific expertise.
iii. Project’s success is highly dependent on the risk analysis phase.
iv. Doesn’t work well for smaller projects.

When to use Spiral model:

i. When costs and risk evaluation is important
ii. For medium to high-risk projects
iii. Long-term project commitment unwise because of potential changes to economic priorities
iv. Users are unsure of their needs
v. Requirements are complex
vi. New product line
vii. Significant changes are expected (research and exploration)

6.3.3 Prototype
A prototype is a model implementation of the system. It usually exhibits limited functional
capabilities, low reliability, and inefficient performance compared to the actual software. A
prototype is usually built using several shortcuts. The shortcuts might involve using inefficient,
inaccurate, or dummy functions. The shortcut implementation of a function, for example, may
produce the desired results by using a table look-up instead of performing the actual computations.
There are several uses of a prototype. An important purpose is to illustrate the input data formats,
messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for
gaining better understanding of the customer’s needs:
• how the screens might look
• how the user interface would behave
• how the system would produce outputs

This is something similar to what the architectural designers of a building do; they show a prototype
of the building to their customer. The customer can evaluate whether he likes it or not and the
changes that he would need in the actual product. A similar thing happens in the case of a software
product and its prototyping model.
Another reason for developing a prototype is that it is impossible to get the perfect product in the
first attempt. Many researchers and engineers advocate that if you want to develop a good product
you must plan to throw away the first version. The experience gained in developing the prototype
can be used to develop the final product.
A prototyping model can be used when technical solutions are unclear to the development team. A
developed prototype can help engineers to critically examine the technical issues associated with
the product development. Often, major design decisions depend on issues like the response time of
a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a
prototype may be the best or the only way to resolve the technical issues.

Following is the stepwise approach to design a software prototype:

i. 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.
ii. 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.
iii. 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.
iv. 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.

There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely:

1. 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.
2. 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.
3. 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.
4. 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.

A prototype of the actual product is preferred in situations such as:

i. user requirements are not complete
ii. technical issues are not clear

Let’s see an example for each of the above category.

Advantages of Prototype model:

i. Users are actively involved in the development
ii. Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
iii. Errors can be detected much earlier.
iv. Quicker user feedback is available leading to better solutions.
v. Missing functionality can be identified easily
vi. Confusing or difficult functions can be identified

Disadvantages of Prototype model:

i. Leads to implementing and then repairing way of building systems.
ii. Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
iii. Incomplete application may cause application not to be used as the full system was designed
iv. Incomplete or inadequate problem analysis.
When to use Prototype model:
i. Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
ii. Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built that
allows ease of use and needs minimal training for the end user.
iii. Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

6.3.4 Evolutionary Development

Evolutionary development is an iterative and incremental approach to software

development. Instead of creating a comprehensive artifact, such as a requirements specification,
that you review and accept before creating a comprehensive design model, you instead evolve the
critical development artifacts over time in an iterative manner. Instead of building and then
delivering your system in a single “big bang” release you instead deliver it incrementally over time
It is often associated with the object-oriented approach to system development. The aim of this
process is to split the problem up into many sub-tasks each of which can deliver a part of the
product that offers a tangible improvement in the system to the users. Each sub-task is tackled and
delivered as a separate deliverable in the life of the project. Delivery of a new component changes
the perception of the project, then the priorities on completing the remaining tasks are re-evaluated
in the light of the new component and the most important (from a user view) is chosen as the next
to deliver. Evolutionary development is highly robust because changes can easily be factored into
the process but it is not particularly visible because it may be difficult to keep track of many sub-
tasks in an efficient way.
There is growing recognition that software, like all complex systems, evolves over a period of time.
Business and product requirements often change as development proceeds, making a straight line
path to an end product unrealistic; tight market deadlines make completion of a comprehensive
software product impossible, but a limited version must be introduced to meet competitive or
business pressure; a set of core product or system requirements is well understood, but the details of
product or system extensions have yet to be defined. In these and similar situations, software
engineers need a process model that has been explicitly designed to accommodate a product that
evolves over time.
The Evolutionary models are iterative. They are characterized in a manner that enables software
engineers to develop increasingly more complete versions of the software.

Advantages of Evolutionary Model

⚫ This model is useful in exploratory programming (such as Artificial Intelligence
applications) where it is difficult to frame the
specifications.
⚫ In case major problems are foreseen, the developer can stop the
development after some iterations.
⚫ This model is very appropriate for research projects. For example, to develop
software for automatic speech recognition, a small vocabulary can be taken and the system is
developed. After achieving success, the vocabulary can be increased in stages. This approach is
better than starting development of an unlimited vocabulary speech recognition system directly (and
after two years, realizing that it is very difficult!).

Disadvantages of Evolutionary Model

i. Lack of process visibility
ii. Systems are often poorly structured
iii. Special skills (e.g. in languages for rapid prototyping) may be required

When to use Evolutionary Model

i. For small or medium-size interactive systems
ii. For parts of large systems (e.g. the user interface)
iii. For short-lifetime systems

6.3.5 INCREMENTAL MODEL

The incremental model the whole requirement is divided into various builds. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed modules. Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced during the first
module, so you have working software early on during the software life cycle. Each subsequent
release of the module adds function to the previous release. The process continues till the complete
system is achieved.

Advantages of Incremental model:

i. Generates working software quickly and early during the software life cycle.
ii. More flexible – less costly to change scope and requirements.
iii. Easier to test and debug during a smaller iteration.
iv. Customer can respond to each built.
v. Lowers initial delivery cost.
vi. Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:
i. Needs good planning and design.
ii. Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
iii. Total cost is higher than waterfall.

When to use the Incremental model:

i. Requirements of the complete system are clearly defined and understood.
ii. Major requirements must be defined; however, some details can evolve with time.
iii. There is a need to get a product to the market early.
iv. A new technology is being used
v. Resources with needed skill set are not available
vi. There are some high risk features and goals.

Discuss at least six software process models. Identify their advantages and disadvantages

phase. Such models are suitable for projects with very clear product requirements and where the

Software Prototype and evolutionary are modern techniques to understand the requirements in a
Ian Sommerville (2011) Software Engineering (11th Edition) Addison Wesley

Various Internet resources