V E E R S U R E N D R A S A I U N I V E R S I T Y O F T E C H N O L O G Y, B U R L A

Software Engineering
Complete Lecture Notes & Examination Guide

Module 1 - All 10 Lectures Covered

Dr. H.S. Behera | Asst. Prof. K.K. Sahu | Asst. Prof. Gargi Bhattacharjee

LEC TU RE N O TES & STU DY GU IDE

Table of Contents

Lecture 1: Introduction to Software Engineering

1.1.
Software & Software Engineering Defined
1.2.
Need for Software Engineering
1.3.
Characteristics of Good Software
Lecture 2: Software Development Life Cycle
2.1.
SDLC Activities - 11 Stages
2.2.
Need for a Software Life Cycle Model
2.3.
Classical Waterfall Model
2.4.
Iterative Model
Lecture 3: Prototype Model & Spiral Model
3.1.
Prototyping Model - 4 Steps
3.2.
Spiral Model - 4 Quadrants
Lecture 4: Requirement Analysis & Specification
4.1.
Requirement Engineering Process
4.2.
Requirement Elicitation Process
4.3.
Elicitation Techniques
Lecture 5: Software Requirement Characteristics
5.1.
 SRS Qualities
5.2.
Functional & Non-Functional Requirements
5.3.
User Interface Requirements
5.4.
System Analyst & Software Metrics
Lecture 6: Software Design
6.1.
Three Levels of Software Design
6.2.
Modularization
6.3.
Concurrency
Lecture 7: Coupling & Cohesion
7.1.
Cohesion - 7 Types
7.2.
Coupling - 5 Levels
7.3.
Design Verification
Lecture 8: Software Analysis & Design Tools - DFD
8.1.
Data Flow Diagram
8.2.
Levels of DFD
Lecture 9: Structure Charts & Structured English
9.1.
Structure Chart Symbols
9.2.
Structured English
9.3.
Pseudo-Code
Lecture 10: Decision Table, ER Model, Data Dictionary
10.1.
 Decision Tables
10.2.
Entity-Relationship Model
10.3.
Data Dictionary
Quick Reference Tables
References
Lecture 1Introduction to Software Engineering

Lecture 1

Introduction to Software Engineering

1.1 Software & Software Engineering Defined

The term software engineering is composed of two words: software and engineering.
Understanding each term separately is essential to grasping the discipline as a whole.

Software
Software is more than just program code. A program is an executable code that
serves some computational purpose. Software is considered to be a collection of
executable programming code, associated libraries, and documentations.
Software, when made for a specific requirement, is called a software product.

Engineering
Engineering is all about developing products using well-defined, scientific
principles and methods.

Software Engineering
Software engineering is an engineering branch associated with the development
of software product using well-defined scientific principles, methods, and
procedures. The outcome of software engineering is an efficient and reliable
software product.

IEEE Definition of Software Engineering

"The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software."

We can alternatively view software engineering as a systematic collection of past

experience. The experience is arranged in the form of methodologies and guidelines.

KEY PRINCIPLE
A small program can be written without using software engineering principles. But
if one wants to develop a large software product, then software engineering

5
Lecture 1Introduction to Software Engineering

principles are absolutely necessary to achieve good quality software cost-effectively.

Problem Complexity Reduction Techniques

Software engineering principles use two important techniques to reduce problem
complexity:
1. Abstraction - The principle of abstraction implies that a problem can be simplified by
omitting irrelevant details. The main purpose of abstraction is to consider only those
aspects of the problem that are relevant for a certain purpose and suppress other aspects
that are not relevant for the given purpose. Once the simpler problem is solved, the
omitted details can be taken into consideration to solve the next lower level abstraction,
and so on. Abstraction is a powerful way of reducing the complexity of the problem.
2. Decomposition - In this technique, a complex problem is divided into several
smaller problems and then the smaller problems are solved one by one. However, any
random decomposition will not help. The problem has to be decomposed such that each
component can be solved independently and then the solutions of the different
components can be combined to get the full solution. A good decomposition should
minimize interactions among various components.

1.2 Need for Software Engineering

The need for software engineering arises because of the higher rate of change in user
requirements and environment on which the software is working.
Table 1.1: Need for Software Engineering - Key Factors

Factor Description

Large As the size of software becomes large, engineering has to step in to give it a
Software scientific process. It is easier to build a wall than a house or building.

Scalability If the software process were not based on scientific and engineering concepts,
it would be easier to re-create new software than to scale an existing one.

Cost As the hardware industry has lowered the price of computers, the cost of
software remains high if proper process is not adopted.

6
Lecture 1Introduction to Software Engineering

Dynamic The always growing and adapting nature of software hugely depends upon
Nature the environment in which the user works. New enhancements need to be
done in existing software.

Quality Better process of software development provides better and quality

Management software product.

1.3 Characteristics of Good Software

A software product can be judged by what it offers and how well it can be used. Well-
engineered and crafted software is expected to have characteristics across three
categories:

