lecture note 10 describing process specifications and structured decisions

44
Lecture Note 10 Describing Process Specifications and Structured Decisions Systems Analysis and Design Kendall & Kendall Sixth Edition Part III: The Analysis Process

Upload: monty

Post on 11-Jan-2016

70 views

Category:

Documents


1 download

DESCRIPTION

Part III: The Analysis Process. Lecture Note 10 Describing Process Specifications and Structured Decisions. Systems Analysis and Design Kendall & Kendall Sixth Edition. Major Topics. Process Specifications Business Rules Structured English Decision Tables Decision Trees - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Lecture Note 10 Describing Process Specifications and Structured Decisions

Lecture Note 10Describing Process Specifications

and Structured Decisions

Systems Analysis and Design

Kendall & Kendall

Sixth Edition

Part III: The Analysis Process

Page 2: Lecture Note 10 Describing Process Specifications and Structured Decisions

2

Major Topics

• Process Specifications• Business Rules• Structured English• Decision Tables• Decision Trees• Horizontal Balancing

Page 3: Lecture Note 10 Describing Process Specifications and Structured Decisions

3

Process SpecificationsWhat occurs within a process? How are the input data converted to

the output information? Since DFD are not really designed to show the detailed logic of process.

• Process specifications (說明書 ) are created for processes and some higher level processes on a DFD. They are also called minispecs.• Explain :

• the Decision-Making Logic, • Business Logic and • Formulas that will transform process input data into output.

• Each derived (衍生 ) element must have process logic to show how it is produced from the base elements.

1

?

Page 4: Lecture Note 10 Describing Process Specifications and Structured Decisions

4

Goal of Creating Process Specifications

1. To reduce the ambiguity (不明確 ) of the process.– Compels (強迫 ) the SA to learn details about how the

process works.– Any vague (模糊不清的 ) areas should be noted, written

down, and consolidated (統一 ) for all process specifications.

2. To obtain a precise (精確的 ) description of what is accomplished (完成 ).

3. To validate (確認 ) the system design, including data flow diagrams and the data dictionary.

• Ensures (確保 ) that a process has all the input data flow necessary for producing the output.

• All input and output must be represented on the DFD.

Page 5: Lecture Note 10 Describing Process Specifications and Structured Decisions

5

Process specifications are not created for:– Processes that represent physical input or

output, e.g. read, write. (Require only simple logic).

– Processes that represent simple data validation (easy to accomplish). The edit criteria (條件 ) are included in the data dictionary and incorporated (合併 ) into the computer source code.

– Processes that use prewritten (預先寫好 ) code (included in a system as subprograms and functions). E.g. validating a date or a check digit.

Page 6: Lecture Note 10 Describing Process Specifications and Structured Decisions

6

Data Flow Diagram and Process Specifications

The system analyst approaching process specifications and structured decisions has many options for documenting and analyzing them. The methods available for documenting and analyzing the logical of decisions include Structured English, Decision Tables and Decision Tree.

Page 7: Lecture Note 10 Describing Process Specifications and Structured Decisions

7

Process Specification Format

• Process specifications link the process to the DFD and the data dictionary. Each process specification should be entered on a separate form. (or into a case tool screen such as the one used for Visible Analyst)

• The following information should be entered:– The process number, which must match the process ID

on the DFD. This specification allows SA to work on or review any process and easily locate the DFD containing the process.

– Process name, the same as the name displayed within the process symbol on the DFD.

– A brief description of what the process accomplishes.

Page 8: Lecture Note 10 Describing Process Specifications and Structured Decisions

8

– A list of input and output data flow, using the names found on the DFD. Data names used in the formula or logic should match those in the data dictionary to ensure consistency and good communication.

– The Output data flows, using DFD and data dictionary names.

– An indication if the type of process: Batch (一批 ), On-line or Manual. All on-line processes require screen designs, and all manual processes should have well-defined procedures for employees performing (實行 ) the process tasks.

– If the process uses prewritten code, include the name of the subprogram or function containing that code.

– Data names used in the formulae or logic should match the data dictionary, for consistency and good communication.

Page 9: Lecture Note 10 Describing Process Specifications and Structured Decisions

9

– A description of the process logic that states policy and business rules, not computer language pseudocode. Common business rule formats include the following:

– Definitions of business terms– Business conditions and actions– Data integrity constraints– Mathematical and functional derivations– Logical inferences– Processing sequences– Relationships among facts about the business

– If there is not enough room on the form for a complete structured English description or if there is a Decision Table or Decision Tree depicting (描述 ) the logic, include the corresponding table or tree name.

