SOFTWARE

ENGINEERING
FOR BSE 1 2020 CORONA
Aaron atuhe
COURSE CODE:
 LECTURE 1: INTRODUCTION TO
SOFTWARE ENGINEERING

• The term software engineering is composed of two words, software and

engineering

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

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

• decomposition. In this technique, a complex problem is divided into several smaller

problems and then the smaller problems are solved one by one
 THE NEED FOR 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.
 CHARACTERESTICS 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:

1. Operational
• This tells us how well software works in operations. It can be measured on:
Usability , Efficiency ,Functionality,Dependability , Security e tc
2. Transitional

• This aspect is important when the software is moved from one platform to another

(Portability, Interoperability, Reusability,Adaptability )

3. Maintenance

• This aspect briefs about how well a software has the capabilities to maintain itself in the

ever-changing environment: (Flexibility , Scalability )

 SOFTWARE DEVELOPMENT LIFE CYCLE
• LIFE CYCLE MODEL :

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

 THE NEED FOR A SOFTWARE LIFE CYCLE
MODEL
• Without using of a particular life cycle model the development of a software product would
not be in a systematic and disciplined manner .
• Otherwise it would lead to chaos and 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

1. CLASSICAL WATERFALL MODEL

• It seems 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

• The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed

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

• 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
• Integration and system testing: -Integration of different modules is undertaken once they
have been coded and unit tested.
• 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.
• Finally, when all the modules have been successfully integrated and tested, system testing is
carried out.

• α – 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
 MAINTENANCE:

• Maintenance involves performing any one or more of the following three kinds of activities:

• corrective maintenance: Correcting errors that were not discovered during the product development
phase.

• perfective maintenance : Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s requirements.

• adaptive maintenance :adapting(porting) the software to work in a new environment. For example,
adapting(porting)may be required to get the software to work on a new computer platform or with a
new operating system.
 SHORTCOMINGS OF THE CLASSICAL
WATERFALL MODEL

• The classical waterfall model is an idealistic one since it assumes that no development error

is ever committed by the engineers during any of the life cycle phases.

• However, in practical development environments, the engineers do commit a large number

of errors in almost every phase of the life cycle.

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

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

• might involve using inefficient, inaccurate, or dummy functions

 NEED FOR A PROTOTYPE IN SOFTWARE
DEVELOPMENT

• An important purpose is to illustrate the input data formats, messages, reports, and the
interactive dialogues to the customer. This is a valuable mechanism for gaining better
understanding of the customer’s needs:

•  how the screens might look like

•  how the user interface would behave

•  how the system would produce outputs

 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.
•  Also used in object oriented software development because the system can be easily
portioned into units in terms of objects.
• 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 & delivered.

 5. SPIRAL MODEL

• 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)
 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.
 CIRCUMSTANCES TO USE SPIRAL MODEL

• The spiral model is called a meta model since it encompasses all other life cycle models.

• Risk handling is inherently built into this model. The spiral model is suitable for

development of technically challenging software products that are prone to several kinds of

risks.
 COMPARISON OF DIFFERENT LIFE-
CYCLE MODELS

• The classical waterfall model can be considered as the basic model and all other life cycle

models as embellishments of this model.

• However, the classical waterfall model cannot be used in practical development projects,

since this model supports no mechanism to handle the errors committed during any of the

phases.
• This problem is overcome in the iterative waterfall model. The iterative waterfall model is

probably the most widely used software development model evolved so far.

• This model is simple to understand and use. However this model is suitable only for well-

understood problems; it is not suitable for very large projects and for projects that are subject

to many risks.
• The prototyping model is suitable for projects for which either the user requirements or the

underlying technical aspects are not well understood. This model is especially popular for

development of the user-interface part of the projects.

• The evolutionary approach is suitable for large problems which can be decomposed into a

set of modules for incremental development and delivery.

• This model is also widely used for object-oriented development projects. Of course, this

model can only be used if the incremental delivery of the system is acceptable to the

customer
• The spiral model is called a meta model since it encompasses all other life cycle models.

Risk handling is inherently built into this model. The spiral model is suitable for

development of technically challenging software products that are prone to several kinds of

risks.

• However, this model is much more complex than the other models – this is probably a factor

deterring its use in ordinary projects.