1.3.1 Operational Characteristics

This tells us how well software works in operations. It can be measured on:
Budget - Cost-effectiveness in development and operation
Usability - Ease of use for end users
Efficiency - Optimal use of system resources
Correctness - Accuracy of outputs and behavior
Functionality - Range of features provided
Dependability - Reliability and trustworthiness
Security - Protection against unauthorized access
Safety - Prevention of harm to users or data

1.3.2 Transitional Characteristics

This aspect is important when the software is moved from one platform to another:
Portability - Ability to run on different platforms
Interoperability - Ability to work with other systems
Reusability - Components can be reused in other projects
Adaptability - Ease of modification for different environments

1.3.3 Maintenance Characteristics

7
Lecture 1Introduction to Software Engineering

This aspect briefs about how well software can maintain itself in the ever-changing
environment:
Modularity - Divided into independent, manageable modules
Maintainability - Ease of making modifications
Flexibility - Ability to accommodate changes
Scalability - Ability to handle growing amounts of work

EXAM TIP: Memorize all three categories and their characteristics - commonly asked in 5-
mark questions.

Table 1.2: Summary of Good Software Characteristics

Category Characteristics

Operational Budget, Usability, Efficiency, Correctness, Functionality, Dependability,

Security, Safety

Transitional Portability, Interoperability, Reusability, Adaptability

Maintenance Modularity, Maintainability, Flexibility, Scalability

DEFINING STATEMENT
Software engineering is a branch of computer science, which uses well-defined
engineering concepts required to produce efficient, durable, scalable, in-budget
and on-time software products.

* * * * *

8
Lecture 2Software Development Life Cycle

Lecture 2

Software Development Life Cycle

2.1 SDLC Activities - 11 Stages

Software Development Life Cycle (SDLC)

SDLC is a well-defined, structured sequence of stages in software engineering to
develop the intended software product.

SDLC provides a series of steps to be followed to design and develop a software product
efficiently. The SDLC framework includes the following 11 stages:

Stage 1: Communication
This is the first step where the user initiates the request for a desired software product.
The user contacts the service provider and tries to negotiate the terms. The request is
submitted to the service providing organization in writing.

Stage 2: Requirement Gathering

From this step onwards, the software development team works to carry out the project.
The team holds discussions with various stakeholders from the problem domain and
tries to bring out as much information as possible on their requirements. The
requirements are segregated into:
User requirements
System requirements
Functional requirements
Requirements are collected using practices such as:
Studying the existing or obsolete system and software
Conducting interviews of users and developers
Referring to the database
Collecting answers from questionnaires

9
Lecture 2Software Development Life Cycle

Stage 3: Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process.
At this step, the team analyzes if the software can be made to fulfill all requirements of
the user and if there is any possibility of the software being no longer useful. If the
project is financially, practically, and technologically feasible for the organization,
they take up the project; otherwise, they let it go.

Stage 4: System Analysis

At this step, the developers decide a roadmap of their plan and try to bring up the best
software model suitable for the project. System analysis includes:
Understanding software product limitations
Learning system-related problems or changes to be done in existing systems
beforehand
Identifying and addressing the impact of project on organization and personnel
Analyzing the scope of the project and planning schedule and resources accordingly

Stage 5: Software Design

The whole knowledge of requirements and analysis is brought to the desk to design the
software product. The output of this step comes in the form of two designs:
Logical design
Physical design
Engineers produce meta-data and data dictionaries, logical diagrams, data-flow
diagrams, and in some cases pseudo codes.

Stage 6: Coding
This step is also known as the programming phase. The implementation of software
design starts in terms of writing program code in the suitable programming language
and developing error-free executable programs efficiently.

Stage 7: Testing

10
Lecture 2Software Development Life Cycle

CRITICAL FACT
An estimate says that 50% of the whole software development process should be
tested. Errors may ruin the software from critical level to its own removal.

Software testing is done while coding by the developers, and thorough testing is
conducted by testing experts at various levels:
Module testing
Program testing
Product testing
In-house testing
Testing at user's end
Early discovery of errors and their remedy is the key to reliable software.

Stage 8: Integration
Software may need to be integrated with libraries, databases, and other programs.
This stage is involved in the integration of software with outer world entities.

Stage 9: Implementation
This means installing the software on user machines. At times, software needs post-
installation configurations at the user end. Software is tested for portability and
adaptability, and integration-related issues are solved during implementation.

Stage 10: Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and fewer
errors. If required, users are trained on or aided with documentation on how to operate
the software. The software is maintained timely by updating the code according to
changes taking place in user-end environment or technology.

Stage 11: Disposition

As time elapses, the software may decline in performance. It may go completely obsolete
or may need intense upgradation. This phase includes:
Archiving data and required software components

11
Lecture 2Software Development Life Cycle

Closing down the system

Planning disposition activity
Terminating system at appropriate end-of-system time

EXAM TIP: Memorize the 11 stages in sequence - frequently asked in examination.

