ASHA M TARSADIA INSTITUTE OF COMPUTER SCIENCE & TECNOLOGY

BE 2RD YEAR 3RD SEM

Unit 1 Introduction to Software

Engineering & Software
processes

Software Engineering(CE4013)
Urvisha Patel
Assistant Professor
 Why to Study Software Engineering?
• Software development Process needs to be engineered to
avoid the communication gap & to meet the actual
requirement of customer within stipulated budget & time.
The Nature of software
 Dual Role of Software
• As product:-
Act as an information transformer—producing,
managing,acquiring, modifying, displaying or
transmitting information
• As process:-
The vehicle for delivering a product as - To control the
computer or to establish communication between the
computer (Ex. Networking software)
 What is Software?
Software is
• Computer program that when executed provide desired features,
function & performance
• Data Structure that enable programs to easily manipulate information
• Descriptive information in both hard and soft copy that describes the

+
operation and use of programs
+
Computer Data Documents
Program Structure Soft & Hard
 The Evolving Role of Software
The role of software is significantly changing over past
decade. There are many factors affecting the role of
software like:
• Changes in computer architectures.
• Improvement in hardware performance.
• Vast increase in amount of memory.
• Wide variety of input and output.
 Characteristics of Software
• Software is developed or engineered. It is not
manufactured like hardware
• Manufacturing phase can introduce quality problem that are
nonexistent (or easily corrected) for software
• Both requires construction of “product” but approaches are
different

• Software doesn’t “wear out.”

• Although the industry is moving toward component-
 Characteristics of Software
Infant
“Wear out”
Failure Rate morality

Time
Bathtub curve of hardware failure

• Figure depicts failure rate as a function of time for hardware.

• The relationship, often called the “bathtub curve,” indicates
that hardware exhibits relatively high failure rates early in its
life
 Characteristics of Software
Change
Failure Rate Increate failure rate due to side effect

Actual Curve

Idealized Curve

Software failure curve Time

• During its life, software will undergo change. As changes are made, it is likely that
errors will be introduced, causing the failure rate curve to spike as shown in the
“actual curve”. Before the curve can return to the original steady-state failure rate,
another change is requested, causing the curve to spike again. Slowly, the minimum
failure rate level begins to rise
Software Application Domains

System
Software Point of Sale,
Artificial Customized
Application Software
intelligence
Software Software

Web Software Engineering /

Application Application Scientific
Domains Software

Product line Embedded

Software Software
 Software Engineering
• Software engineering is the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently in real machines.
• Software Engineering is the science and art of building(designing
and writing programs) a software systems that are:
• on time
• on budget
• with acceptable performance
 Legacy Software
• Some of software are just released to individuals, industry &
government. But other programs are older, in some cases much
older.
• These older programs - often referred to as legacy software
• Legacy software systems were developed decades ago & have been
continually modified to meet changes in business requirements and
computing platforms.
• The proliferation of such systems is causing headaches for large
organizations who find them costly to maintain & risky to evolve.
 •Documentation Manuals
•Analysis / Specification
List of Documentation Manuals
•Formal Specification
•Context Diagram
•Data Flow Diagram

•Design
•Flow Charts
•ER Diagram

•Implementation
•Source Code Listings
•Cross-Reference Listings

•Testing
•Test Data
List of Documentation Manuals
•Documentation Manuals
•User Manuals
•System Overview
•Beginner’s Guide Tutorials
•Reference Guide

•Operational Manuals
•Installation Guide
•System Administration Guide
Software Engineering: A Layered Technology
Software Engineering Layered Approach
Software Engineering Tools allows automation of activities
which helps to perform systematic activities. A system for the
support of software development, called computer-aided
software engineering (CASE). Examples: Testing Tools,
Bug/Issue Tracking Tools etc…

It provides technical how-to’s for building software, it

encompasses many tasks including communication,
requirement analysis, design modeling, program
construction, testing and support

Foundation Layer of Software Engineering

Framework with order of activities.
Example: Sequence of Requirement Gathering, Design
Development, Testing Activities.
Defines continuous process improvement principles
 Software Engineering Cont…
