Data-Oriented Design

Introduction

Conceptual Foundations

Definition of Information Engineering Design Terms

A full list of the activities in IE design is given here; included are references to chapters in which some topics are discussed. 

1. Design security, recoverability, and audit controls 

2. Design human interface structure 

• Develop menu structure 
• Define screen dialogue flow 

3. Data analysis 

• Reconfirm subject area database definition 
• Denormalize to create physical database design 
• Conduct distribution analysis and recommend production data distribution strategy 

4. Develop an action diagram and conduct reusability analysis 

5. Plan hardware and software installation and testing 

6. Design conversion from the old to the new method of data storage (Chapter 14) 

7. Design and plan application tests (Chapter 17) 

8. Design and plan implementation (Chapter 14)

9. Develop, schedule, and conduct training programs for users (Chapter 14)

The topics in this chapter are design of data usage, action diagrams (which are program specs), screen dialogues, security, recovery, audit controls, and installation planning. They are discussed in this section in the order above, by the amount of work involved, and their importance to the application. 

The first activity in IE design is to confirm design of the database and determine the optimal data location. Invariably, when the details of processing are mapped to specifications, data usage changes from that originally envisioned. To confirm database design, the data is mapped to application processes in an entity/process (CRUD) matrix and the matrix is reanalyzed. (See Chapter 9 for a more complete discussion of entity/process matrices.) The entity/ process matrix (see Figure 10-1) clusters data together based on processes with data creation authority. The subject area databases defined by the clusters are stored in the same database environment. 

The second step of database design is to determine a need to denormalize the data. Recall that normalization is the process of removing anomalies that would cause unwanted data corruption. Denormalizing is the process of designing storage items of data to achieve performance efficiency (see Figure 10-2). Having normalized the data, you know where the anomalies are and can design measures to prevent the problems.

The next activity in data analysis is to determine the location of data when choices are present. A series of objective matrices are developed and analyzed. The matrices identify process by location and data by location and transaction volume. These are used to develop potential designs for distribution of data. The application processes and data are both mapped to locations. Cells of the process/location matrix contain responsibility information, identifying locations with major and minor involvement (see Figure 10-3). This information is used to determine which software would also be required to be distributed, if distribution is selected. 

Two data/location matrices are developed. The first data/location matrix identifies data function as either update (i.e., add, change, or delete) or retrieval by location (see Figure 10-4a). The second defines options for data in each location (Figure 10-4b). Together these matrices identify options for distributing data. The options for distributed data are replication, partitioning, subset partitioning, or federation (see Figure 10-5). Replication is the copying of the entire database in two or more locations. Vertical partitioning is the storage of all data for a subset of the tuples ( or records) of a database. Subset partitioning is the storage of a partial set of attributes for the entire database. Federation is the storage of different types of data in each location, some of which might be accessible to network users. The selection of distribution type is determined by the usage of data at each location.

FIGURE 10-1 Example of Entity/Process Matrix

Then, a transaction volume matrix is developed to identify volume of transaction traffic by location. Cells of this matrix contain an average number of transactions for each data relation/process per day (see Figure 10-6). In an active application, hourly or peak activity period estimates of volume might be provided. During matrix analysis, the data and processes are clustered to minimize transmission traffic. Then formulae are applied to the information to determine whether the traffic warrants further consideration of distribution. 

Finally, subjective reasons for centralizing or for distributing the application are developed. The subjective arguments ensure that political, organizational, and nonobjective issues are identified and considered. Examples of subjective motivations for centralization/distribution relating to Figures 10-4, 10-5, and 10-6 are in Table 10-1. Recommendations on what, how, and why to distribute (or centralize) data are then developed from the matrices and subjective analysis. The recommendations and reasoning are presented to user and IS managers to accept or modify.

After data are designed, the design of the human interface can begin with a definition of interface requirements. The hierarchy diagram is used to determine the structure of selections needed by the application. A menu structure is a structured diagram translating process alternatives into a hierarchy of options for the automated application (see Figure 10-7). In general, we plan one menu entry for each process hierarchy diagram entry between the top and bottom levels. One level of menus corresponds to one level in the process hierarchy diagram. At the lowest level of the process hierarchy, a process corresponds to either a program or module. Screens at the lowest level are determined by estimating execute units. These functional screens may not be final in menu structure definition because execute unit design is usually a later activity. Once the menu structure is defined, it is given to the human interface designer( s) for use during screen design (Chapter 14).

FIGURE 10-2 Example of Denormalized Data for an Order

FIGURE 10-3 Example of Process/Location Matrix

Data Usage by Location Matrix 

FIGURE 10-40a Example of Data Matrices by Location

Distribution Alternatives by Location

FIGURE lO-4b Example of Data Matrices by Location

The structure is then analyzed further to determine the allowable movement between the options on the menu structure. The dialogue flow diagram documents allowable movement between entries on the menu structure diagram (see Figure 10-8). On the diagram, rows correspond to screens and columns correspond to allowable movements. For instance, in the menu structure example (Figure 10-7), Customer Maintenance has four subprocesses. A dialogue flow diagram shows how Customer Maintenance is activated from the main menu (or elsewhere) and the \options for movement from that level. From the Customer Maintenance menu, the options are to move to the main menu or to one of the four subprocesses. The dialogue flow diagram is used by the designers in developing program specifications, by the human interface designer( s) in defining screens, and by testers in developing interactive test dialogues. Next, procedure design begins with analysis of the process hierarchy and process data flow diagrams developed during IE analysis (Chapter 9). Remember, in analysis, we developed one process data flow diagram (PDFD) for each activity. Now each PDFD is converted into an action diagram. An action diagram shows procedural structure and processing details suitable for automated code generation. An action diagram is drawn with different types of bracket structures to show the hierarchy, relationships, and structured code components of all processes.

FIGURE 10-5 Data Distribution Alternatives

The first-cut action diagram translates the PDFD into gross procedural structures (see Figure 10-9). Then, using detailed knowledge obtained during the information gathering process, the details of each procedure are added to the diagram to develop program specifications (see Figure 10-10). These program specifications may then be packaged into modules that perform one function. Data entities are added to the diagram at the level they are accessed (see Figure 10-11). Progressively more detail about data usage is provided about data attributes. Arrows are attached to show reading and writing of data (see Figure 10-12). When the details are completely specified, the action diagram is mapped to procedural templates to determine the extent to which reusable modules can be used in the application, and the changes to the action diagrams required to define modules for reuse. A procedural template is a general, fill-in-the-blanks guide for completing a frequently performed process. For instance, error processing and screen processing can be defined as reusable templates (see Figure 10-13). A data template is a partial definition of an ERD or database that is consistent within a user community. For example, the insurance industry has common data requirements for policy holders, third party insurance carriers, and policy information; most companies have similar accounting data needs, and so on. To be a candidate for template definition, a process must do exactly the same actions whenever it is invoked, and data must be consistent across users. 

FIGURE 10-6 Example of Transaction Volume Matrix 

After reusability analysis, the action diagram set is finalized and used to generate code. If the application is specified manually, the action diagrams are given as program specifications to programmers who begin coding. If the application uses a CASE tool, automatic code generation is possible. A code generator is a program that reads specifications and creates code in some target language, such as Cobol or C. If the application uses a code generator, the action diagram contains the symbols and procedural detail specific to the code generation software. If the application uses a 4GL, the action diagram might contain actual code. If manual programming uses a 3GL or lower, the action diagram contains pseudo-code consisting of structured programming constructs. The next activity in IE design is to develop security plans, recovery procedures, and audit controls for the application. Each of these designs restrict the application to performing its activities in prescribed ways. The goal of security plans is to protect corporate IT assets against corruption, illegal or unwanted access, damage, or theft. Security plans can address physical plant, data, or application assets, all by restricting access in some way. Physical security deals with access to computers, LAN servers, pes, disk drives, cables, and other components of the network tying computer devices together. Data security restricts access to and functions against data (e.g., read, write, or read/write). Application security restricts program code from access and modification by unauthorized users. Examples of the results of security precautions are locking of equipment, requirement of user passwords, or assignment of a software librarian for program changes. 

TABLE 10-1 Example of Subjective Reasons for Centralization and Distribution

FIGURE 10-7 Menu Structure Example 

Recovery procedures define the method of restoring prior versions of a database or application software after a problem has destroyed some or all of it. Recovery is from a copy of the item. Backup is the process of making extra copies of data to ensure recoverability.· Disasters considered in the plan include user error, hacker change, software failure, DBMS failure, hardware failure, and location failure. Recovery is the process of restoring a previous version of data (or software) from a backup copy to active use following some damage to, or loss of, the previously active copy. The backup/recovery strategy should be designed to provide for the six types of errors above. Several backup options add requirements to program design that need to be accommodated. 

FIGURE 10-8 Dialogue Flow Diagram Example 

FIGURE 10-10 Action Diagram with Create Purchase Order Process Detail 

Next, audit controls are designed to prove transaction processing in compliance with legal, fiduciary, or stakeholder responsibilities. Audit controls usually entail the recording of day, time, person, and function for all access and modification to data in the application. In addition, special totals, transaction traces, or other special requirements might be applied to provide process audit controls. 

Last, hardware installation is planned and implemented, if required for the application. Again, there is no theory or research about hardware installation, but long practice has given us guidelines on the activities and their timing. 

Information Engineering Design

In this section, we discuss each activity in IE design in detail, and relate them to the ABC Video rental application. IE design topics in this section, in order of their occurrence in the application development process, include development of the following:

• data use and distribution analysis
• security, recovery, and audit controls
• action diagrams
• menu structure and dialogue flow
• hardware and software installation and testing plans

Analyze Data Use and Distribution

Guidelines for Data Use and Distribution Analysis 

The two activities in this section precede physical database design which is assumed to be performed by a DBA. First, data usage analysis is performed to confirm the logical database design. Then the potential for distributing data throughout the organization is analyzed. The result is a strategy for data and software location that best fits user needs.

FIGURE 10-11 Action Diagram with Entities

The entity/process (CRUD) matrix from IE analysis is reanalyzed and mapped to the completed action diagram. Each process is identified on the action diagram with its associated data items and the related entity. Recall that the clustering of entities and processes on the matrix is primarily based on which processes have created responsibility for the data. The entities and processes are arranged into a new entity/process matrix which is compared to the one developed during analysis. If the definition of subject area databases does not change, the distribution analysis can begin. If the definition of subject area databases does change, the logical definition of the databases is redone as discussed in Chapter 9. 

