Information

Systems
Session 14-15 | System Analysis & Design with DFD
Structured Methodologies (1 of 2)
• Structured: Techniques are step-by-step, progressive
• Process-oriented: Focusing on modeling processes or actions that
manipulate data
• Separate data from processes
• Data flow diagram (DFD)
• Represents system’s component processes and flow of data between them
• Logical graphic model of information flow
Structured Methodologies (2 of 2)
• Data dictionary
• Defines contents of data flows and data stores
• Process specifications
• Describe transformation occurring within lowest level of data flow diagrams
• Structure chart
• Top-down chart, showing each level of design, relationship to other levels,
and place in overall design structure
Object-Oriented Development (1 of 2)
• Object
• Basic unit of systems analysis and design
• Combines data and the processes that operate on those data
• Data in object can be accessed only by operations associated with that object
• Object-oriented modeling
• Based on concepts of class and inheritance
• Objects belong to a certain class and have features of that class
• May inherit structures and behaviors of a more general, ancestor class
Class and Inheritance
Object-Oriented Development (2 of 2)
• More iterative and incremental than traditional structured
development
• Systems analysis: Interactions between system and users analyzed to identify
objects
• Design phase: Describes how objects will behave and interact; grouped into
classes, subclasses, and hierarchies
• Implementation: Some classes may be reused from existing library of classes,
others created or inherited
• Objects are reusable
• Object-oriented development can potentially reduce time and cost of
development
Computer-Aided Software Engineering
• Software tools to automate development and reduce repetitive work,
including:
• Graphics facilities for producing charts and diagrams
• Screen and report generators, reporting facilities
• Analysis and checking tools
• Data dictionaries
• Code and documentation generators
• Support iterative design by automating revisions and changes and
providing prototyping facilities
• Require organizational discipline to be used effectively
Traditional Systems Life Cycle
• Oldest method for building information systems
• Phased approach
• Development divided into formal stages
• “Waterfall” approach: One stage finishes before next stage begins
• Formal division of labor between end users and information systems
specialists
• Emphasizes formal specifications and paperwork
• Still used for building large complex systems
• Can be costly, time-consuming, and inflexible
The Traditional Systems Development Life
Cycle
Prototyping (1 of 2)
• Building experimental system rapidly and inexpensively for end users
to evaluate
• Prototype: Working but preliminary version of information system
• Approved prototype serves as template for final system
• Steps in prototyping
• Identify user requirements
• Develop initial prototype
• Use prototype
• Revise and enhance prototype
The Prototyping Process
Prototyping (2 of 2)
• Advantages of prototyping
• Useful if some uncertainty in requirements or design solutions
• Often used for end-user interface design
• More likely to fulfill end-user requirements
• Disadvantages
• May gloss over essential steps
• May not accommodate large quantities of data or large number of users
• May not undergo full testing or documentation
End-User Development (1 of 2)
• Allows end users to develop simple information systems with little or
no help from technical specialists
• Reduces time and steps required to produce finished application
• Tools include
• User friendly query languages and reporting
• PC software tools
End-User Development (2 of 2)
• Advantages
• More rapid completion of projects
• High level of user involvement and satisfaction
• Disadvantages
• Not designed for processing-intensive applications
• Inadequate management and control, testing, documentation
• Loss of control over data
• Managing end-user development
• Require cost-justification of end-user system projects
• Establish hardware, software, and quality standards
Application Software Packages and Cloud
Software Services
• Application software packages and cloud software services
• Save time and money
• Many packages offer customization features
• Evaluation criteria for systems analysis include:
• Functions provided, flexibility, user friendliness, required resources, database requirements,
installation and maintenance efforts, documentation, vendor quality, and cost
• Request for Proposal (RFP)
• Detailed list of questions submitted to packaged-software vendors
• Used to evaluate alternative software packages
Outsourcing (1 of 2)
• Several types
• Cloud and SaaS providers
• Subscribing companies use software and computer hardware provided by
vendors
• External vendors
• Hired to design, create software
• Domestic outsourcing
• Driven by firm’s need for additional skills, resources, assets
• Offshore outsourcing
• Driven by cost-savings
Outsourcing (2 of 2)
• Advantages
• Allows organization flexibility in IT needs
• Disadvantages
• Hidden costs, for example:
• Identifying and selecting vendor
• Transitioning to vendor
• Opening up proprietary business processes to third party
Total Cost of Offshore Outsourcing
Rapid Application Development (RAD), Agile
Development, and DevOps
• Rapid application development (RAD)
• Process of creating workable systems in a very short period of time
• Joint application design (JAD)
• Used to accelerate generation of information requirements and to develop initial systems
design
• Agile development
• Focuses on rapid delivery of working software by breaking large project into several small
subprojects
• DevOps
• Builds on Agile development principles as an organizational strategy
Component-Based Development and Web
Services
• Component-based development
• Groups of objects that provide software for common functions (e.g., online
ordering) and can be combined to create large-scale business applications
• Web services
• Reusable software components that use XML and open Internet standards
(platform independent)
• Enable applications to communicate with no custom programming required
to share data and services
• Can engage other web services for more complex transactions
Mobile Application Development
• Mobile websites
• Mobile web apps
• Native apps
• Special requirements for mobile platform
• Smaller screens, keyboards, multitouch gestures, saving resources (memory,
processing)
• Responsive web design
• Websites programmed so that layouts change automatically according to
user’s computing device
Data Flow Diagrams (DFD)
• Data flow diagrams is a tool used to coherently represent the
information gathered as part of requirement analysis.

