1|Page

CSC 4219
(SPECIAL TOPICS IN SOFTWARE ENGINEERING)

COURSE OUTLINE

- Software Re engineering and Software Configuration Management

- Software Cost Estimate
- Software Architecture
- Software Reuse and Open Source Development
- Introduction to software as a Service

MATHEMATICAL SCIENCE DEPARTMENT

BAUCHI STATE UNIVERSITY GADAU

©2023
2|Page

Software engineering is an engineering branch associated with development of software

product using well-defined scientific principles, methods and procedures. The outcome of
software engineering is an efficient and reliable software product.

DEFINITIONS

IEEE defines software engineering as:

(1) The application of a systematic, disciplined, quantifiable approach to the development,

operation, and maintenance of software; that is, the application of engineering to software.

(2) The study of approaches as in the above statement. Fritz Bauer, a German computer
scientist, defines software engineering as: “Software engineering is the establishment and use
of sound engineering principles in order to obtain economically software that is reliable and
work efficiently on real machines.
3|Page

Software Evolution

The process of developing a software product using software engineering principles and
methods is referred to as Software Evolution. This includes the initial development of software
and its maintenance and updates, till desired software product is developed, which satisfies
the expected requirements.

Evolution starts from the requirement gathering process. After which developers create a
prototype of the intended software and show it to the users to get their feedback at the early
stage of the software product development. The users suggest changes, on which several
consecutive updates and maintenance keep on changing too. This process changes to the
original software, till the desired software is accomplished. Even after the user has the desired
software in hand, the advancing technology and the changing requirements force the software
product to change accordingly. Re-creating software from scratch and to go one-on-one with
the requirement is not feasible. The only feasible and economical solution is to update the
existing software so that it matches the latest requirements.
Software Evolution Laws
Lehman has given laws for software evolution. He divided the software into three different
categories:

1. Static-type (S-type) - This is software, which works strictly according to defined

specifications and solutions. The solution and the method to achieve it, both are
immediately understood before coding. The s-type software is least subjected to
changes hence this is the simplest of all. For example, calculator program for
mathematical computation.
4|Page

2. Practical-type (P-type) - This is software with a collection of procedures.

This is defined by exactly what procedures can do. In this software, the specifications can be
described but the solution is not obviously instant. For example, gaming software.
3. Embedded-type (E-type) - This software works closely as the requirement of real-world
environment. This software has a high degree of evolution as there are various changes in
laws, taxes etc. in the real world situations. For example, Online trading software.
E-Type software evolution

Lehman has given eight laws for E-Type software evolution –

1. Continuing Change - An E-type software system must continue to adapt to the real world
changes, else it becomes progressively less useful.

2. Increasing Complexity - As an E-type software system evolves, its complexity tends to

increase unless work is done to maintain or reduce it.

3. Conservation of familiarity - The familiarity with the software or the knowledge about how
it was developed, why was it developed in that particular manner etc., must be retained at any
cost, to implement the changes in the system. 4. Continuing growth- In order for an E-type
system intended to resolve some business problem, its size of implementing the changes
grows according to the lifestyle changes of the business.

5. Reducing quality - An E-type software system declines in quality unless rigorously

maintained and adapted to a changing operational environment.

6. Feedback systems- The E-type software systems constitute multi-loop, multi-level feedback
systems and must be treated as such to be successfully modified or improved. 7. Self-
regulation - E-type system evolution processes are self-regulating with the distribution of
product and process measures close to normal.
8. Organizational stability - The average effective global activity rate in an evolving E-type
system is invariant over the lifetime of the product.
Need of Software Engineering
The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working. Following are some of the
needs stated:
5|Page

 Large software- It is easier to build a wall than a house or building, likewise, as the size of
the software becomes large, engineering has to step to give it a scientific process.
 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 hardware industry has shown its skills and huge manufacturing has lower down the
price of computer and electronic hardware. But, cost of the software remains high if proper
process is not adapted.
 Dynamic Nature- Always growing and adapting nature of the software hugely depends upon
the environment in which the user works. If the nature of software is always changing, new
enhancements need to be done in the existing one. This is where the software engineering
plays a good role.
 Quality Management- Better process of software development provides better and quality
software product

Characteristics of good software

