1

What is Software Engineering ?

Software Engineering is a systematic approach to the design, development, operation, and

maintenance of a software system.

Objectives of Software Engineering:

1. Maintainability:
It should be feasible for the software to evolve to meet changing requirements.
2. Correctness: –
A software product is correct, if the different requirements as specified in the SRS
document have been correctly implemented.
3. Reusability: –
A software product has good reusability, if the different modules of the product can
easily be reused to develop new products.
4. Testability: –
Here software facilitates both the establishment of test criteria and the evaluation of the
software with respect to those criteria.
5. Reliability: –
It is an attribute of software quality. The extent to which a program can be expected to
perform its desired function, over an arbitrary time period.
6. Portability: –
In this case, software can be transferred from one computer system or environment to
another.
7. Adaptability: –
In this case, software allows differing system constraints and user needs to be satisfied by
making changes to the software.

Program vs Software Product:

1. Program is a set of instruction related each other where as Software Product is a

collection of program designed for specific task.
2. Programs are usually small in size where as Software Products are usually large in size.
3. Programs are developed by individuals that means single user where as Software Product
are developed by large no of users.
4. In program, there is no documentation or lack in proper documentation.
In Software Product, Proper documentation and well documented and user manual
prepared.
5. Development of program is Unplanned, not Systematic etc but Development of Software
Product is well Systematic, organized, planned approach.
 2

6. Programs provide Limited functionality and less features where as Software Products
provides more functionality as they are big in size (lines of codes) more options and
features.

Software Engineering | Classical Waterfall

Model

Classical waterfall model is the basic software development life cycle model.

Classical waterfall model divides the life cycle into a set of phases. This model considers that one phase
can be started after completion of the previous phase. That is the output of one phase will be the input
to the next phase. Thus the development process can be considered as a sequential flow in the
waterfall. Here the phases do not overlap with each other.

Let us now learn about each of these phases in brief details:

1. Feasibility Study: The main goal of this phase is to determine whether it would be financially and
technically feasible to develop the software.
The feasibility study involves understanding the problem and then determine the various possible
strategies to solve the problem.

2. Requirements analysis and specification: The aim of the requirement analysis and specification phase
is to understand the exact requirements of the customer and document them properly.

This phase consists of two different activities

 Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been omitted) and
inconsistencies (inconsistent requirement is one in which some part of the requirement
contradicts with some other part).
 Requirement specification: These analyzed requirements are documented in a software
requirement specification (SRS) document. SRS document serves as a contract between
 3

development team and customers. Any future dispute between the customers and the
developers can be settled by examining the SRS document.

3.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.

4.Coding and Unit testing: In coding phase software design is translated into source code using
any suitable programming language. Thus each designed module is coded. The aim of the unit
testing phase is to check whether each module is working properly or not.

5.Integration and System testing: 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 and
system testing is carried out on this.

System testing consists three different kinds of testing activities as described below:

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

 β-testing: β-testing is the system testing performed by a friendly set of customers.
 Acceptance testing: After the software has been delivered, the customer performed the
acceptance testing to determine whether to accept the delivered software or to reject it.

6. Maintainence: Maintenance is the most important phase of a software life cycle. The effort
spent on maintenance is the 60% of the total effort spent to develop a full software. There are
basically three types of maintenance :
 Corrective Maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as work on a new computer platform or
with a new operating system.

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 undestood milestones.
 4

 Process, actions and results are very well documented.

 This model works well for smaller projects.

Drawbacks of Classical Waterfall Model:

No feedback path: In classical waterfall model evolution of a software from one phase to another phase
is like a waterfall. It assumes that no error is ever committed by developers during any phases.
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 actually 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 new phase can start only after the completion
of the previous phase. But in real projects, this can’t be maintained. To increase the efficiency and
reduce the cost, phases may overlap requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.

Software Engineering | Iterative Waterfall

Model
In a practical software development project, the classical waterfall model is hard to use. So, Iterative
waterfall model can be thought of as incorporating the necessary changes to the classical waterfall
model to make it usable in practical software development projects. It is almost same as the classical
waterfall model except some changes are made to increase the efficiency of the software development.

The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.

Feedback paths introduced by the iterative waterfall model are shown in the figure below.

When errors are detected at some later phase, these feedback paths allow correcting errors committed
by programmers during some phase. The feedback paths allow the phase to be reworked in which errors
are committed and these changes are reflected in the later phases. But, there is no feedback path to the
stage – feasibility study, because once a project has been taken, does not give up the project easily.
 5

It is good to detect errors in the same phase in which they are committed. It reduces the effort and time
required to correct the errors.

Advantages of Iterative Waterfall Model

 Feedback Path: In the classical waterfall model, there are no feedback paths, so there is
no mechanism for error correction. But in iterative waterfall model feedback path from
one phase to its preceding phase allows correcting the errors that are committed and these
changes are reflected in the later phases.
 Simple: Iterative waterfall model is very simple to understand and use. That’s why it is
one of the most widely used software development models.

Drawbacks of Iterative Waterfall Model

 Difficult to incorporate change requests: The major drawback of the iterative waterfall
model is that all the requirements must be clearly stated before starting of the
development phase. Customer may change requirements after some time but the iterative
waterfall model does not leave any scope to incorporate change requests that are made
after development phase starts.
 Incremental delivery not supported: In the iterative waterfall model, the full software
is completely developed and tested before delivery to the customer. There is no scope for
any intermediate delivery. So, customers have to wait long for getting the software.
 Overlapping of phases not supported: Iterative waterfall model assumes that one phase
can start after completion of the previous phase, But in real projects, phases may overlap
to reduce the effort and time needed to complete the project.
 Risk handling not supported: Projects may suffer from various types of risks. But,
Iterative waterfall model has no mechanism for risk handling.
 Limited customer interactions: Customer interaction occurs at the start of the project at
the time of requirement gathering and at project completion at the time of software
delivery. These fewer interactions with the customers may lead to many problems as the
finally developed software may differ from the customers’ actual requirements.