IT361-Software Engineering

K.D.Patel Department of Information Technology

✓ Outline
Looping

▪ Software, Characteristics of Software, Software Application Domains

▪ Software Engineering, Software Engineering Layered Approach
▪ Software Process, Process Framework Activities , Umbrella Activities
▪ Software Myths
• Management Myth
• Customer Myth
• Practitioner's/Developer Myth)
▪ Software Process Models
• The Waterfall Model
• Incremental Process Model
• Prototyping Model, Spiral Model
• Spiral Model
• Rapid Application Development Model (RAD)
Why to Study Software Engineering?
Software Development Life Cycle without Software
Engineering

1 2 3 4 5
How the How the How the How the How the
Customer Project System Programme Business
Explains Leader Analyst r Works Consultant
Requirement understand design it on it describe it
it
3
Why to Study Software Engineering?
Software Development Life Cycle without Software
Engineering

6 7 8 9 10

How the What How the How it What the

Project Operations Customer was customer
documented Installed billed supported really needed

4
SDLC without Software Engineering

Customer Requirement Solution The software

• Have one trunk • Have one trunk development
• Have four legs • Have four legs process needs to be
• Should carry load both • Should carry load both engineered
passenger & cargo passenger & cargo
• Black in color • Black in color
to avoid the
• Should be herbivorous • Should be herbivorous communication gap
& to meet the actual
Our value requirements of
customer
added,
within stipulated
also gives budget
milk & time
5
Software Engineering
Engineering
Software Engineering

Desig Buil Product

n d

6
Software is dead…..!
The old School view of Software
You buy it
You own it &
It’s your job to manage it
That is coming to an end

Because of web 2.0 & extensive computing

power, there is a different generation of software
It is delivered via Internet
It looks exactly like it’s residing on each user’s
computing device
Actually it reside on far away server

7
What is Software?

Software is
1) Computer program that when executed provide desired features, function & performance
2) Data Structure that enable programs to easily manipulate information
3) Descriptive information in both hard and soft copy that describes the operation and use of
programs

+ +
Compute Data Documents
r Structur Soft &
Program e Hard
8
List of documentation & manuals
Formal Specification
Analysis / Documentation Manuals
Context Diagram
Specification
Data Flow Diagram
User Manuals Operational
Documentation

Flow Charts Manuals

Manuals

Design
ER Diagram System Installation
Overview Guide
Source Code Listings
Beginner’s
Implementation Guide
Cross-Reference Listings Tutorials System
Administration
Test Data Guide
Reference
Testing Guide
Test Results

9
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” ,but it does deteriorate.
Although the industry is moving toward component-based assembly, most software continues to be custom built.
Increate failure rate due to
Change side effect
Infant
“Wear out”
morality

Actual
Failure

Failure
Curve
Rate

Rate
Idealized
Tim Curve Tim
e e
Bathtub curve of hardware failure Software failure curve
10
Software Application Domains

• System Software System

Softwar
• Application Software e Point of
Artificial Sale,
• Engineering / Application
intelligence Customized
Software
Scientific Software Software Software
• Embedded Software Software
• Product line Software Application
Web Engineerin
• Web Application Domains g /
Application
• Artificial intelligence Scientific
Software
Software
Product line Embedded
Software Software

11
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:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

12
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

It is a foundation of Software Engineering, It is the glue the

holds the technology layers, It defines a framework
activities
Defines continuous process improvement principles
13
Software Engineering Layered Approach 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 & similar approaches encourages a continuous
process improvement culture
Process Layer
It is a foundation of Software Engineering, It is the glue the holds the technology layers
together and enables logical and timely development of computer software.
It defines a framework with activities for effective delivery of software engineering
technology
It establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.
14
Software Engineering Layered Approach Cont.
Method
It provides technical how-to’s for building software
It encompasses many tasks including communication, requirement analysis, design
modeling, program construction, testing and support

Tools
Software engineering tools provide automated or semiautomated support for the process
and the methods
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.

15
Software Process
A process is a collection of activities, actions and tasks that are performed when some work
product is to be created
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 tasks
An activity try to achieve a broad objective (e.g., communication with stakeholders)
An activity is applied regardless of the application domain, size of the project, complexity
of the effort, or degree of accuracy with which software engineering is to be applied.
An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural design model).
A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a noticeable outcome.
Each of these activities, actions & tasks reside within a framework or model

16
Software Process Software Process Framework
Figure represents “The Software Process” Process
framework
Umbrella
Each framework activity is populated by
activities
set of software engineering actions framework activity
#1 Software Engineering action #1.1
Each software engineering action is Task Work tasks
defined by a task set that identifies work Sets
… Work products
to be completed, product to be produced, … Quality assurance points
quality assurance points & milestones to Software Engineering action #1.k

Software
indicate progress