A software product can be judged by what it offers and how well it can be used. This software must
satisfy on the following grounds:
 Operational

 Transitional

 Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational

This tells us how well the software works in operations. It can be measured on:

 Budget  Functionality

 Usability  Dependability

 Efficiency  Security

 Correctness  Safety
6|Page

Transitional

This aspect is important when the software is moved from one platform to another:

 Portability  Reusability

 Interoperability  Adaptability

Maintenance

This aspect briefs about how well the software has the capabilities to maintain itself in the ever-
changing environment:

 Modularity  Flexibility

 Maintainability  Scalability

In short, 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.

Software Project Management

The job pattern of an IT company engaged in software development can be seen split in two
parts:
 Software Creation
 Software Project Management

A project is well-defined task, which is a collection of several operations done in order to

achieve a goal (for example, software development and delivery). A Project can be
characterized as:
 Every project may have a unique and distinct goal.
 Project is not a routine activity or day-to-day operation.
 Project comes with a start and end time.
 Project ends when its goal is achieved. Hence, it is a temporary phase in the lifetime of an
organization.
 Project needs adequate resources in terms of time, manpower, finance, material, and
knowledge-bank.
7|Page

Software Project
A Software Project is the complete procedure of software development from requirement
gathering to testing and maintenance, carried out according to the execution methodologies,
in a specified period of time to achieve intended software product.

Need of Software Project Management

Software is said to be an intangible product. Software development is a kind of all new stream
in world business and there is very little experience in building software products. Most
software products are tailor made to fit client’s requirements. The most important is that the
underlying technology changes and advances so frequently and rapidly that the experience of
one product may not be applied to the other one. All such business and environmental
constraints bring risk in software development hence it is essential to manage software
projects efficiently.

The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget
constrain and deliver the project as per scheduled. There are several factors, both internal and
external, which may impact this triple constrain triangle. Any of the three factors can severely
impact the other two. Therefore, software project management is essential to incorporate
user requirements along with budget and time constraints.
Software Project Manager
A software project manager is a person who undertakes the responsibility of executing the
software project. Software project manager is thoroughly aware of all the phases of SDLC that
the software would go through. The project manager may never directly involve in producing
the end product but he controls and manages the activities involved in production. A project
8|Page

manager closely monitors the development process, prepares and executes various plans,
arranges necessary and adequate resources, maintains communication among all team
members in order to address issues of cost, budget, resources, time, quality and customer
satisfaction.
Let us see few responsibilities that a project manager shoulders –

Managing People
 Act as project leader
 Lesion with stakeholders
 Managing human resources
 Setting up reporting hierarchy etc

Managing Project
 Defining and setting up project scope
 Managing project management activities
 Monitoring progress and performance
 Risk analysis at every phase
 Take necessary step to avoid or come out of problems
 Act as project spokesperson

Software Management Activities

Software project management comprises of a number of activities, which contains planning of
project, deciding scope of software product, estimation of cost in various terms, scheduling of
tasks and events, and resource management.
Project management activities may include:
 Project Planning
 Scope Management
 Project Estimation
Project Planning Software project planning is task, which is performed before the production
of software actually starts. It is there for the software production but involves no concrete
activity that has any direct connection with the software production; rather it is a set of
multiple processes, which facilitates software production.
Project planning may include the following:
9|Page

Scope Management
It defines scope of the project; this includes all the activities, process need to be done in order
to make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what
would not be done. This makes project to contain limited and quantifiable tasks, which can
easily be documented and in turn avoids cost and time overrun.
During Project Scope management, it is necessary to –
 Define the scope
 Decide its verification and control
 Divide the project into various smaller parts for ease of management
 Verify the scope
 Control the scope by incorporating changes to the scope
Project Estimation
For an effective management, accurate estimation of various measures is a must. With the
correct estimation, managers can manage and control the project more efficiently and
effectively. Project estimation may involve the following:
 Software size estimation
Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating
number of function points in the software. Lines of code depend upon coding practices.
Function points vary according to the user or software requirement.
 Effort estimation
The manager estimates efforts in terms of personnel requirement and man-hour required to
produce the software. For effort estimation software size should be known. This can either be
derived by manager’s experience, historical data of organization, or software size can be
converted into efforts by using some standard formulae.
 Time estimation