• DFD enable you to model how data flow through an information

system, the relationships among the data flows, and how data come
to be stored at specific locations.

• DFDs are considered as process models since the diagrams focus on

the movement of data between processes.
DFD : Process Modeling
• Process modeling involves graphically representing the functions, or
processes, that capture, manipulate, store, and distribute data
between a system and its environment and between components
within a system.

• It is shown as a hierarchy from top (high-level) to bottom (low-level).

DFD : Process Hierarchy
• The highest level DFD is called as context diagram.

• The purpose of context diagram is to show the scope of the system

indicating which elements are inside the scope of the system and
which elements are outside.

• The rationale for this process hierarchy is that process understanding

evolves from the general to more detailed.
 DFD Language Vocabulary* : PROCESS
• It is work or action performed on data so that it
gets transformed, stored or distributed.

• Upper portion is used to indicate the number of

the process (starting with 0).

• Lower portion contains the name of the process.

• It uses a verb phrase representing some action

taken (Receive, Calculate, Transform, etc.)
* as per the Gane & Sarson notations. Other notation is developed by Yourdon & Coad.
 DFD Language Vocabulary* : DATA STORE
• It is data at rest.
• It may be person (customer, supplier), concept
(order, invoice), object (customer receipt file).
• The left end is used to number the data store
(D1, D2…)

• Inside the main part of the rectangle is the label

for the data store.
• It uses a noun phrase.
* as per the Gane & Sarson notations
 DFD Language Vocabulary* : SOURCE/SINK
• It is the origin and/or destination of the data.

• They are referred as external entities since they

are outside the system and define the boundaries
of the system.

• Data must originate from one or more sources,

and the system must produce information to one
or more sinks.

• It uses a noun phrase.

* as per the Gane & Sarson notations
 DFD Language Vocabulary* : DATA FLOW

• The arrow with a label to highlight the data in

motion.

• It uses a noun phrase.

* as per the Gane & Sarson notations

Case Study
• Consider the process of ordering pizza from Dominos.
• The information system used by Dominos
i. Takes customer orders
ii. Sends the orders to the kitchen
iii. Monitors orders prepared and consumed and
iv. Tracks inventory for preparing MIS reports for Dominos
management.
Context Diagram (Level 0)
• One process, 3 source/sinks, 4 data flows and 0 data stores.
• The single process is labelled 0 and represents the entire system.
• All context diagrams have only one process, labelled 0.
• Data stores are never present in the context diagram since at this
highest level of process hierarchy, all data stores are present inside
the process.
Level 1
• The food ordering system (Context
Diagram) can be broken down into
4 processes flows:
1. Customer order gets transmitted
to the kitchen and comes back as
receipt to customer.
2. Customer order gets transmitted
into a list of menu items sold.
3. The customer order is
transformed into inventory data.
4. The goods and inventory process
generates reports for the
management.
Level 2 for Process 4
Level 3 for Process 4.3
Process Hierarchy
➢Context : Level 0

➢Level 1 : 1, 2, 3

