LECTURE NOTES

SOFTWARE ENGINEERING

(6TH SEMESTER)

PREPARED BY: Debaranjan Nayak

Computer Science and Engineering

& Information Technology

Balasore College of Engineering and Technology.

 SOFTWARE ENGINEERING

MODULE 1
LECTURE 1

Introduction to software engineering

Software as we know is a set of programs containing instructions that provide desired functionality and Engineering is the
process of designing and building something that serves a particular purpose and finds a cost-effective solution to
problems. Hence Software Engineering is a systematic, disciplined, quantifiable study and approach for design,
development, operation, and maintenance of a software system.

Software engineering discusses systematic and cost-effective techniques for software development. This technique helps
in developing software using an engineering approach. An alternative definition of software engineering is: “An
engineering approach to develop software.

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress in user requirements and the
environment on which the program is working.

1.Huge Programming: It is simpler to build a wall than a house or building, similarly, as the measure of programming
become extensive engineering has to step to give it a scientific process.

2. Adaptability: If the software procedure were not based on scientific and engineering ideas, it would be simpler to re-
create new software than to scale an existing one.

3. Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let down the cost of computer
and electronic hardware. But the cost of programming remains high if the proper process is not adapted.

4. Dynamic Nature: The continually growing and adapting nature of programming hugely depends upon the environment
in which the client works. If the quality of the software is continually changing, new upgrades need to be done in the
existing one.

5. Quality Management: Better procedure of software development provides a better and quality software product.

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 which has aroused from customers need and is obtained by writing good quality programs for software
development.
Fig 1.1 Evolution of software design techniques.
 LECTURE 2

Software Crisis

Software Crisis is a term used in the field of computer science for expressing challenges the writing useful and
efficient computer programs in the required time. The software crisis occurred due to use of the same workforce, same
methods and same tools even though rapid increase in software demand, complexity of software, and software
challenges. With the increase in the complexity of software, many software problems arise because existing methods
were insufficient. If we will use the same workforce, same methods, and same tools after the fast increase in software
demand then there arise some problems like software budget problems, software efficiency problems, software quality
problems, software managing and delivering problem, etc. This condition is called a software crisis.

Fig 2.1 Representation of software crisis

The expenses that organizations all around the world are incurring on software purchases compared to those on hardware
purchases have been showing a challenging trend over the years.

Fig 2.2 Relative changes of hardware and software costs over time.
Organizations are spending larger and larger portions of their budget on software. Not only are the software products
becoming more expensive than hardware, but also they present a bunch of other problems to the customers. Software
products are difficult to alter, debug, and enhance; use resources non optimally; often fail to meet the user requirements;
are far from being reliable; frequently crash; and are often delivered late.

Among these, the trend of increasing software costs is probably the most important indication of the present
software crisis. Remember that the cost we are talking about is not on account of increased features, but due to ineffective
way of development. Product characterized by inefficient resource usage, and time and cost over-runs. There are many
factors that have contributed to the making of the present software crisis.

Factors are contributing to the software crisis.

 Poor project management.
 Inadequate training in software engineering field.
 Less skilled project members.
 Low improvements in productivity.

SOFTWARE PRODUCT

Before defining a software product, let us first know what a product is? A product is the final result of the work that we
may obtain after doing a series of work. For example, in a cotton mill, the cotton is the input, the machines work on it and
after all the processing, we get threads as our final product(output). In the case with the software product is also
somewhat similar. After all the processing, like the requirement analysis, designing, coding, testing and maintenance
work, the final software that is eligible to be presented as a product for its users is called the software product. Hence, the
software product can be defined as "The software that is eligible for being delivered to its customers or users is known as
the software product."

A software product is vividly different from a program. Programs is a set of instructions that are given to a computer in
order to achieve a specific task developed for a particular use hence they are small in size with limited functionality and
scope and needs very little documentation. Software products are set of programs which are extremely large, well
documented, must be developed using the accepted software engineering principles along with its licensing and then it is
made available for commercial business.

