SAD-1to8

Assuming the Role of the
Systems Analyst
Major Topics
• Information systems
• Phases of analysis and design
• System maintenance
• CASE tools
• Alternate methodologies
Kendall & Kendall 2005 Pearson Prentice Hall 1-2

Information
• Information is an organizational
resource, which must be managed as
carefully as other resources.
• Costs are associated with information
processing.
• Information processing must be
managed to take full advantage of its
potential.

Categories
Information systems fall into one of the
following eight categories:
• Transaction processing systems (TPS).
• Office automation systems (OAS).
• Knowledge work systems (KWS).
• Management information systems (MIS).
• Decision support systems (DSS).
• Expert systems (ES) and Artificial Intelligence (AI).
• Group decision support systems (GDSS) and Computer-
Supported Collaborative Work Systems.
• Executive support systems (EES).

New Technologies
New technologies are being integrated
into traditional systems:
• Ecommerce uses the Web to perform business
activities.
• Enterprise Resource Planning (ERP) has the
goal of integrating many different information
systems within the corporation.
• Wireless and handheld devices, including
mobile commerce (mcommerce).
• Open source software.

Advantages of Using the Web
• The benefits of using the Web are:
• Increasing awareness of the availability
of the service, product, industry,
person, or group.
• 24-hour access for users.
• Standard interface design.
• Creating a global system.
Nature of Analysis and Design
Systems analysis and design is a
systematic approach to:
• Identifying problems, opportunities, and
objectives.
• Analyzing the information flows in
organizations.
• Designing computerized information
systems to solve a problem.

Systems Analyst
• Systems analysts act as:
• Outside consultants to businesses.
• Supporting experts within a business.
• As change agents.
• Analysts are problem solvers, and
require communication skills.
• Analysts must be ethical with users and
customers.

Systems Development Life
Cycle
• The systems development life cycle is a
systematic approach to solving business
problems.
• It is divided into seven phases.
• Each phase has unique activities.

Phase 1
• Identifying:
• Problems.
• Opportunities.
• Objectives.
• Personnel involved:
• Analyst.
• User management.
• Systems management.

Phase 2
• Determining information requirements:
• Interview management, operations personnel.
• Gather systems/operating documents.
• Use questionnaires.
• Observe the system and personnel involved.
• Learn the who, what, where, when, and how,
and the why for each of these.

Phase 2 (Continued)
• Analyst.
• User operations workers.

Phase 3
• Analyzing system needs:
• Create data flow diagrams.
• Document procedural logic for data flow diagram
processes.
• Complete the data dictionary.
• Make semistructured decisions.
• Prepare and present the system proposal.
• Recommend the optimal solution to management.

Phase 3 (Continued)
• Analyst.

Phase 4
• Designing the recommended system:
• Design the user interface.
• Design output.
• Design input.
• Design system controls.
• Design files and/or database.
• Produce program specifications.
• Produce decision trees or tables.
Phase 4 (Continued)
• Analyst.
• System designer.

Phase 5
• Developing and documenting software:
• Design computer programs using structure
charts, Nassi-Schneiderman charts, and
pseudocode.
• Walkthrough program design.
• Write computer programs.
• Document software with help files,
procedure manuals, and Web sites with
Frequently Asked Questions.

Phase 5 (Continued)
• Analyst.
• Programmers.

Phase 6
• Testing and maintaining the system:
• Test and debug computer programs.
• Test the computer system.
• Enhance system.

Phase 6 (Continued)
• Analyst.
• Programmers.

Phase 7
• Implementing and evaluating the
system:
• Plan conversion.
• Train users.
• Purchase and install new equipment.
• Convert files.
• Install system.
• Review and evaluate system.

Phase 7 (Continued)
• Analyst.
• Programmers.

Rapid Application Development
Rapid Application development (RAD) is
an object-oriented approach to systems
development.

System Maintenance
• System maintenance is:
• Removing undetected errors, and
• Enhancing existing software.
• Time spent on maintenance typically
ranges from 48-60 percent of total
time.

System Enhancements
Systems are enhanced for the following
reasons:
• Adding additional features to the system.
• Business and governmental requirements
change over time.
• Technology, hardware, and software are
rapidly changing.

CASE Tools
• CASE tools are automated, microcomputer-
based software packages for systems
analysis and design.
• Four reasons for using CASE tools are:
• To increase analyst productivity.
• Facilitate communication among analysts and
users.
• Providing continuity between life cycle phases.
• To assess the impact of maintenance.

CASE Tool Categories
CASE tools may be divided into several
categories
• Upper CASE (also called front-end CASE)
tools, used to perform analysis and design.
• Lower CASE (also called back-end CASE).
These tools generate computer language
source code from CASE design.
• Integrated CASE, performing both upper
and lower CASE functions.

Upper CASE
Upper CASE tools:
• Create and modify the system design.
• Store data in a project repository.
• The repository is a collection of records,
elements, diagrams, screens, reports, and
other project information.
• These CASE tools model organizational
requirements and define system
boundaries.

Lower CASE
• Lower CASE tools generate computer
source code from the CASE design.
• Source code may usually be generated
in several languages.

Advantages of Generating
Code
• Time to develop new systems decreases.
• The time to maintain generated code is less than
to maintain traditional systems.
• Computer programs may be generated in more
than one language.
• CASE design may be purchased from third-party
vendors and tailored to organizational needs.
• Generated code is free from program coding
errors.

Reverse Engineering
• Reverse engineering is generating the
CASE design from computer program
code.
• Source code is examined, analyzed, and
converted into repository entities.

Reverse Engineering
(Continued)
• Reverse engineering produces
(depending on the tool set used):
• Data structures and elements, describing
the files, records, and field.
• Screen designs, if the program is online.
• Report layouts for batch programs.
• A structure chart showing the hierarchy of
the modules in the program.
• Database design and relationships.
Advantages of Reverse
Engineering
Reverse Engineering has the following
advantages:
• Reduced system maintenance time.
• Program documentation is produced for loosely
documented programs.
• Structured programs may be generated from
unstructured, older programs.
• Future system maintenance is easier to
implement.
• Unused portions of programs may be eliminated.

Object-Oriented Analysis and
Design
• Object-oriented (O-O) analysis and
design is used to build object-oriented
programs.
• O-O programming examines the objects
of a system.
• Objects are grouped into classes for
optimal reuse and maintainability.

The Unified Modeling
Language
• The Unified Modeling Language (UML)
is an industry standard for modeling
object-oriented systems.
• It breaks down a system into a use case
model.

Extreme Programming (XP)
• Extreme programming takes good
software development practices and
pushes them to the limit.
• It is based on:
• Values.
• Principles.
• Core practices.

(Continued)
• Extreme programming values are:
• Communication.
• Simplicity.
• Feedback.
• Courage.

Alternate Methodologies
• Alternate methodologies are available
for analyzing systems.
• These include:
• Prototyping.
• ETHICS.
• Project Champions.
• Soft Systems Methodology.
• Multi-view.

Understanding Organizational
Style and Its Impact on
Information Systems
Organizations
• Organizations are composed of
interrelated and interdependent
subsystems.
• System and subsystem boundaries and
environments impact on information
system analysis and design.

