Chapter 1 Introduction to Systems Design and Analysis Systems Analysis and Design Kendall and...

Chapter 1Introduction to Systems Design and Analysis

Systems Analysis and DesignKendall and Kendall

Sixth Edition

1-2

Readings & Major Topics

ReadingsChapter 1 (p. 1) in the textbook

Major TopicsInformation systemsSDLC (Systems Development Life

Cycle)Phases of analysis and designCASE tools

1-3

Information

What is information? Domain dependent

Facts, concepts, or instructions; any sort of knowledge or supposition which can be communicated.

Organizational resource Must be managed as carefully as other resources

(e.g., raw material, labor) Costs are associated with information processing

Production, distribution, security, storage, retrieval, …

Information processing must be managed to take full advantage of its potential

1-4

Systems Analysis & Design

GoalsAnalyze data input, processing or

transforming data, data storage, and information output within the context of a particular business

Analyze, design, and implement improvements in the functioning of a business via the use of computerized information systems

1-5

How can we Analyze and Design Systems?

Intuitive approachPros and Cons?

Systematic approachPros and cons?

1-6

Systems Analysis and Design in this Course

Systematic approach to identifying problems, opportunities, and objectives; analyzing the information flows in organizations; and designing computerized information systems to solve a problem

1-7

Systems Analyst

Performs systems analysis and design

Assesses how businesses function by examining the inputting and processing of data and the outputting of information with the intent of improving organizational processes

1-8

Different Types of Systems Analysts

Two major typesOutside consultants to businesses

Hired specifically to address information systems issues within a business

Supporting experts (within a business you are regularly employed)

Not a full-blown systems project, but rather entails a small modification or decision affecting a single department

Your role as a systems analyst: agent of changeCatalyst for change (i.e., improvements to the

business that can be done via information systems)

1-9

Interactions of a Systems Analyst

A systems analyst interacts with users at different levels in the organizationUser managersOperations workersSystems managersSystems designersProgrammers….

1-10

Qualities of a Systems Analyst

Analysts are problem solvers. Communication skills Analysts must be ethical with users and customers

ACM’s (Association of Computing Machinery) code of ethics… respect the privacy of othersGive comprehensive and thorough evaluations of

computer systems and their impacts, including analysis of possible risks

…..

1-11

Systems Development Life Cycle (SDLC)

SDLC is a systematic approach to solving business problems

It is divided into seven phasesEach phase has unique activitiesA phase is never accomplished as a

separate phaseSeveral activities can occur

simultaneouslyActivities may be repeated

1-12

Phase 1: Identifying problems, opportunities, and objectives

IdentifyingProblems: don’t want to address the wrong

problemsOpportunities: situations that can be improved Objectives: how can the organization reach its

objectives via computerized IS Personnel involved

AnalystUser managersSystems managers

1-13

Phase 2: Determining Information Requirement

Understand how the business functions and have complete information on the people, goals, data, and procedures Interview management, operations personnel Gather systems/operating documents Use questionnaires Observe the system and personnel involved

Learn the details of the current system functions: who (people involved), what (business activities), where (environment in which the work takes place), when (timing), how (procedures), and the why (why is it done this way)

1-14

Phase 2: Determining Information Requirement (cont’d)

Personnel involvedAnalystUser managersOperations workersSystems managers

Information Analyst (phases 1 and 2)

1-15

Phase 3: Analyzing Systems Needs

Analyzing system needs Create data flow diagrams Document procedural logic for data flow diagram

processes Complete the data dictionary Analyze structured decisions Make semistructured decisions (decisions taken

under risk) Prepare and present the system proposal Recommend the optimal solution to management

1-16

Phase 3: Analyzing Systems Needs (cont’d)

Analyst makes recommendations to managementManagement decide whether to

continue or notPersonnel involved

AnalystUser managersSystems managers

1-17

Phase 4: Designing the Recommended System

Accomplish the logical design of the information system Design the user interface

Design outputDesign input

Design files and/or database Design control and backup procedures Produce decision trees or tables Produce program specifications

1-18

Phase 4: Designing the Recommended System (cont’d)

Personnel involvedAnalystSystem designerUser managersOperations workersSystems managers

1-19

Phase 5: Developing and Documenting Software

Develop any original software that is neededDesign computer programs using structure

charts, Nassi-Schneiderman charts, and pseudocode

Walkthrough program designWrite computer programsDocument software with help files,

procedure manuals, and Web sites with Frequently Asked Questions (FAQs)

1-20

Phase 5: Developing and Documenting Software (cont’d)

Personnel involvedAnalystSystem designerProgrammersSystems managers

1-21

Phase 6: Testing and Maintaining the system

Testing and maintaining the system Test and debug computer programs Test the computer system Enhance system

Personnel involved Analyst System designer Programmers Systems management

1-22

System Maintenance

Maintenance: starts in phase 6 but carried out routinely throughout the life of the IS

System maintenance is Removing undetected errors, andEnhancing existing software

Time spent on maintenance typically ranges from 48-60 percent of total time

1-23

System Enhancements

Systems are enhanced for the following reasons:Adding additional features to the

systemBusiness and governmental

requirements change over timeTechnology, hardware, and software

are rapidly changing

1-24

Phase 7: Implementing and Evaluating the System

Implementing and evaluating the systemPlan conversion from the old system to the