Types of software products:

Software products fall into two broad categories:

1) Generic products: Generic products are stand-alone systems/ software that are developed by a production unit and sold
on the open market to any customer who is able to buy them.

2) Customized Products: Customized products are the systems/software that are commissioned by a particular customer.
Some contractor develops the software for that customer.

Essential characteristics of Well-Engineered Software Product:

A well-engineered software product should holds the following essential characteristics:

1) Efficiency: The software/product should not make wasteful use of system resources such as memory and processor
cycles.
2) Maintainability: It should be possible to modify and update the software in order to meet the changing requirements of
customers in future.

3) Dependability: It is the flexibility of the software that determines not cause any physical or economic injury in the
event of system failure. It includes a range of characteristics such as reliability, security, and safety.

4) Time and Budget Friendly: The software development costs should not overrun and it should be within the budgetary
limit of the customer. It must also be delivered within the specified time.

5) Functionality: The software system should exhibit the proper functionality i.e. it should perform all the functions
appropriately which it is supposed to perform.

6) Adaptability: The software system should have the ability to get adapted to a reasonable extent with the changing
enviroment in near future.
 LECTURE 3
EXPLORATORY STYLE OF SOFTWARE DEVELOPMENT

The Exploratory program development style refers to an informal and conventional style of development where the
programmer makes use of his own intuitive mind to develop a program rather than making use the systematic approach of
knowledge implementation under the software engineering discipline. It imposes no protocols of SE and typical
development starts after an initial briefing from the customer’s need. Based on this briefing, the developers start coding to
develop a working product. The software is tested and the bugs found are fixed in iteration till the software works
satisfactorily for the customer. A schematic representation of this work sequence in a build and fix style has been shown
graphically below.

Fig 3.1 Exploratory program development.

Issues with exploratory style of software development

In an exploratory development scenario, let us see how do the effort and time required for developing a professional
software affected with the increase in program size. The increase in development effort and time with problem size has
been indicated below graphically.

Fig 3.2 Increase in development time and effort with problem size.

It can be seen from the figure that as the program size increases, the required effort and time also increases almost
exponentially. For large sized problems, it would take too much time and cost to be practically meaningful to develop the
program using the exploratory style of development hence the perceived complexity of a problem grows exponentially
with its size due to human cognitive limitations (it becomes practically infeasible to solve problems larger than a certain
size). Using this model no development team can remain competitive. To overcome these limitations, the concept and
principles of like Abstraction and Decomposition are used.

Shortcomings of the exploratory style of software development:

 The foremost difficulty is the exponential growth of development time and effort with problem size and large-
sized software becomes almost impossible using this style of development.
 The exploratory style usually results in unmaintainable code. The reason for this is that any code developed
without proper design would result in badly structured and poor quality code.
 It becomes very inefficient to use the exploratory style in a team development environment. In the exploratory
style, the development work is undertaken without any proper design and documentation.

Principle of Abstraction and Decomposition

Two important principles that are deployed by software engineering to overcome the problems arising due to human
cognitive limitations are—abstraction and decomposition

Abstraction refers to creation of a simpler version of a problem by ignoring the minute details. The principle of
constructing an abstraction is popularly known as modeling (or model construction). By using the principle of abstraction
to understand a complex problem, we focus our attention on only one or two specific aspects of the problem and ignore
the rest. Whenever we omit some details of a problem to construct an abstraction, we construct a model of the problem.

In technical terms, we can define Abstraction as the simplification of a problem by focusing only single aspect of the
problem while omitting all other aspects.

Fig 3.3 Abstraction representation

A single level of abstraction can be sufficient for rather simple problems. However, more complex problems would need
to be modeled as a hierarchy of abstractions. A schematic representation of an abstraction hierarchy has been shown in
above figure.

