Software Engineering

Software Engineering
m
.co
nt
Unit 1
oi
Part 1 Software Engineering Fundamentals
lp
ria
Part 2 Software Analysis
to
Tu
Cs
By SWARNIMA SHRIVASTAVA 1
part1
m
Software
.co
nt
oi
Engineering
lp
ria
to
Fundamentals
Tu
Cs
Software
(1) Instructions (computer programs) that

when executed provide desired features,
m
.co
function, and performance
nt
oi
(2) Data structures that enable the
lp
programs to adequately manipulate
ria
to
information
Tu
(3) Descriptive information in both hard

Cs
copy and virtual forms that describes the

operation and use of the programs.
Software Product
IEEE defines “Software is the collection
m

.co
of computer programs, procedure rules
nt
and associated documentation and data. “
oi
lp
ria
Software is considered to be collection of
to

Tu
executable programming code, associated

Cs
libraries and documentations. Software,

when made for a specific requirement is
called software product.
m
.co
nt
oi
lp
ria
to
Tu
Cs
Characteristics of
m
.co
software
nt
oi
lp
ria
to
Tu
Cs
m
.co
nt
oi
lp
 ria
software has one fundamental
to
characteristic that makes it considerably
Tu
Cs
different from hardware: Software

doesn’t “wear out.”
m
.co
nt
oi
lp
ria
to
Tu
Cs
 software will undergo change.
As changes made, it is likely that errors will
m
.co
be introduced, causing the failure rate curve
nt
to spike as shown in the “actual curve”
oi
Before the curve can return to the original
lp
steady-state failure rate, another change is
ria
to
requested, causing the curve to spike again.
Tu
Slowly, the minimum failure rate level begins

Cs
to rise—the software is deteriorating due to

change.
Software engineering
 Software engineering is an engineering
branch associated with development of
m
.co
software product using well-defined
nt
scientific principles, methods and
oi
lp
procedures. The outcome of software
ria
engineering is an efficient and reliable
to
Tu
software product.
Cs
Definition
IEEE defines software engineering as:
m
(1)The application of a
.co
systematic,disciplined,quantifiable
nt
oi
approach to the development, operation
lp
ria
and maintenance of software; that is, the
to
application of engineering to software.
Tu
(2) The study of approaches as in (1).

Cs
SDLC
 Software Development Life Cycle, SDLC
for short, is a well-defined, structured
m
.co
sequence of stages in software
nt
engineering to develop the intended
oi
lp
software product.
ria
to
Tu
Cs
m
.co
nt
oi
lp
ria
to
Tu
Cs
Software Development Life Cycle
m
.co
nt
oi
lp
ria
to
Tu
Cs
Communication
 This is the first step where the user

initiates the request for a desired
m
.co
software product. He contacts the service
nt
provider and tries to negotiate the terms.
oi
lp
He submits his request to the service
ria
providing organization in writing.
to
Tu
Cs
Requirement Gathering
 The requirements are collected using a
m
number of practices as given -
.co
 studying the existing or obsolete system
nt
oi
and software,
lp
ria
 conducting interviews of users and
to
developers,
Tu
Cs
 referring to the database or

 collecting answers from the
questionnaires.
Feasibility Study
 After requirement gathering, the team comes

up with a rough plan of software process. At
m
.co
this step the team analyzes if a software can
nt
be made to fulfill all requirements of the user
oi
and if there is any possibility of software
lp
ria
being no more useful. It is found out, if the
to
project is financially, practically and
Tu
technologically feasible for the organization

Cs
to take up. There are many algorithms

available, which help the developers to
conclude the feasibility of a software project.
System Analysis
 At this step the developers decide a roadmap

of their plan and try to bring up the best
m
.co
software model suitable for the project.
nt
System analysis includes Understanding of
oi
software product limitations, learning system
lp
ria
related problems or changes to be done in
to
existing systems beforehand, identifying and
Tu
addressing the impact of project on

Cs
organization and personnel etc. The project

team analyzes the scope of the project and
plans the schedule and resources accordingly.
Software Design
 Next step is to bring down whole knowledge

of requirements and analysis on the desk and
m
.co
design the software product. The inputs from
nt
users and information gathered in
oi
requirement gathering phase are the inputs of
lp
ria
this step. The output of this step comes in the
to
form of two designs; logical design and
Tu
physical design. Engineers produce meta-

Cs
data and data dictionaries, logical diagrams,

data-flow diagrams and in some cases
pseudo codes.
Coding
 The goal of coding phase is to translate