new oneTrain usersPurchase and install new equipmentConvert files Install systemReview and evaluate system: whether the

intended users are indeed using the system

1-25

Phase 7: Implementing and Evaluating the System (cont’d)

Personnel involvedAnalystSystem designerProgrammersUser managersOperations workersSystems managers

1-26

CASE Tools

Computer-Aided Software Engineering (CASE)

CASE tools are automated, microcomputer-based software packages for systems analysis and design

Four reasons for using CASE tools are:To increase analyst productivityFacilitate communication among analysts and

usersProviding continuity between life cycle phasesTo assess the impact of maintenance

1-27

CASE Tool Categories

CASE tools may be divided into several categoriesUpper CASE (also called front-end CASE)

tools, used to perform analysis and designLower 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

1-28

Upper CASE

Upper CASE toolsCreate and modify the system designStore data in a project repositoryThe repository is a collection of

records, elements, diagrams, screens, reports, and other project information

These CASE tools model organizational requirements and define system boundaries

1-29

Lower CASE

Lower CASE tools generate computer source code from the CASE design

Source code may usually be generated in several languages

1-30

Lower CASE: Advantages of Generating Code

Time to develop new systems decreasesThe time to maintain generated code is less

than to maintain traditional systemsComputer programs may be generated in

more than one languageCASE design may be purchased from third-

party vendors and tailored to organizational needs

Generated code is free from program coding errors

1-31

Reverse Engineering

Reverse engineering is generating the CASE design from computer program code

Source code is examined, analyzed, and converted into repository entities

Uses Computer-Assisted Reengineering (CARE) software

1-32

Reverse Engineering Produces

Depending on the tool set used:Data structures and elements,

describing the files, records, and fieldScreen designs, if the program is onlineReport layouts for batch programsA structure chart showing the hierarchy

of the modules in the programDatabase design and relationships

1-33

Advantages of Reverse Engineering It has the following advantages:

Reduced system maintenance timeProgram documentation is produced for loosely

documented programsStructured programs may be generated from

unstructured, older programsFuture system maintenance is easier to

implementUnused portions of programs may be

eliminated

Chapter 2Information Gathering: Interactive Methods


Sixth Edition

4-35


ReadingsChapter 4 in the textbook (p. 89)

Major TopicsInterviewing techniquesJoint Application Design (JAD)Questionnaires

4-36

Information Gathering in SDLC

Phase 1 Identifying problems, opportunities,

and objectives

Phase 2 Determining information requirements

Phase 3 Analyzing systems needs

Phase 4 Designing the recommended system

Phase 5 Developing and documenting software

Phase 6 Testing and maintaining the system

Phase 7 Implementing and evaluating the

system

4-37

Information Gathering: Two Approaches

Interactive: talking with and listening to people in the organization through a series of carefully composed questions Example: interviewing

Unobtrusive: do not require the same degree of interactivity between analysts and users Example: observing

Our focus: Interactive methods Interviewing JAD Questionnaires

4-38

Interviewing

Important method for collecting data on information system requirements

Directed conversation with a specific purpose that uses Q&A format

Reveals information aboutInterviewee opinionsFeelings about the current state of the

systemOrganizational and personal goalsInformal procedures

4-39

Planning the Interview

Five steps in planning the interview areReading background materialEstablishing interview objectivesDeciding whom to interviewPreparing the intervieweeDeciding on question types and structure

4-40

Before the Interview

Contact the interviewee and confirm the interview

Dress appropriatelyArrive a little earlyAffirm that you are present and

ready to begin the interview

4-41

Recording the Interview

Interviews can be recorded with tape recorders or notes

Audio recording should be done with permission and understanding

4-42

Advantages of Audio Recording the Interview

Providing a completely accurate record of what each person said

Freeing the interviewer to listen and respond more rapidly

Allowing better eye contact and better rapport

Allowing replay of the interview for other team members

4-43

Disadvantages of Audio Recording the Interview

Possibly making the interviewee nervous and less apt to respond freely

Difficulty in locating important passages on a long tape

4-44

Note Taking During Interviews: Pros and Cons

ProsKeeping the interviewer alertAiding recall of important interview trendsShowing interviewer interest in the interview

ConsLosing vital eye contactLosing the train of conversationCausing excessive attention to facts and less

attention to feelings

4-45

Beginning the Interview

Shake handsRemind them of your name and

why you are thereTake out note pad or tape recorderMake sure tape recorder is working

correctly

4-46

Opening Questions

Start with pleasant conversationListen closely to early responses

Pick up on vocabularyLook for metaphors

“The accounting department is a zoo”“We’re one big family here”

4-47

During the Interview

The interview should not exceed 45 minutes to one hour

Make sure that you are understanding what the interviewee is telling you

Ask for definitions if needed

4-48

Closing the Interview

Always ask “Is there anything else that you would like to add?”

Ask whom you should talk with next

Set up any future appointmentsThank them for their time and

shake hands

4-49

Interview Report

Write as soon as possible after the interview

Provide an initial summary, then more detail

Review the report with the respondent

4-50

Question Types

There are two basic types of interview questions:Open-endedClosed

4-51

Open-Ended Questions

Allow interviewees to respond how they wish, and to what length they wish

E.g.: Once the data is submitted via the Web site, how is it processed?

