Chapter 1

Introduction to Software Engineering

12/23/2019 DEVEN GOL 1

Content

1. Introduction
2. Components
3. Layered Technologies
4. Generic View of Software Engineering
5. Study of Different Models
6. Process Technology

12/23/2019 DEVEN GOL 2

1. Introduction

What is Software?
Software is nothing but a collection of computer
programs and related documents that are intended
to provide desired features, functionalities and
better performance.

Software products may be:

1.Generic- That means developed to be sold to
range of different customers.
2.Custom- That means developed for a single
customer according to their specifications.

12/23/2019 DEVEN GOL 3

Evolution of Software Engineering

Early Computer Programming

High level language Programming
Control flow-based design
Data structure-oriented design
Data flow-oriented design
Object-oriented design
Web-based design

12/23/2019 DEVEN GOL 4

2. Components

Any software consist of three major

components – Programs, Documents,
Operating Procedure.
◦ Program is one part of entire software.
◦ Documentation consists of various
Manuals.(SRS and Different diagrams)
◦ Procedure represent instructions for initial
setup.(User guide, Installation guide)

12/23/2019 DEVEN GOL 5

 3. Layered Technologies
Software engineering is discipline in which theories,
methods and tools are applied to develop professional
software product.

Software Engineering Layers

12/23/2019 DEVEN GOL 6

Layered Technologies (Continued..)
A quality management is a backbone of
software engineering technology.
Process defines the framework for
timely delivery of software
Here Actual Method of implementation
is carried out with the help of analysis,
design, coding and testing.
Tools are used to bring automation in
software development process.
12/23/2019 DEVEN GOL 7
Software Characteristics

Software is engineered , not manufactured.

- In software development process, problems can
be rectified.
Software does not ware out.
- Software cant be replaced by another
components like Hardware.
Most software is custom built rather than
being assembled from components.
- In Hardware components such as ICs, capacitors
and registers are assembled according to design but
this is not done while building software.

12/23/2019 DEVEN GOL 8

4. Generic View of Software
Engineering
Common Process Framework:
It is characterized by Process Framework
Activities, Task sets and Umbrella Activities.
Process Framework Activities:
1.Communication 4. Constructions
2.Planing 5. Deployment (feedback of
customer)
3.Modeling
Task Set:
The task set defines the actual work done in order to
achieve the software objective. It is divided to :
1.Collection of software engineering work task
2. Project milestones
3. Software quality assurance points
12/23/2019 DEVEN GOL 9
Common Process Framework
(Continued)
Umbrella Activities :
1.Software project tracking and control (Progress and
schedule)
2.Risk Management (may affect project outcomes)
3. SQA (to maintain quality)
4. Formal technical review (remove errors)
5. Software configuration management
6. Work product preparation and production (to create
models, log, documentation)
7. Reusability management
8. Measurement.

12/23/2019 DEVEN GOL 10

5. Study of Different Models
Software Development Life Cycle (SDLC):
A framework that describes the
activities performed at each stage of a
software development project.

12/23/2019 DEVEN GOL 11

Phases of SDLC
1. Software Requirement Analysis
2. System Analysis and Design
3. Code Generation
4. Code Testing
5. Implementation
6. Maintenance

12/23/2019 DEVEN GOL 12

Phases of SDLC (1)
Software Requirement Analysis:
This process is also known as feasibility study.
In this phase, the development team visits the customer and studies
their system.
They investigate the need for possible software automation in the given
system.
By the end of the feasibility study, the team furnishes a document that
holds the different specific recommendations for the candidate system.
It also includes the personnel assignments, costs, project schedule,
target dates etc...
The requirement gathering process is intensified and focused specially
on software.
To understand the nature of the program(s) to be built, the system
engineer or "Analyst" must understand the information domain for the
software, as well as required function, behavior, performance and
interfacing.
The essential purpose of this phase is to find the need and to define
the problem that needs to be solved
12/23/2019 DEVEN GOL 13
Phases of SDLC (2)
System Analysis and Design:
1. High Level Design (HLD)
◦ List of modules and a brief description of each module.
◦ Brief functionality of each module.
◦ Interface relationship among modules.
◦ Dependencies between modules (if A exists, B exists etc).
◦ Database tables identified along with key elements.
◦ Overall architecture diagrams along with technology details.
2. Low Level Design (LLD)
◦ Detailed functional logic of the module, in pseudo code.
◦ Database tables, with all elements, including their type and size.
◦ All interface details.
◦ All dependency issues
◦ Complete input and outputs for a module.
A software development model is thus created.
Analysis and Design are very crucial in the whole development cycle. Any
glitch in the design phase could be very expensive to solve in the later stage of
the software development.
The logical system of the product is 12/23/2019
developedDEVEN
in this
GOLphase. 14
Phases of SDLC (3)
Code Generation:
The design must be translated into a machine-readable form. The code
generation step performs this task.
If the design is performed in a detailed manner, code generation can
be accomplished without much complication.
Programming tools like compilers, interpreters, debuggers etc... are
used to generate the code.
Different high level programming languages like C, C++, Pascal, Java are
used for coding. With respect to the type of application, the right
programming language is chosen.