once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required are segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks are
divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The
tasks are scheduled on day-to-day basis or in calendar months.
10 | P a g e

The sum of time required to complete all tasks in hours or days is the total time invested to
complete the project.
 Cost estimation
This might be considered as the most difficult of all because it depends on more elements
than any of the previous ones. For estimating project cost, it is required to consider –
 Size of the software  Travel involved
 Software quality  Communication
 Hardware  Training and support
 Additional software or tools, licenses etc.  Skilled personnel with task-specific skills

Project Estimation Techniques

We discussed various parameters involving project estimation such as size, effort, time and
cost. Project manager can estimate the listed factors using two broadly recognized
techniques:-
Decomposition Technique
This technique assumes the software as a product of various compositions. There are two
main models –
 Line of Code: Here the estimation is done on behalf of number of line of codes in the
software product.
 Function Points: Here the estimation is done on behalf of number of function points in the
software product.
Empirical Estimation Technique
This technique uses empirically derived formulae to make estimation. These formulae are
based on LOC or FPs.
 Putnam Model
This model is made by Lawrence H. Putnam, which is based on Norden’s frequency
distribution (Rayleigh curve). Putnam model maps time and efforts required with software
size.
 COCOM
COCOMO stands for Constructive Cost Model, developed by Barry W. Boehm. It divides the
software product into three categories of software: organic, semi-detached, and embedded.
11 | P a g e

Configuration Management
Configuration management is a process of tracking and controlling the changes in software in
terms of the requirements, design, functions and development of the product.
IEEE defines it as “the process of identifying and defining the items in the system, controlling
the change of these items throughout their life cycle, recording and reporting the status of
items and change requests, and verifying the completeness and correctness of items”.
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as
there is a possibility of cost and time overrun.
Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines
completeness of a phase. A phase is baselined when all activities pertaining to it are finished
and well documented. If it was not the final phase, its output would be used in next
immediate phase. Configuration management is a discipline of organization administration,
which takes care of occurrence of any changes (process, requirement, technological,
strategical etc.) after a phase is baselined. CM keeps check on any changes done in software.
Change Control
Change control is function of configuration management, which ensures that all changes made
to software system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps –
 Identification - A change request arrives from either internal or external source. When
change request is identified formally, it is properly documented.
 Validation - Validity of the change request is checked and its handling procedure is
confirmed.
 Analysis - The impact of change request is analyzed in terms of schedule, cost and required
efforts. Overall impact of the prospective change on system is analyzed.
 Control - If the prospective change either impacts too many entities in the system or it is
unavoidable, it is mandatory to take approval of high authorities before change is
incorporated into the system. It is decided if the change is worth incorporation or not. If it is
not, change request is refused formally.
12 | P a g e

 Execution - If the previous phase determines to execute the change request, this phase takes
appropriate actions to execute the change, through a thorough revision if necessary.
 Close request - The change is verified for correct implementation and merging with the rest
of the system. This newly incorporated change in the software is documented properly and
the request is formally closed.

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
client’s point of view.
Requirement Engineering
The process to gather the software requirements from client, analyze, and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.
Requirement Engineering Process
It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
Let us see the process briefly –
Feasibility study
When the client approaches the organization for getting the desired product developed, it
comes up with a rough idea about what all functions the software must perform and which all
features are expected from the software. Referencing to this information, the analysts do a
detailed study about whether the desired system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes whether
13 | P a g e

the software product can be practically materialized in terms of implementation, contribution

of project to organization, cost constraints, and as per values and objectives of the
organization. It explores technical aspects of the project and product such as usability,
maintainability, productivity, and integration ability. The output of this phase should be a
feasibility study report that should contain adequate comments and recommendations for
management about whether or not the project should be undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, 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 the software to include.
Software Requirement Specification (SRS)
SRS is a document created by 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 of system, portability of software
across various platforms, maintainability, speed of recovery after crashing, Security, Quality,
Limitations etc. The requirements received from client are written in natural language. It is the
responsibility of the system analyst to document the requirements in technical language so
that they can be comprehended and used by the software development team.
SRS should come up with the following features:
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements inaccurately. This results in huge increase in cost if not nipped in
the bud. Requirements can be checked against following conditions –
14 | P a g e

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Requirement Elicitation Process
Requirement elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and end users and know
their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the requirements in order
of importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, it is then negotiated and discussed with the
stakeholders. Requirements may then be prioritized and reasonably compromised. The
requirements come from various stakeholders. To remove the ambiguity and conflicts, they
are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.
 Documentation - All formal and informal, functional and non-functional requirements are