➢Level 2 : {1.1, 1.2,1.3,..}, {2.1, 2.2, 2.3,2.4}, …

➢Level 3 : {1.2.1, 1.2.2, 1.2.3…} {2.4.1, 2.4.2} …

Functional Decomposition
• This process of starting with the entire system and then going into
sub-components is called as functional decomposition.

• This decomposition continues till you have reached a point at which

no sub-process can be logically broken down any further.
DFD Balancing
• When we are decomposing the DFD from one level to another, the
inputs and outputs to the process do not change from one level to
the next level.

• No new inputs or outputs are shown when we decompose the DFD.

• This is called balancing.

Example of Unbalanced DFD
Context Diagram Level 1 Diagram
Data Flow Balancing
• If a process gets decomposed, the data flows from higher to lower
level should also be named accordingly.

• No new data can be added during the decomposition and all the data
in the higher (composite) process must be accounted for in one or the
other sub-flows.
Higher level composite Lower level composite
data flow name data flow name
RULES : PROCESS

• No process can have output without input.

• No process can have input without output.

RULES : DATA STORE
• Data cannot move directly from one data store to another.

• It must be moved by a process.

RULES : DATA STORE
• Data cannot directly move from an outside source to a data store.

• It must be moved by a process that receives data from the source and
places the (processed) data into the data store.
RULES : DATA STORE
• Data cannot directly move from a data store to an outside sink.

• It must be moved by a process that receives data from the data

store and places the (processed) data into the outside sink.
RULES: SOURCE/SINK
• Data cannot move directly move from source to sink.

• It must be moved by a process if the data are of concern to our

system.
RULES : DATA FLOW
• A data flow cannot be shown bidirectional.

• If you would need to show two separate data flows, you need to
create two separate single direction arrows.
RULES : DATA FLOW
• A fork in a data flow means that exactly the same data goes from a
common location to two (or more) processes, data sources, or
sources/sinks.
RULES : DATA FLOW
• A join in the data flow means that exactly the same data come
from any of two (or more) different processes, data stores, or
sources/sinks to a common location.
RULES : DATA FLOW
• A data flow cannot directly go back to the same process it leaves.
• There must be at least one other process that handles the data
flow, produces some other data flow, and then returns the original
data flow to the beginning process.
RECAP
• Q: The conservation of inputs and outputs to a DFD process when that process is
decomposed to a lower level.
• A: Balancing

• Q: The work or actions performed on data so that they are transformed, stored,
or distributed.
• A: Process

• Q: The origin and/or destination of data; sometimes referred to as external

entities.
• A: Source/Sink
RECAP
• Q: A picture of the movement of data between external entities and the
processes and data stores within a system is known as..
• A: Data Flow Diagram

• Q: The overview of an organizational system that shows the system boundary,

external entities that interact with the system, and the major information flows
between the entities of the system.
• A: Context Diagram
RECAP
• Q: Data at rest, which may take the form of many different physical
representations.
• A: Data Source

• Q: The iterative process of breaking the description of a system down into finer
and finer detail, which creates a set of charts in which one process on a given
chart is explained in greater detail on another chart.
• A: Functional Decomposition
In-class Exercise
State Bank of India (SBI) provides loans to its banking customers. First a
potential loan customer meets with a loan officer and submits a loan
application by filling details such as type of loan (home loan/car loan),
required loan amount, loan duration, PAN Number, annual income
documents and residence address.
The loan officer determines the customer's credit score (CIBIL score) by
entering his PAN No. Depending on the credit rating of the customer and
annual income, the loan officer can either accept or reject the loan
application. In case the loan is approved, the loan officer decides the interest
rate, loan amount and payment schedule. Customer is intimated whether the
loan application is approved or rejected through a written letter that is sent
to the customer to his residence address.
Based on the above loan application process, develop a draw a DFD - Level 0,
1 and 2.
DFD Modelling Software and Related Links
SmartDraw
➢https://www.smartdraw.com/data-flow-diagram/#DFDSymbols
Visual-paradigm
➢ https://online.visual-paradigm.com/diagrams/features/dfd-maker/

Creately
➢ https://creately.com/lp/data-flow-diagram-software-online/

Lucid Chart
➢ https://www.lucidchart.com/pages/examples/data-flow-diagram-software