3150711

Software Engineering

Unit - 1
Introduction to
Software & Software
Engineering
Why to Study Software Engineering?

Software development Process needs to be

engineered to avoid the communication gape &
to meet the actual requirement of customer
within stipulated budget & time.
What is Software?
 Software is nothing but a collection of computer programs and
related documents that are desired features, functionalities and
better performance.

+ +
Computer Data Documents
Program Structure Soft & Hard
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

+ +
Computer Data Documents
Program Structure Soft & Hard
The Evolving Role of Software
Dual Role of Software
1. As product
Act as information transformer —
Producing, managing,
modifying, displaying and/or
transmitting the source of
information
2. As process
The vehicle for delivering a
product as
To control the computer or to
establish communication
between the computer (Ex.
Networking software)
The Evolving Role of Software
The role of software is significantly changing over
past decade. There are many factors affecting the
role of software and those are:

• Changes in computer architectures.

• Improvement in hardware performance.

• Vast increase in amount of memory.

• Wide variety of input and output.

Different Era of Computing
Era of Computing Software
Early Years Batch Processing ,
Custom software
Second Era Multi user Real Time System
Database System
Product Software
Third Era Distributed Systems
Forth Era Object oriented systems
Expert Systems
Parallel Computing
Network Computers
Fifth Era Web Technologies
Mobile Computing
List of Documentation Manuals
Formal Specification
Analysis /
Context Diagram
Specification
Data Flow Diagram
Documentation

Flow Charts
Design
Manuals

ER Diagram

Source Code Listings

Implementation
Cross-Reference Listings

Test Data
Testing
Test Results
List of Documentation Manuals

System Overview
Documentation

User Manuals Beginner’s Guide Tutorials

Manuals

Reference Guide

Installation Guide
Operational Manuals
System Administration Guide
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”
Infant
“Wear out”
morality
Failure Rate

Time

Bathtub curve of hardware failure

Characteristics of Software cont.
Change
Failure Rate Increate failure rate due to side effect

Actual Curve

Idealized Curve

Time
Software failure curve

 Although the industry is moving toward component

based construction, most software continues to be

custom built
Software Failure curve

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

Software
Application Engineering
Web Domains
Application / Scientific
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:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation
 Layered
Technology
Software Engineering: A Layered Technology

16
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
Myths
1.3 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 quality in the product.
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
program.

 Reality:
• 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.

• It helps in creating better quality. Hence documentation is

not wastage of time but it is a must for any software project.
Software
Process
Software Process
 A process is a collection of activities, actions and tasks that
are performed when some work product is to be created.
1. 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
2. Action
 A set of tasks that produce a major work product
 E.g. Architectural Design
3. Task
 A piece of work to be done.
 Focuses on a small, but well-defined objective
Software Process
 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.
 The purpose of software process is
• to deliver software in timely manner and
• within sufficient quality to satisfy those
• Who has given proposal for software development and
• Those who will use software

• A process framework establishes the foundation for complete

software engineering process, it encompasses five activities.
Process Framework Activities
Communication Communication Planning Software Project Plan
with Customers / 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

understand Generation
requirements and (manual or automated)
shows design of &
software to Testing
achieve (to uncover errors in the
requirements code)

Deliver Software to Customer

Collect feedback from customer based on
Deployment evaluation
Software Support
Umbrella
Activities
Umbrella Activities

 Umbrella activities are those

which keep running in the
background throughout the
software development.
 Umbrella activities applied
throughout the software project
& help a software team to
manage, tracking and control
progress, quality, change &
risks.
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.
 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.
 Measurement: defines and collects process, project and
product measures that assist the team in delivering software
that meets stakeholders’ needs.
Umbrella Activities Cont.
 Software configuration management: it manages the effects
of change throughout the software process.

 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 includes the

activities required to create work products such as models,
documents, logs, forms and lists.
 Software
Process
Framework
Generic Software Process Framework
Process framework
Umbrella activities
framework activity #1
Software Engineering action #1.1
Software Process

Task Sets Work tasks

… Work products
… Quality assurance points
Software Engineering action #1.k
Task Sets Work tasks
… Work products
… Quality assurance points

framework activity #n
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 tasks(e.g., requirements gathering, elaboration, specification,
validation etc.)
• A list of the 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
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.
 Software process models are adapted (adjusted) to meet the
needs of software engineers and managers for a specific
project.
 SDLC
(Software
Development
Life Cycle)
SDLC Phases

Deployment Planning

Construction
Different Process Models
 Waterfall Model (Linear Sequential Model)

 Incremental Process Model

 Prototyping Model

 The Spiral Model

 Rapid Application Development Model

 Agile Model
Waterfall
Model
The Waterfall Model

Communication • Project initiation,

requirements gathering

• Estimating, scheduling,
Planning tracking

Modeling • Analysis, design

