The purpose of this phase is to design sub-systems to implement information requirements. This is the logical system design phase of ISEM. Several events occur during this phase:

• Sub-Systems are designed with their appointed inputs, outputs and files.

• Actual examples of outputs (reports, screens, etc.) and pertinent inputs are prepared.

• The project plan and associated project estimates/ schedules are updated.

• A formal review with user management is conducted to verify the phase findings.

The formal deliverable resulting from Phase 2 is a "System Design Manual" consisting of a description of the sub-systems, samples of outputs, along with an updated project plan. This is reviewed with management who must decide whether to:

• Approve the project for continuation.

• Request revisions to the phase findings.

• Discontinue the projects.

Following Phase 2, the ISEM project will branch to multiple Phase 3's "Sub-System Design." Because of the one-to-one relationship between sub-systems and Phase 3, the number of Phase 3's to be performed is based on the number of sub-systems identified in Phase 2.

By definition, without any one of these basic characteristics, it is not a system.

We can, therefore, provide a standard definition:

INFORMATION SYSTEM - a prescribed set of processes operating routinely to produce information for users to fulfill business actions and decisions.

Information Systems are used to pay employees, manage finances, manufacture products, monitor and control production, forecast trends, process customer orders, etc. These are all excellent examples of how systems support information requirements.

But what is a Computer System? What does it produce? Information about computers? Or, are we merely trying to describe how a system was implemented? We beg the issue as to what is more important; the system or how it was implemented? To many in the field, implementation is more important than what is being implemented.

Are the terms "Information System" and "Computer Software" synonymous? Software is obviously the opposite of "Hardware." Software is machine processable instructions that permit the hardware to perform specific functions. Software has the same relationship to systems as robots have to a manufacturing process. Even if the robot performs properly or a program executes correctly, it does not necessarily mean you are producing anything worthwhile. What is most important in this situation is whether the logical system design is correct or not. The physical implementation can be less than perfect and you can still produce good results. The reverse is not true. "Systems" and "software" are as dissimilar as "information" and "data."  

UNDERSTANDING SUB-SYSTEMS

A sub-system is a specific business process that operates routinely in a unique time frame. This time frame is predicated on the information produced by the sub-system. In other words, the timing of the sub-system is derived from the information requirements it supports.

The sub-system is also used to logically join data with processing. It simply defines what data is required and when. The succeeding phases of ISEM will be used to define how the data will be physically processed by the human being, office equipment, and by the computer.

To those people entrenched in programming, the sub-system concept is somewhat nebulous. Instead of thinking in terms of BUSINESS PROCESSES, they tend to think in terms of COMPUTER PROCESSES. This type of physical thinking does not apply in Phase 2 and should be reserved for Phases 3 and 4-II. During Phase 2, Systems Engineering must concentrate on enterprise-wide business processes.

There is no practical limitation to the number of sub-systems in a system. A system can have as few as one, or as many as hundreds.  

DESIGN CORRECTNESS

During Phase 1, approval was given for the Project Scope, the Information Requirements, and System Approach (the rough design). In Phase 2 each sub-system is finalized as to its Inputs, Outputs, Files, and processing specifications. The primary objective of Systems Design is to define the system in terms of:

• WHAT business processes make up the system.

• WHEN these processes need to occur.

• WHAT inputs and outputs will be produced during processing.

• WHAT data will be required for processing.

The emphasis in Phase 2 is on design correctness; designing a system that correctly satisfies information requirements. As such, ISEM's design philosophy during Phase 2 is to work backwards from the information requirements:

Information Requirements	>>>	Data Requirements
Receiver of Information	>>>	Originator of Data
Outputs	>>>	Inputs

Later, during Phases 3 and 4, the process is reversed. Here, the design expresses how data will physically be processed in order to produce information.

Source of Data	>>>	Destination of Info
Inputs	>>>	Outputs
Start	>>>	End

 

CHRONOLOGICAL DECOMPOSITION

"Chronological Decomposition" is a technique used in ISEM to decompose a system into its logical sub-systems (business processes). Although several design concepts are implemented by Chronological Decomposition, "Information Driven Design" is the driving force behind the technique.

