Cse 320

Lecture Zero
Software Engineering
CSE320
CSE320 : CSE
Course details
• LTP – 3 0 0 [Three lectures/week]
• Text Book
FUNDAMENTALS OF SOFTWARE ENGINEERING by RAJIB
MALL, PHI (PRETICE HALL INDIA),
CSE320 : CSE
Course Assessment Model
• Marks break up*
• Attendance 5
• CA (3 online Assignments) 25
• MTT 20
• ETE 50
• Total 100
CSE320 : CSE
Detail of Academic Tasks
• AT1: Online Assigment1
**** 2 best out of three****
CSE320 : CSE
MTT and ETT
• MTT:-- All MCQs
• ETT:-- MCQs
CSE320 : CSE
Course Outcomes
• Plan and deliver an effective software engineering
process, based on knowledge of widely used
development life cycle models.
• Work effectively in a team to analyze the requirements
of a complex software system and solve problems by
creating appropriate designs that satisfies these
requirements.
• Translate a requirements specification into an
implementable design, following a structured and
organized process.
CSE320 : CSE
Course Outcomes
• Formulate a testing strategy for a software system,
employing test case design techniques such as
functional and structural testing.
• Manage a project including planning, scheduling,

estimation and configuration management.
• Recognize current trends in the area of software

engineering.
CSE320 : CSE
The course contents
• Introduction to software engineering : Before MTE
Evolution and impact of software engineering, Software life cycle
models, Feasibility study, Functional and non-functional requirements,
Requirement gathering, Requirement analysis and specification
• Issues in software design : cohesion, coupling, DFDs
• Object modelling :
Object modelling using UML, Object oriented software
development, User interface design, Coding standards and code
review techniques
CSE320 : CSE
The course contents
• Testing : After MTE
Fundamentals of testing, White box and black box testing, Test coverage
analysis and test case design techniques, Mutation testing, Static and
dynamic analysis, Software reliability metrics, Reliability growth
modelling.
• Software project management :
Project management, Project planning and control, Cost
estimation, Project scheduling using PERT and GANTT
charts, Software Configuration Management
• Quality management :
Quality management, ISO and SEI CMMI, PSP and Six sigma,
Software Maintenance, reuse, CBSD, CASE, Advance topics
of Software Engineering.
CSE320 : CSE
The hitch…
The three BURNING questions in mind…
• What is software? Is it different from Program?
• What is Software Engineering?
• Why Software Engineering?
• What are learning outcomes?
CSE320 : CSE
What is software?
❑ Computer programs and associated documentation
❑ Software products may be developed for a particular customer or

may be developed for a general market.
❑ Software products may be
1. Generic - developed 2. Bespoke - developed
to be sold to a range for a single customer
of different according to their
customers specification
CSE320 : CSE
What is software engineering?
Software engineering is an engineering discipline which is
concerned with all aspects of software production
Software engineers should

• adopt a systematic and organised approach to their work
• use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
• the resources available
CSE320 : CSE
Phases of Development
CSE320 : CSE
The Role of Software Engineering-1
A bridge from customer needs to programming implementation
Programmer
Customer
First law of software engineering

Software engineer must learn the problem domain (problem cannot be solved without understanding it first)
CSE320 : CSE
The Role of Software Engineering-2
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction with the environment
in a specified manner
System-to-be
Environment
Software-to-be
User
Software Engineer’s task:

To understand how the system-to-be needs to interact with
the user or the environment so that customer’s requirement is met
and design the software-to-be
May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer
CSE320 : CSE
Example: ATM Machine
Understanding the money-machine problem:
1
7
4
0
2
5 3
8 6
9
Communication link
Bank’s
remote
ATM machine
datacenter
Bank
customer
CSE320 : CSE
How ATM Machine Might Work
Domain model Domain Model
created with help of
domain expert
Transaction
How may I record
help you? Cash
Bookkeeper
Speakerphone Safe
Safe keeper
Phone
Window clerk
Datacenter
liaison
Dispenser
Bank’s
remote
datacenter
CSE320 : CSE Customer
Cartoon Strip: How ATM Machine Works?
CSE320 : CSE
Software Engineering Blueprints
➢Specifying software problems and solutions is like cartoon strip

writing
➢Unfortunately, most of us are not artists, so we will use something
less exciting:
Designing symbols
➢However …
CSE320 : CSE
Second Law of Software Engineering
• Software should be written for people first
• ( Computers run software, but hardware quickly becomes outdated )
• Useful + good software lives long
• To nurture software, people must be able to understand it
CSE320 : CSE
Software Development Methods
➢Method = work strategy

▪ The Feynman Problem-Solving Algorithm:
(i) Write down the problem (ii) think very hard, and (iii) write down the answer.
➢Waterfall
▪ Unidirectional, finish this step before moving to the next
➢Iterative + Incremental
▪ Develop increment of functionality, repeat in a feedback loop
➢Agile
▪ User feedback essential; feedback loops on several levels of granularity
CSE320 : CSE
Software Development Methodologies
CSE320 : CSE
Waterfall Method
Unidirectional, no way back finish this step before moving to the next
CSE320 : CSE
Software myths
1. “If we get behind schedule, we can just add more people”
❑Fact: Adding people to a late project makes it even later.
❑Someone has to teach the new people.
2. “A general statement of objectives is enough to start programming”.
❑Fact: Incomplete requirements are a major cause for project failures.
3. “Changes in requirements are easy to deal with because software is
flexible”.
❑Fact: Changes are hard and expensive.
❑Especially during coding and after software deployment.
CSE320 : CSE
Software myths
4. “Once we get the program running, we are done”

❑ Fact: Most effort comes after the software is delivered for the first
time.
❑ Bug fixes, feature enhancements, etc
5. “The only product is the running program”

❑ Fact: Need the entire configuration
❑ Documentation of system requirements, design, programming,
and usage
CSE320 : CSE
Software crises
• The various software crises are:

1. Over-budget.
2. Not delivering product on time.
3. Product is of poor quality.
4. Software product is not meeting the customer
requirements.
CSE320 : CSE
What are the attributes of good software?
The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable
• Maintainability
• Software must evolve to meet changing needs
• Dependability
• Software must be trustworthy
• Efficiency
• Software should not make wasteful use of system resources
• Usability
• Software must be usable by the users for which it was designed
CSE320 : CSE
Next Class: Software Life Cycle Models
www.lpu.in
•CSE320 : CSE
SOFTWARE
ENGINEERING
1
What is Software Engineering?
• Engineering approach to develop

software.
• Systematic collection of past
experience:
−techniques,
−methodologies,
−guidelines.
2
Programs versus Software
Products
• Usually small in size • Large

• Author himself is sole • Large number of
user users
• Single developer • Team of developers
• Lacks proper user • Well-designed
interface interface
• Lacks proper • Well documented &
documentation user-manual prepared
• Ad hoc development. • Systematic development
3
Software Complexity
4
Principle of Abstraction
• The principle of abstraction

implies that a problem can be
simplified by omitting irrelevant
details.
5
Hierarchy of Abstraction
6
Decomposition
• In this technique,
a complex problem
is divided in
several small
problems and then
small problems are
solved one by one.
7
Software Crisis
• Software products:
−fail to meet user requirements.
−frequently crash.
−expensive.
−difficult to alter, debug, and
enhance.
−often delivered late.
−use resources non-optimally.
8
Factors contributing to the
software crisis
• Larger problems,
• Lack of adequate training in
software engineering,
• Increasing skill shortage,
• Low productivity improvements.
9
Evolution of Technology
with Time
10
Evolution of Other Software
Engineering Techniques
−life cycle models,

−specification techniques,
−project management techniques,
−testing techniques,
−debugging techniques,
−quality assurance techniques,
−software measurement
techniques,
−CASE tools, etc. 11
Differences between the exploratory
style and modern software
development practices
• Use of Life Cycle Models

• Software is developed through
several well-defined stages:
−requirements analysis and
specification,
−design,
−coding,
−testing, etc.
12
development practices
• Emphasis has shifted

− from error correction to error
prevention.
• Modern practices emphasize:
−detection of errors as close to
their point of introduction as
possible.
13
style and modern software development
practices
14
development practices (CONT.)
• In exploratory style,
−errors are detected only during
testing,
• Now,
− focus is on detecting as many
errors as possible in each
phase of development.
15
• During all stages of
development process:
−Periodic reviews are being carried
out
• Software testing has become
systematic:
−standard testing techniques are
available.
16
• Projects are being thoroughly

planned:
− estimation,
− scheduling,
− monitoring mechanisms.
• Use of CASE tools.
17
EMERGENCE OF
SOFTWARE ENGINEERING
18
Control Flow-based Design
• Flow Charting
Technique:
− to write cost-
effective and correct
programs.
− to represent and
design algorithms.
− easier to develop
and understand.
19
Example: Control Flow-
based Design
Unstructured Program Structured Program

Program having a messy flow chart
representation would indeed be difficult to
understand and debug.
20
Data Structure-oriented
Design
• Need of Data Structure-oriented

Design:
− with the advent of integrated circuits (ICs)
− to solve more complex problems.
• Data structure- oriented design
techniques :
− design data structures of program then
design the code structure
21
Data Flow-oriented Design
• Data flow-oriented techniques:

− major data items must be identified.
− Data is represented in DFDs (Data Flow
Diagrams)
• Need of Data Flow-oriented Design
− For very large scale integrated (VLSI) Circuits
− For new architectural concepts, complex and
sophisticated software
22
Example: Data Flow-oriented
Design
Data Flow diagram of Car Assembly Plant
23
Object-Oriented Design (80s)
• Object-oriented technique:
−natural objects (such as employees,
pay-roll-register, etc.) occurring in
a problem are first identified.
• Relationships among objects:
−such as composition, reference,
and inheritance are determined.
24
Life Cycle Model
• A software life cycle model (or
process model):
− a descriptive and diagrammatic model
of software life cycle:
− identifies all the activities required for
product development,
− establishes a precedence ordering among
the different activities,
− Divides life cycle into phases.
25
SDLC
26
SDLC Phases
• Planning and Requirement analysis.

• Defining Requirements
• Designing the Software
• Building or Developing the Software
• Testing the Software
• Deployment and Maintenance
27
Why Model Life Cycle ?
• A written description:
− forms a common understanding of
activities among the software
developers.
− helps in identifying inconsistencies,
redundancies in the development
process.
28
Life Cycle Model (CONT.)
• The development team must

identify a suitable life cycle model:
− and then adhere to it.
− Primary advantage of adhering to a
life cycle model:
 helps development of software in a
systematic and disciplined manner.
29
• When a software product is being

developed by a team:
− there must be a precise understanding
among team members as to when to
do what,
− otherwise it would lead to and project
failure.
30
• A life cycle model:

−defines entry and exit criteria for
every phase.
−A phase is considered to be
complete:
only when all its exit criteria's are
satisfied.
31
• The phase exit criteria for the software

requirements specification phase:
− Software Requirements Specification (SRS)
document is complete, reviewed, and
approved by the customer.
• A phase can start:
− only if its phase-entry criteria have been
satisfied.
32
• It becomes easier for software

project managers:
−to monitor the progress of the
project.
33
• Many life cycle models have been

proposed.
• We will confine our attention to a few
important and commonly used models.
− classical waterfall model
− iterative waterfall,
− evolutionary,
− prototyping, and
− spiral model
34
SOFTWARE ENGINEERING
1
CLASSICAL
WATERFALL MODEL
2
Classical Waterfall Model
• Classical waterfall model divides
life cycle into phases:
− feasibility study,
− requirements analysis and
specification,
− design,
− coding and unit testing,
− integration and system testing,
− maintenance.
3
Feasibility Study
Req. Analysis
Design
Coding
Testing
Maintenance
4
(CONT.)
• Most organizations usually define:

− entry and exit criteria for every phase.
• They also prescribe specific
methodologies for:
− specification,
− design,
− testing,
− project management, etc.
5
Why to study Waterfall
Model?
• Every other model is based on

Waterfall Model.
• To develop an understanding
toward various phases of
software development.
6
(CONT.)
7
Feasibility Study
• Main aim of feasibility study:determine whether
developing the product
− financially worthwhile
− technically feasible.
• First roughly understand what the customer
wants:
− different data which would be input to the system,
− processing needed on these data,
− output data to be produced by the system,
− various constraints on the behavior of the system.
8
Activities during Feasibility
Study
• Work out an overall understanding
of the problem.
• Formulate different solution
strategies.
• Examine alternate solution
strategies in terms of:
 resources required,
 cost of development, and
 development time.