2.2 Need for a Software Life Cycle Model

The development team must identify a suitable life cycle model for the particular
project and then adhere to it. Without using a particular life cycle model, the
development of a software product would not be in a systematic and disciplined
manner.

CRITICAL CONSEQUENCE
Without a particular life cycle model, the development of a software product would
not be in a systematic and disciplined manner. When a software product is being
developed by a team, there must be a clear understanding among team members
about when and what to do. Otherwise it would lead to chaos and project failure.

A software life cycle model defines entry and exit criteria for every phase. A phase can
start only if its phase-entry criteria have been satisfied. Without a software life cycle
model:
The entry and exit criteria for a phase cannot be recognized
It becomes difficult for software project managers to monitor the progress of the
project

2.3 Classical Waterfall Model

Classical Waterfall Model

The classical waterfall model is the simplest model of software development
paradigm. All the phases of SDLC function one after another in a linear manner.
When the first phase is finished, only then the second phase will start, and so on.

Key Characteristics

12
Lecture 2Software Development Life Cycle

Nature: Linear and sequential

Assumption: Everything is carried out perfectly as planned in the previous stage
No going back: The sequential nature does not allow us to go back and undo or redo
actions

Limitations
This model does not work smoothly if there are issues left at the previous step
Cannot address changes in requirements mid-process

Best Suited For

This model is best suited when developers already have designed and developed
similar software in the past and are aware of all its domains.

2.4 Iterative Model

Iterative Model
This model leads the software development process in iterations. It projects the
process of development in a cyclic manner, repeating every step after every cycle of
the SDLC process.

How It Works
The software is first developed on a very small scale and all the steps are followed.
Then, on every next iteration, more features and modules are designed, coded, tested,
and added to the software. Every cycle produces a software which is complete in itself
and has more features and capabilities than the previous one.

Key Characteristics
Nature: Cyclic and repeating
Process: Start small, add features each iteration
Advantage: Easier risk management; after each iteration, the management team can
work on risk management

13
Lecture 2Software Development Life Cycle

Disadvantage: Because a cycle includes a small portion of the whole software

process, it is easier to manage, but it consumes more resources
Table 2.1: Waterfall vs. Iterative Model Comparison

Aspect Waterfall Model Iterative Model

Approach Linear, sequential Cyclic, repeating

Phase Movement One direction only Repeats phases in cycles

Scale Full scale from start Starts small, grows incrementally

Risk Management Difficult Easier after each iteration

Resource Usage Controlled Consumes more resources

Best For Well-understood, similar projects Complex, evolving requirements

* * * * *

14
Lecture 3Prototype Model & Spiral Model

Lecture 3

Prototype Model & Spiral Model

3.1 Prototyping Model

Prototype
A prototype is a toy implementation of the system. It usually exhibits limited
functional capabilities, low reliability, and inefficient performance compared to
the actual software. A prototype is usually built using several shortcuts (inefficient,
inaccurate, or dummy functions).

Stepwise Approach to Design a Software Prototype (4 Steps)

Step 1: Basic Requirement Identification

This step involves understanding the very basic product requirements, especially in
terms of user interface. The more intricate details of internal design and external
aspects like performance and security can be ignored at this stage.

Step 2: Developing the Initial Prototype

The initial prototype is developed where the very basic requirements are showcased and
user interfaces are provided. These features may not exactly work in the same manner
internally in the actual software - workarounds are used to give the same look and feel
to the customer.

Step 3: Review of the Prototype

The prototype is presented to the customer and other important stakeholders.
Feedback is collected in an organized manner and used for further enhancements.

Step 4: Revise and Enhance the Prototype

Feedback and review comments are discussed. Negotiations happen with the customer
based on factors like time and budget constraints and technical feasibility. Changes
accepted are incorporated in the new prototype, and the cycle repeats until customer
expectations are met.

15
Lecture 3Prototype Model & Spiral Model

3.2 Spiral Model

Spiral Model
The spiral model appears like a spiral with many loops. The exact number of loops
is not fixed. Each loop represents a phase of the software process. Each phase is
split into four sectors (quadrants).

Spiral Model - Four Quadrants per Phase

Table 3.1: Spiral Model Quadrants

Quadrant Name Activities

First Objective Setting Identify the objectives of the phase. Examine the risks
associated with these objectives.

Second Risk Assessment Detailed analysis for each identified project risk. Steps are
and Reduction taken to reduce risks. If requirements are inappropriate,
a prototype may be developed.

Third Development and Develop and validate the next level of the product after
Validation resolving identified risks.

Fourth Review and Review results achieved so far with the customer and plan
Planning the next iteration around the spiral.

KEY POINT
Progressively more complete versions of the software get built with each iteration
around the spiral.

Table 3.2: Comparison of All Process Models

Model Nature Key Feature Best For

Waterfall Linear, No going back to previous Similar software developed

sequential phases before

Iterative Cyclic, Adds features each cycle Evolving requirements