Organizational Environment
• Community environment
• Geographical
• Demographics (education, income)
• Economic environment
• Market factors
• Competition
• Political environment
• State and local government
Open and Closed Systems
Systems are described as either
• Open
• Free-flowing information.
• Output from one system becomes input to
another.
• Closed with restricted access to information
• Limited by numerous rules.
• Information on a need to know basis.

Virtual Organizations
• A virtual organization has parts of the
organization in different physical
locations.
• Computer networks and
communications technology are used to
work on projects.

Virtual Organization
Advantages
Advantages of a virtual organization
are:
• Reduced costs of physical facilities.
• More rapid response to customer needs.
• Flexibility for employees to care for
children or aging parents.

Enterprise Resource Planning
• Enterprise Resource Planning (ERP)
describes an integrated organizational
information system.
• The software helps the flow of
information between the functional
areas within the organization.

Context-Level Data Flow
Diagram (DFD)
• A context-level data flow diagram is an
important tool for showing data used
and information produced by a system.
• It provides an overview of the setting or
environment the system exists within:
which entities supply and receive
data/information.

Context-Level DFD Symbols
• Entity, a person, group, department, or
system that supplies or receives
information.
• It is labeled with a noun.
Customer

(Continued)
• Process, representing the entire system.
• It is given the number 0.
0
Customer
System

(Continued)
• Data flow, represented by an arrow.
• It shows information that passes to or
from the process.
• Data flow is labeled with a noun.
Travel Request
Passenger Reservation
Data Flow Example

Entity-Relationship Diagrams
(E-R Diagrams)
• Entity-relationship diagrams help the
analyst understand the organizational
system and the data stored by the
organization.
• Symbols are used to represent entities
and relationships.

Entities
There are three types of entities:
• Fundamental entity, describing a person,
place, or thing.
• Associative entity, linking entities.
• Attributive entity, to describe attributes
and repeating groups.

Fundamental Entity
• Describes a person, place, or thing.
• Symbol is a rectangle.
Patron

Associative Entity
• Joins two entities.
• Can only exist between two entities.
• Symbol is a diamond inside a rectangle.
• Also called a:
• Gerund.
• Junction. Reservation
• Intersection.
• Concatenated entity.

Attributive Entity
• Describes attributes and repeating
groups.
• Symbol is an oval in a rectangle.
Performance

Relationships
• Relationships show how the entities are
connected.
• There are three types of relationships:
• One to one.
• One to many.
• Many to many.
• Relationship lines are labeled.

Relationship Notation
• One is indicated by a short vertical line.
• Many is indicated by a crows foot.

Entity Relationship Example

Attributes
Data attributes may be added to the
diagram.
Patron Name
Patron Patron address
Patron phone
Patron credit card

Creating Entity-Relationship
Diagrams
Steps used to create E-R diagrams:
• List the entities in the organization.
• Choose key entities to narrow the scope of
the problem.
• Identify what the primary entity should be.
• Confirm the results of the above through
data gathering.

Levels of Management

Managerial Control
• The three levels of managerial control
are:
• Operations management.
• Middle management.
• Strategic management.

Operations Management
• Make decisions using predetermined
rules that have predictable outcomes
make decisions.
• Oversee the operating details of the
organization.
• dependent on internal information.

Middle Management
• Make short-term planning and control
decisions about resources and
organizational objectives.
• Decisions may be partly operational and
partly strategic.
• Decisions are dependent on internal
information, both historical and
prediction oriented.

Strategic Management
• Look outward from the organization to
the future.
• Make decisions that will guide middle
and operations managers.
• Work in highly uncertain decision-
making environment.
• Define the organization as a whole.
• Often make one-time decisions.
Managerial Levels
Each of the three levels of management
have:
• Different organization structure.
• Leadership style.
• Technological considerations.
• Organization culture.
• Human interaction.
• All carry implications for the analysis and
design of information systems.

Organizational Culture
• Organizations have cultures and
subcultures.
• Learn from verbal and nonverbal
symbolism.

Verbal Symbolism
Using language to convey:
• Myths.
• Metaphors.
• Visions.
• Humor.

Nonverbal Symbolism
• Shared artifacts
• Trophies, etc.
• Rites and rituals
• Promotions
• Birthdays, etc.
• Clothing worn
• Office placement and decorations
Determining Feasibility and
Managing Analysis and Design
Activities
Project Initiation
Projects are initiated for two broad
reasons:
• Problems that lend themselves to systems
solutions.
• Opportunities for improvement through
• Upgrading systems.
• Altering systems.
• Installing new systems.

Organizational Problems
Identify problems by looking for the following
signs:
• Check output against performance criteria
• Too many errors.
• Work completed slowly.
• Work done incorrectly.
• Work done incompletely.
• Work not done at all.

(Continued)
• Observe behavior of employees
• High absenteeism.
• High job dissatisfaction.
• High job turnover.

(Continued)
• Listen to feedback from vendors,
customers, and suppliers
• Complaints.
• Suggestions for improvement.
• Loss of sales.
• Lower sales.

Project Selection
Five specific criteria for project selection:
• Backed by management.
• Timed appropriately for commitment of resources.
• It moves the business toward attainment of its
goals.
• Practicable.
• Important enough to be considered over other
projects.

Possibilities for Improvement
Many possible objectives exist including:
• Speeding up a process.
• Streamlining a process.
• Combining processes.
• Reducing errors in input.
• Reducing redundant storage.
• Reducing redundant output.
• Improving system and subsystem integration.

Feasibility Impact Grid (FIG)
• A feasibility impact grid (FIG) is used to
assess the impact of any improvements
to the existing system.
• It can increase awareness of the
impacts made on the achievement of
corporate objectives

Feasibility Impact Grid (FIG)
(Continued)
• Current or proposed systems are listed
on the left.
• Objectives are listed on the top.
• Red arrows indicate a positive impact.
• Green arrows indicate implementation.

Feasibility
• A feasibility study assesses the
operational, technical, and economic
merits of the proposed project.
• There are three types of feasibility:
• Technical feasibility.
• Economic feasibility.
• Operational feasibility.

Technical Feasibility
• Technical feasibility assesses whether
the current technical resources are
sufficient for the new system.
• If they are not available, can they be
upgraded to provide the level of
technology necessary for the new
system.

Economic Feasibility
• Economic feasibility determines whether
the time and money are available to
develop the system.
• Includes the purchase of:
• New equipment.
• Hardware.
• Software.

Operational Feasibility
• Operational feasibility determines if the
human resources are available to
operate the system once it has been
installed.
• Users that do not want a new system
may prevent it from becoming
operationally feasible.

Activity Planning
• Activity planning includes:
• Selecting a systems analysis team.
• Estimating time required to complete each
task.
• Scheduling the project.
• Two tools for project planning and
control are Gantt charts and PERT
diagrams.
Estimating Time
• Project is broken down into phases.
• Further project is broken down into tasks or
activities.
• Finally project is broken down into steps or
even smaller units.
• Time is estimated for each task or activity.
• Most likely, pessimistic, and optimistic
estimates for time may be used.

Gantt Charts
• Easy to construct and use.
• Shows activities over a period of time.

Gantt Chart Example

PERT Diagram
PERT-Program Evaluation and Review
Technique
• PERT diagrams show precedence, activities that
must be completed before the next activities may
be started.
• Once a diagram is drawn it is possible to identify
the critical path, the longest path through the
activities.
• Monitoring critical path will identify shortest time
to complete the project.