Decomposition is another important principle that is available in the repertoire of a software engineer to handle problem
complexity. This principle is profusely made use by several software engineering techniques to contain the exponential
growth of the perceived problem complexity. The decomposition principle is popularly known as the divide and conquers
principle.
In other words, the principle of decomposition emphasizes on decomposing the problem into many small independent
parts. The small parts are then taken up one after another and solved independently. The idea is that each small part would
be easy to understand and can be easily solved. The solution is accomplished when all the parts are solved. Figure below
shows the decomposition o f a large problem into many small parts.

Fig 4.4 Representation of decomposition

 LECTURE 4

EMERGENCE OF SOFTWARE ENGINEERING (Overview of software development activities)

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. Let us briefly examine few of these
innovations and programming experiences which have contributed to the development of the software engineering
discipline.

1) Early Computer Programming

Early commercial computers were very slow and too basic as compared to today’s models. Those programs were
usually written in assembly languages in individualistic style of the programmer. Even simple processing tasks
took considerable computation time on those systems. This approach have already been designated as the build
and fix (or the exploratory programming) style.

2) High-level Language Programming

Computers became faster with the introduction of the semiconductor technology in the early 1960s. Faster
semiconductor transistors replaced the vacuum tube-based circuits in a computer. With the availability of more
powerful computers, it became possible to solve larger and more complex problems in less time. 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 easily.

3) Control Flow-based Design

As the size and complexity of programs kept on increasing, the exploratory programming style proved to be
insufficient. It very problematic to write cost-effective and correct programs and even to understand and maintain
programs written by others. To solve 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.

In order to help develop programs having good control flow structures, the flow charting technique was
developed. Even today, the flow charting technique is being used to represent and design algorithms; though the
popularity of flow charting represent and design programs has want to a great extent due to the emergence of
more advanced techniques.

Let us take an example to understand the relation between a program and its control flow diagram which is
represented by below two figures.
 Fig 4.1 A specimen program

Fig 4.2 Corresponding Flow Chart

4) Data Structure-oriented Design

Computers became even more powerful with the advent o f integrated circuits (ICs) in the early 1970’s. These
could now be used to solve more complex problems. It was soon discovered that 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. However, these techniques are rarely used in the industry today and have been
replaced by the data flow based and the object-oriented techniques.

5) 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 d a t a 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.

DFDs: A crucial program representation for procedural.

Let us take an example of a automated car assembly plant in which there are several processing stations (called
workstations) which are located along side of a conveyor belt (called an assembly line). Each workstation is
specialized to do specific job such as fitting of wheels, fitting the engine, spray painting the car, etc. As the partially
assembled project moves along the assembly line, different workstations execute their respective jobs on the partially
assembled software. Each circle in the DFD model of figure given below represents a workstation (called a process or
bubble). Each workstation consumes certain input items and produces certain output items. As a car under assembly
arrives at a workstation, it fetches the necessary items to be fitted from the corresponding stores (represented by two
parallel horizontal lines), and as soon as the fitting work is complete passes on to the next workstation. It is easy to
understand the DFD model of the car assembly plant shown in figure even without knowing anything regarding
DFDs. A major advantage of the DFDs is their simplicity.

Fig 4.3 DFD of a car assembly plant

6) Object-oriented Design
Data flow-oriented techniques evolved into object-oriented design (OOD) techniques in the late seventies. Object-
oriented design technique is an intuitively appealing 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 entity (also
known as data abstraction). Object-oriented techniques have gained wide spread acceptance because of their
simplicity, the scope for code and design reuse, promise of lower development time and cost, more robust code,
and easier maintenance.
 LECTURE 5
PROCESS MODELS
Exploratory style is also known as the build and fix programming. The issues related to this programming style are
overcome by the software engineering approaches, which emphasizes 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. Several life cycle models have so far been proposed. In this lecture, we confine our attention to only a few
important and commonly used Life Cycle Models.

