System Analysis and Design Program

System Analysis and Design
An ISO 9001:2008 Certified Company
A NASSCOM Member Company
www.AdaptiveProcesses.com

Any organized combination of people, hardware,
software, communications networks, and data
resources that stores, retrieves, transforms, and
disseminates information in an organization
© Adaptive Processes Consulting Experience World Class Processes! 4
What is an Information System?
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/system-analysis-and-design-program-1926

A Business System

Transaction Processing Cycle

ECS Tools

Manufacturing Systems

Financial Management Systems

CRM Application Clusters

System Development Overview

System development Tools & Techniques
CASE Tools:
• Provides an overall frame work to develop and
maintain an information system.
•Supports Various design methodologies
• Many CASE tools can generate code from design
models
•Boosts IT productivity & quality

System design methods
Structured analysis method
• Focuses on processes that transform data into
information and data ( Relational Database Design)
separately
• Divides the system based on Procedures and
Functions
• System functionality is realized by a set of
interacting procedures

Invoice processing system
Issue invoices
Receive payments
Issue receipts
Issue reminders

Successful System development tips
Involve user throughout the development process
Listening to stakeholders needs
Remain flexible
Use project management tools
Have clear cost benefit informationThis document is a partial preview. Full document download can be found on Flevy:

Implementing Business Systems

Application development
Design
Modules
Code
Modules
Test
Modules
Document
Modules
Integration
Testing
System Testing
documentation

Application development
Software Testing
Unit testing
Integration testing
System testing

Documentation
Documentation includes:
• Program documentation
•System documentation
•Operations documentations
•User documentationThis document is a partial preview. Full document download can be found on Flevy:

System installation & evaluation
Training
• Plan should start early in the system development
process
• As documentations are created we should plan how
to use these in training.
•
•Who should receive training
• Users
• Mangers
• IT staff

IT Staff Training
•Project history and justification
• System architecture
•System documentation
•Typical user questions
•Vendor support
•Logging and resolving problems
•Technical training for IT staff
• User and management training

System changeover
Process of putting new system online and retiring the
old system
• Direct cutover
•Parallel operation
•Pilot operation
•Phased operation

Final report to management
•Final versions of all system documentation
• Planned modifications and enhancements to the
system that have been identified
•Recap of all system development costs and
schedules
• Comparison of costs and schedules estimates
•Post implementation evaluation

Water Fall model

Evolutionary development
• Exploratory development
– Objective is to work with customers and to evolve a
final system from an initial outline specification. Should
start with well-understood requirements and add new
features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system requirements.
Should start with poorly understood requirements to
clarify what is really needed.

Prototyping
• A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
• System stakeholders can experiment with prototype to find out
more about the problem and possible solutions
• This is called throw away prototype as it is not delivered to the
customer or maintained by developer

Process iteration
• System requirements ALWAYS evolve in the course of a
project so process iteration where earlier stages are
reworked is always part of the process for large systems.
• Two approaches
– Incremental delivery;
– Spiral development.

Incremental development advantages
• Customer value can be delivered with each increment
so system functionality is available earlier.
• Early increments act as a prototype to help elicit
requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the
most testing.

Kendall & Kendall
6-79
RAD

RAD
• RAD environment are usually organized as a set of tools that
allow data to be created, searched, displayed and presented in
reports
• Tools included in RAD environment are:
• Database programming language
• Interface generator
• Links to office applications
• Report generators

RAD environment
• Links to office applications: provides facility to link to office
application like spreadsheet for numerical analysis and Word
processor for report template creation
• Report generator: used to create reports from information
contained in the database

Visual programming with reuse: example

Compound Document example

Principles of agile methods
Customer
involvement
Closely involved throughout
Provide requirements
Prioritize requirements
Evaluate Iterations
Incremental
Delivery
Software is developed in
increments
Customer specify the
requirement to be included
in increment

Problems with agile methods
• Difficult to get customer representative’s time to work
with development team.
• Team members may not have suitable personality to
interact well with others and work closely.
• Prioritizing changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity requires extra work.
• Writing contracts may be difficult for iterative
developmentThis document is a partial preview. Full document download can be found on Flevy:

The XP release cycle

Extreme programming practices
5.
Refactoring
Developers refactor the code
continuously.
This keeps code simple &
maintainable
6. Pair
programming
Developers work in pairs,
checking each others work

XP and agile principles
• Customer involvement : through full-time customer
engagement with the team.
• Incremental development : through small, frequent system
releases.
• People not process : through pair programming, collective
ownership and a process that avoids long working hours.
• Change supported: through regular system releases.
• Maintaining simplicity: through constant refactoring of
code.

XP and Requirements
• If changes are required for the system that is already
implemented, new user stories are developed and
again the customer decides whether these changes
should have priority over new functionality

Test-first development
• Tests are written before the code.
• Each tasks generates one or more unit test that
checks the implementation described in that task
• Tests are written as programs rather than data so
that they can be executed automatically. The test
includes a check that it has executed correctly.

