Software Engineering and Testing

OBJECTIVES:

-oriented software engineering. make

students to get experience and be ready for the large scale projects in IT Industry.

Unit I Introduction:- Evolution – From an Art form on Engineering Discipline: Evolution of an

Art into an Engineering Discipline. – Software Development of Projects: Program versus Product
– Emergence of Software Engineering: Early Computer Programming – High Level Language
Programming – Control Flow-based Design – Data Structure Oriented Design –
Object Oriented Design. Software Life Cycle Models:- A few Basic Concepts – Waterfall Model
and its Extension: Classical Waterfall Model – Iterative Waterfall Model – Prototyping Model –
Evolutionary Model. – Rapid Application Development (RAD): Working of RAD. – Spiral Model.
(12L)

Unit II Software Project Management:- Responsibilities of a Software Project Manager –

Project Planning- Project Estimation Techniques-Risk Management. Requirements Analysis and
Specification:- Requirements Gathering and Analysis – Software Requirements Specifications
(SRS):Users of SRS Document – Characteristics of a Good SRS Document – Important
Categories of Customer Requirements – Functional Requirements – How to Identify the
Functional Requirements? – Organisation of the SRS Document. (12L)

Unit III Software Design:- Overview of the Design Process: Outcome of the Design Process –
Classification of Design Activities. – How to Characterize a good Software Design? Function
Oriented Software Design:- Overview of SA/SD Methodology – Structured Analysis –
Developing the DFD Model of a System: Context Diagram – Structured Design – Detailed
Design. (12L) Page 29 of 57

Unit IV User Interface Design:- Characteristics of a good User Interface - Basic Concepts –
Types of User Interfaces – Fundamentals of Components based GUI Development: Window
System. Coding and Testing:- Coding – Software Documentation – Testing: Basic Concepts and
Terminologies – Testing Activities. – Unit Testing – Black-box Testing: Equivalence Class
Partitioning – Boundary Value Analysis. – White-box Testing. (12L)

Unit V Software Reliability and Quality Management:- Software Reliability: Hardware versus
Software Reliability. – Software Quality – Software Quality Management System – ISO 9000:
What is ISO 9000 Certification? – ISO 9000 for Software Industry – Shortcomings of ISO 9000
Certification. – SEI Capability Maturity Model: Level 1 to Level 5. Software Maintenance:-
Characteristics of Software Maintenance: Characteristics of Software Evolution – Software
Reverse Engineering. (12L)

Text Book: Fundamentals of Software Engineering Fourth Edition by Rajib Mall – PHI Learning
Private Limited 2015.
 UNIT-1
SOFTWARE ENGINEERING
Software engineering discusses systematic and cost-effective techniques for software
development. These techniques help develop software using an engineering approach.

Is software engineering a science or an art?

∙ Writing good quality programs is an art.

∙ Past experiences have been systematically organized and wherever possible theoretical basis
to the empirical observations have been provided.
∙ An appropriate solution is chosen out of the candidate solutions based on various trade offs
that need to be made on account of issues of cost, maintainability, and usability. ∙ Engineering
disciplines such as software engineering make use of only well-understood and
well-documented principles

1. EVOLUTION—FROM AN ART FORM TO AN ENGINEERING DISCIPLINE

∙ Early programmers used an ad hoc programming style. This style of program development is
now variously being referred to as exploratory, build and fix, and code and fix styles.
∙ The exploratory programming style is an informal style in the sense that there are no set
rules or recommendations that a programmer has to adhere to—every programmer himself
evolves his own software development techniques.

∙ Organisations are spending increasingly larger portions of their budget on software as

compared to that on hardware.
2. SOFTWARE DEVELOPMENT PROJECTS

A Professional software is developed by a group of software developers working together in a

