Introduction

1
 IEEE Definition
• “Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software; that is, the application of engineering to
software.”

3
 Software Crisis (cont.)

Laptop or Desktop =
Rs.45,000/-
Rational suite node locked =
Hw cost Rs.3,14,600/-
Sw cost
Rational suite floating license=
Rs.6,03,200/-

1960 Year 2018

Relative Cost of Hardware and Software
5
28% Successful

49% Delayed or
cost overrun

23% Cancelled

Standish Group Report

Programming: an Art or
Engineering? Technology
Development
Pattern
Esoteric Past
Experience Engineering
Technology

Craft
Systematic Use of Past
Experience and Scientific
Basis
Unorganized Use of
Past Experience
Art Time
9
 What is Exploratory Software Development?
• Early programmers used exploratory (also called build and fix) style.
• A `dirty' program is quickly developed.
• The bugs are fixed as and when they are noticed.
• Similar to how a junior student develops programs…

11
 What is Wrong with the Exploratory Style?

• Can successfully be used for developing only

very small (toy) programs.

Software
Exploratory Engineering
time, cost

Machine
Effort,

Program Size 13
 What is Wrong with the Exploratory Style? Cont…

• Why does the effort required to

develop a software grow
Software
exponentially with size? Exploratory Engineering

Effort, time,
Machine

• Why does the approach

cost
completely breaks down
Program Size
when the size of software
becomes large? 15
 Human Cognition Mechanism
• Suppose I ask: “It is 10:10AM now,
how many hours are remaining today?"
• 10AM would be stored in the short-term memory.
• “A day is 24 hours long.” would be fetched from the
long term memory into short term memory.

• The mental manipulation unit would compute the

difference (24-10).

17
• An item stored in the short Short Term
term memory can get lost: Memory
• Either due to decay with time or
• Displacement by newer information.
• This restricts the time for which an item is
stored in short term memory:
• Typically few tens of seconds.
• However, an item can be retained longer in the
short term memory by recycling.
19
 Chunking
• If I ask you to remember the number
110010101001
• It may prove very hard for you to understand
and remember.
• But, the octal form of 6251 (110)(010)(101)(001)
would be easier.
• You have managed to create chunks of three
items each. 21
• If a person deals with seven or less number of
items: The Magical Number 7
• These would be accommodated in the short term memory.
• So, he can easily understand it.

• As the number of new information increases

beyond seven:
• It becomes exceedingly difficult to understand it.

23
 Implication in Program Development
• Instead of a human, if a machine could be writing
(generating) a program,
• The slope of the curve would be linear.
• But, how does use of software engineering principles
helps hold down the effort-size curve to be almost
linear?
• Software engineering principles extensively use
techniques specifically targeted to overcome the
25

human cognitive limitations.

 Two Fundamental
Techniques to Handle
Complexity

27
Abstraction Example
• Suppose you are asked to develop an
overall understanding of some country.
• Would you:
• Meet all the citizens of the country, visit every
house, and examine every tree of the country?
• You would possibly refer to various types of
maps for that country only. 29
Does every Problem have a single Abstraction?
• Several abstractions of the
same problem can be created:
• Focus on some specific
aspect and ignore the rest.
• Different types of models
help understand different
aspects of the problem.
31
Abstraction of Complex Problems -- An Example
• Suppose you are asked to understand all life forms
that inhabit the earth.

• Would you start examining each living organism?

• You will almost never complete it.
• Also, get thoroughly confused.
• Solution: Try to build an abstraction hierarchy.
33
 Quiz
• What is a model?
• Why develop a model? That is, how
does constructing a model help?

• Give some examples of models.

35
 Decomposition
• A popular example of decomposition
principle:
• Try to break a bunch of sticks tied
together versus breaking them individually.

• Any arbitrary decomposition

of a problem may not help.
• The decomposed parts must 37

be more or less independent of each other.

 Why Study Software Engineering? (1)

• To acquire skills to develop large

programs.
• Handling exponential growth in
complexity with size.
• Systematic techniques based on
abstraction (modelling) and
decomposition. 39
 Why Study Software Engineering? (3)

• To acquire skills to be a better

programmer:
•Higher Productivity
•Better Quality Programs
41
• Two types of software projects:
• Products (Generic software) Types of
Software
• Services (custom software) Projects

• Total business – Several Trillions of US $

• Half in products and half services
• Services segment is growing fast!
43
 Types of Software Projects

• Software product development

projects

• Software services projects

2
Factors responsible for accelerated growth of
services…
• Now lots of code is available in a company:
– New software can be developed by modifying the
closest.

• Speed of Conducting Business has increased

tremendously:
– Requires shortening of project duration

4
Scenario of Indian Software Companies

• Indian companies have

largely focused on the
services segment --- Why?

6
 Traditional versus Modern Projects
• Projects are increasingly becoming services:
– Either tailor some existing software or reuse pre-built
libraries.
• Facilitate and accommodate client feedbacks
• Facilitate customer participation in project
development work
• Incremental software delivery with evolving
functionalities.
• No software is being developed from scratch ---
Significant reuse is being made…
8
Computer Systems Engineering
• The high-level problem:
–Deciding which tasks are to be solved by
software.
–Which ones by hardware.

10
 Computer Systems Engineering (CONT.)
Feasibility
Study

Requirements
Analysis and
Specification Hardware
Development
Hardware
Software
Partitioning Software
Development
Integration
and Testing

Project Management

12
Emergence of Software Engineering Techniques

• Early Computer Programming

(1950s):
–Programs were being written in
assembly language…
–Sizes limited to about a few hundreds
of lines of assembly code…
14
High-Level Language Programming (Early 60s)

• High-level languages such as FORTRAN,

ALGOL, and COBOL were introduced:

 This reduced software development

efforts greatly.

 Why reduces?

16
 Control Flow-Based Design (late 60s)
• Size and complexity of programs increased
further:
–Exploratory programming style proved to be
insufficient.

• Programmers found:
–Very difficult to write cost-effective and
correct programs.
18
 Control Flow-Based Design (late 60s)
• What is a program's control
structure?
– Sequence in which a program's
instructions are executed.

• To help design programs having

good control structure:
–Flow charting technique was
developed.
20
 Control Flow-Based Design

• A program having a messy flow chart

representation:
–Difficult to understand and debug.

22
 Control Flow-Based Design (Late 60s)
• What causes program complexity?
–GO TO statements makes control
structure of a program messy.
–GO TO statements alter
the flow of control arbitrarily.
–The need to restrict use of GO TO statements
was recognized.

24
 Control-flow Based Design (Late 60s)
• At that time, Dijkstra published his
article:
–“Goto Statement Considered Harmful”
Comm. of ACM, 1969.
• Many programmers were unhappy to
read his article.
26
 Control Flow-Based Design (Late 60s)
• It soon was conclusively proved:
–Only three programming constructs are
sufficient to express any programming logic:
•sequence (a=0;b=5;)
•selection (if(c==true) k=5 else m=5;)
•iteration (while(k>0) k=j-k;)
28
 Structured Programming
• A program is called structured:
–When it uses only the following types of
constructs:
•sequence,
•selection,
•iteration
–Consists of modules.

30
 Advantages of Structured programming

• Structured programs are:

–Easier to read and understand,
–Easier to maintain,
–Require less effort and time for
development.
–Less buggy

32
 Data Structure-Oriented Design (Early 70s)

• As program sizes increased further, soon

it was discovered:

–It is important to pay more attention to

the design of data structures of a program

• Than to the design of its control structure.

34
 Data Structure Oriented Design (Early 70s)
• An example of data structure-oriented
design technique:

–Jackson's Structured Programming(JSP)

methodology

• Developed by Michael Jackson in 1970s.

36
 A Data Structure Oriented Design (Early
70s)

JSP methodology:

A program's data structures are first

designed using notations for

sequence, selection, and iteration.

 The data structure design is then used :

To derive the program structure.

38
 Data Flow-Oriented Design (Late 70s)

• Data flow-oriented techniques advocate:

–The data items input to a system must first be
identified,
–Processing required on the data items to
produce the required outputs should be
determined.

40
 Data Flow-Oriented Design (Late 70s)
• Data flow technique is a generic
technique:
–Can be used to model the working of any
system.
• not just software systems.

• A major advantage of the data flow

technique is its simplicity.
42
 Software
Conceptualize
Life Cycle
Retire Specify

Design
Maintain

Deliver Code

Test

2
 Life Cycle Model (CONT.)

• Each life cycle phase consists of

several activities.
–For example, the design stage might
consist of:
• structured analysis
• structured design
• Design review
4
 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.
6
 Life Cycle Model (CONT.)

• When software 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 chaos and
project failure.
8
 Phase Entry and Exit Criteria
• 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 are
satisfied.

10
 Life Cycle Model: Milestones

• Milestones help software project

managers:
–Track the progress of the project.
–Phase entry and exit are
important milestones.

12
Project Management Without Life Cycle Model

• It becomes very difficult to track the

progress of the project.
–The project manager would have to
depend on the guesses of the team
members.
• This usually leads to a problem:
–known as the 99% complete syndrome.
14
• Many life cycle models have been proposed.
• We confine our attention to only a few commonly
used models.
–Waterfall Life Cycle Model (CONT.)

–V model,
–Evolutionary, Traditional models
–Prototyping
–Spiral model,
–Agile models
16
 Classical Waterfall Model
• Classical waterfall model divides life
cycle into following phases:
–Feasibility study, Conceptualize

Retire Specify
–Requirements analysis and
Design
specification, Maintain

–Design, Deliver Code

–Coding and unit testing, Test

–Integration and system testing,

–Maintenance. 18
 Relative Effort for Phases
• Phases between feasibility study
and testing
–Called development phases.

Relative Effort
• Among all life cycle phases
–Maintenance phase consumes
maximum effort.
• Among development phases,
–Testing phase consumes the
maximum effort.
 Classical Waterfall Model (CONT.)
• The guidelines and methodologies of an
organization:
–Called the organization's software
development methodology.

• Software development organizations:

– Expect fresh engineers to master the
organization's software development
methodology. 22
• Main aim of feasibility study: determine
whether developing the software is:
– Financially worthwhile Feasibility Study
– Technically feasible.
First Step
• Roughly understand what customer wants:
–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. 24
 Feasibility: Case Study
• Manager visits main office, finds out the
main functionalities required
• Visits mine site, finds out the data to be
input
• Suggests alternate solutions
• Determines the best solution
• Presents to the CFL Officials
• Go/No-Go Decision
26
• Perform a cost/benefit analysis:
–Determine which solution is the best.
–May also find that none of the
solutions is feasible due to:
• high cost, Activities during
Feasibility Study
• resource constraints,
• technical reasons.

28
 The business case
• Benefits of delivered
project must outweigh
Benefits
costs
Costs • Costs include:
- Development
Rs - Operation
Rs • Benefits:
– Quantifiable
– Non-quantifiable

30
1. Executive summary
2. Project background:
 The focus must be on what, exactly, the project is undertaking, and should
not be confused with what might be a bigger picture.

3. Business opportunity
- What difference will it make? Writing an Effective
- What if we don’t do it?
Business Case
4. Costs
- Should include the cost of development, implementation, training, change
management, and operations.

5. Benefits
 Benefits usually presented in terms of revenue generation and cost
reductions.

6. Risks
− Identify risks.
− Explain how these will be managed.
32
 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.
34
 Requirements Gathering
• Gathering relevant data:
–Usually collected from the end-users
through interviews and discussions.
–Example: for a business accounting
software:
• Interview all the accountants of the
organization to find out their requirements.
36
 Requirements Analysis (Cont...)
• Ambiguities and contradictions:
–must be identified
–resolved by discussions with the
customers.

• Next, requirements are organized:

–into a Software Requirements Specification
(SRS) document. 38
 Design
• During design phase requirements
specification is transformed into :
– A form suitable for implementation in
some programming language.
• Two commonly used design
approaches:
–Traditional approach,
–Object oriented approach 40
 Structured Design
root
• High-level design:
order query

–decompose the system into indent

modules, Handle-
order
Handle-indent Handle-
query

–represent invocation
relationships among modules.
Accept-
• Detailed design: Get-
order
order Process-
order

–different modules designed in

greater detail:
• data structures and algorithms for each
module are designed. 42
 Object Oriented Design (CONT.)
• Object structure:

–Refined to obtain the detailed design.

• OOD has several advantages:

–Lower development effort,

–Lower development time,

–Better maintainability.
44
Life Cycle Models

Continued….

1
 Coding and Unit Testing
• During this phase:
–Each module of the design is coded,
–Each module is unit tested
•That is, tested independently as a stand
alone unit, and debugged.

–Each module is documented.

3
 Integration and System Testing
• Different modules are integrated in a
planned manner:
–Modules are usually integrated through a
number of steps. M1 M2 M5 M7

M3 M4 M6 M8
• During each integration step,
–the partially integrated system is tested.
5
Feasibility Study
Classical Waterfall
Req. Analysis Model
Design

Coding

Testing

Maintenance

7
 Types of Maintenance?
• 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,
9
• e.g. to a new computer or to a new operating system.
 Iterative Waterfall Model (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.

–The later the phase in which the defect gets

detected, the more expensive is its removal --
- why?

11
 Iterative Waterfall Model (CONT.)

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

13
 Phase Containment of Errors
• Reason: rework must be carried out not only to the
design but also to code and test phases.
• 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 by far the most widely
used model.
–Almost every other model is derived from the
waterfall model. 15
 Waterfall Strengths
• Easy to understand, easy to use, especially
by inexperienced staff
• Milestones are well understood by the
team
• Provides requirements stability during
development
• Facilitates strong management control
(plan, staff, track) 17
 When to use the Waterfall Model?

• Requirements are well known and

stable

• Technology is understood

• Development team have experience

with similar projects
19
 Classical Waterfall Model (CONT.)

• Metaphor of mathematical theorem

proving:
–A mathematician presents a proof as a single
chain of deductions,

• Even though the proof might have come from

a convoluted set of partial attempts, blind
alleys and backtracks.

21
 What are Requirements?
• A Requirement is:

– A capability or condition required from the system.

• What is involved in requirements analysis and

specification?

– Determine what is expected by the client from the

system. (Gather and Analyze)

– Document those in a form that is clear to the client as

well as to the development team members.
(Document)
 Requirements for Products

• When a company plans to develop a

generic product:

– Who gives the requirements?

• The sales personnel!

Requirements Engineering Process

Feasibility
Study Requirements
gathering
Requirements
analysis
Feasibility Requirements
report specification

SRS Document
• Good SRS reduces development cost:
– Req. errors are expensive to fix later Need for SRS…
– Req. changes cost a lot (typically 40% of requirements
change later)
– Good SRS can minimize changes and errors
– Substantial savings --- effort spent during req. saves
multiple times that effort

Cost
• An Example:
– Cost of fixing errors in req. , design , coding , acceptance
testing and operation increases exponentially
 Forms A Basis for User Manual
• The SRS serves as the basis for writing User
Manual for the software:

– User Manual: Describes the functionality from

the perspective of a user --- An important
document for users.

– Typically also describes how to carry out the

required tasks with examples.
User needs Requirement process..

Gathering
• Specification
Analysis
and review may
Specification
lead to further
gathering and
Review
analysis.
SRS Document
 Requirements Gathering Activities
• 1. Study existing documentation

• 2. Interview

• 3. Task analysis

• 4. Scenario analysis

• 5. Form analysis
 Requirements Gathering (CONT.)

• Some desirable attributes of a good

requirements analyst:

– Good interaction skills,

– Imagination and creativity,

– Experience…
Case Study: Automation of Office Work at CSE Dept.

• The team was first briefed by the HoD:

– Concerning the specific activities to be automated.

• The analysts first discussed with the two office

clerks:
– Regarding their specific responsibilities (tasks) that were
to be automated. Interview

• The analyst also interviewed student and faculty

representatives who would also use the software.
Case Study: Automation of Office Work at CSE Dept.
• The analysts understood the requirements for the
system from various user groups: Requirements Analysis
– Identified inconsistencies, ambiguities, incompleteness.

• Resolved the requirements problems through

discussions with users:
– Resolved a few issues which the users were unable to
resolve through discussion with the HoD.

• Documented the requirements in the form of an

SRS document. Requirements Specification
 Ambiguity
“When temperature becomes high, start
cooler”
Do you notice any problems?

• Above what threshold we consider

the temperature to be high?
• Some requirements not included:
– Possibly due to oversight. Incomplete
Requirement
• Example:
– The analyst has not recorded that when
temperature falls below 90°C :

• heater should be turned ON

• water shower turned OFF.

 Analysis of the Gathered Requirements (CONT.)

• It is quite difficult to obtain:

– A clear, in-depth understanding of the

problem:

•Especially if there is no working model of

the problem.
 Analysis of the Gathered Requirements
(CONT.)

• Experienced systems analysts know -

often as a result of painful experiences ---
– “Without a clear understanding of the
problem, it is impossible to develop a
satisfactory system.”
 Analysis of the Gathered Requirements
• Some anomalies and inconsistencies
can be very subtle:
– Escape even most experienced eyes.

– If a formal specification of the system is

constructed,
• Many of the subtle anomalies and
inconsistencies get detected.
 Software Requirements Specification
needs

• Main aim: Gathering

Analysis
– Systematically organize the
Specification

requirements arrived during

Review

requirements analysis.
SRS
Document

– Document requirements properly.

 SRS Document (CONT.)

• SRS document is known as black-box

specification: Input
Data S Output
Data

– 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.
 SRS Document (CONT.)

• The requirements at this stage:

– Written using end-user terminology.

• If necessary:
– Later a formal requirement specification
may be developed from it.
 Properties of a Good SRS Document
(cont...)

• It should be traceable
– You should be able to trace which part of the
specification corresponds to which part of the
design, code, etc and vice versa.

• It should be verifiable
– e.g. “system should be user friendly” is not
verifiable
 SRS Document (CONT.)

• Four important parts:

– Functional requirements,

– External Interfaces

– Non-functional requirements,

– Constraints
 Functional Requirement
Documentation
• Overview
– describe purpose of the function and the
approaches and techniques employed
• Inputs and Outputs
– sources of inputs and destination of outputs
– quantities, units of measure, ranges of valid
inputs and outputs
– timing
 Nonfunctional Requirements
• Characteristics of the system which can not be
expressed as functions:
• Maintainability,
• Portability,
• Usability,
• Security,
• Safety, etc.
 Constraints
• Hardware to be used,
• Operating system
– or DBMS to be used

• Capabilities of I/O devices

• Standards compliance
• Data representations by the interfaced
system
 Goals of Implementation
• Goals describe things that are desirable
of the system:
– But, would not be checked for compliance.
– For example,
• Reusability issues
• Functionalities to be developed in future
 IEEE 830-1998 Standard – Section 2 of
• Title SRS
• Table of Contents •Present the business case and operational concept of the system
•Describe external interfaces: system, user, hardware, software, communication

• 1. Introduction •Describe constraints: memory, operational, site adaptation

• 2. Overall Description
– 2.1 Product Perspective •Summarize the major functional capabilities

– 2.2 Product Functions

– 2.3 User Characteristics •Describe technical skills of each user class

– 2.4 Constraints
– 2.5 Assumptions and Dependencies
•Describe other constraints that will limit
developer’s options; e.g., regulatory policies;
• 3. Specific Requirements target platform, database, network,
development standards requirements
• 4. Appendices
• 5. Index
 IEEE 830-1998 Standard – Templates

• Section 3 (Specific Requirements)can be

organized in several different ways based on
– Modes
– User classes
– Concepts (object/class)
– Features
– Stimuli
 Design Constraints (3.2)
• 3.2 Design Constraints
• C-001:
– AAS shall provide user interface through standard web
browsers.
• C-002:
– AAS shall use an open source RDBMS such as Postgres
SQL.
• C-003:
– AAS shall be developed using the JAVA programming
language

16
 Functional Requirements
• It is desirable to consider every system as:
– Performing a set of functions {fi}.
• Each function fi considered as:
– Transforming a set of input data to
corresponding output data.
Input Output
Data fi Data
 Functional Requirements
• Functional requirements describe:
– A set of high-level requirements
– Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
– Each high-level requirement:
• might consist of a set of identifiable sub-functions
 Is it a Functional Requirement?
• A high-level function is one:
– Using which the user can get some useful
piece of work done.
• Can the receipt printing work during withdrawal
of money from an ATM:
– Be called a functional requirement?
• A high-level requirement typically involves:
– Accepting some data from the user,
– Transforming it to the required response, and
then
– Outputting the system response to the user.
 Example Functional
• Req. 1: Requirements
– Once user selects the “search” option,
• he is asked to enter the key words.
– The system should output details of all books
• whose title or author name matches any of the key
words entered.
• Details include: Title, Author Name, Publisher name,
Year of Publication, ISBN Number, Catalog Number,
Location in the Library.
 High-Level Function: A Closer View
• A high-level function:
– Usually involves a series of interactions between
the system and one or more users.
• Even for the same high-level function,
– There can be different interaction sequences (or
scenarios)
– Due to users selecting different options or
entering different data items.
 Examples of Bad SRS
Documents
• Noise:
– Presence of text containing information
irrelevant to the problem.

• Silence:
– Aspects important to proper solution of the
problem are omitted.
 Examples of Bad SRS Documents
• Ambiguity:
– Literary expressions
– Unquantifiable aspects, e.g. “good user interface”
• Forward References:
– References to aspects of problem
• defined only later on in the text.
• Wishful Thinking:
– Descriptions of aspects
• for which realistic solutions will be hard to find.
 Suggestions for Writing Good Quality
Requirements

• Split a requirement into multiple sub-

requirements:
– Because each will require separate test
cases and because each should be
separately traceable.
– If several requirements are strung together
in a paragraph, it is easy to overlook one
during construction or testing.
 A Sample SRS Checklist
• Have response times been specified for functions ?

• Have all the HW, external SW and data interfaces

been defined ?

• Is each requirement testable ?

• Is the initial state of the system defined ?

• Are the responses to exceptional conditions

specified ?
 V Model

9/28/2024
1
 Production,
Project Planning Operation &
Maintenance

Requirements System Testing

Specification

Integration
High Level Design Testing

Detailed Design Unit testing

Coding

3
 V Model: Strengths
• Starting from early stages of
software development:
– Emphasizes planning for verification
and validation of the software

• Each deliverable is made testable

• Easy to use
5
 When to use V Model
• Natural choice for systems requiring high
reliability:
– Embedded control applications, safety-
critical software

• All requirements are known up-front

• Solution and technology are known

7
 Prototyping Model
• A derivative of waterfall model.
• Before starting actual development,
– A working prototype of Prototype Construction
the system should first be built. Design

• A prototype is a toy Coding

Testing
implementation of a system: Maintenance

–Limited functional capabilities,

–Low reliability,
–Inefficient performance. 9
 Reasons for Developing a Prototype
• Illustrate to the customer:
–input data formats, messages, reports, or
interactive dialogs.
• Examine technical issues associated with
product development:
–Often major design decisions depend on
issues like:
• Response time of a hardware controller,
• Efficiency of a sorting algorithm, etc.
11
 Prototyping Model
• Start with approximate requirements.
• Carry out a quick design.
Prototype Construction

• Prototype is built using several

Design
short-cuts:
Coding
– Short-cuts might involve:
Testing
• Using inefficient, inaccurate, or
dummy functions. Maintenance

• A table look-up rather than performing the actual

computations.

13
 Prototyping Model (CONT.)
• The developed prototype is submitted to the
customer for his evaluation:
Build Prototype

Requirements
Customer
Evaluation of
Customer
Gathering Quick Design Prototype Design
satisfied
–Based on the user feedback,
Refine
Requirements Implement

the prototype is refined.

Test

–This cycle continues until the user

Maintain

approves the prototype.

• The actual system is developed using the waterfall
model.
15
 Prototyping Model (CONT.)
• Even though construction of a working prototype
model involves additional cost --- overall
development cost usually lower for:
– Systems with unclear user requirements,
– Systems with unresolved technical issues.

• Many user requirements get properly defined and

technical issues get resolved:
– These would have appeared later as change requests
and resulted in incurring massive redesign costs.
17
 Prototyping: disadvantages
• For some projects, it is expensive

• Susceptible to over-engineering:

– Designers start to incorporate

sophistications that they could not
incorporate in the prototype.

19
Major difficulties of Waterfall-Based Life Cycle
Models

• Requirements for the system are

determined at the start:

– Are assumed to be fixed from that point

on.

– Long term planning is made based on this.

21
• “The basic idea… take advantage of what was
being learned during the development of earlier,
incremental, deliverable versions of the system.
Learning comes from both the development and
use of the system… Start with a simple
implementation of a subset of the software
requirements and iteratively enhance the
evolving sequence of versions. At each version
design modifications are made along with adding
new functional capabilities. “ Victor Basili
2
 Customer’s Perspective
C

A AB A

B B

4
Incremental Model: Requirements
Split into
Features

Requirements: High Level Analysis

Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
Slice
6
 Incremental delivery
increment design
1 build

install
Customer
Feedback
design
increment
build
2
install
Customer
Feedback
design
increment build
3
install
Customer
Feedback

8
 Which step first?
• Some steps will be pre-requisite because
of physical dependencies
• Others may be in any order
• Value to cost ratios may be used
– V/C where
– V is a score 1-10 representing value to
customer
– C is a score 0-10 representing cost to
developers 10
Evolutionary Model
with Iterations

12
 Evolutionary Model with Iteration

• “A complex system will be most successful if

implemented in small steps… “retreat” to a
previous successful step on failure…
opportunity to receive some feedback from
the real world before throwing in all
resources… and you can correct possible
errors…” Tom Glib in Software Metrics

14
 Evolutionary Model
• First develop the core modules of the
software.
• The initial skeletal software is refined
into increasing levels of capability:
(Iterations)
–By adding new functionalities in successive
versions.
16
 Evolutionary Model with Iteration
• Outcome of each iteration: tested, integrated,
executable system
• Iteration length is short and fixed
– Usually between 2 and 6 weeks

– Development takes many iterations (for example: 10-15)

• Does not “freeze” requirements and then

conservatively design :
– Opportunity exists to modify requirements as well as the
design… 18
 Evolutionary Model
• Evolves an initial implementation with user
feedback:
– Multiple versions until the final version.

Initial
Specification version
Initial Rough
Intermediate
Requirements
Development versions

Final
Validation version

20
 Advantages of evolutionary model

• Better management of complexity by

developing one increment at a time.

• Better management of changing requirements.

• Can get customer feedback and incorporate

them much more efficiently:
– As compared when customer feedbacks come only
after the development work is complete.

22
 Evolutionary Model: Problems
• The process is intangible:
–No regular, well-defined deliverables.
• The process is unpredictable:
–Hard to manage, e.g., scheduling, workforce
allocation, etc.
• Systems are rather poorly structured:
–Continual, unpredictable changes tend to
degrade the software structure.
• Systems may not even converge to a final version.
24
Rapid Application Development (RAD) Model
• Sometimes referred to as the rapid
prototyping model.
• Major aims:
– Decrease the time taken and the cost incurred
to develop software systems.
– Facilitate accommodating change requests as
early as possible:
• Before large investments have been made in development
and testing. 26
 Methodology
•Plans are made for one increment at a time.
• The time planned for each iteration is called
a time box.

•Each iteration (increment):

• Enhances the implemented functionality of
the application a little.

28
How Does RAD Facilitate Faster Development?
• RAD achieves fast creation of working
prototypes.
– Through use of specialized tools.

• These specialized tools usually support the

following features:
– Visual style of development.

– Use of reusable components.

– Use of standard APIs (Application Program

Interfaces).
30
For Which Applications RAD is Unsuitable?

• Few plug-in components are available

• High performance or reliability required

• No precedence for similar products exists

• The system cannot be modularized.

32
 Prototyping versus RAD
• In contrast:
• In RAD the developed prototype evolves
into deliverable software.

• RAD leads to faster development

compared to traditional models:
• However, the quality and reliability would
possibly be poorer.

34
 RAD versus Iterative Waterfall Model
• The iterative waterfall model:
– Does not facilitate accommodating requirement
change requests.
• Iterative waterfall model does have some
important advantages:
– Use of the iterative waterfall model leads to
production of good documentation.
– Also, the developed software usually has better
quality and reliability than that developed using
RAD. 36
 Agile Models

9/28/2024
2
 Agile Model
• To overcome the shortcomings of the waterfall
model of development.
– Proposed in mid-1990s
• The agile model was primarily designed:
– To help projects to adapt to change requests
• In the agile model:
– The requirements are decomposed into many small
incremental parts that can be developed over one to
four weeks each.

4
 Agile Methodologies
• XP
• Scrum
• Unified process
• Crystal
• DSDM
• Lean
6
• At a time, only one increment is planned,
developed, deployed at the customer site.
– No long-term plans are made.

• An iteration may not add significant

functionality, Agile Model: Nitty Gritty
– But still a new release is invariably made at
the end of each iteration

– Delivered to the customer for regular use.

8
 Effectiveness of
Communication Modes

10
• Travel light: Agile Documentation
– You need far less documentation than you think.
• Agile documents:
– Are concise
– Describe information that is less likely to change
– Describe “good things to know”
– Are sufficiently accurate, consistent, and detailed
• Valid reasons to document:
– Project stakeholders require it
– To define a contract model
– To support communication with an external group
– To think something through
12
 Adoption Detractors
• Sketchy definitions, make it possible to
have
– Inconsistent and diverse definitions
• High quality people skills required
• Short iterations inhibit long-term
perspective
• Higher risks due to feature creep:
– Harder to manage feature creep and customer
expectations 14
• Steps of Agile Model versus Waterfall Model
Waterfall model are a planned sequence:
– Requirements-capture, analysis, design, coding,
and testing .
• Progress is measured in terms of delivered
artefacts:
– Requirement specifications, design documents,
test plans, code reviews, etc.
• In contrast agile model sequences:
– Delivery of working versions of a product in
several increments. 16
 Agile versus RAD Model
• Agile model does not recommend
developing prototypes:
– Systematic development of each
incremental feature is emphasized.
• In contrast:
– RAD is based on designing quick-and-dirty
prototypes, which are then refined into
production quality code.
18
Extreme Programming
(XP)

20
 Taking Good Practices to Extreme
• If code review is good:
– Always review --- pair programming
• If testing is good:
– Continually write and execute test cases ---
test-driven development
• If incremental development is good:
– Come up with new increments every few days
• If simplicity is good:
– Create the simplest design that will support
only the currently required functionality.
22
• Communication: 4 Values
– Enhance communication among team members
and with the customers.
• Simplicity:
– Build something simple that will work today
rather than something that takes time and yet
never used
– May not pay attention for tomorrow
• Feedback:
– System staying out of users is trouble waiting to
happen
• Courage:
– Don’t hesitate to discard code 24
 Best Practices
• Designing:
– Without proper design, a system
implementation becomes too complex
– The dependencies within the system become
too numerous to comprehend.
• Feedback:
– Feedback is important in learning customer
requirements.

26
 Extreme Programming Activities
• XP Coding
• Recommends the construction of unit test cases before
coding commences (test-driven development)
• Encourages “pair programming”

• XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and
executed to assess customer visible functionalities
28
 Full List of XP Practices
7. Refactoring – programmers continuously
restructure the system without changing its
behavior to remove duplication and simplify
8. Pair-programming -- all production code is
written with two programmers at one machine
9. Collective ownership – anyone can change any
code anywhere in the system at any time.
10. Continuous integration – integrate and build the
system many times a day – every time a task is
completed. 30
Emphasizes Test-Driven Development (TDD)
• Based on user story develop test cases
• Implement a quick and dirty feature every
couple of days:
– Get customer feedback
– Alter if necessary
– Refactor

• Take up next feature

32
 Introduction
• Object-oriented design (OOD) techniques are now
extremely popular:

–Inception in early 1980’s and nearing maturity.

–Widespread acceptance in industry and academics.

–Unified Modelling Language (UML) became an ISO

standard (ISO/IEC 19501) in 2004.
2
 UML Origin
• OOD in late 1980s and early 1990s:
 Different software development houses were using different
notations.

 Methodologies were tied to notations.

• UML developed in early 1990s:

 To standardize the large number of object-oriented modelling
notations that existed. 4
 Different Object
OMT Modeling
Techniques in
UML
UML
Booch’s
OOSE
Methodology

6
 Developments to UML
• UML continues to UML 2.0 2003
develop, due to: Application
to embedded
– Refinements systems
UML 1.X
– Making it applicable to
new contexts
UML 1.0 1997

8
 UML Diagrams
• Nine diagrams in UML1.x :
• Used to capture 5 different views of a system.
• Views:
• Provide different perspectives of a software
system.
• Diagrams can be refined to get the actual implementation
of a system.
10
 Diagrams
Behavioural View
Structural View - Sequence Diagram
and views
- Class Diagram
- Object Diagram
- Collaboration Diagram
- State-chart Diagram
in UML
- Activity Diagram
User’s View
-Use Case
Diagram

Implementation View Environmental View

- Component Diagram - Deployment Diagram

12
• Use Case Diagram
– high-level behaviors of the system, user goals, external entities:
actors

• Sequence Diagram Behavioral

– focus on time ordering of messages Diagrams
• Collaboration Diagram
– focus on structural organization of objects and messages

• State Chart Diagram

– event driven state changes of system

• Activity Diagram
– flow of control between activities 14
 Are All Views Required for
• NO Developing A Typical System?
• For a simple system:
• Use case diagram, class diagram and one of the interaction
diagrams only.
• State chart diagram:
• when class has significant states.
• When states are only one or two, state chart model becomes
trivial
• Deployment diagram:
• In case several hardware components used to develop the
system.
16
 Use Case Model Behavioural View
Structural View - Sequence Diagram
- Class Diagram
• Consists of a set of “use cases” - Object Diagram
- Collaboration Diagram

User’s View
-State-chart Diagram
- Activity Diagram
-Use Case
Diagram

• It is the central model: Implementation View

- Component Diagram
Environmental View
- Deployment Diagram

–Other models must conform to this model

–Not really an object-oriented model, it is a functional

model of a system

18
–Use cases for a Library information system
•issue-book
•query-book
•return-book Example
Use Cases
•create-member
•add-book, etc.

20
 An Example Use Case Diagram

Play Move

Tic-tac-toe game
Player

Use case model

22
• Represented in a use case diagram Representation of
• A use case is represented by an ellipse Use Cases

• System boundary is represented by a rectangle

• Users are represented by stick person icons (actor)
• Communication relationship between Backup

Play Move
actor and use case by a line <<external
system>>
Tic-tac-toe game
Player
• External system by adding a stereotype
24
 Relationships between Use Cases and Actors
• Association relation indicates that the actor and the
corresponding use case communicate with one another.

update
grades

faculty

26
 Yet Another Use
Telephone Order System
Case Example
Check
Status Salesperson

Place
Order

Fill
Shipping
Orders
Customer Clerk

Establish
credit

Supervisor

28
 Generalization
• The child use case inherits the
parent
behavior of the parent use case.
–The child may add to or override some
child
of the behavior of its parent.

30
Factoring Use Cases Using Generalization

Pay membership fee

Pay through credit card Pay through library pay card

32
 <<include>> Common
Base use case
use case
Factoring Use
Cases Using
Include
Base use case 2 Base use case 1

<<include>>
<<include>>
<<include>>
<<include>>

Common use case 1 Common use case 2 Common use case 3

34
 Extend
• Use when a use-case optionally can do a little bit more:
– Capture the normal behavior

– Capture the extra behavior in a separate use-case

– Create extend dependency

Base <<extend>> Common
use case use case

36
 Extension Point
• The base use case may include/extend other use cases:
– At certain points, called extension points.

• Note the direction of the arrow

<<extend>>
Perform Sale Product is a gift
Gift wrap
After checkout Product

38
• Video Store Information System supports the following
business functions: Example 1: Video Store Information System
– Recording information about videos the store owns
• This database is searchable by staff and all customers
– Information about a customer’s borrowed videos
• Access by staff and customer. It involves video database searching.
– Staff can record video rentals and returns by customers. It involves
video database searching.
– Staff can maintain customer and video information.
– Managers of the store can generate various reports.
40
Name
Actors Use Case
Trigger Description
Preconditions
Post conditions

Mainline Scenario
Alistair Cockburn
“Writing
Effective Use
Cases”
Alternatives flows

42
 ATM Money Withdraw Example
• Actors: Customer
• Pre Condition:
– ATM must be in a state ready to accept transactions
– ATM must have at least some cash it can dispense
– ATM must have enough paper to print a receipt
• Post Condition:
– The current amount of cash in the user account is the amount before withdraw
minus withdraw amount
– A receipt was printed on the withdraw amount

44
 ATM Money Withdraw (cont.)
• Alternative flow of events:
– Step 3: Customer authorization failed. Display an error message, cancel the
transaction and eject the card.
– Step 8: Customer has insufficient funds in its account. Display an error
message, and go to step 6.
– Step 8: Customer exceeds its legal amount. Display an error message, and go to
step 6.
• Exceptional flow of events:
– Power failure in the process of the transaction before step 9, cancel the
transaction and eject the card.

46
 Example 2: Use Case Model for Course Management Software
• At the beginning of each semester,
– Each professor shall register the courses that he is going to teach.
• A student can select up to four-course offerings.
– During registration a student can request a course catalogue showing course offerings for the
semester.
– Information about each course such as professor, department and prerequisites would be
displayed.
– The registration system sends information to the billing system, so that the students can be
billed for the semester.
• For each semester, there is a period of time during which dropping of courses is
permitted.
• Professors must be able to access the system to see which students signed up for each
of their course offerings.

48
• Use case name should begin with a verb. Style Notes
• While use cases do not explicitly imply timing:
(Ambler, 2005)
– Order use cases from top to bottom to imply timing -- it improves readability.
• The primary actors should appear in the left.
• Actors are associated with one or more use cases.
• Do not use arrows on the actor-use case relationship.
• To initiate scheduled events include an actor called “time”, or
“calendar”
• Do not show actors interacting with each other.
• <<include>> should rarely nest more than 2 levels deep.
50
 Use Case Packaging

Accounts

Print
Query balance
Balance sheet

Receive Make
grant payments

52
 UML Class Representation
• A class represents a set of objects having similar attributes,
operations, relationships and behavior.
Class Name
Window
A class can
size: Size implicitly
Attributes have a few
visibility: boolean association
attributes
display()
Operations hide()

54
What are the Different Types of Relationships
Among Classes?
• Four types of relationships:
– Inheritance
– Association
– Aggregation/Composition
– Dependency

56
 Inheritance Example
Animal “A Dog ISA Animal”
“A Cat ISA Animal”

Dog Cat

58
 Multiple LibraryMember Base Class LibraryMember Base Class

Inheritance

Derived
Faculty Students Staff Faculty Students Staff
Classes

Multiple
Inheritance

UnderGrad PostGrad Research UnderGrad PostGrad Research

60
 Objects myRectangle and myBox Rectangle

Rectangle myRectangle = new Rectangle(5, 3);

Box
Box myBox = new Box(6, 5, 4);

length 5.0 length 6.0

myRectangle
myBox

width 3.0 width 5.0

Object height 4.0

Reference
62
Inheritance Example Library
Book

issuable reference

Issuable Reference
Issuable Reference
Single Volume Single Volume
BookSet BookSet
Book Book

Discriminator: allows one to group subclasses into

clusters that correspond to a semantic category.

64
 Association Relationship
• How implemented in program?
• Enables objects to communicate with each other:
–One object must “know” the ID of the corresponding
object in the association.
• Usually binary:
–But in general can be n-ary.
66
1-1 Association tax_file
– example
Rakesh Shukla 760901-1234

V. Ramesh
691205-5678
Keshab Parhi

People Tax_files
1 1
People Associated Tax_files
with

68
 Association UML Syntax
role B
Class A role A Class B

• A Person works for a Company. Role

Person employee employer Company

works for

Association Name

70
 Navigability

opens 0..5
Key * Door

72
 Quiz: Draw Class Diagram
• A Student can take up to five Courses.

• A student needs to enroll in at least one course.

• Up to 300 students can enroll in a course.

• An offered subject in a semester should have at least 10

registered students.

74
 Student credits hasEnrolmentOf Course
Identify as 20..300 Enrols in 1..5

Correct or
Wrong Student credits hasEnrolmentOf Course
20..300 Enrols in 1..5

Student credits hasEnrolmentOf Course

20..300 Enrols in 1..5

Student credits hasEnrolmentOf Course

20..300 Enrols in 1..5

76
 Association and Link
• A link:
– An instance of an association
– Exists between two or more objects
– Dynamically created and destroyed as the run of a
system proceeds
• For example:
– An employee joins an organization.
– Leaves that organization and joins a new organization.
78
Self Association: Example of
Computer Network

Connects to

Computer *

80
 Association Exercise 1
• A Person works for a Company.
Role Implicit attribute of type Company

Implicit attribute of type Person

Person employee employer Company

works for

Association Name

Observe: Implicit bidirectional navigation Implementation?

82
 Aggregation Relationship
• Represents whole-part relationship
• Represented by a diamond symbol at the composite end.
• Usually creates the components:
–Also, aggregate usually invokes the same operations of all its
components.
–This is in contras to plain association
• Usually owner of the components:
–But can share with other classes

84
 Aggregation cont…

 An aggregate object contains other objects.

 Aggregation limited to tree hierarchy:

 No circular aggregate relation. Paragraph Line

1
*

86
 Composition
• A stronger form of aggregation
– The whole is the sole owner of its part.
• A component can belong to only one whole
– The life time of the part is dependent upon the whole.
• The composite must manage the creation and destruction of its
parts. 1
Circle Point Circle
3..* Point
Polygon

88
Composition: Alternate Notation
Car
4 1
Wheel Engine

2 1
Door Chassis
1 1
Axle Steering

90
• Composition: Aggregation vs. Composition
– Composite and components have the same life line.
• Aggregation:
– Lifelines are different.
• Consider an order object:
– Aggregation: If order items can be
changed or deleted after placing order.
– Composition: Otherwise.

92
 public class Car{
Implementing
Composition private Wheel wheels[4];
public Car (){
wheels[0] = new Wheel();
wheels[1] = new Wheel();
wheels[2] = new Wheel();
wheels[3] = new Wheel();
}
1 4 Wheel
} Car

94
 Class Dependency

Dependent Class Independent Class

96
 Association Vs. Aggregation

• Is aggregation an association?

• Is composition an aggregation?

98
 UML Class Class
Relation Notation Generalization
Relationship
dependency

Summary

Object Object
Aggregation Composition
Object Association Association Association

1..* 1
n n
0..* 0..*

By default and will always be “1”

100
 Association and Link
• A link:
– An instance of an association
– Exists between two or more objects
– Dynamically created and destroyed as the run of a
system proceeds
• For example:
– An employee joins an organization.
– Leaves that organization and joins a new organization.
102
Self Association: Example of
Computer Network

Connects to

Computer *

104
 Association Exercise 1
• A Person works for a Company.
Role Implicit attribute of type Company

Implicit attribute of type Person

Person employee employer Company

works for

Association Name

Observe: Implicit bidirectional navigation Implementation?

106
 Aggregation Relationship
• Represents whole-part relationship
• Represented by a diamond symbol at the composite end.
• Usually creates the components:
–Also, aggregate usually invokes the same operations of all its
components.
–This is in contras to plain association
• Usually owner of the components:
–But can share with other classes

108
 Aggregation cont…

 An aggregate object contains other objects.

 Aggregation limited to tree hierarchy:

 No circular aggregate relation. Paragraph Line

1
*

110
 Composition
• A stronger form of aggregation
– The whole is the sole owner of its part.
• A component can belong to only one whole
– The life time of the part is dependent upon the whole.
• The composite must manage the creation and destruction of its
parts. 1
Circle Point Circle
3..* Point
Polygon

112
Composition: Alternate Notation
Car
4 1
Wheel Engine

2 1
Door Chassis
1 1
Axle Steering

114
• Composition: Aggregation vs. Composition
– Composite and components have the same life line.
• Aggregation:
– Lifelines are different.
• Consider an order object:
– Aggregation: If order items can be
changed or deleted after placing order.
– Composition: Otherwise.

116
 public class Car{
Implementing
Composition private Wheel wheels[4];
public Car (){
wheels[0] = new Wheel();
wheels[1] = new Wheel();
wheels[2] = new Wheel();
wheels[3] = new Wheel();
}
1 4 Wheel
} Car

118
 Dependency
• Dependency relationship can arise due to a variety of reasons:
– Stereotypes are used to show the precise nature of the dependency.

Type of Stereotype Description

dependency
Abstraction «abstraction» Dependency of concrete class on its abstract class.
 Car

• aggregation: "is part of" 1

Association 1 aggregation
– Symbolized by empty diamond Engine
Types
• composition: is made of Book
composition
– Stronger version of aggregation 1

*
– The parts live and die with the whole Page

– Symbolized by a filled diamond

dependency

• dependency: Depends on Lottery Random

Ticket
– Represented by dotted arrow.
122
 Aggregation Composition
Faculty SalesOrder

(team- 1..5 1
teaching is
possible) 0..* 1..*
CourseTeaching SalesOrderLineItem

124
 Class Diagram Inference Based on Text Analysis
(based on Dennis, 2002)
• A common noun implies a class e.g. Book
• A proper noun implies an object (instance of a class): CSE Dept, OOSD, etc.
• An adjective implies an attribute e.g. price of book
• A “doing” verb implies an operation
– Can also imply a relationship e.g. student issues Book
• A “having” verb implies an aggregation relationship
• A predicate or descriptive verb phrase elaborates an operation e.g. ISBN
numbers are integers
• An adverb implies an attribute of an operation e.g. fast loading of image…

126
• A square is a polygon
Identify Classes &
• Shyam is a student
Relations
• Every student has a name
• 100 paisa is one rupee
• Students live in hostels
• Every student is a member of the library
• A student can renew his borrowed books
• The Department has many students

128
• Describes static structure of a system
• Main constituents are classes and their
relationships:
Class Diagram: Recap
–Generalization
–Aggregation
–Association
–Various kinds of dependencies

130
 Object Diagram
LibraryMember

Mritunjay LibraryMember
LibraryMember
B10028
C-108, Laksmikant Hall Mritunjay
1119 B10028
Mrituj@cse C-108, Laksmikant Hall
25-02-04 1119
25-03-06 Mrituj@cse
NIL 25-02-04
25-03-06
IssueBook( ); NIL
findPendingBooks( );
findOverdueBooks( ); Different representations of
returnBook( ); the LibraryMember object
findMembershipDetails( );

132
 A First Look at Sequence Diagrams
• Captures how objects interact with each other:
– To realize some behavior (use case execution).
• Emphasizes time ordering of messages.
• Can model:
– Simple sequential flow, branching, iteration, recursion,
and concurrency.

134
 Sequence Diagram
• Shows interaction among objects in a two-dimensional
chart member:
LibraryMember
book:Book
:Book
Copy

• Objects are shown as boxes at top ok = canBorrow()

borrow(book)
• If object created during execution: [ok] borrow(member)
setTaken(member)
–Then shown at appropriate place in time line
• Object existence is shown as dashed lines (lifeline)
• Object activeness, shown as a rectangle on lifeline

136
 member: :Book
book:Book
LibraryMember Copy
• iteration marker *[for all objects]
ok = canBorrow()

• [condition] borrow(book)

[ok] borrow(member)
– message is sent only if the condition is true setTaken(member)

• self-delegation
– a message that an object sends to itself
Gist of Syntax
• Loops and conditionals:
– UML2 uses a new notation called interaction frames to support
these

138
 Elements of A Sequence Diagram
X-Axis (objects)
member: :Book
book:Book
LibraryMember Copy
Y-Axis (time)

borrow(book) Life Line

Object
ok = canBorrow()
message
Activation box
[ok] borrow(member)
setTaken(member)

condition
How do you show Mutually exclusive conditional messages?

140
140
 :Library
:Library
:Library Book :Library
Book :Book
Boundary Renewal Member
Register
Controller
renewBook
renewBook find MemberBorrowing
displayBorrowing
selectBooks
Sequence
bookSelected
* find Diagram for
[reserved] the renew
[reserved] apology
update book use
apology case
confirm

confirm
updateMemberBorrowing

142
 Example: Solution
:client

plan <<create>> :travelAgent

setItinerary
calculateRoute

<<destroy>>

144144
 Method Population in Classes
• Methods of a class are determined from the
interaction diagrams…
:Registration :Registration
form manager

add course
RegistrationManager
(joe, math 01)

addCourse(Student,Course)

146
 Object Creation
• An object may create another object via a <<create>>
message.

:A

<<create>>
:B

148
 Control Information

Iteration
example
:CompoundShape :Shape
UML 1.x:
draw()
*draw()

150
 Quiz: Write Code for class B
a:A

m1
create
:B

flag=doA(this)
create
doB(c) c:C

152
Software Design - I

1
 Items Designed During Design Phase
• Module structure,
• Control relationship among the modules
– call relationship or invocation relationship
• Interface among different modules,
– data items exchanged among different modules,
• Data structures of individual modules,
• algorithms for individual modules.
Module Structure
 Stages in Design
• Design activities are usually classified into two stages:
– Preliminary (or high-level) design
– Detailed design.

• Meaning and scope of the two stages:

– vary considerably from one methodology to another.
 High-level design
• The outcome of high-level design:
–program structure, also called software
architecture.
 Detailed design
• For each module, design for it:
– data structure
– algorithms
• Outcome of detailed design:
– module specification.
 Good and bad designs
• There is no unique way to design a software.

• Even while using the same design methodology:

– different engineers can arrive at very different designs.

• Need to determine which is a better design.

 What Is Good Software Design?
• Understandability of a design is a major issue:
– Largely determines goodness of a design:
– a design that is easy to understand:
• also easy to maintain and change.
 How to Improve Understandability?
• Use consistent and meaningful names
– for various design components,
• Design solution should consist of:
– A set of well decomposed modules (modularity),
• Different modules should be neatly arranged in a hierarchy:
– A tree-like diagram.
– Called Layering
 Modularity
• If modules are independent:
– Each module can be understood separately,
• reduces 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.
 :Source

Bad design
may look
like this…
 Modularity
• Arrangement of modules in a hierarchy
ensures:
– Low fan-out
– 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.
 Advantages of Functional Independence
• Better understandability
• Complexity of design is reduced,
No dependencies

• Different modules easily understood in isolation:

– Modules are independent
Highly coupled-many dependencies
 Reuse: An Advantage of Functional Independence

• A functionally independent module:

– can be easily taken out and reused in a different
program.
• each module does some well-defined and precise function
• the interfaces of a module with other modules is simple and
minimal.
 Classification of Cohesiveness
• Classification can have scope for ambiguity:
– yet gives us some idea about cohesiveness of a
module.
• By examining the type of cohesion exhibited by a module:
– we can roughly tell whether it displays high cohesion or
low cohesion.
 Coincidental cohesion
• The module performs a set of tasks:
– which relate to each other very loosely, if at all.
• That is, 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.
• An example of logical cohesion:
– a set of print functions to generate an output report
arranged into a single module.
 Temporal cohesion
• The module contains functions so that:
– all the functions must be executed in the same time span.
• Example:
– The set of functions responsible for
• initialization,
• start-up, shut-down of some process, etc.
 Procedural cohesion
• The set of functions of the module:
– all part of a procedure (algorithm)
– 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
handle-Student- Data() {
Static Struct Student-data[10000];
Store-student-data();
Function A
Search-Student-data(); Function B

Print-all-students(); Function C

Communicational
}; Access same data
 Functional cohesion
• Different elements of a module cooperate:
– to achieve a single function,
– e.g. managing an employee's pay-roll.
• When a module displays functional cohesion,
– we can describe the function using a single sentence.
 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
 Stamp coupling
• Two modules are stamp coupled,
– if they communicate via a composite data item

• or an array or structure in C.
 Common Coupling

• Two modules are common coupled,

– if they share some global data.
 Hierarchical Design
• Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program structure.
• Most common notation:
– a tree-like diagram called structure chart.
 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.
Module Structure
Fan out=2

Fan out=1
Fan in=1

Fan in=2
Fan out=0
 Large Fan Out
• A module that invokes a large
number of other modules:
– likely to implement several different functions:
– not likely to perform a single cohesive function.
 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.
 Abstraction
• Lower-level modules:
– Perform input/output and other low-level
functions.
• Upper-level modules:
– Perform more managerial functions.
High-level
f1
Design
f2 d1 d2
f3

• d3 d4
d1
•
•
fn
 Design Approaches
• These two design approaches are radically different.
– However, are complementary
• rather than competing techniques.
– Each technique is applicable at
• different stages of the design process.
 Example
• The function create-new-library- member:

– creates the record for a new member,

– assigns a unique membership number

– prints a bill towards the membership

 Function-Oriented Design
• Several function-oriented design approaches have been
developed:
– Structured design (Constantine and Yourdon, 1979)
– Jackson's structured design (Jackson, 1975)
– Warnier-Orr methodology
– Wirth's step-wise refinement
– Hatley and Pirbhai's Methodology
 Object-Oriented Design
• System is viewed as a collection of objects (i.e.
entities).
• System state is decentralized among the objects:
– each object manages its own state information.
 Object-Oriented Design
• 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
• In OOD:
– software is not developed by designing functions such as:
• update-employee-record,
• get-employee-address, etc.
– but by designing objects such as:
• employees,
• departments, etc.
Object-Oriented versus Function-Oriented Design
• In OOD:
– state information is not shared in a centralized data.
– but is distributed among the objects of the system.
 Object-Oriented versus Function-Oriented Design

• Objects communicate by message passing.

– one object may discover the state information of another
object by interrogating it.
 Object-Oriented versus Function-Oriented Design
• Function-oriented techniques group functions together if:
– as a group, they constitute a higher level function.
• On the other hand, object-oriented techniques group
functions together:
– on the basis of the data they operate on.
 Fire-Alarm System
• We need to develop a computerized fire alarm
system for a large multi-storied building:
– There are 80 floors and 2000 rooms in
the building.
 Fire-Alarm System
• Whenever a fire condition is reported by any smoke
detector:
– the fire alarm system should:
• determine the location from which the fire condition was
reported
• sound the alarms in the neighbouring locations.
 Fire-Alarm System
• After a fire condition has been successfully
handled,
– the fire alarm system should let fire fighting
personnel reset the alarms.
 Object-Oriented Approach:
class detector
attributes: status, location, neighbors
operations: create, sense-status, get-location, find-neighbors

class alarm
attributes: location, status
operations: create, ring-alarm, get_location, reset-alarm

– Appropriate number of instances of the class detector and alarm are created.
 Object-Oriented versus Function-Oriented Design

• Use OOD to design the classes:

– then applies top-down function oriented techniques
• to design the internal methods of classes.
 Summary
• We started with an overview of:
– activities undertaken during the software design phase.
• We identified:
– the information need to be produced at the end of
design:
• so that the design can be easily implemented using a
programming language.
 Summary
• We classified different types of cohesion and
coupling:
– enables us to approximately determine the cohesion
and coupling existing in a design.
 Summary
• We examined the essential philosophy behind these
two approaches
– these two approaches are not really competing but
complementary approaches.
 Introduction
• Structured analysis is a top-down decomposition technique:
– DFD (Data Flow Diagram) is the modelling technique used
– Functional requirements are modelled and decomposed.

• Why model functionalities?

– Functional requirements exploration and validation
– Serves as the starting point for design.

101
 Structured analysis and Structured Design
• During Structured analysis:
– High-level functions are successively decomposed:
•Into more detailed functions.
• During Structured design:
– The detailed functions are mapped to a module
structure. 103
 SA/SD (Structured Analysis/Structured Design)
• SA/SD technique draws heavily from the following
methodologies:
– Constantine and Yourdon's methodology
We largely use
– Hatley and Pirbhai's methodology
– Gane and Sarson's methodology
– DeMarco and Yourdon's methodology
• SA/SD technique results in:
– high-level design. 105
 Structured Analysis
• Textual problem description converted into a graphic
model.

– Done using data flow diagrams (DFDs).

– DFD graphically represents the results of structured analysis.

107
 Structured Design
• The functions represented in the DFD:

– Mapped to a module structure.

• Module structure:

– Also called software architecture

109
 Structured Analysis: Recap
• 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). 111
 DFD Concepts
• It is useful to consider each function as a processing
station: move

– Each function consumes some input data. Validate-move

Updated
board

– Produces some output data.

113
 Pros of Data Flow Diagrams (DFDs)
• A DFD model:

– Uses limited types of symbols.

– Simple set of rules

– Easy to understand --- a hierarchical model.

115
A Hierarchical Model

117
 External Entity Symbol
• Represented by a rectangle

• External entities are either users or external systems:

– input data to the system or Librarian

– consume data produced by the system.

– Sometimes external entities are called terminator, source, or sink.

119
 Data Flow Symbol
• A directed arc or line. book-name

– Represents data flow in the direction of the

arrow.
– Data flow symbols are annotated with names of
data they carry.

121
 Data Store Symbol
• Direction of data flow arrow:
find-book
– Shows whether data is being read from
or written into it.
Books
• An arrow into or out of a data store:
– Implicitly represents the entire data of the data store
– Arrows connecting to a data store need not be annotated
with any data name. 123
 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

125
 Yourdon's vs. Gane Sarson Notations

• The notations that we are following:

– Are closer to the Yourdon's notations
• You may sometimes find notations in books and used in some
tools that are slightly different:
– For example, the data store may look like a box with one end
closed

127
 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.

129
 Context Diagram
• A context diagram shows:
– External entities.

– Data input to the system by the external entities,

– Output data generated by the system.

• The context diagram is also called the level 0 DFD.

131
 Level 1 DFD Construction
• Examine the SRS document: Display-
game
move board
0.1 result
– Represent each high-level
function as a bubble. Validate-
move
Check-
winner
0.2 board 0.4

– Represent data input to every

high-level function. Play-
move
0.3

– Represent data output from every

high-level function.
133
 Decomposition
• Decomposition of a bubble:

– Also called factoring or exploding.

• Each bubble is decomposed into

– Between 3 to 7 bubbles.

135
 Decomposition Pitfall
• Too many bubbles at a level, a sign of poor
modelling:
– More than 7 bubbles at any level of a DFD.

– Make the DFD model hard to understand.

137
 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.

139
Example 1: RMS Calculating Software

Data- Compute-
items
RMS
0

User result

Context Diagram (Level 0 DFD)

141
 Example 1: RMS Calculating Software

–Accept input numbers from the user:

– Validate the numbers,
– Calculate the root mean square of the input
numbers
– Display the result.

143
 Example: RMS Calculating 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.

145
 Importance of Data Dictionary
• Provides the team of developers with standard terminology
for all data:
– A consistent vocabulary for data is very important

• In the absence of a data dictionary, different developers

tend to use different terms to refer to the same data,
–Causes unnecessary confusion.

147
 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.

149
• Composite data are defined in terms of primitive data items using
simple operators:

• +: denotes composition of data items, e.g

Data
Definition
– a+b represents data a together with b.

• [,,,]: represents selection,

– Any one of the data items listed inside the square bracket can occur.
– For example, [a,b] represents either a occurs or b

151
 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.

153
Structured Analysis and Design
Cont…

155
 c
Balancing a DFD
b c

c1
d1

a d
e
Level 1 d
e1
e
Level 2
157
 Example 2: Tic-Tac-Toe Computer Game
• A human player and the computer make
alternate moves on a 3 X 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.
159
 Tic-tac-toe
display software
0

Context
move Diagram for
Human Player Example

161
 Data Dictionary
Display=game + result
move = integer
board = {integer}9
game = {integer}9
result=string

163
 Example 3: Trading-House Automation System (TAS)
• The trading house maintains names and addresses of its
regular customers.
• Each customer is assigned a unique customer identification
number (CIN).
• As per current practice when a customer places order:
– The accounts department first checks the credit-worthiness of the
customer.
165
 Example: Trading-House Automation System (TAS)
• If a customer is credit-worthy:
– Items he/she has ordered are checked against the list of items the
trading house deals with.

• The items that the trading house does not deal with:
– Are not processed any further
– An appropriate message for the customer for these items is
generated.
167
 Example: Trading-House Automation System (TAS)

• The customer can produce the material issue slip at the

store house:

– Take delivery of the items.

– Inventory data adjusted to reflect the sale to the customer.

169
 Example: Trading-House Automation System (TAS)
• The purchase department:
– would periodically issue commands to generate indents.
• When generate indents command is issued:
– The system should examine the "pending-order" file
– Determine the orders that are pending
– Total quantity required for each of the items.
171
 Example: Trading-House Automation System (TAS)

• TAS should also answers managerial queries:

– Statistics of different items sold over any given period of
time

– Corresponding quantity sold and the price realized.

173
 Customer-history Item-file
query

Accept inventory
Customer-file -order
0.1 Handle- statistics
query
0.3
order Process
Accepted-
orders -order
Vendor-list
0.2 Level 1
Handle-
indent-
DFD
Indent- Sales-statistics
request request
0.4
Indents Material-issue-
pending-order slip + bill

175
• item-name: string
• house#: string Example: Data
• street#: string Dictionary
• city: string
• pin: integer
• customer-id: integer
• bill: {item + quantity + price}* + total-amount + customer-address
• material-issue-slip: message + item + quantity + customer-address
• message: string
• statistics: {item + quantity + price }*
• sales-statistics: {statistics}*
• quantity: integer

177
 Observation
• As a DFD is refined into greater levels of detail:
– The analyst performs an implicit functional
decomposition.

– At the same time, refinements of data takes place.

179
 Guidelines For Constructing DFDs
• All external entities should be represented in the
context diagram:
– External entities should not appear at any other level DFD.
• Only 3 to 7 bubbles per diagram should be allowed:
– Each bubble should be decomposed to between 3 and 7
bubbles.

181
 Guidelines For Constructing DFDs
• A DFD model does not represent control information:
– When or in what order different functions (processes) are invoked
– The conditions under which different functions are invoked are not
represented.
– For example, a function might invoke one function or another depending on
some condition.
– Many beginners try to represent this aspect by drawing an arrow between
the corresponding bubbles.

183
 item query
statistics
inventory
Item-file Handle-
query
Process- 0.3
order
0.2
statistics

Handle-
Find 4
indent-
request Sales-statistics Errors
0.4
Material-issue-slip +
pending-order bill

185
 Find Error Example-2
• A function accepts the book name to be searched from
the user
• If the entered book name is not a valid book name
– Generates an error message, Search-
Get- Good-book- book
name
• If the book name is valid, book- Book-
name details
Print-
– Searches the book name err-
Error-
in database. Book-name message
message

187
• Unbalanced DFDs
Commonly
• Forgetting to name the data flows Made Errors
• Unrepresented functions or data
• External entities appearing at higher level DFDs
• Trying to represent control aspects
• Context diagram having more than one bubble
• A bubble decomposed into too many bubbles at next level
• Terminating decomposition too early
• Nouns used in naming bubbles 189
 Shortcomings of the DFD Model
• For example, a bubble named find-book-position has only
intuitive meaning:
– Does not specify several things:
• What happens when some input information is missing or is
incorrect.
• Does not convey anything regarding what happens when book is
not found
• What happens if there are books by different authors with the
same book title. 191
 Shortcomings of the DFD Model
• Decomposition is carried out to arrive at the successive
levels of a DFD is subjective.
• The ultimate level to which decomposition is carried out is
subjective:
– Depends on the judgement of the analyst.
• Even for the same problem,
– Several alternative DFD representations are possible:
– Many times it is not possible to say which DFD representation is
superior or preferable. 193
Structured Analysis and Design
Cont…

195
 Structure Chart
• Structure chart representation
root
– Easily implementable using programming languages.
• Main focus of a structure chart: Process-
order
Handle-indent Handle-
query

– Define the module structure of a software,

– Interaction among different modules,
– Procedural aspects (e.g, how a particular functionality
is achieved) are not represented.
 Arrows
• An arrow between two modules implies:
– During execution control is passed from one module to the
other in the direction of the arrow.

root

Process-order Handle-indent Handle-query

 Library Modules
• Library modules represent frequently called modules:
– A rectangle with double side edges.
– Simplifies drawing when a module is called by several
modules.
Quick-sort
 Repetition
• A loop around control flow arrows
root
denotes that the concerned modules
are invoked repeatedly.

Process-order Handle-indent Handle-query

 Structure Chart
• Makes use of principle of abstraction:
– does not allow lower-level modules to invoke higher-
level modules:

– But, two higher-level modules can invoke the same

lower-level module.
 Example:
Bad Design
 Transformation of a DFD Model into Structure Chart
• Two strategies exist to guide transformation of
a DFD into a structure chart:
– Transform Analysis
– Transaction Analysis
• Input portion in the DFD:
Transform Analysis
– processes which convert input data from physical to logical form.
– e.g. read characters from the terminal game
Display-
and store in internal tables or lists. move board result

• Each input portion: Validate- Check-

move board winner
– called an afferent branch.
– Possible to have more than one afferent Play-
move
branch in a DFD.
 Transform Analysis
• Derive structure chart by drawing one functional
component for: Display-
game

move board
result

– afferent branch,
Validate- Check-
move board winner
– central transform,
– efferent branch. Play-
move
 Transform Analysis
• First level of structure chart:
root
– Draw a box for each input and output units
– A box for the central transform. Process- Handle- Handle-
order indent query
• Next, refine the structure chart:
– Add subfunctions required by each high-level module.
– Many levels of modules may required to be added.
Example 1: RMS Calculating Software

Data-items Compute-
RMS
0

User result

Context Diagram
 numbers
Read- Validate-
numbers numbers
0.1 0.2
Valid -
Data- numbers
items error
Example 1: RMS
Compute- Calculating
Display rms Software
0.4 0.3

result RMS
 root Example 1:
rms RMS
rms
Valid-numbers Calculating
Valid-numbers
Software
Get-good-data Compute-solution Display-solution

Get-data Validate-
data
Context Diagram for Example 2
Tic-tac-toe
display software
0

move
Human Player
 root

Get-good-move Compute-game Display

Get-move Validate- play-move Check-

Structure
move winner Chart
 Transaction Analysis
• Transaction:
–Any input data value that triggers an action:
–For example, a menu option selection might trigger a set
of functions.
–Represented by a tag identifying its type.
• Transaction analysis uses this tag to divide the system
into:
–Several transaction modules
–One transaction-center module.
 Customer-history Item-file query

Accept- inventory statistics

Customer-file order
Handle-
query
order Process
Accepted-orders
-order Level 1 DFD
Vendor-list
for TAS
Handle-
indent- Sales-statistics
Indent- request
request
Indents
pending-order
 Summary
• We discussed a sample function-oriented software
design methodology:
– Structured Analysis/Structured Design(SA/SD)
– Incorporates features from some important design
methodologies.
• SA/SD consists of two parts:
– Structured analysis
– Structured design.
 Summary
• Several CASE tools are available:
– Support structured analysis and design.
– Maintain the data dictionary,
– Check whether DFDs are balanced or not.
 Faults and Failures

 A program may fail during testing:

A manifestation of a fault (also called

defect or bug).

 Mere presence of a fault may not lead to a

failure.

2
 Fault, defect, or bug Error or mistake

Failure

Design Code
Specification

4
 How to Reduce Bugs?

 Review

 Testing

 Formal specification and verification

 Use of development process

6
 Examine Test Result…

 If the program does not behave as

expected:
 Notethe conditions under which it failed
(Test report).

 Later debug and correct.

8

8
 Testing Facts

 Testing is getting more complex and

sophisticated every year.
 Larger and more complex programs

 Newer programming paradigms

 Newer testing techniques

 Test automation
10

10
 Monkey Testing is Passe…
 Testing through random
inputs.
 Problems:
 Many program parts may not
get tested. •Two types of monkeys:

 Risky areas of a program •Dumb monkey

may not get tested.
 The tester may not be able
•Smart monkey
to reproduce the failure.
12
 Verification versus Validation

 Verification is concerned with phase

containment of errors:

 Whereas, the aim of validation is that the final

product is error free.

14

14
Testing Levels

16
 Test Levels
 Unit testing
 Test each module (unit, or component) independently

 Mostly done by developers of the modules

 Integration and system testing

 Test the system as a whole

 Often done by separate testing or QA team

 Acceptance testing
 Validation of system functions by the customer
18
Basic Concepts in
Testing

20
 Quiz 1
 As testing proceeds more and more bugs
are discovered.
 How to know when to stop testing?

 Give examples of the types of bugs

detected during:
 Unit testing?
 Integration testing?
22

 System testing?
22
 Integration Testing
 After modules of a system
have been coded and unit
tested:
 Modulesare integrated in steps
according to an integration plan
 The partially integrated system
is tested at each integration
step.
24
 Types of System Testing
 Based on types test:

 Functionality test

 Performance test

 Based on who performs testing:

 Alpha

 Beta
26

 Acceptance test 26
 User Acceptance Testing

 User determines whether the system

fulfills his requirements

 Accepts or rejects delivered system

based on the test results.

28

28
 V&V
Feasibility Study

Req. Analysis

Design
Testing by developers

Coding
Testing by Tester
Review,
Simulation, etc. Testing

Maintenance

30
 Capers Jones Rule of Thumb

 Each of software review,

inspection, and test step will find
30% of the bugs present.
In IEEE Computer, 1996

32
 Quiz 1. When are verification
undertaken in waterfall
model?
Feasibility Study 2. When is testing
undertaken in waterfall
Req. Analysis
model?
Design
3. When is validation
Coding undertaken in waterfall
model?
Testing

Maintenance

34
 Test Cases
 Each test case typically tries to
establish correct working of some
functionality:
 Executes (covers) some program
elements.
 Forcertain restricted types of
faults, fault-based testing can be
used. 36
 Test Cases and Test Suites

 A test case is a triplet [I,S,O]

I is the data to be input to the
system,
S is the state of the system at which
the data will be input,
O is the expected output of the
system.
38
 What are Negative Test Cases?
 Purpose:
 Helps to ensure that the application
gracefully handles invalid and unexpected
user inputs and the application does not
crash.
 Example:
 Ifuser types letter in a numeric field, it
should not crash but politely display the
message: “incorrect data type, please enter a
40

number…” 40
Test Case number
Test Case author
Test purpose Sample: Recording of Test Case & Results
Pre-condition:
Test inputs:
Expected outputs (if any):
Post-condition:
Test Execution history:
Test execution date
Person executing Test
Test execution result (s) : Pass/Fail
42

If failed : Failure information and fix status 42

Software Testing
continued…

44
 If test cases are selected randomly:
 Many test cases would not contribute to
the significance of the test suite,
 Wouldonly detect errors that are already
detected by other test cases in the suite.

 Therefore, the number of test cases

in a randomly selected test suite:
 Does not indicate the effectiveness of
testing. Design of
Test Cases
46
 Design of Test Cases

 The code has a simple programming error:

 If (x>y) max = x;
else max = x; // should be max=y;

 Test suite {(x=3,y=2);(x=2,y=3)} can detect

the bug,

 A larger test suite {(x=3,y=2);(x=4,y=3);

(x=5,y=1)} does not detect the bug.
48
 Testing Strategy
 Test Strategy primarily addresses:
 Which types of tests to deploy?
 How much effort to devote to which
type of testing?
 Black-box: Usage–based testing (based on
customers’ actual usage pattern)
 White-box testing can be guided by black
50

box testing results

50
 When and Why of Unit Testing?

• Unit testing carried out:

 After coding of a unit is complete
and it compiles successfully.

 Unit testing reduces debugging

effort substantially.

52
 Unit Testing

PROCEDURE
STUB UNDER TEST
DRIVER
CALL CALL

Access To Nonlocal Variables

54
 Design of Unit Test Cases

 There are essentially three main

approaches to design test cases:
 Black-box approach

 White-box (or glass-box) approach

 Grey-box approach

56

56
 What is Hard about BB Testing

 Data domain is large

 A function may take multiple

parameters:

 We need to consider the combinations of

the values of the different parameters.

58
 Solution

 Construct model of the data domain:

 Called Domain based testing

 Select data based on the domain model

60
 Software considered as a black box:
Test data derived from the specification
 No knowledge of code necessary Black Box
Testing
 Also known as:
 Data-driven or
 Input/output driven testing

 The goal is to achieve the thoroughness of

exhaustive input testing:
Input System Output

With much less effort!!!! 62

 Use Case
Scenarios

Start use case

Alternative flow 3 Alternative flow 1

Alternative flow 2

Alternative flow 4
end use case
end use case
end use case

64
 Identify use case scenarios: Example

Scenario Originating flow Alternative Next Next

number flow alternative alternative

1 Basic flow

2 Basic flow Alt. flow 1

3 Basic flow Alt. flow 1 Alt. flow 2

4 Basic flow Alt. flow 3

5 Basic flow Alt. flow 3 Alt. flow 1

6 Basic flow Alt. flow 3 Alt. flow 1 Alt. flow 2

7 Basic flow Alt. flow 4

8 Basic flow Alt. flow 3 Alt. flow 4

66
Equivalence Class
Testing

68
 Why Define Equivalence Classes?

 Premise: E1 E2 E3

 Testing code with any one

representative value from a
equivalence class:

As good as testing using any other

values from the equivalence class.
70
 Equivalent class partition: Example

 Given three sides, determine the type

of the triangle:
 Isosceles

 Scalene

 Equilateral, etc.

 Hint: scenarios expressed in output in

this case. 72
 Equivalence Partitioning

 Further partition valid and

invalid test cases into
equivalence classes

Invalid
Valid

74
 Equivalence Class Partitioning

 If the input data to the program is

specified by a range of values:
 e.g. numbers between 1 to 5000.

 One valid and two invalid equivalence

classes are defined.
1 5000

76
 Example

 A program reads an input value in the

range of 1 and 5000:

 Computes the square root of the input

number

SQRT

78
 Example (cont.)

 The test suite must include:

Representatives from each of the
three equivalence classes:
A possible test suite can be:
{-5,500,6000}.
1 5000

80
 Design Equivalence class test cases: Quiz 1
 A bank pays different rates of interest on a
deposit depending on the deposit period.

 3% for deposit up to 15 days

 4% for deposit over 15days and up to 180 days

 6% for deposit over 180 days upto 1 year

 7% for deposit over 1 year but less than 3

years

 8% for deposit 3 years and above 82

Special Value
Testing

84
 Boundary Value Analysis

 Some typical programming errors occur:

 At boundaries of equivalence classes

 Mightbe purely due to psychological

factors.

 Programmers often fail to see:

 Special processing required at the boundaries
of equivalence classes.
86
 Boundary Value Analysis: Guidelines
 If an input condition specifies a range, bounded by values
a and b:
 Test cases should be designed with value a and b, just
above and below a and b.
 If an input condition specifies a range of number values:
 Test cases should be exercise the minimum and maximum
numbers. Values just above and below minimum and maximum
are also to be tested.
 Example 1: Integer D with input range [-3, 10],
 test values: -3, 10, 11, -2, 0
 Example 2: Input in the range: [3,102]
 test values: 3, 102, -1, 200, 5
88
 Boundary Value Testing Example (cont)

 If (applicantAge >= 0 && applicantAge <=16)

hireStatus="NO";

 If (applicantAge >= 16 && applicantAge <=18)

hireStatus="PART";

 If (applicantAge >= 18 && applicantAge <=55)

hireStatus="FULL";

 If (applicantAge >= 55 && applicantAge <=99)

hireStatus="NO";
90
 Boundary Value Testing Example (cont)
 The code to implement the corrected rules is:
If (applicantAge >= 0 && applicantAge <=15)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=17)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=54)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
 Special values on or near the boundaries in this example
are {-1, 0, 1}, {14, 15, 16}, {17, 18, 19}, {54, 55, 56}, and
92

{98, 99, 100}. 92

 Example 1

 For a function that computes the square

root of an integer in the range of 1 and
5000:
 Test cases must include the values:
{0,1,2,4999,5000,5001}.
1 5000

94
 Boundary Value Analysis: Robustness

 Numeric values are often entered as strings :

 Internally converted to numbers [int x = atoi(str);]

 This conversion requires the program to

distinguish between digits and non-digits

 A boundary case to consider: Will the program

accept / and : as digits?

Char / 0 1 2 3 4 5 6 7 8 9 :
ASCII 47 48 49 50 51 52 53 54 55 56 57 58

96
 Quiz: BB Test Design

 Design black box test suite for a

function that solves a quadratic
equation of the form ax2+bx+c=0.
Complex
 Equivalence classes Coincident
Real

 Invalid Equation Unique

 Valid Equation: Roots?

98
 Combinations

Rule1 Rule2 Rule3 Rule4

Condition1 Yes Yes No No

Condition2 Yes X No X
Conditions
Condition3 No Yes No X

Condition4 No Yes No Yes

Action1 Yes Yes No No

Actions Action2 No No Yes No

Action3 No No No Yes

100
 Test cases from Decision Tables
Test Case
ID a b c Expected
output

TC1 4 1 2 Not a
Triangle
TC2 2888 2888 2888 Equilateral
TC3 ? | ) Impossible
TC4
…

TC11

102
 Case a b c Expected
Output
ID
DT1 4 1 2 Not a
Triangle

DT2 1 4 2 Not a
Triangle

Test Cases for DT3 1 2 4 Not a

Triangle
the Triangle
Problem DT4 5 5 5 Equilateral

DT5 ? ? ? Impossible

DT6 ? ? ? Impossible

DT7 2 2 3 Isosceles

DT8 ? ? ? Impossible

DT9 2 3 2 Isosceles

DT10 3 2 2 Isosceles
104

DT11 3 4 5 Scalene
104
 Quiz: Develop BB Test Cases
 Policy for charging customers for certain
in-flight services:

If the flight is more than half-full and

ticket cost is more than Rs. 3000, free
meals are served unless it is a domestic
flight. The meals are charged on all
domestic flights.

106
 POSSIBLE COMBINATIONS
Analyze
column by more than
N N N N Y Y Y Y
column to half-full

CONDITONS
determine
which actions more than Rs.
N N Y Y N N Y Y
are 3000 per seat
appropriate
for each domestic
combination N Y N Y N Y N Y
flight
ACTION

serve meals X X X X
S

free X

108
 Final Combinations
solution more than half-full N Y Y Y

CONDITONS more than 3000 per

- N Y Y
seat

domestic flight - - N Y
ACTIONS

serve meals X X X

free X

110
 Guidelines and Observations
 Decision Table testing is most appropriate for
programs for which:
 There is a lot of decision making
 There are important logical relationships among
input variables
 There are calculations involving subsets of input
variables
 There are cause and effect relationships between
input and output
 There is complex computation logic

Decision tables do not scale up very well

112

Software Testing
Continued...

114
 What is White-box Testing?

 White-box test cases designed based

on:

 Code structure of program.

 White-box testing is also called structural

testing.

116
 Several white-box testing strategies have become
very popular :
 Statement coverage
 Branch coverage
White-Box
 Path coverage Testing
 Condition coverage
 MC/DC coverage
 Mutation testing
 Data flow-based testing
118
 Coverage-Based Testing Versus Fault-Based
Testing

 Idea behind coverage-based testing:

 Design test cases so that certain program
elements are executed (or covered).
 Example: statement coverage, path coverage,
etc.
 Idea behind fault-based testing:
 Design test cases that focus on discovering
certain types of faults.
 Example: Mutation testing. 120
 Stronger and
Coverage Weaker Testing

Stronger
Weaker

122
Stronger, Weaker, and Complementary
Testing

Complementary

Weaker

124
 Statement Coverage

 The principal idea:

 Unless a statement is executed,

 We have no way of knowing if an error

exists in that statement.

126
 Statement Coverage

 Coverage measurement:
# executed statements
# statements

 Rationale: a fault in a statement can only be

revealed by executing the faulty statement

128
 Example

int f1(int x,int y){

1 while (x != y){
2 if (x>y) then
3 x=x-y;
4 else y=y-x;
5 }
6 return x; }

130
 Branch Coverage

 Also called decision coverage.

 Test cases are designed such that:
Each branch condition
 Assumes true as well as false value.

132
 Example

 Test cases for branch coverage can be:

 {(x=3,y=3),(x=3,y=2), (x=4,y=3),
(x=3,y=4)}

134
 Quiz 1: Branch and Statement
Coverage: Which is Stronger?

 Branch testing guarantees statement

coverage:

A stronger testing compared to the

statement coverage-based testing.

136
Coverage
Report

138
 Statements vs Branch Testing
 Traversing all edges of a graph causes all nodes
to be visited

 So a test suite that satisfies branch

adequacy criterion also satisfies statement
adequacy criterion for the same program.

 The converse is not true:

 A statement-adequate (or node-adequate)

test suite may not be branch-adequate (edge-
adequate). 140
 All Branches can still miss
conditions
 Sample fault: missing operator (negation)

digit_high == 1 || digit_low == -1

 Branch adequacy criterion can be satisfied by

varying only digit_low

 The faulty sub-expression might not be

tested!

 Even though we test both outcomes of the

branch 142
 Example

 Consider the conditional expression

 ((c1.and.c2).or.c3):

 Each of c1, c2, and c3 are exercised

at least once,

 That is, given true and false values.

144
 Branch Testing

 To think of it:

 Branch testing is the simplest condition

testing strategy:

 Compound conditions determining

different branches

 Are given true and false values.

146
MC/DC Testing

148
 Condition Testing

 Condition/decision coverage:

 Each atomic condition made to assume both T and F

values

 Decisions are also made to get T an F values

 Multiple condition coverage (MCC):

 Atomic conditions made to assume all possible

combinations of truth values

150
 Shortcomings of Condition Testing

 Redundancy of test cases: Condition

evaluation could be compiler-dependent:

 Short circuit evaluation of conditions

 Coverage may be Unachievable: Possible

dependencies among variables:

 Example: ((chr==`A ́)||(chr==`E ́)) can not both be

true at the same time

152
 Multiple Condition Coverage

 Consider a Boolean expression having n

components:
n
 For condition coverage we require 2 test
cases.

 Therefore practical only if n (the number

of component conditions) is small ( two or
three).
154
 What is MC/DC?

 MC/DC stands for Modified Condition / Decision

Coverage

 It is a condition coverage technique

 Condition: Atomic conditions in expression.

 Decision: Controls the program flow.

 Main idea: Each condition must be shown to

independently affect the outcome of a decision.
 The outcome of a decision changes as a result of
changing a single condition. 156
 MC/DC Requirement 1

• The decision is made to take both T/F values.

If (( a>10 ) && (( b<50 ) && ( c==0 ))) then

true false

 This is as in Branch coverage.

158
 MC/DC Requirement 3
• Every condition in the decision independently affects the
decision’s outcome.

If ( ( a>10 ) && (( b<50 ) || ( c==0 )) ) then…

true false true false

If ( ( a>50 ) && (( b<50 ) || ( c==0 ))

) then…

true true false false

If ( ( a>50 ) && ( ( b<50 ) || ( c==0 ))) then…

true false true false

160
 Another Example

If( (A  B)  C) ….
A B C Result A B C MC/DC

1 1 1 1 1
2 1 1 0 0 * *
3 1 0 1 1 * *
4 0 1 1 1 * *
5 1 0 0 0 * *
6 0 1 0 0
7 0 0 1 0
8 0 0 0 0
* * *
162
 Critique
 MC/DC criterion is stronger than
condition/decision coverage MCC

criterion,
MC/DC

 but the number of test cases to

Condition/Decision
achieve the MC/DC criterions still
linear in the number of conditions Decision

n in the decisions. Statement

164
166
 Path Coverage
 Design test cases such that:

 All linearly independent paths in the

program are executed at least once.

 Defined in terms of

 Control flow graph (CFG) of a program.

168
 How to Draw Control Flow Graph?
 Number all statements of a program.
 Numbered statements:
 Represent nodes of control flow graph.

 Draw an edge from one node to another

node:
 Ifexecution of the statement representing
the first node can result in transfer of
control to the other node.
170
 Cyclomatic Complexity

 The first method of computing V(G) is

amenable to automation:
 You
can write a program which determines the
number of nodes and edges of a graph

 Applies the formula to find V(G).

172
 Cyclomatic Complexity

 Knowing the number of test cases

required:
 Does not make it any easier to derive the
test cases,

 Only gives an indication of the minimum

number of test cases required.

174
 Derivation of Test Cases
 Draw control flow graph.
 Determine V(G).
 Determine the set of linearly
independent paths.
 Prepare test cases:
 Force execution along each path.
 Not practical for larger programs. 176
178
180
182
184
186
188
 Derivation of Test Cases

 Number of independent paths: 3

 1,6

 1,2,3,5,1,6

 1,2,4,5,1,6

190
192
194
 Derivation of Test Cases

 Number of independent paths: 3

 1,6 test case (x=1, y=1)

 1,2,3,5,1,6 test case(x=1, y=2)

 1,2,4,5,1,6 test case(x=2, y=1)

196
 Cyclomatic Complexity

 Cyclomatic complexity of a
program:
Also indicates the psychological
complexity of a program.

Difficulty level of understanding the

program.
198
 Dataflow and
Mutation Testing

200
 White-Box Testing : Recap

statement
weakest coverage

condition branch
coverage (or decision)
coverage

branch and condition

(or condition /decision)
coverage
Practically important
coverage techniques independent path
modified condition / (or basis path)
decision coverage
coverage

multiple- condition
coverage

strongest All path

coverage

202
 Data Flow-Based Testing

 Select test paths of a program:

 According to the locations of

 Definitions and uses of different variables

in a program.

204
 Data Flow-Based Testing
 For a statement numbered S,
 DEF(S) = {X/statement S contains a definition
of X}
 USES(S)= {X/statement S contains a use of
X}
 Example: 1: a=b; DEF(1)={a}, USES(1)={b}.
 Example: 2: a=a+b; DEF(1)={a}, USES(1)={a,b}.

206
 DU Chain Example
1 X(){
2 int a=5; /* Defines variable a */
3 While(c>5) {
4 if (d<50)
5 b=a*a; /*Uses variable a */
6 a=a-1; /* Defines variable a */
7 }
8 print(a); } /*Uses variable a */

208
 Data Flow-Based Testing

 One simple data flow testing strategy:

 Every DU chain in a program be covered at
least once.

 Data flow testing strategies:

 Usefulfor selecting test paths of a program
containing nested if and loop statements.

210
 Data Flow-Based Testing

 [a,1,5]: a DU chain.

 Assume:
 DEF(X) = {B1, B2, B3, B4, B5}

 USES(X) = {B2, B3, B4, B5, B6}

 There are 25 DU chains.

 However only 5 paths are needed to cover

these chains.
212
 Mutation Testing

 In this, software is first tested:

 Usingan initial test suite designed using white-

box strategies we already discussed.
 After the initial testing is complete,

 Mutation testing is taken up.

 The idea behind mutation testing:

 Make a few arbitrary small changes to a

program at a time.
214
 Mutation Testing Terminology

 Each time the program is changed:

 It is called a mutated program

 The change is called a mutant.

216
 Mutation Testing
 If a mutant remains alive:

 Even after all test cases have been

exhausted,

 Thetest suite is enhanced to kill the

mutant.
 The process of generation and killing of mutants:

 Canbe automated by predefining a set

of primitive changes that can be applied
to the program. 218
 Traditional Mutation Operators
 Deletion of a statement
 Boolean:
 Replacement of a statement with another
eg. == and >=, < and <=
 Replacement of boolean expressions with true or false
eg. a || b with true
 Replacement of arithmetic
eg. * and +, / and -
 Replacement of a variable (ensuring same
scope/type)
220
 The Competent Programmer Hypothesis

 Programmers create programs that are

close to being correct:

 Differ from the correct program by some

simple errors.

222
 The Mutation Process

Program If program is
not error-free,
Create fix it
Mutants Test
Process

Mutation
Mutation Tests
Problem
New Testwith
Mutant Test Tests?
Cases
Mutants
Yes

Any Live Test

Mutants that are Mutants? No Complete
caught by tests are killed
Dead
Mutants

224
 Disadvantages of Mutation Testing

 Equivalent mutants

 Computationally very expensive.

 A large number of possible mutants can be
generated.

 Certain types of faults are very difficult to

inject.
 Only simple syntactic faults introduced

226
 Quiz 1: Solution
 Identify two advantages and two
disadvantages of the mutation test
technique.
 Adv:
 Can be automated
 Helps effectively strengthen black box and
coverage-based test suite
 Disadv:
 Equivalent mutants
228
 How to Draw Control flow Graph?

 Sequence: 1
1 a=5;
2 b=a*b-1;
2

230
 How to Draw Control Flow Graph?

 Iteration:
1
1 while(a>b){
2 b=b*a; 2

3 b=b-1;}
3
4 c=b+d;
4

232
 All Path Criterion

 In the presence of loops, the number

paths can become extremely large:
 This makes all path testing
impractical

234
 Independent path

 It is straight forward:

 To identify linearly independent paths of

simple programs.

 For complicated programs:

 It is not easy to determine the number of

independent paths.
236
 McCabe's Cyclomatic Metric

 Given a control flow graph G,

cyclomatic complexity V(G):
 V(G)= E-N+2

 N is the number of nodes in G

 E is the number of edges in G

238
 Cyclomatic Complexity

 Another way of computing cyclomatic

complexity:
 inspect control flow graph

 determine number of bounded areas in the

graph

 V(G) = Total number of bounded areas + 1

 Any region enclosed by a nodes and edge
sequence. 240
 Example

 From a visual examination of the CFG:

 Number of bounded areas is 2.
 Cyclomatic complexity = 2+1=3.

242
 Coding Phase
 Coding is undertaken once design
phase is complete.
 During coding phase:
 every module identified in the design
document is coded and unit tested.
 Unit testing (aka module testing):
 testing of different modules (aka units)
of a system in isolation. 2
 Coding
 At the end of the design phase we have:
 modulestructure (e.g. structure chart) of
the system
 module specifications:
 data structures and algorithms for each
module.
 Objective of coding phase:
 transform design into code
 unit test the code. 4
 Coding Standards
 Many software development
organizations:
 formulatetheir own coding
standards that suits them most,
 requiretheir engineers to
follow these standards
rigorously. 6
 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.
8
8
 Code inspection and code walk
throughs
 After a module has been coded:
 codeinspection and code walk
through are carried out
 ensures that coding standards
are followed
 helpsdetect as many errors as
possible before testing. 10
 Coding Standards and
Guidelines
 Good organizations usually develop
their own coding standards and
guidelines:
 depending on what best suits their
organization.

 We will discuss some representative

coding standards and guidelines.
12
Representative Coding Standards

 Contents of headers for different

modules:
 Theheaders of different modules
should be standard for an
organization.
 The exact format for header
information is usually specified.
14
Representative Coding 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.
16
 Representative Coding Guidelines

 Clever coding can obscure meaning

of the code:
 hampers understanding.
 makes later maintenance
difficult.
 Avoid obscure side effects.
18
 Representative Coding Guidelines
 Obscure side effects make it difficult
to understand a piece of code.

 For example,
 if a global variable is changed obscurely in
a called module,

 it becomes difficult for anybody trying

to understand the code.
20
Example use of a variable for
multiple purposes

 for(i=1;i<100;i++)
{…..}
i=2*p*q;
return(i);

22
 Use of a variable for multiple
purposes
 There are several things wrong
with this approach:
 hence should be avoided.
 Each variable should be given a
name indicating its purpose:
 Thisis not possible if an identifier is
used for multiple purposes.
24
 Representative Coding Guidelines

 Code should be well-documented.

 Rules of thumb:
 onthe average there must be at least
one comment line
 for every three source lines.

 Thelength of any function should not

exceed 10 source lines.
26
Representative Coding Guidelines

 Do not use goto statements.

 Use of goto statements:
 make a program unstructured
 makeit very difficult to
understand.

28
28
 Code Walk Through
 Even though an informal technique:
 several guidelines have evolved over the
years
 making this naive but useful analysis
technique more effective.
 These guidelines are based on
 personal experience, common sense, and
several subjective factors.
30
 Code Walk Through
 Discussion should focus on discovery of
errors:
 and not on how to fix the discovered
errors.
 To foster cooperation:
 avoid the feeling among engineers that
they are being evaluated in the code walk
through meeting,
 managers should not attend the walk
through meetings.
32
 Code Inspection
 For instance, consider:
 classical error of writing a procedure that
modifies a formal parameter
 while the calling routine calls the procedure
with a constant actual parameter.
 It is more likely that such an error will be
discovered:
 by looking for this kind of mistakes in the code,
 rather than by simply hand simulating execution
of the procedure.
34
 Commonly made errors
 Use of uninitialized variables.
 Nonterminating loops.
 Array indices out of bounds.
 Incompatible assignments.
 Improper storage allocation and
deallocation.
 Actual and formal parameter mismatch in
procedure calls.
 Jumps into loops. 36
 Software Documentation
 When developing a software product we develop
various kinds of documents :
 In addition to executable files and the source code:
 users' manual,
 software requirements specification (SRS)
document,
 design document, test document,
 installation manual, etc.

 All these documents are a vital part of good

software development practice.
38
 Internal Documentation

 Internal documentation:
 documentation provided in the
source code itself.
 External documentation:
 documentation other than those
present in the source code.

40
 Internal Documentation
 Good software development
organizations:
 ensure good internal documentation

 through coding standards and coding

guidelines.

 Example of unhelpful documentation:

 a = 10; /* a made 10 */ 42
 External Documentation
 Users' manual,
 Software requirements specification
document,
 Design document,
 Test documents,
 Installation instructions, etc.
44
 External Documentation
 Unless all documents are consistent
with each other,
a lot of confusion is created for somebody
trying to understand the product.
 All the documents for a product should
be up-to-date:
 Even a few out-of-date documents can
create severe confusion. 46
 Gunning’s Fog Index

Number of Words Percentage of

F=0.4 ` + words of 3 or
Number of Sentences more syllables

 F corresponds to the number of years

of schooling to easily understand the
document.

48
 Summary
 Widgets are the building blocks of
user interface design.
 To develop a modern GUI:
 put together the widgets you require
 stitch them together.
 makes user interface development easy.

50
 Summary
 Coding standards:
 enforce good coding practice
 Coding guidelines:
 suggestions to programmers
 exact implementation depends on
discretion of the programmers.

52
 Summary
 Documentation
 Internal

 External

 Internal documentation
 provided in the source code itself.
 Comprehensibility of text
documents: 54
Contents
1 Introduction 4
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Definitions, Acronyms, and Abbreviations . . . . . . . . . . . . . 4
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Overall Description 5
2.1 Product perspective . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Registration: . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Patient check out. . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Report Generation: . . . . . . . . . . . . . . . . . . . . . . 6
2.3 User characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Front-desk staff: . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Administrators: . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 General Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . 7

3 Specific Requirement 7
3.1 External Interface Requirements . . . . . . . . . . . . . . . . . . 7
3.1.1 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 Communications Interfaces . . . . . . . . . . . . . . . . . 8
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Check Out . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 Report Generation . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Logical Database Requirements . . . . . . . . . . . . . . . . . . . 9
3.4 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . 9
3.5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5.2 Performance Requirements . . . . . . . . . . . . . . . . . 10

2
1 Introduction
1.1 Purpose
The purpose of this document is to describe the requirements for the Hospital
Patient Info Management System (HPIMS). The intended audience includes all
stakeholders in the potential system. These include, but are not necessarily
limited to, the following: Administrative Staff, patients and developers.
Developers should consult this document and its revisions as the only source
of requirements for the project. They should not consider any requirements
statements, written or verbal as valid until they appear in this document or its
revision.

1.2 Scope
The proposed software product is the Hospital Patient Info Management System
(HPIMS). The system will be used to get the information from the patients and
then storing that data for future usage. The current system in use is a paper-
based system. It is too slow and cannot provide updated lists of patients within
a reasonable timeframe.The intentions of the system are to reduce over-time pay
and increase the number of patients that can be treated accurately. Require-
ments statements in this document are both functional and non-functional.

1.3 Definitions, Acronyms, and Abbreviations

AHSS Advanced High Strength Steel
HPIMS Hospital Patient Info Management System
PHN Personal Health Number on health card
Report an account of patients
Front-desk staff administrative staff that work at reception desk
Logon ID a user identification number to enter the system
Password a word that enables one to gain admission into the system
Web-based an application that runs on the Internet
application

MySQl a query language to interrogate the system

GUI Graphical User Interface
SRS Software Requirements Speficification

4
2.2.2 Patient check out.

If a patient checks out, the administrative staff shall delete his PHN from the
system and the just evacuated bed is included in available-beds list.

2.2.3 Report Generation:

Report Generation: The system generates reports on the following information:

List of detailed information regarding the patient who has admitted in the
hospital.

2.3 User characteristics

The system will be used in the hospital. The administrators,front-desk staff
will be the main users. Given the condition that not all the users are computer-
literate. Some users may have to be trained on using the system. The system
is also designed to be user-friendly. It uses a Graphical User Interface (GUI).

2.3.1 Front-desk staff:

They all have general reception and secretarial duties. Every staff has some basic
computer training. They are responsible for patient’s check-in or notification of
appropriate people.

2.3.2 Administrators:

They all have post-secondary education relating to general business adminis-

tration practices. Every administrator has basic computer training. They are
responsible for all of the scheduling and updating day/night employee shifts.

2.4 General Constraints

1. The system must be delivered by January 1st 2011.
2. The existing Telecommunication infrastructure is based on IEEE100802.3
standards and the system must conform to this standard using category
5 cables for networking

3. The system must be user-friendly

6
3.1.4 Communications Interfaces

<Describe the requirements associated with any communications functions re-

quired by this product, including e-mail, web browser, network server commu-
nications protocols, electronic forms, and so on. Define any pertinent message
formatting. Identify any communication standards that will be used, such as
FTP or HTTP. Specify any communication security or encryption issues, data
transfer rates, and synchronization mechanisms.>

3.2 Functional Requirements

3.2.1 Registration

SRS001 : Add patients The HPIMS shall allow front-desk staff to

add new patients to the system.

SRS002 : Assign ID The HPIMS shall allow front-desk staff to give

each patient a ID and add it to the patient’s record. This ID shall be
used by the patient throughout his/her stay in hospital.

3.2.2 Check Out

SRS003 : Delete Patient ID The administrative staff in the ward

shall be allowed to delete the ID of the patient from the system when
the patient checks out.

SRS004 : Add to beds-available list The HPIMS shall allow front-

desk staff to give each patient a ID and The administrative staff in the
ward shall be allowed to put the beds just evacuated in beds-available
list.

3.2.3 Report Generation

SRS005 : Patient information The administrative staff in the ward

shall be allowed to delete the ID of the patient from the system when
the patient checks out.

SRS006 : Bed Aavailability The HPIMS shall allow front-desk staff

to give each patient a ID and The administrative staff in the ward
shall be allowed to put the beds just evacuated in beds-available list.