9
Activities during Feasibility
Study
• Perform a cost/benefit analysis:
− to determine which solution is the
best.
− you may determine that none of
the solutions is feasible due to:
 high cost,
 resource constraints,
 technical reasons.
10
Requirements Analysis and
Specification
• Aim of this phase:
− understand the exact
requirements of the customer,
− document them properly.
• Consists of two distinct
activities:
− requirements gathering and
analysis
− requirements specification. 11
Goals of Requirements
Analysis
• Collect all related data from the
customer:
− analyze the collected data to
clearly understand what the
customer wants,
− find out any inconsistencies and
incompleteness in the
requirements,
− resolve all inconsistencies and
incompleteness. 12
Requirements Gathering
• Gathering relevant data:

− usually collected from the end-
users through interviews and
discussions.
− For example, for a business
accounting software:
 interview all the accountants of the
organization to find out their
requirements.
13
Requirements Analysis (CONT.)
• The data you initially collect

from the users:
−would usually contain several
contradictions and
ambiguities:
−each user typically has only a
partial and incomplete view of
the system.
14
• Ambiguities and contradictions:

− must be identified
− resolved by discussions with the
customers.
• Next, requirements are organized:
− into a Software Requirements
Specification (SRS) document.
15
• Engineers doing
requirements analysis and
specification:
−are designated as analysts.
16
Requirements Specification
• Organizing requirement
analysis into SRS
• Important content of document
− Functional Requirements
− Non - Functional Requirements
− The goal of implementation
17
Design
• Design phase transforms
requirements specification:
− into a form suitable for
implementation in some
programming language.
18
Design
• In technical terms:
− during design phase, software
architecture is derived from the
SRS document.
• Two design approaches:
− traditional approach,
− object oriented approach.
19
Traditional Design Approach
• Consists of two activities:

−Structured analysis
−Structured design
20
Structured Analysis
Activity
• Identify all the functions to be
performed.
• Identify data flow among the
functions.
• Decompose each function
recursively into sub-functions.
− Identify data flow among the
subfunctions as well.
21
Structure Analysis (cont.)
22
Structured Analysis (CONT.)
• Carried out using Data flow

diagrams (DFDs).
• After structured analysis, carry
out structured design:
− architectural design (or high-level
design)
− detailed design (or low-level
design).
23
Structured Design
• High-level design:
− decompose the system into modules,
− represent relationships among the
modules.
• Detailed design:
− different modules designed in greater
detail:
 data structures and algorithms for each
module are designed.
24
Object Oriented Design
• First identify various objects (real

world entities) occurring in the
problem:
− identify the relationships among the
objects.
− For example, the objects in a pay-roll
software may be:
 employees,
 managers,
 pay-roll register,
 Departments, etc. 25
Object Oriented Design
26
Object Oriented Design (CONT.)
• Object structure
− further refined to obtain the
detailed design.
• OOD has several advantages:
− lower development effort,
− lower development time,
− better maintainability.
27
Implementation
• Purpose of implementation
phase (coding phase):
−translate software design into
source code.
28
Implementation
• During the implementation

phase:
− each module of the design is
coded,
− each module is unit tested
 tested independently as a stand
alone unit, and debugged,
− each module is documented.
29
Implementation (CONT.)
• The purpose of unit testing:

− test if individual modules work
correctly.
• The end product of
implementation phase:
− a set of program modules that
have been tested individually.
30
Integration and System
Testing
• Different modules are integrated in
a planned manner:
− modules are almost never integrated
in one shot.
− Normally integration is carried out
through a number of steps.
• During each integration step,
− the partially integrated system is
tested.
31
Integration and System
Testing
M1 M2
M3 M4
32
System Testing
• After all the modules have been

successfully integrated and
tested:
− system testing is carried out.
• Goal of system testing:
− ensure that the developed system
functions according to its
requirements as specified in the
SRS document. 33
Maintenance
• Maintenance of any
software product:
−requires much more effort than
the effort to develop the product
itself.
−development effort to
maintenance effort is typically
40:60.
34
Maintenance (CONT.)
• Corrective maintenance:
− Correct errors which were not discovered
during the product development phases.
• Perfective maintenance:
− Improve implementation of the system
− enhance functionalities of the system.
• Adaptive maintenance:
− Port software to a new environment,
 e.g. to a new computer or to a new operating system.
35
Drawbacks of classical
water fall model
• 1. no feedback paths
• 2. difficult to accommodate changes
• 3. No overlapping of phases
• 4. Limited customer interactions
36
Question
What is the first step in the software

development lifecycle?
a) System Design
b) Coding
c) System Testing
d) Preliminary Investigation and Analysis
37
Iterative Waterfall Model
• Classical waterfall model is
idealistic:
− assumes that no defect is
introduced during any
development activity.
− in practice:
 defects do get introduced in almost
every phase of the life cycle.
38
(CONT.)
• Defects usually get detected

much later in the life cycle:
−For example, a design defect might
go unnoticed till the coding or
testing phase.
39
(CONT.)
• Once a defect is detected:

− we need to go back to the phase
where it was introduced
− redo some of the work done during
that and all subsequent phases.
• Therefore we need feedback paths
in the classical waterfall model.
40
(CONT.)
Feasibility Study
Req. Analysis
Design
Coding
Testing
Maintenance
41
(CONT.)
• Errors should be detected

• in the same phase in which they are
introduced.
• For example:
• if a design problem is detected in
the design phase itself,
• the problem can be taken care of much
more easily than, if it is identified at the
end of the integration and system testing
phase.
42
Phase containment of
errors
• The principle of detecting errors as close to

its point of introduction as possible:
− is known as phase containment of errors.
• Iterative waterfall model is most widely
used model.
− Almost every other model is derived from the
waterfall model.
43
NEXT CLASS :
PROTOTYPING MODEL
44
FEASIBILITY
STUDY
1
Feasibility Study
To determine what the candidate

system is to do by defining its
expected performance.
Thus a feasibility study is carried out
to select the best system that meets
performance requirements
2
Types of Feasibility Study
Economic Feasibility
Technical Feasibility
Behavioral Feasibility
3
Economic Feasibility
Also known as cost benefit analysis

To determine the benefits and savings
that are expected from a candidate
system and compare them with costs.
If Benefits outweigh Costs, then the
decision is made to Design and Implement
the system.
4
Technical Feasibility
It checks whether the existing computer system

supports the candidate system or not or up to
what extent it supports.
It basically centers around Hardware, Software
etc.
For e.g. Current Computer is operating at 77 %
capacity and running another application can
Overload the system so need new system.
5
Behavioural Feasibility
An estimate should be made of how strong a

reaction the user staff is likely to have
towards the development of a computerized
system.
It is common knowledge that computer
installation have something to do with
Turnover, Transfers and changes in
employee Job Status.
For e.g. SBI Bank.
6
Steps in Feasibility Analysis
Form a project team and appoint a project

leader
Prepare system flowcharts
Enumerate potential candidate systems
Describe and identify characteristics of
candidate systems
7
Steps in Feasibility Analysis(cont.)
Determine and evaluate performance and

cost effectiveness of each candidate
system
Weight system performance and cost data
Select the best candidate system
Prepare and report final project directive
to management
8
Question
A feasibility study:
A. Includes a statement of the problems

B. Considers a single solutions
C. Both (a) and (b)
E. None of the above
9
Specification
Many projects fail:
because they start implementing
the system without determining
whether they are building what
the customer really wants.
10
Specification
Goals of requirements analysis and
specification phase:
fully understand the user requirements
remove inconsistencies, anomalies,
etc. from requirements
document requirements properly in an
SRS document
11
Specification
Consists of two distinct
activities:
Requirements Gathering and
Analysis
Specification
12
Specification
The person who undertakes
requirements analysis and specification:
known as systems analyst:
collects data pertaining to the product
analyses collected data:
to understand what exactly needs to be
done.
writes the Software Requirements
13
Specification
Final output of this phase:
Software Requirements
Specification (SRS) Document.
The SRS document is reviewed
by the customer.
reviewed SRS document forms the
basis of all future development
activities.
14
Analyst gathers requirements

through:
observation of existing systems,
studying existing procedures,
discussion with the customer and
end-users,
analysis of what needs to be
done, etc.
15
(CONT.)
In the absence of a working

system,
lot of imagination and creativity
are required.
Interacting with the customer to
gather relevant data:
requires a lot of experience.
16
(CONT.)
Some desirable attributes of

a good system analyst:
Good interaction skills,
imagination and creativity,
experience.
17
Question
System Study involves

A. Study of an existing system
B. Documenting the existing system.
C. Identifying current deficiencies and
establishing new goals
D. All of the above
18
Analysis of the Gathered
Requirements
After gathering all the requirements:

analyze it:
Clearly understand the user requirements,
Detect inconsistencies, ambiguities, and
incompleteness.
Incompleteness and inconsistencies:
resolved through further discussions
with the end-users and the customers.
19
Inconsistent requirement
Some part of the requirement:
contradicts with some other part.
Example:
One customer says turn off heater
and open water shower when
temperature > 100 C
Another customer says turn off
heater and turn ON cooler when
temperature > 100 C
20
Incomplete requirement
Some requirements have been

omitted:
due to oversight.
Example:
The analyst has not recorded:
when temperature falls below 90 C
heater should be turned ON
water shower turned OFF.
21
Requirements (CONT.)
Requirements analysis involves:

obtaining a clear, in-depth
understanding of the product to
be developed,
remove all ambiguities and
inconsistencies.
22
Several things about the project should

be clearly understood by the analyst:
What is the problem?
Why is it important to solve the problem?
What are the possible solutions to the
problem?
What complexities might arise while solving
the problem?
23
After collecting all data regarding

the system to be developed,
remove all inconsistencies and
anomalies from the requirements,
systematically organize requirements
into a Software Requirements
24
Software Requirements Specification
1
 Main aim of requirements

specification:
systematicallyorganize the
requirements arrived during
requirements analysis
document requirements properly.
Software Requirements Specification
2
 The SRS document is useful in

various contexts:
statement of user needs
contract document
reference document
definition for implementation
Software Requirements Specification: A Contract
Document
3
 Requirements document is a reference

document.
 SRS document is a contract between the
development team and the customer.
 Once the SRS document is approved by the customer,
 any subsequent controversies are settled by referring the SRS
document.
Software Requirements Specification: A Contract
Document
4
 Once customer agrees to the SRS

document:
 development team starts to develop the product
according to the requirements recorded in the
SRS document.
 The final product will be acceptable to the
customer:
 as long as it satisfies all the requirements
recorded in the SRS document.
SRS Document (CONT.)
5
 The SRS document is known as black-box

specification:
 the system is considered as a black box whose
internal details are not known.
 only its visible external (i.e. input/output)
behavior is documented.
Input Data Output Data
S
6
 SRS document concentrates on:

 what needs to be done
 carefully avoids the solution (“how to do”)
aspects.
 The SRS document serves as a contract
 between development team and the customer.
 Should be carefully written
7
 The requirements at this stage:

written using end-user terminology.
 If necessary:
latera formal requirement
specification may be developed from it.
Question
8
 The SRS document is also known as

________________ specification ?
A. black-box
B. white-box
C. grey-box
D. none of the mentioned
Properties of a good SRS document
9
 It should be concise
 and at the same time should not be ambiguous.
 It should specify what the system must do
 and not say how to do it.
 Easy to change.,
 i.e. it should be well-structured.
 It should be consistent.
 It should be complete.
Properties of a good SRS document
(cont...)
10
 It should be traceable
 you should be able to trace which part of the
specification corresponds to which part of the
design and code, etc and vice versa.
 It should be verifiable
11
 SRS document, normally

contains three important parts:
functional requirements,
nonfunctional requirements,
constraints on the system.
12
 It is desirable to consider every system:

 performing a set of functions {fi}.
 Each function fi considered as:
 transforming a set of input data to corresponding output
data.
Input Data Output Data

fi
Example: Functional Requirement
13
 F1: Search Book

 Input:
 an author’s name:
 Output:
 details of the author’s books and the locations of these books
in the library.
Author Name Book Details

f1
Functional Requirements
14
 Functional requirements describe:

A set of high-level requirements
 Each high-level requirement:
takesin some data from the user
outputs some data to the user
 Each high-level requirement:
might consist of a set of identifiable
functions
Functional Requirements
15
 For each high-level requirement:

every function is described in terms
of
input data set
output data set
processing required to obtain the output
data set from the input data set
Nonfunctional Requirements
16
 Characteristics of the system

which can not be expressed as
functions:
maintainability,
portability,
usability, etc.
Nonfunctional Requirements
17
 Nonfunctional requirements include:

 reliability issues,
 performance issues,
 human-computer interface issues,
 Interface with other external systems,
 security, maintainability, etc.