PERT Diagram Example

PERT Diagram Advantages
• Easy identification of the order of
precedence
• Easy identification of the critical path
and thus critical activities
• Easy determination of slack time, the
leeway to fall behind on noncritical
paths

Timeboxing
• Timeboxing sets an absolute due date
for project delivery.
• The most critical features are developed
first and implemented by the due date.
• Other features are added later.

Personal Information Manager
Software
Personal information manager (PIN)
software is useful for scheduling
activities and includes features such as:
• Telephone and fax number lists.
• To-do lists.
• Online calendars.

Team Management
• Teams often have two leaders:
• One who leads members to accomplish
tasks.
• One concerned with social relationships.
• The systems analyst must manage:
• Team members.
• Their activities.
• Their time and resources.

Goal Setting
• Successful projects require that
reasonable productivity goals for
tangible outputs and process activities
be set.
• Goal setting helps to motivate team
members.

Ecommerce Project
Management
Ecommerce and traditional software
project management differences:
• The data used by ecommerce systems is
scattered across the organization.
• Ecommerce systems need a staff with a
wide variety of skills.
• Partnerships must be built externally and
internally well ahead of implementation.
• Security is of utmost importance.
Project Failures
Project failures may be prevented by:
• Training.
• Experience.
• Learning why other projects have failed.

Extreme Programming
Extreme programming (XP) takes good
systems development practices to the
extreme.

Extreme Programming Variables
Extreme programming has four

variables that the developer can
control:
• Time.
• Cost.
• Quality.
• Cost.
• These are balanced for a project.
Extreme Programming

Extreme Programming Activities
The activities of extreme

programming are:
• Coding.
• Testing.
• Listening.
• Designing.

Extreme Programming Core
Practices
There are four core practices in

extreme programming:
• A short release time.
• Working a 40-hour week.
• Having an onsite customer.
• Pair programming.

Roles in Extreme Programming

Roles in Extreme Programming
There are a 7roles played in XP:

• Programmer.
• Customer.
• Tester.
• Tracker.
• Coach.
• Consultant.
• Big Boss.

The Planning Game
• The planning game defines rules to help
formulate the development team and
customer relationship.
• Limits uncertainty.
• Two players: the development team
and the business customer.
• Customers decide what to tackle first.

XP Development Process
• XP projects are interactive and
incremental.
• The five Stages of XP development are:
• Exploration.
• Planning.
• Iterations to the first release.
• Productionizing.
• Maintenance.


Information Gathering:
Interactive Methods
Interviewing
• Interviewing is an important method for
collecting data on information system
requirements.
• Interviews reveal information about:
• Interviewee opinions.
• Interviewee feelings.
• About the current state of the system.
• Organizational and personal goals.
• Informal procedures.

Planning the Interview
Five steps in planning the interview are:
• Reading background material.
• Establishing interview objectives.
• Deciding whom to interview.
• Preparing the interviewee.
• Deciding on question types and structure.

Question Types
There are two basic types of interview
questions:
• Open-ended.
• Closed.

Open-Ended Questions
• Open-ended interview questions allow
interviewees to respond how they wish,
and to what length they wish.
• Open-ended questions are appropriate
when the analyst is interested in breadth
and depth of reply.

Advantages of Open-Ended
Questions
Eight benefits of open-ended questions are:
• Puts the interviewee at ease.
• Allows the interviewer to pick up on the
interviewee's vocabulary.
• Reflect education, values, attitudes, and beliefs.
• Provides richness of detail.
• Reveals avenues of further questioning that may
have gone untapped.

Advantages of Open-Ended
Questions
Eight Benefits of open-ended questions
are: (continued)
• Provides more interest for the interviewee.
• Allows more spontaneity.
• Makes phrasing easier for the interviewer.
• Useful if the interviewer is unprepared.

Disadvantages of Open-Ended
Questions
The five drawbacks include:
• May result in too much irrelevant detail.
• Possibly losing control of the interview.
• May take too much time for the amount of
useful information gained.
• Potentially seeming that the interviewer is
unprepared.
• Possibly giving the impression that the
interviewer is on a "fishing expedition”

Closed Interview Questions
• Closed interview questions limit the
number of possible responses.
• Closed interview questions are
appropriate for generating precise,
reliable data that is easy to analyze.
• The methodology is efficient, and it
requires little skill for interviewers to
administer.

Benefits of Closed Interview
Questions
Six benefits are:
• Saving interview time.
• Easily comparing interviews.
• Getting to the point.
• Keeping control of the interview.
• Covering a large area quickly.
• Getting to relevant data.

Disadvantages of Closed
Interview Questions
Four drawbacks of closed interview
questions include:
• Boring for the interviewee.
• Failure to obtain rich detailing.
• Missing main ideas.
• Failing to build rapport between
interviewer and interviewee.

Attributes of Open-ended and
Closed Questions

Bipolar Questions and Probes
• Bipolar questions are those that may be
answered with a „yes‟ or „no‟ or „agree‟
or „disagree‟.
• Bipolar questions should be used
sparingly.

Probing Questions
• Probing questions elicit more detail
about previous questions.
• The purpose of probing questions is:
• To get more meaning.
• To clarify.
• To draw out and expand on the
interviewee's point.

Question Sequencing
The three basic ways of structuring
interviews are :
• Pyramid, starting with closed questions and
working toward open-ended questions.
• Funnel, starting with open-ended questions
and working toward closed questions.
• Diamond, starting with closed, moving
toward open-ended, and ending with
closed questions.

Pyramid Structure
• Begins with very detailed, often closed
questions
• Expands by allowing open-ended
questions and more generalized
responses
• Is useful if interviewees need to be
warmed up to the topic or seem
reluctant to address the topic
Funnel Structure
• Begins with generalized, open-ended
questions
• Concludes by narrowing the possible
responses using closed questions
• Provides an easy, nonthreatening way
to begin an interview
• Is useful when the interviewee feels
emotionally about the topic
Diamond Structure
• A diamond-shaped structure begins in a
very specific way
• Then more general issues are examined
• Concludes with specific questions
• Combines the strength of both the
pyramid and funnel structures
• Takes longer than the other structures
Closing the Interview
• Always ask “Is there anything else that
you would like to add?”
• Summarize and provide feedback on
your impressions.
• Ask whom you should talk with next.
• Set up any future appointments.
• Thank them for their time and shake
hands.

Interview Report
• Write as soon as possible after the
interview.
• Provide an initial summary, then more
detail.
• Review the report with the respondent.

Joint Application Design (JAD)
• Joint Application Design (JAD) can
replace a series of interviews with the
user community.
• JAD is a technique that allows the
analyst to accomplish requirements
analysis and design the user interface
with the users in a group setting.

When to Use JAD
JAD may be used when:
• Users are restless and want something
new.
• The organizational culture supports joint
problem-solving behaviors.
• Analysts forecast an increase in the
number of ideas using JAD.
• Personnel may be absent from their jobs
for the length of time required.

JAD Personnel
JAD involves:
• Analysts
• Users
• Executives
• Observers
• Scribe
• Session leader