FEW BASIC CONCEPTS

 Software life cycle

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the
phases through which a software undergoes during its development period. A life cycle model represents all the
activities required to make a software product transit through its life cycle phases. It also captures the order in
which these activities are to be undertaken.

The stage where the customer feels a need for the software and forms rough ideas about the required features is
called as the inception stage. In other words, 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

An SDLC graphically depicts the different phases through which software evolves. It is usually accompanied by a
textual description of the different activities that need to be carried out during each phase. It describes the
different activities that need to be carried out for the software to evolve in its life cycle. An SDLC is represented
graphically by drawing various stages of the life cycle and showing the transitions among the phases.

 Why do we need SDLC?

When a software product is being developed by a team there must be a clear understanding among team members
about when and what to do. Hence, the development team must identify a suitable life cycle model for the
particular project and then adhere to it. Without using of a particular life cycle model the development of a
software product would not be in a systematic and disciplined manner and which might lead to chaos and project
failure.

 Why do we need documentation in a development process?

It is not enough for an organization to just have a well-defined development process, but the development process
needs to be properly documented. A documented process model ensures that every activity in the life cycle is
accurately defined and recorded via documentation. Without documentation, the activities and their ordering are
loosely defined and leads to confusion and misinterpretation to different teams in the organization.

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.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages.
A few important and commonly used life cycle models are as follows:

Classical Waterfall Model

 Iterative Waterfall Model
 Prototyping Model
 Evolutionary Model
 Spiral Model

1) CLASSICAL WATERFALL MODEL

The classical waterfall model is intuitively the most obvious way to develop software. Though the classical
waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used
in actual software development projects. Thus, 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.
So, 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 as shown in figure below.
 Fig 5.1 Classical waterfall model

Phases of the classical waterfall model

 Feasibility study – The objective of feasibility study is to determine whether it would be financially and technically
feasible to develop the product.

 Development of an overall understanding of the problem: At first project managers gains a

rough idea of what is required to be done by visiting the client side. They study different input 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 of the system.
 Formulation of the various possible strategies for solving the problem: After they have an
overall understanding of the problem they analyze the different possible solutions. Then they examine
each of the solutions in terms of what kind of resources are required, what would be the cost of
development incur and what would be the development time for each solution.
 Evaluation of the different solution strategies: Based on this analysis the best solution is
chosen and determine whether the solution is financially and technically feasible or not. They check
whether the customer budget would meet the cost of the product and whether they have sufficient
technical expertise in the area of development.

 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

 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 to clearly understand the customer requirements so that incompleteness and
inconsistencies are removed.

The requirements analysis starts by collecting all relevant data required for the product/software development from the
customer through interviews and discussions. 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 contain several ambiguities, since each user typically
has only a partial and incomplete view of the system. Therefore it is 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 all the requirements properly understood, the requirements
specification activity can start.
During requirements specification activity, 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.
 LECTURE 6

CLASSICAL WATERFALL MODEL(continuation)

 Design: - The aim 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. In technical terms, 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.
 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.
 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.

 Coding and unit testing:-The purpose of the coding phase (sometimes called the implementation phase) of
software development is to translate the software design into source code. 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 tested.
During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves
testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.

 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 in a planned manner. The different
modules making up a software product are almost never integrated in one shot. 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:

 α – testing: It is the system testing performed by the development team.

 β –testing: It is the system testing performed by a friendly set of customers.
 Acceptance testing: It is the system testing performed by the customer himself after the product delivery to
determine whether to accept or reject the delivered product.

System testing is carried out in a organized 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 resources. It
also lists all the test cases and the expected outputs for each test case.

Maintenance: -Maintenance of a typical software product requires much more than the effort necessary 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 ratios. Maintenance involves performing any one
or more of the following three kinds of activities:
  Correcting errors that were not discovered during the product development phase. This is called corrective
maintenance.
 Improving the implementation of the system, and enhancing the functionalities of the system according to the