Pair programming
• Measurements suggest that development
productivity with pair programming is similar to
that of two people working independently.

RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software

Software change
• Software change is inevitable
– New requirements emerge when the software is
used;
– The business environment changes;
– Errors must be repaired;
– New computers and equipment is added to the
system;
– The performance or reliability of the system may
have to be improved.
• A key problem for organisations is implementing and
managing change to their existing software systems.

Emergency repair

Goal of Project Management
To deliver the system that is acceptable to
users and is developed on time and within
budget
3-127

Project Planning
• Probably the most time-consuming project
management activity.
• Continuous activity from initial concept through
to system delivery. Plans must be regularly
revised as new information becomes available.
• Various different types of plan may be developed
to support the main software project plan that is
concerned with schedule and budget.
3-130

Milestones in the requirement process
3-133

Project Scheduling
3-136
Once the time for each task is estimated, the PM
determines if certain tasks are dependant on other
activities
A dependant task can not be started until one or more
tasks are completed
After identifying the dependencies all the tasks are
arranged in a logical sequenceThis document is a partial preview. Full document download can be found on Flevy:

Activity network
3-139

Risk management
3-142
What is a Risk ?
Risk Tolerance
Risk response

Using Dataflow Diagrams
Systems Analysis and Design, 7e
Kendall & Kendall

Data Flow Diagrams
• Graphically characterize data
processes and flows in a business
system
• Depict:
– System inputs
– Processes
– outputs
148

Basic Symbols
• A double square for an external
entity
• An arrow for movement of data
from one point to another
• A rectangle with rounded corners
for the occurrence of a
transforming process
• An open-ended rectangle for a data
store
151

Data Flow
• Shows movement of data from one
point to another
• Described with a noun
• Arrowhead indicates the flow
direction
• Represents data about a person,
place, or thing
7-154

Figure 7.2 Steps in developing data flow diagrams
157

Figure 7.3 Context diagram
160

• Start with the data flow from an
entity on the input side
• Work backwards from an output
data flow
• Examine the data flow to or from a
data store
• Analyze a well-defined process
• Take note of any fuzzy areas
163

Creating Child Diagrams
• Each process on diagram 0 may be exploded to create a child
diagram
• A child diagram cannot produce output or receive input that
the parent process does not also produce or receive
• The child process is given the same number as the parent
process
– Process 3 would explode to Diagram 3
7-166
Kendall &
Kendall

Checking the Diagrams for Errors
• Forgetting to include a data flow
or pointing an arrow in the wrong
direction
7-169

Figure 7.5 Typical errors that can occur in a data flow diagram
(payroll example)
172

Figure 7.7 Features common of logical and physical data flow
diagrams
175

• Sequencing processes that have to
be done in a particular order
• Identifying temporary data stores
• Specifying actual names of files
and printouts
• Adding controls to ensure the
processes are done properly
• Describing processes in more
detail
7-178

Event Response Tables
• An event table is used to
create a data flow diagram
by analyzing each event
and the data used and
produced by the event
• Every row in an event table
represents a data flow
diagram fragment and is
used to create a single
process on a data flow
diagram
181

Use Cases and Data Flow Diagrams
• Each use case defines one activity
and its trigger, input, and output
• Allows the analyst to work with
users to understand the nature of
the processes and activities and
then create a single data flow
diagram fragment
184

Reasons for Partitioning Data Flow Diagram
187
5.Efficiency:
Several batch processes may be included in the same program for
efficiency
6.Consistency:
Several processes may be included in the same program or job
stream for consistency of data.
7.Security:
May be partitioned into different programs for security reasons.

Summary
• Data flow diagrams
– Structured analysis and design
tools that allow the analyst to
comprehend the system and
subsystems visually as a set of
interrelated data flows
• DFD symbols
– Rounded rectangle
– Double square
– An arrow
– Open-ended rectangle
190

Analyzing Systems Using Data Dictionaries
Systems Analysis and Design, 7e
Kendall & Kendall

Figure 8.1 How data dictionaries relate to data flow diagrams
8-196

Data Stores
• We must document every DFD data store in data dictionary
• Data stores are created for each different data entity being
stored
• When data flow base elements are grouped together to form a
structural record, a data store is created for each unique
structural record
8-199

Documenting Entities
• Documenting all external entities that interact with the system
– Entity name
– Description
– Alternate name
– Input data flows
– Output data flows
8-202

Structural Record Example
8-205

Data Element Characteristics
• Element ID
• The name of the element
• Aliases
• A short description of the element
• Element is base or derived
• Element length
• Type of data
• Input and output formats
• Validation criteria
• Default value
• An additional comment or remark area
• Source, Security, Responsible user
8-208

Element Is Base or Derived
• A base element is one that has been initially keyed into the
system
• A derived element is one that is created by a process, usually
as the result of a calculation or a series of decision making
statements
8-211

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

System Analysis and Design Program

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to System Analysis and Design Program

Similar to System Analysis and Design Program (20)

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

System Analysis and Design Program