12/23/2019 DEVEN GOL 15

Phases of SDLC (4)
Testing:
Once the code is generated, the software program testing begins.
Different testing methodologies are available to detect the bugs that
were committed during the previous phases.
Different testing tools and methodologies are available.
Some companies build their own testing tools that are tailor made for
their own development operations.

12/23/2019 DEVEN GOL 16

Phases of SDLC (5)
Installation :

Installation of the product in its operational environment.

12/23/2019 DEVEN GOL 17

Phases of SDLC (6)
Maintenance:

After the software is released and the client starts using the software,
maintenance phase is started.
3 things happen - Bug fixing, Upgrade, Enhancement
Bug fixing – bugs arrived due to some untested scenarios.
Upgrade – Upgrading the application to the newer versions of the
software.
Enhancement - Adding some new features into the existing software.

12/23/2019 DEVEN GOL 18

Types of Process flows
Linear Process flow
Iterative Process flow
Evolutionary Process flow
Parallel Process flow

12/23/2019 DEVEN GOL 19

12/23/2019 DEVEN GOL 20
 SOFTWARE LIFE CYCLE
MODELS
Waterfall Model / Linear Sequential Model

Prototype Model

Rapid Application Development (Rad) Model

Evolutionary Process Models:

• Incremental Model
• Spiral Model
• Concurrent Development Model

12/23/2019 DEVEN GOL 21

Waterfall Model

12/23/2019 DEVEN GOL 22

Waterfall Model
The project is divided in to separate
distinct phases
Each next phase starts after finishing the
previous phase.
Each phase communicate to next through
pre specified output
When an error is detected or revision is
required it is traced back to one previous
phase at a time, until it gets resolved at
some earlier phase
12/23/2019 DEVEN GOL 23
Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff,
track)
Works well when quality is more
important than cost or schedule

12/23/2019 DEVEN GOL 24

Waterfall deficiencies
All requirements must be known upfront
Deliverables created for each phase are
considered frozen(unmoving) – reduce
flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of
software development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview
the system (until it may be too late)

12/23/2019 DEVEN GOL 25

When to use the Waterfall Model
Requirements are very well known
Product definition is stable i.e.
Deliverables of each Phase can be frozen.
Technology is understood
New version of an existing product
Porting an existing product to a new
platform.

12/23/2019 DEVEN GOL 26

Prototyping Model

Q u i ck p l a n
Quick
Co m m u n icat io n plan
communication
Mo d e l i n g
Modeling
Q u ick d e sig n
Quick design

Deploym ent
Deployment
D e live r y
delivery
& Fe e d b & ack Co n st r u ct io n
feedback Construction
of
ofr oprototype
p t o t yp e

12/23/2019 DEVEN GOL 27

Prototyping Model
This model uses constant user interaction,
early in the requirements gathering stage to
produce a prototype.
Developers build a prototype during the
requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code
is brought up to the standards needed for a
final product.
12/23/2019 DEVEN GOL 28
Prototyping Steps
A preliminary project plan is developed
An partial high-level paper model is created
The model is source for a partial requirements
specification
A prototype is built with basic and critical
attributes to show how the eventual software
system look like, how input screens and output
reports would look like.
The designer builds
◦ the database
◦ user interface
◦ algorithmic functions
Continue….

12/23/2019 DEVEN GOL 29

Prototyping Steps (continued)
The designer demonstrates the prototype, the
user reviews and evaluates for problems, more
features and suggests improvements.
Based on feedback the prototype is improved and
sent for review.
This loop continues until the user is satisfied

Finally software product is created based on the

prototype.

12/23/2019 DEVEN GOL 30