repeating

Prototype Loop-based Customer feedback loop Unclear requirements

16
Lecture 3Prototype Model & Spiral Model

Spiral Risk-driven spiral 4 quadrants with risk analysis High-risk, complex projects

* * * * *

17
Lecture 4Requirement Analysis & Specification

Lecture 4

Requirement Analysis & Specification

The software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected
from the client's point of view.

4.1 Requirement Engineering

Requirement Engineering
The process to gather software requirements from client, analyze and document
them is known as requirement engineering. The goal is to develop and maintain a
sophisticated and descriptive System Requirements Specification (SRS) document.

Requirement Engineering Process - Four Steps

Step 1: Feasibility Study

When the client approaches the organization, they come up with a rough idea about what
functions the software must perform. The analysts do a detailed study about whether the
desired system and its functionality are feasible to develop.
This study analyzes whether the software product can be practically materialized in
terms of:
Implementation feasibility
Contribution of project to organization
Cost constraints
Values and objectives of the organization
Technical aspects: usability, maintainability, productivity, integration ability

OUTPUT OF FEASIB ILITY STUDY

A feasibility study report that contains adequate comments and
recommendations for management about whether or not the project should be

18
Lecture 4Requirement Analysis & Specification

undertaken.

Step 2: Requirement Gathering

If the feasibility report is positive, the next phase starts with gathering requirements
from the user. Analysts and engineers communicate with the client and end-users to
know their ideas on what the software should provide and which features they want.

Step 3: Software Requirement Specification (SRS)

SRS Document
SRS is a document created by the system analyst after the requirements are
collected from various stakeholders. SRS defines how the intended software will
interact with hardware, external interfaces, speed of operation, response time,
portability, maintainability, recovery after crashing, security, quality, and limitations.

The requirements received from the client are written in natural language. It is the
responsibility of the system analyst to document the requirements in technical language
so they can be comprehended by the software development team.
SRS should include:
User requirements expressed in natural language
Technical requirements expressed in structured language
Design description written in pseudo code
Format of forms and GUI screen prints
Conditional and mathematical notations for DFDs

Step 4: Software Requirement Validation

After requirement specifications are developed, the requirements are validated. User
might ask for illegal, impractical solutions or experts may interpret requirements
incorrectly. This results in a huge increase in cost if not caught early.
Requirements are checked against the following conditions:
Can they be practically implemented?
Are they valid and as per functionality and domain of software?
Are there any ambiguities?
Are they complete?
Can they be demonstrated?

19
Lecture 4Requirement Analysis & Specification

4.2 Requirement Elicitation Process

The requirement elicitation process consists of four stages:

Stage 1: Requirements Gathering

The developers discuss with the client and end users and know their expectations from
the software.

Stage 2: Organizing Requirements

The developers prioritize and arrange the requirements in order of importance,
urgency, and convenience.

Stage 3: Negotiation & Discussion

If requirements are ambiguous or conflicting among stakeholders, they are negotiated
and discussed. Requirements may then be prioritized and reasonably compromised.
Unrealistic requirements are compromised reasonably.

Stage 4: Documentation
All formal and informal, functional and non-functional requirements are
documented and made available for next phase processing.

4.3 Requirement Elicitation Techniques

Interviews
Interviews are a strong medium to collect requirements. Types of interviews include:
Structured (closed) interviews - Every information to be gathered is decided in
advance; they follow the pattern firmly
Non-structured (open) interviews - Information is not decided in advance; more
flexible and less biased

20
Lecture 4Requirement Analysis & Specification

Oral interviews
Written interviews
One-to-one interviews - Held between two persons across the table
Group interviews - Held between groups of participants; help uncover missing
requirements

Surveys
Organization may conduct surveys among stakeholders by querying about their
expectations and requirements from the upcoming system.

Questionnaires
A document with a pre-defined set of objective questions and respective options is
handed over to all stakeholders. A shortcoming: if an option for some issue is not
mentioned, the issue might be left unattended.

Task Analysis
The team of engineers and developers may analyze the operation for which the new
system is required. If the client already has software for certain operations, it is studied
to collect requirements.

Domain Analysis
Every software falls into some domain category. Expert people in the domain can be a
great help to analyze general and specific requirements.

Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.

Prototyping
Prototyping is building a user interface without adding detailed functionality for the
user to interpret features. If the client is not aware of their own requirements, the

21
Lecture 4Requirement Analysis & Specification

developer creates a prototype based on initially mentioned requirements. The prototype

is shown to the client and feedback is noted.

Observation
The team of experts visits the client's workplace. They observe the actual working of
existing systems, the workflow, and how execution problems are dealt. The team draws
conclusions which aid in forming requirements.

* * * * *

22
Lecture 5Software Requirement Characteristics

Lecture 5

Software Requirement Characteristics

5.1 SRS Must Be - 11 Qualities

Gathering software requirements is the foundation of the entire software

