Methodologies for

Modeling and
Designing Systems
 Data Flow Diagram (DFD)
 The primary tool for representing a system’s component
processes and the flow of data between them
 Offers a logical graphic model of information flow, partitioning a
system into modules that show manageable levels of detail.
 Rigorously specifies the processes or transformations that occur
within each module and the interfaces that exist between them.
 Through leveled data flow diagrams, a complex process can be
broken down into successive levels of detail.
 An entire system can be divided into subsystems with a high-level
data flow diagram.
 Each subsystem, in turn, can be divided into additional subsystems
with second-level data flow diagrams,
 The lower-level subsystems can be broken down again until the
lowest level of detail has been reached.
2
 Components of DFD
 External entity: an outside system that sends or receives data,
communicating with the system being diagrammed.
 They are the sources and destinations of information entering or
leaving the system. They might be an outside organization or
person, a computer system or a business system.
 They are also known as terminators, sources and sinks or actors.
 Process: any process that changes the data, producing an output. It
might perform computations, or sort data based on logic, or direct
the data flow based on business rules.
 Data store: files or repositories that hold information for later use,
such as a database table or a membership form.
 Data flow: the route that data takes between the external entities,
processes and data stores. It portrays the interface between the other
components
3
Data Flow Diagram – Context Level

4
Data Flow Diagram – Level 1

5
Data Flow Diagram – Level 2

6
Core Activities of Systems Development
7
 Software Development Process

 Engineering stage - Less predictable but smaller teams doing design and
production activities.
 This stage is decomposed into two distinct phases Inception and Elaboration
 Production stage - More predictable but larger teams doing construction,
test, and deployment activities.
 This stage is also decomposed into two distinct phases Construction and
Transition.
8
SDLC Vs PDLC
 SDLC – Software Development Life Cycle
 Describe a process for planning, creating, testing, and deploying an
information system.
 Composed of a number of clearly defined and distinct work phases to
plan for, design, build, test, and deliver information systems.
 The SDLC is not a methodology per se, but rather a description of
the phases in the life cycle of a software application.
 PDLC – Product Development Life Cycle
 Process that is responsible for creating and bringing to market, a
new product and generally includes the business units.
 It also includes hardware and is concerned with the complete
development of a product.
 The SDLC is the specific steps within the PDLC that are
completed by the technical organization
9
SDLC – PDLC Relationship

10
Systems Development Life Cycle (SDLC) –
Life Cycle Phases

11
 SDLC Phases
 Initiation - Identify and validate an opportunity to improve business
accomplishments of the organization or a deficiency related to a business
need and document them as concept proposal
 System Concept Development Phase
 Once a business need is approved, the approaches for accomplishing the
concept are reviewed for feasibility and appropriateness.
 The Systems Boundary Document identifies the scope of the system and
requires approval from stakeholders and funding before beginning the
Planning Phase.
 Planning - The concept is further developed to describe
 How the business will operate once the approved system is implemented
 Assess how the system will impact employee and customer privacy.
 To ensure the products and /or services provide the required capability on-
time and within budget, project resources, activities, schedules, tools, and
reviews are defined.
12
 SDLC Phases
 Requirement Analysis

 Design the Application – Define

 System characteristics, data storage and access for the database layer, user
interface at the desktop layer, business rules layer or the application logic, A
top-level architecture of the system identifying items of hardware, software,
and manual-operations
 Development - The detailed specifications produced during the design
phase are translated into hardware, communications, and executable
software.
 Code and Test Software, Integrate the software units, components and
modules, Conduct software and systems qualification testing and document
software acceptance support.
13
 SDLC Phases
 Integration and Testing - Various components of the system are integrated
and systematically tested.
 Establish the test environment, conduct Integration, Subsystem/System,
security and acceptance testing
 Implementation - The system or system modifications are installed and
made operational in a production environment after the system has been
tested and accepted.
 Maintenance - The system is monitored for continued performance in
accordance with user requirements, and needed system modifications are
incorporated.
 The operational system is periodically assessed through In-Process Reviews
to determine how the system can be made more efficient and effective.
 Disposition - Ensure the orderly termination of the system and preserve
the vital information about the system so that some or all of the
information may be reactivated in the future if necessary.
14
 SDLC
METHODOLOGIES

15
 SDLC Methodologies
 Defined as a mathematical and engineering approach of
dividing the development process.
 Model to plan, design, test and control the processes for
developing an information system, furnished with tools
and techniques
 In this context, model refers to a logical description
of development processes, which can be sequential
or iterative
 Recommended collection of phases, procedures,
guidelines, tools and techniques for management of
information systems development
16
 Choosing an SDLC approach
 Broadly two approaches for performing software development activities
 Prescriptive − The SDLC models that will provide you ways of
performing the activities in a prescribed manner as defined by the
framework.
 Adaptive − The SDLC models that will give you flexibility in
performing the activities, with certain rules that need to be followed.
 Selecting the right approach or methodology depends
 Requirements
 Solution or the end product
 Feedback on the work done
 Frequency of change request or enhancements
 Cost of Delay
 Experience on projects
 Traditional Vs Agile Methodologies