Software Engineering is a layered technology
• Quality
• Main principle of Software Engineering is Quality Focus.
• An engineering approach must have a focus on quality.
• Total Quality Management (TQM), Six Sigma, ISO 9001, ISO
9000-3, CAPABILITY MATURITY MODEL (CMM), CMMI
(Capability Maturity Model Integration ) & similar approaches
encourages a continuous process improvement culture
 Software Engineering Cont…
• Process layer
• It is a foundation of Software Engineering
• It is the glue the holds the technology layers
• It defines a framework with activities for effective delivery of
software engineering technology
• Method
• It provides technical how-to’s for building software
• It encompasses many tasks including communication,
 Software Engineering Cont…
• Tools
• Computer‐aided software engineering (CASE) is the scientific
application of a set of tools and methods to a software system
which is meant to result in high‐quality, defect‐free, and
maintainable software products.
• CASE tools automate many of the activities involved in various
life cycle phases.
 Software Myths
Beliefs about software and the process used to build it.
• “Misleading Attitudes that cause serious problem” are myths.
• Management Myths
• Customer Myths
• Practitioner's (Developer) Myths
 Management Myth - 1
Using a collection of standards and procedures one
can build software.

Reality:
• Even though we have all standard and procedures with us for
helping the developer to build the software, it is not possible for
software professional to build desired product.
• This is because – the collection which we have should be complete,
it should reflect modern techniques and more importantly it should
be adaptable. It should also help the software professional to bring
 Management Myth - 2
Add more people to meet deadline of project.

Reality:
• Adding more people in order to catch the schedule will cause the
reverse effect on the software project
• i.e. software project will get delayed.
Because , we have to spend
more time on educating people or informing them about the
project.
 Management Myth - 3
If a project outsourced to the third party than all worries
of software building is over.

Reality:
• When a company needs to outsource the project then it simply
indicates that the company does not know how to manage the
project.
• Sometimes outsourced projects required proper support for
development
 Customer Myth - 1
Even if the software Requirements
are changing continuously it is
possible to accommodate these
changes in software.
Reality:
• It is true that software very flexible entity but if continuous
changes in the requirements have to be incorporated then there are
chances of introducing more and more errors in the software.
• Similarly , the additional resources and more design modifications
may be demanded by the software.
 Customer Myth - 2
We can start writing program by
using general problem statements
only. Later on using problem
description we can add up the
required functionalities in the
Reality: program.
• It is not possible each time to have Comprehensive (detailed)
problem statements. We have to start with general problem
statement; however by proper communication with customer the
software professionals can gather useful information.
• The most important thing is that the problem statement should be
unambiguous (clear) to begin with.
 Practitioner's (Developer) Myth - 1

Once we write the program, our job

is done.
Reality:
• Experts say "the sooner you begin 'writing code', the longer it will
take you to get done."
• Industry data indicates that 60 to 80 % effort expended on software
will be after it is delivered to the customer for the first time.
 Practitioner's (Developer) Myth - 2
There is no need of documenting the software
project; it unnecessarily slows down the
development process.

Reality:
• Documenting the software project helps in establishing ease in use
of software.
• Ithelps in creating better quality. Hence documentation is not
wastage of time but it is a must for any software project.
A Generic Process Model
 Software Process
A process is a collection of activities, actions and tasks that are
performed when some work product is to be created.
• Activity
• A thing that is happening or going on by a person or group to achieve a
broad objective is applied regardless of the application domain, size of the
project, complexity of the effort
• E.g. Communication with Stakeholders

• Action
• a set of tasks that produce a major work product

• E.g. Architectural Design

 Software Process
• Task
• A piece of work to be done.
• Focuses on a small, but well-defined objective
• E.g. Conducting a Unit Test

• A process is not a rigid prescription for how to build the software.

Rather it is adaptable approach that enables the people doing the work
to pick and choose the appropriate set of work actions and task.
• The purpose of software process is to deliver software in timely
manner and within sufficient quality to satisfy those Who has given
 Process Framework Activities