As the name indicates, timing is an essential part of Chronological Decomposition. This is because information is a perishable commodity. It only has value during a particular point in time. Users require information to support actions and decisions on a routine and timely basis, either instantaneously, daily, weekly, monthly, etc. All information systems operate routinely based on timing. Since this is true, why not make use of this timing consideration during system design as opposed to discovering it after the fact?

Timing will ultimately dictate how data will be collected and stored (availability requirements) and how data will be accessed to produce information. This approach implies that there are substantial differences between information and data, one of which is that data is the raw material that is used to produce information.

The supporting data must be defined in such a way that we can easily understand what primary data must be supplied by a User and what generated data must be calculated internal to the system. Data relationships can be extensive. For example, take NET-PAY which may be based on a complicated computation:

The data elements used in the formula may also be calculated, such as:

What this means is that in order to arrive at the correct value for NET-PAY, we must be able to reach all of the primary values, such as HOURS-WORKED and RATE, in a TIMELY manner. If we cannot do this, NET-PAY will be incorrect.

Defining these data dependencies has typically defaulted to the programmer who redefines the relationships with each application and buries it in the source code, making maintenance and change difficult.

The timing and data specifications resulting from the information requirements will ultimately dictate the type of system to be created. For example, if information is required upon request and within a matter of seconds, this will probably result in an "interactive" type of process. However, if the information is required upon request but within a few hours, this will probably result in "batch" type processing (it may even be processable manually). These specifications are the basic building blocks for all systems and software design.

Chronological Decomposition organizes all of the data required to support the application, into logical files (objects), or as DBEM refers to it, the Application Logical Data Base Model (ALDBM). As such, it synchronizes this data base with the application.

Perhaps the biggest benefits derived from Chronological Decomposition, as reported by users, has been that it forces the Systems Engineer to consider all of the required data and simplifies processing. It also emphasizes the need for sharing data. As a design develops, consideration is given to using data from other applications. After all, why create new files and processes if they already exist? To do this, Chronological Decomposition makes active use of the IRM.

With the logical design defined, consideration is then given to the most appropriate way to physically process the data, either manually or computer assisted. Here is where Functional Decomposition and Data Driven design excels. For software engineering, the characteristics of the data, its structures and what functions the computer must perform (e.g., create, update and reference) dictates the required programs. These specifications are the result of Chronological Decomposition. The physical characteristics of the data defines its validity. The data structures denote input, file and output relationships. The functional requirements determine how the data will be read and written in a program, whether sequentially, iteratively or selectively. In other words, Functional Decomposition and Data Driven Design will dictate physically "WHO" and "HOW" the data will be processed.

In no way should "Chronological Decomposition" be confused with "Functional Decomposition." Both have distinctly different purposes and missions. Whereas the former is concerned with logical system design based on the characteristics of information, the latter is concerned with how data is to be processed physically. They are not conflicting techniques. In fact, they are complementary as long as they are put into proper perspective. They simply have entirely different roles.

Steps In Design

The following is a brief explanation of the steps in Chronological Decomposition:

I. ANALYZE THE BUSINESS

This includes an analysis of the logical functions of the enterprise along with a study of the physical organization. The purpose of this is to evaluate how and when business actions and decisions are made. Included in this step are interviews with users.

II. SPECIFY INFORMATION REQUIREMENTS

Information Requirements are formally documented and reviewed with users for accuracy.

III. DEFINE DATA REQUIREMENTS

Define the data items needed to support each information requirement. Both primary and generated data elements are defined and related to the information requirements. Data definitions that were previously defined can be re-used. New elements are defined as required. What is important is that data dependencies be correctly defined (such as those primary data items needed to calculate generated items).

IV. DETERMINE OUTPUTS

Since, outputs are used as the vehicle for transmitting information, the Systems Engineer must determine what type of output(s) will be required to satisfy the information requirement(s). There is not necessarily a one-to-one relationship between information requirements and outputs. As part of this process, the engineer defines the timing of each output, along with the data that must appear on the output. This is derived from the information requirements.

