For any human, to have any hope of being successful, it must pass through a small set of essential phases.

(1)

CHAPTER 1

Logical Analysis & Problem Solving for Programming Beginning System Analysis and Design

1. Find out what needs to be done 2. Plan what needs to be done 3. Carry out the plan

4. Evaluate what has been done. System

1. All biological organisms are systems and made up of systems; and all machines are systems.

System with feedback

1. feedback : A return of part of the output of a system to the input as a means towards improved quality or self-correction of error.

2. Negative and positive feedback. 3. GIGO – Garbage In Garbage Out

Program working on incorrect data produces incorrect results. Subsystems

Systems are generally built-up of smaller systems – called subsystems. 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. Information System

A groupware of people, objects and processes … that provides information about the organization and its environment. It should be useful to members and clients of that organization.

Importance of 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. ITDB 3100 - Logical Analysis and Problem Solving for Programming - 1 -

(2)

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.

(3)

CHAPTER 2

The Software Development Life Cycle History of SDLC Models

• Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure.

• Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.

– Note: There are different types of software development that call for different development strategies.

How Software Engineering has changed

• Seven factors that have altered software engineering practice: 1. Criticality of time-to-market for commercial products

2. Shifts in the economics of computing: lower hardware costs and greater development and maintenance costs

3. Availability of powerful desktop computing 4. Extensive local and wide-area networking 5. Availability and adoption of OO technology 6. GUI’s using windows, icons, menus and pointers

7. Unpredictability of the waterfall method of software development

• To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.

What Is the SDLC?

• The software/system development life cycle (SDLC) is the overall process of developing information systems through a multi-step process from investigation of initial requirements through analysis, design, implementation and maintenance. • There are many different models and methodologies, but each generally

consists of a series of similar defined steps or stages.

(4)

Phases of the SDLC

• Feasibility study and project planning.

• Requirements definition and systems analysis. • Systems and program design.

• Implementation.

• Unit testing, Integration and system testing: • Acceptance, installation, deployment. • Maintenance.

Phases of the SDLC

• Over the years, one thing that has become apparent to most software engineers is that requirements grow and change throughout the process and beyond. They are not static.

• This calls for considerable feedback and iterative consultation with the users. Often you will find the need to go back and reiterate earlier stages a number of times as the project progresses.

• In the SDLC process, some activities obviously can't start before others -- such as you need a design before you can start coding – but there is a considerable overlap between some of the activities.

• Many argue that the most effective model for dealing with today’s systems development is the incremental model.

• The incremental model divides the product into builds, where sections of the project are created and tested separately.

• This method also allows many teams to work efficiently in parallel. Teams can do successive compilations (called builds) of the entire project, bringing together all the current components.

Tools Used in Phases of SDLC: Project Planning • Feasibility study and project planning:

– In this phase, the project manager establishes a high-level view of the intended project and determines its goals.

– The software engineer uses his/her technical expertise to determine the feasibility of the desired goals and to give cost/time estimates.

(5)

– Usually the project manager and the software engineer(s) meet with the users to generate a high-level project plan. Gantt charts are often used to track progress in the project plan.

– As requirements are gathered and specific tasks assigned, this project plan is refined.

• Popular tools used in this phase:

• Microsoft project is the industry standard for maintaining project plans.

• Personnel involved:

• Analyst

• User management

• Systems management

Tools Used in Phases of SDLC: Requirements Gathering

• Requirements definition and analysis:

– In this phase, the SE refines project goals into defined functions and operations for the intended application. He/she constantly analyzes end-user information needs and transforms this information into models used by the programmers.

– UML is the standard modeling language used for OO system design. It is a very powerful modeling language and we could spend several semesters just talking about UML alone. We will only learn the basics. • Popular tools used in this phase:

– Rational rose, TogetherJ, EclipseUML. • Personnel involved:

• Analyst

• User management

• User operations workers

(6)

Tools Used in Phases of SDLC: System and Program Design • System and program design.

– System and program design are slightly different.