customer’s requirements. This is called perfective maintenance.
 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. This is called adaptive maintenance.

Advantages of Classical Waterfall Model

 This model is very simple and is easy to understand.

 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well-understood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before- design, design-before-code.
 This model works well for smaller projects and projects where requirements are well understood.

Shortcomings of the classical waterfall model

 No feedback path: In the classical waterfall model evolution of software from one phase to another phase is like
a waterfall. It assumes or overlooks the occurrence of error committed by developers during any phase.
Therefore, it does not incorporate any mechanism for error correction.

 Difficult to accommodate change requests: This model assumes that all the customer requirements can be
completely and correctly defined at the beginning of the project, but in actual scenario customers’ requirements
keep on changing with time. It is difficult to accommodate any change requests after the requirements
specification phase is complete.

 No overlapping of phases: This model recommends that a new phase can start only after the completion of the
previous phase. But in real projects, this can’t be maintained. To increase efficiency and reduce cost, phases may
overlap.

LECTURE 7
ITERATIVE WATERFALL MODEL

To overcome the major shortcomings of the classical waterfall model, a new iterative waterfall model was formed. 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.

Fig 7.1 Iterative waterfall model

Here, we provide feedback paths for error correction as & when detected later in a phase. Though errors are inevitable, but
it is desirable to detect them in the same phase in which they occur and iteration can be done to rectify the error. This can
reduce the effort to correct the bug.

The advantage of this model is that there is a working model of the system at a very early stage of development which
makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take
corrective measures in a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects.
This is because it is hard to break a small software system into further small serviceable increments/modules.

3) PROTOTYPING MODEL

Prototyping is defined as the process of developing a working replication of a product or system that has to be
engineered. The product then is called a prototype. A prototype usually exhibits limited functional capabilities, low
reliability, and inefficient performance compared to the actual software. A prototype is may be 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. A prototype usually turns out to be a very crude version of the actual system and also helps in development
of the actual one.

This model is used when the customers do not know the exact project requirements beforehand. In this model, a
prototype of the end product is first developed, tested and refined as per customer feedback repeatedly till a final
acceptable prototype is achieved which forms the basis for developing the final product .

Fig 7.1 Prototyping waterfall model

Life cycle activities of prototyping model

The prototyping model of software development is graphically shown above, 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 designing
activity is carried out and a prototype (product demo) 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 until
the actual product is achieved.

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. However, 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.

Advantages of the prototyping model

1. This model is the most appropriate for projects that suffer from technical and requirements risks. A constructed
prototype helps overcome these risks.
2. This model is flexible in design.
3. It is easy to detect errors.
4. We can find missing functionality easily.
5. There is scope of refinement; it means new requirements can be easily accommodated.

Disadvantages of the prototyping model

 This model is costly.
 It has poor documentation because of continuously changing customer requirements.
 There may be too much variation in requirements.
 Customers sometimes demand the actual product to be delivered soon after seeing an early prototype.
 LECTURE 8

EVOLUTIONARY MODEL

It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it
undergoes functional improvements and developers keep on adding new functions till the desired system is built. The
principal idea behind the evolutionary life cycle model is conveyed by its name. In the incremental development model,
complete requirements are first developed and the SRS document prepared. In contrast, in the 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. Such evolution is consistent with the pattern of
unpredictable feature discovery and feature changes that take place in new product development.

Fig 8.1 Evolutionary model

Evolutionary model is appropriate for object-oriented development project, since it is easy to partition the software into
stand alone units in terms of the classes. Also, classes are more or less self contained units that can be developed
independently.

Advantages:

 Risk analysis is better.

 It supports changing environment.
 Initial operating time is less.
 Better suited for large mission-critical projects.
 During the life cycle software is produced early which facilitates customer evaluation and feedback.

Disadvantages:
 Management complexity is more.
 Not suitable for smaller projects.
 Can be costly to use.
 Highly skilled resources are required for risk analysis.
 LECTURE 9