Construction • Code, test

• Delivery,
Deployment support,
feedback
The Waterfall Model cont.
 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 cont.
 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 cont.
 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
Incremental Process Model
Incremental Process Model cont.
 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;
• spelling and grammar checking in the third increment; and
• advanced page layout capability in the fourth increment.
Incremental Process Model cont
 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 Process Model cont
 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
• Needs good planning and design to integrate components.
• Total cost is higher than Waterfall.
 RAD Model
(Rapid
Application
Development)
RAD(Rapid Application Development )Model

Team - 1
Modeling

Construction
Integration
Communication Delivery
Team - 2 Feedback

Planning Modeling
Deployment
Construction

Team - 3
Component Reuse
Modeling
Business Automatic Code
Modeling Generation
Construction
Data Modeling Testing
Process Modeling
RAD Model Cont.
 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 Cont.
 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 support business.
• Process Modeling: Data object transforms to information flow
necessary to implement business.
 Construction
• It highlighting the use of pre-existing software component.
 Deployment
• Deliver to customer basis on subsequent iteration.
RAD Model 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.

 RAD Model Cont.
 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.
• Projects fail if developers and customers are not
committed in a much shortened time-frame.
• Problematic if system can not be modularized.
• Not appropriate when technical risks are high (heavy use
of new technology).
Evolutionary
Process
Models
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
• Spiral Model
• Concurrent Development 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
• Developers get to build something immediately
Prototyping model cont.

Deployment & Communication

Feedback

Construction
of Prototype Quick Plan

Modeling
Quick Design
Prototyping model cont.
 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 to which that software quality suffers
as a result.
• Developer often makes implementation in order to get a
prototype working quickly.
Prototyping model
Types of Prototyping Models
Rapid Throwaway Prototype

 Rapid throwaway is based on the preliminary requirement. It is

quickly developed to show how the requirement will look visually.

 The customer’s feedback helps drives changes to the requirement,

and the prototype is again created until the requirement is baselined.

 In this method, a developed prototype will be discarded and will not

be a part of the ultimately accepted prototype.

 This technique is useful for exploring ideas and getting instant

feedback for customer requirements.
Prototyping model
Evolutionary Prototyping

 Here, the prototype developed is incrementally refined based

on customer’s feedback until it is finally accepted. It helps you
to save time as well as effort.

 That’s because developing a prototype from scratch for every

interaction of the process can sometimes be very frustrating.

 It is also used for a complex project where every functionality

must be checked once. It is helpful when the requirement is not
stable or not understood clearly at the initial stage.
Rapid Prototyping
Evolutionary Prototyping
Prototyping model cont.
 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.
• There is no way to know the numbers of iteration will be
required.
The Spiral Model
The Spiral Model cont.
 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)
 Meta 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.
The Spiral Model cont.
 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 cont.
 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.
• Doesn’t work well for smaller projects.
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)
with other activities, actions
or tasks.
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.
Agile Process Model
Agile Process Model
• Ability to move quickly and respond to changes –
changes from requirements, technology and people.
• Agile SDLC model is a combination of iterative and
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
• Agile Methods break the product into small
incremental builds.
• Every iteration involves cross functional teams
working simultaneously on various areas like
planning, requirements analysis, design, coding, unit
testing, and acceptance testing.
Agile Process Model (Cont…)
Advantages
• Customer satisfaction by rapid, continuous
delivery of useful software.
• Customers, developers and testers constantly
interact with each other.
• Daily cooperation between business people and
developers.
• Continuous attention to technical excellence
(quality) and good design.
• Regular adaptation to changing circumstances.
Agile Process Model (Cont…)
Disadvantages
• In case of some software, it is difficult to
estimate the effort required at the beginning
of the software development life cycle.
• The project can easily get “off track” if the
customer representative is not clear about final
outcome, that they want.
• Only senior programmers are capable of taking
the kind of decisions required during the
development process.
Component-Based Development
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.
Component based Development cont.
 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.
Component based Development cont.
 Properties of Components
• Independent
• Standardized
• Deployable
• Documented

 Advantages
• It leads to software reuse.
• Extensibility
• Maintainability
• It reduces development cycle time.
• Reduction in project cost.
Software Process & Software Product
Sr.
Process Product
No.
Process is a set of sequence steps that Product is the final production of the
1
have to be followed to create a project. project.
Process is focused on completing each
2 A product focuses on the final result.
step being developed.
The process consistently follows In the case of products, the firm
3
guidelines. guidelines are followed.
4 Process tends to be long-term. A product tends to be short-term.

5 Developed by Process Engineer. Developed by Software Engineer.

The purpose of the process is to make
6
the quality of the project better.
A process serves as a model for
7 producing various goods in a similar
way.
The main goal of the product is to
complete the work successfully.
Product is created based on the
needs and expectations of the
customers.
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.