V. BUILD NEW LOGICAL FILES

Based on the data requirements of the outputs, logical files are constructed using primary data (not generated). These files represent a logical view of the required data for this application only (not a global view).

VI. SUBSTITUTE EXISTING FILES FOR NEW FILES

Wherever applicable, existing files are substituted for the new logical files. This eliminates redundancy and promotes a shared data base environment. The criteria for substitution is:

• Uses the same "basic grouping" (logical key to the file).

• Uses the same data in the file.

• The file is maintained (updated) in a time frame that will accommodate the outputs.

VII. CREATE INPUTS TO COLLECT DATA FOR THE NEW LOGICAL FILES

Create inputs to collect data in a timely manner. This is only for the new files, not for the existing files that were substituted in the last step. After all, why create inputs for data that is already being collected elsewhere?

VIII. ORGANIZE INPUTS, FILES AND OUTPUTS INTO SUB-SYSTEMS

Inputs and outputs are sorted into separate business processes (sub-systems) based on compatible time frames and users (e.g., Sales, Customer Services, Manufacturing, etc.). Files are also attached to the sub-systems based on the data to be collected (through inputs) or retrieved (through outputs).

As Chronological Decomposition implies, there are basically two types of sub-systems:

• File Maintenance - to collect and store data in a timely manner.

• Display/Reporting - to access data in a timely manner to support outputs.

Sub-systems can be merged or separated as deemed practical by the Systems Engineer. However, the engineer must be highly sensitive to the timing issue since it will have a significant impact on the data base design.

In addition to the two types of sub-systems mentioned above, the Systems Engineer must determine the need for additional types of sub-systems; for example:

• File Conversion - a one time sub-system to move data from an old file format to a new file format.

• File Backup/Recovery - this is required in the absence of standard operating procedures that deal with recovering files in case of emergency.

• File Management - this is also required in the absence of standard operating procedures for file handling considerations (e.g., initialization, reorganization, auditing, repairing a damaged data base, etc.).

SYSTEM FLOWCHART

A system design is represented with the System Flowchart, one of the formal deliverables resulting from Phase 2. As with all ISEM flowcharts, the diagram graphically shows the next level of detail in the system structure: sub-systems. Each sub-system is represented on the flowchart with its appointed inputs, outputs, files and timing. A Table of Files accompanies the flowchart which shows how the various files are used in the sub-systems: either "C" Created, "U" Updated, "R" Referenced, or combinations of all three.

For additional information on "PRIDE" Graphics, see: "PRIDE" Flowcharting Symbols.  

SUB-SYSTEM CONCEPT DIAGRAM

Following the system design, the Systems Engineer evaluates how each sub-system will be physically implemented. This is similar in intent as the rough design prepared in Phase 1, Activity F. From this rough design, the Systems Engineer creates a Sub-System Concept Diagram. Like the System Concept Diagram prepared in Phase 1, the Sub-System Concept Diagram is a free-form schematic used to graphically express how each sub-system will be implemented. As such, it will be used by User Management to visualize and evaluate the proposed sub-system. This diagram is prepared in Phase 2 and is confirmed in Phase 3 as the sub-system design is completed.  

ILLUSTRATIVE EXAMPLES

After the decomposition of the system into sub-systems has been completed, Systems Engineering prepares illustrations of each Output and Input for review with users. These illustrative examples contain actual data values, so the users can visualize field alignment and contents to assure each Information Requirement is implemented in a usable form. Attention to detail on the part of Systems Engineering during the preparation and review of the illustrative examples dramatically reduces requests for changes later in the project. These actual Data Values also assist Systems Engineering in confirming the physical attributes of the Data Elements (such as class, length, precision, scale, etc.).

