INTRODUCTION TO SOFTWARE ENGINEERING

The term software engineering is composed of two words, software and engineering.
Software is more than just a program code.
A program is an executable code, which serves some computational purpose.
Software is considered to be a collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is called software product. Engineering on
the other hand, is all about developing products, using well-defined, scientific principles and methods. So, we
can define software engineering as an engineering branch associated with the development of software
product using well-defined scientific principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product. IEEE defines software engineering as: The application
of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of
software.
Without using software engineering principles, it would be difficult to develop large programs. In industry it is
usually needed to develop large programs to accommodate multiple functions. A problem with developing
such large commercial programs is that the complexity and difficulty levels of the programs increase
exponentially with their sizes. Software engineering helps to reduce this programming complexity.
Software engineering principles use two important techniques to reduce problem complexity:
abstraction and decomposition.
The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other
words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for
certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler
problem is solved, then the omitted details can be taken into consideration to solve the next lower level
abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem.
The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is
divided into several smaller problems and then the smaller problems are solved one by one. However, in this
technique any random decomposition of a problem into smaller parts will not help. The problem has to be
decomposed such that each component of the decomposed problem can be solved independently and then
the solution of the different components can be combined to get the full solution.
A good decomposition of a problem should minimize interactions among various components. If the different
subcomponents are interrelated, then the different components cannot be solved separately and the desired
reduction in complexity will not be realized.

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements and
environment on which the software is working.
Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become
large engineering has to step to give it a scientific process.
Scalability- If the software process were not based on scientific and engineering concepts, it would be easier
to re-create new software than to scale an existing one.
Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of computer
and electronic hardware. But the cost of software remains high if proper process is not adapted.
Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment
in which the user works. If the nature of software is always changing, new enhancements need to be done in
the existing one. This is where software engineering plays a good role.
Quality Management- Better process of software development provides better and quality software product.
CHARACTERISTICS OF GOOD SOFTWARE
A software product can be judged by what it offers and how well it can be used. This software must satisfy on
the following grounds:

 Operational
 Transitional
 Maintenance
Well-engineered and crafted software is expected to have the following characteristics:
Operational
This tells us how well software works in operations. It can be measured on: Budget Usability Efficiency
Correctness Functionality Dependability Security Safety
Transitional
This aspect is important when the software is moved from one platform to another: Portability Interoperability
Reusability Adaptability .
Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the everchanging
environment: Modularity Maintainability Flexibility Scalability.
In short, Software engineering is a branch of computer science, which uses well-defined engineering concepts
required to produce efficient, durable, scalable, in-budget and on-time software products.

SOFTWARE DEVELOPMENT LIFE CYCLE

LIFE CYCLE MODEL : A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. 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. In other words, a life cycle model
maps the different activities performed on a software product from its inception to retirement.
THE NEED FOR A SOFTWARE LIFE CYCLE MODEL
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. 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. Otherwise it would lead to chaos and
project failure. This problem can be illustrated by using an example. Suppose a software development problem
is divided into several parts and the parts are assigned to the team members. From then on, suppose the team
members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is
possible that one member might start writing the code for his part, another might decide to prepare the test
documents first, and some other engineer might begin with the design phase of the parts assigned to him. This
would be one of the perfect recipes for project failure. A software life cycle model defines entry and exit
criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without
software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life
cycle models it becomes difficult for software project managers to monitor the progress of the project.

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.
 Feasibility study - The main aim of feasibility study is to determine whether it would
be financially and technically feasible to develop the product.
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 activity is begun by collecting all relevant data regarding the product to be
developed from the users of the product and 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 contradictions and 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 this 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.
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. In technical terms, during the
design phase the software architecture is derived from the SRS document.
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
2. ITERATIVE WATERFALL MODEL
To overcome the major shortcomings of the classical waterfall model, we come up with the 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. If so, 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
A prototyping model can be used when technical solutions are unclear to the development team.
A developed prototype can help engineers to critically examine the technical issues associated
with the product development

A prototype is a toy implementation of the system. A prototype usually exhibits limited

functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve using
inefficient, inaccurate, or dummy functions
A prototype of the actual product is preferred in situations such as:
• User requirements are not complete
• Technical issues are not clear

4. 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 & we keep on adding new functions till the desired
system is built.
Applications:
Large projects where you can easily find modules for incremental implementation. Often used
when the customer wants to start using the core features rather than waiting for the full software.

Advantages:
User gets a chance to experiment partially developed system
Reduce the error because the core modules get tested thoroughly.
Disadvantages:
It is difficult to divide the problem into several versions that would be acceptable to the customer
which can be incrementally implemented and delivered.
 5. SPIRAL MODEL
The Spiral model of software development is shown in Fig. 5. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number of
loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software
process. For example, the innermost loop might be concerned with feasibility study, the
next loop with requirements specification, the next one with design, and so on. Each phase
in this model is split into four sectors (or quadrants) as shown in fig. 4.1. The following
activities are carried out during each phase of a spiral model.

Fig 5: 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.

Parts of a SRS document

• The important parts of SRS document are:
Functional requirements of the system
Non-functional requirements of the system, and
-Goals of implementation

Functional requirements:-
The functional requirements part discusses the functionalities required from the system. The system is
considered to perform a set of high-level functions {fi}. The functional view of the system is shown in Fig. 6.
Each function fi of the system can be considered as a transformation of a set of input data (ii) to the
corresponding set of output data (oi). The user can get some meaningful piece of work done using a high-level
function.
Non-functional requirements:-
Non-functional requirements deal with the characteristics of the system which cannot be
expressed as functions - such as the maintainability of the system, portability of the system, usability of the
system, etc.

Example:
Consider Library Membership Automation Software (LMS) where it should support
the following three options:
New member
Renewal
Cancel membership New member option

Cancel membership option-

Decision: If the 'cancel membership' option is selected, then the software asks for member's name and his
membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the member is printed and
finally the membership record is deleted from the database.
The following tree (Fig. 7) shows the graphical representation of the above example.
 Fig 7: Decision Tree of LMS

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.

Three types of maintenance carried out in SDLC. Corrective maintenance

1. Corrective
2. Adaptive maintenance
3. Perfective maintenance
Corrective: Corrective maintenance of a software product is necessary to rectify the bugs observed while the
system is in use.
Adaptive: A software product might need maintenance when the customers need the product to run on new
platforms, on new operating systems, or when they need the product to interface with new hardware or
software.
Perfective: A software product needs maintenance to support the new features that users want it to support,
to change different functionalities of the system according to customer demands, or to enhance the
performance of the system.
DECISION TABLE
A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows
of the table specify the variables or conditions to be evaluated

Modularization
Modularization is a technique to divide a software system into multiple discrete and independent modules,
which are expected to be capable of carrying out task(s) independently. These modules may work as basic
constructs for the entire software.
Advantage of modularization:
i. Smaller component are easier to maintain
ii. Programs can be divided based on functional aspect
iii. Desired level of abstraction can be brought in the program

Concurrency
concurrency provides capability to the software to execute more than one part of code in parallel to each other.