documented and made available for next phase processing.
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users, and others who have a stake in
the software system development. There are various ways to discover requirements. Some of
them are explained below:
1. Interviews
Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:
15 | P a g e

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.
2. Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
3. Questionnaires
A document with pre-defined set of objective questions and respective options is handed over
to all stakeholders to answer, which are collected and compiled. A shortcoming of this
technique is, if an option for some issue is not mentioned in the questionnaire, the issue might
be left unattended.
4. Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied
and requirements of proposed system are collected.
5. Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.
6. Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
7. Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. It helps giving better idea of requirements. If there
is no software installed at client’s end for developer’s reference and the client is not aware of
its own requirements, the developer creates a prototype based on initially mentioned
16 | P a g e

requirements. The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.
8. Observation
Teams of experts visit the client’s organization or workplace. They observe the actual working
of the existing installed systems. They observe the workflow at the client’s end and how
execution problems are dealt. The team itself draws some conclusions which aid to form
requirements expected from the software.
Software Requirements Characteristics
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:
 Clear  Modifiable
 Correct  Verifiable
 Consistent  Prioritized
 Coherent  Unambiguous
 Comprehensible  Traceable
 Credible source
Software Requirements We should try to understand what sort of requirements may arise in
the requirement elicitation phase and what kinds of requirement are expected from the
software system.
Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this category. 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 business rules and administrative functions.
 Software is developed keeping downward compatibility intact.
17 | P a g e

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this category.
They are implicit or expected characteristics of software, which users make assumption of.
Non-functional requirements include –
 Security  Cost
 Logging  Interoperability
 Storage  Flexibility
 Configuration  Disaster recovery
 Performance  Accessibility
Requirements are categorized logically as:
 Must Have: Software cannot be said operational without them.
 Should have: Enhancing the functionality of software.
 Could have: Software can still properly function with these requirements.
 Wish list : These requirements do not map to any objectives of software.
While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of
debate with stakeholders and negation, whereas ‘Could have’ and ‘Wish list’ can be kept for
software updates.

User Interface requirements

User Interface (UI) is an important part of any software or hardware or hybrid 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 acceptance majorly depends upon how user can use the software. UI is the only way for
users to perceive the system. A well performing software system must also be equipped with
attractive, clear, consistent, and responsive user interface. Otherwise the functionalities of
software system cannot be used in convenient way. A system is said to be good if it provides
means to use it efficiently. User interface requirements are briefly mentioned below –
 Content presentation  Default settings
 Easy Navigation  Feedback mechanism
18 | P a g e

 Simple interface  Purposeful layout

 Responsive  Consistent UI elements
 Strategical use of color and texture.  Provide help information
 User centric approach  Group based view settings.

Software Metrics and Measures

Software Measures can be understood as 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.
Software measures are fundamental requirements of software engineering. They not only
help to control the software development process but also aid to keep the quality of ultimate
product excellent.
According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot
measure.” By his saying, it is very clear how important software measures are.
Let us see some software metrics:
 Size Metrics - Lines of Code (LOC) (), mostly calculated in thousands of delivered source code
lines, denoted as KLOC.
 Function Point Count is measure of the functionality provided by the software. Function
Point count defines the size of functional aspect of the software.
 Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the
number of independent paths in a program, which is perceived as complexity of the program
or its modules. It is represented in terms of graph theory concepts by using control flow graph.
 Quality Metrics - Defects, their types and causes, consequence, intensity of severity and
their implications define the quality of the product.
 The number of defects found in development process and number of defects reported by
the client after the product is installed or delivered at client end, define quality of the
product.
 Process Metrics - In various phases of SDLC, the methods and tools used, the company
standards and the performance of development are software process metrics.
 Resource Metrics - Effort, time, and various resources used, represents metrics for resource
measurement.
19 | P a g e

Introduction to Software as a Service