Appropriate when the analyst is interested in breadth and depth of reply

4-52

Advantages of Open-Ended Questions

Putting the interviewee at easeAllowing the interviewer to pick up on

the interviewee's vocabularyProviding richness of detailRevealing avenues of further

questioning that may have gone untapped

Allows more spontaneityUseful if the interviewer is unprepared

4-53

Disadvantages of Open-Ended Questions

May result in too much irrelevant detail

Possibly losing control of the interviewMay take too much time for the

amount of useful information gainedPotentially seeming that the

interviewer is unpreparedPossibly giving the impression that the

interviewer is on a "fishing expedition”

4-54

Closed Interview Questions

Limit the number of possible responses

E.g.: On average, how many calls does the call center receive monthly?

Appropriate for generating precise, reliable data which is easy to analyze

4-55

Advantages of Closed Interview Questions

Saving interview timeEasily comparing interviewsGetting to the pointKeeping control of the interviewCovering a large area quicklyGetting to relevant data

4-56

Disadvantages of Closed Interview Questions

Boring for the intervieweeFailure to obtain rich detailMissing main ideasFailing to build rapport between

interviewer and interviewee

4-57

Bipolar Questions

Questions that may be answered with a ‘yes’ or ‘no’ or ‘agree’ or ‘disagree’

E.g.: Do you want to receive a printout of your account status every month?

E.g.: Do you agree or disagree that ecommerce on the Web lacks security?

4-58

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

E.g.: Please give an illustration of the security problems you’re experiencing with your online systems?

4-59

Tradeoffs: Open-ended and Closed Questions

Reliability of data Efficient use of time Precision of data Breadth and depth Interviewer skill required Ease of analysis

4-60

Question Pitfalls

Leading questions: imply an answer Tend to guide interviewees into responses apparently

desired by the interviewer Should be avoided to reduce bias and improve reliability

and validity E.g.: You agree with other managers that inventory control

should be computerized, don’t you?

Double-barreled questions: two questions in one Interviewees may answer only one question, leading to

difficulties in interpretation E.g.: What decisions are made during a typical day and

how do you make them?

4-61

Question Sequencing

There are three basic ways of structuring interviews:PyramidFunnelDiamond

4-62

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

4-63

Funnel Structure

Begins with generalized, open-ended questions

Concludes by narrowing the possible responses using closed questions

Provides an easy, non-threatening way to begin an interview

Is useful when the interviewee feels emotionally about the topic

4-64

Diamond Structure

A diamond-shaped structure begins in a very specific way

Then more general issues are examined

Concludes with specific questionsIs useful in keeping the interviewee's

interest and attention through a variety of questions

4-65

Joint Application Design (JAD)

Can replace a series of 1-on-1 interviews Allows the analyst to accomplish

requirements analysis and design the user interface with the users in a group setting

Systems analysts (SAs): passive role SAs Should be present May give expert opinions about any

disproportionate costs of solutions

4-66

Topics Discussed in JAD

Requirements analysis and user interface design But could be used at any appropriate phase

of SDLC Address topics such as

Planning, receiving, receipt processing/tacking, monitoring and assigning, processing, recording, sending, and evaluating

For each topic, ask: Who, what, how, where, and why

4-67

JAD Personnel

AnalystsUsers, executives, … (8 to 12)Observers (technical experts)A scribe: write down everythingA session leader

Senior person: visible symbol of organizational commitment

May be outside management consultant

4-68

Preparing a JAD Session

Two-to-four-day sessions offsiteIf possible, away from the organization, in

comfortable surroundingsMinimize the daily distractions and

responsibilities of the participants’ regular workUse of group decision support facilities (e.g.,

networked computers, projection system, …)

Make use everybody will be able to attendOrientation meeting (1/2 day) a week

before the workshop

4-69

When to Use JAD

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

4-70

Benefits of JAD

Time is saved, compared with traditional interviewing (15%)

Rapid development of systemsImproved user ownership of the

systemCreative idea production is improved

4-71

Drawbacks of Using JAD

Requires a large block of time 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

4-72

Questionnaires

Also called Surveys Respondent: person answering a

questionnaire (or survey) Useful in gathering information from

key organization members about Attitudes: what people say they want (in the

new system) Beliefs: what people think is actually true Behaviors: what organizational members do Characteristics: properties of people or

things

4-73

When to Use Questionnaires

Organization members are widely dispersed Many members are involved with the project Exploratory work is needed: quantify what

was found in interviewsHow widespread or limited an opinion expressed in

an interview really is Problem solving prior to interviews is

necessaryRaise important issues before interviews are

scheduled May be used in conjunction with interviews

Follow-up unclear questionnaire responses with interviews

Design questionnaires based on what was discovered in interviews

4-74

Question Types

Questions are designed as either Open-ended

Try to anticipate the response you will getWell suited for getting opinionsUseful in explanatory situationsUseful when it is impossible to list effectively all

possible responses to a question

ClosedUse when all the options may be listedWhen the options are mutually exclusive

4-75

Open-Ended vs. Closed Questions

Open-ended ClosedSlow Speed of completion Fast

High Exploratory nature Low

High Breadth and depth Low

Easy Ease of preparation Difficult

Difficult Ease of analysis Easy

4-76

Questionnaire Language

Simple: use the language of respondents whenever possible