Constraints
18
 Constraints describe things that the system

should or should not do.
 For example,
 how fast the system can produce results
so that it does not overload another
system to which it supplies data, etc.
Examples of constraints
19
 Hardware to be used,
 Operating system
 or DBMS to be used
 Capabilities of I/O devices

 Standards compliance
 Data representations
 by the interfaced system
Question
20
 Which of the following is not defined in a good

Software Requirement Specification (SRS)
document?
a) Functional Requirement
b) Non-functional Requirement
c) Constraints on the system
d) Algorithm for software implementation
Examples of Bad SRS Documents
21
 Unstructured Specifications:
 Narrative essay --- one of the worst types of specification
document:
 Difficult to change,
 difficult to be precise,
 difficult to be unambiguous,
 scope for contradictions, etc.

Organization of the SRS Document
22
 1. Introduction to the Document
 1.1 Purpose of the Product
 1.2 Scope of the Product
 1.3 Acronyms, Abbreviations, Definitions
 1.4 References
 1.5 Outline of the rest of the SRS
 2. General Description of Product
 2.1 Context of Product
 2.2 Product Functions
 2.3 User Characteristics
 2.4 Constraints
 2.5 Assumptions and Dependencies
 3. Specific Requirements
 3.1 External Interface Requirements
 3.1.1 User Interfaces
 3.1.2 Hardware Interfaces
 3.1.3 Software Interfaces
 3.1.4 Communications Interfaces
Organization of the SRS Document(contd)
23
 3.2 Functional Requirements

 3.2.1 Class 1
 3.2.2 Class 2
 …
 3.3 Performance Requirements
 3.4 Design Constraints
 3.5 Quality Requirements
 3.6 Other Requirements
 4. Appendices
24
Thank you
Evolutionary Model
Evolutionary Model
Evolutionary model:
◦ The system is broken down into several modules which
can be incrementally implemented and delivered.
First develop the core modules of the system.
The initial product skeleton is refined into
increasing levels of capability:
◦ by adding new functionalities in successive versions.
2
Evolutionary Model (CONT.)
Successive version of the product:

◦functioning systems capable of performing
some useful work.
◦A new release may include new
functionality:
◦ also existing functionality in the current release
might have been enhanced.
3
Evolutionary Model (CONT.)
A A A
B B
4
Version n
Design
Code Final
Test software
Version n-1 Deploy
Requirement
Specification Design
Version 2 Code
Test
Deploy
Version 1
Design
Code
Test
Deploy
Advantages of Evolutionary Model
Users get a chance to experiment with a partially developed

system:
◦ much before the full working version is released,
Helps finding exact user requirements:
◦ much before fully working system is developed.
Core modules get tested thoroughly:
◦ reduces chances of errors in final product.
6
Disadvantages of Evolutionary
Model
Often, difficult to subdivide problems into
functional units:
◦which can be incrementally implemented and
delivered.
◦evolutionary model is useful for very large problems,
◦ where it is easier to find modules for incremental
implementation.
7
Question
Evolutionary Model are:
A) Iterative
B) Non Linear
C) Non Repetitive
D) Discontinues
Evolutionary Model with Iteration
Many organizations use a combination of

iterative and incremental development:
◦a new release may include new functionality
◦existing functionality from the current release may
also have been modified.
9
Evolutionary Model with iteration
Several advantages:
◦ Training can start on an earlier release
◦ customer feedback taken into account
◦ Markets can be created:
◦ for functionality that has never been offered.
◦ Frequent releases allow developers to fix unanticipated
problems quickly.
10
Spiral Model
Spiral Model
Proposed by Boehm in 1988.
Each loop of the spiral represents a phase of the software
process:
◦ the innermost loop might be concerned with system feasibility,
◦ the next loop with system requirements definition,
◦ the next one with system design, and so on.
There are no fixed phases in this model, the phases shown in the
figure are just examples.
12
Spiral Model (CONT.)
The team must decide:

◦ how to structure the project into phases.
Start work using some generic model:
◦ add extra phases
◦ for specific projects or when problems are identified during a
project.
Each loop in the spiral is split into four sectors (quadrants).
13
Determine Identify &

Objectives Resolve Risks
Review and
plan for next Develop Next
phase Level of Product
14
Objective Setting (First Quadrant)
Identify objectives of the phase,

Examine the risks associated with these objectives.
◦ Risk:
◦ any adverse circumstance that might hamper
successful completion of a software project.
Find alternate solutions possible.
15
Risk Assessment and Reduction (Second
Quadrant)
For each identified project risk,
◦ a detailed analysis is carried out.
Steps are taken to reduce the risk.
For example, if there is a risk that the requirements are
inappropriate:
◦ a prototype system may be developed.
16
Development and Validation (Third quadrant):

◦ develop and validate the next level of the product.
Review and Planning (Fourth quadrant):

◦ review the results achieved so far with the customer and plan the next
iteration around the spiral.
With each iteration around the spiral:

◦ progressively more complete version of the software gets built.
17
Spiral Model as a meta model
Subsumes all discussed models:
◦ a single loop spiral represents waterfall model.
◦ uses an evolutionary approach --
◦ iterations through the spiral are evolutionary levels.
◦ enables understanding and reacting to risks during each
iteration along the spiral.
◦ uses:
◦ prototyping as a risk reduction mechanism
◦ retains the step-wise approach of the waterfall model.
18
Question
Which is the most important feature of spiral model?
A) Quality Management
B) Risk Management
C) Performance Management
D) Efficiency Management
Comparison of Different Life Cycle Models
Iterative waterfall model
◦ most widely used model.
◦ But, suitable only for well-understood problems.
Prototype model is suitable for projects not well understood:
◦ user requirements
20
Comparison of Different Life Cycle Models
(CONT.)
Evolutionary model is suitable for large problems:

◦ can be decomposed into a set of modules that can be
incrementally implemented,
◦ incremental delivery of the system is acceptable to the customer.
The spiral model:
◦ suitable for development of technically challenging software
products that are subject to several kinds of risks.
21
Prototyping Model
Prototyping Model
Before starting actual development,
◦a working prototype of the system should
first be built.
A prototype is a toy implementation of a
system:
◦limited functional capabilities,
◦low reliability,
◦inefficient performance.
2
Prototyping Model (CONT.)
In many instances the client only has a general view of

what is to be expected from the software product. In
such a scenario where there is an absence of detailed
information regarding the input to the system, the
processing needs and the output requirements, the
prototyping model may be employed.
Question
When we should choose Prototyping model?
A) When complete requirement is given
B) When requirements are not properly cleared.
C) When client understand the development process.
D) None of the mentioned.
The developed prototype is submitted to the

customer for his evaluation:
◦Based on the user feedback, requirements
are refined.
◦This cycle continues until the user approves
the prototype.
The actual system is developed using the
iterative waterfall approach.
5
Build Prototype
Requirements Customer Customer

Gathering Quick Design Evaluation of satisfied
Design
Prototype
Implement
Refine
Requirements
Test
Maintenance
6
REQUIREMENTS AND GATHERING ANALYSIS:

◦ The user is interviewed to gather information regarding the requirement
of the software.
DESIGN:
◦ Preliminary design or quick design involving only the important aspects
is created.
BUILD PROTOTYPE:
◦ Information from the quick design is modified to form a prototype.
CUSTOMER EVALUATION OF PROTOTYPE:

◦ The proposed system is now presented to the user for consideration.
PROTOTYPE REFINEMENT:
◦ Once the user evaluates the prototype the required changes are made
and the final prototype is used to make the final system.
ENGINEER PRODUCT:
◦ The final thoroughly tested and undergoes routine maintenance in
order to avoid any future system failures.
Types of Prototyping
1. Throwaway prototypes
2. Evolutionary prototypes
3. Incremental prototypes
4. Extreme prototypes
Throwaway Prototypes
•The prototype is developed rapidly based on the initial
requirements and given to the client for review.
•Once the client provides feedback, final requirements
are updated and work on the final product begins. As
the name suggests, the developed prototype is
discarded, and it will not be part of the final product.
•It is also known as close-ended prototyping.
Evolutionary Prototypes
•A prototype is made, and the client feedback is received. Based
on the feedback, the prototype is refined until the client
considers it the final product.
•It follows an incremental development approach and saves
time compared to the rapid throwaway prototyping method as
in evolutionary prototyping old prototype is reworked rather
than developing a new prototype from scratch.
•It is also known as breadboard prototyping.
Incremental Prototypes
•In this type of prototype model, final product requirements are
break into smaller parts and each part is developed as a
separate prototype.
•All the parts (prototypes) are merged which becomes a final
product.
Extreme Prototypes
•This type of prototyping model is mainly used for web
applications. It is divided into three phases
oFirst, a basic prototype with static pages is created, it consists
of HTML pages.
oNext, using a services layer, data processing is simulated.
oIn the last phase, services are implemented.
Advantages of Prototype Model
•Quick client feedback is received which speeds up the development
process. Also, it helps the development team to understand the
client’s needs.
•Developed prototypes can be used later for any similar projects.
•Any missing functionality and any error can be detected early.
•It is useful when requirements are not clear from the client’s end,
even with limited requirements, the development team can start the
development process.
Disadvantages of Prototype Model
•It is a time-consuming process or method as multiple prototypes might
be needed until the client reaches the final requirements. The Client may
not have an explicit idea about what they want.
•This method involves too much client interaction and involvement, which
can be done only with a committed client.
•In the beginning, it is a bit difficult to predict the exact amount of time
needed to reach the final product.
•While coding, developers do not have a broad perspective of what is
coming, because of which they might use an underlying architecture that
is not suitable for a final product.
Difference Between Prototype and
waterfall model.
In Waterfall Model:
•The waterfall model directly delivers the final product to the user
and his feedback is only taken in, before the design phase.
In prototype Model:
•The prototype model creates several rough working applications and
involves constant user interaction, until the developers come up with
the final application
Difference Between Prototype and
waterfall model.(Cont.)
In Waterfall Model:
The waterfall model is better suited for a more conventional
software projects, where user requirements are clear, right from the
start.
In prototype Model:
The prototype model is well suited for online applications where
user interfaces are the most important component.
Question
Which of the following are advantages of iterative model?
A. To iterate the phases to find the missing necessity
B. Simpler to manage
C. Early feedback
D. All of the mentioned above
Next Lecture: Spiral Model
Function-Oriented
Software Design
1
Introduction
Function-oriented design
techniques are very popular:
currently in use in many software
development organizations.
techniques:
start with the functional requirements
specified in the SRS document.
2
Question
In Function oriented design, which

Diagrammatical representation is used?
A) UML Diagrams
B) Data Flow Diagrams
C) ER Diagrams
D) None of above
3
Introduction
During the design process:
high-level functions are
successively decomposed:
into more detailed functions.
finally the detailed functions are
mapped to a module structure.
4
Introduction
Successive decomposition of
high-level functions:
Technically known as top-
down decomposition.
5
Introduction
SA/SD methodology:
has essential features of several
important function-oriented
design methodologies ---
if you need to use any specific
design methodology later on,
you can do so easily with small
additional effort.
6
SA/SD (Structured
Analysis/Structured Design)
7
SA/SD (Structured
SA/SD technique draws heavily

from the following methodologies:
Constantine and Yourdon's
methodology
Hatley and Pirbhai's methodology
Gane and Sarson's methodology
DeMarco and Yourdon's methodology
SA/SD technique can be used to
perform
high-level design.
8
Overview of SA/SD
Methodology
SA/SD methodology consists of
two distinct activities:
Structured Analysis (SA)
Structured Design (SD)
During structured analysis:
functional decomposition takes
place.
During structured design:
module structure is formalized.
9
Functional
decomposition
Each function is analyzed:
hierarchically decomposed
simultaneous decomposition
of high-level data
into more detailed data.
10
Structured analysis
Transforms a textual
problem description into a
graphic model.
done using data flow
diagrams (DFDs).
DFDs graphically represent
the results of structured
analysis.
11
Structured design
All the functions represented in
the DFD:
The module structure:
also called as the software
architecture:
12
Detailed Design
Software architecture:
refined through detailed
design.
Detailed design can be
directly implemented:
using a conventional
13
Question
Outcome of Structured Analysis:

a) Data Flow Diagram
b) Structure Chart
c) Module Diagram
d) Detail Design
14
Structured Analysis vs.
Structured Design
Purpose of structured analysis:
capture the detailed structure of
the system as the user views it.
Purpose of structured design:
arrive at a form that is suitable
for implementation in some
15
Structured Design
The results of structured analysis can be
easily understood even by ordinary
customers:
does not require computer knowledge
directly represents customer’s perception of
the problem
uses customer’s terminology for naming
different functions and data.
reviewed by customers:
to check whether it captures all their
requirements.
16
Structured Analysis
Based on principles of:
Top-down decomposition approach.
Divide and conquer principle:
each function is considered individually
(i.e. isolated from other functions)
decompose functions totally disregarding
what happens in other functions.
Graphical representation of results
using
data flow diagrams (or bubble charts).
17
Data flow diagrams
DFD is an elegant modelling
technique:
useful not only to represent the results
of structured analysis
applicable to other areas also:
e.g. for showing the flow of documents or
items in an organization,
DFD technique is very popular
because
it is simple to understand and use.
18
Data flow diagram
DFD is a hierarchical
graphical model:
shows the different functions
(or processes) of the system
and
data interchange among the
processes.
19
DFD Concepts
It is useful to consider each
function as a processing
station:
each function consumes some
input data and
produces some output data.
20
Data Flow Model of a Car
Assembly Unit
Engine Store Door Store
Chassis with Partly