When ISEM refers to "inputs" and "outputs," it does not mean "files," although they may be related. Instead, an Input is a human intelligible medium that is used to collect data for storage in a file. An Output is a human intelligible medium used to convey information. Inputs can be represented by a keyboard, touch screen, audio input, optical input, printed forms, etc. Outputs can also take many forms: printed reports, screens, audio output, etc. The basic difference between the two is one collects data (inputs) and the other displays information (outputs). Sometimes, a printed form can represent both; it is used to collect data in a specific format that is ultimately passed on to a user for review as information. Such an input/output is commonly referred to as a "turnaround document" and should be represented as both an ID and an OD in the IRM. The common bond between the two is the FORM NUMBER. Also, the ID can be directly related to the OD in the IRM.  

PROTOTYPING

With the advent of Fourth Generation Languages (4GL) and other application development aids, the concept of "Prototyping" has gained in prominence. To many, it represents a significant productivity improvement for their systems development efforts; others seem to be at a loss as to how to appropriately apply this technology. Some see it as a substitute for requirements definition; others see it as a way for evaluating the viability of a design. Which is correct? Well, let's begin by providing a standard definition for the word:

PROTOTYPING - To develop an actual physical archetype of a product to some scale. The prototype is used for testing in order to visualize and evaluate the performance of the product and to make recommendations for improvement prior to the final design.

Prototyping's "roots" are found in Engineering, Manufacturing and Construction. In the automotive field, working models of automobiles are prepared to scale prior to going into production. As an aside, prototypes are frequently used in car advertisements. If you were to look beyond the facade, you will find an automobile that is very poorly held together. One you definitely would not want to drive.

In engineering and construction, companies have whole departments dedicated to building physical models of buildings, plants, bridges, etc., that the company is planning to build. In fact, substantial money is invested into these models prior to construction.

In virtually all instances, the prototype is based on some form of logical design, usually in the form of a set of blueprints. Further, the logical design is based on a set of predetermined requirements. In other words, prototyping is applied in the following sequence:

REQUIREMENTS	-->	DESIGN	-->	PROTOTYPE	-->	BUILD

It is unimaginable to try and build an automobile, airplane, building, etc., in any other sequence. Companies do not allow modeling departments to develop prototypes of products before the logical design and requirements have been completed. It would be a senseless waste of time and money. So why should systems development be any different?

Until recently, it was not feasible to develop a prototype of an Information System. Systems departments could not develop a rudimentary model of their applications because it would have to be developed by hand and would take considerable time and money to develop. But these new application development aids quickly changed all of that. Systems developers suddenly discovered that they could build an application in a very short period of time. The productivity improvements seemed boundless.

People then began to ask how to apply prototyping tools in relation to their systems methodology. Some extremists felt that it eliminated the need for the programming phases completely. Some even feel the requirements and design phases can be eliminated, since systems can now be built on an "ad hoc" basis. What they did not realize was that the phases were not eliminated, but rather, some of the technical tasks were expedited. The same activities and tasks were required to build the application but at a much higher rate of speed.

There were also those who felt that prototyping was a good way for helping the user determine their information requirements. "After all, users don't know what they want." This is a lame excuse for not defining information requirements at the beginning. This "ad hoc" approach is simply a sign that the person was never trained in how to properly define requirements to begin with. The excuse is that it is fast and cheap to develop an application this way. "If you don't like the application, simply throw it away." Translation: "Since I don't know what I'm doing, I'll keep hacking away at the problem until something worthwhile happens." If there is one place prototyping definitely does not belong, it is in the area of requirements definition. It only helps to determine physical requirements, not logical business requirements.

So where does prototyping apply in ISEM? Several places:

Prototyping and Phase 1 - "System Study & Evaluation"

During Activity F Systems Engineering prepares a rough design of the system. All sub-systems, procedures, programs, inputs, outputs and files are identified at this time. Following the rough design, a System Concept Diagram is prepared which is a rendering of the entire system. In most instances, this amount of detail is sufficient in order to make a practical Phase 1 decision to proceed with the project, modify it, postpone it or cancel it completely. However, there are instances where more detail is required.