the design of the system into code in a
m
.co
given programming language.
nt
oi
lp
ria
to
Tu
Cs
Testing
 The basic function of testing is to detect
errors in the software
m
.co
 The goal of testing is to uncover
nt
requirement ,design and coding erros in
oi
lp
the programs.
ria
to
Tu
Cs
Implementation
 This means installing the software on user
m
machines. At times, software needs post-
.co
installation configurations at user end.
nt
oi
Software is tested for portability and
lp
adaptability and integration related issues
ria
to
are solved during implementation.
Tu
Cs
Maintenance
 It is an important part of SDLC
m
 If there is any error or change is needed
.co
in the system then it is part of
nt
maintenance.
oi
lp
ria
 The cost of maintenance is more than the
to
cost of development.
Tu
Cs
Types of Maintenance
❑Corrective maintenance
m
❑Adaptive maintenance
.co
❑Perfective maintenance
nt
oi
❑Preventive maintenance
lp
ria
to
Tu
Cs
Software Development Paradigm
 The software development paradigm helps
m
developer to select a strategy to develop
.co
the software. A software development
nt
oi
paradigm has its own set of tools, methods
lp
and procedures, which are expressed
ria
to
clearly and defines software development
Tu
life cycle. A few of software development

Cs
paradigms or process models are defined

as follows:
Process Model
 To solve actual problem in an industry a team of
software engineers must incorporate a development
m
.co
strategy that encompasses the process,methods,tools
nt
this strategy is called process model.
oi
 S/W process Model is an abstract representation of
lp
ria
S/W process.to
 S/W processes are categorized into three phases:
Tu
Definition phase, Development phase and support

Cs
phase.
 Process model depends on the nature of software.
Process models
 Waterfall model
m
 Evolutionary model
.co
1. Prototype model
nt
oi
2. Spiral model
lp

ria
Iterative model
to
Incremental model
Tu

Cs
Waterfall model/Linear
sequential/Classic life cycle
m
.co
 Waterfall model is the simplest process model .
nt
oi
 Proposed by ROYCE.
lp
ria
 It consists of all the phases of SDLC.
to
 Phases organized in linear order that’s why it is
Tu
called linear sequential model.

Cs
m
.co
nt
oi
lp
ria
to
Tu
Cs
Feasibility Report
m
Design
.co
Document
nt
oi
lp
coding Testing and
verification ria integration
to
program
Tu
Cs
Operation and
installation
maintenance
Installation report
When to use
 Requirements are very well known, clear
m
and fixed.
.co
 Product definition is stable.
nt
oi
 Technology is understood.
lp
ria
 There are no ambiguous requirements.
to
Tu
 Ample resources are available.

Cs
 Project is short.
Advantages
 It is the simplest model.
m
 Best for straight line development.
.co
 It encompasses all stages of sdlc.
nt
oi
 It divides the task into clearly defined
lp
phases. ria
to
Tu
 Costly and slow but satisfies all the

Cs
requirements of user.
Disadvantages
 Customer needs a lot of patience.
m
 It is difficult for a customer to state all the
.co
requirements explicitly.
nt
 Real project rarely follow this model.
oi
lp
 Costly and slow.
ria
to
Tu
Cs
Example: automobile companies who make cars

or bikes.
Prototype model
m
.co
nt
oi
lp
ria
to
Tu
Cs
Definition
 The goal of prototype model is to build a
prototype that help to understand the
m
requirements.
.co
nt
 Prototype is build on the basis of current
oi
requirement.
lp
ria
 Client can get an actual feel of the system by
to
using prototype.
Tu
 It gives better idea to understand the

Cs
requirements of the desired system.

 Generally used for large and complicated
system.
Types of prototype model
 Throwaway prototype
m
.co
nt
oi
lp
ria
to
Tu
 Evolutionary prototype
Cs
When to use
 When customer is clueless about detailed
requirements of the system.
m
.co
 When it requires a lot of interaction with user.
nt
 Customer is freely available to provide feedback
oi
lp
of the prototype.
ria
to
Tu
Cs
Advantages
 It does not require complete set of specification
or requirement before the development of
m
.co
software begins.
nt
oi
lp
 When the customer is clueless this model is
ria
perfect to develop the quality software.
to
Tu
Cs
Disadvantages
 The developer makes implementation
compromise.
m
.co
nt
 Needs a lot of interaction between client and
oi
lp
developer.
ria
to
Tu
 This model may increase the complexity of the