Engine Assembled
Fit Fit Car Fit Paint and
Engine Doors Wheels Test
Assembled
Car Car
Chassis Store Wheel Store
21
Data Flow Diagrams (DFDs)
A DFD model:
uses limited types of symbols.
simple set of rules
easy to understand:
it is a hierarchical model.
22
Hierarchical model
Human mind can easily

understand any hierarchical
model:
in a hierarchical model:
we start with a very simple and
abstract model of a system,
details are slowly introduced
through the hierarchies.
23
Hierarchical Model
24
Primitive Symbols Used for Constructing DFDs:
25
External Entity Symbol
Represented by a rectangle
External entities are real Librarian
physical entities:
input data to the system or
consume data produced by the
system.
Sometimes external entities are
called terminator, source, or sink.
26
Function Symbol
A function such as “search-book” is
represented using a circle: search-
This symbol is called a book
process or bubble or transform.
Bubbles are annotated with
corresponding function names.
Functions represent some activity:
function names should be verbs.
27
Data Flow Symbol
A directed arc or line.

represents data flow in the
direction of the arrow.
Data flow symbols are
annotated with names of data
they carry.
book-name
28
Data Store Symbol
Represents a logical file:
A logical file can be:
a data structure
a physical file on disk.
Each data store is connected
to a process:
by means of a data flow
symbol.
book-details
29
Data Store Symbol
Direction of data flow arrow:
shows whether data is being read
from or written into it.
find-book
An arrow into or out of a data
store: Books
implicitly represents the entire data of

the data store
arrows connecting to a data store
need not be annotated with any data
name.
30
Output Symbol
Output produced by the system
31
Synchronous operation
If two bubbles are directly

connected by a data flow arrow:
they are synchronous
Read- number Validate-
numbers numbers
0.1 0.2 Valid
Data- number
items
32
Asynchronous operation
If two bubbles are connected via a
data store:
they are not synchronous.
Read- Validate-
numbers numbers
0.1 0.2
numbers Valid
Data- number
items
33
Question
During structure analysis the functional

requirements are transformed into_____.
b) Structure Chart
c) Module Diagram
d) Detail Design
34
Data Dictionary
A DFD is always accompanied by a data
dictionary.
A data dictionary lists all data items
appearing in a DFD:
definition of all composite data items in
terms of their component data items.
all data names along with the purpose of
data items.
For example, a data dictionary entry may
be:
grossPay = regularPay+overtimePay
35
Importance of Data
Dictionary
Provides all engineers in a project
with standard terminology for all
data:
A consistent vocabulary for data is
very important
different engineers tend to use
different terms to refer to the same
data,
causes unnecessary confusion.
36
Importance of Data
Dictionary
Data dictionary provides the
definition of different data:
in terms of their component elements.
For large systems,
the data dictionary grows rapidly in
size and complexity.
Typical projects can have thousands of
data dictionary entries.
It is extremely difficult to maintain
such a dictionary manually.
37
Data Dictionary
CASE (Computer Aided
Software Engineering) tools
come handy:
CASE tools capture the data
items appearing in a DFD
automatically to generate the
data dictionary.
38
Data Dictionary
CASE tools support queries:
about definition and usage of data items.
For example, queries may be made to
find:
which data item affects which processes,
a process affects which data items,
the definition and usage of specific data
items, etc.
Query handling is facilitated:
if data dictionary is stored in a relational
database management system (RDBMS).
39
Data Definition
Composite data are defined in terms of
primitive data items using following
operators:
+: denotes composition of data items,
e.g
a+b represents data a and b.
[,,,]: represents selection,
i.e. any one of the data items listed inside the
square bracket can occur.
For example, [a,b] represents either a occurs
or b occurs.
40
Data Definition
( ): contents inside the bracket
represent optional data
which may or may not appear.
a+(b) represents either a or a+b
occurs.
{}: represents iterative data
definition,
e.g. {name}5 represents five name
data.
41
Data Definition
{name}* represents
zero or more instances of name data.
= represents equivalence,
e.g. a=b+c means that a represents b
and c.
* *: Anything appearing within *
* is considered as comment.
42
Data dictionary for RMS
Software
numbers=valid-numbers=a+b+c
a:integer * input number *
b:integer * input number *
c:integer * input number *
asq:integer
bsq:integer
csq:integer
squared-sum: integer
Result=[RMS,error]
RMS: integer * root mean square value*
error:string * error message*
43
Software
a b
c
Square Square Square
0.3.1.1 0.3.1.2 0.3.1.3
bsq
asq csq
Sum
0.3.1.4
Squared-sum
44
Question
What is the purpose of {} in data

dictionary?
a) It define the composition of data
b) Iterative data
c) Common data
d) Comment section
45
How is Structured Analysis
Performed?
Initially represent the software
at the most abstract level:
called the context diagram.
the entire system is represented
as a single bubble,
this bubble is labelled according
to the main function of the
system.
46
Tic-tac-toe: Context
Diagram
Tic-tac-toe
display software
move
Human Player
47
Context Diagram
A context diagram shows:
data input to the system,
output data generated by
the system,
external entities.
The context diagram is also
called as the level 0 DFD.
48
Context Diagram
Context diagram
establishes the context of the
system, i.e.
represents:
Data sources
Data sinks.
49
Level 1 DFD
Examine the SRS document:
Represent each high-level
function as a bubble.
Represent data input to every
high-level function.
Represent data output from every
50
Level 1 DFD
Display- game
board
move 0.1 result
Validate- Check-
move board winner
0.2 0.4
Play-
move
0.3
51
Higher level DFDs
Each high-level function is
separately decomposed into
subfunctions:
identify the subfunctions of the
function
identify the data input to each
subfunction
identify the data output from each
subfunction
These are represented as DFDs.
52
Decomposition
Decomposition of a bubble:
also called factoring or
exploding.
Each bubble is decomposed
to
between 3 to 7 bubbles.
53
Decomposition
Too few bubbles make

decomposition superfluous:
if a bubble is decomposed to
just one or two bubbles:
then this decomposition is
redundant.
54
Decomposition
Too many bubbles:

more than 7 bubbles at
any level of a DFD
make the DFD model hard
to understand.
55
Decompose how long?
Decomposition of a
bubble should be carried
on until:
a level at which the
function of the bubble can
be described using a
simple algorithm.
56
Question
Which of the following team is know as

decomposition of bubbles?
a) Sub-Functions
b) Factoring
c) Exploding
d) Both B and C
57
Balancing a DFD
Data flowing into or out of a bubble:
must match the data flows at the next level
of DFD.
This is known as balancing a DFD
In the level 1 of the DFD,
data item c flows into the bubble P3 and the
data item d and e flow out.
In the next level, bubble P3 is
decomposed.
The decomposition is balanced as data item c
flows into the level 2 diagram and d and e
flow out. 58
Balancing a DFD
c
b c
c1
d1
a d
e
Level 1 d e1
e
Level 2
59
Numbering of Bubbles:
Number the bubbles in a DFD:
numbers help in uniquely identifying any
bubble from its bubble number.
The bubble at context level:
assigned number 0.
Bubbles at level 1:
numbered 0.1, 0.2, 0.3, etc
When a bubble numbered x is
decomposed,
its children bubble are numbered x.1, x.2,
x.3, etc.
60
Example 1: RMS Calculating
Software
Consider a software called RMS

calculating software:
reads three integers in the range
of -1000 and +1000
finds out the root mean square
(rms) of the three input numbers
displays the result.
61
Software
The context diagram is

simple to develop:
The system accepts 3
integers from the user
returns the result to him.
62
Software
Data- Compute-
items RMS
0
User result
Context Diagram
63
Software
From a cursory analysis of

the problem description:
we can see that the
system needs to perform
several things.
64
Software
Accept input numbers from

the user:
validate the numbers,
calculate the root mean
square of the input numbers
display the result.
65
Software
numbers
Read- Validate-
numbers numbers
0.1 0.2
Valid -
Data- numbers
items error
Compute-
Display rms
0.4 0.3
result RMS
66
Software
Squared-
Calculate- sum Calculate-
squared-sum mean
0.3.1 0.3.2
Valid - Mean-
numbers square
Calculate-
root
0.3.3
RMS
67
Example: RMS Calculating
Software
b
a c
0.3.1.1 0.3.1.2 0.3.1.3
bsq
asq csq
Sum
0.3.1.4
Squared-sum
68
Software
Decomposition is never
carried on up to basic
instruction level:
a bubble is not decomposed
any further:
if it can be represented by a
simple set of instructions.
69
Example 2: Tic-Tac-Toe
Computer Game
A human player and the computer make
alternate moves on a 3 3 square.
A move consists of marking a previously
unmarked square.
The user inputs a number between 1
and 9 to mark a square
Whoever is first to place three
consecutive marks along a straight line
(i.e., along a row, column, or diagonal)
on the square wins.
70
Example: Tic-Tac-Toe
Computer Game
As soon as either of the human player or
the computer wins,
a message announcing the winner should be
displayed.
If neither player manages to get three
consecutive marks along a straight line,
and all the squares on the board are filled up,
then the game is drawn.
The computer always tries to win a
game.
71
Context Diagram for
Example
Tic-tac-toe
software
display 0
move
Human Player
72
Level 1 DFD
Display- game
board
move 0.1 result
Validate- Check-
move board winner
0.2 0.4
Play-
move
0.3
73
Data dictionary
Display=game + result
move = integer
board = {integer}9
game = {integer}9
result=string
74
Software Design
Introduction
Design phase transforms SRS
document:
into a form easily implementable in
some programming language.
SRS Document Design Documents

Design Activities
Items Designed During
Design Phase
1. module structure,
2. control relationship among the modules
3. interface among different modules,
data items exchanged among different
modules,
4. data structures of individual modules,
5. algorithms for individual modules.
Module Structure
Introduction
A module consists of:
1. several functions
2. associated data structures.
D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
Introduction
Design activities are usually classified into
two stages:
1. preliminary (or high-level) design
2. detailed design.
High-level design
Identify:
1. modules
2. control relationships among modules
3. interfaces among modules.
d1 d2
d3 d1 d4
High-level design
The outcome of high-level design:

program structure (or software
architecture).
Detailed design
For each module, design:
1. data structure
2. algorithms
Outcome of detailed design:

module specification.
What Is Good Software
Design?
➢Should implement all functionalities of

the system correctly.
➢Should be easily understandable.
➢Should be efficient.
➢Should be easily able to change,
i.e. easily maintainable.
Design?
Understandability of a design is a
major issue:
➢determines goodness of design:
➢a design that is easy to
understand: also easy to
maintain and change.
Design?
Unless a design is easy to understand,

tremendous effort needed to maintain it.
We already know that about 60% effort is

spent in maintenance.
If the software is not easy to understand:

maintenance effort would increase many
times.
Understandability
Use consistent and meaningful names

for various design components,
Design solution should consist of:

a cleanly decomposed set of modules
(modularity),
Different modules should be neatly
arranged in a hierarchy:
in a neat tree-like diagram.
Modularity
Modularity is a fundamental attributes
of any good design.
Decomposition of a problem cleanly into

modules:
1. Modules are almost independent of
each other
2. divide and conquer principle.
Modularity
If modules are independent:
➢modules can be understood
separately.
➢reduces the complexity greatly.
To understand why this is so,
➢remember that it is very difficult to break

a bunch of sticks but very easy to break
the sticks individually.
Example of Cleanly and
Non-cleanly Decomposed
Modules
Modularity
In technical terms, modules should

