SOFTWARE

ENGINEERING
 Preferred Text Books acc. to Syllabus

Text Books:
1. Pankaj Jalote, ―A Concise Introduction to Software Engineering‖, Springer
International Edition.
2. Roger S. Pressman, ―Software Engineering‖, 7th edition, TMH.

Reference books:
1. K.K Aggarwal and Yogesh Singh, ―Software Engineering‖, 3rd Edition, New Age
Publications
2. Software Engineering, Ian Sommerville, 8th edition, Pearson education.
3. Software Engineering : A Primer, Waman S Jawadekar, Tata McGraw-Hill, 2008

2
 Introduction and
Unit-I
Software Life
Cycle Models
 SYLLABUS
• INTRODUCTION
Evolving role of software – Software Engineering – Software
characteristics, The Changing Nature of software, Software
Myths.

• SOFTWARE LIFE CYCLE MODELS

Basic Concepts, process models- waterfall model – Prototyping
model – Iterative Development Model – RUP model- Extreme
programming & Agile Development Models.
4
 Evolving role of software
• s/w as a product
• s/w as a vehicle

5
 Evolving role of software

 Software takes on a dual role.

As Product
&
As Vehicle for delivering a product

6
7
 Software as a product
Information transformer
• Producing, managing, acquiring, modifying ,displaying or
transmitting information.
• Examples: MS-Office

8
 Software as a Vehicle

It gives the platform to run other software .

• The basis for the control of the computer(OS)
• The communication of information(networks)
• The creation & control of other programs(s/w tools &
environments) Linkers,debuggers.

9
 SOFTWARE ENGINEERING

• SOFTWARE
set of instructions or programs instructing a computer to do specific tasks.
Software is a set of
• Instructions that when executed provide desired function and
performance,
• Data Structures that enable the programs to adequately manipulate
information,
• Documents that describe the operation and use of the programs.
• ENGINEERING
Engineering is the application of mathematics, science, economics, social and
practical knowledge to invent, innovate, design, build, maintain and research.
11
12
 Quality
 It act as a Bedrock
 Functionality changes
changes in the functionality of a software is adaptable
 Maintainability of software
Software should run for long period of time
 Provide security
if any unauthorised persons use software we should get a notification
 Usability
The product that make other than client (the original owner) of the product the
users will be using it more.

13
 Process
• Foundation layer
• It keeps all layers together
• Covers all activities ,actions, tasks in order to develop a
software

14
 Methods
• Provides technical questions “how to” for building a software
how to built a module,how to write a code
• Technical way to implement software
which coding lang is choose inorder to develop a software

15
 Tools
• Provide automated or semi automated support for process and
methods

16
Software characteristics

18
 Introduction and
Unit-I
Software Life
Cycle Models
 Characteristics of software

1. Software is developed or engineered, it is not

manufactured
Here we can’t construct with raw material, it is
logically developed.
– Hardware is manufactured, but software is developed.
2. Software doesn't "wear out"
– Figure represents failure rate as a function of time for hardware.
– The relationship is often called the "bathtub curve".
• These defects can be corrected and the failure rate drops to
a steady-state level (ideally, quite low) for some period of
time.
• As time passes, however, the failure rate rises again as
hardware components suffer from the cumulative effects of
dust, vibration, abuse, temperature extremes, and many
other environmental maladies, which means that the
hardware begins to wear out.
• the failure rate curve for software should take the form of
the “idealized curve”
• Undiscovered defects will cause high failure rates early in
the life of a program.
• However, these are corrected (ideally, without introducing
other errors) and the curve flattens as shown.
Every software failure indicates an error in design or in the process through which
design was translated into machine executable code.
 3.Custom built
• Based on Customer needs we can develop software .