The second step to data analysis is to determine the potential for data distribution. Distribution analysis uses three matrices as the objective basis for determining whether data should be distributed. 

FIGURE 10-12 Action Diagram with Data Detail

First, a location/process matrix is developed to identify major and minor performance of processes in the application (see Figure 10-14). This location/process matrix determines which software is needed at each location to support the functions. The information needed to complete the matrix is provided by the users.

Next, a data distribution by location matrix is developed to show creation and retrieval needs by location (see Figure 10-15). This data location matrix is used to determine the potential age of data required by each location. For instance, retrieval data might be down-loaded from a centralized location each day at the close of business, rather than maintained at the remote sites. Created data must be available for creation, and therefore, up-to-date at the creating sites. The information needed to complete the matrix is provided partly from the entity/ process matrix from the first data analysis, and partly by the users.

FIGURE 10-13 Procedure Template for Error Message Processing

The next matrix shows data usage by location (see Figure 10-16). Recall from above that data can be centralized, vertically or horizontally partitioned, or federated. For instance, a bank branch might create data about customers, but it only accesses information about its own customers on a regular basis. So, for most processing, a vertical partition of the customer database, the branch's customers, could be accessible locally in the branch to speed processing. 

FIGURE 10-14 Process by Location Matrix Example

FIGURE 10-15 Data Usage by Location Matrix Example

The last objective matrix summarizes transaction volume by process by location (from the process/location table) against each subject database from the data analysis. Two daily transaction volume estimates for each process and location are developed (see Figure 10-17). The first estimate is for transactions that create or update the database. The second estimate is for read-only retrieval processing. Also notice that if no database access is performed by a process, no entry is made. This increases the readability of each matrix.

The analysis of this data is to first identify the location with the highest total transaction count for each database. The example shows a thick box around each such location (see Figure 10-18). If the application were distributed, with centralization of subject databases in one location, the boxes would identify the most likely location for each database. All other transactions, outside the boxes, represent transmission traffic. When the transmission traffic is a high percentage of the total traffic, say over 40%, different types of replication, federation, and partitioning are tried. To analyze the data, first box the transaction numbers for the site(s) representing 50% or more of the total processing. If there is one site boxed in a column, that identifies a centralized database at the location corresponding to the box. We have two of these in the example (Figure 10-18) – the Work in Process and Inventory databases at location E. The initial recommendation would be to centralize this data at E. Even though D's volume is significantly less than E's, the data usage table shows that each site accesses only its own data, so the option to vertically partition data and provide 'home ownership' could be used to support the business needs.

The other databases all have access competition from two sites (Figure 10-18). Two locations, A and B, have fairly even usage of the Prospect and Customer, Customer Order, and Customer History data. The options from the Data Usage table show that Replication would be the distributed recommendation since the sites both access all data. Customer History processing differs from the other databases in that it is all read-only and it has a much lower volume than the others. Therefore, it could be centralized at either site with an access delay at the other site for retrievals. This option might be chosen if there are hardware configuration differences that favor centralization.

Locations Band E compete for the Manufacturing Plan data (Figure 10-18). Location B only retrieves the data, while the location E volume of updates is low. The database could either be centralized at B to provide fast query access, with delayed access by E, or, if politics are involved, the data could be centralized at site E, the owner, with delayed retrieval by B.

FIGURE 10-16 Data Distribution by Location Matrix

The second part of the analysis is to compute the ratio of data retrieval transactions (DR) to data update transactions (Du). If the ratio is greater than one less than the number of locations (L) (or nodes in the network), distribution should be considered (see Table 10-2). In the example, the ratio clearly favors centralization of data (Table 10-2). Keep in mind that centralization here means that each database is stored at one location. It does not mean that the databases are all at the same location.

If a delay can be introduced for retrieval processing, then the ratio changes. It becomes much easier to argue for distribution. Distribution should be considered when retrieval volume is less than the ratio of locations to the delay (D). The delay is for update transactions which are now transmitted in bulk once per period to each other location. In the example, with even a 15-minute delay, the numbers overwhelmingly favor distribution. The rationale for these ratios is given in Table 10-3.

This discussion about distribution is important because it highlights an ethical problem in software engineering. The numbers can be made to argue for distribution regardless of transaction activity. If the transaction ratio of retrievals to updates is large, then the no-delay argument is more likely to favor distribution. If the retrieval to update ratio is less than one, the delay argument is likely to favor centralization.

As an ethical person, you are bound to tell the client about all computations and how the formulae can make either argument. 

Last, a subjective list of reasons for and against centralization and distribution is developed for the organization. The exact topic headings for this list are tailored to the company and application environment.

FIGURE 10-17 Summary Transaction Volume Matrix

FIGURE 10-18 Analysis of Summary Transaction Volume Matrix

Each reason is rated as weak or strong justification of its position. The purpose of list creation is to surface and attempt to objectify objections and arguments from each stakeholder viewpoint regarding distribution of data in the application. An easy analysis is to count the capital and small letters of each type, and compare them. A more elaborate analysis might entail giving a weight to each item and developing a weighted ranking of the central/distributed positions. If the results of this analysis support the objective measures and results, a compelling justification for the result can be developed and presented to user management for approval. If the subjective analysis contradicts the objective measures, the user manager/champion might have to do some political maneuvering to obtain the desired result. Of course, if the champion is against the recommendation, the numbers in the traffic table still are useful in determining the size and speed of the machine and telecommunications lines required to service the application's data needs.

TABLE 10-2 Distribution Ratio Formulae

ABC Video Example Data Use Distribution and Analysis 

ABC's one location simplifies the choices for this analysis. Centralization of data and processes is the only possible choice. For the record, a table of transaction volumes is presented in Figure 10-19. A secondary issue, if not already decided, is hardware selection. ABC could use a multiuser minicomputer or a LAN. This analysis, too, is simple because ABC is a small company without a high volume of processing. A LAN is cheaper, more easily maintained, more easily staffed, and less costly {or incremental upgrades. Therefore, a LAN is the choice. Most multiuser mini-computers allow eight units without major expenditures for an additional I/O controller board. Mini-computers tend to have proprietary operating systems and use packages that tie the user to a given vendor. The strength of multiuser minis is in their added horsepower that allows them to support applications with a high volume of transactions (in the millions per day). A multiuser mini is not recommended here because, for the money, it would be analogous to buying a new Porsche 911 Targa when a used Hyundai would do just fine. To discuss configuration of the LAN, we move to the next section on hardware and software installation.

TABLE 10-3 Rationale for Distribution Ratios

FIGURE 10-19 ABC Transaction Volume Matrix

Define Security, Recovery, and Audit Controls

Guidelines for Security, Recovery, and Audit Control Planning 

The three issues in this section-security, recovery, and controls-all are increasingly important in software engineering. The threat of data compromise from casual, illegal acts, such as viruses, are real and growing. These topics each address a different perspective of data integrity to provide a total solution for a given application. Security is preventive, recovery is curative, and controls prove the other two. Having one set of plans, say for security, without the other two is not sufficient to guard against compromise of data or programs. Trusting individuals' ethical senses to guide them in not hurting your company's applications simply ignores the reality of today's world. Morally, not having planned for attempts to compromise data and programs, you, the SE, are guilty of ethical passivity that implicitly warrants the compromiser's actions. Therefore, design of security, recovery, and controls should become an integral activity of the design of any application. 

The major argument against security, recovery, and audit controls is cost, which factors in all decisions about these issues. The constant trade-off is between the probability of an event and the cost of minimizing its probability. With unlimited funds, most computer systems, wherever they are located, can be made reasonably secure. However, most companies do not have, nor do they want to spend, unlimited money on probabilities. The trade-off becomes one of proactive security and prevention versus reactive recovery and audit controls. Audit controls, if developed as part of analysis and design, have a minimal cost. Recoverability has on-going costs of making copies and of off-site storage. Each type of security has a cost associated with it. Keep the cost issues in mind during this discussion, and try to weigh how you might balance the three methods of providing for ABC's application integrity.

Security plans define guidelines for who should does not use chemicals near computer have access to what data and for what purpose. equipment. Access can be restricted to hardware, software, and data. There are few specific guidelines for limiting access since each application and its context are different. Those guidelines are listed here:

1. Determine the vulnerability of the physical facility to fire. Review combustibility of construction. Determine adjacent, overhead, and underfloor fire hazards. Determine the status of current fire detection devices, alarms, suppression equipment, emergency power switches, extinguishers, sprinklers, and smoke detectors. Determine the extent of fire-related training. If the facility is shared, evaluate the risk of fire from other tenants.

Plan for fire prevention and minimize fire threats by using overhead sprinklers, C02, or halon. Develop fire drills and fire contingency plans. If no emergency fire plans exist, develop one, reviewing it with the local fire department, and practicing the procedures.

2. Consider electrical/power facilities. Review electrical routing and distribution of power. Review the means of measuring voltage and frequency on a steady-state or transient basis. Determine whether operators know how to measure electrical power and can determine both normal and abnormal states. Define electrical and power requirements for the new application hardware and software. Determine power sufficiency for the computing environment envisioned.

Correct any deficiencies before any equipment is delivered. For instance, install a universal power supply (UPS) if warranted by frequent power fluctuations or other vulnerabilities.

3. Review air-conditioning systems and determine environmental monitoring and control mechanisms. Evaluate the 'housekeeping' functions of the maintenance staff.

Correct any deficiencies before any equipment is delivered. For instance, make sure the maintenance staff cleans stairwells and closets, uses fireproof waste containers, and does not use chemicals near computer equipment.

4. Determine the capability of the facility to withstand natural hazards such as earthquakes, high winds, and storms. Evaluate the facility's water damage protection and the facility's bomb threat reaction procedures.

Design the facility without external windows and with construction to withstand most threats. To minimize bomb and terrorist threats, remove identifying signs, place equipment in rooms without windows, and do not share facilities. To minimize possible storm damage, do not place the facility in a flood zone or on a fault line.

5. Evaluate external perimeter access controls in terms of varied requirements for different times of day, week, and year. Determine controls over incoming and outgoing materials. Evaluate access authorization rules, identification criteria, and physical access controls.

Plan the security system to include perimeter lights, authorization cards, physical security access, etc. as required to minimize the potential from these threats. Establish procedures for accepting, shipping, and disposing of goods and materials. For instance, shred confidential reports before disposal. Only accept goods for which a purchase order is available.

6. Evaluate the reliability and potential damage from everyday use of terminals and remote equipment from unauthorized employees.