display:
1. high cohesion
2. low coupling.
Modularity
Neat arrangement of modules in a
hierarchy means:
1. low fan-out
Fan-out: a measure of the number of
modules directly controlled by given
module.
2. abstraction
Cohesion and Coupling
Cohesion is a measure of:

➢functional strength of a module.
➢A cohesive module performs a single

task or function.
Coupling between two modules:

➢a measure of the degree of
interdependence or interaction
between the two modules.
Cohesion and Coupling
A module having high cohesion

and low coupling:
functionally independent of other

modules:
A functionally independent module

has minimal interaction with other
modules.
Advantages of Functional
Independence
Better understandability and good

design:
Complexity of design is reduced,

➢Different modules easily understood
in isolation:
➢modules are independent

Advantages of Functional
Independence
Functional independence reduces
error propagation.
➢degree of interaction between
modules is low.
➢an error existing in one module does

not directly affect other modules.
Reuse of modules is possible.

Classification of
Cohesiveness
functional
sequential
communicational Degree of
procedural cohesion
temporal
logical
coincidental
Coincidental cohesion
The module performs a set of tasks:

which relate to each other very loosely,
if at all.
➢the module contains a random collection

of functions.
➢functions have been put in the module

out of pure coincidence without any
thought or design.
Logical cohesion
All elements of the module perform

similar operations:
e.g. error handling, data input, data
output, etc.
Temporal cohesion
The module contains tasks that are related

by the fact that all the tasks must be
executed in the same time span.
Procedural cohesion
If the set of functions of the

module all part of a procedure
(algorithm) in which certain
sequence of steps have to be
carried out in a certain order for
achieving an objective,
e.g. the algorithm for decoding a message.
Communicational
cohesion
If All functions of the module

Refer to the same data structure,
Example:
the set of functions defined on an
array or a stack.
Sequential cohesion
If the Elements of a module forms

different parts of a sequence,
output from one element of the
sequence is input to the next.
Example: sort
search
display
Functional cohesion
If the Different elements of a

module cooperate to achieve a
single function.
Coupling
Coupling indicates:
➢how closely two modules interact
or how interdependent they are.
➢The degree of coupling between

two modules depends on their
interface complexity.
Classes of coupling
data
stamp
control Degree of
coupling
common
content
Data coupling
Two modules are data coupled,
if they communicate by an
elementary data item that is
passed as a parameter between
the two, eg an integer, a floa,
character etc.
Stamp coupling
Two modules are stamp coupled,
if they communicate via a

composite data item:
➢such as a record in PASCAL
or a structure in C.
Control coupling
It exists between two modules.
If Data from one module is used
to direct order of instruction
execution in another.
Example of control coupling:
a flag set in one module and tested
in another module.
Common Coupling
Two modules are common

coupled, if they share some
global data items.
Content coupling
Content coupling exists between two
modules:
if they share code,
e.g, branching from one module into

another module.
The degree of coupling increases

from data coupling to content coupling.
Neat Hierarchy
Control hierarchy represents organization of
modules. control hierarchy is also called
program structure.
Characteristics of
Module Structure
Depth:
number of levels of control
Width:
overall span of control.
Fan-out:
a measure of the number of modules
directly controlled by given module.
Characteristics of
Module Structure
Fan-in:
indicates how many modules
directly invoke a given module.
High fan-in represents code reuse
and is in general encouraged.
Module Structure
Fan out=2
Fan out=1
Fan in=2
Fan out=0
Goodness of Design
A design having modules:

with high fan-out numbers is not a
good design:
a module having high fan-out lacks
cohesion.
Visibility and Layering
A module A is said to be visible by

another module B,
if A directly or indirectly calls B.
The layering principle requires

modules at a layer can call only the
modules immediately below it.
Bad Design
Abstraction
The principle of abstraction
requires:
lower-level modules do not invoke
functions of higher level modules.
Also known as layered design.

High-level Design
High-level design maps functions into

modules {fi} {mj} such that:
1. Each module has high cohesion
2. Coupling among modules is as low as

possible
3. Modules are organized in a neat

hierarchy
Design Approaches
Two fundamentally different

software design approaches:
Object-oriented design
Function-Oriented
Design
A system is looked upon as something
that performs a set of functions.
Starting at this high-level view of the
system:
➢each function is successively refined into
more detailed functions.
➢Functions are mapped to a module

structure.
Function-Oriented
Design
Each subfunction:
split into more detailed subfunctions

and so on.
Object-Oriented Design
System is viewed as a collection

of objects (i.e. entities).
➢each object manages its own state

information.
Example
Library Automation Software:
➢each library member is a
separate object with its own
data and functions.
➢Functions defined for one
object:
cannot directly refer to or change
data of other objects.
Objects have their own internal data:

defines their state.
Similar objects constitute a class.
➢each object is a member of some
class.
➢Classes may inherit features from
a super class.
Conceptually, objects communicate
by message passing.
Object-Oriented versus
Function-Oriented Design
Unlike function-oriented design,

in OOD the basic abstraction is not
functions such as “sort”,
“display”, “track”, etc.,
but real-world entities such as

“employee”, “picture”, “machine”,
“radar system”, etc.
Object-Oriented versus
In OOD:
➢software is not developed by
designing functions such as:
1. update-employee-record,
2. get-employee-address, etc.
but by designing objects such as:

1. employees,
2. departments, etc.
Summary
We characterized the features of a
good software design by
introducing the concepts of:
fan-in, fan-out,
cohesion, coupling,
abstraction, etc.
Summary

approaches to software design:
function-oriented approach
object-oriented approach
Characteristics of Good Design
• Component independence
– High cohesion
– Low coupling
• Fault prevention and fault tolerance
Question
• Which of the following is not an Advantage of
modularization?
a. Smaller components are easier to maintain.
b. Concurrent execution can be made possible.
c. Program cannot be divided based on functional
aspects.
d. Desired level of abstraction can be brought in the
program.
Cohesion
• Definition: The degree to which all elements of a
component are directed towards a single task
and all elements directed towards that task are
contained in a single component.
• Internal glue with which component is
constructed
• All elements of component are directed toward
and essential for performing the same task
• High is good
Range of Cohesion
High Cohesion
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
Low
Coincidental Cohesion
• Definition: Parts of the component are only
related by their location in source code
• Elements needed to achieve some
functionality are scattered throughout the
system.
• Accidental
• Worst form
Coincidental Cohesion(cont.)
Module Name: Module-Name:

Random-Operation Managing-Book-Lending
Function: Function:
Issue-book Issue-book
Create-member Return-book
Compute-vendor-credit Query-book
Request-librarian-leave Find-borrower
Example of cohesion
Logical Cohesion
• Definition: Elements of component are
related logically and not functionally.
All elements of the module perform similar
operations:
e.g. error handling, data input, data output,
etc.
Function A
logic Function A’
Function A’’
Logical
Similar functions
Temporal Cohesion
• Definition: Elements of a component are
related by timing.
• The module contains tasks that are related
by the fact that all the tasks must be
executed in the same time span.
Time t0
Time t0 + X
Time t0 + 2X
Temporal
Related by time
Procedural Cohesion
• Definition: Set of functions of the module
are executed one after the other
If the set of functions of the module all part of a procedure
(algorithm) in which certain sequence of steps have to
be carried out in a certain order for achieving an
objective,
e.g. the algorithm for decoding a message.
For example: Login(), place-order(), check-order(), print-
bill() and logout()
Communicational Cohesion
Definition: If All functions of the module Refer to
the same data structure,
Example:
the set of functions defined on an array or a
stack.
admitStudent,
enterMarks studentRecords
printGradeSheet ARRAY
Sequential Cohesion
• The output of one component is the input to
another.
Sort
Search
Display
Functional Cohesion
• Definition: If the Different elements of a
module cooperate to achieve a single
function.
• Every element in the component is
essential to the computation.
Module-Name:
Managing-Book-Lending
Function:
Issue-book
Return-book
Query-book
Find-borrower
Examples of Cohesion-1
Function A Function A Time t0

Function Function
B C Function A’ Time t0 + X
logic
Function Function Time t0 + 2X
D E Function A’’
Coincidental Logical Temporal

Parts unrelated Similar functions Related by time
Function A
Function B
Function C
Procedural
Related by order of functions
Examples of Cohesion-2
Function A Function A
Function B Function B
Function C Function C
Communicational Sequential
Access same data Output of one is input to another
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Question
• Which of the following is the best type of
module cohesion?
a. Functional Cohesion
b. Temporal Cohesion
c. Logical Cohesion
d. Sequential Cohesion
Coupling: Degree of dependence
among components
No dependencies Loosely coupled-some dependencies
High coupling makes modifying

parts of the system difficult, e.g.,
Highly coupled-many dependencies modifying a component affects all
the components to which the
component is connected.
Range of Coupling
High Coupling
Content
Common
Control
Loose
Stamp
Data
Uncoupled
Low
Question
• What is the typical relationship between
coupling and cohesion?
a. There is no relationship between coupling
and cohesion.
b. As cohesion increases, coupling
increases.
c. As cohesion increases, coupling
decreases.
Content coupling
Content coupling exists between two
modules:
if they share code,
e.g, branching from one module into

another module.
The degree of coupling increases

from data coupling to content coupling
Common Coupling
• Definition: Two components share data
– Global data structures
– Common blocks
• Usually a poor design choice because
– Lack of clear responsibility for the data
– Reduces readability
– Difficult to determine all the components that affect
a data element (reduces maintainability)
– Difficult to reuse components
– Reduces ability to control data accesses
Control Coupling
• Definition: Component passes control
parameters to coupled components.
• May be either good or bad, depending on situation.
– Bad when component must be aware of internal
structure and logic of another module
– Good if parameters allow factoring and reuse of
functionality
Example of control coupling:
a flag set in one module and tested in another
module.
Stamp Coupling
• Definition: Component passes a data structure
to another component that does not have access
to the entire structure.
if they communicate via a composite
data item:
➢such as a record in PASCAL
or a structure in C.
Data Coupling
• Definition: Two components are data
coupled:
• if they communicate by an elementary
data item that is passed as a parameter
between the two, e.g.: an integer, a float,
character etc.
Question
• When multiple modules share a common data
structure and work on different part of it, it is
called _.
a. Common coupling
b. Share coupling
c. Data coupling
d. Stamp coupling
Neat Hierarchy
Control hierarchy represents organization of
modules. control hierarchy is also called
program structure.
Characteristics of Module
Structure
Depth:
number of levels of control
Width:
overall span of control.
Fan-out:
a measure of the number of modules
directly controlled by given module.
Characteristics of
Module Structure
Fan-in:
indicates how many modules
directly invoke a given module.
High fan-in represents code reuse
and is in general encouraged.
Module Structure
Fan out=2
Fan out=1
Fan in=2
Fan out=0
Goodness of Design
A design having modules:

with high fan-out numbers is not a
good design:
a module having high fan-out lacks
cohesion.
Visibility and Layering
A module A is said to be visible by another
module B,
if A directly or indirectly calls B.
The layering principle requires

modules at a layer can call only the
modules immediately below it.
Bad Design
Abstraction
The principle of abstraction
requires:
lower-level modules do not invoke
functions of higher level modules.
Also known as layered design.

High-level Design
High-level design maps functions into
modules {fi} {mj} such that:
1. Each module has high cohesion
2. Coupling among modules is as low
as possible
3. Modules are organized in a neat
hierarchy
Design Approaches

software design approaches:
Object-oriented design
A system is looked upon as something

that performs a set of functions.
Starting at this high-level view of the
system:
➢each function is successively refined into
more detailed functions.
➢Functions are mapped to a module
structure.
Each subfunction:
split into more detailed subfunctions

and so on.
System is viewed as a collection
of objects (i.e. entities).
➢each object manages its own state

information.
Example
Library Automation Software:
➢each library member is a
separate object with its own
data and functions.
➢Functions defined for one
object:
cannot directly refer to or change
data of other objects.
Objects have their own internal data:
defines their state.
Similar objects constitute a class.
➢each object is a member of some
class.
➢Classes may inherit features from
a super class.
Conceptually, objects communicate
by message passing.
Object-Oriented versus Function-
Oriented Design
Unlike function-oriented design,

in OOD the basic abstraction is not
functions such as “sort”, “display”,
“track”, etc.,
but real-world entities such as

“employee”, “picture”, “machine”,
“radar system”, etc.
Object-Oriented versus Function-
Oriented Design
In OOD:
➢software is not developed by
designing functions such as:
1. update-employee-record,
2. get-employee-address, etc.
but by designing objects such as:

1. employees,
2. departments, etc.
Function-Oriented
Software Design
1
Introduction
techniques are very popular:
currently in use in many software
development organizations.
techniques:
start with the functional requirements
specified in the SRS document.
2
Question
In Function oriented design, which