– List any unresolved issues (問題 ), incomplete portions of logic or other concerns. These issues form the basis (基本 ) of the questions used for follow-up interviews.

Page 10: Lecture Note 10 Describing Process Specifications and Structured Decisions

10

Process Specification Example 1

Page 11: Lecture Note 10 Describing Process Specifications and Structured Decisions

Structured English

• It is special form of spoken English analyst use to illustrate the logic of processes depicted in DFD.

• It is based on structured logic, or instructions organized into nested and grouped procedures, sequence, conditional statement, repetition, and simple English statements.

• It is primarily a communication technique for analysts and user.

• It is an appropriate technique for analyzing the system when structured decisions are not complex.

Sequence Structure Selection StructureIteration Structure

Page 12: Lecture Note 10 Describing Process Specifications and Structured Decisions

12

Steps to Use Structured English• The following steps are needed:

– Express all logic in terms of sequential structures, decision structures, case structures, or iterations.

– Use and capitalize accepted keywords such as IF, THEN, ELSE, DO, and PERFORM.

– Indent (縮排 ) blocks of statements to show their hierarchy (等級 ) (nesting) clearly.

– Underline words or phrases used have been defined in a data dictionary to signify that they have a specialized, reserved meaning.

– Be careful when using “AND" and “OR ".– Avoid confusion (糊塗 ) when using logical comparisons

such as "greater than" and "greater than or equal to” and “Like” relationships. So clarify the logical statements now rather than waiting until the program coding stage.

Page 13: Lecture Note 10 Describing Process Specifications and Structured Decisions

13

Page 14: Lecture Note 10 Describing Process Specifications and Structured Decisions

A Structured English Example 1:

The VERIFY ORDER process description includes logical rules and a structured English version of the policy. Notice the alignment and indentation of the logic statements.

Structured English Statements

Page 15: Lecture Note 10 Describing Process Specifications and Structured Decisions

A Structured English Example 2:We process all of our claims (索賠 ) in this manner (方式 ).

1. First we determine (決定 ) whether the claimant (索賠者 ) has ever sent in a claim before; if not, we set up a new record. The claim totals for the year are then updated.

2. Next we determine if a claimant has policy A or policy B, which differ (不同 ) in deductibles (扣除條款 ) and co-payments (the percentage of the claim claimants pay themselves). For both policies, we check to see if the deductible has been met ($100 for plan A and $50 for plan B). If the deductible has not been met, we apply the claim to the deductible.

3. Another step adjusts (調整 ) for the co-payment; we subtract ( 減 ) the percentage the claimant pays (40% for plan A and 60% for plan B) from the claim.

4. Then we issue (發出 ) a check if there is money coming to the claimant, print a summary of the transaction (交易 ), and update our accounts. We do this until all claims for that day are processed.

The example demonstrates how a spoken procedure for processing medical claims in transformed into structured English.

Page 16: Lecture Note 10 Describing Process Specifications and Structured Decisions

16

Advantages of Structured English

• Clarifying the logic and relationships found in human languages• An effective communication tool, and easy to teach and

understand.• Structured English might look familiar to programming students

because it resembles pseudo code, which is used in program design.

Page 17: Lecture Note 10 Describing Process Specifications and Structured Decisions

17

Data Dictionary and Structured English

• All computer programs may be coded using the three basic constructs: sequence, selection and iteration. The data dictionary indicates which of these constructs must be included in the process specification.

• The data dictionary is a starting point for creating structured English:– Sequenced data dictionary entries become simple

structured English statements.– Selection [] entries become IF..THEN...ELSE statements.– Iteration { } entries become DO WHILE, DO UNTIL, or

PERFORM UNTIL structured English statements.

Page 18: Lecture Note 10 Describing Process Specifications and Structured Decisions

18

Page 19: Lecture Note 10 Describing Process Specifications and Structured Decisions

19

Decision Tables• It is graphical methods for representing process logic.• It provide a way to examine, describe, and document

decisions using a table.• They are used to:

– Describe the conditions.– Identify possible decision alternatives.– Indicate actions should be performed.– Describe actions.

• The standard format used for presenting a decision table.

Page 20: Lecture Note 10 Describing Process Specifications and Structured Decisions

20

Decision Table Example 1

Rule 3: saysIf N (the total sale is NOT under $50)

AND

If Y (the customer paid by check and had

two forms of ID )

AND

If N (the customer did not use a credit card)

THEN

DO X ( call the supervisor for approval)

conditions

Actions

Decision alternatives

Page 21: Lecture Note 10 Describing Process Specifications and Structured Decisions

21

Developing Decision Tables• Determine the number of conditions that may affect (影響 )

the decision. Combine (合併 ) rows that overlap (重疊 ).