Communication Software Project Plan
Communication with Customers /
Planning which defines workflow
stockholders to that is to follow.
understand project It describes technical
requirements for task, risks, resources,
defining software product to be produced
features & work schedule
Modeling Creating models to
Construction Code Generation
understand (manual or automated)
requirements and &
shows design of Testing
software to achieve (to uncover errors in the
requirements code)
Deliver Software to Customer
Deployment Collect feedback from customer based on evaluation
Software Support
 Umbrella Activities
• Umbrella activities applied throughout the software project & help
a software team to manage, tracking and control progress, quality,
change & risks
• Umbrella activities are those which keep running in the
background
Software throughoutRisk
project the softwareSoftware
development
Tracking & Control Management quality
assurance
Formal Technical
Measurement
Reviews (FTR)
Reusability
Software Configuration Management Management
(SCM)
Work product preparation and production
 Umbrella Activities
• Software project tracking and control: allows the software team to
assess progress against the project plan and take any necessary
action to maintain the schedule.
• Risk management: assesses (evaluates) risks that may affect the
outcome of the project or the quality of the product.
• Software quality assurance: defines and conducts the activities
required to ensure software quality.
• Formal Technical reviews(FTR): assesses software engineering
work products in an effort to uncover and remove errors before
they are propagated to the next activity.
 Umbrella Activities
• Measurement: defines and collects process, project and product
measures that assist the team in delivering software that meets
stakeholders’ needs.
• Software configuration management: it manages the effects of
change throughout the software process.
• Reusabilitymanagement: it defines criteria for work product
reuse (including software components) and establishes
mechanisms to achieve reusable components.
• Work product preparation and production: it encompasses
(includes) the activities required to create work products such as
 Software Process Framework.
• A process is a collection of activities, actions and tasks that are
performed when some work product is to be created.
• Each framework activity is populated by set of software
engineering actions.
• Each software engineering action is defined by a task set.
• Task Set:
• A task set defines the actual work to be done to accomplish (achieve) the
objectives of a software engineering action.
• Ex. Action-Analysis and design where analysis encompasses a set of work
 Software Process Framework.
• A list of task to be accomplished
• A list of the work products to be produced
• A list of the milestones (special events) to determine project status
• A list of the quality assurance filters to be applied
Generic Software Process Framework
Process framework
Umbrella activities
framework activity #1
Software Engineering action #1.1
Task Sets Work tasks
… Work products
… Quality assurance points
Software Engineering action #1.k
Software

Task Sets
Process

Work tasks
… Work products
… Quality assurance points

framework activity #n
 Process Assessment & Improvement
A number of different approaches to software process assessment and
improvement have been proposed over the past few decades:
(CMMI –capability maturity model integration, SEI-software engineering institute)
• Standard CMMI Assessment Method for Process Improvement(SCAMPI)

• Provides a five-step process assessment model that incorporates

Five phases: initiating, diagnosing, establishing, acting, and
learning.
• The SCAMPI method uses the SEI CMMI as the basis for
assessment [SEI00].
•CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
 Process Assessment & Improvement
• SPICE (ISO/IEC15504) - a standard that defines a set of requirements
for software process assessment uses the SEI CMM as the basis for
the assessment[Dun01].
• The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process
[ISO08].
• ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is
directly applicable to software organizations and companies [Ant06].
 Software Process Models
• The process model is the abstract representation of process.
• Also known as Software development life cycle (SDLC) or
Application development life cycle Models
• Process models prescribe a distinct set of activities, actions, tasks and
milestones (deliverables) required to engineer high quality software.
• Process models are not perfect, but provide roadmap for software
engineering work.
• Software models provide stability, control and organization to a
process that if not managed can easily get out of control.
 (SDLC) Phases
Communication

SDLC
Deployment Planning
Software
Development
Life
Cycle
Construction
Modeling
 Different Process Models
• Waterfall Model (Linear Sequential Model)
• Incremental Process Model
• Prototyping Model
• The Spiral Model
• Rapid Application Development Model
• Agile Model
The Waterfall Model

•Communication
•Project initiation, requirements gathering

•Planning
•Estimating, scheduling, tracking