Plan physical locking of equipment, backup copies of data, reports, etc. to minimize potential threats. Design remote equipment to minimize the threat of down-loaded data from the central database except by authorized users. Usually this is done by having PCs without any disk drives as terminal devices.

7. Evaluate the potential damage from unauthorized access to data and programs.

Protect programs and data against unauthorized alteration and access.

8. Evaluate the potential damage to the database from unwitting errors of authorized employees. 

Design the application to minimize accidental errors and to be fault tolerant (i.e., recovers from any casual errors).

In general, we consider internal and external physical environment, plus adequacy of data and program access controls. Security evaluation is a common enough event in many organizations that checklists of items for security review are available. 3 An example of general topics in such checklists follows:

Physical Environment

Electrical Power

Environment

Computer Facility Protection

Physical Access

An example of a detailed checklist for building access is provided next.

Facility type: Mainframe, LAN, PC, RJE, Remote, Communications

1. Are entrances controlled by

__ locking devices

__ guard force

__ automated card-key system anti-intrusion devices

__ sign-in/out logs

__ photo badge system

__ closed circuit TV

__ other ___________

2. Are controls in effect 24 hours per day? If

not, why?

___________

3. Are unguarded doors

__ kept locked (Good)

__ key-controlled (Better with above)

__ alarmed (Best with both of above)

4. If guard force, is it

__ trained (Good)

__ exercised (Better)

armed

5. Are visitors required to

__ sign in and out be escorted

__ wear distinctive badges

__ undergo package inspection

6. If building is shared, has security been

__ discussed (Good)

__ coordinated (Better)

__ formalized (Best)

7. Sensitive office areas, media storage, and computer areas 

__ Does access authority for each area require management review?

Is access controlled by

__ locking devices

__ guard force

__ automated card-key system anti-intrusion devices

__ sign-in/out logs

__ photo badge system closed circuit TV

__ other ___________

__ Are unique badges required?

__ Do employees challenge unidentified strangers?

8. Control Mechanisms

__ Do signs designate control/restricted areas?

If locks are used

__ is key issuance controlled?

__ are keys changed periodically?

9. Administration

__ Does management insist on strict adherence to access procedures?

Are individuals designated responsibility

for

__ access control at various control points

__ authorizing visitor entry

__ establishing and maintaining policy, procedures, and authorization lists

__ compliance auditing

__ follow-up on violations 

The probability of total hardware and software loss is low in a normal environment. In fact, the probability of occurrence of a destructive event is inversely related to the magnitude of the event. That is, the threat from terrorist attack might be miniscule, but the damage from one might be total. Each type of threat should be considered and assigned a current probability of occurrence. High probability threats are used to define a plan to minimize the probability. If the company business is vulnerable to bomb threats, for instance, buildings without external glass and without company signs are more anonymous and less vulnerable. Having all facilities locked at all times, with a specific security system for authorizing employees and screening visitors, reduces vulnerability even further.

The major vulnerability is not related to the physical plant in most cases; it is from connections to computer networks. The only guaranteed security against telecommunications invasion is to have all computers as stand-alone or as a closed network with no outside access capability. As soon as any computer, or network, allows external access, it is vulnerable to invasion. There are no exceptions, contrary to what the local press might have you believe. Data and program access security protection reduce the risk of a casual break-in to an application. Monitoring all accesses by date, time, and person further reduces the risk because it enables detection of intruders. Encrypting password files, data files, and program code files further reduces the risks; it also makes authorized user access more complex and takes valuable CPU cycles.

The most common security in an application is to protect against unwanted data and program access. Data access can be limited to an entire physical file, logical records, or even individual data items. Possible functions against data are read only, read/write, or write only. Users and IS developers consider each function and the data being manipulated to define classes of users and their allowable actions. Allowable actions are to create, update, delete, and retrieve data. A hierarchy of access rights is built to identify, by data item, which actions are allowed by which class of users. A scheme for implementing the access restrictions is designed for the application.

Backup and recovery go hand-in-hand to provide correction of errors because of security inadequacies. A backup is an extra copy of some or all of the data and software, made specifically to provide recovery in the event of some disaster. Recovery is the process of restoring a previous version of data or application software to active use following some damage or loss of the previously active copy. 

Research by IBM and others has shown that companies go out of business within six months of a disaster when no backup copies of computer data and programs are kept. In providing for major disasters, such as tornadoes, off-site storage, the storing of backup copies at a distant site, is an integral part of guaranteeing recoverability. Off-site storage is usually 200+ miles away from the computer site, far enough to minimize the possibility of the off-site facility also being damaged. Old salt mines and other clean, underground, environmentally stable facilities are frequently used for off-site storage.

The disasters of concern in recovery design are user error, unauthorized change of data, software bugs, DBMS failure, hardware failure, or loss of facility. All these problems compromise the integrity of the data. The most difficult aspect of recovery from the first three errors is error detection. If a data change is wrong but contains legal characters, such as $10,000 instead of $1,000 as a deposit, the only detection will come from audit controls. If a data change is wrong because it contains illegal characters, the application must be programmed to detect the error and allow the user to fix it. Some types of errors, such as alteration of a deposit to a bank account or alteration of a payment to a customer, should also have some special printout or supervisory approval required as part of the application design to assist the user in detecting problems and in monitoring the correction process. DBMS software frequently allows transaction logging, logging of before and after images of database changes and assisted recovery from the logs for detected errors.

DBMS failure should be detected by the DBMS and the bad transaction should automatically be 'rolled-back' to the original state. If a DBMS does not have a 'commit/roll-back' capability, it should not be used for any critical applications or applications that provide legal, fiduciary, or financial processing compliance. Commit management software monitors the execution of all database actions relating to a user transaction. If the database actions are all successful, the transaction is 'committed' and considered complete. If the database actions are not all successful, the commit manager issues a rollback request which restores the database to its previous state before the transaction began, and the transaction is aborted. Without commit and roll-back the entire database or software library. An incremental backup is a copy of only changed portions of the database or library. A week's worth of backups are maintained and rotated into reuse after, for example, the fifth day. To minimize the time and money allocated to backup, incremental procedures are most common. A full backup is taken once each week with incremental backups taken daily. An active database would be completely backed-up daily with one copy on-site for immediate use in event of a problem. Regardless of backup strategy, an extra copy of the database is created at least once a week for off-site storage. The extensiveness of backup (and recoverability) is determined by assessing the risk of not having the data or software for different periods (see Table 10-4). The less the tolerance for loss of access, the more money and more elaborate the design of the backup procedures should be. The severity of lost access time varies, depending on the availability of human experts to do work manually and the criticality of the application. In general, the longer a work area has been automated, the less likely manual procedures can be used to replace an application, and the less time the application can be lost without TABLE 10-4 Backup Design Guidelines for Different Periods of Loss Length of Loss 1 Week or longer 1 Day 1 Hour Type of Backup Weekly Full with Off-site storage Above + Daily Incremental/Full Above + 1 or more types of DBMS Logging capabilities, partial transactions might compromise 15 Minutes or less Above + All DBMS Logging Capabilities: database integrity.

Other data and software backup procedures are either full or incremental. A full backup is a copy of the entire database or software library. An incremental backup is a copy of only changed portions of the database or library. A week's worth of backups are maintained and rotated into reuse after, for example, the fifth day. To minimize the time and money allocated to backup, incremental procedures are most common. A full backup is taken once each week with incremental backups taken daily. An active database would be completely backed-up daily with one copy on-site for immediate use in event of a problem. Regardless of backup strategy, an extra copy of the database is created at least once a week for off-site storage. The extensiveness of backup (and recoverability) is determined by assessing the risk of not having the data or software for different periods (see Table 10-4). The less the tolerance for loss of access, the more money and more elaborate the design of the backup procedures should be. The severity of lost access time varies, depending on the availability of human experts to do work manually and the criticality of the application. In general, the longer a work area has been automated, the less likely manual procedures can be used to replace an application, and the less time the application can be lost without severe consequences. The less important an application is to the continuance of an organization as an on-going business, the less critical the application is for recovery design. An application for ordering food for a cafeteria, for instance, is not critical if the company is an oil company but is critical if the company is a restaurant.

TABLE 10-4 Backup Design Guidelines for Different Periods of Loss Length of Loss 1 Week or longer 1 Day 1 Hour Type

Last, we consider audit controls which provide a record of access and modification, and prove transaction processing for legal, fiduciary responsibility, or stakeholder responsibility reasons. Audit controls allow detection and correction of error conditions for data or processing. As new technologies, greater dependence on ITs, and interrelated systems that are vulnerable to telecommunications attacks all increase, business emphasis on controls also increases. In manual systems of work, control points are easily identified; procedures are observable, errors can be reconstructed, and controls applied by humans. In automated applications, the application is the solution, nothing is directly observable, and complexity of functions makes identification of control points increasingly complex.

A control point is a location (logical or physical) in a procedure (automated or manual) where the possibility of errors exists. Errors might be lack of proper authorization, misrecording of a transaction, illegal access to assets, or differences between actual and recorded data. Control points are identified during design because the entire application's requirements should be known in order to define the most appropriate control points. Controls are specified by designers in the form of requirements for program validation. For instance, controls for the validity of expense checks might be as follows: 

1. Only valid, preauthorized checks can be written. 

2. Check amounts may not exceed authorized dollar amounts. 

3. Checks may not exceed the expense report total amount.

Application audit controls address the completeness of data, accuracy of data, authorization of data, and adequacy of the audit trail. Detection of processing errors is either through edit and validation checks in programs, or through processing of redundant data. Examples of controlled redundancy of data include double entry bookkeeping, cross footing totals and numbers, dual departmental custody of replicated critical data, transaction numbering, and primary key verification. Edit and validation rules are designed to identify all logical inconsistencies as early in the process as possible, before they are entered into the database.

ABC Video Example Security, Backup/ Recovery, and Audit Plans 

To design ABC's security, we first review the physical plant and recommend changes to the planned computer site to provide security. The six threats are considered, but the byword from Vic in discussing the possibility of changes is "be reasonable." So, if there is a 'reasonable' chance that a problem will occur, we will recommend a reasonable, and low cost, solution to the problem.

Moving from most to least serious, we consider the six types of threats to application security: location failure, hardware failure, DBMS failure, software failure, hacker change, and user error. For each threat, we consider the potential of occurrence for ABC, then devise a plan to minimize the potential damage. All threats and responses are summarized in Figure 10-21.

FIGURE 10-20 ABC Current Physical Plant