RAD model (RAPID APPLICATION DEVELOPMENT)

RAD is a linear sequential software development process model that emphasizes a concise development cycle using an
element based construction approach. If the requirements are well understood and described, and the project scope is a
constraint, the RAD process enables a development team to create a fully functional system within a concise time period.

Various phases of RAD model

1.Business Modelling: The information flow among business functions is defined by answering questions like what data
drives the business process, what data is generated, who generates it, where does the information go, who process it and
so on.

2. Data Modelling: The data collected from business modeling is refined into a set of data objects (entities) that are
needed to support the business. The attributes (character of each entity) are identified, and the relation between these data
objects (entities) is defined.

3. Process Modeling: The information object defined in the data modeling phase are transformed to achieve the data flow
necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL
techniques.

5. Testing & Turnover: Many of the programming components have already been tested since RAD emphasis reuse.
This reduces the overall testing time. But the new part must be tested, and all interfaces must be fully exercised.

Fig 9.1 RAD model

The major goals of the RAD model are as follows:
 To decrease the time taken and the cost incurred to develop software systems.
 To limit the costs of accommodating change requests.
 T o reduce the communication gap between the customer and the developers.

Advantage of RAD Model

o This model is flexible for change.

o In this model, changes are adoptable.
o Each phase in RAD brings highest priority functionality to the customer.
o It reduced development time.
o It increases the reusability of features.

Disadvantage of RAD Model

o It required highly skilled designers.

o All application is not compatible with RAD.
o For smaller projects, we cannot use the RAD model.
o On the high technical risk, it's not suitable.
o Required user involvement.


 LECTURE 10

SPIRAL MODEL

Spiral model is one of the most important Software Development Life Cycle(SDLC) models, which provides support
or Risk Handling. In its diagrammatic representation given below, it looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to project. Each loop of the spiral is called
a Phase of the software development process. The exact number of phases needed to develop the product may vary
by the project manager depending upon the project type and risks. As the project manager dynamically determines the
number of phases, so the project manager has an important role to develop a product using the spiral model. The
Radius of the spiral at any point represents the expenses (cost) of the project so far, and the angular dimension
represents the progress made so far in the current phase.

Fig 10.1 SPIRAL MODEL

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.

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.

Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

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 :

1. Software is produced early in the software life cycle.
2. Risk handling is one of important advantages of the Spiral model; it is best development model to follow due to
the risk analysis and risk handling at every phase.
3. Flexibility in requirements. In this model, we can easily change requirements at later phases and can be
incorporated accurately. Also, additional Functionality can be added at a later date.
4. It is good for large and complex projects.

Disdvantages of Spiral Model

1. It is not suitable for small projects as it is expensive.

2. It is much more complex than other SDLC models. Process is complex.
3. Too much dependable on Risk Analysis and requires highly specific expertise.
4. Difficulty in time management. As the number of phases is unknown at the start of the project, so time estimation
is very difficult.
5. Spiral may go on indefinitely

Spiral model as a meta model

As compared to the previously discussed models, the spiral model can be viewed as a meta model, since it subsumes all
the discussed models. 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. These
prototypes are 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—the iterations along
the spiral can be considered as evolutionary levels through which the complete system is built. This enables the developer
to understand and resolve the risks at each evolutionary level (i.e. iteration along the spiral).
 LECTURE 11

AGILE DEVELOPMENT MODELS

Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to
best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames) to deliver specific
features for a release.

The agile software development model was proposed in the mid-1990s to overcome the serious shortcomings of the
waterfall model of development identified above. The agile model was primarily designed to help a project to adapt to
change requests quickly. Thus, a major aim of the agile models is to facilitate quick project completion. But, how is
agility achieved in these models? Agility is achieved by fitting the process to the project, i.e. removing activities that may
not be necessary for a specific project. Also, anything that that wastes time and effort is avoided. Please note that agile
model is being used as an umbrella term to refer to a group of development processes. These processes share certain
common characteristics, but do have certain subtle differences among themselves