Prototyping Strengths
Customers can “see” the system
requirements as they are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates
awareness of additional needed functionality
12/23/2019 DEVEN GOL 31
Prototyping Weaknesses
The customer may want the prototype
delivered.
Insufficient analysis
User confusion of prototype and finished
system
Developer misunderstanding of user
objectives
Excessive development time of the
prototype
Expense of implementing prototyping

12/23/2019 DEVEN GOL 32

When to use Prototyping
Requirements are unstable or have to be
clarified
Where we have a user who can give
feedback.
Can be used as the requirements
clarification stage of a waterfall model
Develop user interfaces
New, original development

12/23/2019 DEVEN GOL 33

Evolutionary Process models

Incremental model

Spiral model

Concurrent Development model

12/23/2019 DEVEN GOL 34

Incremental SDLC Model
Combines elements of Linear and Parallel
process flows
Construct a partial implementation of a total
system
Then slowly add increased functionality
The incremental model prioritizes
requirements of the system and then
implements them in groups.
Each subsequent release of the system adds
function to the previous release, until all
designed functionality has been implemented.

12/23/2019 DEVEN GOL 35

 Incremental SDLC Model

increment # n
Co m m u n i c a t i o n
Pl a nni ng
Modeling
analysis Co n s t r u c t i o n
des ign
code De p l o y m e n t
t est d e l i v e ry
feedbac k

delivery of
nt h increment
increment # 2

Co m m u n i c a t i o n
Pla nning
M ode ling
analy sis Co n s t ru c t i o n
design code De p l o y m e n t
t es t d e l i v e ry
fee dback
delivery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pl a nn i ng
Modeling
analysis Co n s t ru c t i o n
design c ode De p l o y m e n t
t est d e l i v e ry delivery of
feedbac k
1st increment

project calendar
12/23/2019time
DEVEN GOL 36
Incremental Model Strengths
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of
tasks
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

12/23/2019 DEVEN GOL 37

Incremental Model Weaknesses
Requires good planning and design
Requires early definition of a complete
and fully functional system to allow for
the definition of increments
Well-defined module interfaces are
required (some will be developed long
before others)
Total cost of the complete system is not
lower
12/23/2019 DEVEN GOL 38
When to use the Incremental
Model
Funding, schedule, program complexity, or
need for early realization of benefits.
Most of the requirements are known up-
front but are expected to evolve over
time
A need to get basic functionality to the
market early
On projects which have lengthy
development schedules
On a project with new technology
12/23/2019 DEVEN GOL 39
Spiral Model
It is an evolutionary software process model that
◦ couples the iterative nature of prototyping and
◦ the controlled and systematic aspects of the linear
sequential model

It provides the potential for rapid development of

incremental versions of the software.
Software is developed in a series of incremental
releases.
During early iterations, the incremental release
might be a paper model or prototype.
During later iterations, increasingly more complete
versions of the engineered system are produced.
12/23/2019 DEVEN GOL 40
Spiral Model

12/23/2019 DEVEN GOL 41

Spiral Model Task Regions
1. Customer communication —tasks required
to establish effective communication
between developer and customer.
2. Planning —tasks required to define
resources, timelines, and other project
related information.
3. Risk analysis —tasks required to assess
both technical and management risks.
4. Engineering —tasks required to build one
or more representations of the
application.
Continue…
12/23/2019 DEVEN GOL 42
Spiral Model Task Regions (continued..)
5. Construction and release —tasks required
to construct, test, install, and provide user
support (e.g., documentation and training).
6. Customer evaluation —tasks required to
obtain customer feedback based on
evaluation of the software representations
created during the engineering stage and
implemented during the installation stage.

12/23/2019 DEVEN GOL 43

Alternative view of Spiral model
Examine the project entry point axis
Concept development project – starts at
the core of the spiral
New development project – If the concept
is to be developed into an actual product
Product enhancement project – when
process is inactive, but starts when change
is initiated
Product maintenance project – using
customer feedback
12/23/2019 DEVEN GOL 44
Alternative view of Spiral model

12/23/2019 DEVEN GOL 45