25
Changing nature of software
• The nature of software has changed a lot over these years.
• Its nature mainly depends on the applications:
– System software
– Application software
– Engineering/scientific software
– Embedded software
– Product-line software
– Web applications
– Artificial Intelligence software
– Ubiquitous computing
– Outsourcing
– Open source
• System Software
– System Software is a collection of programs written to provide
service to other programs.
– It needs heavy interaction with computer hardware.
– Examples: Compilers, Editors, File Management Utilities, other
System Applications Drivers and Networking Software.
• Application Software
– Application Software consists of standalone programs that are used
to solve specific business needs.
– It is used to process technical data/technical decisions and control
business functions in real time
– Examples:Google crome,firefox,word and mobile apps like
whatsup,telegram etc.,
• Engineering/Scientific Software
– It satisfies the needs of a scientific and engineering users.
– It is used to create interactive applications to take on real time.
– Examples: Computer Aided Design(CAD/CAM),Interactive
Applications in Educational Field
• Embedded Software
– Software that resides within a product or system is called as
Embedded Software.
– Examples: Keypad control for a Microwave Oven
• Product-line Software
– This type of software provides specific capability for use by many
different customers.
– The focus will be on limited & esoteric(secret) marketplace
– Examples: Word Processing, Spreadsheets, Computer Graphics,
Database Management, Multimedia & Entertainment and Business
Financial Applications.
• Web Applications
The applications we are accessed using internet.
– Web Application Software has grown relevant as E-Commerce
applications grow in importance
– They provide stand alone features, computing functions & content to
end-user.
• Artificial Intelligence Software
– This type of software uses Non-Numerical Algorithms to solve
complex problems.
– Examples: Robotics, Expert Systems, Pattern Recognition(image and
voice), Artificial Neural Networks, Theorem Proving, Game Playing.
• Open Source
– Open Source Software refers to the software whose source code is
public to everyone to develop, test or improve.
– It benefits both programmers and non-programmers.
– It proves to be beneficial to developers, especially those in
academics.
– Examples: Linux Operating System, Apache Web Server Application,
LibreOffice Application, GNU Image Manipulation Application
Software myths
• Software myths propagate misinformation and confusion.
• Today, most knowledgeable professionals recognize myths for
what they are— misleading attitudes that have caused serious
problems for managers and technical people alike
– Management myths
– Customer myths
– Practitioner's myths
 Management myths
• Managers with software responsibility are often under pressure to
maintain budgets, keep schedules from slipping, and improve quality.
– Myth1: We already have a book that's full of standards and procedures for
building software, won't that provide my people with everything they need to
know?
– Reality: The book of standards may very well exist,
• but is it used?
• Does it reflect modern software engineering practice?
• Is it complete?
• Is it streamlined to improve time to delivery while still maintaining a focus on quality?
• In many cases, the answer to all of these questions is "no."
• Myth2: If we get behind schedule, we can add more
programmers and catch up.
• Reality: If software is late, adding more people will merely
make the problem worse. This is because the people already
working on the project need to educate the newcomers. So,
this does not immediately reduce the work.
• Myth3: If I decide to outsources the software project to a third
party, I can just relax and let that firm build it.
• Reality: If an organization does not understand how to manage
and control software projects internally, it will invariably
struggle when it outsources software projects.
 Customer myths
• Myths lead to false expectations (by the customer) and
ultimately, dissatisfaction with the developer.
• Myth1: A general statement of objectives is sufficient to begin
writing programs. we can fill in the details later.
• Reality : A formal and detailed description of
• the information domain
• function
• behavior
• performance
• interfaces
• design constraints
• validation criteria is essential.
• Myth2: Project requirements continually change, but change
can be easily accommodated because software is flexible.
• Reality:
 It is true that software requirements change, but the impact of
change varies with the time at which it is introduced
 It is true that software requirements change, but the impact of
change varies with the time at which it is introduced. If change is
requested in design, then it costs 5 times more as if it is done in
analysis. If it is requested in coding, then it costs 10 more, in testing it
is 50 times more and if it is requested after delivery, then its cost
increases enormously.
 Practitioner's myths

• Myth1: Once we write the program and get it to work, our job
is done.
• Reality:
Industry data indicate that between 60 and 80 percent of all
effort expended on software will be expended after it is
delivered to the customer for the first time.
• Myth2: Until I get the program "running" I have no way of assessing
its quality.
• Reality: One of the most effective software quality assurance
mechanisms is formal technical review. Software reviews can
effectively detect the problems in requirements documents, design
documents, test plans, and code.
• Myth3: The only deliverable work product for a successful project is
the working program.
• Reality: A working program is only one part of a software delivery.
Apart from this several other documents such as analysis, design
and testing documents, user manuals etc. may also be created
during software development.
 Software Life Cycle model

• A software life cycle model is a descriptive and diagrammatic representation of the

software life cycle.

• The software engineering approaches emphasize software development through a

