MANAKULA VINAYAGAR INSTITUTE OF TECHNOLOGY

KALITHEERTHAL KUPPAM, PUDHUCHERY -605 107

DEPARTMENT OF CSE
SOFTWARE ENGINEERING (CS T55)

UNIT –I Introduction to Software Engineering

Introduction to Software Engineering: The Software Engineering Discipline – Evolution and

Impact – Software Development projects – Emergence of Software Engineering – Computer
System Engineering – Software Life Cycle Models – classic Waterfall model – Iterative
Lifecycle model – prototyping model – Evolutionary model – spiral model – Comparison of Life
cycle models.
---------------------------------------------------------------------------------------------------------------------

1.1 Introduction:

Commercial usage of computers now spans the last sixty years.

Computers were very slow in the initial years and lacked sophistication.
Since then, their computational power and sophistication increased rapidly, while their
prices dropped dramatically.
If similar improvements could have occurred to aircrafts, now personal mini-airplanes
should have become available, costing as much as a bicycle, and flying at over 1000 times
the speed of the supersonic jets.

What is software engineering?

―A systematic collection of good program development practices and techniques‖. The
essence of all past programming experiences and innovations for writing good quality
programs in cost- effective and efficient ways have been systematically organized into a
body of knowledge. This knowledge forms the foundation of the software engineering
principles.

Why software engineering neither a form of science nor an art?

Software engineering makes heavy use of the knowledge that has accrued from the
experiences of a large number of practitioners. In contrast, all scientific solutions are
constructed through rigorous application of provable principles.
As is usual in all engineering disciplines, in software engineering several conflicting goals
are encountered while solving a problem. An appropriate solution is chosen out of the
solutions based on various trade-offs that need to be made on account of issues of cost,
maintainability, and usability.

Page | 1
 Engineering disciplines such as software engineering make use of only well-understood
and well-documented principles. Art, on the other hand, is often based on making
subjective judgment based on qualitative attributes and using ill-understood principles.
From this it seems that software engineering neither a form of science nor an art.
1.2 The Software Engineering Discipline – Its evolution and impact

Evolution of an Art into an Engineering Discipline

The early programmers used an ad hoc programming style. This style of program
development is also called as exploratory, build and fix, and code and fix styles.
In a build and fix style, a program is quickly developed without making any specification,
plan, or design.
In the build and fix method (exploratory model), normally a poor quality program is
quickly developed without making any specification, plan, or design. The different
imperfections that are subsequently noticed while using or testing are fixed.
The exploratory programming style is an informal style, there are no set rules or
recommendations. Every programmer himself evolves his own software development
techniques solely guided by his own intuition, experience, whims, and fancies. The
exploratory style comes naturally to all first time programmers.
Exploratory program development style is an art
The programmers working in modern software industry rarely make use of any esoteric
knowledge and develop software by applying some well-understood principles.

Evolution Pattern for Engineering Disciplines

Art – Esoteric use of past experience
Craft – unorganized use of past experience
Engineering – Systematic use of past experience and formulation of scientific basis
Evolution of technology with time:

Page | 2
A Solution to the Software Crisis
The expenses that organizations all over the world are incurring on software purchases as
compared t o the expenses incurred on hardware purchases
Many organizations are actually spending much more on software than on hardware.
The symptoms of software crisis are,
o rapidly increasing problem size
o lack of adequate training in software engineering techniques
o increasing skill shortage
o low productivity improvement
Satisfactory solution to the present software crisis can possibly come from a spread of
software engineering practices among the developers.

Relative changes of hardware and software costs over time

1.3 Software development projects

Programs versus Products
Types of software development projects

Programs versus Products

Programs Products
Toy software (Programs) are being developed Professional software is developed by a group
by individuals such as students for their of software developers working together in a
classroom assignments and hobbyists for their team.
personal use.
These are usually small in size and support Professional software (product) is often too
limited functionalities. large and complex to be developed by any
single individual.
The author of a program is usually the sole Professional software usually have multiple