Fig 11.1 Agile model

The most popular Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme
Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems
Development Method (DSDM) (1995). These are now collectively referred to as Agile Methodologies, after the Agile
Manifesto was published in 2001.

Advantages of the Agile Model are as follows −

 Is a very realistic approach to software development.
 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
Disadvantages of the Agile Model are as follows −
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and extensibility.
 An overall plan, an agile leader and agile PM practice is a must without which it will not work.
 Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the
deadlines.

SCRUM

In the scrum model, a project is divided into small parts of work that can be incrementally developed and delivered over
time boxes that are called sprints. The software therefore gets developed over a series of manageable chunks. Each sprint
typically takes only a couple of weeks to complete. At the end of each sprint, stakeholders and team members meet to
assess the progress made and the stakeholders suggest to the development team any changes needed to features that have
already been developed and any overall improvements that they might feel necessary. In the scrum model, the team
members assume three fundamental roles— software owner, scrum master, and team member. The software owner is
responsible for communicating the customers vision of the software to the development team. The scrum master acts as a
liaison between the software owner and the team, thereby facilitating the development work.

Extreme Programming
Basic principles of Extreme programming: XP is based on the frequent iteration through which the developers
implement User Stories. User stories are simple and informal statements of the customer about the functionalities
needed. A User story is a conventional description by the user about a feature of the required system. It does not
mention finer details such as the different scenarios that can occur. On the basis of User stories, the project team
proposes Metaphors. Metaphors are a common vision of how the system would work. The development team may
decide to build a Spike for some feature. A Spike is a very simple program that is constructed to explore the suitability
of a solution being proposed. It can be considered similar to a prototype.

Basic activities that are followed during software development by using XP model are given below:
 Coding: The concept of coding which is used in XP model is slightly different from traditional coding. Here,
coding activity includes drawing diagrams (modeling) that will be transformed into code, scripting a web-based
system and choosing among several alternative solutions.
 Testing: XP model gives high importance on testing and considers it be the primary factor to develop a fault-free
software.
 Listening: The developer needs to carefully listen to the customers if they have to develop a good quality
software. Sometimes programmers may not have the depth knowledge of the system to be developed. So, it is
 desirable for the programmers to understand properly the functionality of the system and they have to listen to
the customers.
 Designing: Without a proper design, a system implementation becomes too complex and very difficult to
understand the solution, thus it makes maintenance expensive. A good design results elimination of complex
dependencies within a system. So, effective use of suitable design is emphasized.
 Feedback: One of the most important aspects of the XP model is to gain feedback to understand the exact
customer needs. Frequent contact with the customer makes the development effective.
 Simplicity: The main principle of the XP model is to develop a simple system that will work efficiently in
present time, rather than trying to build something that would take time and it may never be used. It focuses on
some specific features that are immediately needed, rather than engaging time and effort on speculations of
future requirements.
 Question Answer based on Module 1

Q1) What is Software Engineering?

A) Software engineering is defined as the function of the systematic, disciplined, quantified approach to the development,
operations, and maintenance of software.

Q2) What are the characteristics of the software?

A) Characteristics of the software are:

o Software is engineered, not manufactured.

o Software does not wear out.
o Most software is custom-built rather than being assembled from components.

Q3) What are the challenges in software?

A) The challenges in the software are:

o Copying with legacy systems.

o Heterogeneity challenge.
o Delivery times challenge.

Q4) What is SDLC?

A) SDLC stands for Software Development Life Cycle. It defines the step by step approach for the development of
software. SDLC involves the following phases i.e. Requirement Gathering, System Analysis, Design, Coding, Testing,
Maintenance, and Documentation.

Q5) What are the various models available in SDLC?

A) There are several models available in SDLC for efficiently carrying out software development. Some of the models
include the Waterfall model, V-Model, Agile model, etc.