team.
a) Types of Software Development Projects
1. Software products
∙ Microsoft’s Windows and the Office suite, Oracle DBMS, software accompanying a
camcorder or a laser printer, etc. These software are available off-the-shelf for purchase and
are used by a diverse range of customers. These are called generic software products 2.
Software services
∙ Customized software is developed according to the specification drawn up by one or at most
a few customers.
∙ Another type of software service i s outsourced software. Sometimes, it can make good
commercial sense for a company developing a large project to outsource some parts of its
development work to other companies
b) Software Projects Being Undertaken by Indian Companies
∙ Indian software companies have excelled in executing software services projects and have
made a name for themselves all over the world.

3. EMERGENCE OF SOFTWARE ENGINEERING

Software engineering techniques evolution is the result of a series of innovations and
accumulation of experience about writing good quality programs. They are a) Early Computer
Programming
b) High-level Language Programming
c) Control Flow-based Design
d) Data Structure-oriented Design
e) Data Flow-oriented Design
f) Object-oriented Design
g) Web based Design

a) Early Computer Programming

∙ Every programmer developed his own individualistic style of writing programs according to
his intuition and used this style ad hoc while writing different programs. ∙ Then designated this
style of programming as the build and fix (or the exploratory programming) style.
b) High-level Language Programming
∙ In 1960s high-level languages such as FORTRAN, ALGOL, and COBOL were introduced.
∙ Writing each high-level programming construct in effect enables the programmer to write
several machine instructions. Also, the machine details (registers, flags, etc.) are
abstracted from the programmer.
c) Control Flow-based Design
∙ experienced programmers advised other programmers to pay particular attention to the
design of a program’s control flow structure.
∙ A program’s control flow structure indicates the sequence in which the program’s
instructions are executed.

∙ If the flow chart representation is simple, then the corresponding code should be simple.
 Fig:Control flow graphs of the above programs
∙ For example, for the program of Fig 1.9(a) you would have to understand the execution of
the program along the paths 1-2-3-7-8-10, 1-4-5-6-9-10, and 1-4-5-2-3-7-8-10. A program
having a messy control flow (i.e. flow chart) structure, would have a large number of
execution paths.

Figure: CFG of a program having too many GO TO statements.

∙ Are GO TO statements the culprits?
 Dijkstra [1968] published his (now famous) article ―GO TO Statements Considered
Harmful‖. GO TO statements alter the flow of control arbitrarily, resulting in too many
paths.
∙ Structured programming
o A program is called structured when it uses only the sequence, selection, and
iteration types of constructs and is modular.
o Very soon several languages such as PASCAL, MODULA, C, etc., became
available which were specifically designed to support structured programming.

d) Data Structure-oriented Design

∙ It is much more important to pay attention to the design of the important data structures of
the program than to the design of its control structure.
∙ Design techniques based on this principle are called data structure- oriented design
techniques.
∙ Using data structure-oriented design techniques, first a program’s data structures are
designed. The code structure is designed based on the data structure.
e) Data Flow-oriented Design
∙ The data flow-oriented techniques advocate that the major data items handled by a system
must be identified and the processing required on these data items to produce the desired
outputs should be determined.
∙ The functions (also called as processes ) and the data items that are exchanged between the
different functions are represented in a diagram known as a data flow diagram (DFD).
f) Object-oriented Design
∙ Data flow-oriented techniques evolved into object-oriented design (OOD) techniques in the
late seventies.
∙ Natural objects relevant to a problem are first identified and then the relationships among the
objects such as composition, reference, and inheritance are determined. Each object
essentially acts as a data hiding (also known as data abstraction ) entity.
g) Web based design
∙ Many of the present day software are required to work in a client-server environment
through a web browser-based access (called web-based software ).
4. SOFTWARE LIFE CYCLE MODELS
In the software engineering approaches emphasize software development through a well-defined
and ordered set of activities. These activities are graphically modeled (represented) as well as
textually described and are variously called as software life cycle model, software development
life cycle (SDLC) model, and software development process model.
.
a) A few basic concepts of Software life cycle
∙ The software life cycle has been defined to imply the different stages (or phases) over which a
software evolves from an initial customer request for it, to a fully developed software, and
finally to a stage where it is no longer useful to any user, and then it is discarded.
∙ The life cycle of every software starts with a request for it by one or more customers. ∙ This
stage where the customer feels a need for the software and forms rough ideas about the required
features is known as the inception stage.
∙ A software evolves through a series of identifiable stages (also called phases) on account of
the development activities carried out by the developers, until it is fully developed and is
released to the customers.
∙ Once installed and made available for use, the users start to use the software. This signals
the start of the operation (also called maintenance) phase.
∙ The maintenance phase usually involves continually making changes to the software to
accommodate the bug-fix and change requests from the user.
∙ The operation phase is usually the longest of all phases and constitutes the useful life of a
software.
∙ Finally the software is retired
∙ The life cycle of a software represents the series of identifiable stages through which it
evolves during its life time.
Software development life cycle (SDLC) model
∙ A software development life cycle (SDLC) model (also called software life cycle model
and software development process model) describes the different activities that need to be
carried out for the software to evolve in its life cycle.
∙ The terms software development life cycle (SDLC) and software development process are
interchangeable.
∙ An SDLC graphically depicts the different phases through which a software evolves. It is
usually accompanied by a textual description of the different activities that need to be
carried out during each phase.
∙ Process and methodology are at time used interchangeably, there is a subtle difference
between the two. First, the term process has a broader scope and addresses either all the
activities taking place during software development, or certain coarse grained activities
such as design (e.g. design process), testing (test process), etc. Further, a software process
not only identifies the specific activities that need to be carried out, but may also prescribe
certain methodology for carrying out each activity.