Specific and short questionsFree of biasNot patronizing: avoid low-level language choicesTechnically accurateRight question to the right person: addressed to

those who are knowledgeableAppropriate for the reading level of the

respondent

4-77

Using Scales in Questionnaires

Assigning numbers or other symbols to an attribute/characteristic for the sake of measuring that attribute/characteristic

Devised to have respondents act as judges for the subject of the questionnaire

4-78

Measurement Scales

There are four different forms of measurement scales:NominalOrdinalIntervalRatio

4-79

Nominal Scales

Nominal scales are used to classify things into categories

What type of software do you use the most?

1 = Word Processor

2 = Spreadsheet

3 = Database

4 = An Email Program

4-80

Ordinal Scales

Allow classificationOrdinal scales also imply rank

orderingThe support staff of the Technical Support Group is:

1. Extremely Helpful

2. Very Helpful

3. Moderately Helpful

4. Not Very Helpful

5. Not Helpful At All

4-81

Interval Scales

An interval scale is used when the intervals are equal

There is no absolute zero

How useful is the support given by the Technical Support Group?

NOT USEFUL EXTREMELY

AT ALL USEFUL

1 2 3 4 5

4-82

Ratio Scales

The intervals between numbers are equal

Ratio scales have an absolute zero

Approximately how many hours do you spend on the Internet daily?

0 2 4 6 8

4-83

Guidelines for Using Scales

Use a ratio scale when intervals are equal and there is an absolute zero

Use an interval scale when intervals are equal but there is no absolute zero

Use an ordinal scale when the intervals are not equal but classes can be ranked

Use a nominal scale when classifying but not ranking

4-84

Validity and Reliability

Reliability: Consistency in responseGetting the same results if the same

questionnaire was administered again under the same conditions

Validity: Degree to which the question measures what the analyst intends to measure

4-85

Problems Associated With Poorly Constructed Scales

Leniency: caused by easy ratersCentral tendency: respondents rate

everything as averageHalo effect: impression formed in one

question carries into the next question

4-86

Questionnaire Format

Allow ample white spaceAllow enough space for responses to

be typed for open-ended questionsAsk respondents to clearly mark their

answersBe consistent in style

4-87

Order of Questions

Most important questions go firstSimilar topics should be clustered

togetherControversial questions should be

positioned after less controversial questions

4-88

Methods of Administering Questionnaires

Convening All concerned respondents together at one time

Personally administering the questionnaireAllowing respondents to self-administer

the questionnaireMailing questionnaires: supply deadlines,

instructions, and return postageAdministering over the Web or via email

Chapter 3Data Flow Diagrams


Sixth Edition

90



Major TopicsData flow diagram symbolsData flow diagram levelsCreating data flow diagramsPhysical and logical data flow

diagramsPartitioning

91

Data Flow Diagrams in SDLC


and objectives







system

92

Data Flow Diagrams (DFDs)

One of the main methods available for analyzing data-oriented systems

DFD: a graphical representation of data movement through the organizationProcesses

Transforming of data as it moves through a variety of processes within the enterprise

Inputs/outputsData storage

93

Why DFDs?

Freedom from committing to the technical implementation too early

Understanding of the interrelationships of systems and subsystems

Communicating current system knowledge to users

94

Basic Symbols in DFDs

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

95

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

96

External Entities (cont’d)

External entities may be A person, such as CUSTOMER or

STUDENTA company or organization, such as

BANK or SUPPLIERAnother department within the

company, such as ORDER FULFILLMENTAnother system or subsystem, such as

the INVENTORY CONTROL SYSTEM

97

Processes

Represent either:A whole systemA subsystemWork being done, an activity

Names should be in the form verb-adjective-nounThe exception is a process that

represents an entire system or subsystem

1

Add NewCustomer

2Customer

InquirySubsystem

98

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 databaseA transaction file A set of tables A manual file of records

D1 CustomerMaster

99

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 directionUse double headed-arrows only when a

process is reading data and updating the data on the same table or file

Customer Record

New Customer

100

Data Flow Diagram Levels

Data flow diagrams are built in levelsThe top level is the Context level DFDEach process may explode to a lower

levelThe lower level diagram number is the

same as the parent process numberProcesses that do not create a child

diagram are called primitive

101

Data Flow Diagram Levels (cont’d)

Different levels of DFDsOne (1) Context level DFDOne (1) Diagram 0One or more Child Diagrams

102

Context Level DFD

Contains only one process, representing the entire system to be designed/analyzed

Highest-level diagramOverview including basic inputs, the general

system, and basic outputs

The process is given the number zero (0) Includes all external entities as well as major

data flow to and from them The diagram does not contain any data

stores

103

Diagram 0

Diagram 0 is the explosion of the context level diagram (i.e., process 0)

Should include up 9 processesAny more will result in a cluttered diagram

Processes are numbered with an integerThe major data stores and all external

entities are included in Diagram 0

104

Child Diagrams

Each process on diagram zero may be (if not primitive) exploded to create a child diagram

Each process on a lower-level diagram may be (if not primitive) exploded to create another child diagram

A diagram found below Diagram 0 is given the same number as its parent processProcess 3 in Diagram 0 would explode to

Diagram 3

105

Child Diagrams (cont’d)

Each process is numbered with the parent diagram number, a period, and a unique child number

Examples are: On Diagram 3, the processes would be