Q6) What are the responsibilities of a Software Project Manager?

A) A Software Project Manager is responsible for driving the project towards successful completion. It is the
responsibility of the Software Project Manager to make sure the entire team follows a systematic and well-defined
approach towards the development of software.

Q7) What are the various phases of SDLC?

A)The following are the most common phases of SDLC.

 Requirement Analysis
 Design
 Coding
  Testing
 Maintenance

Q8) What is a Feasibility Study?

A)A feasibility study is conducted on a software product to assess how practical and beneficial is the development of the
software product to the organization. Software is analyzed thoroughly to understand the economic and technical aspects of
a software product to be developed.

Q9) What do you mean by Software Scope?

A)Software scope is the list of features provided by the developed software. Based on the scope of the software,
estimations such as time allocation, budget and resource allocation can be done.

Q10) What is SRS?

A)SRS stands for Software Requirement Specification (SRS) document. It is a document to capture all the functional and
non-functional requirements of a product. Not all SDLC models need to follow SRS documents, some models capture
requirements in the form of user stories, whereas some models in the form of excel sheets, etc.

Q11)What is the limitation of RAD Model?

A)Limitation of RAD Model are:

o It requires a sufficient number of Human Resources to create enough number of teams.
o Developers and Users are not committed,the system fails.
o It is not Properly Modularized building component may be Problematic.
o It is not applicable when there is more possibility for Technical Risk.

Q12) What are the disadvantages of classic life cycle model?

A)Disadvantages of the classic life cycle model are:

o Real projects rarely follow the sequential flow. Iteration always occurs and creates a problem.
o Challenging for the customer to state all requirements.
o The working version of the program is not available. So the customer must have patience

Q13)Name the Evolutionary process Models.

A)Evolutionary powers models are:

o Incremental model
o Spiral model
o WIN-WIN spiral model
o Concurrent Development

Q14)What are the prototyping methods in software process?

A)The prototyping methods in the software process are:

 o Evolutionary prototyping: In this method of system development, the initial prototype is arranged, and it is then
precise through the number of phases to the final stage.
o Throw-away prototyping: Using this method, a rough practical implementation of the system is produced. The
requirement issues can be identified from this implementation. It is then rejected. System is then developed using
some various engineering paradigm.

Q15)What is DFD?

A) Data Flow Diagram depicts the data flow and the transforms which are applied to the data as it moves from input to
output.
 ASSIGNMENT QUESTIONS ON MODULE 1

1. What is software engineering?

2. What are the characteristics of Software?

3. What are the various phases of SDLC?

4. What is SRS? Software Requirement Specification (SRS) Format

5.What is the Agile software development model?

6. Which model is used to check software reliability?

7.When you know programming, what is the need to learn software engineering concepts?

8. Mention some project management tools.

9. Which are the major phases in the waterfall model of software development? Which phase consumes the maximum
effort for developing typical software?

10. Consider the following assertion: “The classical waterfall model is an Idealistic model”. Based on this assertion,
answer the following:
(a) Justify why the above assertion is true.
(b) Even if the classical waterfall model is an idealistic model, is there any practical use of this model at all? Explain your
answer.

11. Draw a schematic diagram to represent the iterative waterfall model of software development. On your diagram
represent the following:
(a) The phase entry and exit criteria for each phase.
(b) The deliverables that need to be produced at the end of each phase.

12. Briefly explain the important differences and similarities between the incremental and evolutionary models of SDLCs.

13. What do you understand by “build-and-fix” style of software development? Diagrammatically depict the typical
activities in this style of development and their ordering. Identify at least four major problems that would arise, if a large
professional software development project is undertaken using a “build-and-fix” style of software development.

14. Why is the classical waterfall model called an idealistic development model? Does this model of development has any
practical use at all?

15. Give an example of a software development project for which the iterative waterfall model is not suitable. Briefly
justify your answer.