First, we review the physical plant and relate it to location and hardware failures. ABC Video is located in suburban Atlanta, Georgia, 300 miles from the ocean and 25 miles from the nearest large lake. The company is located in a mall, the Dunwoody Village, a clustering of small shops and offices in open-square buildings containing a plaza in the middle of the square. The company occupies 3200 square feet of 80' x 40' space in the southeast corner of Building A. The adjoining spaces are occupied by Cheap's Drugs and Ra-Dan Hair Salon. A schematic of the space is shown in Figure 10-20.

The northeast corner of the area (abutting Ra-Dan's) contains a 12' x 16' office which contains two desks, one supply closet, and a bathroom. The office has no windows and can be locked, although it is frequently empty and unlocked. The supply closet has double doors which do not currently have a lock. 

The clerk's checkout counter is near the customer doors on the south side of the building in the western corner. The counter is an 'L' shape with the entry on the short side. A fire door, equipped with an alarm bar, is located in the northwest corner of the area and opens on a short alley behind the building.

Location failure usually results from violent weather, terrorist attacks, or government takeover. The chance of violent weather is the only potential major problem in the area. Tornadoes occur in the area regularly. The expectation is that there is a 20% chance of tornado damage some time in the next 10 years (see Figure 10-21). Tornadoes also imply strong thunderstorms which are common to the area. The chance of damage from a storm is about 30% within five years to the windows, and about 65% within two years for lightning to cause electrical spikes.

The response to location threats is to provide offsite backup of all information, with the site far enough away that it is unlikely to be affected by the same storm (see Figure 10-21). Vic should investigate the possibility of closing in the window wall in the southeast side of the building to minimize storm damage. He can also install lightning rods on the roof of the building to dissipate lightning when it hits. 

The next category of problems relate to the hardware selected for the rental/return application. Vendor-cited reliability is 99 years mean time between failure (MTBF) for individual components. When the components are considered as a whole, the probability of component failure is once in two years (see Figure 10-21). The current plan is to have an extra PC in the office that could be moved to the front desk if needed. A hardware service contract with a local company to provide response within 24 hours is recommended. 

The planned server location is near the bathroom in the northeast corner of the area. The toilet has a history of overflows during wet spring months. Because of the way the office was constructed, the water is confined to a small area but almost always runs into the supply closet and has been as high as one foot. The probability of component failure to file server and/or disks from water due to toilet overflow is 50% in two years. The answer to this problem is simple, but expensive: Build a new area, specifically for the computer, away from the toilet area to reduce this probability to near zero. Ideally, if the windows are closed in, the office could be moved to the front of the building and the old office removed. A new enclosure for the toilet facilities could be added or the toilet could also be rebuilt in the new location with whatever precautions are needed to preclude the spring overruns. 

There is another problem with the planned server location. The planned location-the supply closet has no ventilation. If the closet doors are open, ventilation for the office is sufficient for the planned equipment, but, ideally, the server closet doors should be locked. If the doors were locked, the probability of server failure due to lack of ventilation is 50% in two years. The solutions possible are to build a new area for the server equipment, or to add ventilation to the planned area to reduce this probability to near zero. Both solutions should be presented to Vic for his decision.

Less serious problems stem from the building location. Glass windows that run along 60' of the external front wall and the drop ceiling are accessible from neighboring companies. Theft and break-ins are somewhat common in the area, but the probability of a break-in is 50% in 10 years. Most burglars are looking for money, but some might maliciously tamper with the computer equipment. Therefore, the probability of computer damage during a break-in is 60% according to police estimates. 

The recommendations to minimize theft have to address the easy access to the company through windows and ceiling. If the office remains in its current location, a security system with movement sensors in the ceiling and glass-breakage sensors on all windows should be added (whether or not the computer is installed). Long-term, Vic should investigate the possibility of closing-in some or all windows to improve security of the company.

Next, because of the location of the checkout desk at the front of the building, the ability of clerks to monitor approaches to the office is low due to limited visibility. Further, theft of tapes is possible because clerks cannot see down all aisles without moving away from the desk area. For application security, we are concerned with office access; but, as professionals, we can make recommendations that will improve Vic's ability to reduce general theft as well. An easy, but somewhat expensive solution is to move the checkout desk to the center of the floor and assign surveillance duties to clerks. Even if the desk is not moved, mirrors installed in the corners of the room would allow clerks to monitor customers' actions. Both recommendations are made with the understanding that the mirrors should be installed whether or not the desk is moved.

FIGURE 10-21 Security Review Findings and Recommendations (Continued)

After physical issues are evaluated, we next look at software security and reliability. Vendor-stated reliability for the planned DBMS is two years MTBF. This SQL software is one of the best on the market, but each new release is unstable for at least six months, and those instability figures are not in the MTBF estimates. The company routinely disclaims any responsibility for new release errors and loss of data or processing to using companies. The DBMS does stabilize and is usually reliable after a six-month trial period for each new release. The simple solution to this problem is that unless a feature of a new release is needed, no change from the current stable version should be made. In addition, no software, whether vendor package or customer designed, should be allowed into production use until it is thoroughly tested using the application regression test package that will accompany the system.

A secondary problem with DBMS errors is that, if the DBMS fails, there is no other way to access the data. Part of the contract negotiation should include discussion of such software for the vendor to provide in event of DBMS failure. Other companies have successfully received such commitments from this vendor, although not voluntarily. Such data access software should be included in the vendor contract. 

Additional problems that might cause DBMS failure are electrical surges and brownouts due to uneven service in the area. Surges generally occur during the summer months when equipment comes on-line to service air-conditioning in the area. The probability of surges is 100% based on local electrical company history. The probability of brownouts with reduced power is 30% within two years, also using electrical history as the basis for the estimate. Problems from both causes can be minimized by a surge protector on the entire ABC electrical system which shuts down power if a particularly large surge is experienced. In addition, one surge protector for each outlet should be installed to further protect the equipment since whole system protectors do not guarantee integrated chip safety. Finally, a limited, inexpensive, uninterrupted power supply (UPS) should be installed to provide emergency power in the event of electrical failure and for limited use during brownouts to supplement reduced electricity from the local provider.

We consider application software failures next. Failure due to software defects should be less than once in 15 years after the first three months of operational use. During the first three months of operation, the probability of application failure is about 75%; no more than one is expected. The application is designed for IS-minute recovery of all data and programs. Loss of partial transactions will always occur with any failure; they will have to be reentered. Program problems will be fixed within one business day. Any lost transactions will be reentered free of charge by Software Engineers Unlimited (Mary's company). 

Outside user access to the system should be zero since no telecommunications capabilities are planned. However, the untended server and occasional lack of clerks at the desk area may provide a local hacker enough time to access and modify the system. If the physical security precautions recommended above are provided, such hacker break-ins would be nearly impossible. Therefore, at a minimum the precautions for security mirrors, assigning clerks monitoring responsibility, and locking the office and file server doors should be implemented (see Figure 10-21). 

Finally, the use of computer novices as clerks guarantees user errors. The probability of user errors is 100% within one week of system operation. To prevent any application or DBMS damage from user errors (inadvertent or otherwise), the first line of defense is to restrict what users may do and the data they may access as a way to prevent errors. Each job should be defined and a security access scheme developed to allow access to all processes and data required for the job, and nothing more.

Second, the application should withstand any casual error-hitting of any key on the keyboard, scanning any barcode type, and so on. If required, a report of such errors can be created and printed on demand by Vic to allow retraining (or other action) for repeated errors by one user. Application design also includes validation of all fields such that only valid data can be in the database. Such checks are not possible for alphanumeric data, however, so on-demand reports of new customers and video entries will allow Vic to monitor the typing skills of employees. 

Application training will use computer-based training (CBT) in entering application data. The CBT will use simulated transactions and should minimize the user errors if taken seriously by clerks. \ New-hire orientation should include discussion of the importance of accuracy of work, especially with the computer. Further, new hires should be assigned a more senior 'mentor' for learning the application after training.

After disaster recovery is planned, application security must be developed. From the recovery plan, we know that each job should be evaluated to determine the data and processing requirements of the position. ABC jobs evaluated include clerks, owner, and accountant. The owner should be allowed to do any functions on the application and system that he desires. However, many owners do not want to become the chief user of the computer. When asked, Vic's reaction is, "Does this mean I can never take a vacation? Do I have to be here in the morning and at night? If so, define a new position that can do most of my functions, just not delete data!" So the position of chief clerk is also considered.

FIGURE 10-22 ABC Data Security Hierarchy of Access Rights

The owner should be the lead person and still be allowed to perform all functions, access all data, and provide security password changes, and so on (see Figure 10-22). The chief clerk, according to Vic's wishes, has all of those functions except deleting information (see Table 10-5). If there were sensitive data in the system, more discussion of the chief clerk's duties and access rights might take place. The clerks have access rights to rent and return videos, and to create and update customers and videos. Finally, the accountant has limited read-only access to several files.

Backup and recovery are considered next. First we decide the maximum tolerable time loss for a computer outage, then select the backup scheme that best fits the time loss maximum. The rental/return application is critical to ABC's ability to conduct business. Vic knows that when he moves all production work to the computer that the clerks will quickly forget the manual way of conducting business. Also, we know that if the databases are not kept up to date, the system is next to useless because the clerks won't know whether to look at manual or automated files for returns, fees, and so on. Therefore, the maximum outage should be less than 15 minutes with recovery of all fully complete transactions. Even at 15 minutes, if an outage were to occur during a peak time, as many as four transactions could need to be reentered and as many as 15-20 transactions would be queued for entry upon system return to production. Ideally, the system should be functional during all business hours. 

The recovery requirements imply the most backup protection possible. From Table 10-4, a 15-minute recovery requirement means the use of weekly full backups with off-site storage, daily backups, and logging for transactions, preupdate data items and postupdate data items. Therefore, these are the backup and recovery requirements.

Requirements: Application and system availability during all store open hours, with no more  than 15 minutes of down-time from failures of any type.

Backups: Transaction, preupdate, and postupdate logs

Transaction logs maintained one week until weekly backups are verified. Pre- and post-update logs maintained for 72 hours.

Daily complete database backups with onsite copy plus off-site storage at owner's

home. 

Paper copy of transactions maintained for one calendar year in accountant's office.

Weekly complete disk backups with on-site copy plus off-site storage at owner's home and a

third copy at

TABLE 9-5 ABC User Classes and Access Rights

If ABC's application processed millions of transactions each day, we would do further analysis of the cost of backup and recovery, but here that is not necessary. 

Finally, we need to decide about audit controls as summarized here: 

Data accuracy and completeness – All edit checks possible will be used as data are entered to prevent errors from entering the system. Sight verification by clerks and customers will be used to verify alphanumeric information.

Rental transaction accuracy can be verified by customers' signing for all monetary transactions. In case of discrepancy, transaction logs and historical paper copies of transactions can be consulted.

Data authorization-Security controls will provide sufficient authorization for data processing. Only the owner is authorized to perform any delete functions on customer, video, and open rental data. No delete functions for history records are provided. 

User ID, date, and time of user to last change data will be maintained in Customer, Video, and Open Rental databases.

Audit trail – A paper trail of receipts should be maintained by the accountant for each calendar year. This is a sufficient trail since ABC is a cash business without any accruals. Nonmonetary transactions (e.g., return of on-time tapes), have no paper audit trail. If a question about a tape return arises, the database can be checked to verify the information.

All edit checks possible should be used as data are entered to prevent errors from entering the system. To ensure complete editing, we review the data dictionary to check that all non-alphanumeric fields have edit and validation criteria. 

On names, addresses, and other alphanumeric fields, little verification can be performed automatically. What cannot be done automatically should be done manually. Procedures for operators should be developed to document clerical 'sight verification' and customer verification standards. An example of such a procedure that would be part of the user manual is shown as Figure 10-23. Sight verification means that the person entering information into the computer reads the monitor to verify the accuracy of the information he or she entered. The user, then, is responsible for data integrity of items that cannot be computer verified.

FIGURE 10-23 User Sight Verification Procedure

Rental transaction accuracy will be verified by customers' signing for all monetary transactions. In case of discrepancy, transaction logs and historical paper copies of transactions can be consulted. If many discrepancies persist (more than one per week), a special history file of transactions can be added to the application to speed the transaction look-up process. 

Security controls can be designed to provide sufficient authorization for data processing. The security scheme should be developed to serve two goals: to provide data access and to provide function access to those who need it. To require several layers of security checking for a simple application does not make sense and wastes clerical time. So, once again the KISS (Keep It Simple, Stupid) method of one security access scheme is best. User ID, date, and time of user to last change data will be maintained in Customer, Video, and Open Rental databases. These attributes are added to affected database relations.

To minimize the extent to which damage can be done to data, only ABC's owner should be authorized to perform any delete functions on customer, video, and open rental data. No automated delete functions for history records are provided without circumventing the application completely. Changes to files will always be somewhat traceable because the historical record will reflect activity. If unauthorized file changes are thought to be a problem, Vic can always request a browsing capability for any of the transaction logs to check on problems. 

A manual audit trail should be used for ABC to conserve computer resources. All monetary transactions can be reconstructed through a paper trail of receipts maintained by the accountant. The receipt form is a two-ply preprinted form on which all monetary transactions are printed. For rentals, customers sign the form as proof of rental responsibility. Paper records should be maintained for one calendar year in the accountant's office; this is sufficient since ABC is a cash business without any accruals. If a tape audit trail were to be necessary at some time in the future, it can be added to the system easily.

Nonmonetary transactions (e.g., return of on-time tapes), have no paper audit trail. If a question about a tape return arises, the user ID, date, and time of the return will be on the database and can be checked to verify the information.

Develop Action Diagram

Guidelines for Developing an Action Diagram 

An action diagram is a diagram that shows procedural structure and processing details for an application. It is built from the process hierarchy and process data flow diagram developed during IE analysis (see Figure 9-45 for ABC's PDFD). The diagram uses only structured programming constructs to convert the PDFD into a hierarchy of processes that can be divided into programs and modules. First we discuss the components of the diagram, then we discuss how to build an action diagram from the process hierarchy and PDFD.

Action diagrams use different bracket structures to depict the code elements in an application. Basic structured programming tenets-iteration, selection, and sequence-are all accommodated with several variations provided. As Figure 10-24 shows, a sequence bracket is a simple bracket. It is optionally identified with a process name and ended with the term ENDPROC to represent a program module consisting of a sequence of instructions. 

When a module is designed and detailed in another document or diagram, a rounded rectangle containing the module name is drawn between the brackets (see Figure 10-25). When the module is not yet defined in detail, a rounded rectangle with question marks down the right side is shown. Reusable modules are drawn with a vertical bar to represent reuse.

FIGURE 10-24 Simple Sequence Bracket Format

FIGURE 10-25 Module Designation Format

Selection of modules from the PDFD is shown by a selection bracket (also called a condition bracket) which begins with an IF condition and ends with the term ENDIF (see Figure 10-26a). If the conditional statement has multiple conditions, two other options are allowed. The condition can be stated as an IF statement with one or more ELSE conditions (see Figure 10-26b), or a condition can be stated as a mutually exclusive selection list as in Figure 10-26c; this selection list is eventually translated into an IF statement. 

Repetition is shown with a double bracketed figure. The repetition bracket name begins with either DO or DO WHILE + condition (see Figure 10-27). The bracket ends with either an UNTIL + condition(Figure 10-27a), or ENDDO (Figure 10-27b). DO WHILE implies that the condition is checked before the conditional statements are executed. Do while processing may occur zero times. Conversely, DO UNTIL implies that the condition is checked after the lower statements are executed. Do until processes occur at least once. 

Miscellaneous items include goto, exit, and concurrency identification. A goto is shown by an arrow leaving one level and pointing to the line for the destination level with a goto statement and destination at the right of the arrow (Figure 28a).

An exit is shown as an arrow leaving one level and pointing to the line for the destination level with the word exit at the right of the arrow (Figure 28b). Unless an exit destination is named with the exit, exit always means that the calling module is the exit destination. For example, if Rent/Return calls CustomerAdd, the exit from CustomerAdd returns to Rent/Return. Further, if CustomerMaint calls CustomerAdd, the exit from CustomerAdd returns to CustomerMaint. That is, the calling module, regardless of what it is, is the return module. 

Processes can be sequential or concurrent. Concurrent processes execute at the same time. There are two types of concurrent processes: independent and dependent. Independent concurrent processes are those which execute at the same time but do not synchronize their process completion. For example, when Process Payment and Compute Change is complete in ABC's application, printing and file updates of several types could all be concurrent. If there is no checking on the success of their completions with subsequent action for any failures, these processes are independent. Independent concurrency is shown on the diagram by an arc which connects the module brackets (Figure 10-28). Dependent concurrent processes are those which must be synchronized to coordinate further application actions. Dependent concurrency is shown on the diagram by an asterisk (or some other special character) on the arc connecting the modules (Figure 10-28d). Dependent concurrent processes require the development of a synchronization module, if not already in the application, to ensure complete, accurate processing.

Now that you know the bracket symbols used to define action diagrams, we move to discuss the steps to developing one. The steps to define an action diagram are to translate processes into levels of action using structured constructs, design modules, perform reusability analysis, decide module timing, add data to the diagram, and optionally, add screens to the diagram.

FIGURE 10-26 Conditional Bracket Design Formats

The first step is to translate processes into levels of action. The first-level diagram is developed from the process hierarchy diagram to identify the major activities being performed by the application. The activities themselves are added to the diagram as they are written on the hierarchy diagram. The structured constructs should identify sequence and any selection or conditional processing relating to the activities. Most often, when the diagram is begun at the activity level, the alternative processes are mutually exclusive. When the diagram starts at the process level (Figure 10-29), any construct might apply. The example shows a mutually exclusive selection from among the three alternatives. 

Now we shift to the process data flow diagram (Figure 10-30) to add process details to the action diagram. Remember that the processes on the PDFD must match exactly the processes on the hierarchic decomposition diagram. We use the PDFD to translate the structural relationships between the processes correctly. The structural relationships are on the PDFD and not on the decomposition; they refer to the sequential, conditional, and repetitive relationships between processes.

FIGURE 10-27 Repetition Bracket Design Formats

In developing the second-level action diagram, we first add the processes, in sequence, from the PDFD. Then the brackets are drawn to reflect the sequential, conditional, and repetitive structural relationships. In the example (Figure 10-31), the main processes are Identify Item and Vendor, Sort by Vendor and Item, Get Price, Create Order, and Mail Order. Between these processes, there are two repetitive blocks: one based on New Releases, and the other based on Vendors (see Figure 10-32). We identify the repetitive blocks by looking at the circular loops and the conditions for repeating the process(es}. Notice that the Sort is not included in either loop.

Next, evaluate each process grouping. Identify Item is alone within its loop. Sort is also alone. The last three processes are together and are analyzed. The processes are sequential but according to the PDFD, they are not all processed in sequence. If the vendor has not changed from the previous item, we Get Price and Create Order. When the Vendor changes, we File and Mail the order. These statements from the PDFD translate into the IF conditional statement in the action diagram as shown in Figure 10-33.

The diagram is correct in interpreting the PDFD, but it is incomplete as a program specification. First we need to deal with the First Vendor. The First Vendor will not equal Last Vendor, and to file an order for a nonexistent vendor is wrong. Second, think about what an order looks like (Figure 10-34). There are one-time Vendor information and variable lines of Item information. Where the PDFD says Create Order, it really means Add Item to Order. When the Vendor changes and an order is complete, we want to format Vendor information for the new order. Figure 10-35 reflects these details and is ready for the next step. The purpose of this example is to show how a correct PDFD may need elaboration to translate into program specifications.

FIGURE 10-28 Miscellaneous Bracket Design Formats

FIGURE 10-29 Process Hierarchy and First-Level Action Diagram

U sing the action diagram, modules are defined. There are few guidelines on this aspect of Information Engineering. In general, you should try to define modules that perform one well-defined process and nothing else. The guidelines presented in Chapter 8 for module definition can be applied here. For the example in Figure 10-35, the IF ... ELSE IF ... ELSE processing is the module's control flow. Within the control flow we have stand-alone processes that conveniently define modules. Figure 10-36 shows the module names, each enclosed in its own rounded rectangular box to indicate that there are more details for each module. The submodules are each further diagrammed or, if fully documented in a data dictionary, refer to the dictionary entry in the module box.

For Create Purchase Order processing, then, we have a main module and submodules for Create Vendor Info, Get Price, Create Order Item, File Order, and Mail Order. Notice that Create Vendor Info is used twice. 

Next, the action diagram modules are compared to templates already in use to determine whether reuse of existing modules is possible. As reusable modules are identified, the process details are removed from the action diagram and replaced with a call statement. The called module name should indicate whether the reused module is customized for this application or not. The conventional way to identify customized reused modules is by a prefix or suffix on the name. For example~ a date compare routine might be used to determine lateness. If not modified, the name of the routine might be DateCompare. If customized, the name of the routine might be RentDateCompare or LateReturnDateCompare. In the example in Figure 10-36, Sort uses a utility program, a special class of reusable module. The Sort statement is removed from the diagram and replaced with a call statement. No other modules in this example are general enough for reuse. 

FIGURE 10-30 Sample Process Data Flow Diagram

FIGURE 10-31 Second-Level Action Diagram

When reusability analysis is complete, the action diagram should show the mainline logic of the application with modules for the processes and subprocesses. At this point, timing of processes is decided and added to the diagram. Recall that processes can be sequential or concurrent, and that concurrent processes can be either independent or dependent. Frequently, user requirements will identify required concurrency. If no user requirements identify concurrent operations, a design decision to offer or not offer concurrency is made by the SEs. Concurrency is expensive and adds a level of maintenance complexity to the application that the user might not want.

Optional concurrency is determined by evaluating module interrelationships again. Only groups of sequential modules are evaluated at first. Then the groups themselves are evaluated for possible concurrency. In Figure 10-36, two groups of two or more modules are present. The first is Get Price with Create Order Item. The second group is File Order, Mail Order, and Create Vendor Information on Order. Working backward, we ask if the modules are dependent on each other. Could we create an order item without knowing the price? In this case, the answer is no, we must know the price. Therefore, the modules are dependent and cannot be concurrent. In the second group, we might perform File and Mail Order at the same time, IF success of the file operation is not an issue. Create Vendor cannot be done until the last order is fully processed. To decide on concurrency, we need to know the details of error handling. In this case, we find that errors are checked and handled in the module in which they can occur. If a fatal error occurs, the application does no other processing on this order. This process definition implies sequence to the processes. If the processes were concurrent and a fatal error occurred, some undesired processing would occur. Therefore, in this example, concurrency is not an option.

FIGURE 10-32 Repetitive Blocks on Second-Level Action Diagram

FIGURE 10-33 Conditional Statements on Second-Level Action Diagram

Order at the same time, IF success of the file operation is not an issue. Create Vendor cannot be done until the last order is fully processed. To decide on concurrency, we need to know the details of error handling. In this case, we find that errors are checked and handled in the module in which they can occur. If a fatal error occurs, the application does no other processing on this order. This process definition implies sequence to the processes. If the processes were concurrent and a fatal error occurred, some undesired processing would occur. Therefore, in this example, concurrency is not an option.

FIGURE 10-34 Order Example

Next, the entities and data elements used by the processes are added to the diagram(s). By the time this action is complete, every attribute of every relation must, at least, have been identified for creation and deletion. Any attributes not included in the processing should be reconsidered for elimination from the application. These process definitions should include attributes added to the relations as a result of design activities. 

If the action diagrams are developed manually, screen identifiers can be added to the diagram with entities and attributes linked to screens (see Figure 10-38). The diagram then links data sources and destinations to both processes and screens. This type of diagram does manually what linkages in a CASE tool automate.

ABC Video Example Action Diagram 

The steps to developing the action diagram are to develop the levels of action using structured constructs, perform reusability analysis, design modules, decide module timing, add data to the diagram, and optionally, add screens to the diagram. Only the first-level action diagram includes all of the processes. The lower-level diagrams consider Rent/ Return processing and Video Maintenance only. The other processes are left as an exercise.

FIGURE 10-35 Order Format Details on Action Diagram

The first-level action diagram is based on the process hierarchy (Figure 10-39). First we draw the general bracket and add the module names, indicating the structural relationships between the modules by the bracket type (Figure 10-40). In the ABC diagram, the processes are all mutually exclusive. 

Then, using the PDFD as reference (Figure 10-41), we develop the next level of procedural detail. The subprocess names are added to the diagram as shown in the PDFD (and process hierarchy). For each subprocess, the structural brackets indicating modular control are added.

The subprocesses for Video Maintenance are for create, retrieval, update, and delete processing. These processes are all mutually exclusive, so the diagram is simple (Figure 10-42). At the lowest level, we identify modules that refer to the dictionary for process details. 

Rent/Return has all of the complexity in the application. Each cluster of modules is discussed separately. First, Get Request is always executed whenever Rent/Return is invoked (Figure 10-43).

FIGURE 10-36 Module Boxes on Action Diagram  FIGURE 10-37 Data Addition to High Level Action Diagram

Then the conditional statement for determining the type of request is added (Figure 10-43). The two options are If Customer and If Video ID, and each has its own processes. 

Next, Open Rentals are read and displayed until all Open Rentals for this customer are in memory (Figure 10-44). The Open Rental loop is a simple Do While process.

Then video returns are processed using a repetition with a conditional structure (Figure 10-45). Late fees are checked in a repetitive loop for all Open Rentals (Figure 10-46). New rental Video IDs are entered for all new rentals (Figure 10-47). Process Payment and Make Change is a stand-alone module. Then, for all open and new rentals, the Open Rentals file is updated; for all of today's returns, history is updated; and if payment is made or a user requests, a receipt is printed (Figure 10-48). The consolidated action diagram is shown in Figure 10-49.

Next, evaluate the diagram to identify program modules. As in the example above, we have naturally identified modules as part of process definition. For instance, Get Valid Customer is a small, self-contained module that does one thing only. The module uses a Customer ID to access the Customer relation. If the entry is present, the credit is checked. The name, address, and credit status are returned. The remaining modules, that we originally defined as business processes doing one thing, should each be reviewed to ensure that they are, in fact, single purpose. This is left as a class activity.

In addition, we can now resolve the issue held over from analysis about whether to keep separate or consolidate Get Open Rentals, Add Return Date and Check for Late Fees. Individually, each of these processes is singular (i.e., does one thing). If they are consolidated, they would remain singular but be placed within the same repetition loop. The issue here, then, is which method is easier to program and implement in the intended language, and which provides the better user interface. We need to visualize the user interface and memory processing for each alternative.

FIGURE 10-38 Optional Screen Processing on Action Diagram

If the modules are kept separate, all Open Rentals are read first and displayed. Then the clerk can be prompted for new videos or for returns. If we prompt for returns every time, many wasted entries to deny return processing will be made. If we prompt for either new or return Video IDs, we need a method of knowing which is entered. Assuming we figure that out, we then get all returns and enter today's date for returned videos. Then all entries on the screen are scanned to determine new late fees.

If the modules are consolidated, as each Open Rental is read, Late Fees are computed for tapes with return dates and no late fees (see Figure 10-50). There are two options for this process. Either we assume there are no more returns or the clerk must respond to each Open Rental. With the first option, the clerk would have a selectable option for more return processing. When chosen, each return Video ID is entered and Late Fees are computed for that video.

FIGURE 10-39 ABC Video Process Hierarchy Diagram

Notice that both alternatives have problems. The separation alternative has a problem in dealing with returns, and there will be a slight delay for Late Fee processing. The consolidation option actually modifies the processes from the PDFD somewhat for Late Fee processing.

Data storage for a rental in memory is the same for both alternatives. We need a location for customer information, a table for open rentals, a table for new rentals, and locations for payment information. We will have three iterations through the table for Open Rentals in the separate alternative, and one, or two if returns are present, iteration(s) in the consolidated alternative.

The alternatives are approximately the same in implementation complexity, although three iterations are more likely to contain bugs than one. The human interface design is the same for both alternatives. The difference in the human interfaces is the speed and timing for data to appear on the Open Rentals lines. In this case the consolidated alternative is slightly faster. The difference in memory processing is the number of iterations through Open Rental data. Again, the consolidated alternative is preferred somewhat because it is less likely to contain bugs. With no overwhelming evidence for or against either alternative, this amounts to a judgment call. We will choose the consolidated alternative to minimize the probability of errors and the number of iterations through the data. The action diagram, reflecting consolidated open rental processing, is in Figure 10-50.

FIGURE 10-40 ABC First-Level Action Diagram

The next activity is reusability analysis. ABC has no library of reusable modules to consider since it currently has no computer processing. The types of modules the consultants are likely to have might be relevant to error processing or to screen interactions. For our purposes, we assume no reusable modules. 

To assess module timing, we analyze the module clusters. The only modules that could be concurrent are those in the last cluster to update files and print a receipt. Before deciding concurrency, we must decide the details of history processing that were deferred from analysis. We have two types of history files: Customer and Video. Customer History is a separate file that contains the Customer ID and all Video IDs rented by that customer. No counts, dates, or copy information are anticipated. This description complies with the case requirements in Chapter 2.

Video History contains Video ID, Copy ID, Year, Month, Number of Rentals, and Days of Rental for each entry. This data description also complies with the case requirements in Chapter 2. The issue to be decided is whether or not Video History is maintained during on-line processing, or if the current month's activity is kept with Copy information. If the second alternative is chosen, we need a monthly process to update the Video History and reinitialize the counts in the Copy relation. If the first alternative is chosen, we have two more alternatives. First, we might need to update and create processing because, for anyone to copy, we would not know in advance whether it has a historical entry or not. This alternative requires bug-prone processing that is more complex than keeping counts in the current Copy relation. Second, we could create an empty entry for every tape at the beginning of every month. This alternative is not attractive because it generates many empty records on history. Both of these alternatives would require history to be on-line. Keeping current counts with Copy relations does not require history to be on-line. The final argument for keeping the counts in Copy information is that, to maintain status of a given tape, Copy information must be updated upon video return anyway. As long as the tuple is being read, updating it with count information requires adding lines of code rather than a new module. From this discussion, it should be clear that keeping current counts in the Copy relation is the preferred alternative. We document this and the other changes in the Data Dictionary.

Now we can discuss module timing for the last group of modules. In this group we create and/or update Open Rentals, update Copy, and Print Receipt. Recall from analysis that Vic does not want file update success to be known to the customers. The receipt should be printed regardless of updating success. This implies that printing could be concurrent with the file processes. The file updates cannot be concurrent because they will all be on the same device. Since there is already contention for the file among the users, it is unlikely that we would want to increase contention by having the updates concurrent. If printing is the only concurrent process, it is not worth the cost to provide concurrency. Therefore, the processes will be made sequential for production operation. Figure 1 0-50 is not changed at this point.

FIGURE 10-41 ABC Video Process Dependency Diagram

The entities and data attributes are added to the diagram next to show input and output processing. Two entities, EOD and Rental Archive, are still undefined, having been deferred in analysis. These are left as an exercise. The entities referenced in Rental/Return processing, Customer, Open Rental, Video, Copy, Customer History, and EOD are all shown in Figure 10-51. When an action diagram arrow is from an entity to a process, it means that the entire tuple is accessed. The final action is to add screens to the action diagram, but they are not yet defined, so this activity will be left as a future exercise.

FIGURE 10-42 ABC Video Maintenance Second-Level Action Diagram

Define Menu Structure and Dialogue Flow

Guidelines for Defining the Menu Structure and Dialogue Flow 

The interface structure includes design of a menu structure and design of dialogue flow within the menu structure. Both designs are based on the PDFD and process hierarchy diagram developed during IE analysis. 

First, the menu structure is developed. Recall that the menu structure is a structured diagram translating process alternatives into a hierarchy of options for the automated application. The task hierarchy is analyzed to define the individual processing screens required to perform whole activities, and to identify the other processes and activities in the hierarchy which must be selected to get to the processing screens.

Let's walk through the development of the sample menu structure shown in Figure 10-7. The related process hierarchy diagram is shown as Figure 10-52 with the individual processing screens, selection alternatives, and hierarchy levels identified. For each level in the hierarchy, we identify a level of menu processing. Using simple bracket structures to translate from the top to the bottom of the hierarchy, we first define the options for the first level menu (see Figure 10-53). Next, the menu options for the first process level of the hierarchy are shown in Figure 10-54. Finally, the remaining detailed processes are added to the diagram (see Figure 10-55). 

If, for any reason, the hierarchy or lower-level processes are in doubt, review the proposed menu structure with the users before proceeding. If the process hierarchy diagram is accepted as correctly mirroring the desired functions in the application, proceed to the next step, defining the movements between menu items.

FIGURE 10-43 Request Processing Action Diagram Constructs

FIGURE 10-44 Open Rental Action Diagram Constructs       FIGURE 10-45 Video Returns Action Diagram Constructs

Traditionally, applications were constrained to moving top-to-bottom-to-top with no deviation. Anyone who uses such an interface for long knows it is irritating to wait for some menu that is unwanted and to enter choices purely for system design reasons. The decisions should relate to application requirements as much as possible. For instance, security access control requirements can be partially met by restricting movement to functions as part of dialogue flow. The decisions about legal movement should be made by the users based on recommendations by the designers; although frequently, dialogue flow decisions are made by the SEs. In general, if the users are functional experts, an open design that allows free movement should be used. If users are novices or not computer literate, a more restrictive design should be used to minimize the amount of their potential confusion. 

Figure 10-56 shows types of arrows used to depict movement between levels of a menu structure. In a small diagram, with less than ten screens, only single-headed arrows are used, and at least two arrows are drawn for each entry: one entering and one leaving (Figure lO-56a). In a large diagram, with over ten screens, the triple-headed arrows can be added to the diagrams to depict call-return processing (Figures lO-56b and lO-56c).

FIGURE 10-46 Late Fee Action Diagram Constructs      FIGURE 10-47 New Rentals Action Diagram Constructs

An example of restricted screen movement that might be designed for novice users is shown in Figure lO-57a. In the diagram, all movement is to or from a menu. The diagram in Figure lO-57b shows that any level of upper menu might be reached from the lower levels. This speeds processing through menus and is preferred to the design shown in Figure lO-57a which only allows a process to return to the menu level from which it was activated. Restrictive dialogue flow (Figure lO-57a) is the type of design that is most likely to waste user time and become annoying. 

Experts and frequent users usually are provided more alternatives for interscreen movement because they become proficient with the application. Unrestricted screen movement is desirable for these users. An example of unrestricted movement in screen design is shown in Figure lO-57c. In the example, the user begins at the main menu and may move down the hierarchy in the same manner as a novice, or may move directly to a process screen, at the user's option. Unrestricted movement requires the design and implementation of a command language or sophisticated menu selection structure that is consistent with the basic novice menu selections, but adds the expert mode.

FIGURE 10-48 Payments, File Update and Printing Action Diagram Constructs

Unrestricted movement can be costly and error-prone, which are the main reasons why it is not prevalent. The added cost is due to increased access control structure that must accompany an open movement design. The added errors are from a need to provide a specific location on the screen for entry of the expert's direct screen requests. Each request must be checked for access control and legality, plus the current context (i.e., screen and memory information) might need to be saved for return processing.

FIGURE 10-49 ABC Consolidated Action Diagram

FIGURE 10-50 ABC Action Diagram with Consolidated Open Rental Processing

Upon completion, the menu structure and dialogue flow diagrams are given to the human interface designers to use in developing the screen interface (see Chapter 14). The dialogue flow diagram is also used by designers in developing program specifications. Before we move on, note that even though the menu structure is identified, the human interface may or may not be structured exactly as defined in the menu structure diagram. The human interface designers use the menu structure information to understand the dependencies and relationships between business functions, entities, and processes; they may alter the structure to fit the actual human interface technique used. If a traditional menu interface is designed, it could follow the menu structure diagram.

ABC Video Example Menu Structure and Dialogue Flow 

The menu structure is derived from the process hierarchy diagram in Figure 10-58 (reprint of Figure 9-26). First, the activities from the decomposition form the main menu options (see Figure 10-59). The processes are used to develop submenu options. Then, the lowest level of processing completes the simple structure (Figure 10-60).

Notice that all Rent/Return processing is expressed in the first menu option even though we have many subprocesses in the hierarchy. Rental/return has many subprocesses performed as part of the hierarchy diagram. Unlike the other subprocesses, rental/return does not have individual menus and screens for each subprocess. Rather, rental/return requires a complex, multifunction screen with data from several relations and processing that varies by portion of the screen. The subprocesses for rental/ return, then, describe actions on portions of the screen. You cannot tell from the decomposition diagram that rental/return has this requirement; rather, you know from application requirements (and experience) what type of screen(s) are needed. An incorrect rendering of the menu structure, such as the one in Figure 10-61, would look weird and should make you feel uncomfortable about its correctness. 

Second, notice that we do not indicate access rights for any of the processing options on the diagram. The security access definition is superimposed on the menu structure by the interface designers to double-check the design thinking of the process designers. If there is an inconsistency, the two groups reconcile the problems. 

Next we develop a dialogue flow diagram from the menu structure diagram. The rows of the dialogue flow diagram correspond to the entries in the menu structure (Figure 10-62). Rows are entered by level of the hierarchy by convention.

FIGURE 10-51   ABC Action Diagram with Data Entities and Attributes

We need to decide how much flexibility to give users, keeping in mind the security access requirements and the users' computer and functional skills. Users are mostly novices with little computer experience. The average job tenure is less than six months. Data and function access for clerks are unrestricted for customer, video, and open rentals add, change, and retrieve functions. Other options are more restricted in terms of which user class can perform each function.

First we define the options. We could define flexible movement between those options only, and restrict movement to other options through the hierarchy. Top-down hierarchic access is possible. We could allow hierarchic access combined with flexible 'expert' mode movement throughout the hierarchy, constrained by access restrictions. 

For each option, ask the following questions. Does Vic have a preference? Which best fits the user profile? Which is the cleanest implementation, least likely to cause testing and user problems?

FIGURE 10-52 Example of Process Hierarchy Diagram

Vic, in this case, has no preference. Having never used computers, he has no background that allows him to make a decision. He says, "Do whatever is best for us. I let that up to you. But I would like to see whatever you decide before it is final." This statement implies interface prototyping, which should always be done to allow users to see the screens while they are easily changed.

Most of Vic's employees work there for 1 Y2 years and have little or no computer experience. Therefore, screen processing that is least confusing to new users should be preferred. Usually, novices prefer hierarchic menus, providing the number of levels do not become a source of confusion. Also, the simplest implementation is always preferred; that is, the hierarchic menu option. 

Based on the answers to the questions, we should design a restrictive, hierarchic flow. As Figure 10-63 shows, this design is simple and easy to understand. The dialogue flow and screens should be prototyped and reviewed with Vic at the earliest possible time to check that he does not want an expert mode of operation.

FIGURE 10-53 First-Level Menu Structure

You might question whether the movement from rent/return to customer add and video add should be on the dialogue flow diagram. This is a reasonable concern since the process of rent/return does allow adding of both customers and videos within its process. The issue is resolved by local custom. In general, given the option, such flexibility should be shown on the diagram for clarity and completeness. Sometimes, local convention or a specific CASE tool requirement do not allow such completeness.

Plan Hardware and Software Installation and Testing

Guidelines for Hardware/Software Installation Plan 

The guidelines for hardware and software installation planning are developed from practice and identify what work is required, environmental planning issues, responsibility for the work, timing of materials and labor, and scheduling of tasks. 

Installation requirements should always be defined as far in advance of the needs as possible and documented in a hardware installation plan. Installation planning tasks are:

1. Define required work 

2. Assign responsibility for each task 

3. Create a schedule of work

If the SE team has no experience with configuring installations, their work definition should always be checked by someone who has experience. In general, you define the complete hardware, software, and network configuration needed, match the application configuration requirements to the current installation, get approval for all incremental expenditures, order all equipment and software, and install and test all equipment and software. In a mainframe environment, this task is simplified because the first step, configuration definition, can be abbreviated and done with help from an operations support group.

FIGURE 10-54 Second-Level Menu Structure

FIGURE 10-55 Final Menu Structure

The operations support group also would install and test hardware and install software. 

When the configuration is defined, it is matched to the current installation to determine what items need to be purchased. In new installations, the physical installation environment is as important as the equipment. Building, cooling, heating, humidity control, ventilation, electrical cable, and communications cable needs should all be assessed. If you have no experience performing these analyses, hire someone who does. Do not guess. You only do the client a disservice, and chances of making a costly mistake are high.

Once needed items are identified, they should be ordered with delivery dates requested on the orders . The delivery dates should conform to the expected installation schedule which is discussed below. The goal is to have all equipment and parts when they are needed and not before. For capital expenditures, this delays the expense until it is needed. Planning for large capital expenditures should be done with the client and accountant to stagger charges that might be a financial burden. 

As items to be installed are identified and ordered, responsibility for installation and testing should be identified. The alternatives for who should do hardware and software installation are varied. Choices include consultants, unions, contractors, subcontractors, or current personnel. In many cases, there are three types of installations being made: software, hardware, and the network, and each has its own installation responsibility.

Software should be installed by system programmers in an operations support group in a mainframe installation, and by the software builders for a PC installation. Contracts, whether formal or informal, should state what work is to be done, timing of work, penalties for failure to meet the time requirements, and price. Other items such as number of hours and dates of access to the site might also be included. 

Hardware, in a mainframe environment, is managed, ordered, and installed through an operations department. You, as an SE needing equipment, must know what you need, but must trust the operations department to obtain, install, and test the equipment. Most PC computer equipment is simplified enough that special assistance is not usually required. If desired, you can usually negotiate with a hardware vendor to burn-in equipment and set it up for a small fee. Burn-in means to configure the hardware and run it for some period of time, usually 24-72 hours. If there are faulty chips in the machine, 90% of the time they fail during the bum-in period.

FIGURE 10-56 Dialogue Flow Movement Alternatives

FIGURE 10-57 a Example of Restrictive Screen Movement

FIGURE lO-57b Example of Less Restrictive Screen Movement

At least two terminals or pes should be configured during installation of network cable for testing the cable. For LAN installation, hire a consultant if you've never done this before. The consultant helps you

• define what is to be done 
• define required equipment (e.g., cabling; connectors, etc.) 
• get permits from the government and building owners 
• obtain zoning variances 
• identify and hire subcontractors 
• supervise and guarantee the work.

As the user's representative, you can prepare the installation for the work to be done. Mark walls where all wires should be, using colored dots. For instance, you can use blue dots for phone lines, red dots for LAN cable, and green dots for electrical outlets. Number all outlets for identification of wires at the server end. Colored tape shows where cable runs should be placed in false ceilings and walls. Configure one PC, with the network operating system installed, in the location of the file server. As cabling is complete, move the second PC to each wired location, start-up the network, and send messages. Make sure the location is as expected and that the wiring works. Test all wires because they will be wrong. Make sure all wiring is correct before the electrical contractor is paid and leaves.

FIGURE lO-57c Example of Less Restrictive Screen Movement

FIGURE 10-58 ABC Process Hierarchy

FIGURE 10-59 ABC First-Level Menu Hierarchy

FIGURE 10-60 ABC Menu Structure

The important issue is to make a choice of who will do what work long before the work is needed, and plan for what is to be done. Use a lawyer to write all contracts using information provided by you, as the client's representative, and the client. 

Timing of installations can be crucial to implementation success. When different types of work are needed, such as air-conditioning and electrical cabling, the work should be sequenced so the contractors are not in each other's way, and in order of need. For instance, a typical sequence might be building frame, building shell, false floor/ceiling framing, electrical wiring, plumbing, air-conditioning, communications cabling, false floor/ceiling finishing, finishing walls, painting, and decorating. Any sequences of work should be checked with the people actually performing the work to guarantee that they agree to the work and schedule. 

In general, you want to end testing of all equipment to be available for the beginning of design at the latest. This implies that all previous analysis work is manual. If CASE is to be used, the latest possible date for equipment and software availability is the beginning of project work. 

Cabling is needed before equipment. Equipment is needed before software. Software is needed before application use. Some minimal slack time should be left as a cushion between dates in case there is a problem with the installation or the item being installed. Leave as big a cushion between installation and usage as possible, with the major constraint being payment strains on a small company.

ABC Video Example Hardware/Software Installation Plan 

For ABC, a local area network is to be used. A file server with one laser printer, three impact printers, and five PCs are planned. The LAN will be a Novell ethernet with SOL-compatible DBMS software, Carbon Copy, Word Perfect, Lotus, Norton Utilities, Fastback, and Symantek Virus software. The goal is for all hardware to last at least five years if no other business functions are added to the system. The configuration details are shown in Figures 10-64 and 10-65. There should be adequate capacity to add accounting and order processing software if needed. The current average daily rentals of 600 is expected to double in five years. The current number of customers is 450, and is expected to be 1,000 in five years.

FIGURE 10-61 Incorrect Rental/Return Menu Structure

FIGURE 10-62 ABC Dialogue Flow Diagram Menu Structure Entries

FIGURE 10-63 ABC Dialogue Flow Diagram

n five years. To develop a plan, assume that the current date is January 1, and that the application installation is scheduled for August 1. Design has just begun. The PCs and laser printer were installed five months ago for availability during planning, feasibility, and . analysis. The currently installed software includes a CASE tool on two machines, Word Perfect, Norton Utilities, Fastback, the SOL DBMS, and SAM Virus software. The remainder of the software and hardware must be ordered, installed, and tested as part of this plan. 

First we determine what we need. A comparison of currently installed items to the list of required items shows the following items need to be planned:

Network cable and connecters

File Server

Novell Software

Network Interface Cards (NICs, i.e., ethernet boards)

Impact printers

Bar Code Reader and Imprinter

Carbon Copy (network version)

Word Perfect (network version)

Norton Utilities (network version)

Fastback

SOL DBMS (network version)

SAM (network version)

Lotus (network version) 

FIGURE 10-64 ABC Configuration Schematic

FIGURE 10-65 ABC Hardware and Software Details

Everything should be ordered as soon as possible to ensure availability. Equipment and software ordering is the first item on the plan. 

The group has installed network software before but not the cable, so they obtain approval from Vic to engage another consultant, Max Levine, from their company to perform that work. Max has been installing mainframe and PC networks for over 20 years and knows everything about their installations and problems. He immediately takes over the network planning tasks. He first obtains a rough idea of the planned locations for equipment, computes cable requirements, and orders cable and connectors. Then, for the plan, he adds tasks for mapping specific cable locations for the installers, for installing and testing the file server, and for installing and testing the cable (see Table 10-6). 

At the same time, Mary and Sam work at planning the remaining tasks. Each software package must be installed and tested. These tasks are planned for Sam and one junior person. The tests for all but the SQL package are to use the tool and verify that it works. For the SQL package, Sam and a DBA will install a small, multiuser application to test that the single and multiuser functions are working as expected. Of all the software being used, it is the one with which they are least familiar, so they use the installation test as a means of gaining more experience. 

All tasks relating to new equipment and software are scheduled to take place during a six-week period in January and February. This allows several months of cushion for any problems to be resolved; it also allows disruptive installations (e.g., cable) to be scheduled around peak hours and days. The schedule does not show elapsed time, but other work is taking place beside the installations. For instance, design work is progressing at the same time. As the application is implemented and the users have need for the equipment, the PCs and printers are moved to their permanent locations. This occurs in late spring for data conversion. The last stand-alone PCs are scheduled to be added to the network in late July, long before the application implementation date of August 15.

Automated Support Tools for Data-Oriented Design

Many CASE tools support aspects of data oriented design (see Table 10-7). Two specifically support IE as discussed in this chapter. The IE CASE tools are Information Engineering Workbench4 (lEW) by Knowledgeware, Inc., an4 Information Engineering Facility (lEF) by Texas Instruments, Inc. Both products receive high marks of approval and satisfaction from the user communities. Because of their cost, both products are used by mostly large companies. The products offer enterprise analysis in addition to application analysis, design, and construction (i.e., coding). Both IEF and lEW work on PCs, networks, and mainframes. 

A typical IEF installation could include a mainframe version with the centralized repository. Users check out portions of a repository to work with on a PC. Then, when the work is complete and checked on the PC, it is merged with the mainframe repository for official storage. When the merge takes place, the checked-out items are revalidated for consistency with all mainframe repository definitions. Both products offer automatic SQL schema generation for data. IEF offers automatic code generation for Cobol with embedded SQL, and can interface to generators for other languages.

TABLE 10-6 Installation Plan Items

lEW and IEF differ in important ways. lEW is more flexible in that it does not require the completion of any matrices or diagrams. However, to take advantage of the interdiagram evaluation software that assesses completeness and syntactic consistency, all matrices and diagrams are required during a given phase. This means that you might not have the diagrams or analyses from planning, but you still can create levels of ERDs within the analysis tool. Similarly, you might not have the analysis tool, so action diagrams can be created directly within the design tool. IEF's strength is that its rigorous adherence to Information Engineering has led to substantive intelligence checking within the software. Both tools easily manage and sort large matrices that result from several of the analyses. 

The weakness of the tools differs for each tool. lEW is primarily a PC-based product that can be unstable when used for large projects. lEW also provides DFDs, not PDFDs, and is not a pure data methodology tool. A strength of lEW is that Knowledgeware was an IBM partner in its repository definition; as a result, lEW is compatible with AD-cycle software from IBM.

IEF's strength is also its biggest weakness. IEF requires completion of every table, matrix, and diagram at this time. 5 The level of intelligent checking that can be performed is higher than with most other CASE products, but the requirement to complete every table, and so on does not make sense for all projects. TI has recognized the severity of this shortcoming and is increasing the flexibility of the product without compromising its capabilities. The mainframe version of IEF uses DB/2 for repository management and can generate C, Cobol, DB/2, SQL, and other languages' codes.

Table 10-7 Automated Tool Support for Data-Oriented Methodologies

Summary

Data-oriented methods assume that, since data are stable and processes are not, data should be the main focus of activities. First, design focuses on the usage of data to develop a strategy for distributing or centralizing applications. Several matrices summarize process responsibility, data usage, type of data used, transaction volumes, and subjective reasons for centralizing or distributing data.

Next, processes from a process hierarchy diagram are restructured into action diagrams in design. The details of process interrelationships are identified from the PDFD and placed on the action diagram. Each process is fully defined either in a diagram or in the data dictionary. Process details are grouped into modules and compared to existing modules to determine module reusability. Modules are analyzed from a different perspective to reflect concurrency opportunities or requirements on the action diagram. Entities are added to the diagram and related to processes. Lines connect individual processes to attributes to complete the action diagram specification of each application module. For manually drawn diagrams, an optional activity is to identify screens and link them to attributes and processes, to give a complete pictorial representation of the on-line portion of the application.

Data-oriented design focuses on the needs for security, recovery, and audit controls, relating each topic to the data and processes in the application.

The menu structure and dialogue flow for the application are defined next. The menu structure is constructed from the process hierarchy diagram to link activities, processes, and subprocesses for menu design. The structure can be used to facilitate interface designers' application understanding. The dialogue flow documents the flexibility or restrictiveness of the interface by defining the allowable movements from each menu level (from the menu structure) to other levels of menus and processing.

Finally, installation plans for all hardware and software are developed. A list of tasks is defined, responsibilities are assigned, and due dates are allocated to the tasks.

There are two fully functional CASE tools that support data-oriented methodology as discussed in this chapter, lEW and IEF. They are popular in companies that use data-oriented methods.