Diagrammatical representation is used?
A) UML Diagrams
B) Data Flow Diagrams
C) ER Diagrams
D) None of above
3
Introduction
During the design process:
high-level functions are
successively decomposed:
finally the detailed functions are
4
Introduction
Successive decomposition of
high-level functions:
Technically known as top-
down decomposition.
5
Introduction
SA/SD methodology:
has essential features of several
important function-oriented
design methodologies ---
if you need to use any specific
design methodology later on,
you can do so easily with small
additional effort.
6
SA/SD (Structured
7
SA/SD (Structured
SA/SD technique draws heavily

from the following methodologies:
Constantine and Yourdon's
methodology
Hatley and Pirbhai's methodology
Gane and Sarson's methodology
DeMarco and Yourdon's methodology
SA/SD technique can be used to
perform
high-level design.
8
Overview of SA/SD
Methodology
SA/SD methodology consists of
two distinct activities:
Structured Analysis (SA)
Structured Design (SD)
During structured analysis:
functional decomposition takes
place.
During structured design:
module structure is formalized.
9
Functional
decomposition
Each function is analyzed:
hierarchically decomposed
simultaneous decomposition
of high-level data
into more detailed data.
10
Structured analysis
Transforms a textual
problem description into a
graphic model.
done using data flow
diagrams (DFDs).
DFDs graphically represent
the results of structured
analysis.
11
Structured design
All the functions represented in
the DFD:
The module structure:
also called as the software
architecture:
12
Detailed Design
Software architecture:
refined through detailed
design.
Detailed design can be
directly implemented:
using a conventional
13
Question
Outcome of Structured Analysis:

b) Structure Chart
c) Module Diagram
d) Detail Design
14
Structured Design
Purpose of structured analysis:
capture the detailed structure of
the system as the user views it.
Purpose of structured design:
arrive at a form that is suitable
for implementation in some
15
Structured Design
easily understood even by ordinary
customers:
does not require computer knowledge
directly represents customer’s perception of
the problem
uses customer’s terminology for naming
different functions and data.
reviewed by customers:
to check whether it captures all their
requirements.
16
Structured Analysis
Based on principles of:
Top-down decomposition approach.
Divide and conquer principle:
each function is considered individually
(i.e. isolated from other functions)
decompose functions totally disregarding
what happens in other functions.
Graphical representation of results
using
data flow diagrams (or bubble charts).
17
Data flow diagrams
DFD is an elegant modelling
technique:
useful not only to represent the results
of structured analysis
applicable to other areas also:
e.g. for showing the flow of documents or
items in an organization,
DFD technique is very popular
because
it is simple to understand and use.
18
Data flow diagram
DFD is a hierarchical
graphical model:
shows the different functions
(or processes) of the system
and
data interchange among the
processes.
19
DFD Concepts
It is useful to consider each
function as a processing
station:
each function consumes some
input data and
produces some output data.
20
Data Flow Model of a Car
Assembly Unit
Engine Store Door Store
Chassis with Partly

Engine Assembled
Fit Fit Car Fit Paint and
Engine Doors Wheels Test
Assembled
Car Car
Chassis Store Wheel Store
21
A DFD model:
uses limited types of symbols.
simple set of rules
easy to understand:
it is a hierarchical model.
22
Hierarchical model
Human mind can easily

understand any hierarchical
model:
in a hierarchical model:
we start with a very simple and
abstract model of a system,
details are slowly introduced
through the hierarchies.
23
Hierarchical Model
24
Primitive Symbols Used for Constructing DFDs:
25
External Entity Symbol
Represented by a rectangle
External entities are real Librarian
physical entities:
input data to the system or
consume data produced by the
system.
Sometimes external entities are
called terminator, source, or sink.
26
Function Symbol
A function such as “search-book” is
represented using a circle: search-
This symbol is called a book
process or bubble or transform.
Bubbles are annotated with
corresponding function names.
Functions represent some activity:
function names should be verbs.
27
Data Flow Symbol
A directed arc or line.

represents data flow in the
direction of the arrow.
Data flow symbols are
annotated with names of data
they carry.
book-name
28
Data Store Symbol
Represents a logical file:
A logical file can be:
a data structure
a physical file on disk.
Each data store is connected
to a process:
by means of a data flow
symbol.
book-details
29
Data Store Symbol
Direction of data flow arrow:
shows whether data is being read
from or written into it.
find-book
An arrow into or out of a data
store: Books
implicitly represents the entire data of

the data store
arrows connecting to a data store
need not be annotated with any data
name.
30
Output Symbol
Output produced by the system
31
Synchronous operation
If two bubbles are directly

connected by a data flow arrow:
they are synchronous
Read- number Validate-
numbers numbers
0.1 0.2 Valid
Data- number
items
32
Asynchronous operation
If two bubbles are connected via a
data store:
they are not synchronous.
Read- Validate-
numbers numbers
0.1 0.2
numbers Valid
Data- number
items
33
Question
During structure analysis the functional

requirements are transformed into_____.
b) Structure Chart
c) Module Diagram
d) Detail Design
34
Data Dictionary
A DFD is always accompanied by a data
dictionary.
A data dictionary lists all data items
appearing in a DFD:
definition of all composite data items in
terms of their component data items.
all data names along with the purpose of
data items.
For example, a data dictionary entry may
be:
grossPay = regularPay+overtimePay
35
Importance of Data
Dictionary
Provides all engineers in a project
with standard terminology for all
data:
A consistent vocabulary for data is
very important
different engineers tend to use
different terms to refer to the same
data,
causes unnecessary confusion.
36
Importance of Data
Dictionary
Data dictionary provides the
definition of different data:
in terms of their component elements.
For large systems,
the data dictionary grows rapidly in
size and complexity.
Typical projects can have thousands of
data dictionary entries.
It is extremely difficult to maintain
such a dictionary manually.
37
Data Dictionary
CASE (Computer Aided
Software Engineering) tools
come handy:
CASE tools capture the data
items appearing in a DFD
automatically to generate the
data dictionary.
38
Data Dictionary
CASE tools support queries:
about definition and usage of data items.
For example, queries may be made to
find:
which data item affects which processes,
a process affects which data items,
the definition and usage of specific data
items, etc.
Query handling is facilitated:
if data dictionary is stored in a relational
database management system (RDBMS).
39
Data Definition
Composite data are defined in terms of
primitive data items using following
operators:
+: denotes composition of data items,
e.g
a+b represents data a and b.
[,,,]: represents selection,
i.e. any one of the data items listed inside the
square bracket can occur.
For example, [a,b] represents either a occurs
or b occurs.
40
Data Definition
( ): contents inside the bracket
represent optional data
which may or may not appear.
a+(b) represents either a or a+b
occurs.
{}: represents iterative data
definition,
e.g. {name}5 represents five name
data.
41
Data Definition
{name}* represents
zero or more instances of name data.
= represents equivalence,
e.g. a=b+c means that a represents b
and c.
* *: Anything appearing within *
* is considered as comment.
42
Software
numbers=valid-numbers=a+b+c
a:integer * input number *
b:integer * input number *
c:integer * input number *
asq:integer
bsq:integer
csq:integer
squared-sum: integer
Result=[RMS,error]
RMS: integer * root mean square value*
error:string * error message*
43
Software
a b
c
0.3.1.1 0.3.1.2 0.3.1.3
bsq
asq csq
Sum
0.3.1.4
Squared-sum
44
Question
What is the purpose of {} in data

dictionary?
a) It define the composition of data
b) Iterative data
c) Common data
d) Comment section
45
How is Structured Analysis
Performed?
Initially represent the software
at the most abstract level:
called the context diagram.
the entire system is represented
as a single bubble,
this bubble is labelled according
to the main function of the
system.
46
Tic-tac-toe: Context
Diagram
Tic-tac-toe
display software
move
Human Player
47
Context Diagram
A context diagram shows:
data input to the system,
output data generated by
the system,
external entities.
The context diagram is also
called as the level 0 DFD.
48
Context Diagram
Context diagram
establishes the context of the
system, i.e.
represents:
Data sources
Data sinks.
49
Level 1 DFD
Examine the SRS document:
Represent each high-level
function as a bubble.
Represent data input to every
Represent data output from every
50
Level 1 DFD
Display- game
board
move 0.1 result
Validate- Check-
move board winner
0.2 0.4
Play-
move
0.3
51
Higher level DFDs
Each high-level function is
separately decomposed into
subfunctions:
identify the subfunctions of the
function
identify the data input to each
subfunction
identify the data output from each
subfunction
These are represented as DFDs.
52
Decomposition
Decomposition of a bubble:
also called factoring or
exploding.
Each bubble is decomposed
to
between 3 to 7 bubbles.
53
Decomposition
Too few bubbles make

decomposition superfluous:
if a bubble is decomposed to
just one or two bubbles:
then this decomposition is
redundant.
54
Decomposition
Too many bubbles:

more than 7 bubbles at
any level of a DFD
make the DFD model hard
to understand.
55
Decompose how long?
Decomposition of a
bubble should be carried
on until:
a level at which the
function of the bubble can
be described using a
simple algorithm.
56
Question
Which of the following team is know as

decomposition of bubbles?
a) Sub-Functions
b) Factoring
c) Exploding
d) Both B and C
57
Balancing a DFD
Data flowing into or out of a bubble:
must match the data flows at the next level
of DFD.
This is known as balancing a DFD
In the level 1 of the DFD,
data item c flows into the bubble P3 and the
data item d and e flow out.
In the next level, bubble P3 is
decomposed.
The decomposition is balanced as data item c
flows into the level 2 diagram and d and e
flow out. 58
Balancing a DFD
c
b c
c1
d1
a d
e
Level 1 d e1
e
Level 2
59
Numbering of Bubbles:
Number the bubbles in a DFD:
numbers help in uniquely identifying any
bubble from its bubble number.
The bubble at context level:
assigned number 0.
Bubbles at level 1:
numbered 0.1, 0.2, 0.3, etc
When a bubble numbered x is
decomposed,
its children bubble are numbered x.1, x.2,
x.3, etc.
60
Software
Consider a software called RMS

calculating software:
reads three integers in the range
of -1000 and +1000
finds out the root mean square
(rms) of the three input numbers
displays the result.
61
Software
The context diagram is

simple to develop:
The system accepts 3
integers from the user
returns the result to him.
62
Software
Data- Compute-
items RMS
0
User result
Context Diagram
63
Software
From a cursory analysis of

the problem description:
we can see that the
system needs to perform
several things.
64
Software
Accept input numbers from

the user:
validate the numbers,
calculate the root mean
square of the input numbers
display the result.
65
Software
numbers
Read- Validate-
numbers numbers
0.1 0.2
Valid -
Data- numbers
items error
Compute-
Display rms
0.4 0.3
result RMS
66
Software
Squared-
Calculate- sum Calculate-
squared-sum mean
0.3.1 0.3.2
Valid - Mean-
numbers square
Calculate-
root
0.3.3
RMS
67
Software
b
a c
0.3.1.1 0.3.1.2 0.3.1.3
bsq
asq csq
Sum
0.3.1.4
Squared-sum
68
Software
Decomposition is never
carried on up to basic
instruction level:
a bubble is not decomposed
any further:
if it can be represented by a
simple set of instructions.
69
Computer Game
unmarked square.
on the square wins.
70
Example: Tic-Tac-Toe
Computer Game
the computer wins,
displayed.
game.
71
Context Diagram for
Example
Tic-tac-toe
software
display 0
move
Human Player
72
Level 1 DFD
Display- game
board
move 0.1 result
Validate- Check-
move board winner
0.2 0.4
Play-
move
0.3
73
Data dictionary
Display=game + result
move = integer
board = {integer}9
game = {integer}9
result=string
74
Software engineering
USER INTERFACE
DESIGN
Characteristics of a user
interface
 Speed of learning.
 Speed of use
 Speed of recall.
 Error prevention
 Attractiveness.
 Consistency.
 Feedback.
 Error recovery (undo facility).
 User guidance and on-line help.
BASIC CONCEPTS:
Mode-based interface vs. modeless
interface
 A mode is a state or collection of states in which

only a subset of all user interaction tasks can be
performed.
 In a modeless interface, the same set of commands
can be invoked at any time during the running of the
software. Thus, a modeless interface has only a
single mode and all the commands are available all
the time during the operation of the software.
 On the other hand, in a mode-based interface,
different set of commands can be invoked
depending on the mode in which the system is.
Graphical User Interface vs.
Text-based User Interface
⚫ In a GUI multiple windows with different