Page | 3
User of the software and he maintains the code.Users and, therefore, have good user-interface,
proper
Therefore it has lack of good user-interface and user’s manuals, and good
lack of proper documentation. documentation support.
These programs have poor maintainability, These Professional software’s have good
poor efficiency, and poor reliability. maintainability, good efficiency, and good
reliability.
Programs do not have any supporting A professionally written software usually
documents such as users’ manual, maintenance consists not only of the program code but also
manual, design document, test documents, etc., all associated documents such as requirements
specification document, design document, test
document, user’s manuals, etc.,

Types of software development projects

There are two types of software development projects. They are,

Software products
Outsourced projects
Software products

Software such as Microsoft’s Windows and the Office suite, Oracle DBMS, or a laser
printer, etc. These are called generic software products since many users essentially use
the same software.
When a software development company wishes to develop a generic product, it first
determines the features or functionalities that would be useful to a large cross section of
users.
Development team draws up the product specification on its own. Its design based on
feedbacks collected from a large number of users.

Outsourced projects

A software service usually involves either development of a customized software or

development of some specific part of software in an outsourced mode.
Customized software is developed according to the specification drawn up by one or at
most a few customers.
These need to be developed in a short time frame (typically a couple of months), and at
the same time the development cost must be low.
It makes good commercial sense for a company developing a large project to outsource
some parts of its development work to other companies.
Reason for outsourced project may be, if it feels that it does not have sufficient expertise
to develop some specific parts of the software.
If it determines that some parts can be developed cost-effectively by another company.
Since an outsourced project is a small part of some larger project and need to be
completed within a few months or a few weeks of time.

Page | 4
1.4 Emergence of Software Engineering
Software engineering techniques have evolved over many years in the past. This
evolution is the result of a series of innovations and accumulation of experience about writing
good quality programs. Some of these are as follows,

Early Computer Programming

High-level Language Programming
Control Flow-based Design
Data Structure-oriented Design
Data Flow-oriented Design
Object-oriented Design

Early Computer Programming

Early commercial computers were very slow and too elementary as compared to today’s
standards.
Even simple processing tasks took considerable computation time on those computers.
Programs at that time were very small in size and lacked sophistication.
Those programs were usually written in assembly languages.
Program lengths were typically limited to about a few hundreds of lines of monolithic
assembly code.
Every programmer developed his own individualistic style of writing programs according
to his intuition and used this style ad hoc while writing different programs.
Programmers wrote programs without formulating any proper solution strategy, plan, or
design and jump to the terminal and start coding immediately on hearing out the problem.
This style of programming is called as the build and fix (or the exploratory programming)
style.

High-level Language Programming

Computers became faster with the introduction of the semiconductor technology in the
early 1960s.
Faster semiconductor transistors replaced the prevalent vacuum tube-based circuits in a
computer.
With the availability of more powerful computers, it became possible to solve larger and
more complex problems.
At this time, high-level languages such as FORTRAN, ALGOL, and COBOL were
introduced.
This considerably reduced the effort required to develop software and helped
programmers to write larger programs.
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.

Page | 5
 However, programmers were still using the exploratory style of software development.
Typical programs were limited to sizes of around a few thousands of lines of source
code.

Control Flow-based Design

As the size and complexity of programs kept on increasing, the exploratory programming
style proved to be insufficient.
Programmers found it increasingly difficult not only to write cost-effective and correct
programs, but also to understand and maintain programs written by others.
To cope up with this problem, 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.
To develop programs having good control flow structures, the flow charting technique
was developed. The flow charting technique is being used to represent and design
algorithms.

Unstructured and structured program:

Unstructured program consists of number of GOTO statements, but structured programs

are very simple to look.
A program is called structured when it uses only the sequence, selection, and iteration
types of constructs and is modular.

Page | 6
 The control flow graph of the Unstructured and structured program