numbered 3.1, 3.2, 3.3 and so on 3.2 on Diagram 3, a child of process 3 5.2.7 on Diagram 5.2, a child of process 5.2

3.2

EditCustomer

5.2.7

CalculateCustomerDiscount

106


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

107


A lower-level diagram may contain data stores not shown on the parent process, such asA 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 diagramHandling of exceptions is generally ignored

for the first two levels

108


Vertical Balancing ruleA child diagram cannot produce

output or receive input that the parent process does not also produce or receive

Must be respected while designing DFDs

109


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 processesLogic is written for these processes (will

be discussed in another chapter)

110

Data Flow Diagram Errors

A process with only input data flow or only output data flow from it

AddNew Customer

1AddNew Customer

2

111

Data Flow Diagram Errors (cont’d)

Data stores or external entities are connected directly to each other, in any combination

Customer D1 Customer

Vendor D2 Vendor Master

112


Incorrectly labeling data flow or objectsExamples are

Labels omitted from data flow or objectsData flow labeled with a verbProcesses labeled with a noun

Too many processes on a data flow diagramNine is the suggested maximum

113


Omitting data flow from the diagram

Unbalanced decomposition between a parent process and a child diagramThe data flow in and out of a parent

process must be present on the child diagram

114

Guidelines for Developing DFDs

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 processInclude the external entities and major

data storesCreate a child diagram for each complex

process on Diagram 0

115

Guidelines for Developing DFDs (cont’d)

Detailed DFDs (child or Diagram 0) 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 Examining the data flow to or from a data

store Unclear areas of a data flow diagram should

be noted and investigated

116

Event Driven DFDs

An input flow from an external entity is called a triggerIt starts processes

Events are activities that happen within the system

117

Event Driven DFDs (cont’d)

Another approach used to create a data flow fragmentAnalyze events, which are summarized

in an event table

Events are eitherExternal, coming from outside the

system, orTemporal, which occur at fixed times

118

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

119

DFD Progression

The progression of creating DFDs isCreate a logical DFD of the current

systemNext add all the data and processes

not in the current system which must be present in the new system

Finally derive the physical data flow diagram for the new system

120

Logical DFDs

Logical data flow diagrams show how the business operates

Represent features that would exist no matter what the physical means of doing business are.

Processes that would exist regardless of the type of system implemented

121

Logical DFDs Advantages

Better communication with usersMore stable systems, since the design

is based on a business frameworkIncreased understanding of the

business by analystsElimination of redundancy

122

Physical DFDs

Show how the system operates or how the new system will be implemented

Physical DFDs include Clarifying which processes are manual/automatic Describing processes in greater detail “Sequencing processes” to rearrange the order of

records “Validation processes” for ensuring accurate data input Intermediate data stores Actual document and file names Controls to ensure accuracy and completeness

123

CRUD Matrix

Physical DFDs include processes for adding, reading, changing, and deleting records

CRUD is an acronym for Create, Read, Update, Delete

A CRUD matrix shows which processes add, read, update, or delete master file records

124

Partitioning

Process of analyzing a DFD 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

125

Manual Procedures

Performed by peopleHave manual input and manual

outputComputer processing not used with

manual processes

126

Batch Processes

If the data flow into and out of a process is entirely computer information, the process is called a batch process

Batch processes do not require any human intervention

A job stream is several separate programs running back-to-back, usually a series of batch processes

127

User Interface

A user interface represents a screen, a data entry operation, a report, or some other means for persons to interact with a computer

It occurs when the data flow links a manual and an automated process

128

Reasons for Partitioning

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

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

129

Using DFDs

Unexploded data flow diagrams are useful to identify information requirements

Exploded data flow diagrams can be used for presentation, education, and gathering feedback information from users

DFDs may be used to analyze the system to ensure that the design is complete

DFDs are used to partition the system into programs

Data flow diagrams can be used for the system documentation

Chapter 4Analyzing SystemsUsing Data Dictionaries


Sixth Edition

131



Major TopicsData dictionary conceptsDefining data flowDefining data structuresDefining elementsDefining data stores

132

Data Dictionaries in SDLCPhase 1 Identifying

problems, opportunities, and objectives







system

133

Data Dictionary

Reference work of data about data (metadata)

Main method for analyzing data flows and data stores

Collects, coordinates, and confirms what a specific data term means to different people in the organization

134

Reasons for Using a Data Dictionary

Some reasons Provide documentation Eliminate redundancy Validate the data flow diagram Provide a starting point for developing

screens and reports Develop the logic for DFD processes

Automated dictionaries (CASE tools) Cross-reference data items

135

The Repository

A data repository is a large collection of project information

It includesInformation about system dataProcedural logicScreen and report designProject requirements and deliverablesProject management information (e.g.,

delivery schedules, achievements, …)

136

Data Dictionary Contents

Data dictionaries contain data aboutData flow

Data flow description form

Data structuresData Elements

Element description form

Data storesData store description form

137

Data Flow Description Form

Each data flow should be defined with descriptive information and it's composite structure or elements

Includes:ID - identification numberUnique name for the data flow: should

appear on the DFDA general description of the data flow

138

Data Flow Description Form (cont’d)

Includes: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 flowType of data flow, either

A record entering or leaving a file Containing a report, form, or screen Internal - used between processes

139