information can simultaneously be displayed
on the user screen. This is perhaps one of
the biggest advantages of GUI over text-
based interfaces.
⚫ Iconic information representation and
symbolic information manipulation is
possible in a GUI.
Text-based
Interface
Graphical
User
Interface
 A GUI usually supports command
selection using an attractive and user-
friendly menu selection system.
 In a GUI, a pointing device such as a
mouse or a light pen can be used for
issuing commands. The use of a
pointing device increases the efficacy
issue procedure.
Some advantages about
TBUI
 On the other hand, a text-based user

interface can be implemented even on
a cheap alphanumeric display
terminal.
 Graphics terminals are usually much
more expensive than alphanumeric
terminals.
Types of user interfaces
 User interfaces can be classified into

the following three categories:
⚫ • Command language based
interfaces
⚫ • Menu-based interfaces
⚫ • Direct manipulation interfaces
Command Language-based
Interface
 A command language-based interface – as the name

itself suggests, is based on designing a command
language which the user can use to issue the
commands.
 The user is expected to frame the appropriate
commands in the language and type them in
appropriately whenever required.
 A command language-based interface can be made
concise requiring minimal typing by the user.
 Command language-based interfaces allow fast
interaction with the computer and simplify the input of
complex commands.
Menu-based Interface
 An important advantage of a menu-based
interface over a command language-based
interface is that a menu-based interface
does not require the users to remember the
exact syntax of the commands.
 A menu-based interface is based on
recognition of the command names, rather
than recollection.
 Further, in a menu-based interface the
typing effort is minimal as most interactions
are carried out through menu selections
using a pointing device.
Menu-based Interface
Direct Manipulation
Interfaces
 Direct manipulation interfaces present the interface to
the user in the form of visual models (i.e. icons or
objects).
 For this reason, direct manipulation interfaces are
sometimes called as iconic interface.
 In this type of interface, the user issues commands by
performing actions on the visual representations of the
objects, e.g. pull an icon representing a file into an icon
representing a trash box, for deleting the file.
 Important advantages of iconic interfaces include the
fact that the icons can be recognized by the users very
easily, and that icons are language-independent.
Direct Manipulation
Interface
UNIFIED
PROCESS
WHAT IS THE UNIFIED PROCESS
The unified process is an extensible framework which
needs to be customized for specific type of projects.
The two main characteristics of the unified process are:
use case-driven and iterative
The leading object-oriented methodology for the
development of large-scale software
Maps out when and how to use the various UML
techniques
THE MOST IMPORTANT UP IDEA:
ITERATIVE DEVELOPMENT
• The use case model is the central model. All models that are constructed in the subsequent design
activities must conform to use case model.
• In this approach, development is organized into a series of short, fixed-length (for example, four
week) mini-projects called iterations.
• The outcome of each is a tested, integrated, and executable system.
• Each iteration includes its own requirements analysis, design, implementation, and testing activities.
ITERATIVE AND INCREMENTAL
DEVELOPMENT
• The system grows incrementally over time, iteration by iteration, and thus this approach is also
known as iterative and incremental development.
BENEFITS OF ITERATIVE DEVELOPMENT
It includes:
• early rather than late mitigation of high risks (technical, requirements, objectives, usability, and
so forth)
• early visible progress
• early feedback, user engagement, and adaptation, leading to a refined system that more closely
meets the real needs of the stakeholders
• managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and
complex steps
• the learning within an iteration can be methodically used to improve the development process
itself, iteration by iteration
ITERATION LENGTH
• The UP (and experienced iterative developers) recommends an iteration length between two
and six weeks.
• Much less than two weeks, and it is difficult to complete sufficient work to get meaningful
throughput and feedback;
• Much more than six or eight weeks, and the complexity becomes rather overwhelming, and
feedback is delayed.
• A very long iteration misses the point of iterative development.
• Short is good.
THE UP PHASES
The unified process involves iterating over the following four phases as following:
1.Inception— During the phase, the scope of the project is defined and Prototype may be
developed to form a clear idea of the project .
2.Elaboration—In this phase, the functional and non functional requirements are captured.
3.Construction- During this phase analysis, design, and implementation activity is carried out. Full
text description of use case are written during the construction phase and each use case is taken up
for the start of new iteration.
4.Transition—Produces beta-release system. During this phase the product is installed in the user’s
environment and maintained.
QUESTION
• In which phase of unified process development of the software will

be done?
a) Inception
b) Elaboration
c) Construction
d) Transition
Object-Oriented
Software Design
1
Object-oriented Concepts
Basic Mechanisms:
Objects:
A real-world entity.
A system is designed as a set of
interacting objects.
Consists of data (attributes) and
functions (methods) that operate on data
Hides organization of internal information
(Data abstraction)
Examples: an employee, a book etc.
2
m8 m7
mi are methods
of the object
m1 m6
Data
m2 m5
Object
m3 m4
Model of an object
3
Class:
Instances are objects
Template for object creation
Examples: set of all employees, different
types of book
4
Methods and message:
Operations supported by an object
Means for manipulating the data of
other objects
Invoked by sending message
Examples: calculate_salary, issue-
book, member_details, etc.
5
Inheritance:
Allows to define a new class (derived
class) by extending or modifying existing
class (base class)
Represents Generalization-
specialization relationship
Allows redefinition of the existing
methods (method overriding)
6
Multiple Inheritance:
Subclass can inherit attributes and
methods from more than one base class
Multiple inheritance is represented by

arrows drawn from the subclass to each of
the base classes
7
LibraryMember Base Class LibraryMember Base Class

Multiple
Inheritance
Derived
Faculty Students Staff Faculty Students Staff
Classes
UnderGrad PostGrad Research UnderGrad PostGrad Research
8
Key Concepts:
Abstraction:
Consider aspects relevant for certain
purpose
Suppress non-relevant aspects
Supported at two levels i.e. class level
where base class is an abstraction &
object level where object is a data
abstraction entity
9
Advantages of abstraction:
Reduces complexity of software
Increases software productivity
It is shown that software
productivity is inversely proportional
to software complexity
10
Encapsulation:
Objects communicate outside world
through messages
Objects data encapsulated within its
methods
11
m4
m3
m5
m2 Data
m6
m1
Methods
Concept of encapsulation
12
Polymorphism:
Denotes to poly (many) morphism
(forms)
Same method call result in different
actions by different objects (static
binding)
13
Dynamic binding:
In inheritance hierarchy, an object can be
assigned to another object of its ancestor class
A method call to an ancestor object would

result in the invocation of appropriate method
of object of the derived class
14
Dynamic binding:
Exact method cannot be known at compile
time
Dynamically decided at runtime
15
Question
The same operation may apply to two or

more classes is called what?
a) Inheritance
b) Polymorphism
c) Encapsulation
d) Multiple classification
16
Advantages
of Object-oriented design
Code and design reuse
Increased productivity
Ease of testing & maintenance
Better understandability
Its agreed that increased
productivity is chief advantage
17
Advantages
of Object-oriented design
Initially incur higher costs, but
after completion of some projects
reduction in cost become possible
Well-established OO methodology
and environment can be managed
with 20-50% of traditional cost
of development
18
Object
modelling using UML
UML is a modelling language
Not a system design or
development methodology
Used to document object-
oriented analysis and design
Independent of any specific
design methodology
19
UML
Based Principally on
OMT [Rumbaugh 1991]
Booch’s methodology[Booch 1991]
OOSE [Jacobson 1992]
Odell’s methodology[Odell 1992]
Shlaer and Mellor [Shlaer 1992]
20
UML
OMT
UML
Booch
OOSE Methodology
Different object modelling techniques in UML
21
Why UML is required?
Model is required to capture only

important aspects
UML a graphical modelling tool, easy
to understand and construct
Helps in managing complexity
22
UML diagrams
Nine diagrams to capture

different views of a system
Provide different perspectives of
the software system
Diagrams can be refined to get
the actual implementation of the
system
23
UML diagrams
Views of a system
User’s view
Structural view
Behavioral view
Implementation view
Environmental view
24
UML diagrams
Behavioural View
Structural View
- Sequence Diagram
- Class Diagram - Collaboration Diagram
- Object Diagram - State-chart Diagram
- Activity Diagram
User’s View
-Use Case
Diagram
Implementation View Environmental View

- Component Diagram - Deployment Diagram
Diagrams and views in UML

25
Are all views required?
NO
Use case model, class diagram and one
of the interaction diagram for a simple
system
State chart diagram in case of many
state changes
Deployment diagram in case of large
number of hardware components
26
Use Case model
Consists of set of “use cases”

An important analysis and design
artifact
Other models must confirm to this
model
Not really an object-oriented model
Represents a functional or process
model
27
Use Cases
Different ways in which system can be used

by the users
Corresponds to the high-level requirements
Represents transaction between the user and
the system
Define behavior without revealing internal
structure of system
Set of related scenarios tied together by a
common goal
28
Question
Why use case model is required?

a) For describing the internal functionality
b) To describe the different way of user
interaction
c) For system specification
d) None of above
29
Use Cases
Normally, use cases are independent

of each other
Implicit dependencies may exist
Example: In Library Automation
System, renew-book & reserve-book
are independent use cases. But in
actual implementation of renew-book,
a check is made to see if any book has
been reserved using reserve-book
30
Example of
Use Cases
For library information system
issue-book
Query-book
Return-book
Create-member
Add-book, etc.
31
Representation of
Use Cases
Represented by use case diagram
Use case is represented by ellipse
System boundary is represented by
rectangle
Users are represented by stick
person icon (actor)
Communication relationship
between actor and use case by line
External system by stereotype
32
Example of Use Cases
Play Move
Player Tic-tac-toe game
Use case model
33
Why develop
Use Case diagram?
Serves as requirements specification
Users identification helps in
implementing security mechanism
through login system
Another use in preparing the
documents (e.g. user’s manual)
34
Factoring
Use Cases
Complex use cases need to be factored
into simpler use cases
Represent common behavior across
different use cases
Three ways of factoring
Generalization
Includes
Extends
35
Factoring Using
Generalization
Pay membership fee
Pay through credit card Pay through library pay card
Use case generalization
36
Factoring Using Includes
<<include>> Common
Base use case
use case
Use case inclusion
Base use case Base use case
<<include>>
<<include>>
<<include>> <<include>>
Base use case Base use case Base use case
Paralleling model 37
Factoring Using Extends
Base <<extends>> Common

use case use case
Use case extension
38
Question
Which symbol is used for the use case?

a) Rectangle
b) Circle
c) Ellipse
d) Stick person
39
Class diagram
Describes static structure of a system

Main constituents are classes and their
relationships:
Generalization
Aggregation
Association
Various kinds of dependencies
40
Class diagram
Entities with common features, i.e.

attributes and operations
Classes are represented as solid
outline rectangle with compartments
Compartments for name, attributes &
operations
Attribute and operation compartment
are optional for reuse purpose
41
Example of
Class diagram
LibraryMember LibraryMember LibraryMember

Member Name Member Name
Membership Number Membership Number
Address Address
Phone Number Phone Number
E-Mail Address E-Mail Address
Membership Admission Date Membership Admission Date
Membership Expiry Date Membership Expiry Date
Books Issued Books Issued
issueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
Different representations of the LibraryMember class
42
Association Relationship
1 borrowed by *
Library Member Book
Association between two classes
43
Aggregation Relationship
Represent a whole-part relationship
Represented by diamond symbol at
the composite end
Cannot be reflexive(i.e. recursive)
Not symmetric
It can be transitive
44
Aggregation Relationship
1 * 1
Document Paragraph * Line
Representation of aggregation
45
Composition Relationship
Life of item is same as the order
1 *
Order Item
Representation of composition
46
Class Dependency
Dependent Class Independent Class
Representation of dependence between class
47
48
Object diagram
LibraryMember LibraryMember LibraryMember
Mritunjay Mritunjay
B10028 B10028
C-108, Laksmikant Hall C-108, Laksmikant Hall
1119 1119
Mrituj@cse Mrituj@cse
25-02-04 25-02-04
25-03-06 25-03-06
NIL NIL
IssueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
Different representations of the LibraryMember object
49
Object diagram
50
Question
Which Symbols is used to represent

composition between the classes?
a) Arrow
b) Solid Diamond
c) Triangle
d) Diamond
51
Interaction diagram
Models how groups of objects
collaborate to realize some behaviour
Typically each interaction diagram
realizes behaviour of a single use case
Two kinds: Sequence & Collaboration
These diagram play a very important
role in the design process
52
Sequence diagram
Shows interaction among objects as two-
dimensional chart
Objects are shown as boxes at top
If object created during execution then
shown at appropriate place
Objects existence are shown as
dashed lines (lifeline)
Objects activeness, shown as
rectangle on lifeline
53
Sequence diagram
Messages are shown as arrows