Several languages such as PASCAL, MODULA, C, etc., became available which were
specifically designed to support structured programming.
These programming languages facilitated writing modular programs and programs
having good control structures.
It focused on designing good control structures to designing good data structures for
programs.

Data Structure-oriented Design

Computers became even more powerful with the advent o f integrated circuits (ICs) in the
early seventies.
These could now be used to solve more complex problems. Software developers were
tasked to develop larger and more complicated software.
It often required writing in excess of several tens of thousands of lines of source code.
The control flow-based program development techniques could not be used satisfactorily
any more to write those programs, and more effective program development techniques
were needed.
It is much more important to pay attention to the design 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.
Data structure-oriented design technique is the Jackson’s Structured Programming (JSP)
technique developed by Michael Jackson.
In JSP methodology, a program’s data structure is first designed using the notations for
sequence, selection, and iteration.
JSP methodology provides an interesting technique to derive the program structure from
its data structure representation.
This techniques became very popular and were extensively used.

Page | 7
Data Flow-oriented Design

As computers became still faster and more powerful with the introduction of very large
scale integrated (VLSI) Circuits and some new architectural concepts, more complex and
sophisticated software were needed to solve further challenging problems.
Therefore, software developers looked out for more effective techniques for designing
software and soon data flow-oriented techniques were proposed.
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).
The program structure can be designed from the DFD representation of the problem.

Data flow model for a car assembly plant

Object-oriented Design

Data flow-oriented techniques evolved into object-oriented design (OOD) techniques in

the late seventies.
Object-oriented design technique is naturally an attractive approach, where the natural
objects (such as employees, pay-roll-register, etc.) 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.
Object-oriented techniques have gained wide spread acceptance because of their
simplicity, the scope for code and design reuse, lower development time, lower
development cost, more robust code, and easier maintenance.

Page | 8
Evolution of software design techniques

1.5 Computer System Engineering

Page | 9
 Software being developed would run on some general-purpose hardware platform such as
a desktop computer or a server.
In several situations it may be necessary to develop special hardware on which the
software would run.
o Examples of such systems are a robot, a factory automation system, and a cell
phone.
o In a cell phone, there is a special processor and other specialized devices such as a
speaker and microphone. I t can run only the programs written specifically for it.
Development of such systems entails development of both software and specific
hardware that would run the software.
Computer systems engineering addresses development of such systems requiring
development of both software and specific hardware to run the software.
Systems engineering is the stage in which decision is made regarding the parts of the
problems that are to be implemented in hardware and that would be implemented in
software.
While partitioning the functions between hardware and software, several trade-offs such
as flexibility, cost, speed of operation, etc., need to be considered. \
The functionality implemented in hardware run faster and functionalities implemented in
software is easier to extend.
It is difficult to implement complex functions in hardware. Also, functions implemented
in hardware incur extra space, weight, manufacturing cost, and power overhead.
After the hardware-software partitioning stage, development of hardware and software
are carried out concurrently.
The hardware on which the software would run and tested would still be under
development, that the hardware and the software are being developed at the same time.
To test the software during development, it usually becomes necessary to develop
simulators of the hardware being developed.
The software is tested using these simulators. Once both hardware and software
development are complete, these are integrated and tested.

1.6 Software Life Cycle Models

Early the software product is developed using build and fix style (exploratory program
development style). It consists of several disadvantages.
Thus we moved to the software engineering approaches that develop software through a
well-defined and ordered set of activities.
These kinds of approaches are variously called as software life cycle model, software
development life cycle (SDLC) model, and software development process model.

Software life cycle

The term software life cycle has been defined to imply the different stages (or phases)
over which software evolves from an initial customer request for it, to fully developed software,
and finally to a stage where it is no longer useful to any user, and then it is discarded.

Page | 10
 The life cycle of software represents the series of identifiable stages through which it
evolves during its life time.

Software development life cycle (SDLC) model