• Determine the number of actions that can be taken.• Determine the number of condition alternatives (Y, N) for

each condition.• Calculate the maximum number of columns in the

decision table by multiplying ( 乘 ) the number of alternatives for each condition.

Condition 1: 2 alternativesCondition 2: 2 alternativesCondition 3: 2 alternativesCondition 4: 2 alternatives

24 =16 possibilities

Page 22: Lecture Note 10 Describing Process Specifications and Structured Decisions

22

5. Fill in the condition alternatives. Start with the 1st condition and divide the number of columns by the number of alternatives for that condition.

6. Complete the table by inserting an X where rules suggest actions.

7. Combine rules where it is apparent (明顯的 ) that an alternative does not make a difference in the outcome (結果 ).

8. Check the table for any impossible situations, contradictions (矛盾 ), and redundancies (多餘 ).

9. Rearrange (再安排 ) the conditions and actions if this makes the decision table more understandable.

Condition 1: YYCondition 2: YNAction 1: XX

Condition 1: YCondition 2: Action 1: X

Condition 1: YYYYYYYYNNNNNNNN

Condition 1: YYYYYYYYNNNNNNNNCondition 2: YYYYNNNNYYYYNNNNCondition 3: YYNNYYNNYYNNYYNNCondition 4: YNYNYNYNYNYNYNYN

Page 23: Lecture Note 10 Describing Process Specifications and Structured Decisions

Creating the Decision Table Example 1

For each ORDER IF CUSTOMER STATUS CODE = Y and IF PRODUCT DETAIL = OK Output ACCEPTED ORDER ELSE Output REJECTED ORDER

Structured English Statements

1

2 3

4

1. Place the name of the process in a heading at the top left.

2. Enter the conditions under the heading, with one condition per line, to represent the customer status and available of products.

3. Enter the potential combinations of Y/N for the conditions. Each column represents a numbered possibility called a rule.

4. Place an X in the action entries area for each rule to indicate whether to accept or reject the order.

Four columns = (2 alternatives × 2 alternatives)

Page 24: Lecture Note 10 Describing Process Specifications and Structured Decisions

24

Decision Table Example 2

This tables an illustration of a decision table. The company is trying to maintain a meaningful mailing list of customers. The objective is to send out only the catalogs from which customers will buy merchandise.

A decision table is constructed for three conditions, each having two alternatives (Y or N). Three actions can be taken. The regular decision table has six rows (3 conditions and 3 actions) and eight columns (2 alternatives × 2 alternatives 2 × alternatives ).

Page 25: Lecture Note 10 Describing Process Specifications and Structured Decisions

25

Rules 2,4,6 and 8 can be combined because they all have two things in common:

1. They instruct us to send out this year’s Christmas catalog.

2. The alternative for Condition 3 is always N

Page 26: Lecture Note 10 Describing Process Specifications and Structured Decisions

26

Suppose the rule is:

IF the customer did not order more than $50

THEN do not send any catalogs

Page 27: Lecture Note 10 Describing Process Specifications and Structured Decisions

27

Checking for Completeness and Accuracy

• Decision tables help analysts ensure completeness and accuracy.

• Four main problems that can occur in developing decision tables:– Incompleteness.– Impossible situations.– Contradictions (自相矛盾 ).

– Redundancy.

Page 28: Lecture Note 10 Describing Process Specifications and Structured Decisions

28

Rule 1 is not feasible, because a person cannot earn greater than $50,000 per year and less than $2,000 per month at the same time.

Contradictions often occur of dashes [--] are incorrectly inserted into the table. Redundancy occurs when identical sets of alternatives require the exact same action. The analyst has to determine what is correct and then resolve the contradiction or redundancy.

Page 29: Lecture Note 10 Describing Process Specifications and Structured Decisions

29

More Advanced Decision Tables • Decision tables can become very big because they grow rapidly

as the number of conditions and alternatives increases.

• In order to avoid a decision table to grow rapidly, we can use Extended Entries or ELSE rule.

C1: Did not order YNNNC2: Ordered once NYNNC3: Ordered twice NNYYC4: Ordered more than twice NNNY

C1: Number of times customer ordered 0 1 2 >2

1. Extended entries: to reduce the possibility of redundancy and contradiction.

Example:

The number of required columns and rows decreases and the understandability increases. Instead of using four rows for the number of timers a customer orders, only one row is needed.

Page 30: Lecture Note 10 Describing Process Specifications and Structured Decisions

30

An example of a structured inventory ordering policy.

Page 31: Lecture Note 10 Describing Process Specifications and Structured Decisions

31

2. ELSE Rule: to eliminate repetitive rules requiring the exact same action.