Data Flow Description Form (cont’d)

Includes:The name of the data structure or

elementsThe 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

140

Data Flow Description Form - Example

Name Customer OrderDescription Contains customer order information and is used

to update the customer master and item files and to produce an order record.

Source Customer External EntityDestination Process 1, Add Customer OrderType ScreenData Structure Order InformationVolume/Time 10/hourComments An order record contains information for one

customer order. The order may be received by mail, fax, or by telephone.

141

Defining Data Structures

Data structures are a group of smaller structures and elements

An algebraic notation is used to represent the data structure

142

Algebraic Notation

The symbols used areEqual sign, meaning “consists of”Plus sign, meaning "and”Braces {} meaning repetitive elements,

also called repeating groups or tablesBrackets [] for an either/or situation

The elements listed inside are mutually exclusive

Parentheses () for an optional element

143

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

The repeating group may have A fixed number of repetitions

12 {Monthly Sales} Upper and lower limits for the number of

repetitions {Order Line}5

1

144

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

Structural records and elements used within many different systems should be given a non-system-specific nameE.g.: street, city, and zip

145

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

146

Logical Data Structures

Data structures may be either logical or physical

Logical data structures indicate the composition of the data familiar to the user

147

Physical Data Structures

Include elements and information necessary to implement the system

Additional physical elements includeKey fields used to locate recordsCodes to indicate record statusCodes to identify records when multiple

record types exist on a single fileEtc.

148

Data Structure ExampleCustomer 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)

149

Element Description Forms

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

150

Element Description Forms - Attributes

Element ID. This is an optional entry that allows the analyst to build automated data dictionary entries

The name of the element, descriptive and uniqueIt should be what the element is

commonly called in most programs or by the major user of the element

151

Element Description Forms – Attributes (cont’d)

Aliases, which are synonyms or other names for the elementThese are names used by different users

within different systemsExample, a Customer Number may be

called a Client Number

A short description of the element

152

Element Description Forms – Attributes (cont’d)

Whether the element is base or derivedA base element is one that has been

initially keyed into the systemA derived element is one that is created

by a process, usually as the result of a calculation or some logic

153

Element Description Forms - Attributes (cont’d)

The length of an element 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 users must decide the final length 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

154


Percent of data that willElement Length fit within the length (US)

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

155


The length of an element (cont’d)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

156


The type of data Numeric, date, alphabetic or alphanumeric

or other microcomputer formats

Input and output formats should be included, using coding symbols:

Z – Leading Zeros or spaces9 - NumberX - Character

X(8) - 8 charactersEtc.

157


Validation criteriaDiscrete, meaning they have fixed

valuesDiscrete elements are verified by checking

the values within a programThey may search a table of codes

Continuous, with a smooth range of valuesContinuous elements are checked that the

data is within limits or ranges

158


Default valueThe default value is displayed on

entry screensReduces the amount of keying

CommentsThis might be used to indicate the

format of the date, special validation that is required, etc.

159

Data Element Example

Name Customer NumberAlias Client NumberAlias Receivable Account NumberDescription Uniquely identifies a customer that has made any business

transaction within the last five years.Length 6Input Format 9(6)Output Format 9(6)Default ValueContinuous/Discrete ContinuousType NumericBase or Derived DerivedUpper Limit <999999Lower Limit >18Discrete Value/Meaning Comments The customer number must pass a modulus-11 check-digit test.

160

Data Store Description Form

Data stores contain a minimal of all base elements as well as some derived elements

Data stores are created for each different data entity, that is, each different person, place, or thing being stored

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

161

Data Store Description Form - Attributes

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:

Manual or computerized If the file is computerized, the file format

designates whether the file is a database file or the format of a traditional flat file

162

Data Store Description Form – Attributes (cont’d)

The maximum and average number of records on the file

The growth per yearPredict the amount of disk space required

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

163

Data Store Description Form – Attributes (cont’d)

Primary and secondary keys must be elements (or a combination of elements) found within the data structureExample: Customer Master File

Customer Number is the primary key, which should be unique

The Customer Name, Telephone, and Zip Code are secondary keys

Comments

164

Data Store Example - Part 1

ID D1Name Customer Master FileAlias Client Master FileDescription Contains a record for each customerFile Type ComputerFile Format DatabaseRecord Size 200Maximum Records 45,000Average Records 42,000 Percent Growth/Year 6%

165

Data Store Example - Part 2

Data Set/Table Name CustomerCopy Member CustmastData Structure Customer RecordPrimary Key Customer NumberSecondary Keys Customer Name, Telephone, Zip CodeComments 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.

166

Data Dictionary and Data Flow Diagram Levels

Data dictionary entries vary according to the level of the corresponding DFD

Data dictionaries are created in a top-down manner Whole structures, such as the whole report or

screen, are used on the top level of the DFD Data structures are used on intermediate-level DFD Elements are used on lower-level data flow diagrams

Data dictionary entries may be used to validate parent and child DFD level balancing

167

Creating Data Dictionaries

1. Information from interviews and JAD sessions is summarized on Input and Output Analysis FormsThis provides a means of

summarizing system data and how it is used

2. Each structure or group of elements is analyzed

168


3. Each element should be analyzed by asking the following questions:A. Are there many of the field?

If the answer is yes, indicate that the field is a repeating field using the { } symbols