Benefits of JAD
The potential benefits of using JAD are:
• Time is saved, compared with traditional
interviewing.
• Rapid development of systems.
• Improved user ownership of the system.
• Creative idea production is improved.

Drawbacks of Using JAD
Potential drawbacks of using JAD are:
• JAD requires a large block of time to be
available for all session participants.
• If preparation is incomplete, the session
may not go very well.
• If the follow-up report is incomplete, the
session may not be successful.
• The organizational skills and culture may
not be conducive to a JAD session.

Questionnaires
Questionnaires are useful in gathering
information from key organization
members about:
• Attitudes.
• Beliefs.
• Behaviors.
• Characteristics.

When to Use Questionnaires
Questionnaires are valuable if:
• Organization members are widely
dispersed.
• Many members are involved with the
project.
• Exploratory work is needed.
• Problem solving prior to interviews is
necessary.

Question Types
Questions are designed as either:
• Open-ended
• Try to anticipate the response you will get.
• Well suited for getting opinions.
• Closed
• Use when all the options may be listed.
• When the options are mutually exclusive.

Open-Ended and Closed
Questions

Questionnaire Language
Questionnaire language should be:
• Simple.
• Specific.
• Free of bias.
• Not patronizing.
• Technically accurate.
• Addressed to those who are knowledgeable.
• Appropriate for the reading level of the
respondent.

Measurement Scales
• The two different forms of
measurement scales are :
• Nominal.
• Interval.

Nominal Scales
• Nominal scales are used to classify
things into categories.
• It is the weakest form of measurement.
• Data may be totaled.
What type of software do you use the most?
1 = Word Processor
2 = Spreadsheet
3 = Database
4 = An Email Program

Interval Scales
• An interval scale is used when the
intervals are equal.
• There is no absolute zero.
• Examples of interval scales include the
Fahrenheit or centigrade scale.
How useful is the support given by the Technical Support Group?
NOT USEFUL EXTREMELY
AT ALL USEFUL
1 2 3 4 5

Validity and Reliability
Questionnaires must be valid and
reliable.
• Reliability of scales refers to consistency in
response--getting the same results if the
same questionnaire was administered
again under the same conditions.
• Validity is the degree to which the question
measures what the analyst intends to
measure.

Problems with Scales
There are three problems associated
with poorly constructed scales:
• Leniency.
• Central tendency.
• Halo effect.

Leniency
• Caused by easy raters.
• Solution is to move the “average”
category to the left or right of center.

Central Tendency
Central tendency occurs when
respondents rate everything as
average.
• Improve by making the differences
smaller at the two ends.
• Adjust the strength of the descriptors.
• Create a scale with more points.

Halo Effect
• When the impression formed in one
question carries into the next question
• Solution is to place one trait and several
items on each page.

Designing the Questionnaire
Good response rates can be achieved
with consistent control of questionnaire.
• Allow ample white space.
• Allow ample space to write or type in
responses.
• Make it easy for respondents to clearly
mark their answers.
• Be consistent in style.
Order of Questions
• Place most important questions first.
• Cluster items of similar content
together.
• Introduce less controversial questions
first.

Web Form Questionnaires
Controls (fields) used on Web forms:
• Single line text box.
• Scrolling text box, used for one or more
paragraphs of text.
• Check box for yes-no or true-false answers.
• Radio button for mutually exclusive yes-no or
true-false answers.
• Drop-down menu for selection from a list.
• Submit or Clear buttons.

Methods of Administering the
Questionnaire
Methods of administering the
questionnaire include:
• Convening all concerned respondents
together at one time.
• Personally administering the questionnaire.
• Allowing respondents to self-administer the
questionnaire.
• Mailing questionnaires.
• Administering over the Web or via email.
Electronically Submitting
Questionnaires
Administering a questionnaire
electronically has the following benefits:
• Reduced costs.
• Collecting and storing the results
electronically.

Prototyping, RAD, and
Extreme Programming
Prototyping
• Prototyping is an information-gathering
technique.
• Prototypes are useful in seeking user
reactions, suggestions, innovations, and
revision plans.
• Prototyping may be used as an
alternative to the systems development
life cycle.
Kendall & Kendall © 2005 Pearson Prentice Hall 6-155

Four Kinds of Prototypes
The four conceptions of prototypes are :
• Patched-up prototype.
• Nonoperational scale model.
• First-of-a-series.
• Prototype that contains only some of the
essential system features.

Patched-up Prototype
• This is a working model with all the
features but is inefficient.
• Users can interact with the system.
• Storage and retrieval of data may be
inefficient.
• May contain only basic features.

Nonoperational Scale Models
• A nonoperational scale mode is one that
is not operational, except for certain
features to be tested
• Prototype input and output

First-of-a-Series Prototype
• Pilot system is created.
• Prototype is an operation model.
• Useful when many installations of the
same information system are planned.
• An example is a system to be installed
in one location, tested and modified as
necessary, and later implemented in
other locations.

Selected Features Prototype
• An operational model includes some,
but not all, of the final system features.
• With the acceptance of these features,
later essential features are added.
• Some menu items are available.
• System is built in modules.
• These are part of the actual system.
Prototyping As an Alternative
to the Systems Life Cycle
• Two main problems with the SDLC:
• Extended time required to go through the
development life cycle.
• User requirements change over time.
• Prototyping may be used as an alternative.

Prototype Development
Guidelines
Guidelines for developing a prototype
are:
• Work in manageable modules.
• Build the prototype rapidly.
• Modify the prototype in successive
iterations.
• Stress the user interface.

Prototype Disadvantages
• Managing the prototyping process is
difficult because of its rapid, iterative
nature.
• Incomplete prototypes may be regarded
as complete systems.

Prototype Advantages
• Potential for changing the system early
in its development
• Opportunity to stop development on an
unworkable system
• Possibility of developing a system that
closely addresses users needs and
expectations

Prototype Evaluation – The User‟s
Role
• The user‟s role is honest involvement.

• Three ways the user is involved:
• Experimenting with the prototype.
• Giving open reactions to the prototype.
• Suggesting additions to and/or deletions
from the prototype.

Rapid Application Development
(RAD)
RAD, or rapid application development,
is an object-oriented approach to
systems development that includes a
method of development as well as
software tools.

RAD Phases
• The three broad phases to RAD are :
• Requirements planning.
• RAD design workshop.
• Implementation.

RAD Phases
Insert Figure 8.7 here
NOTE: Confirm with author which figure

should be inserted!

Requirements Planning Phase
• Users and analysts meet to identify
objectives of the application or system
• Oriented toward solving business
problems

RAD Design Workshop
• Design and refine phase.
• Use group decision support systems to help users
agree on designs.
• Programmers and analysts can build and show
visual representations of the designs and workflow
to users.
• Users respond to actual working prototypes.
• Analysts refine designed modules based on user
responses.

Implementation Phase
• As the systems are built and refined,
the new systems or partial systems are
tested and introduced to the
organization.
• When creating new systems, there is no
need to run old systems in parallel.

Martin Approach to RAD
The Martin approach to RAD includes
four phases:
• Requirements planning.
• User design.
• Construction.
• Cutover.

Martin Approach to RAD

RAD and the SDLC
• RAD tools are used to generate screens
and exhibit the overall flow of the
application.
• Users approve the design and sign off
on the visual model.
• Implementation is less stressful because
users helped to design the business
aspects of the system.