In build and fix style there is number of disadvantages; mostly the projects developed in this style are
failure projects.
The software engineering approaches emphasize software development through a well-defined and
ordered set of activities. These activities are graphically modeled 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.

Process versus methodology

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 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.
Use of software life cycle model

Software development organizations 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

Why document a life cycle model

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 are usually expressed as a set of conditions that needs to 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.
If the entry and exit criteria for various phases are not well-defined, then that would leave enough
scope for ambiguity in starting and ending various phases, and cause lot of confusion among the
developers.

Page | 11
 Types of software life cycle model:

Classic Waterfall model

Iterative Lifecycle model
Prototyping model
Evolutionary model
Spiral model

1.7 Classic Waterfall model

Classical waterfall model is intuitively the most obvious way to develop software.
It is not a practical model in the sense that it cannot be used in actual development
projects.
This model is considered as theoretical way of developing software.

Phases of the classical waterfall model

The phases starting from the feasibility study to the integration and system testing phase are
known as the development phases.
Software is developed during the development phases, and at the completion of the development
phases, the software is delivered to the customer.
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 phase of the life cycle.

Page | 12
Effort needed for each phase:

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
The feasibility study involves carrying out several activities such as collection of basic
information relating to the software such as
o 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
o Various constraints on the development.

These collected data are analyzed to perform at the following:

An abstract of problem definition: Only the important requirements of the customer are captured and
the details of the requirements are ignored
Formulation of the various possible strategies for solving the problem: All the different ways in
which the problem can be solved are identified
Evaluation of the different solution strategies:
The different identified solution schemes are analyzed to evaluate their benefits and
shortcomings.
Such evaluation requires approximate estimates of the resources required, cost of development,
and development time required.
The different solutions are compared based on the estimations that have been worked out.
Once the best solution is identified, all activities in the later phases are carried out as per this
solution.

Page | 13
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.
It consists of two activities,
Requirements gathering and analysis
Requirements specification

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.
First requirements are gathered from the customer and then the gathered requirements are
analyzed.
The goal of the requirements analysis activity is to weed out the incompleteness and
inconsistencies in these gathered requirements.
Inconsistent requirement is one in which some part of the requirement contradicts with some
other part.
Incomplete requirement is one in which some parts of the actual requirements have been omitted.

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.
The SRS document normally serves as a contract between the development team and the
customer.
Any future dispute between the customer and the developers can be settled by examining the SRS
document.
The SRS document is therefore an important document which must be thoroughly understood by
the development team, and reviewed jointly with the customer.
The SRS document not only forms the basis for carrying out all the development activities, but
several documents such as users’ manuals, system test plan, etc. are prepared directly based on it.
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.
Two different design approaches procedural and object-oriented design approaches.

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
o First structured analysis of the requirements specification is carried out where the detailed
structure of the problem is examined.
o This is followed by a structured design step where the results of structured analysis are
transformed into the software design.

Page | 14
 During structured analysis, the functional requirements specified in the SRS document are
decomposed into subfunctions and the data-flow among these subfunctions is analyzed and
represented diagrammatically in the form of DFDs.
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.

Object-oriented design approach

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.

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.

Integration and system testing

During the integration and system testing phase, the different modules are integrated in a planned
manner.
During each integration step, previously planned modules are added to the partially integrated
system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the full working
system is obtained. System testing is carried out on this fully working system.

System testing usually consists of three different kinds of testing activities:

α-testing: testing is the system testing performed by the development team.

β-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.
Maintenance
Maintenance is required in the following three types of situations:
Corrective maintenance: This type of maintenance is carried out to correct errors that were not
discovered during the product development phase.

Page | 15
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.

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

No feedback paths
Difficult to accommodate change requests
Inefficient error corrections
No overlapping of phases

1.8 Iterative Waterfall 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 programmer during some phase, when errors
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.

Page | 16
Phase containment of errors