•Modeling
•Analysis, design

•Construction
•Code, test

•Deployment
•Delivery, support, feedback
 The Waterfall Model
• This Model also called as the Classic life cycle or linear sequential
model.
• The Linear sequential model suggests a systematic sequential
approach to software development.
• When requirements for a problems are well understood then this
model is used in which work flow from communication to
deployment is linear.
• Once a phase is complete, you cannot go back and repeat the
process of previous phase.
 The Waterfall Model
When to use ?
• Requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous (unclear) requirements.
• Sufficient resources with required expertise are available freely.
• The project is short
 The Waterfall Model
Advantages
• Simple to implement and manage
• Easy to use
Drawbacks
• Unable to accommodate changes at later stages, that is required in
most of the cases.
• Deadlock can occur due to delay in any step.
• Not suitable for large projects.
Incremental Process Model
• The Incremental Model
• The RAD Model
Incremental Model
 Incremental Model
• This model applies linear sequence in a iterative manner.
• Initially core working product is delivered.
• Each linear sequence produces deliverable “increments” of the
software.
• For example, word-processing software developed using the
incremental model
• It might deliver basic file management, editing and document
production functions in the first increment
• More sophisticated editing in the second increment;
 Incremental Model
When to Use ?
• When the requirements of the complete system are clearly
defined and understood but staffing is unavailable for a
complete implementation by the business deadline.
• When the major requirements are understood but some
requirement evolve within the passage of time.
• When product launch in the market is getting late.
• When customer have no problem of budget and time but he
demands for more and more quality in software.
 Incremental Model
Advantages
• Generates working software quickly and early during the software
life cycle.
• It is easier to test and debug during a smaller iteration.
• Customer can respond to each built.
• Lowers initial delivery cost.

• Easier to manage risk because risky pieces are identified and handled
during iteration.
Disadvantages
RAD(Rapid Application Development )Model
Team - 1
Modeling
Construction Integration
Communication Delivery
Team - 2 Feedback

Planning Modeling
Deployment
Construction

Team - 3
Modeling Component Reuse
Business Modeling Automatic Code
Data Modeling Construction Generation
Process Modeling Testing
 RAD Model
• It is a type of incremental model in which; components or
functions are developed in parallel.
• This can quickly give the customer something to see and use and to
provide feedback.
 RAD Model
• Communication - This phase is used to understand business problem.
• Planning - Multiple software teams work in parallel on different
systems/modules.

• Modeling -
• Business Modeling: Information flow among the business.

• Ex. What kind of information drives (moves)?

• Who is going to generate information?

• From where information comes and goes?

• Data Modeling: Information refine into set of data objects that are needed to
 RAD Model
• Construction - It highlighting the use of pre-existing software
component.
• Deployment - Deliver to customer basis on subsequent iteration.

When to Use ?
• There is a need to create a system that can be modularized in 2-3
months of time.
• High availability of designers and budget for modeling along with
the cost of automated code generating tools.
 RAD Model
• Advantages
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.

• Integration from very beginning solves a lot of integration issues.

• Drawback
• For large but scalable projects, RAD requires sufficient human resources.
Evolutionary Process Models
• Prototyping Model
• Spiral Model
• Concurrent Development Model
 Evolutionary Process Models
• When a set of core product or system requirements is well understood but
the details of product or system extensions have yet to be defined.
• In this situation there is a need of process model which specially designed
to accommodate product that evolve with time.
• Evolutionary Process Models are specially meant for that which produce
an increasingly more complete version of the software with each iteration
• Evolutionary Models are iterative.
• Evolutionary models are
• Prototyping Model
 Prototyping model
• Prototyping model is appropriate when
• Customers have general objectives of software but do not have detailed
requirements for functions & features.
• Developers are not sure about efficiency of an algorithm & technical
feasibilities.

• It serves as a mechanism for identifying software requirements.

• Prototype can be serve as “the first system”.
• Both stakeholders and software engineers like prototyping model
• Users get feel for the actual system
 Prototyping model

Deployment &
Communication
Feedback