Cs
system as scope of the system may expand

beyond original plan.
Spiral model
 Proposed by Barry Boehm.
m
.co
 Spiral model is divided into a set of
nt
oi
framework activities defined by s/w
lp
ria
engineering team.
to
Tu
Cs
 These activities are called task region.
m
.co
nt
oi
lp
ria
to
Tu
Cs
When to use?
 When cost and risk evaluation is
m
important.
.co
 For medium to high risk projects.
nt
oi
 Users are unsure about their needs.
lp
ria
 Requirements are complex.
to
Tu
 New product line.

Cs
 Significant changes are expected.
Advantage
 Realistic approach.
m
 Customer and developer better understand and
.co
reacts to the risk at each evolutionary level.
nt
 Use prototype as risk reduction mechanism.
oi
lp
 It maintains the systematic approach like
ria
waterfall model as well as incorporating
to
Tu
iterative framework that are realistically reflects

Cs
the real world.

 No distinction between development and
maintenance.
Disadvantage
 Time consuming approach.
m
 Needs greater communication between
.co
developer and customer.
nt
oi
lp
ria
to
Tu
Cs
Incremental model
m
.co
nt
oi
lp
ria
to
Tu
Cs
When to use?
 Requirements are clearly understood.
m
.co
 Major requirements are known some are evolve
nt
over time.
oi
lp

ria
There is a need to get a product in market early.
to
Tu
Cs
 New technology being used.
 Resources with needed skills are not available.
Advantages
 Flexible and less costly.
m
 Easier to test and debug.
.co
 Customer respond to each built.
nt
oi
lp
ria
to
Tu
Cs
Disadvantage
 Needs good planning and design.
m
 Total cost is high.
.co
nt
oi
lp
ria
to
Tu
Cs
Iterative model
m
.co
nt
oi
lp
ria
to
Tu
Cs
m
.co
nt
oi
lp
ria
to
Tu
Cs
 Knowledge engineering is a field of artificial
intelligence(AI) that creates rules to apply to
data to imitate the thought process of a human
expert. It looks at the structure of a task or a
m
decision to identify how a conclusion is reached.
.co
nt
oi
 In its initial form, knowledge engineering
lp
focused on the transfer process; transferring the
ria
to
expertise of a problem-solving human into a
Tu
program that could take the same data and make

Cs
the same conclusions.
End user development
 End-user development (EUD) or end-user
programming (EUP) refers to activities and tools that
m
allow end-users – people who are not professional
.co
software developers – to program computers. People
nt
who are not professional developers can use EUD tools
oi
lp
to create or modify software artifacts (descriptions of
ria
automated behavior) and complex data objects without
to
significant knowledge of a programming language.
Tu
Examples include natural language programming,

Cs
spreadsheets.
Software Requirements
 A requirement is a feature of the system or a description
of something the system is capable of doing in order to
m
fulfill the system’s purpose.
.co
nt
oi
Types of requirement
lp
ria
to
•Those that should be absolutely met.
Tu
•Those that are highly desirable but not necessary.

Cs
•Those that are possible but could be eliminated.
Software Requirements
Broadly software requirements should be categorized in
two categories:
m
1. Functional Requirements: Requirements, which are
.co
related to functional aspect of software fall into this
nt
category. Like I/O format, storage structure
oi
,computational capabilities, timing and synchronization
lp
ria
to
2. Non-Functional Requirements: Requirements, which
Tu
are not related to functional aspect of software, fall into

Cs
this category. They are implicit or expected

characteristics of software, which users make
assumption of.
 Non-functional requirements include -
 Security
 Portability
m
.co
 Performance
nt
 Interoperability
oi
 Flexibility
lp
ria
 Accessibilityto
 Usability
Tu
 Efficiency
Cs
 Reliability
m
.co
nt
oi
lp
ria
to
Tu
Cs
Software analysis
 Software requirement specification(SRS):
IEEE defines a requirement as
m
“(1)A condition of capability needed by a user to solve
.co
a problem or achieve an objective.
nt
(2) A condition or a capability that must be met or
oi
possessed by a system to satisfy a
lp
ria
contract,standard,specification or other formally
imposed document”
to
Tu
Cs
 The goal of requirement activity is to produce the

SRS that describes what the proposed software
should do without describing how the software will
do it.
Need of SRS
 Basic purpose of SRS is to bridge the
communication gap between client and
m
.co
developer.
nt
oi
Advantage of SRS
lp
ria
to
1. It is an agreement between user and developer.
Tu
2. It provides reference for validation of the final