The principle of detecting errors as close to their points of commitment as possible is known as 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.
o For example, if a design problem is detected in the design phase itself, then the problem
can be taken care of much more easily than if the error is identified, say, at the end of the
testing phase.
o 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.
o It may not always be possible to detect all the errors in the same phase in which they are
made.
o The errors should be detected as early as possible.

Phase overlap

Two main reasons for 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. These subsequently detected errors cause
the activities of some already completed phases to be reworked. If we consider such rework after
a phase is complete, we can say that the activities pertaining to a phase do not end at the
completion of the phase, but overlap with other phases
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

Difficult to accommodate change requests

Incremental delivery not supported
Phase overlap not supported
Error correction unduly expensive
Limited customer interactions
Heavy weight
No support for risk handling and code reuse

Page | 17
1.9 Prototyping Model
The prototype model is also a popular life cycle model.
The prototyping model can be considered to be an extension of the waterfall model.
This model suggests building a working prototype of the system, before development of
the actual software.
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.

Page | 18
Necessity of the prototyping model

It is advantageous to use the prototyping model for development of the graphical user interface
(GUI) part of an application.
it becomes easier to illustrate the input data formats, messages, reports, and the interactive dialogs
to the customer.
The GUI part of a software system is almost always developed using the prototyping model.
The prototyping model is especially useful when the exact technical solutions are unclear to the
development team.
A prototype can help them to critically examine the technical issues associated with product
development.
An important reason for developing a prototype is that it is impossible to ―get it right‖ the first
time.
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.

Life cycle activities of prototyping model

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.
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.
For GUI parts, the requirements analysis and specification phase becomes redundant since the
working prototype that has been approved by the customer serves as an animated requirements
specification.
The code for the prototype is usually thrown away. But the experience gathered from developing
the prototype helps a great deal in developing the actual system.

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.

Page | 19
 The prototyping model is effective only for those projects for which the risks can be identified
upfront before the development starts.
It is constructed only at the start of the project; the prototyping model is ineffective for risks
identified later during the development cycle.
The prototyping model would not be appropriate for projects for which the risks can only be
identified after the development is underway.

1.10 Evolutionary Model

This life cycle model is sometimes referred to as the successive versions model or the incremental
model.
In this life cycle model, first a simple working system implementing only a few basic features is
built and delivered to the customer.
It is sometime referred to as design a little, build a little, test a little, deploy a little model.

In the incremental life cycle model, the requirements of the software are first broken down into
several modules.
The development team first develops the core modules of the system.
The core modules are those that do not need service from other modules and the non-core
modules need service from core modules.
Once the initial core features are developed, these are refined into increasing levels of capability
by adding new functionalities in successive versions.
Each incremental version is usually developed using an iterative waterfall model of development.
Each delivered version of the software incorporates additional features over the previous version
and also refines the features that were already delivered to the customer.

Advantages

Error reduction
Incremental resource deployment
Effective elicitation of actual customer requirements

Page | 20
 Easy handling change requests

Disadvantages

Feature division into incremental parts can be non-trivial

Ad hoc design

Applicability of the evolutionary model

The evolutionary model is normally useful for very large products, where it is easier t o find
modules for incremental implementation.
The evolutionary model is well-suited to use in object-oriented software development projects.

Page | 21
1.11 Spiral Model
This 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 project. Each
loop of the spiral is called a phase of the software process.
The exact number of phases through which the product is developed can be varied by the project
manager depending upon the project risks.
It is more flexible because the number of phases is not fixed.

Risk handling in spiral model

A risk is essentially any adverse circumstance that might hamper the successful completion of a
software project.
As an example, consider a project for which a risk can be that data access from a remote database
might be too slow to be acceptable by the customer.
This risk can be resolved by building a prototype of the data access subsystem and experimenting
with the exact access rate.
The spiral model supports coping up with risks by providing the scope to build a prototype at
every phase of software development.

Phases of spiral model