Construction
of Prototype Quick Plan

Modeling Quick
Design
 Prototyping model
• It works as follow
• Communicate with stockholders & define objective of Software
• Identify requirements & design quick plan
• Model a quick design (focuses on visible part of software)
• Construct Prototype & deploy

• Stakeholders evaluate this prototype and provides feedback

• Iteration occurs and prototype is tuned based on feedback

• Customer demand that “a few fixes” be applied to make the prototype a

working product rather than rebuilding the whole system on prototype, due
Prototyping model
Rapid Prototyping
Evolutionary Prototyping
 Prototyping model
• Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system is
provided, the users get a better understanding of the system being
developed
• Errors can be detected much earlier
• Disadvantages
• It is impossible to know how long it will take.
The Spiral Model
 The Spiral Model
• The Spiral model is an evolutionary process model that couples
iterative nature of prototyping with the controlled and systematic
aspects of waterfall model.
• Combination of water fall model and iterative waterfall model
(Incremental model)
• It provides the potential for rapid development.
• Software is developed in a series of evolutionary releases.
• Early iteration release might be prototype but later iterations
provides more complete version of software.
 The Spiral Model
When to use Spiral Model?
• For development of large scale / high-risk projects.
• When costs and risk evaluation is important.
• Users are unsure of their needs.
• Requirements are complex.
• Significant (considerable) changes are expected.
 The Spiral Model
Advantages
• High amount of risk analysis hence, avoidance of Risk is enhanced
• Additional functionality can be added at a later date.
• Software is produced early in the Software Life Cycle.
Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
Concurrent Development Model
• Allow a software team to
represent iterative and
concurrent elements of any of
the process models.
• The Figure shows modeling
may be in any one of the states
at any given time.
• Each activity, action or task on
the network exists
simultaneously (all together)
Concurrent Development Model (Cont…)
For example,
• Communication activity has completed its first iteration and is in
the awaiting changes state.
• The modeling activity was in inactive state, now makes a transition
into the under development state.
 Specialized Process Models
• Component Based Devlopment
• The Formal Methods Model
• Aspect-Oriented Software Development
Component-Based Development
Component-Based Development (Cont…)
COTS software components, developed by vendors provide targeted
functionality with well-defined interfaces that enable the component
to be integrated in software.
Consists of the following process steps
• Available component-based products are researched and evaluated for the
application domain.
• Component integration issues are considered.

• A software architecture is designed to accommodate the components.

• Comprehensive (complete) testing is conducted to ensure proper functionality.

• Relies on a robust (healthy) component library.

Component-Based Development (Cont…)
• Commercial off the shelf (COTS) software components are offered
as product.
• COTS provides set of functionality with well defined interfaces
that enables component to be integrated into software.
• The component based development model incorporates many
characteristics of the spiral model.
• It is evolutionary in nature.
• Component based development model constructs applications from
prepackaged software components.
Component-Based Development (Cont…)
Properties of Components
• Independent
• Standardized
• Deployable
• Documented
Advantages
• It leads to software reuse.

• Extensibility

• Maintenance
 Formal Methods Model
Although not a mainstream approach, the formal methods model
offers the promise of defect-free software. Yet, concern about its
applicability in a business environment has been voiced:
• The development of formal models is currently quite time consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
• These concerns notwithstanding, the formal methods approach has gained
adherents among software developers who must build safety-critical software
 Aspect-Oriented Software Development
Aspect-oriented software development (AOSD), often referred to as
aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides
• a process and methodological approach for defining, specifying,
designing, and constructing aspects—
• “mechanisms beyond subroutines and inheritance for localizing the
expression of a crosscutting concern”
Software Process & Software Product
 Product & Process
• If the process is weak, the end product will suffer. But more confidence
on process is also dangerous.
• People gain more satisfaction from the creative process as they do from
the end product.
• Like an artist enjoys the brush strokes as much as the framed result.
• A writer enjoys the search for the proper metaphor (comparison) as
much as the finished book.
• As software professional, you should also derive as much satisfaction
from the process as the end product.
• The duality (contrast) of product and process is one important element in
Thank you