A software development process has a much broader scope as compared to a software

development methodology. A process usually describes all the activities starting from the
inception of a software to its maintenance and retirement stages, or at least a chunk of activities in
the life cycle. It also recommends specific methodologies for carrying out each activity. A
methodology, in contrast, describes the steps to carry out only a single or at best a few individual
activities.

Software development organisations have realized that adherence to a suitable life cycle model
helps to produce good quality software and that helps minimize the chances of time and cost
overruns.

∙ Programming-in-the-small refers to development of a toy program by a single programmer.

∙ While development of a software of the former type could succeed even while an individual
programmer uses a build and fix style of development,
∙ Programming-in-the-large refers to development of a professional software through team
effort.
∙ Use of a suitable SDLC is essential for a professional software development project involving
team effort to succeed.
∙ A documented development process forms a common understanding of the activities to be
carried out among the software developers and helps them to develop software in a systematic
and disciplined manner.
∙ A documented development process model, besides preventing the misinterpretations that
might occur when the development process is not adequately documented, also helps to
identify inconsistencies, redundancies, and omissions in the development process.

Phase entry and exit criteria

 ∙ A good SDLC besides clearly identifying the different phases in the life cycle, should
unambiguously define the entry and exit criteria for each phase.
∙ The phase entry (or exit) criteria is usually expressed as a set of conditions that needs to be
be satisfied for the phase to start (or to complete).
∙ As an example, the phase exit criteria for the software requirements specification phase, can
be that the software requirements specification (SRS) document is ready, has been reviewed
internally, and also has been reviewed and approved by the customer. ∙ Only after these
criteria are satisfied, the next phase can start.

5. WATERFALL MODEL AND ITS EXTENSIONS

The waterfall model and its derivatives were extremely popular in the 1970s.
Classical Waterfall Model
∙ Classical waterfall model is intuitively the most obvious way to develop software. The classical
waterfall model divides the life cycle into a set of phases as shown in figure below.
Phases of the classical waterfall model

∙ The different phases are feasibility study, requirements analysis and specification, design, coding
and unit testing, integration and system testing, and maintenance.
∙ The phases starting from the feasibility study to the integration and system testing phase are
known as the development phases.
∙ A software is developed during the development phases, and at the completion of the
development phases, the software is delivered to the customer.

Fig. Phases of the classical water fall model

∙ After the delivery of software, customers start to use the software signaling the commencement
 of the operation phase.