Page | 22
Quadrant 1: Determine objectives and identify alternative solutions
The objectives are investigated, elaborated, and analyzed. Based on this, the risks involved in
meeting the phase objectives are identified. In this quadrant, alternative solutions possible for the phase
under consideration are proposed.

Quadrant 2: Identify and resolve risks

During the second quadrant, the alternative solutions are evaluated to select the best possible
solution. To be able to do this, the solutions are evaluated by developing an appropriate prototype.

Quadrant 3: Review and plan for the next phase

Activities during the third quadrant consist of developing and verifying the next level of the
software. At the end of the third quadrant, the identified features have been implemented and the next
version of the software is available.

Quadrant 4: Develop next level of the product

Activities during the fourth quadrant concern reviewing the results of the stages traversed so far
(i.e. the developed version of the software) with the customer and planning the next iteration of the spiral.

Disadvantages of the spiral model

the spiral model that restrict its use to a only a few types of projects.
The spiral model usually appears as a complex model to follow, since it is risk-driven and is more
complicated phase structure than the other models.

Advantages of the spiral model

The spiral model would be the most appropriate development model to follow.
It is much more powerful than the prototyping model.
Prototyping model can meaningfully be used when all the risks associated

Spiral model as a Meta model

The spiral model can be viewed as a Meta model.

For example, a single loop spiral actually represents the waterfall model.
The spiral model uses the approach of the prototyping model by first building a prototype in each
phase before the actual development starts. This prototype is used as a risk reduction mechanism.
The spiral model incorporates the systematic step- wise approach of the waterfall model.
Also, the spiral model can be considered as supporting the evolutionary model.
This enables the developer to understand and resolve the risks at each evolutionary level

Page | 23
 QUESTION BANK
2 Marks:

1. Define software engineering.

2. Why to study software engineering?
3. Why software engineering neither a form of science nor an art?
4. Define exploratory style.
5. Which factors have precipitated the present software crisis?
6. What are the types of software development projects?
7. Define control flow structure.
8. What is structured program and unstructured program?
9. Define data structured oriented design techniques.
10. Define data flow oriented design techniques.
11. Define data flow diagram.
12. Define object oriented design techniques.
13. Define life cycle model.
14. Define product conception.
15. Define software life cycle.
16. Define the term process and methodology.
17. Why use of life cycle model?
18. Why document a life cycle model?
19. What are phase entry and phase exit criteria?
20. What is the different life cycle model?
21. What is classical waterfall model?
22. What are the types of phases in classical waterfall model?
23. What are the steps followed by feasibility study in life cycle model?
24. What is requirements gathering and analysis?
25. What is requirements specification?
26. What are the two different types of design approaches?
27. What is traditional design approach?
28. What is object oriented design approach?
29. Define coding phases.
30. Define unit testing.
31. What is integration?
32. Define system testing.
33. What is maintenance phase?
34. What are the activities involved in maintenance phase?
35. Write the disadvantages of classical waterfall model.
36. Is the classical waterfall model useful at all?
37. Define phase containment errors.
38. Disadvantages of iterative waterfall model.

Page | 24
 39. Define the term rigid phase sequence.
40. Define prototype.
41. What are the types of development phase in iterative model?
42. What are the phases in prototype development?
43. Define evolutionary model.
44. Give the advantages and disadvantages of evolutionary model.
45. What is spiral model?
46. What are phases of the spiral model?
47. Give the pros and cons of the spiral model.
48. How a spiral model can be viewed as a meta model?
49. How can we select an appropriate life cycle model for a project?
50. What is the radial dimension of the spiral model refers to?

11 Mark Questions:

1. Write about the software engineering discipline and its evolution and impact.
2. Explain about software development projects.
3. Explain about the emergence of software engineering.
4. Write about computer system engineering.
5. Explain about classical waterfall model.
6. Explain about iterative waterfall model.
7. Explain prototyping model with necessary example?
8. Explain evolutionary model.
9. Explain spiral model.
10. Write the comparison of different life cycle model.

Page | 25