development project. Hence they must be clear, correct, and well-defined. A complete
Software Requirement Specifications must be:
Table 5.1: 11 Essential Qualities of SRS

# Quality Meaning

1 Clear Unambiguous and easy to understand

2 Correct Accurately represents requirements

3 Consistent No contradictions between requirements

4 Coherent Requirements are logically connected

5 Comprehensible Can be understood by all stakeholders

6 Modifiable Easy to update when changes occur

7 Verifiable Can be tested and validated

8 Prioritized Ranked by importance

9 Unambiguous Only one interpretation possible

10 Traceable Each requirement can be tracked to its origin

11 Credible source Comes from reliable, authorized sources

5.2 Functional & Non-Functional Requirements

Functional Requirements

Functional Requirements

23
Lecture 5Software Requirement Characteristics

Requirements related to the functional aspect of software. They define functions

and functionality within and from the software system.

Examples:
Search option given to user to search from various invoices
User should be able to mail any report to management
Users can be divided into groups and groups can be given separate rights
Should comply with business rules and administrative functions
Software is developed keeping downward compatibility intact

Non-Functional Requirements

Non-Functional Requirements
Requirements not related to functional aspect of software. They are implicit or
expected characteristics of software which users assume.

Non-functional requirements include:

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility

Logical Categorization of Requirements

Table 5.2: Requirement Priority Categories

Category Description Action

Must Have Software cannot be operational without them Must be implemented

24
Lecture 5Software Requirement Characteristics

Should Have Enhancing functionality of software Matter of debate/negotiation

Could Have Software can still properly function Can be kept for updates

Wish List Do not map to any objectives of software Can be kept for updates

5.3 User Interface (UI) Requirements

UI is an important part of any software system. A software is widely accepted if it is:

Easy to operate
Quick in response
Effectively handling operational errors
Providing simple yet consistent user interface
User interface requirements include:
Content presentation - Clear display of information
Easy Navigation - Simple movement between features
Simple interface - Not overly complex
Responsive - Quick reaction to user actions
Consistent UI elements - Uniform design throughout
Feedback mechanism - Informing users of action results
Default settings - Sensible pre-configured options
Purposeful layout - Logical arrangement of elements
Strategic use of color and texture
Provide help information
User centric approach
Group based view settings

5.4 System Analyst & Software Metrics

System Analyst

System Analyst

25
Lecture 5Software Requirement Characteristics

A person who analyzes the requirement of the proposed system and ensures that
requirements are conceived and documented properly and correctly. The role starts
during the Software Analysis Phase of SDLC.

Responsibilities of a System Analyst:

Analyzing and understanding requirements of intended software
Understanding how the project will contribute to the organization's objectives
Identifying sources of requirements
Validation of requirements
Developing and implementing requirement management plan
Documentation of business, technical, process, and product requirements
Coordination with clients to prioritize requirements and remove ambiguity
Finalizing acceptance criteria with client and other stakeholders

Software Metrics and Measures

Software Measures
A process of quantifying and symbolizing various attributes and aspects of
software.

Software Metrics
Provide measures for various aspects of software process and software product.
They help control the software development process and aid in keeping quality
excellent.

Table 5.3: Types of Software Metrics

Metric Type Description Examples

Size Metrics Measure of software LOC (Lines of Code), KLOC (thousands of lines),
size Function Point Count

Complexity Measure of program McCabe's Cyclomatic Complexity - quantifies

Metrics complexity independent paths using control flow graph

Quality Measure of product Defects, their types, causes, severity, implications;

Metrics quality defects found in development and reported by client

26
Lecture 5Software Requirement Characteristics

Process Measure of development Methods and tools used, company standards,

Metrics process performance of development

Resource Measure of resources Effort, time, and various resources

Metrics used

* * * * *

27
Lecture 6Software Design

Lecture 6

Software Design

Software Design
A process to transform user requirements into some suitable form, which helps
the programmer in software coding and implementation. It is the first step in SDLC
that moves the concentration from problem domain to solution domain.

6.1 Three Levels of Software Design

Level 1: Architectural Design

The architectural design is the highest abstract version of the system. It identifies the
software as a system with many components interacting with each other. At this level,
designers get the idea of the proposed solution domain.

Level 2: High-Level Design

High-level design breaks the "single entity-multiple component" concept of architectural
design into a less-abstracted view of sub-systems and modules and depicts their
interaction. It focuses on how the system along with all its components can be
implemented in forms of modules. It recognizes the modular structure of each sub-
system and their relations and interactions.

Level 3: Detailed Design

Detailed design deals with the implementation part of what is seen as a system and its
sub-systems. It is more detailed towards modules and their implementations. It defines
the logical structure of each module and their interfaces to communicate with other
modules.
Table 6.1: Three Levels of Software Design

Level Name Focus Output

1 Architectural System components and interactions Abstract system view

28
Lecture 6Software Design

2 High-Level Sub-systems, modules, and their relations Modular structure

3 Detailed Module implementation and interfaces Logical module structure