well-defined and ordered set of activities. If these activities are graphically
modeled as well as textually described then it is called as Software Life cycle
Model.

• Software Life cycle Model is also called as Software Development Life cycle Model
or Software Development Process Model.

• The life cycle of a software represents the series of identifiable stages through
which it evolves during its life time.
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.
• A software life cycle model defines entry and exit
criteria for every phase.
 Software Life Cycle models

• Classical waterfall model

• Iterative waterfall model
• Prototyping model
• Agile Development model
• V-model
• Spiral Model
• Incremental Development Model
• RUP process model
 Classical waterfall model

• The waterfall model is a classical development

process model proposed by Winston Walker Royce
in 1970.
• The simplest process model is the waterfall model,
which states that the phases are linear order.
 Water fall model contd…,
• It follows-------
• Linear ordering of activities follow some consequences
--Certification Mechanism: To know the end of the phase &
beginning of the next phase
--Verification & Validation: checks whether
The o/p is consistent with its i/p &
The o/p is consistent with overall system
 Classical Waterfall Model cont…..
• Classical waterfall model divides life cycle into
phases:
– feasibility study
– requirements analysis and specification
– design
– coding and unit testing
– integration and system testing
– maintenance
Classical Waterfall Model Diagram

Feasibility Study

Req. Analysis and

specification
Design
Coding and Unit Testing

Integration and System Testing

Maintenance
 Feasibility Study
• Main aim of feasibility study is to determine whether
it would be financially and technically feasible to develop the software.
• First roughly understand what the customer wants:
– different data which would be input to the system,
– processing needed on these data,
– output data to be produced by the system,
– various constraints on the behaviour of the system.
 Feasibility Study
• Development of an overall understanding of the
problem.
• Formulation of various possible strategies for
solving the problem different solution strategies.
• Evolution of different solution strategies in terms
of:
• resources required,
• cost of development, and
• development time.
Requirements Analysis and Specification
• This phase is to
– understand the exact requirements of the
customer
– document them properly.
• Consists of two distinct activities:
– requirements gathering and analysis
– requirements specification
 Requirements Gathering and Analysis

• Collect all related data from the customer:

– analyze the collected data to clearly understand
what the customer wants,
– find out any inconsistencies and
incompleteness in the requirements,
– resolve all inconsistencies and incompleteness.
 Requirements Specification
• After the requirements gathering and analysis the
identified requirements are documented. This is a
Software Requirements Specification (SRS)
document.
 Design
• Design phase transforms requirements
specification into a form suitable for implementation
in some programming language.
• During design phase, software architecture is
derived from the SRS document.
• Two design approaches are used at present:
– Procedural Design approach
– Object oriented Design approach.
 Procedural Design approach

• It consists of two activities:

–Structured analysis (typically carried
out by using data flow diagram )
–Structured design(Architecture)
 Object Oriented Design
• First identify various objects (real world entities)
occurring in the problem:
– identify the relationships among the objects.
– For example, the objects in a pay-roll software may be:
• employees,
• managers,
• pay-roll register,
• Departments, etc.
 Coding and unit testing
– This phase is to translate software design into source code.
– This phase is also called as Implementation phase.
• During the implementation phase:
– each module of the design is coded, M1
– each module is unit tested and debugged.
• The purpose of unit testing: M2
– test if individual modules work correctly.
• The end product of implementation phase is a set of program
M3
modules that have been tested individually.
Unit test debugging
 Integration and System Testing

• Different modules are integrated in a planned

manner.
Integration and System Testing

M1 M2

M3 M4
 System Testing

• After all the modules have been successfully

integrated and tested system testing is carried out.
• Goal of system testing is to ensure that the
developed system functions according to its
requirements as specified in the SRS document.
 Maintenance
• Maintenance of any software product requires
much more effort than the effort to develop the product
itself.
• Maintenance is required in three situations.
 Maintenance
• Corrective maintenance:
– Correct errors which were not discovered during the product
development phases.
• Perfective maintenance:
– Improve implementation of the system
– enhance functionalities of the system.
• Adaptive maintenance:
– Port software to a new environment,
• e.g. to a new computer or to a new operating system.
When to use the Waterfall Model?

 Requirements are well known and stable

 Technology is understood
 Development team have experience with
similar projects
 For small projects
 Prototyping Model