Page 32: Lecture Note 10 Describing Process Specifications and Structured Decisions

32

Decision Trees

• Decision tree is a graphical representation of a decision situation.

• Decision trees are used when complex branching occurs in a structured decision process.

• Trees are also useful when it is essential to keep a string of decisions in a particular sequence.

• Decision tree are most often drawn with the root of the tree on the left side and the tree branches out to the right. This orientation allows the analyst to write on the branches to describe conditions and actions.

Page 33: Lecture Note 10 Describing Process Specifications and Structured Decisions

33

Drawing Decision Trees

• First, identify all conditions and actions and the order and timing of these (if they are critical).

• Second, begin building the tree from left to right while making sure you are complete in listing all possible alternatives before moving over to the right.– A square node indicates an action (THEN).

– A circle to represent a condition (IF).

– Numbering the circles and squares sequentially.

Page 34: Lecture Note 10 Describing Process Specifications and Structured Decisions

34

Decision Tree Example 1A point-of-sale example was used to determine the purchase approval (批准 ) actions for a department store. Conditions included the amount of the sale (under $50) and whether the customer paid by check or credit card. The four actions possible were to ring up the sale, look up the credit card in a book, call the supervisor for approval, or call the bank for credit card authorization.

Page 35: Lecture Note 10 Describing Process Specifications and Structured Decisions

35

Decision Tree Advantages

Three advantages over a decision table are:– The order of checking conditions and executing

actions is immediately noticeable (顯而易見 ).

– Second, conditions and actions of decision trees are found on some branches but not on others, which contrasts with decision tables, in which they are all part of the same table. Those conditions and actions that are critical are connected directly to other conditions and actions. The tree does not have to be symmetrical (對稱 ).

– Third, compared to decision tables, decision trees are more readily understood by others in the organization.

Page 36: Lecture Note 10 Describing Process Specifications and Structured Decisions

36

Selecting a Structured Decision Analysis Technique

Guidelines are as follows:– Use structured English when there are many

repetitious actions or when communication to end users is important.

– Use decision tables when complex combination of conditions, actions, and rules are found or you require a method that effectively avoids impossible situations, redundancies, and contradictions.

– Use decision trees when the sequence of conditions and actions is critical or when not every condition is relevant to every action (the branches are different).

Page 37: Lecture Note 10 Describing Process Specifications and Structured Decisions

37

Page 38: Lecture Note 10 Describing Process Specifications and Structured Decisions

38

Using Process Specifications

• All the process specifications are consolidated (使堅固 ) for a computer program and are included in the specification packet given to the computer programmer.

• Process specifications may be used for generating (產生 ) computer language source code and for analyzing the system design.

• Process specifications are developed on a small scale (規模 ), one process at a time, each one may be analyzed for complete and correct logic. The logic is easier to understand.

• When the SA is finished and corrections are made for all processes within a program, the final program specifications should be complete and accurate.

Page 39: Lecture Note 10 Describing Process Specifications and Structured Decisions

39

Horizontal (水平的 ) Balancing• 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.

• Process specifications may be used to analyze the DFD and data dictionary through a method called horizontal balancing.

• Horizontal balancing dictates (規定 ) that all output data-flow elements must be obtained from the input elements and process logic.

• Base elements on an output data flow must be present (出現 ) on the input flow.

• Derived elements on an output flow must be either present on an input data flow or created using the process specifications.

• Unresolved areas should be summarized into a series of interview questions.

Page 40: Lecture Note 10 Describing Process Specifications and Structured Decisions

40

How Structured English can help us complete the DFD.

Page 41: Lecture Note 10 Describing Process Specifications and Structured Decisions

41

Shows corresponding data dictionary entries for producing the Supplier Sales Receipt.

Page 42: Lecture Note 10 Describing Process Specifications and Structured Decisions

42

Page 43: Lecture Note 10 Describing Process Specifications and Structured Decisions

43

Page 44: Lecture Note 10 Describing Process Specifications and Structured Decisions

44

Review Question• List the three reasons for producing process specifications.• What is the advantage of using structured English to

communicate with people in the organization?• What three advantages do decision trees have over decision

tables?• In which two situations should you use structured English?

(when many actions are repeated and when communicating with others is important)

• In which two situations do decision tables work best? (When complex combinations of conditions, actions, and rules are found or you

require a method that effectively avoids impossible situations, redundancies, and contradictions.)

• In which two situations are decision trees preferable? (when the sequence of conditions and actions is critical or not every condition is relevant to every action )

• What four elements must be known for the systems analyst to design systems for structured decisions?

(Conditions, Condition Alternatives, Actions, and Action Rules)