6.2 Modularization

Modularization
A technique to divide a software system into multiple discrete and independent
modules, which are expected to be capable of carrying out task(s) independently.
Modular design unintentionally follows the rules of "divide and conquer" problem-
solving strategy.

Advantages of Modularization
Smaller components are easier to maintain
Program can be divided based on functional aspects
Desired level of abstraction can be brought in the program
Components with high cohesion can be reused again
Concurrent execution can be made possible
Desired from security aspect

6.3 Concurrency

Back in time, all software was meant to be executed sequentially - coded instructions
executed one after another, implying only one portion of the program being activated at
any given time.

Concurrency
Implemented by splitting the software into multiple independent units of
execution (like modules) and executing them in parallel. Concurrency provides
capability to the software to execute more than one part of code in parallel to
each other.

29
Lecture 6Software Design

It is necessary for programmers and designers to recognize those modules which can
be made for parallel execution.
Example: The spell check feature in a word processor is a module that runs alongside
the word processor itself.

* * * * *

30
Lecture 7Coupling & Cohesion

Lecture 7

Coupling & Cohesion

When a software program is modularized, its tasks are divided into several modules.
Modules are a set of instructions put together to achieve some tasks. They are considered
as a single entity but may refer to each other to work together. Coupling and cohesion
are measures by which the quality of module design and their interaction can be
measured.

7.1 Cohesion - 7 Types

Cohesion
A measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.

Table 7.1: Seven Types of Cohesion (Worst to Best)

Rank Type Description

7 Co-incidental Unplanned and random cohesion; result of breaking program

(Worst) into smaller modules for modularization's sake. Causes
confusion to programmers and is generally not accepted.

6 Logical When logically categorized elements are put together into a

module.

5 Temporal When elements of a module are organized such that they are
processed at a similar point in time.

4 Procedural When elements of a module are grouped together which are

executed sequentially in order to perform a task.

3 Communicational When elements are grouped together which are executed

sequentially and work on the same data.

2 Sequential When elements are grouped because the output of one

element serves as input to another.

31
Lecture 7Coupling & Cohesion

1 Functional Highest degree of cohesion. Elements are grouped because they all
(Best) contribute to a single well-defined function. Can also be reused.

REMEMB ER
For cohesion: Higher is better. Functional cohesion (Rank 1) is the best type.

7.2 Coupling - 5 Levels

Coupling
A measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other.
The lower the coupling, the better the program.

Table 7.2: Five Levels of Coupling (Worst to Best)

Rank Type Description

5 Content When a module can directly access, modify, or refer to the contents
(Worst) of another module.

4 Common When multiple modules have read and write access to some global
data.

3 Control Two modules are control-coupled if one decides the function of the
other module or changes its flow of execution.

2 Stamp When multiple modules share a common data structure and work on
different parts of it.

1 (Best) Data When two modules interact by passing data as parameters. If a

module passes a data structure, the receiving module should use all its
components.

IDEAL GOAL
Ideally, no coupling is considered to be the best. For coupling: Lower is better.
Data coupling (Rank 1) is the best type.

Table 7.3: Cohesion vs. Coupling - Quick Comparison

Aspect Cohesion Coupling

32
Lecture 7Coupling & Cohesion

Measures Intra-dependability within a module Inter-dependability among modules

Better When Higher Lower

Best Type Functional (Rank 1) Data (Rank 1)

Worst Type Co-incidental (Rank 7) Content (Rank 5)

7.3 Design Verification

The output of the software design process includes:

Design documentation
Pseudo codes
Detailed logic diagrams
Process diagrams
Detailed description of all functional or non-functional requirements
The next phase (implementation) depends on all these outputs. It is necessary to verify
the output before proceeding. The earlier any mistake is detected, the better -
otherwise it might not be detected until testing.
If outputs are in formal notation form, their associated tools for verification should be
used; otherwise, a thorough design review can be used for verification and validation.

KEY STATEMENT
A good design review is important for good software design, accuracy, and
quality. By structured verification approach, reviewers can detect defects that might
be caused by overlooking some conditions.

* * * * *

33
Lecture 8Software Analysis & Design Tools - DFD

Lecture 8

Software Analysis & Design Tools - DFD

Software analysis and design includes all activities that help the transformation of
requirement specification into implementation. Requirement specifications specify all
functional and non-functional expectations in human-readable documents. Software
analysis and design is the intermediate stage that helps transform human-readable
requirements into actual code.

8.1 Data Flow Diagram (DFD)

Data Flow Diagram

A graphical representation of data flow in an information system. It is capable of
depicting incoming data flow, outgoing data flow, and stored data. The DFD does not
mention how data flows through the system.

DFD vs. Flowchart

CRITICAL DIFFERENCE
There is a prominent difference between DFD and Flowchart:
Flowchart depicts flow of control in program modules
DFD depicts flow of data in the system at various levels
DFD does not contain any control or branch elements