Message labelled with message name
Message can be labelled with control
information
Two types of control information:
condition ([]) & an iteration (*)
54
Example of
Sequence diagram
:Library
:Library
:Library Book :Library
Book :Book
Boundary Renewal Member
Register
Controller
renewBook find MemberBorrowing

displayBorrowing
selectBooks bookSelected
* find
[reserved]
[reserved] apology
update
apology
confirm
confirm
updateMemberBorrowing
Sequence Diagram for the renew book use case

55
Collaboration diagram
Shows both structural and behavioural
aspects
Objects are collaborator, shown as boxes
Messages between objects shown as a solid
line
Message is shown as a labelled arrow
placed near the link
Messages are prefixed with sequence
numbers to show relative sequencing
56
Example of
Collaboration diagram
6: * find
:Library
Book :Book
[reserved] Register
9: update
8: apology 5: book 10: confirm
Selected
1: renewBook :Library [reserved]
:Library Book 7: apology
Boundary 3: display Renewal
Borrowing Controller
4: selectBooks
2: findMemberBorrowing
12: confirm
:Library
Member
updateMemberBorrowing
Collaboration Diagram for the renew book use case

57
Activity diagram
New concept, possibly based on event
diagram of Odell [1992]
Represent processing activity, may not

correspond to methods
Activity is a state with an internal

action and one/many outgoing
transition
58
Activity diagram
Can represent parallel activity and
synchronization aspects
Swim lanes enable to group activities

based on who is performing them
Example: academic department vs.

hostel
59
Activity diagram
Normally employed in business process
modelling
Carried out during requirement analysis

and specification
Can be used to develop interaction

diagrams
60
Example of
Activity diagram
Academic Section Accounts Section Hostel Office Hospital Department
check
student
records
receive
fees
allot create
hostel hospital
record
register
receive
in
fees
course
conduct
allot medical
room examination
issue
identity card
Activity diagram for student admission procedure at IIT
61
State Chart diagram
Based on the work of David Harel
[1990]
Model how the state of an object

changes in its lifetime
Based on finite state machine (FSM)

formalism
62
State Chart diagram
Elements of state chart diagram
Initial State: Filled circle
Final State: Filled circle inside larger
circle
State: Rectangle with rounded corners
Transitions: Arrow between states,
also boolean logic condition (guard)
63
Example of
State Chart diagram
order received
Unprocessed
Order
[reject] checked [accept] checked
Rejected Accepted
Order Order
[some items available]
[some items not processed / deliver
available] processed
[all items
Pending available] Fulfilled
Order newsupply Order
Example: State chart diagram for an order object

64
Question
Which UML diagram represent the large

hardware component requirement?
a) Use case diagram
b) Deployment Diagram
c) Sequence Diagram
d) State chart Diagram
65
Computer Game
unmarked square.
on the square wins.
66
Computer Game
the computer wins,
displayed.
game.
67
Example 1: Use Case Model
Play Move
Player Tic-tac-toe game
68
Example 1: Sequence Diagram
:playMove :playMove
:board
Boundary Controller
acceptMove checkMoveValidity
move
[invalidMove] [invalidMove]
announceInvalidMove
announceInvalidMove
checkWinner
[game over]
[game over] announceResult
announceResult
playMove
checkWinner
[game over] [game over]

announceResult announceResult
displayBoardPositions getBoardPositions
[game not over]

promptNextMove
Sequence Diagram for the play move use case

69
Example 1: Class Diagram
Board PlayMoveBoundary
int position[9]
checkMove Validity announceInvalidMove

checkResult announceResult
playMove displayBoard
Controller
announceInvalidMove
announceResult
70
Example 2: Supermarket Prize
Scheme
Supermarket needs to develop
software to encourage regular
customers.
Customer needs to supply his
residence address, telephone
number, and the driving licence
number.
Each customer who registers is
assigned a unique customer
number (CN) by the computer.
71
Scheme
A customer can present his CN to
the staff when he makes any
purchase.
The value of his purchase is
credited against his CN.
At the end of each year, the
supermarket awards surprise gifts
to ten customers who make highest
purchase.
72
Scheme
Also, it awards a 22 carat gold coin
to every customer whose purchases
exceed Rs. 10,000.
The entries against the CN are reset
on the last day of every year after
the prize winner’s lists are
generated.
73
Example 2: Use Case Model
register
Customer customer Clerk
register
sales
Sales Clerk
select
winners
Supermarket
Prize scheme
Manager
74
Example 2: Sequence Diagram for
the Select Winners Use Case
:SelectWinner :SelectWinner :Sales :Sales :Customer :Customer
Boundary Controller History Record Register Record
Select
SelectWinners
Winners
SelectWinners
*computeSales
*browse
[for each winner]

find WinnerDetails [for each winner]
announces
browse
Sequence Diagram for the select winners use case

75
the Register Customer Use Case
:SelectWinner :SelectWinner :Customer :Customer
Boundary Controller Register Record
register
register
checkDuplicate
*match
[duplicate]
showError
generateCIN
create
register :Customer
Record
displayCIN
Sequence Diagram for the register customer use case

76
the Register Sales Use Case
:Register :Register
:Sales
Sales Sales
History
Boundary Controller
RegisterSales registerSales
registerSales
create :Sales
Record
confirm
confirm
Sequence Diagram for the register sales use case
77
the Register Sales Use Case
:Register
:Sales
Sales
History
Boundary
registerSales
RegisterSales
create :Sales
Record
confirm
Refined Sequence Diagram for the register sales use case
78
Example 1: Class Diagram
SalesHistory CustomerRegister
selectWinners findWinnerDetails
registerSales register
1 1
* *
SalesRecords CustomerRecord
salesDetails name
address
computerSales browse
browse checkDuplicate
create create
79
Summary
We discussed object-oriented
concepts
Basic mechanisms: Such as objects,
class, methods, inheritance etc.
Key concepts: Such as abstraction,
encapsulation, polymorphism,
composite objects etc.
80
Summary
We discussed an important OO language
UML
Its origin, as a standard, as a model
Use case representation, its factorisation
such as generalization, includes and extends
Different diagrams for UML representation
In class diagram we discussed some
relationships association, aggregation,
composition and inheritance
81
Summary
Some more diagrams such as
interaction diagrams (sequence and
collaboration), activity diagrams,
state chart diagram
We discussed OO software
development process and patterns
In this we discussed some patterns
example and domain modelling
82
Coding
At the end of the design phase we have:
module structure of the system
module specifications:
data structures and algorithms for each module.
Objective of coding phase:
transform design into code
unit test the code.
1
Coding Standards
Good software development
organizations require their
programmers to:
adhere some standard style of
coding
called coding standards.
2
Coding Standards
Many software development
organizations:
formulate their own coding
standards that suits them most,
require their engineers to follow
these standards.
3
Coding Standards
Advantage of adhering to a
standard style of coding:
it gives a uniform appearance to
the codes written by different
engineers,
it enhances code understanding,
encourages good programming
practices.
4
Coding Standards
A coding standard
sets out standard ways of
doing several things:
the way variables are named,
code is laid out,
maximum number of source
lines allowed per function, etc.
5
Question
Why it is required to have certain coding

standards?
a) To have correct syntax
b) To prevent errors
c) For better understanding
d) All of above
6
Coding guidelines
Provide general suggestions
regarding coding style to be
followed.
7
Coding Standards and
Guidelines
Good organizations usually develop
their own coding standards and
guidelines:
depending on what best suits their
organization.
8
Representative Coding
Standards
Rules for limiting the use of global:
what types of data can be declared
global and what can not.
Naming conventions for
global variables,
local variables, and
constant identifiers.
9
Standards
Contents of headers for different
modules:
The headers of different modules
should be standard for an
organization.
The exact format for header
information is usually specified.
10
Standards
Header data:
Name of the module,
date on which the module was created,
author's name,
modification history,
synopsis of the module,
different functions supported, along with
their input/output parameters,
global variables accessed/modified by the
module.
11
Standards
Naming conventions for global

variables, local variables, and
constant identifiers: A possible naming
convention can be that global variable
names always start with a capital letter,
local variable names are made of small
letters, and constant names are always
capital letters.
12
Standards
Error return conventions and
exception handling mechanisms.
the way error and exception
conditions are handled should be
standard within an organization.
For example, when different functions
encounter error conditions
should either return a 0 or 1 consistently.
13
Guidelines
Do not use too clever and difficult to

understand coding style.
Code should be easy to understand.
Many inexperienced engineers actually
take pride:
in writing cryptic and incomprehensible
code.
14
Guidelines
Clever coding can obscure meaning
of the code:
hampers understanding.
makes later maintenance difficult.
Avoid obscure side effects.
15
Guidelines
Code should be well-documented.
Rules of thumb:
on the average there must be at least
one comment line
for every three source lines.
The length of any function should not
exceed 10 source lines.
16
Guidelines
Lengthy functions:
usually very difficult to
understand
probably do too many different
things.
17
Guidelines
Do not use goto statements.

Use of goto statements:
make a program unstructured
make it very difficult to
understand.
18
Code review
Code review for a model is carried out after the

module is successfully compiled and the all the
syntax errors have been eliminated.
Normally, two types of reviews are carried out
on the code of a module.
These two types code review techniques are
code inspection and code walkthrough.
19
Code Walkthrough
An informal code analysis technique.
undertaken after the coding of a module is
complete.
A few members of the development team
select some test cases:
simulate execution of the code by hand using
these test cases.
Discussion should focus on discovery of
errors:
and not on how to fix the discovered errors.
20
Code Walkthrough
The main objectives of the walk through are to

discover the algorithmic and logical errors in the
code.
The members note down their findings to
discuss these in a walk through meeting where
the coder of the module is present.
The team performing code walk through should
not be either too big or too small.
Ideally, it should consist of between three to seven
members.
21
Code Inspection
In contrast to code walk through, the aim of code
inspection is to discover some common types of errors
caused due to oversight and improper programming.
In addition to the commonly made errors, adherence to
coding standards is also checked during code inspection.
Good software development companies collect statistics
regarding different types of errors commonly committed
by their engineers and identify the type of errors most
frequently committed.
Such a list of commonly committed errors can be used
during code inspection to look out for possible errors.
22
Commonly made errors
Use of uninitialized variables.
Nonterminating loops.
Array indices out of bounds.
Improper storage allocation and
deallocation.
Actual and formal parameter mismatch in
procedure calls.
Jumps into loops.
23
Question
What is the purpose of code inspection?

a) To verify the syntax of program
b) To discover the algorithmic error
c) To discover the module error
d) None of above
24

Cse 320

Uploaded by

Document Information

Original Title

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

Cse 320

Uploaded by

Copyright:

Available Formats

Lecture Zero

**** 2 best out of three****

• MTT:-- All MCQs

• Manage a project including planning, scheduling,

• Recognize current trends in the area of software

• What is software? Is it different from Program?

• What is Software Engineering?

• Why Software Engineering?

• What are learning outcomes?

❑ Computer programs and associated documentation

❑ Software products may be developed for a particular customer or

Software engineers should

First law of software engineering

Software Engineer’s task:

May be the Programmer’s task:

➢Specifying software problems and solutions is like cartoon strip

• Useful + good software lives long

• To nurture software, people must be able to understand it

➢Method = work strategy

4. “Once we get the program running, we are done”

5. “The only product is the running program”

• The various software crises are:

• Engineering approach to develop

• Usually small in size • Large

• The principle of abstraction

−life cycle models,

• Use of Life Cycle Models

• Emphasis has shifted

• Projects are being thoroughly

Unstructured Program Structured Program

• Need of Data Structure-oriented

• Data flow-oriented techniques:

Data Flow diagram of Car Assembly Plant

• Planning and Requirement analysis.

• The development team must

• When a software product is being

• A life cycle model:

• The phase exit criteria for the software

• It becomes easier for software

• Many life cycle models have been

• Most organizations usually define:

• Every other model is based on

• Gathering relevant data:

• The data you initially collect

• Ambiguities and contradictions:

• Consists of two activities:

• Carried out using Data flow

• First identify various objects (real

• During the implementation

• The purpose of unit testing:

• After all the modules have been

What is the first step in the software

• Defects usually get detected

• Once a defect is detected:

• Errors should be detected

• The principle of detecting errors as close to

To determine what the candidate

Also known as cost benefit analysis

It checks whether the existing computer system

An estimate should be made of how strong a

Form a project team and appoint a project

Determine and evaluate performance and

A. Includes a statement of the problems

2 best out of three