– In system design, the engineer designs the system components and how they will interact. This includes the presentation layer pieces (e.g. Screen layouts), the business logic layer pieces (business rules), and the data layer pieces (data access processes). The SE will determine what technologies should be used in each layer.

– Program design is system design at a finer level. Here the flow and structure of the actual program code is specified. For example, senior programmers/analysts will take the UML model and write pseudo-code detailing the classes, methods, interfaces, package design, etc. More junior programmers will take this pseudo-code and transform it into actual code (e.g. with java).

– Visio is a very popular tool for drawing flow charts and etc. For program design.

– Rational rose, TogetherJ, and EclipseUML are excellent resources for class diagrams. They all have the ability to transform changes to a UML model into code and vice-versa.

• Analyst

• System designer

• User management

Tools Used in Phases of SDLC: Implementation • Implementation

– This is where the real code is written based on the system and program design.

– IDE’s (Integrated Development Environments) provide many helpful tools that assist programmers in this phase of development.

– Examples of these views include:

• Varying views, debuggers, code completion, code organization, color schemes, and built-in plug-ins to help with other phases.

(7)

– Application Servers are needed to run servlets (Java’s version of server-side program). The engineer will write code in the IDE for objects that will execute in the application server.

– Source code repositories are tools used to manage source code among several developers. They allow developers to check code out (preventing other developers from modifying that program). They also maintain version control allowing developers to see what changes were made by other developers.

• Popular tools used in this phase: – IDE’s

• Eclipse, Visual Café, Visual Age, JDeveloper, Kawa

• We are going to use Eclipse, which is shareware from the Jakarta project. Eclipse is an IDE that has many plug-ins for the other tools we will be using.

– Application Servers:

• WebLogic, WebSphere, Tomcat

• Although WebLogic and WebSphere control most of the market in larger companies, most smaller companies use Tomcat, which is shareware from the Jakarta project. All app servers vary in different respects, but almost all work the same way for basic functionality. So, by learning one, it is easier to learn the others. • We will use Tomcat because it is an industry standard, it is easier

to work with than most app servers, and it is free. – Source code repository and version control systems

• CVS, ClearCase, PVCS, etc.

• We are going to use CVS, which is also from the Jakarta project. CVS is an industry leader in SCM tools and is shareware.

• Analyst

• System designer

• Programmers

• User management

(8)

Tools Used in Phases of SDLC: Testing • Testing

– Testing is an extremely important part of system development. Many companies have teams dedicated to testing and QA alone.

– There are different levels of testing that are needed throughout the SDLC. • Unit testing

– This includes the testing of individual components. You have complete control over the test data and test cases and you run the tests yourself.

• Integration testing

– In this stage of testing, the SE often collaborates with a small number of other developers to test the integration of various system components.

• System testing.

– Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. These tests are often performed by a QA team.

– JUnit is used for unit and integration testing.

• This is a very popular tool in the J2EE world. It is free shareware from the Jakarta project. It has the ability to set up testing plans for individual components including regression testing.

• We will use this for our unit and integration testing. • Personnel involved:

• Analyst

• System designer

• Programmer

(9)

Tools Used in Phases of SDLC: Deployment • Delivery and Deployment

– This is the final stage of initial development, where the software is put into production and runs actual business.

– This part of the project is most often done by a build engineer, but software engineers should be familiar with the deployment tools used by the build engineer.

– The SE will often use the same tool for development and testing. • Popular tools used in this phase:

– Ant, Make

– We will use Ant, a shareware tool from the Jakarta project.

• It is an industry-standard in the OO development community. • It is free.

• It is easier to use than Make. • It is integrated with Eclipse. Tools Used in Phases of SDLC

• Maintenance

– What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

– Most junior developers start here to learn the systems. • Popular tools used in this phase:

– All of the tools above • Personnel involved:

• Analyst

• System designer

• Programmers

(10)

ITDB 3100 - Logical Analysis and Problem Solving for Programming - 10 -

CzHAPTER 3

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. • Observe behavior of employees

• High absenteeism. • High job dissatisfaction. • High job turnover.