Types of DFD
Table 8.1: Types of Data Flow Diagrams

Type Focus Example

Logical Concentrates on system process and In Banking software, how data is

DFD flow of data in the system moved between different entities

34
Lecture 8Software Analysis & Design Tools - DFD

Physical Shows how data flow is actually More specific and close to
DFD implemented in the system implementation

DFD Components (4 Components)

Table 8.2: DFD Components

Component Symbol Description

Entities Rectangle Source and destination of information data.

Represented by rectangles with their respective names.

Process Circle or Rounded- Activities and actions taken on the data.

edged rectangle

Data Open-sided rectangle Can be represented as a rectangle with absence of both

Storage smaller sides or with only one side missing.

Data Flow Pointed arrows Movement of data shown from base of arrow (source)
towards head of arrow (destination).

8.2 Levels of DFD

Level 0 (Context Level DFD)

The highest abstraction level DFD known as Level 0 DFD, which depicts the entire
information system as one diagram, concealing all underlying details. Also known as
Context Level DFDs.

Level 1 DFD
The Level 0 DFD is broken down into more specific Level 1 DFD. It depicts basic
modules in the system and flow of data among various modules. Level 1 DFD also
mentions basic processes and sources of information.

Level 2 DFD
At this level, DFD shows how data flows inside the modules mentioned in Level 1.

NOTE

35
Lecture 8Software Analysis & Design Tools - DFD

Higher level DFDs can be transformed into more specific lower level DFDs with a
deeper level of understanding until the desired level of specification is achieved.

* * * * *

36
Lecture 9Structure Charts & Structured English

Lecture 9

Structure Charts & Structured English

9.1 Structure Chart

Structure Chart
A chart derived from Data Flow Diagram. It represents the system in more detail
than DFD. It breaks down the entire system into lowest functional modules,
describes functions and sub-functions of each module to a greater detail than DFD. It
represents the hierarchical structure of modules.

Structure Chart Symbols (6 Symbols)

Table 9.1: Structure Chart Symbols

Symbol Representation Description

Module Rectangle Represents process, subroutine, or task. A control module

branches to more than one sub-module. Library modules
are reusable and invokable from any module.

Condition Small diamond Shown at the base of a module. Depicts that the control
module can select any sub-routine based on some
condition.

Jump Arrow pointing Depicts that control will jump in the middle of the sub-
inside module module.

Loop Curved arrow Represents loop in the module. All sub-modules covered
by the loop repeat execution.

Data Flow Directed arrow with Represents data flow between modules.
empty circle

Control Directed arrow with Represents control flow between modules.

Flow filled circle

9.2 Structured English

37
Lecture 9Structure Charts & Structured English

Structured English
A method that uses plain English words in structured programming paradigm. It
is not the ultimate code but a kind of description of what is required to code and how
to code it. Structured English is independent of programming language.

Key tokens of structured programming used in Structured English:

IF-THEN-ELSE
DO-WHILE-UNTIL
Analysts use the same variable and data names stored in the Data Dictionary, making it
simpler to write and understand.

Example: Customer Authentication in Online Shopping

Structured English Example - Customer Authentication

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

KEY POINTS AB OUT STRUCTURED ENGLISH

The code is more like day-to-day spoken English

It cannot be implemented directly as software code
It is independent of programming language
Helps mitigate understanding gaps between analysts and programmers

9.3 Pseudo-Code

Pseudo-Code
Written more close to programming language. Considered as augmented
programming language, full of comments and descriptions. Avoids variable

38
Lecture 9Structure Charts & Structured English

declaration but uses actual programming language constructs (C, Fortran, Pascal,
etc.).

Pseudo-code contains more programming details than Structured English. It provides

a method to perform the task, as if a computer is executing the code.

Example: Fibonacci Series

Pseudo-Code Example - Fibonacci Series

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
print b;
}
else if b greater than a
{
increase a by b;
print a;
}
}

Table 9.2: Structured English vs. Pseudo-Code

Aspect Structured English Pseudo-Code

Language Plain English words Programming language

constructs

Detail Level Less detailed More programming details

Implementability Cannot be directly implemented Closer to actual implementation

Purpose Description of what and how to Method to perform the task

code

Variable Names Uses Data Dictionary names Avoids variable declarations

39
Lecture 9Structure Charts & Structured English

* * * * *

40
Lecture 10Decision Table, ER Model, Data Dictionary

Lecture 10

Decision Table, ER Model, Data

Dictionary

10.1 Decision Tables

Decision Table
A Decision Table represents conditions and the respective actions to be taken to
address them, in a structured tabular format. It is a powerful tool to debug and
prevent errors.

Creating a Decision Table - Four Steps

1. Identify all possible conditions to be addressed
2. Determine actions for all identified conditions
3. Create maximum possible rules
4. Define action for each rule
Decision tables should be verified by end-users and can be simplified by eliminating
duplicate rules and actions.

Example: Internet Connectivity Troubleshooting