When to Use RAD
RAD is used when:
• The team includes programmers and
analysts who are experienced with it.
• There are pressing reasons for speeding up
application development.
• The project involves a novel ecommerce
application and needs quick results.
• Users are sophisticated and highly engaged
with the goals of the company.

Disadvantages of RAD
• May try and hurry the project too much
• Loosely documented

Extreme programming (XP) takes good
systems development practices to the
extreme.

Four Values of Extreme
Programming
The four values of extreme

programming are:
• Communication.
• Simplicity.
• Feedback.
• Courage.

Five XP Principles
The five XP principles are:
• Providing rapid feedback.
• Assuming simplicity.
• Changing incrementally.
• Embracing change.
• Encouraging quality work.

Five XP Principles

Four Basic Activities of XP
The four basic activities of XP are:
• Coding.
• Testing.
• Listening, to the programming partner and
customer.
• Designing.

Four XP Resource Control
Variables
The four resource control variables in XP

are:
• Time.
• Cost.
• Scope.
• Quality.

Four XP Core Practices
The four XP core practices are:
• Short releases, work with the most
important features first.
• Having a 40-hour work week.
• Having an onsite customer.
• Pair programming with another
programmer.

XP Relationships

The phases of the XP development
process are:
• Exploration.
• Planning.
• Iterations to the first release.
• Productionizing.
• Maintenance.

XP Stories
• XP stories are a spoken interaction
between developers and users.
• It is not written communication.
• The goal is prevention of
misunderstanding or misinterpretations
of user requirements.

XP Lessons
The six lessons that can be drawn from
the XP development approach are:
• Short releases allow the system to evolve.
• Pair programming enhances overall quality.
• Onsite customers are mutually beneficial to
the business and the XP team.

XP Lessons
The six lessons that can be drawn from
the XP development approach
(continued)
• The 40-hour work week improves
worker effectiveness.
• Balanced resources and activities
support project goals.
• XP values are crucial to success.
XP Lessons

Agile Modeling
• Agile modeling is similar to XP.
• In addition to the values of
communication, simplicity feedback and
courage, has a fifth value of humility.

Agile Modeling (Continued)
• Agile modeling process is:
• Listen to user stories.
• Draw a logical workflow model.
• Create new user stories based on the
workflow.
• Develop some prototypes.
• Use feedback from the prototypes and
logical workflow to create physical model.

Scrum
• Scrum is an Agile approach that has an
emphasis on teamwork.
• Team success is of primary importance.
• Individual success is secondary.
• The team works within a strict time
frame.
• The project leader has some but not
much influence on detail.

Using Data Flow Diagrams
Data Flow Diagrams
• DFDs are one of the main methods
available for analyzing data-oriented
systems.
• DFDs emphasize the logic underlying
the system.
• The systems analysts can put together
a graphical representation of data
movement through the organization.

Advantages of the Data Flow
Diagram Approach
Four advantages over narrative
explanations of data movement:
• Freedom from committing to the technical
implementation too early.
• Understanding of the interrelationships of
systems and subsystems.
• Communicating current system knowledge
to users.
• Analysis of the proposed system.
Basic Symbols
Four basic symbols are:
• A double square for an external entity--a
source or destination of data.
• An arrow for movement of data from one
point to another.
• A rectangle with rounded corners for the
occurrence of transforming process.
• An open-ended rectangle for a data store.

Basic Symbols

External Entities
• Represent people or organizations
outside of the system being studied
• Shows the initial source and final
recipient of data and information
• Should be named with a noun,
describing that entity
Customer

External Entities (Continued)
• External entities may be:
• A person, such as CUSTOMER or
STUDENT.
• A company or organization, such as BANK
or SUPPLIER.
• Another department within the company,
such as ORDER FULFILLMENT.
• Another system or subsystem, such as the
INVENTORY CONTROL SYSTEM.

Processes
• Represent either: 1 2
• A whole system Add New Customer
Inquiry
• A subsystem
Customer Subsystem
• Work being done, an activity

• Names should be in the form verb-
adjective-noun
• The exception is a process that represents
an entire system or subsystem.

Data Stores
• Name with a noun, describing the data
• Data stores are usually given a unique
reference number, such as D1, D2, D3.
• Include any data stored, such as:
• A computer file or database.
• A transaction file .
• A set of tables . D1 Customer
Master
• A manual file of records.

New Customer
Data Flow Customer Record
• Data flow shows the data about a person,

place, or thing that moves through the
system.
• Names should be a noun that describes the
data moving through the system.
• Arrowhead indicates the flow direction.
• Use double headed-arrows only when a
process is reading data and updating the data
on the same table or file.

Developing Data Flow
Diagrams
Use the following guidelines:
• Create the context level diagram, including all
external entities and the major data flow to or
from them.
• Create Diagram 0 by analyzing the major activities
within the context process.
• Include the external entities and major data stores.
• Create a child diagram for each complex process
on Diagram 0.

Creating Data Flow Diagrams
Detailed data flow diagrams may be
developed by:
• Making a list of business activities.
• Analyzing what happens to an input data
flow from an external entity.
• Analyzing what is necessary to create an
output data flow to an external entity.

Creating Data Flow Diagrams
Detailed data flow diagrams may be

developed by (continue):
• Examining the data flow to or from a data
store.
• Analyzing a well-defined process for data
requirements and the nature of the
information produced.
• Noting and investigating unclear areas.

Data Flow Diagram Levels
• Data flow diagrams are built in layers.
• The top level is the Context level.
• Each process may explode to a lower
level.
• The lower level diagram number is the
same as the parent process number.
• Processes that do not create a child
diagram are called primitive.

Context-Level Data Flow
Diagram
• It contains only one process,
representing the entire system.
• The process is given the number zero.
• All external entities are shown on the
context diagram as well as major data
flow to and from them.
• The diagram does not contain any data
stores.

DFD Levels
• Insert Figure 4.3 here
NOTE: confirm correct figure with

author.

Diagram 0
• Diagram 0 is the explosion of the
context level diagram.
• It should include up to 7 or 9 processes.
• Any more will result in a cluttered diagram.
• Processes are numbered with an
integer.
• The major data stores and all external
entities are included on Diagram 0.

Child Diagrams
• Each process on diagram zero may be
exploded to create a child diagram.
• Each process on a lower-level diagram may
be exploded to create another child diagram.
• These diagrams found below Diagram 0 are
given the same number as the parent
process.
• Process 3 would explode to Diagram 3.

3.2 5.2.7
Edit Calculate
Customer Customer
Discount
Child Diagrams (Continued)

• Each process is numbered with the
parent diagram number, a period, and a
unique child diagram number.
• Examples are:
• 3.2 on Diagram 3, the child of process 3.
• 5.2.7 on Diagram 5.2, child of process 5.2.
• On Diagram 3, the processes would be
numbered 3.1, 3.2, 3.3 and so on.
• External entities are usually not shown
on the child diagrams below Diagram 0.
• If the parent process has data flow
connecting to a data store, the child
diagram may include the data store as
well.