∙ As the customers start to use the software, changes to it become necessary on account of bug
fixes and feature extensions, causing maintenance works to be undertaken. ∙ Therefore, the last
phase is also known as the maintenance
∙ An activity that spans all phases of software development is project management. Since it
spans the entire project duration, no specific phase is named after it.
∙ In the waterfall model, different life cycle phases typically require relatively different amounts
of efforts to be put in by the development team.
∙ On the average, about 60 per cent of the total effort put in by the development team in the entire
life cycle is spent on the maintenance activities alone.

Fig. Relative effort distribution among different phases.

∙ However, among the development phases, the integration and system testing phase requires the
maximum effort in a typical development project.

1. Feasibility study
∙ The main focus of the feasibility study stage is to determine whether it would be financially
and technically feasible to develop the software.
∙ Feasibility study involves carrying out several activities such as
o collection of basic information relating to the software such as the different data
items that would be input to the system,
o the processing required to be carried out on these data,
o the output data required to be produced by the system, as well as various
constraints on the development.
∙ These collected data are analyzed to perform at the following:
o Development of an overall understanding of the problem
o Formulation of the various possible strategies for solving the problem
o Evaluation of the different solution strategies.

2. Requirements 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, and
requirements specification.

a) Requirements gathering and analysis:

∙ The goal of the requirements gathering activity is to collect all relevant information regarding
the software to be developed from the customer with a view to clearly understand the
requirements.
∙ For this, first requirements are gathered from the customer and then the gathered requirements
are analyzed.

b)Requirements specification:
∙ After the requirement gathering and analysis activities are complete, the identified requirements
are documented.
∙ This is called a software requirements specification (SRS) document.
∙ The SRS document is written using end-user terminology.
∙ This makes the SRS document understandable to the customer.

3. Design
∙ The goal of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language. ∙ During the
design phase the software architecture is derived from the SRS document.

a) Procedural design approach:

∙ The traditional design approach is in use in many software development projects at the present
time.
∙ This traditional design technique is based on the data flow-oriented design approach. ∙ It consists
of two important activities; first 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 step where the results of structured analysis are transformed into the software design.
Structured design consists of two main activities—architectural design (also called high-level
design ) and detailed design (also called Low-level design).
∙ High-level design involves decomposing the system into modules, and representing the
interfaces and the invocation relationships among the modules.
∙ A high-level software design is sometimes referred to as the software architecture. ∙ During the
detailed design activity, internals of the individual modules such as the data structures and
algorithms of the modules are designed and documented

b) 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.
∙ The OOD approach is credited to have several benefits such as lower development time and
effort, and better maintainability of the software.
4. Coding and unit testing
∙ The purpose of the coding and unit testing phase is to translate a software design into source
code and to ensure that individually each function is working correctly.
∙ The coding phase is also sometimes called the implementation phase, since the design is
implemented into a workable solution in this phase.
∙ 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 individually unit tested.
∙ The main objective of unit testing is to determine the correct working of the individual modules.
The specific activities carried out during unit testing include designing test cases, testing,
debugging to fix problems, and management of test cases.

5. Integration and System Testing

∙ Integration of different modules is undertaken soon after they have been coded and unit tested.
∙ During the integration and system testing phase, the different modules are integrated in a
planned manner.

a) Integration testing is carried out to verify that the interfaces among different units are
working satisfactorily.
∙ On the other hand, the goal of system testing is to ensure that the developed system
conforms to the requirements that have been laid out in the SRS document.

b) System testing usually consists of three different kinds of testing activities: ∙ alpha-testing:
testing is the system testing performed by the development team. ∙ beta-testing: This is the
system testing performed by a friendly set of customers. ∙ Acceptance testing: After the
software has been delivered, the customer performs system testing to determine whether to
accept the delivered software or to reject it.
6. Maintenance
∙ The total effort spent on maintenance of a typical software during its operation phase is much
more than that required for developing the software itself.
∙ Many studies carried out in the past confirm this and indicate that the ratio of relative effort of
developing a typical software product and the total effort spent on its maintenance is roughly
40:60.
∙ Maintenance is required in the following three types of situations:

a) Corrective maintenance: This type of maintenance is carried out to correct errors that were
not discovered during the product development phase.
b) Perfective maintenance: This type of maintenance is carried out to improve the performance
of the system, or to enhance the functionalities of the system based on customer’s requests.

c) Adaptive maintenance: Adaptive maintenance is usually required for porting the software to
work in a new environment. For example, porting may be required to get the software to work on
a new computer platform or with a new operating system.

Shortcomings of the classical waterfall model

The classical waterfall model is a very simple and intuitive model. However, it suffers from
several shortcomings.
1. No feedback paths: Once a defect is detected at a later time, the developers need to redo some
of the work done during that phase and also redo the work of later phases that are affected by the
rework.
2. Difficult to accommodate change requests: The customers’ requirements usually keep on
changing with time. But, in this model it becomes difficult to accommodate any requirement
change requests made by the customer after the requirements specification phase is complete, and
this often becomes a source of customer discontent.
3. Inefficient error corrections:
This model defers integration of code and testing tasks until it is very late when the problems are
harder to resolve.
4. No overlapping of phases: This model recommends that the phases be carried out
sequentially—new phase can start only after the previous one completes.

6. ITERATIVE WATER FALL MODEL:

∙ The main change brought about by the iterative waterfall model to the classical waterfall model
is in the form of providing feedback paths from every phase to its preceding phases. ∙ The
feedback paths allow for correcting errors committed by a programmer during some phase, as and
when these are detected in a later phase.
∙ For example, if during the testing phase a design error is identified, then the feedback path
allows the design to be reworked and the changes to be reflected in the design documents and
all other subsequent documents.
∙ There is no feedback path to the feasibility stage.

Phase containment of errors: It is advantageous to detect these errors in the same phase in
which they take place, since early detection of bugs reduces the effort and time required for
 correcting those.
∙ In the later case, it would be necessary not only to rework the design, but also to appropriately
redo the relevant coding as well as the testing activities, thereby incurring higher cost.
∙ The principle of detecting errors as close to their points of commitment as possible is known as
phase containment of errors.
∙ After all, the end product of many phases is text or graphical documents, e.g. SRS document,
design document, test plan document, etc.

Phase overlap
∙ In spite of the best effort to detect errors in the same phase in which they are committed, some
errors escape detection and are detected in a later phase. An important reason for phase
overlap is that usually the work required to be carried out in a phase is divided among the
team members.
∙ Some members may complete their part of the work earlier than other members. If strict phase
transitions are maintained, then the team members who complete their work early would idle
waiting for the phase to be complete, and are said to be in a blocking state.

Shortcomings of the iterative waterfall model

1. Difficult to accommodate change requests: Based on the frozen requirements, detailed plans
are made for the activities to be carried out during the design, coding, and testing phases. Since
activities are planned for the entire duration, substantial effort and resources are invested in the
activities as developing the complete requirements specification, design for the complete
functionality and so on. Once requirements have been frozen, the waterfall model provides no
scope for any modifications to the requirements.

2. Incremental delivery not supported: In the iterative waterfall model, the full software is
completely developed and tested before it is delivered to the customer. There is no provision for
any intermediate deliveries to occur.

3. Phase overlap not supported: For most real life projects, it becomes difficult to follow the
rigid phase sequence prescribed by the waterfall model. By the term a rigid phase sequence, we
mean that a phase can start only after the previous phase is complete in all respects. As already
discussed, strict adherence to the waterfall model creates blocking states.

4. Error correction unduly expensive: In waterfall model, validation is delayed till the complete
development of the software. As a result, the defects that are noticed at the time of validation
incur expensive rework and result in cost escalation and delayed delivery.

5. Limited customer interactions: This model supports very limited customer interactions. It is
generally accepted that software developed in isolation from the customer is the cause of many
problems. In fact, interactions occur only at the start of the project and at project completion.

