Automation boundaries

By -

Automation boundaries

36.1 Purpose

Defining automation boundaries is a technique for generating alternative, high-level, physical system designs.

36.2 Strengths, weaknesses, and limitations

Because the automation boundary technique builds on the logical models developed during the analysis stage, the suggested alternatives are likely to be logically consistent. A single set of automation boundaries defines a family of related alternatives, so this technique can be used to identify numerous options (which can be viewed both as an advantage and a disadvantage). Using automation boundaries to identify alternatives requires expertise in data flow diagrams.

36.3 Inputs and related ideas

The techniques described in this chapter require a complete logical model consisting of a set of balanced data flow diagrams and supporting documentation (Chapter 24). Additionally, various system parameters identified during the problem definition and information gathering stage (Part II) and the analysis stage (Part IV) and documented in the requirements specifications (Chapter 35) are used to help identify feasible alternatives. Typically, a few of the best alternatives are further documented using such tools as system flow diagrams (Chapter 37), and a cost/benefit analysis (Chapter 38) is performed for these options. The selected physical alternative forms the basis for component design (Part VI).

36.4 Concepts

A logical model consisting of a data flow diagram (Figure 36.1) and associated documentation (Chapter 24) is the starting point for generating alternatives using automation boundaries.

36.4.1 Trigger events

The trigger event is the event that activates the process. For example, in Table 36.1, Process shipment is triggered by the arrival of a shipment and the activities associated with Sell appliance, Update appliance, and Reorder stock are all triggered by a sales transaction. Because the manager will almost certainly need a week’s summary of sales to make decisions on sale items,Identify sale item is a scheduled (batch) end-of-week activity, and so on.

36.4.2 Response time

Response time is the maximum allowable time to complete a process once the trigger event has occurred. For example, in Table 36.1, Sell appliance is an interactive task that must be completed while the customer is in the store, so its response time is measured in minutes. The other processes in this system can all be performed in batch mode, so their response time requirements are identified as end of day, end of week, and so on. Note that the maximum allowable response time is listed. For example, it would be perfectly acceptable to update inventory within minutes of a sales transaction, but it would not be acceptable to put off selling appliances until the end of the day.

36-01
Figure 36.1  In this example, processes 3 and 4 are inside the same automation boundary. Note that the data flows are not labeled to more clearly show the automation boundaries.

36.4.3 Defining automation boundaries

Given the trigger events and response time requirements for each process, alternatives are generated by superimposing automation boundaries on the data flow diagram. An automation boundary is simply a line drawn around one or more processes. The idea is to group the processes enclosed by an automation boundary to form a single program or procedure. Note that a set of automation boundaries defines a family of alternative solutions.

One possibility is to enclose each process within its own automation boundary. In this family of alternatives (not illustrated, but refer to Figure 36.1), each process is implemented as an independent program or procedure. A manual system might incorporate procedures to Process shipment, Sell appliance, Update inventory, and so on. A second alternative might include nine programs, one for each process. A third alternative might call for a Process shipment program, aSell appliance manual procedure, programs to Update inventory and Perform physical inventory, and manual procedures to perform the other tasks. Additional alternatives might be suggested by studying the associated level 2 data flow diagrams.

Changing the automation boundaries yields a new family of alternatives. For example, Figure 36.1includes an automation boundary that encloses processes 3 and 4. Because all the processes within a given boundary are implemented in a single physical component or set of components (e.g., a program and the computer on which it runs), the alternatives in this family contain a single program or procedure that performs all the functions associated with Update inventory and Reorder stock.

When two or more processes are merged, the shortest response time applies to the new process. For example, Table 36.1 shows that inventory must be updated at least daily and reorders must be issued at least weekly. Daily reorders are fine, but weekly inventory updates are unacceptable, so if processes 3 and 4 are merged, the resulting program or procedure must be executed at least daily.

Processes 2, 3, and 4 are all triggered by a sales transaction (Table 36.1), so it might make sense to define a new family of automation boundaries that groups them (Figure 36.2). One possible physical alternative within this family features a program to perform the functions associated withSell appliance, Update inventory, and Reorder stock. Stock might be reordered weekly and inventory might be updated daily, but appliances are sold continuously as customers arrive. Because the tightest response time rules, the program would have to run continuously and respond to sales transactions in minutes. That, in turn, implies an on-line, interactive program.

36-02
Figure 36.2  This example groups processes 2, 3, and 4.

36.4.4 A strategy

Follow a systematic procedure to generate alternatives. Start by drawing a separate automation boundary around each process. Then try grouping processes by drawing a boundary around 1 and 2, then 1 and 3, and so on. Next, try sets of two processes each; for example, group 1 and 2 within one automation boundary and 3 and 4 within another. Gradually, move up to groups of three, then groups of four, and so on, until every possible combination has been considered. The limit is a single automation boundary containing all the processes and suggesting (perhaps) an on-line, interactive program that does everything.

Another option is to focus on grouping processes that have the same response time requirement or trigger event or that share a common data store. Processes calling for similar response times can often be merged to form a single program or procedure. Processes that occur in response to the same trigger event can often be performed concurrently. Processes that manipulate the same data often belong together.

Given even a small data flow diagram, an amazing number of alternative solutions can be generated. Some, of course, will make no logical sense and thus can be eliminated quickly; for example, because physical inventory is performed quarterly, it would make no sense to combine processesSell appliance and Physical inventory. The scope is another useful screen. If the cost of an alternative significantly exceeds the scope, that alternative is not economically feasible. The idea is to identify two or three reasonable alternatives that are worthy of further study.

36.5 Key terms
Automation boundary —
A line drawn around one or more processes on a data flow diagram, thus grouping them to form a single program or procedure; a set of automation boundaries defines a family of alternative solutions.
Data flow diagram —
A logical model of the flow of data through a system.
Level 1 data flow diagram —
A data flow diagram that shows the system’s primary processes, data stores, sources, and destinations linked by data flows.
Level 2 data flow diagram —
An explosion of a level 1 process.
Response time —
The maximum allowable time to complete a process once its trigger event has occurred.
Trigger event —
The event that activates the process.
36.6 Software

Many CASE products include routines that allow a user to graphically define automation boundaries on a data flow diagram. The examples in this chapter were prepared using Visio.

36.7 References
1.  Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.
2.  Gane, C. and Sarson, T., Structured Systems Analysis: Tools and Techniques, Prentice-Hall, Englewood Cliffs, NJ, 1979.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However...
Read more