There are basically two types of people that can assimilate ideas: The Conceptualist and the Detailist. For example, when building a house, the conceptualist can visualize what the structure will look like simply by looking at blueprints and/or an artist's rendering. However, the detailist often requires a more tangible idea as to what the house will look like. For the Detailist, it is necessary to be able to step through a model home to note the physical appearance of the house. The same is true in Phase 1. Some people will be able to visualize the entire system based on the System Concept Diagram and rough design. Others, will require something more tangible in order to assimilate the system. Prototyping can provide assistance in this respect. A "quick and dirty" application can be developed and reviewed in order for the user to visualize how the system will work and the types of screens and reports produced.

The only danger in using prototyping in Phase 1 is the possibility of devoting substantial time and money to a project that will only be cancelled and postponed after Phase 1. There is also a tendency by some to try to develop the entire system, including programming, in Phase 1. It must be remembered that the purpose of Phase 1 is to specify and analyze a business problem and/or opportunity and to propose to management a course of action. Regardless of how well the system design was thought out it is only a "rough design," not the final design. Changes will be incorporated into the design as it is detailed in the subsequent phases.

Prototyping and Phase 2 - "System Design"

During this phase, the system design begins to take on physical characteristics. Screens and Reports are designed and actual data values are used to give the user an idea of what the finished product will look like. Obviously, this is an area where prototyping excels.

Since the system has been logically defined, it should be relatively easy to mock-up the screens and reports using prototyping tools. Adjustments can then be made with a dialog between the analyst and the user.

The user should be forewarned; some prototyping tools are not as easy to use as they advertise. When a screen or report is designed, it can be quite cumbersome to modify. In a situation like this, it is recommended that the illustrative examples be prepared using simple text editors, screen layout masks or even a plain piece of paper. It will be much easier to accommodate changes (and there will be many) in a more cost effective manner. The manually prepared illustrations become the prototype's prototype.

In the final analysis, if the prototyping tool is easy to use and can readily accommodate change, then use it. If not, prepare the illustrative inputs and outputs by hand first.

Prototyping and Phase 3 - "Sub-System Design"

If the illustrative Output and Inputs were prepared manually in Phase 2, then Phase 3 represents the last opportunity to use prototyping prior to the programming phases. In this instance, because of the detail defined to this point, there should be few, if any, changes made to the screens or reports.

Summary

Prototyping is a valid concept and has an important role to play in systems development. The biggest problems that are associated with prototyping include:

1. Misapplication of prototyping as a concept and as a tool. It is like anything else; it should be used as intended. This specifically excludes using it as a tool for specifying information requirements or system design. This is the biggest danger with prototyping in systems development.

2. When users see a working prototype, they tend to assume that the application is nearing completion and ready for operation. It must be clearly explained to the user the role that prototyping plays in systems development.

3. Users want to use the prototype as the finished product. This may suffice on an interim basis but the User must understand that it is far from being the final product. After all, who wants to drive a prototype of an automobile or fly in a prototype of an airplane?

4. Prototyping only emulates computer processes of a system. They are not helpful for other processes of a system, such as manual and office automation procedures.

5. Many prototyping tools are based on a specific DBMS. This may be fine in some cases, but it also has a tendency to force a company to use a single file management technique, one that may be inappropriate for the application.

Prototyping is not a substitute for requirements definition or system design, but rather a welcomed addition to assist in expediting the physical aspects of systems development.  

INPUT-FILE-OUTPUT RELATIONSHIPS

Although a sub-system expresses the use of inputs, outputs and files, it does not necessarily express direct relationships between these items. Because of this, the Systems Engineer should establish relationships in the IRM to represent:

• Inputs to the Outputs produced (ID-to-OD).

• Inputs to computer transaction Files (ID-to-FD).

• Outputs to computer Files supplying data (OD-to-FD).

• Manual Files containing printed Inputs and Outputs (FD-to-ID/OD).

UPDATING THE PROJECT PLAN

Before proceeding with the management review of Phase 2, Project Management must reappraise the Project Plan, along with the Order-of-Magnitude estimate and schedule. By the end of Phase 2 Project Management should have a clearer understanding of the system and should be able to determine if the project is proceeding as planned. If not, the plans, estimates, and schedules are updated accordingly.  

PHASE 2 REVIEW

Based on this report and subsequent review meeting, management may elect to revise parts of the report, discontinue the project, or approve it for continuation.