6. No support for risk handling and code reuse: It becomes difficult to use the waterfall model
in projects that are susceptible to various types of risks, or those involving significant reuse of
existing development artifacts. Please recollect that software services types of projects usually
involve significant reuse.

7. PROTOTYPING MODEL
∙ The prototype model suggests building a working prototype of the system, before development
of the actual software.
∙ A prototype is a toy and crude implementation of a system.
∙ It has limited functional capabilities, low reliability, or inefficient performance as compared to
the actual software.
∙ A prototype can be built very quickly by using several shortcuts.
∙ The shortcuts usually involve developing inefficient, inaccurate, or dummy functions. ∙
Normally the term rapid prototyping is used when software tools are used for prototype
construction.
∙ For example, tools based on fourth generation languages (4GL) may be used to construct the
prototype for the GUI parts.
Necessity of the prototyping model
∙ The prototyping model is advantageous to use for specific types of projects.
∙ It is advantageous to use the prototyping model for development of the graphical user interface
(GUI) part of an application.
∙ Through the use of a prototype, it becomes easier to illustrate the input data formats, messages,
reports, and the interactive dialogs to the customer.
o The prototyping model is especially useful when the exact technical solutions are unclear to
the development team.
∙ Often, major design decisions depend on issues such as the response time of a hardware
controller, or the efficiency of a sorting algorithm, etc.
∙ In such circumstances, a prototype is often the best way to resolve the technical issues.
o The prototyping model is considered to be useful for the development of not only the GUI
parts of a software, but also for a software project for which certain technical issues are not clear
to the development team.
Figure 2.6: Prototyping model of software development.

Life cycle activities of prototyping model

∙ The prototyping model software is developed through two major activities—prototype
construction and iterative waterfall-based software development.
Prototype development: Prototype development starts with an initial requirements gathering
phase.
∙ A quick design is carried out and a prototype is built.
∙ The developed prototype is submitted to the customer for evaluation.
∙ Based on the customer feedback, the requirements are refined and the prototype is suitably
modified.
∙ This cycle of obtaining customer feedback and modifying the prototype continues till the
customer approves the prototype.
Iterative development: Once the customer approves the prototype, the actual software is
developed using the iterative waterfall approach.
∙ In spite of the availability of a working prototype, the SRS document is usually needed to be
developed since the SRS document is invaluable for carrying out traceability analysis,
verification, and test case design during later phases.
Strengths of the prototyping model
∙ This model is the most appropriate for projects that suffer from technical and requirements risks.
 A constructed prototype helps overcome these risks.
Weaknesses of the prototyping model
∙ The prototype model can increase the cost of development for projects that are routine
development work and do not suffer from any significant risks.
∙ Even when a project is susceptible to risks, the prototyping model is effective only for those
projects for which the risks can be identified upfront before the development starts. ∙ Since the
prototype is constructed only at the start of the project, the prototyping model is ineffective for
risks identified later during the development cycle.

8. EVOLUTIONARY MODEL
∙ The software is developed over a number of increments. At each increment, a concept is
implemented and is deployed at the client site.
∙ The software is successively refined and feature-enriched until the full software is realized. ∙ In
evolutionary model, the requirements, plan, estimates and solution evolve over the iterations
rather than fully defined and frozen in a major up front specification effort before the
development iterations begin.

∙ The evolutionary model is sometimes referred to as design a little, build a little, test a little,
deploy a little model.
∙ After the requirements have been specified, the design, build, test and deployment activities are
iterated.
Advantages:
∙ 1. Effective elicitation of actual customer requirements: The user gets a chance to
experiment with a partially developed software much before the complete requirements
are developed. SO the change request after delivery of the complete software gets
substantially reduced.
∙ 2. Easy handling change requests: Handling change requests is easier as no long term plans
are made. Reworks required are much smaller.
Disadvantages:
1. Feature division into incremental parts can be non-trivial: For small sized projects it is
difficult to divide the required features into several parts for incrementally implemented and
delivered. For larger problems, features are intertwined that expert would need considerable
effort to plan the incremental deliveries.
2. Adhoc design: Design for only the current increment is done, the design can become adhoc
without specific attention being paid to maintainability and optimality.
Applicability of evolutionary model:
∙ The evolutionary model is well suited to use in object oriented software development
projects.