Cs
product.
3. High quality SRS is prerequisite to high quality
S/W.
4. High quality SRS reduces the development cost.
Characteristics of an SRS
1. Correct
m
2. Complete
.co
3. Unambiguous
nt
oi
4. Verifiable
lp
ria
5. Consistent
to
6. Ranked for importance
Tu
7. Modifiable
Cs
8. Traceable
Components of SRS
 Functional requirements :- Functional
requirements specify what output should be
m
.co
produced from the given inputs. So they
nt
basically describe the connectivity between the
oi
input and output of the system.
lp
ria
to
Tu
 Performance requirements :- Performance
Cs
requirements are typically expressed as

processed transactions per second or response
time from the system for a user event or screen
refresh time or a combination of these.
 Design constraints: The client environment may restrict
the designer to include some design constraints that
must be followed. The various design constraints are
standard compliance, resource limits, operating
environment, reliability and security requirements and
m
.co
policies that may have an impact on the design of the
system. An SRS should identify and specify all such
nt
oi
constraints.
lp
 ria
External interface requirements: All the possible
to
Tu
interactions of the software with people hardware and
Cs
other software should be clearly specified.
m
.co
nt
oi
lp
ria
to
Tu
Cs
Specification Tools
 Flow based- DFD
m
 Data based
.co
nt
oi
lp
ria
to
Tu
Cs
Data Flow Diagram
 Data flow diagram is graphical representation of flow of
m
.co
data in an information system. It is capable of mention
of depicting incoming data flow, outgoing data flow and
nt
oi
stored data. There is a prominent difference between
lp
DFD and Flowchart. The flowchart depicts flow of
ria
control in program modules. DFDs depict flow of data
to
in the system at various levels. DFD does not contain
Tu
any control or branch elements.

Cs
Types of DFD
Data Flow Diagrams are either Logical or Physical.
m
.co
 Logical DFD : This type of DFD concentrates on the
nt
system process, and flow of data in between the system .
oi
For example in a Banking software system, how data is
lp
moved between different entities.
ria
to
Tu
 Physical DFD: This type of DFD shows how the data

Cs
flow is actually implemented in the system. It is more

specific and close to the implementation.
DFD Components
m
.co
nt
 Entities - Entities are source and destination of
oi
information data. Entities are represented by a
lp
ria
rectangles with their respective names.
to
Tu
Cs
 Process - Activities and action taken on the data

are represented by Circle or Round-edged
rectangles.
 Data Storage - There are two variants of data
storage - it can either be represented as a
rectangle with absence of both smaller sides or
m
.co
as an open-sided rectangle with only one side
nt
missing.
oi
lp

ria
Data Flow - Movement of data is shown by
to
Tu
pointed arrows. Data movement is shown from
Cs
the base of arrow as its source towards head of

the arrow as destination.
Levels of DFD
 Level 0- Highest abstraction level DFD is known as
Level 0 DFD, which depicts the entire information
m
system as one diagram concealing all the underlying
.co
details. Level 0 DFDs are also known as context level
nt
DFDs.
oi
lp
ria
Online shopping system
to
Tu
delivery
order
Cs
customers
Level 1 DFD
m
 The Level 0 DFD is broken down into more specific, Level
.co
1 DFD. Level 1 DFD depicts basic modules in the system
nt
and flow of data among various modules. Level 1 DFD
oi
lp
also mentions basic processes and sources of information.
ria
to
Tu
Cs
m
.co
nt
oi
lp
ria
to
Tu
Cs
Data Dictionary
 The data dictionary is centralized repository of
information about such a meaning relationship
m
to other data,origin,usage and format. Data
.co
dictionary is read only set of tables that provide
nt
oi
information about the data base. Data dictionary
lp
manages metadata(database about database).
ria
to
Tu
 Data Dictionary contains:-

Cs
1) Definition of all schema object in the

database(table,views,indexes,clusters,synonym
s,procedure,functions,triggers)
2) How much space has been allocated for and is
currently used by schema object.
m
.co
3) Default value for columns.
nt
Integrity constraint information.
oi
4)
lp
5) Names of users.
ria
to
6) Privileges and roles each user has been
Tu
granted.
Cs
7) Auditing information such as who has

accessed.
Data Dictionary files
1) Field’s File
m
.co
FIELD NAME TYPE SIZE
Rollno Number 5
nt
oi
Name Text 10
lp
Courseid Number 5
ria
to
Tu
2) File’s File
Cs
FIELD NAME SIZE