Table 10.1: Decision Table - Internet Troubleshooting (Conditions)

Conditions/Actions R1 R2 R3 R4 R5 R6 R7 R8

Shows Connected N N N N Y Y Y Y

Ping Working N N Y Y N N Y Y

Opens Website N Y N Y N Y N Y

Table 10.2: Decision Table - Internet Troubleshooting (Actions)

Actions R1 R2 R3 R4 R5 R6 R7 R8

41
Lecture 10Decision Table, ER Model, Data Dictionary

Check network cable X

Check internet router X X

Restart Web Browser X

Contact Service provider X X X X

10.2 Entity-Relationship (ER) Model

Entity-Relationship Model
A type of database model based on the notion of real world entities and
relationships among them. ER Model creates a set of entities with their attributes, a
set of constraints, and relations among them. It is best used for the conceptual
design of database.

Entity
An entity in ER Model is a real world being which has some properties called
attributes. Every attribute is defined by its corresponding set of values called domain.
Example: In a school database, a Student is an entity. Student has various attributes like
name, id, age, and class.

Relationship
The logical association among entities is called a relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of
associations between two entities:
One to One
One to Many
Many to One
Many to Many

10.3 Data Dictionary

42
Lecture 10Decision Table, ER Model, Data Dictionary

Data Dictionary
The centralized collection of information about data. It stores meaning and
origin of data, its relationship with other data, data format for usage, etc. Data
dictionary has rigorous definitions of all names to facilitate users and software
designers. Often referenced as meta-data (data about data) repository.

Requirement of Data Dictionary

Data is referenced via data dictionary while designing and implementing software
Removes any chances of ambiguity
Helps keep work of programmers and designers synchronized while using same
object reference
Provides a way of documentation for the complete database system in one place
Validation of DFD is carried out using data dictionary

Contents of Data Dictionary

Data dictionary should contain information about:
Data Flow
Data Structure
Data Elements
Data Stores
Data Processing

Data Dictionary Algebraic Notation

Table 10.3: Data Dictionary Notation Symbols

Symbol Meaning

= Composed of

{} Repetition

() Optional

+ And

[/] Or

43
Lecture 10Decision Table, ER Model, Data Dictionary

Example

Data Dictionary Example

Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level + Course Grades

Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal
or External data stores with the following details:
Primary Name
Secondary Name (Alias)
Use-case - How and where to use
Content Description - Notation etc.
Supplementary Information - Preset values, constraints etc.

Data Store
Stores information about where data enters into the system and exits out of the system.
May include:
Files - Internal to software; External to software but on same machine; External to
software and system on different machine
Tables - Naming convention; Indexing property

Data Processing
Two types of Data Processing:
Logical: As user sees it
Physical: As software sees it

* * * * *

44
Quick Reference Tables

Quick Reference Tables

SDLC 11 Stages - Memorization Aid

Table R.1: SDLC Stages in Sequence

# Stage Key Activity

1 Communication User initiates request

2 Requirement Gathering Collect from stakeholders

3 Feasibility Study Check if project is viable

4 System Analysis Roadmap and planning

5 Software Design Logical and physical design

6 Coding Write program code

7 Testing Verify and validate

8 Integration Combine with libraries/DB

9 Implementation Install on user machines

10 Operation & Maintenance Updates and support

11 Disposition Archive and terminate

Cohesion & Coupling Summary

Table R.2: Cohesion Types (Worst 7 to Best 1)

Rank Type Key Characteristic

7 Co-incidental Unplanned, random

6 Logical Logically categorized

5 Temporal Processed at same time

4 Procedural Executed sequentially

3 Communicational Same data, sequential

45
Quick Reference Tables

2 Sequential Output to input chain

1 Functional Single well-defined function

Table R.3: Coupling Types (Worst 5 to Best 1)

Rank Type Key Characteristic

5 Content Direct access to another module

4 Common Multiple modules access global data

3 Control One module controls another

2 Stamp Share data structure, different parts

1 Data Pass data as parameters

Key Definitions at a Glance

Table R.4: Essential Definitions for Examination

Term Definition

Software Collection of executable code, associated libraries, and

documentation

Software Engineering Systematic, disciplined, quantifiable approach to development,

(IEEE) operation, and maintenance of software

Software Product Software made for a specific requirement

SDLC Software Development Life Cycle - structured sequence of stages

SRS Software Requirement Specification - document after requirements

collection

Modularization Dividing software into discrete, independent modules

Cohesion Intra-dependability within elements of a module (higher is better)

Coupling Inter-dependability among modules (lower is better)

Data Dictionary Centralized collection of information about data (metadata

repository)

DFD Data Flow Diagram - graphical representation of data flow

Prototype Toy implementation of the system with shortcuts

46
References

References

Bibliography

1. Rajib Mall, Fundamentals of Software Engineering, Prentice-Hall of India.

Webliography

1. [Link]

--- End of Lecture Notes ---

Veer Surendra Sai University of Technology, Burla - 768018

47