• A lower-level diagram may contain data
stores not shown on the parent
process, such as:
• A file containing a table of information
(such as a tax table).
• A file linking two processes on the child
diagram.
• Minor data flow, such as an error line,
may be included on a child diagram.
• An interface data flow is data that are
input or output from a child diagram
that matches the parent diagram data
flow.
• Processes that do not create a child
diagram are called primitive processes.
• Logic is written for these processes.

Data Flow Diagram Errors
• The following conditions are errors that
occur when drawing a data flow
diagram:
• A process with only input data flow or
only output data flow from it.
1 2
Add Add
New New
Customer Customer

(Continued)
• Data stores or external entities are

connected directly to each other, in any
combination.
Customer D1 Customer
Vendor D2 Vendor Master

(Continued)
• Incorrectly labeling data flow or objects
• Examples are:
• Labels omitted from data flow or objects.
• Data flow labeled with a verb.
• Processes labeled with a noun.
• Too many processes on a data flow
diagram.
• Nine is the suggested maximum.
(Continued)
• Omitting data flow from the diagram
• Unbalanced decomposition between a
parent process and a child diagram
• The data flow in and out of a parent
process must be present on the child
diagram.

Logical Data Flow Diagrams
• Logical data flow diagrams show how
the business operates.
• They have processes that would exist
regardless of the type of system
implemented.

Data Flow Diagram
Progression
The progression of creating data flow
diagrams is:
• Create a logical DFD of the current system.
• Next add all the data and processes not in
the current system that must be present in
the new system.
• Finally derive the physical data flow
diagram for the new system.

Data Flow
Diagram
Progression

Logical Data Flow Diagrams
Advantages
Advantages of logical DFDs are:
• Better communication with users.
• More stable systems, since the design is
based on a business framework.
• Increased understanding of the business
by analysts.
• The system will have increased flexibility
and be easier to maintain.
• Elimination of redundancy.
Physical Data Flow Diagrams
Physical data flow diagrams show how the
system operates or how the new system will
be implemented.
• Physical data flow diagrams include:
• Clarifying which processes are manual and which
are automated.
• Describing processes in greater detail.
• Sequencing processes in the order they must be
executed.

Physical Data Flow Diagrams
Physical data flow diagrams include
(continued):
• Temporary data stores and transaction
files.
• Specifying actual document and file names.
• Controls to ensure accuracy and
completeness.

CRUD
• Physical data flow diagrams include
processes for adding, reading,
changing, and deleting records.
• CRUD is an acronym for Create, Read,
Update, Delete.
• A CRUD matrix shows which programs
or processes add, read, update, or
delete master file records.

Transaction Files
• Master or transaction database tables or
files are used to link all processes that
operate at different times.
• They are required to store the data
from the process that creates the data
to the process that uses the data.

Triggers and Events
• An input flow from an external entity is
sometimes called a trigger, since it
starts activities.
• Events cause the system to do
something.
• An approach used to create a data flow
fragment is to analyze events, which
are summarized in an event table.

Event 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 unique activity and is used to create
one process on the data flow diagram.

Use Case and Data Flow
Diagrams
• A use case is another approach used to
develop a data flow diagram.
• A use case is used to create a data flow
diagram by providing a framework for
obtaining processes, input, output, and
data stores required for user activities.
• A use case shows the steps performed
to accomplish a task.

Use Case
The major sections of a use case are:
• Use case name.
• Description.
• Trigger.
• Trigger type.
• Input name and source.
• Output name and destination.
• Steps performed.
• Information required for each step.

Partitioning
• Partitioning is the process of analyzing
a data flow diagram and deriving a
series of manual procedures and
computer programs.
• A dashed line is drawn around a group
of processes that are included in each
computer program or manual
procedure.
Reasons for Partitioning
• The reasons for partitioning a data flow
diagram into separate computer
programs are:
• Different user groups should have different
programs.
• Processes that execute at different times
must be in separate programs.
• Processes may be separated into different
programs for security.

Reasons for Partitioning
(Continued)
• Similar tasks may be included in the
same program.
• Several batch processes may be
included in the same program for
efficiency.
• Several processes may be included in
the same program or job stream for
consistency of data.

Partitioning Web Sites
Web sites are partitioned into pages.
• Improves speed of processing
• Easier Web page maintenance
• Different pages when reading different
data
• Partitioned for security, separating pages
using a secure connection from those that
do not

Communicating Using
Data Flow Diagrams
Data flow diagrams can be used for

several different purposes:
• Unexploded data flow diagrams are useful
to identify information requirements.
• Meaningful labels should be used for good
communication.

Analyzing Systems
Using Data Dictionaries
Data Dictionary
• Data dictionary is a main method for
analyzing the data flows and data
stores of data-oriented systems.
• The data dictionary is a reference work
of data about data (metadata).
• It collects, coordinates, and confirms
what a specific data term means to
different people in the organization.

Reasons for Using a Data
Dictionary
The data dictionary may be used for the
following reasons:
• Provide documentation.
• Eliminate redundancy.
• Validate the data flow diagram.
• Provide a starting point for developing
screens and reports.
• To develop the logic for DFD processes.
The Repository
• A data repository is a large collection of
project information.
• It includes:
• Information about system data.
• Procedural logic.
• Screen and report design.
• Relationships between entries.
• Project requirements and deliverables.
• Project management information.

Data Dictionary and
Data Flow Diagram

Data Dictionary Contents
Data dictionaries contain:
• Data flow.
• Data structures.
• Elements.
• Data stores.

Defining Data Flow
• Each data flow should be defined with
descriptive information and its
composite structure or elements.
• Include the following information:
• ID - identification number.
• Label, the text that should appear on the
diagram.
• A general description of the data flow.
Defining Data Flow
(Continued)
• The source of the data flow
• This could be an external entity, a process, or a
data flow coming from a data store.
• The destination of the data flow
• Type of data flow, either:
• A record entering or leaving a file.
• Containing a report, form, or screen.
• Internal - used between processes.

Defining Data Flow
(Continued)
• The name of the data structure or
elements
• The volume per unit time
• This could be records per day or any other unit
of time.
• An area for further comments and
notations about the data flow

Data Flow Example
Name Customer Order
Description Contains customer order information and is used
to update the customer master and item files and
to produce an order record.
Source Customer External Entity
Destination Process 1, Add Customer Order
Type Screen
Data Structure Order Information
Volume/Time 10/hour
Comments An order record contains information for one
customer order. The order may be received by
mail, fax, or by telephone.
Defining Data Structures
• Data structures are a group of smaller
structures and elements.
• An algebraic notation is used to
represent the data structure.

Algebraic Notation
The symbols used are:
• Equal sign, meaning “consists of”.
• Plus sign, meaning "and”.
• Braces {} meaning repetitive elements, a
repeating element or group of elements.
• Brackets [] for an either/or situation.
• The elements listed inside are mutually
exclusive.
• Parentheses () for an optional element.
Repeating Groups
• A repeating group may be:
• A sub-form.
• A screen or form table.
• A program table, matrix, or array.
• There may be one repeating element or
several within the group.

Repeating Groups (Continued)
• The repeating group may have:
• Conditions.
• A fixed number of repetitions.
• Upper and lower limits for the number of
repetitions.

Physical and Logical Data
Structures
• Data structures may be either logical or
physical.
• Logical data structures indicate the
composition of the data familiar to the
user.