Process
Task Work tasks
Sets
… Work products
… Quality assurance points
The purpose of software process is
framework activity
to deliver software in timely manner and #n
within sufficient quality to satisfy those
Who has given proposal for software
development and
Those who will use software
17
Process Framework Activities (CPMCD)
A process framework establishes the foundation for complete software engineering process, it encompasses five
activities Software Project Plan which
Communicatio Communication with Planning
n defines workflow that is to
Customers / stockholders
follow.
to understand project
It describes technical task, risks,
requirements for defining
resources, product to be produced
software features
& work schedule
Modeling Creating models to Constructio Code Generation
understand requirements n (manual or automated)
and shows design of &
software to achieve Testing
requirements (to uncover errors in the code)
Deliver Software to Customer
Deployment Collect feedback from customer based on evaluation
Software Support
18
Umbrella Activities
Umbrella activities applied throughout the software project &
help a software team to manage and control progress, quality,
change & risks
Umbrella activities are those which
keep running in the background
throughout the software development

Software project Risk Software quality

It establish a
Tracking & Control Management assurance
skeleton
Technical Reviews Measurement
Reusability
architecture
Management for software
Software Configuration Management engineering
Work product preparation and production work.

19
Umbrella Activities Cont.
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.
Technical reviews: assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
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.

20
Umbrella Activities Cont.
Reusability management: 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 models, documents, logs, forms and lists.

21
Software Myths Beliefs about software and the process used to build it.

Management
Myths

Customer Myths

“Misleading Attitudes Practitioner's

that cause serious (Developer)
Myths
problem” are myths.
22
Management myth - 1 & 2
We have standards and procedures We have the newest computers
to build a system, which is enough. and development tools.

Realit Realit
y y
Are software practitioners aware of It takes much more than the latest
standard’s existence? model computers to do high-quality
Does it reflect modern software software development.
engineering practice? Computer-aided software engineering
Is it complete? (CASE) tools are more important than
hardware.
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.“
23
Management myth - 3 & 4
We can add more programmers I outsourced the development
and can catch up the schedule. activity, now I can relax and can
wait for the final working product.
Realit Realit
y y
Software development is not a If an organization does not understand
mechanistic process like manufacturing. how to manage and control software
In the words of Fred Brooks : "adding projects internally, it will invariably
people to a late software project makes it struggle when it outsources software
later." projects.
People who were working must spend
time educating the newcomers.
People can be added but only in a planned
and well-coordinated manner.

24
Customer myth - 1 & 2
A general statement of objectives Requirement Changes can be easily
(requirements) is sufficient to start a accommodated because software is
development. very flexible.
Realit Realit
y y
Comprehensive (detailed) statements of It is true that software requirements
requirements is not always possible, an change, but the impact of change
ambiguous (unclear) “statement of varies with the time at which it is
objectives” can lead to disaster. introduced.
Unambiguous (clear) requirements can be When requirements changes are
gathered only through effective and requested early the cost impact is
continuous communication between relatively small.
customer and developer.

25
Practitioner's (Developer) myth – 1 & 2
Once we write the program, our I can’t access quality until it is
job is done. running.

Realit Realit
y y
Experts say "the sooner you begin One of the most effective software
'writing code', the longer it will take you quality assurance mechanisms can be
to get done." applied from the beginning of a project
Industry data indicates that 60 to 80 % - the technical review.
effort expended on software will be after it Software reviews are more effective
is delivered to the customer for the first “quality filter” than testing for finding
time. software defects.

26
Practitioner's (Developer) myth – 3 & 4
Working program is the only Software engineering is about
deliverable work product. unnecessary documentation.

Realit Realit
y y
A working program is only one part of a Software engineering is not about
software configuration. creating documents. It is about creating
A variety of work products (e.g., models, a quality product.
documents, plans) provide a foundation Better quality leads to reduced rework.
for successful engineering and, more And reduced rework results in faster
important, guidance for software support. delivery times.

27
Software Process Models The process model is the abstract representation of process.

Also known as Software development life cycle SDLC

(SDLC) or Application development life cycle
Models Communicatio Phases
n
Process models prescribe a distinct set of
activities, actions, tasks and milestones
(deliverables) required to engineer high quality
software.
Deployme
nt
SD Planni
ng
Software
Process models are not perfect, but provide LC
Developmen
roadmap for software engineering work.
t
Software models provide stability, control and Life
organization to a process that if not managed can Cycle
easily get out of control. Constructi Modelin
on g
Software process models are adapted (adjusted)
to meet the needs of software engineers and
managers for a specific project.
28
Different Process Models
Process model is selected based on Process Models
different parameters
Type of the project & people Waterfall Model (Linear Sequential
Complexity of the project Model)
Size of team Incremental Process Model
Expertise of people in team
Working environment of team
Prototyping Model
Software delivery deadline The Spiral Model
Rapid Application Development Model
Agile Model

29
The Waterfall Model Classic life cycle or linear sequential
model

Communication
• Project initiation
Planning
• Requirements
gathering • Estimating
Modeling
• Scheduling
• Tracking • Analysis
Construction
• Design
• Coding
Deployment
• Testing
• Delivery
• Support
• Feedback