SaaS is also known as "On-Demand Software". It is a software distribution model in which
services are hosted by a cloud service provider. These services are available to end-users over
the internet so, the end-users do not need to install any software on their devices to access these
services. There are the following services provided by SaaS providers -
Business Services - SaaS Provider provides various business services to start-up the business.
The SaaS business services include ERP (Enterprise Resource Planning), CRM (Customer
Relationship Management), billing, and sales.
Document Management - SaaS document management is a software application offered by a
third party (SaaS providers) to create, manage, and track electronic documents.
Example: Slack, Samepage, Box, and Zoho Forms.
Social Networks - As we all know, social networking sites are used by the general public, so
social networking service providers use SaaS for their convenience and handle the general
public's information.
Mail Services - To handle the unpredictable number of users and load on e-mail services, many
e-mail providers offering their services using SaaS.

Advantages of SaaS
1) SaaS is easy to buy
SaaS pricing is based on a monthly fee or annual fee subscription, so it allows organizations to
access business functionality at a low cost, which is less than licensed applications.
Unlike traditional software, which is sold as a licensed based with an up-front cost (and often
an optional ongoing support fee), SaaS providers are generally pricing the applications using a
subscription fee, most commonly a monthly or annually fee.
2. One to Many
SaaS services are offered as a one-to-many model means a single instance of the application is
shared by multiple users.
20 | P a g e

3. Less hardware required for SaaS

The software is hosted remotely, so organizations do not need to invest in additional hardware.
4. Low maintenance required for SaaS
Software as a service removes the need for installation, set-up, and daily maintenance for the
organizations. The initial set-up cost for SaaS is typically less than the enterprise software. SaaS
vendors are pricing their applications based on some usage parameters, such as a number of
users using the application. So SaaS does easy to monitor and automatic updates.
5. No special software or hardware versions required
All users will have the same version of the software and typically access it through the web
browser. SaaS reduces IT support costs by outsourcing hardware and software maintenance and
support to the IaaS provider.
6. Multi device support
SaaS services can be accessed from any device such as desktops, laptops, tablets, phones, and
thin clients.
7. API Integration
SaaS services easily integrate with other software or services through standard APIs.
8. No client-side installation
SaaS services are accessed directly from the service provider using the internet connection, so
do not need to require any software installation.
Disadvantages of SaaS
1) Security
Actually, data is stored in the cloud, so security may be an issue for some users. However,
cloud computing is not more secure than in-house deployment.
2) Latency issue
Since data and applications are stored in the cloud at a variable distance from the end-user,
there is a possibility that there may be greater latency when interacting with the application
compared to local deployment. Therefore, the SaaS model is not suitable for applications whose
demand response time is in milliseconds.
3) Total Dependency on Internet
Without an internet connection, most SaaS applications are not usable.
4) Switching between SaaS vendors is difficult
Switching SaaS vendors involves the difficult and slow task of transferring the very large data
files over the internet and then converting and importing them into another SaaS also.
21 | P a g e

Popular SaaS Providers

Software analysis and design includes all activities, which help the transformation of
requirement specification into implementation. Requirement specifications specify all
functional and non-functional expectations from the software. These requirement
specifications come in the shape of human readable and understandable documents, to which
a computer has nothing to do. Software analysis and design is the intermediate stage, which
helps human readable requirements to be transformed into actual code.
Let us see few analysis and design tools used by software designers:
Data Flow Diagram
Data Flow Diagram (DFD) is a graphical representation of flow of data in an information
system. It is capable of depicting incoming data flow, outgoing data flow, and stored data. The
DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. It does
not contain any control or branch elements.
22 | P a g e

Types of DFD
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system. For example in a banking software system, how data is moved between different
entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.

DFD Components
DFD can represent source, destination, storage, and flow of data using the following set of
components –


Entities - Entities are sources and destinations of information data. Entities are represented by
rectangles with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one side
missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from
the base of arrow as its source towards head of the arrow as destination.
Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are also
known as context level DFDs.
23 | P a g e

 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD
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 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1. Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.
Structure Charts
Structure chart is 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 of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.
Here are the symbols used in construction of structure charts –
24 | P a g e

 Module - It represents process or subroutine or task. A control module branches to more

than one sub-module. Library Modules are re-usable and invokable from any module.