9. RAPID APPLICATION DEVELOPMENT (RAD):

∙ This model has the features of both prototyping and evolutionary models. ∙ In this model
prototypes are constructed and incrementally the features are developed and delivered to the
customer.
∙ But the prototypes are not thrown away but are enhanced and used in the software construction.
∙ The major goals of the RAD model are as follows:
1. To decrease the time taken and the cost incurred to develop software systems.
2. TO limit the costs of accommodating change requests.
3. TO reduce the communication gap between the customer and the developers.
Main motivation: The RAD model tries to overcome the problems of customer expectations,
change requests of the customer, taking long time to have a good solution by inviting and
incorporating customer feedback on successively developed and refined prototypes.
Working of RAD:
∙ In the RAD model, development takes place in a series of short cycles or iterations. ∙ At any
time, the development team focuses on the present iteration only and therefore plans are made for
one increment at a time. The time planned for each iteration is called a time box.
∙ Each iteration is planned to enhance the implemented functionality of the application by only a
small amount.
∙ During each time box, a quick and duty prototype style software for some functionally is
developed.
∙ The customer evaluates the prototype and gives feedback on the specific improvements. ∙ The
development team consists of about five to six members including a customer representative.
How does RAD facilitate accommodation of change requests:
∙ Features are delivered in small increments, incorporation of such change requests just after the
delivery of an incremental feature saves cost as this is carried out before large investments have
been made in development and testing of a large number of features.
How does RAD facilitate Faster development:
∙ The decrease in development time and cost and at the same time an increased flexibility to
incorporate changes are achieved in the RAD model in two ways:
1. Minimal use of planning and heavy reuse of any existing code through rapid prototyping. 2.
The lack of long term an and detailed planning gives the flexibility to accommodate later
requirements changes.
Applicability of RAD Model:
1. Customized software: Automated package , tailored, educational software. 2. Non-critical
software: Developed product is usually far from being optimal in performance and reliability.
3. Highly constrained project schedule: RAD aims to reduce development time at the expense
of good documentation, performance and reliability.
4. Large software: software supporting many features can incremental development and delivery.

10. SPIRAL MODEL

∙ The model gets its name from the appearance of its diagrammatic representation that looks like a
spiral with many loops.
∙ The exact number of loops of the spiral is not fixed and can vary from project to projects. ∙
Each loop of the spiral is called a phase of the software process.
∙ The exact number of phases through with the product is developed can be varied by the project
manager depending upon the project risks.
∙ Over each loop one or more features of the product are elaborated and analyzed and the risks at
that point of time are identified and are resolved through prototyping.

Risk handling in spiral model:

∙ A risk is essentially any adverse circumstance that hamper the successful completion of a
software project.
∙ The risk can be resolved by building a prototype of the subsystem and experimenting with the
exact fault.
Phases of the Spiral Model:

∙ Each phase in the model is split into four sectors(quadrants).

∙ In the first quadrant , a few features of the software are identified to be taken up for immediate
development based on how crucial it is to the software development

Quadrant 1: The objectives are investigated, elaborated and analyzed. The risks involved in the
phase objectives are identified. Alternative solutions are proposed.

Quadrant 2: The alternative solutions are evaluated to select the best possible solution. The
solutions are evaluated by developing an appropriate prototype.

Quadrant 3: Activities consist of developing and verifying the next level of the software, The
identified features have been implemented and next version of the software is available.

Quadrant 4: Reviewing the results of the stages traversed so far with the customer and planning
the next iteration of the spiral.

∙ The radius of the spiral at any point represents the cost incurred in the project so far. ∙ To the
developers of a project the spiral model usually appears as a complex model to follow since it is
risk driven and is more complicated phase structure than other models. ∙ For projects having many
unknown risks that show up as the development proceeds, the spiral model would be the most
appropriate development model to follow.