Student 200
Course 300
Data dictionary are of two types
 Active data dictionary:- Managed automatically by the
m
DBMS . Maintained by system itself.
.co
nt
oi
 Passive data dictionary:-Also called non integrated
lp
data dictionary used only for documentation purpose .
ria
Managed by users of the system and modified whenever
to
the db changed.
Tu
Cs
OOAD - Object Oriented Analysis
 In the system analysis or object-oriented
analysis phase of software development,
m
.co
the system requirements are determined,
nt
the classes are identified and the
oi
relationships among classes are identified.
lp
ria
 The three analysis techniques that are
to
Tu
used in conjunction with each other for
Cs
object-oriented analysis are object

modelling, dynamic modelling, and
functional modelling.
Object modeling
Object modeling develops the static
m
structure of the software system in terms
.co
of objects. It identifies the objects, the
nt
oi
classes into which the objects can be
lp
grouped into and the relationships
ria
to
between the objects. It also identifies the
Tu
main attributes and operations that

Cs
characterize each class.
The process of object modeling can be
visualized in the following steps −
Identify objects and group into classes
m

.co
 Identify the relationships among classes
nt
oi
 Create user object model diagram
lp
ria
 Define user object attributes
to
Tu
 Define the operations that should be

Cs
performed on the classes.
Dynamic Modeling
Dynamic Modeling can be defined as “a
m
way of describing how an individual
.co
object responds to events, either internal
nt
oi
events triggered by other objects, or
lp
external events triggered by the outside
world”. ria
to
Tu
Cs
The process of dynamic modeling can be
 Identify states of each object.
m
 Identify events and analyze the
.co
applicability of actions.
nt
oi
 Construct dynamic model diagram,
lp
ria
comprising of state transition diagrams.
to
 Express each state in terms of object
Tu
Cs
attributes.
 Validate the state–transition diagrams
drawn.
Functional Modeling
 Functional Modeling is the final component of
object-oriented analysis. The functional model
m
.co
shows the processes that are performed within
nt
an object and how the data changes as it moves
oi
between methods. It specifies the meaning of the
lp
ria
operations of object modeling and the actions of
to
dynamic modeling. The functional model
Tu
corresponds to the data flow diagram of

Cs
traditional structured analysis.
The process of functional modeling can be
 Identify all the inputs and outputs.
 Construct data flow diagrams showing
m
functional dependencies.
.co
nt
 State the purpose of each function.
oi
 Identify constraints.
lp
ria
 Specify optimization criteria.
to
Tu
Cs

Software Engineering

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

Software Engineering

(1) Instructions (computer programs) that

(3) Descriptive information in both hard

copy and virtual forms that describes the

IEEE defines “Software is the collection

executable programming code, associated

libraries and documentations. Software,

different from hardware: Software

Slowly, the minimum failure rate level begins

to rise—the software is deteriorating due to

(2) The study of approaches as in (1).

 This is the first step where the user

 The requirements are collected using a

 referring to the database or

 After requirement gathering, the team comes

technologically feasible for the organization

to take up. There are many algorithms

 At this step the developers decide a roadmap

addressing the impact of project on

organization and personnel etc. The project

 Next step is to bring down whole knowledge

physical design. Engineers produce meta-

data and data dictionaries, logical diagrams,

 This means installing the software on user

 The software development paradigm helps

life cycle. A few of software development

paradigms or process models are defined

Definition phase, Development phase and support

called linear sequential model.

 Ample resources are available.

 It is the simplest model.

 Costly and slow but satisfies all the

 Customer needs a lot of patience.

Example: automobile companies who make cars

 It gives better idea to understand the

requirements of the desired system.

 This model may increase the complexity of the

system as scope of the system may expand

 Proposed by Barry Boehm.

 These activities are called task region.

 New product line.

 Significant changes are expected.

iterative framework that are realistically reflects

the real world.

 Time consuming approach.

 Requirements are clearly understood.

 New technology being used.

 Resources with needed skills are not available.

 Flexible and less costly.

 Needs good planning and design.

program that could take the same data and make

the same conclusions.

Examples include natural language programming,

•Those that are highly desirable but not necessary.

•Those that are possible but could be eliminated.

are not related to functional aspect of software, fall into

this category. They are implicit or expected

 The goal of requirement activity is to produce the

2. It provides reference for validation of the final

requirements are typically expressed as

other software should be clearly specified.

 Data flow diagram is graphical representation of flow of

any control or branch elements.