B. Is the element mutually exclusive of another element?If the answer is yes, surround the two

fields with the [ | ] symbols

169


C. 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 storedCreate one file or database file for each

different type of data that must be storedAdd a key field that is unique to each file

170

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

171

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

172

Using the Data Dictionary

Data dictionaries may be used toGenerate computer program source

codeCreate reports, screens, and formsAnalyze the system design for

completion and to detect design flaws

173

Creating Reports, Screens, Forms

To create screens, reports, and formsUse the element definitions to create

fieldsArrange the fields in an aesthetically

pleasing screen, form, or report, using design guidelines and common sense

Repeating groups become columnsStructural records are grouped together

on the screen, report, or form

174

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

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

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

Chapter 5Describing Process Specifications and Structured Decisions


Sixth Edition

176


Readings Chapter 9 in the textbook (page 283)

Major TopicsProcess specificationsDecision tables

Other Types of SpecificationsStructured EnglishDecision trees

177

Process Specification in SDLC


and objectives







system

178

Process Specifications

Process specifications (minispecs) are created for primitive processes and some higher level processes on a DFD

Documenting and analyzing the logic of structured decisionsStructured EnglishDecision treesDecision tables

179

Goals of Creating Process Specifications

Reduce process ambiguity

Obtain a precise description of what is accomplished

Validate the system design, including data flow diagrams and the data dictionary

180

No Process Specifications For

Physical input and/or output processes

Processes that represent simple data validation

Processes for which prewritten code already exists

181

Process Logic

Process descriptions may exist on a form or within a CASE tool repository

Process logic may be represented asStructured EnglishA decision tableA decision treeAny combination of the above

182

Process Specification Format

The process number, which must match the process ID on the data flow diagramThis allows an analyst to work or review any

process and easily locate the DFD containing the process

The process name, the same as displays within the process symbol on the DFD

A brief description of what the process accomplishes

183

Process Specification Format (cont’d)

A list of input and output data flow, using the names found on the data flow diagramData names used in the formulae or logic should

match the data dictionary, for consistency and good communication

An indication of the type of process Batch, online or manualAll online processes require screen designsAll manual processes should have well-defined

procedures for employees performing the process tasks

184

Process Specification Format (cont’d)

If the process has prewritten code for it, include the name of the subprogram or function

A reference to further information, such as a structured English description, a decision table or tree depicting the logic

List any unresolved issuesThese form the basis of the questions used

for a follow-up interview

185

Process Specification Example Part 1

Number 1Name Add Customer Order

Description Key and add the Customer Order.The order should be edited for correct information.Customer and Item master files are updated.

Input Data Flow Customer Order Form from the Customer Customer Record from data store D1, Customer Master File Item Record from data store D2, Item Master File

186

Process Specification Example Part 2

Output Data Flow Pending Order to data store D3, Order File Backordered Item Record to the Inventory Control Department Updated Customer and Item records

Type of process Online

187

Decision Tables

Decision tables provide a way to examine, describe, and document decisions using a table

They are used toDescribe the conditionsIdentify possible decision alternativesIndicate actions should be performed, andDescribe actions

188

Decision Tables

Decision tables help analysts ensure completeness and accuracy

Four main problems that can occur in developing decision tablesIncompletenessImpossible situationsContradictionsRedundancy

189

Parent Process Specifications

If a process explodes to a child diagram, the process becomes a control module when the computer program representing the process is written

The logic of the process shows the sequence that the child diagram processes must be executed in

190

Program Process Specification

All the process specifications are consolidated for a computer program and are included in the specification packet given to the computer programmer

Since they are developed for one process, the logic is easier to understand

191

Horizontal Balancing

Horizontal balancing means that all output data flow must be either on input data flow or described in the process logic

It is used to verify that each process has the required data dictionary entries defined and the formulas and logic necessary to produce the output

192

Rules for Horizontal Balancing

Rules for horizontal balancing areAll base elements on an output data

flow must be present on an input data flow

All derived elements on an output data flow must be eitherPresent on an input data flow, orCreated by the process

Chapter 7Designing Databases


Sixth Edition

194

Database Design in SDLCPhase 1 Identifying

problems, opportunities, and objectives







system

195


Readings Chapter 13 in the textbook (page 443)

Major TopicsDatabasesER ModelRelational ModelNormalizationKey design

196

Objectives of Effective Databases

Ensuring that data can be shared among users for a variety of applications

Maintaining data that are both accurate and consistent

Ensuring all data required for current and future applications will be readily available

Allowing the database to evolve and the needs of the users to grow

Allowing users to construct their personal view of the data without concern for the way the data are physically stored

197

Metadata

Metadata is the information that describes data in the databaseUsed to help users understand the

form and structure of the dataAlso called “schema” in databases

198

Entity-Relationship (ER) Concepts

Entities are objects or events for which data is collected and storedperson, place, thing, event, unit of

time, …

Relationships are associations between entities

199

Entities

A distinct collection of data for one person, place, thing, or event

Customer

200

Attributes, Records, and Keys

Attributes are a characteristic of an entity, sometimes called a fieldAlso called data item

Records are a collection of data items that have something in commonInstance of an entity

Keys are data items in a record used to identify the record

201

Keys

Primary key, unique for the recordSecondary key, a key which may not

be uniqueConcatenated key, a combination of