Spiral Model Strengths
Provides early indication of risks, without
much cost
Users see the system early because of rapid
prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
12/23/2019 DEVEN GOL 46
Spiral Model Weaknesses
Time spent for evaluating risks too large for
small or low-risk projects
Time spent planning, resetting objectives, doing
risk analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-
development phase activities
May be hard to define objective, verifiable
milestones that indicate readiness to proceed
through the next iteration
12/23/2019 DEVEN GOL 47
When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because
of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and
exploration)
12/23/2019 DEVEN GOL 48
Concurrent Development model
Also called concurrent engineering
Constitutes a series of framework activities,
software engineering action, tasks and their
associated states
All activities exist concurrently but reside in
different states
It defines a network of activities. Each activity
on the network exists simultaneously with
other activities
Event generated at one point in the process
trigger transitions among the states
12/23/2019 DEVEN GOL 49
Concurrent Development model
none

M o d e lin g a c t iv it y

r ep r es ent s t he s t at e
Under o f a s o f t w ar e eng ineer ing
ac t iv it y o r t as k
d e v e lo p m e n t

A w a it in g
changes

U n d e r r e v ie w

Under
r e v is io n

B a s e lin e d

Done

12/23/2019 DEVEN GOL 50

Concurrent Development model
Usage
Often used as the paradigm for the
development of client/server applications
A client/server system is composed of a set of
functional components.
When applied to client/server, the concurrent
process model defines activities in two
dimensions
◦ A System dimension - issues are addressed using
three activities: design, assembly, and use
◦ A Component dimension - addressed with two
activities: design and realization
Applicable to all types of software development
12/23/2019 DEVEN GOL 51
Rapid Application Development
Model (RAD)
An incremental software process model
Having a short development cycle
High-speed adoption of the waterfall model using a
component based construction approach
Creates a fully functional system within a very short
span time of 60 to 90 days
Multiple software teams work in parallel on different
functions
Modeling encompasses three major phases: Business
modeling, Data modeling and process modeling
Construction uses reusable components, automatic
code generation and testing
12/23/2019 DEVEN GOL 52
Rapid Application Development (RAD)
Model Team # n
Mo d e lin g
business m odeling
data m odeling
process m odeling

Co n st ru ct io n
com ponent reuse
Team # 2 automatic code
Communicat ion generation
testing
Modeling
business modeling
dat a modeling
process model ing

Planning
Const ruct ion Deployment
Team # 1 com ponent reuse
int egrat ion
aut omat ic code
generat ion
delivery
Modeling t est ing feedback
business modeling
dat a modeling
process modeling

Const ruct ion

component reuse
aut omat ic code
generat ion
t est ing

12/23/2019 DEVEN GOL 53

60 - 90 days
RAD Strengths
Reduced cycle time and improved productivity
with fewer people means lower costs
Time-box approach reduce cost and schedule
risk
Customer involved throughout the complete
cycle minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code
Uses modeling concepts to capture information
about business, data, and processes.
12/23/2019 DEVEN GOL 54
RAD Weaknesses
Requires a number of RAD teams
Requires commitment from both developer
and customer for rapid-fire completion of
activities
Not suited when technical risks are high
Accelerated development process must give
quick responses to the user
Hard to use with inherited systems
Requires a system that can be modularized

12/23/2019 DEVEN GOL 55

When to use RAD
Reasonably well-known requirements
When we have CASE(Computer aided
SE) and other modeling tools
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized

12/23/2019 DEVEN GOL 56

Component Based Development
Object-oriented technologies provide the
technical framework for this type of model
Incorporates many of the characteristics of
the spiral model
It is evolutionary in nature demanding an
iterative approach
The engineering activity begins with the
identification of candidate classes

12/23/2019 DEVEN GOL 57

Component Based Development

12/23/2019 DEVEN GOL 58

6. Process Technology
The process models must be adapted for use by
a software project team
For that, process technology tools have been
developed to help software organizations
Process technology tools allow a software
organization to build an automated model of the
common process framework, task sets, and
umbrella activities
This model (or network), can be analyzed to
determine typical work flow and examine
alternative process structures for reducing
development time or cost
12/23/2019 DEVEN GOL 59
Process Technology (Continued..)
Other process technology tools can also be
used to allocate, monitor and control the
tasks defined as part of the process model
The process technology tool can also be
used to coordinate the use of other
computer-aided software engineering
(CASE) tools that are appropriate for a
particular work task

12/23/2019 DEVEN GOL 60

Product and Process
If the process is weak, the end product
will undoubtedly suffer, but an obsessive
overreliance on process is also dangerous
People derive as much (or more)
satisfaction from the creative process as
they do from the end product

12/23/2019 DEVEN GOL 61