Physical Data Structures
• Include elements and information
necessary to implement the system
• Additional physical elements include:
• Key fields used to locate records.
• Codes to indicate record status.
• Codes to identify records when multiple
record types exist on a single file.
• A count of repeating group entries.

Data Structure Example
Customer Order = Customer Number +
Customer Name +
Address +
Telephone +
Catalog Number +
Order Date +
{Order Items} +
Merchandise Total +
(Tax) +
Shipping and Handling +
Order Total +
Method of Payment +
(Credit Card Type) +
(Credit Card Number) +
(Expiration Date)
Structural Records
• A structure may consist of elements or
smaller structural records.
• These are a group of fields, such as:
• Customer Name.
• Address.
• Telephone.
• Each of these must be further defined
until only elements remain.

General Structural Records
• Structural records and elements that are used
within many different systems should be
given a non-system-specific name, such as
street, city, and zip.
• The names do not reflect a functional area.
• This allows the analyst to define them once
and use in many different applications.

Structural Record Example
Customer Name = First Name +
(Middle Initial) +
Last Name
Address = Street +
(Apartment) +
City +
State +
Zip +
(Zip Expansion) +
(Country)
Telephone = Area code +

Local number
Defining Elements
• Data elements should be defined with
descriptive information, length and type
of data information, validation criteria,
and default values.
• Each element should be defined once in
the data dictionary.

Defining Elements (Continued)
• Attributes of each element are:
• Element ID. This is an optional entry that
allows the analyst to build automated data
dictionary entries.
• The name of the element, descriptive and
unique
• It should be what the element is commonly
called in most programs or by the major user of
the element.

• Aliases, which are synonyms or other
names for the element
• These are names used by different users
within different systems
• Example, a Customer Number may be
called a:
• Receivable Account Number.
• Client Number.

• A short description of the element
• Whether the 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
some logic.
• The length of an element

Determining Element Length
What should the element length be?
• Some elements have standard lengths,
such as a state abbreviation, zip code, or
telephone number.
• For other elements, the length may vary
and the analyst and user community must
decide the final length.

(Continued)
• Numeric amount lengths should be
determined by figuring the largest number
the amount will contain and then allowing
room for expansion.
• Totals should be large enough to
accommodate the numbers accumulated
into them.
• It is often useful to sample historical data
to determine a suitable length.
Percent of data that will

Element Length fit within the length
Last Name 11 98%

First Name 18 95%
Company Name 20 95%
Street 18 90%
City 17 99%

Data Truncation
• If the element is too small, the data will
be truncated.
• The analyst must decide how this will
affect the system outputs.
• If a last name is truncated, mail would
usually still be delivered.
• A truncated email address or Web
address is not usable.

Data Format
• The type of data, either numeric, date,
alphabetic or alphanumeric or other
microcomputer formats
• Storage type for numeric data
• Mainframe: packed, binary, display.
• Microcomputer (PC) formats.
• PC formats depend on how the data will be used,
such as Currency, Number, or Scientific.

Personal Computer Formats
Bit - A value of 1 or 0, a true/false value
Char, varchar, text - Any alphanumeric character
Datetime, smalldatetime - Alphanumeric data, several formats
Decimal, numeric - Numeric data that is accurate to the least significant digit
Can contain a whole and decimal portion
Float, real - Floating point values that contain an approximate decimal value
Int, smallint, tinyint - Only integer (whole digit) data
Money, smallmoney - Monetary numbers accurate to four decimal places
Binary, varbinary, image - Binary strings (sound, picture, video)
Cursor, timestamp, uniqueidentifier - A value that is always unique
within a database

Defining Elements - Format
• Input and output formats should be included,
using coding symbols:
• Z - Zero suppress.
• 9 – Number.
• X – Character.
• X(8) - 8 characters.
• . , - Comma, decimal point, hyphen.
• These may translate into masks used to
define database fields.

Defining Elements - Validation
• Validation criteria must be defined.
• Elements are either:
• Discrete, meaning they have fixed values.
• Discrete elements are verified by checking the
values within a program.
• They may search a table of codes.
• Continuous, with a smooth range of values.
• Continuous elements are checked that the data
is within limits or ranges.

Defining Elements
• Include any default value the element
may have
• The default value is displayed on entry
screens
• Reduces the amount of keying
• Default values on GUI screens
• Initially display in drop-down lists
• Are selected when a group of radio buttons are
used
• An additional comment or remarks area.
• This might be used to indicate the
format of the date, special validation
that is required, the check-digit method
used, and so on.

Data Element Example
Name Customer Number
Alias Client Number
Alias Receivable Account Number
Description Uniquely identifies a customer that has made any business
transaction within the last five years.
Length 6
Input Format 9(6)
Output Format 9(6)
Default Value
Continuous/Discrete Continuous
Type Numeric
Base or Derived Derived
Upper Limit <999999
Lower Limit >18
Discrete Value/Meaning
Comments The customer number must pass a modulus-11 check-digit test.
Defining Data Stores
• Data stores contain a minimal of all
base elements as well as many derived
elements.
• Data stores are created for each
different data entity; that is, each
different person, place, or thing being
stored.

Defining Data Stores
(Continued)
• Data flow base elements are grouped
together and a data store is created for
each unique group.
• Since a data flow may only show part of
the collective data, called the user view,
you may have to examine many
different data flow structures to arrive
at a complete data store description.
Data Store Definition
• The Data Store ID
• The Data Store Name, descriptive and
unique
• An Alias for the file
• A short description of the data store
• The file type, either manual or
computerized

(Continued)
• If the file is computerized, the file format
designates whether the file is a database file
or the format of a traditional flat file.
• The maximum and average number of
records on the file
• The growth per year
• This helps the analyst to predict the amount of
disk space required.

(Continued)
• The data set name specifies the table or
file name, if known.
• In the initial design stages, this may be left
blank.
• The data structure should use a name
found in the data dictionary.

Data Store Definition - Key
Fields
• Primary and secondary keys must be
elements (or a combination of
elements) found within the data
structure.
• Example: Customer Master File
• Customer Number is the primary key,
which should be unique.
• The Customer Name, Telephone, and Zip
Code are secondary keys.

Data Store Example - Part 1
ID D1
Name Customer Master
Alias Client Master
Description Contains a record for each customer
File Type Computer
File Format Database
Record Size 200
Maximum Records 45,000
Average Records 42,000
Percent Growth/Year 6%

Data Store Example - Part 2
Data Set/Table Name Customer
Copy Member Custmast
Data Structure Customer Record
Primary Key Customer Number
Secondary Keys Customer Name, Telephone, Zip Code
Comments The Customer Master file records are
copied to a history file and purged if the customer has not
purchased an item within the past five years. A customer
may be retained even if he or she has not made a purchase
by requesting a catalog.

Data Dictionary and Data Flow
Diagram Levels
• Data dictionary entries vary according
to the level of the corresponding data
flow diagram.
• Data dictionaries are created in a top-
down manner.
• Data dictionary entries may be used to
validate parent and child data flow
diagram level balancing.

Data Dictionary and
(Continued)
• Whole structures, such as the whole
report or screen, are used on the top
level of the data flow diagram.
• Either the context level or diagram zero
• Data structures are used on
intermediate-level data flow diagram.
• Elements are used on lower-level data
flow diagrams.

Data Dictionary and