two or more data items for the keyForeign key, a data item in one record

that is the key of another record

202

Entity Subtype

An entity subtype represents data (fields) about an entity that may not be found on every instance of an entity Preferred customers may have special

fields containing discount information

Eliminates null fields

Preferred Customer

203

Attributive Entity

Attributive Entity - describes attributes, especially repeating elements

Attributive entities tables, table files or database code tables

BookSubject

204

Relationships

Relationships may beOne-to-oneOne-to-manyMany-to-many

A single vertical line represents oneA circle represents zero or noneA crows foot represents many

205

Relationships

Many One

Many NoneO

206

Ordinality

The ordinality is the minimum number that can occur in a relationship

If the ordinality is zero, it means that it is possible to have none of the entity O OrderItem

207

Self-Join

A self-join is when a record has a relationship with another record on the same entityStudent partners with another

student on a project

208

Associative Entity

Associative Entity - links two entities An associative entity can only exist

between two entities The relationship line between a many-to-

many relationship becomes an associative entity, sometimes called a composite entity or gerund

OrderItem

209

Associative Entity Connections

Each entity end has a “one” connection

The associative entity has a “many” connection on each side

210

Associative Entity Keys

The key fields for the associative entity areThe primary key for each “one” end is

a foreign key on the associative entityBoth foreign keys concatenated

together become the primary key

211

ER Diagram and Record Keys

The ER diagram may be used to determine record keysWhen the relationship is one-to-many, the

primary key of the file at the one end of the relationship should be contained as a foreign key on the file at the many end of the relationship

A many-to-many relationship should be divided into two one-to-many relationships with an associative entity in the middle

212

Databases

A database is intended to be shared by many users

There are three structures for storing database files:Hierarchical database structuresNetwork database structuresRelational database structures

213

Normalization

Normalization is the transformation of complex user views and data to a set of smaller, stable, and easily maintainable data structures

Normalization creates data that are stored only once on a fileThe exception is key fieldsThis eliminates redundant data storage

214

Three Steps of Data Normalization

UnnormalizedRelationship

NormalizedRelations (1NF)

Second Normal FormRelations (2NF)

Third Normal FormRelations (3NF)

User View

Remove repeating groups

Remove partial dependencies

Remove transitive dependencies

215

Data Model Diagrams

Data model diagrams are used to show relationships between attributes

An oval represents an attributeA single arrow line represents oneA double arrow line represents

manyCustomerNumber

SalespersonNumber

216

First Normal Form (1NF)

Remove any repeating groupsAll repeating groups are moved into a

new tableForeign keys are used to link the tablesWhen a relation contains no repeating

groups, it is in the 1 NFKeys must be included to link the

relations, tables

217

Second Normal Form (2NF)

Remove any partial dependenciesA partial dependency is when the

data are only dependent on a part of a key field

A relation is created for the data that are only dependent on part of the key and another for data that are dependent on both parts

218

Third Normal Form (3NF)

Remove any transitive dependenciesA transitive dependency is when a

relation contains data that are not part of the entity

The problem with transitive dependencies is updating the data

A single data item may be present on many records

219

Guidelines for Creating Master Files or Database Relations

Guidelines for creating master files or database relations areEach separate entity should have it's

own master file or database relationA specific, nonkey data field should

exist on only one master file or relationEach master file or relation should have

programs to create, read, update, and delete records

220

Integrity Constraints

There are three integrity constraints that help to ensure that the database contains accurate data:Entity integrity constraints, which

govern the composition of primary keysReferential integrity, which governs the

denature of records in a one-to-many relationship

Domain integrity

221

Entity Integrity

Entity integrity constraints are rules for primary keys:The primary key cannot have a null

valueIf the primary key is a composite key,

none of the fields in the key can contain a null value

222

Referential Integrity

Referential integrity governs the denature of records in a one-to-many relationship

Referential integrity means that all foreign keys in one table (the child table) must have a matching record in the parent table

223


Referential integrity includesYou cannot add a record without a

matching foreign key recordYou cannot change a primary key that

has matching child table recordsA child table that has a foreign key for a

different record

You cannot delete a record that has child records

224


A restricted database updates or deletes a key only if there are no matching child records

A cascaded database will delete or update all child records when a parent record is deleted or changed

The parent triggers the changes

225

Domain Integrity

Domain integrity defines rules that ensure that only valid data are stored on database recordsDomain integrity has two forms:

Check constraints, which are defined at the table level

Rules, which are defined as separate objects and may be used within a number of fields

226

Retrieving and Presenting Database Data

Guidelines to retrieve and present dataChoose a relation from the databaseJoin two relations togetherProject columns from the relationSelect rows from the relationDerive new attributesIndex or sort rowsCalculate totals and performance measuresPresent data

About me

Name :- Keval.M.Nagaria

Semester :- III

College :- JVIMS MCA Jamnagar

Enrollment no :- 095370693050

Mobile no :- 9998622949

Email id :- [email protected]@gmail.com

~>pc tricks~>internet tips~>pc shortcuts~>web site hack~>free linkJust Type

JOIN only_hackto9219592195

Thank you...

Chapter 1 Introduction to Systems Design and Analysis Systems Analysis and Design Kendall and...

Documents

Transcript of Chapter 1 Introduction to Systems Design and Analysis Systems Analysis and Design Kendall and...