• 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.

(11)

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 • 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. 1. 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.

2. Economic Feasibility

• Economic feasibility determines whether the time and money are available to develop the system.

• Includes the purchase of: • New equipment. • Hardware. • Software.

(12)

3. 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

(13)

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.

(14)

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. • Scope.

(15)

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.

(16)

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.

(17)

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. XP Development Process

(18)

EXERCISE – I : GANTT & PERT

1. Ths systems analysis consulting firm of Flow Associates is working on a systems project for Wind and Waves Surfing Gear, Inc.

i. Using the data from the table below, draw a Gantt chart to help Flow Associates organize its design project.

Description Task Must Follow Expected Time (Days)

Draw data flow P None 9

Draw decision tree Q P 12

Revise tree R Q 3

Write up project S R,Z 7

Organize data dictionary T P 11

Do output prototype X None 8

Revise output design Y X 14

Design database Z T,Y 5

ii. Create a PERT diagram for above data. List all paths, and calculate and identify the ciritical path.

2. Prepare a list of activities for an online travel agent who is setting up a Web site for customer to book a flight, make direct purchases, and choose their own seats.

i. On the basis of activities prepare the Gantt chart.

ii. On the basis data availbale create a PERT diagram. List all paths, and calculate and identify critical path.

3. A PERT diagram of a company used for Information Gathering users phase.

i. From the above PERT diagram fill up following table in proper order. Description Task Must Follow Expected Time (Days)

(19)

ii. From above table prepare a Gantt chart.

iii. List all the paths and calculate and determine the critical path for the Gathering Information PERT diagram.

4. A PERT diagram of a company used for Interviewing users phase.

i. From the above PERT diagram fill up following table in proper order. Description Task Must Follow Expected Time (Days)

ii. From above table prepare a Gantt chart.

iii. List all the paths and calculate and determine the critical path for the Interview Users PERT diagram.

CASE-I :

(20)

CASE-I : CPU CASE

(21)

Chapter 4

Analyzing Systems 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

(22)

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 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 2 C u s t o m e r I n q u ir y S u b s y s t e m 1 A d d N e w C u s t o m e r • Represent either: • A whole system • A 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 .

D1

_MasterCustomer

• A set of tables .

• A manual file of records. Data Flow

New Customer

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.

(23)

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. • 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. 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.

(24)

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.

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

diagram number. 3.2 Edit Customer 5.2.7 Calculate Customer Discount • 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.

(25)

Chapter 5

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

(26)

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.

• 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. • 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.

(27)

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. • 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.

(28)

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)

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.

• 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.

(29)

Data Dictionary and Data Flow Diagram Levels

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.

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. • 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.

(30)

Chapter 6

Describing Process Specifications and Structured Decisions Process Specifications

• Process specifications are created for primitive processes and some higher level processes on a data flow diagram.

• They are also called minispecs. Goal of Creating Process Specifications

The goals of producing process specifications are: • Reduce process ambiguity.

• Obtain a precise description of what is accomplished.

• Validate the system design, including data flow diagrams and the data dictionary. Process Specifications

Process specifications are not created for:

• Physical input and/or output processes.

• Processes that represent simple data validation. • Processes for which prewritten code already exists. Data Flow Diagram and Process Specifications

(31)

Process Specification Example Part 1 Number 1

Name 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

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 Structured English

• Structured E

• nglish is based on structured logic and Simple English statements such as add, multiply, move, and so on.

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

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”.

(32)

Structured English

Advantages of Structured English

• Clarifying the logic and relationships found in human languages • An effective communication tool, and easy to teach and understand Data Dictionary and Structured English

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.

Decision Tables

• Decision tables 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.

(33)

Decision Table Format

Decision Table Example

• Decision tables help analysts ensure completeness and accuracy. • Four main problems that can occur in developing decision tables:

• Incompleteness. • Impossible situations. • Contradictions. • Redundancy.

(34)

Redundancy and Contradictions

Decision Trees

• 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.

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.

Decision Tree Example

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.

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