• Prototype is not a complete product it is just
function replica of any idea, software or system.
• It is applied when customer do not know exact
project requirements.
• It generate before the actual development of
software.
• It is an iterative, trial and error methodswhich
takes place between developer and client.
71
 Advantages of Prototyping Model
• Prototype model need not know the detailed input,
output,processes,adaptability of operating system and full machine
interaction
• Good where requirements are changing
• Customers are actively involved in development
• Prototypes can be changed and even discarded
• Errors can be detected much earlier as the system is made side by side
• Flexibility in design
• Help team members to communicate effectively.
 Disadvantages of prototyping model
 The client involvement is more and it is not always considered
by developers
 It is slow process because it takes more time for development
 Many changes can disturb rhythm of development team
 Documentation is poor as the requirement change frequently
 costly with respect to time and money
 Prototyping tools are expensive
 Incremental model/Development model
• In incremental model requirements are divided into multiple
standalone modules of software development cycle.
• Each module goes through
requirements,design,implementation,and testng phases
• The process continues until the complete system achieved.

74
75
 When to use incremental mode
• When customers demands a quick release of product.
• A project has a long development schedule
• Software team are not very well skilled or trained.

76
 Advantages
• The client gets important functionality early
• Errors are easy to recognized
• Easier to test and debug
• Changes are easy to implement
• It is less expensive and flexible
• it is good to use when projects having lengthy development
schedules.

77
 DISADVANTAGS
• Proper planned execution are needed
• Science each increment requires its own planning, design,
coding, so overall cost of the project can be higher.
• Difficulty in tracking progress
with multiple increments being developed simultaneously, it
is risk to track progress of a project as a whole.
• More time spent on testing

78
 Rational Unified Process
• It was developed by rational ,now part of IBM.
• It was designed for object-oriented development using uml.
• RUP process that development of software can be divided into
4 phases.
• 1.Inception
• 2.Elaboration
• 3.Construction
• 4.Transition
79
80
• Each Phase has a distinct purpose and completion of each
phase is a well-defined milestone.

81
 Inception Phase
• The purpose of this phase is to establish
 goal
 scope of the project
 vision document
 business benefits it is expected to provide
 initial use-case
we use use-case modeling to identify project scope ,
costs,time required to build it.
82
 Key risks
 Basic plan of the project regarding cost and schedule.
 The Completion of this phase is a life cycle objectives
milestone.

83
 Elaboration Phase
• Final use-case modeling
• Analysis modeling
• The architecture of system is designed
• The completion of this phase is Life-cycle architecture
milestone

84
 Construction Phase
• In construction the software is build and tested.
• This phase results in software product to be delivered along
with user manuals.
• And successfully completing this phase results in initial
operational capability milestone being achieved.

85
 Transition Phase
• The purpose of this phase is to move software from
development environment to clients environment.
• It is complex task which can require additional testing,test-
cases,test-plans etc.,
• The successful execution of this phase results in achieving
milestone product released.

86
 Agile and extreme development model
• Extreme programming is one type of agile s/w
• Extreme programming uses an object-oriented approach.

87
 Planning
• Extreme programming starts with user-stories which are
short(a few sentences) that describes the required output
features and functionality for software to build.
• The customer assigns a value (priority) to the story.
• Members of XP team assess each story measured interms of
weeks.
• Once a basic commitment ,the XP team orders stories in one of
three ways.

88
• 1. all stories will be implemented with in a week
• 2.stories with highest value will be moved up in the schedule
and implement first.
• 3.The riskiest stories will be moved up schedule and
implemented first.

89
 Design
• It follows keep it simple approach.
• Simple design preferred over a complex representation
• Here we follows one kind of design i.e, CRC(Class –
Responsibility Collaborator)
• How many classes we have to create and how many variables
creates etc.,

90
 Coding
• Refactoring
it is process of changing a software system in such a way that
it does not alter external behaviour of code yet improve
internal structure.
• It simplify internal design (minimize chances of introducing
bugs)
• A key concept during coding in XP is PAIR PROGRAMMING.

91
• Pair programming
XP recommends two people work together at one computer
workstation to create code for a story.
• As the pair programmers complete their work ,the code is
integrated with others.

92
 Testing
• XP acceptance tests derived from user user stories are
specified by the customer and focus on overall system features
and functionality.

93