When requirements for a problems are well understood then this model is used
in which work flow from communication to deployment is linear
30
The Waterfall Model
When to use ? Advantages
Requirements are very well known, Simple to implement and manage
clear and fixed
Product definition is stable Drawbacks
Technology is understood Unable to accommodate changes at later
stages, that is required in most of the cases.
There are no ambiguous (unclear)
requirements Working version is not available during
development. Which can lead the
Ample (sufficient) resources with
development with major mistakes.
required expertise are available freely
Deadlock can occur due to delay in any
The project is short
step.
Not suitable for large projects.

31
Incremental Process Model
There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort prevent a purely linear process.
In addition, there may be a compelling need to provide a limited set of software
functionality to users quickly and then refine and expand on that functionality in later
software releases.
In such cases, there is a need of a process model that is designed to produce the software in
increments.

32
Incremental Process Model
Software Functionality &
Features

Project Calendar
Time

The incremental model combines elements of linear and parallel process flows.
This model applies linear sequence in a iterative manner.
Initially core working product is delivered.
Each linear sequence produces deliverable “increments” of the software.

33
Incremental Process Model
e.g. 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; Advantages
spelling and grammar checking in the third Generates working software
increment; and quickly and early during the
software life cycle.
advanced page layout capability in the fourth
increment. It is easier to test and debug during
a smaller iteration.
When to use ?
Customer can respond to each
When the requirements of the complete system built.
are clearly defined and understood but staffing Lowers initial delivery cost.
is unavailable for a complete implementation Easier to manage risk because
by the business deadline. risky pieces are identified and
handled during iteration.
34
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.
They are characterized in a manner that enables you to develop increasingly more complete
versions of the software.
Evolutionary models are
Prototyping Model
Spiral Model

35
Prototyping model
When to use ?
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
Developers get to build something immediately

36
Prototyping model cont.
It works as
follow Communicate with stockholders &
define objective of Software
Deployment & Communication
Feedback Identify requirements & design quick
plan
Model a quick design (focuses on visible
part of software)

Construct Prototype & deploy

Construction
of Prototype Quick Plan Stakeholders evaluate this prototype and
provides feedback
Iteration occurs and prototype is tuned
Modeling Quick based on feedback
Design
37
Prototyping model cont.
Problem Areas
Customer demand that “a few fixes” be applied to make the prototype a working
product, due to that software quality suffers as a result
Developer often makes implementation in order to get a prototype working quickly;
without considering other factors in mind like OS, Programming language, etc.

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

38
The Spiral 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.
It is divided into framework activities
(C,P,M,C,D). Each activity represent one
segment of the spiral
Each pass through the planning region results
in adjustments to
the project plan
Cost & schedule based on feedback

39
The Spiral Model Cont.
When to use Spiral Advantages
Model?
For development of large scale / High amount of risk analysis hence, avoidance of
high-risk projects. Risk is enhanced.
When costs and risk evaluation Strong approval and documentation control.
is important. Additional functionality can be added at a later
Users are unsure of their needs. date.
Requirements are complex. Software is produced early in the Software Life
Disadvantage
Cycle.
New product line.
s
Significant (considerable) Can be a costly model to use.
changes are expected. Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk
analysis phase.
Doesn’t work well for smaller projects.
40
 It is a type of
Rapid Application Development Model (RAD) incremental model
in which;
Communicatio Team - 1 components or
n functions are
Modeling
developed in
Construction • Integratio parallel.
Planning n Rapid development
• Delivery
Team - 2 • Feedback is achieved by
• Business component based
Modeling Modeling
• Data Deployment construction
Construction
Modeling
• Process
This can quickly
Modeling Team - 3 • Component give the customer
Modeling Reuse
• Automatic something to see
Construction Code and use and to
Generation provide feedback.
• Testing
41
Rapid Application Development Model (RAD) Cont.
Communicatio This phase is used to understand business problem.
n
Planning Multiple software teams work in parallel on different systems/modules.

Modeling Construction
Business Modeling: Information flow among the It highlighting the use of
business. pre-existing software component.
Ex. What kind of information drives (moves)?
Who is going to generate information? Deployment
From where information comes and goes?
Integration of modules
Data Modeling: Information refine into set of developed by parallel teams,
data objects that are needed to support business. delivery of integrated software
Process Modeling: Data object transforms to and feedback comes under
information flow necessary to implement business. deployment phase.

42
Rapid Application Development Model (RAD) Cont.
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.
Resources with high business knowledge are available.
Advantages Drawback
Reduced development time. For large but scalable projects, RAD requires
sufficient human resources.
Increases reusability of components.
Projects fail if developers and customers are
Quick initial reviews occur. not committed in a much shortened
Encourages customer feedback. time-frame.
Integration from very beginning Problematic if system can not be
solves a lot of integration issues. modularized.
Not appropriate when technical risks43 are
Component based Development
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.
Modeling and construction activities begin with the identification of components.

44
Component based Development
Component based development incorporates the following steps
1. Available component-based products are researched & evaluated for software
development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.

Advantages
It leads to software reuse.
It reduces development cycle time.
Reduction in project cost.

45
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 keeping creative
people engaged as software engineering continues to evolve.

46