Creating Data Dictionaries
1. Information from interviews and JAD
sessions is summarized on Input and
Output Analysis Forms.
• This provides a means of summarizing
system data and how it is used.
2. Each structure or group of elements
is analyzed.

(Continued)
• 3. Each element should be analyzed by
asking the following questions:
• Are there many of the field?
• If the answer is yes, indicate that the field is a
repeating field using the { } symbols.
• Is the element mutually exclusive of
another element?
• If the answer is yes, surround the two fields
with the [ | ] symbols.

(Continued)
• Is the field an optional entry or optionally
printed or displayed?
• If so, surround the field with parenthesis ( ).
• 4. All data entered into the system must
be stored.
• Create one database table or file for each
different type of data that must be stored.
• Add a key field that is unique to each
table.

Determining Data Store
Contents
• Data stores may be determined by
analyzing data flows.
• Each data store should consist of
elements on the data flows that are
logically related, meaning they describe
the same entity.

Maintaining the Data
Dictionary
• To have maximum power, the data
dictionary should be tied into other
programs in the system.
• When an item is updated or deleted
from the data dictionary it is
automatically updated or deleted from
the database.

Using the Data Dictionary
Data dictionaries may be used to:
• Create reports, screens, and forms.
• Generate computer program source code.
• Analyze the system design for completion
and to detect design flaws.

Creating Reports, Screens,
Forms
To create screens, reports, and forms:
• Use the element definitions to create fields.
• Arrange the fields in an aesthetically
pleasing screen, form, or report, using
design guidelines and common sense.
• Repeating groups become columns.
• Structural records are grouped together on
the screen, report, or form.

Data Dictionary Analysis
• The data dictionary may be used in
conjunction with the data flow diagram
to analyze the design, detecting flaws
and areas that need clarification.

(Continued)
• Some considerations for analysis are:
• All base elements on an output data flow
must be present on an input data flow to
the process producing the output.
• Base elements are keyed and should never
be created by a process.

(Continued)
• A derived element should be output from
at least one process that it is not input
into.
• The elements that are present on a data
flow into or coming from a data store must
be contained within the data store.

Extensible Markup Language
(XML)
• XML is used to exchange data between

businesses.
• An XML document may be transformed
into different formats.
• The transformation may limit the data
seen by a user.
• XML may be sorted, filtered, and
translated.

Using Data Dictionaries to
Create XML
• The data dictionary is an ideal starting

point for developing XML.
• Data names are stored within tags, a
less than and greater than symbol.
• <customer> or <lastName>
• The data dictionary is organized using
structures, which are included in XML.

XML Document Type Definition
(DTD)
• A DTD is used to ensure that the XML

data conforms to the order and type of
data specified in the DTD.
• DTD‟s may be created using the data
dictionary.

SAD-1to8

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SAD-1to8

Загружено:

Авторское право:

Доступные форматы

Assuming the Role of the

Kendall & Kendall 2005 Pearson Prentice Hall 1-2

Kendall & Kendall 2005 Pearson Prentice Hall 1-3

Kendall & Kendall 2005 Pearson Prentice Hall 1-4

Kendall & Kendall 2005 Pearson Prentice Hall 1-5

Kendall & Kendall 2005 Pearson Prentice Hall 1-8

Kendall & Kendall 2005 Pearson Prentice Hall 1-9

Kendall & Kendall 2005 Pearson Prentice Hall 1-10

Kendall & Kendall 2005 Pearson Prentice Hall 1-12

Kendall & Kendall 2005 Pearson Prentice Hall 1-13

Kendall & Kendall 2005 Pearson Prentice Hall 1-14

Kendall & Kendall 2005 Pearson Prentice Hall 1-15

Kendall & Kendall 2005 Pearson Prentice Hall 1-16

Kendall & Kendall 2005 Pearson Prentice Hall 1-18

Kendall & Kendall 2005 Pearson Prentice Hall 1-19

Kendall & Kendall 2005 Pearson Prentice Hall 1-20

Kendall & Kendall 2005 Pearson Prentice Hall 1-21

Kendall & Kendall 2005 Pearson Prentice Hall 1-22

Kendall & Kendall 2005 Pearson Prentice Hall 1-23

Kendall & Kendall 2005 Pearson Prentice Hall 1-24

Kendall & Kendall 2005 Pearson Prentice Hall 1-25

Kendall & Kendall 2005 Pearson Prentice Hall 1-26

Kendall & Kendall 2005 Pearson Prentice Hall 1-28

Kendall & Kendall 2005 Pearson Prentice Hall 1-30

Kendall & Kendall 2005 Pearson Prentice Hall 1-31

Kendall & Kendall 2005 Pearson Prentice Hall 1-32

Kendall & Kendall 2005 Pearson Prentice Hall 1-33

Kendall & Kendall 2005 Pearson Prentice Hall 1-34

Kendall & Kendall 2005 Pearson Prentice Hall 1-36

Kendall & Kendall 2005 Pearson Prentice Hall 1-38

Kendall & Kendall 2005 Pearson Prentice Hall 1-39

Kendall & Kendall 2005 Pearson Prentice Hall 1-40

Kendall & Kendall 2005 Pearson Prentice Hall 1-41

Kendall & Kendall 2005 Pearson Prentice Hall 1-42

Kendall & Kendall 2005 Pearson Prentice Hall 1-43

Kendall & Kendall 2005 Pearson Prentice Hall 2-45

Kendall & Kendall 2005 Pearson Prentice Hall 2-47

Kendall & Kendall 2005 Pearson Prentice Hall 2-48

Kendall & Kendall 2005 Pearson Prentice Hall 2-49

Kendall & Kendall 2005 Pearson Prentice Hall 2-50

Kendall & Kendall 2005 Pearson Prentice Hall 2-51

Kendall & Kendall 2005 Pearson Prentice Hall 2-52

Kendall & Kendall 2005 Pearson Prentice Hall 2-53

Kendall & Kendall 2005 Pearson Prentice Hall 2-55

Kendall & Kendall 2005 Pearson Prentice Hall 2-56

Kendall & Kendall 2005 Pearson Prentice Hall 2-57

Kendall & Kendall 2005 Pearson Prentice Hall 2-58

Kendall & Kendall 2005 Pearson Prentice Hall 2-59

Kendall & Kendall 2005 Pearson Prentice Hall 2-60

Kendall & Kendall 2005 Pearson Prentice Hall 2-61

Kendall & Kendall 2005 Pearson Prentice Hall 2-62

Kendall & Kendall 2005 Pearson Prentice Hall 2-63

Kendall & Kendall 2005 Pearson Prentice Hall 2-64

Kendall & Kendall 2005 Pearson Prentice Hall 2-65

Kendall & Kendall 2005 Pearson Prentice Hall 2-66

Kendall & Kendall 2005 Pearson Prentice Hall 2-67

Kendall & Kendall 2005 Pearson Prentice Hall 2-68

Kendall & Kendall 2005 Pearson Prentice Hall 2-69

Kendall & Kendall 2005 Pearson Prentice Hall 2-71

Kendall & Kendall 2005 Pearson Prentice Hall 2-72

Kendall & Kendall 2005 Pearson Prentice Hall 2-73

Kendall & Kendall 2005 Pearson Prentice Hall 3-76