17
Waterfall Model
Requirements are very
well documented,
clear and fixed,
Product definition is
stable, Technology is
understood and is not
dynamic, there are
very limited or no
ambiguous
requirements,
Development
environment is stable,
Ample resources with
required expertise are
available to support
the product, Very
limited customer
interaction required
during product
development
Incremental Model
 Construct a partial
implementation of a total
system
 Then slowly add increased
functionality
 The incremental model
prioritizes requirements of
the system and then
implements them in groups.
 Each subsequent release of
the system adds function to
the previous release, until all
designed functionality has
been implemented.
Structured Evolutionary Prototyping
 Developers build a prototype
during the requirements phase
 Prototype is evaluated by end
users
 Users give corrective
feedback
 Developers further refine the
prototype
 When the user is satisfied, the
prototype code is brought up
to the standards needed for a
final product.
IT Environment
 Toyota Production System – Deadly
Wastes
 Transport : Unnecessary transportation
 Inventory: Excess inventory levels and too much work in progress at
one time
 Motion : Unnecessary motion of people, poor work standards
equipment or machinery
 Waiting : Lag time in between each step in production.
 When employees are left waiting no value is being added.
 When equipment is left waiting again no value is added
 Over-production : against customer actual demand
 Over-processing : More time into a product than a customer needs
 Designs that require high-tech machinery for unnecessary features
 Defects : Effort and cost required for corrections.
 Waste of unused talent and ingenuity
22
 Lean Manufacturing (Q+C+D)
 Eliminating waste without compromising quality and maximizing
productivity
 Follows a demand-based flow style
 Relies heavily on people & requires a higher inventory of smaller parts
 Value is created by producer defined by the customer
 Value stream encompasses the product's entire
lifecycle - raw materials through to disposal -
examine each stage of the cycle for waste
 Enabling a harmonized & integrated set of processes
in which activities move in a constant stream.
 Demand-based operations - Pull relies on flexibility
and communication.
 Kaizen - Targeting the root causes of quality issues
and ferreting out and eliminating waste across the
value stream.

23
Lean Software Product Development

24
 Lean Vs (and) Six Sigma
 Six Sigma focuses more on eliminating any variation in the customer
experience
 Elimination waste resulting from variation within the process.
 Set of techniques that strive to greatly reduce the rate of defects.
 Lean focuses on analyzing workflow to reduce cycle time and eliminate
waste. Six Sigma strives for near perfect results that will reduce costs
and achieve higher levels of customer satisfaction.
 Six Sigma has a flare to improve the cost of poor quality and Lean
improves Operating costs.
 Six Sigma has a longer learning curve and lean has a shorter one.
 Six Sigma uses various approaches to process improvements whereas
lean mainly use value stream mapping.
 Data is the main driver in a six sigma project while demand is the main
driver for Lean.
25
Agile Manufacturing (Q+C+D) +F+R
 Manufacturing that responds quickly to customer desires and
input through a highly integrated information technology
communication system to produce high-quality, highly
customizable modular products.
 Consists of small teams of highly responsible employees who
are given the freedom to use their skill and creativity in short
uninterrupted cycles to complete the work in a way that makes
the customer happy.
 Production configuration for agile manufacturing uses fewer
people, relying more on automation and modular design
 Requires a lower inventory due to modular design
 More ready to adapt to customization requests.

26
 Agile Manifesto in Software Development
 We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 That is, while there is value in the items on the right, we value the items
on the left more.
 Proposed improved Agile
 Team vision and discipline over individuals and interactions
 Validated learning over working software
 Customer discovery over customer collaboration
 Initiating change over responding to change

27
Agile Principles

28
Agile Development Lifecycle

29
Agile Methodologies
Agile Characteristics Usage constraints
methodology
ASD Promotes adaptive paradigm and derives It is more about concepts and culture
principles from radical software development rather than in practice
AM Agile modelling – agility and rapid It does not work independently but work
development in producing sufficiently within other methods as supplement
advanced models to support acute design.
Crystal Family of methods to be chosen suitable for Lack of support for mission-critical
the business needs with rules of thumb for systems, distributed teams, scalability,
tailoring. Flexible and configurable process insistence on only collocation.

DSDM Provides control framework for rapid Availability issue to wider audience
application development. Keeps time and
resources as constant and adjusted the
functionality to be developed

XP Customer focused and close customer Lack of attention on management

participation, short iterations and small release, practises
continuous refactoring.

30
Agile Methodologies
Agile Characteristics Usage constraints
methodology

FDD More emphasis on quality, frequent and Focused mainly on design and
tangible deliveries and accurate monitoring of implementation
project progress. Very short iterations

ASP The Agile Software Process model focusses on Unable to predict effort upfront and
accelerated development with flexibility to threat of loss of focus due to changing
include volatile requirements requirements,

PP Pragmatic programming – more of pragmatic Does not define any concrete

perspective with a set of best practises methodology to develop a system

SCRUM Focusses on flexibility, adaptability, Coding and all testing process not
productivity, through small, self- motivated defined completely.
teams. Integrated project management process
to overcome deficiencies in the development
process

31
Scrum

32
Questions ???