This stage of system development provides the transition from a definition of system approach and objectives to a fully designed system specification. This system specification consists of the high-level design of the entire system including hardware, software, and personnel subsystems, to the point where programs and procedures may be designed and hardware may be ordered.

Preliminary design involves the development and documentation of an application (or parts thereof) to a specified uniform level of design. There is a human tendency to select one item of interest and to develop this to its ultimate detail. Later, when another item is selected, it usually becomes necessary to change what has already been accomplished, which is wasteful both in terms of time and money. It is therefore desirable to develop the total system to a preliminary level before starting the detail design of any area.

Considerable effort and money will be spent during the design period. Experience has shown that the final product may differ significantly from the initially defined product. It is therefore desirable to arrive at a preliminary design milestone before the design is completed in every detail. In this way, appropriate approval can be obtained and the design changed, if necessary, before further detail is developed.

The Definition Study contained activities that were performed by a relatively small study group focusing directly on the problem with the responsibility to recommend a feasible approach to its solution. During Preliminary Design, the study group will evolve into an organization of sufficient stature to support the design effort through detail design. At this time, the organization will be composed primarily of system designers.

The main features of Preliminary Design may be summarized as:

The products of this state are the Preliminary Design report and supporting documents. The report will provide management with the concise information necessary to make a judgment on whether to continue the developmental effort. The Preliminary Design report should contain a complete and final design but does not require all the interim designs and design decisions encountered throughout this stage (these can be found in the various working papers and supporting documents). The final report should represent a design entity; i.e., the level to which the design must be carried to ensure overall system design completeness and continuity. This design provides the "blueprint" for total system development even though the developmental efforts may be staggered, following the completion of Preliminary Design.

The Preliminary Design report should contain the following sections at a minimum:

Of course, the results will differ depending on the size and complexity of the system. For instance, in a simple system the data base design may be nothing more than a specifying of the record layout and blocking factor of an already existing sequential tape file, while for a big system the data base design might be very complex and include integrated file concepts and very complex data structures.

The standard activities included in the Preliminary Design stage are to:

The only activity that could be considered optional is that dealing with data communications. The specific products produced by these activities and included in the project file are:

Any system will evolve over a period of time and none, no matter how well designed, will remain static. Potential sources of change are:

Changes will occur during maintenance or during system re-design. The adaptation to these changes can be less expensive and time consuming if careful attention is pain to this activity. The changes leading to system expansion can be classified in two categories:

It is relatively easy to design specifically for the predictable factors but almost impossible for those that are not. The best way of accommodating such eventualities is to produce a design which will easily allow adjustment in the future.

A good example relates to unpredictable, latent demand. Quite often, a primary goal of a systems effort concerns improving customer service. The system designer must be constantly alert to the fact that an improved service will often generate a significant (but unpredictable) increase in the demand for that, or additional services, and subsequent expansion in the system load.

The initial system design should be examined from the viewpoint of what may be required after the system has been operational for some time. Each particular feature of the system should be examined to see if it will aid or hinder possible future changes. Typical examples of features which will hinder future changes are:

One feature that will definitely inhibit future expansion or change is inaccurate or incomplete documentation. All documentation must be written so that someone other than the developer can use and understand it.

Typical examples of features which will ensure system expandability are:

There are two basic approaches which may be taken by the designer in order to ensure system expandability. The first is to design the system with considerable over-capacity initially built in. The second is to design the system to accommodate the immediate future load, but with easy upgrading techniques included in the design. Normally, a combination of the two is preferable with a certain amount of initial over-capacity combined with ease of upgrading. The trade-offs to consider when deciding the approach and the amount of expansion to allow for are, among others:

· The time interval over which the system growth will occur

· The amount of predictable growth

Building in ease of expansion can be considered to be a capital investment in the same sense as having more power lines built for a building than will be used immediately. These capabilities may increase the short term cost of the system while lowering its lifetime cost.

A factor which will very likely restrict expansion of the new project planning and control system is that the accounting department has to check all time reports before they are processed further.

At the present moment, one of the main causes of the backlog is that the two persons in the accounting department cannot handle the time reports, which are submitted every Friday afternoon, fast enough. In view of the extra work expected in the coming year, this will become an even more serious bottleneck than it is now.

The solution for this problem could be to process the data from the time reports first, and let the computer make as many of the checks as possible. Only after that would data be passed on to the accounting department for final control. It is felt that an important factor in the backlog would be eliminated and the expansion of the workload in the near future would then cause much less difficulty.

In this activity, the hardware and software environments required to enable the system to meet its objectives are specified. This will lead to decisions for providing capabilities that are lacking or, where this is not feasible, to change in the system objectives; in which case a recycling to the Definition Study state would be necessary. This environment specification should include the structure into which the system will fit and should specify any interfaces to any other systems.

The current or proposed hardware/software configuration must be reviewed to determine the capabilities that are, or will be, available to support the proposed system. This step is necessary because certain characteristics and capabilities that might be required for a system may not be readily available with most standard configurations (e.g., conversational processing). Such requirements would produce the need for the generation of special software.

The following requirements should be considered when defining the system environment:

(To Be Supplied.)

(To Be Supplied.)

A subsystem is defined as being a portion of the system that can be designed and implemented independently of other parts of the system. This does not exclude relationships between subsystems. In most systems, the subsystems are obvious, such as the payroll subsystem within a general accounting system.

Subsystems may be of two general types. The most easily identified are application subsystems; e.g., material inventory, billing or payroll. In addition to these, many systems will require certain support subsystems, e.g., data management, communications, or generalized reporting.

The concept of system vs. subsystem is quite flexible. For instance, at one point in time, an application such as billing may be considered as a total system, while at another, it may be a subsystem of a larger, integrated customer services system. It is also possible that a system may be multi-level; i.e., a subsystem may be subdivided into lower level subsystems. Conversely, a system may be so small that it cannot be practically subdivided into subsystems.

In certain cases, it may be beneficial to identify separate human subsystems in a complex man/machine system.

It is in the interest of both time and efficiency that the system should be divided into logical segments, each of which can be developed separately and managed and controlled more effectively. this segmentation will allow for concurrent development and testing of different sections of the system. However, this modular approach can only be used profitably when proper preparation has taken place. The overall system design must be firm, and the distinction between subsystems specified in exact detail.

A description of the system segmentation is prepared, together with a functional description of the processing requirements for each subsystem.

(To Be Supplied.)

· Subsystem name and identification · Data files required:

· Summary description - data base

· Functions performed - working files

· Processes required: · Outputs produced

- input validation and editing · Inputs required

- file updating · Special hardware/software

- special calculations considerations

- output reporting · Manual tasks required

- error handling

- interactive processes

Input/output requirements can be determined by analyzing the system processes occurring in each subsystem. Initially, this should be accomplished without consideration being given to other subsystems input/output requirements to ensure that each subsystem will have a firm specification of its own input and output requirements.

The subsystem designers should interact to combine their respective input and output requirements into subsystem interface records. The subsystem designers should ensure that all inputs have a course and that all outputs have a destination. The interfaces represent the degree of subsystem interaction and data flow. The ease or difficulty of fitting the subsystems together during implementation is largely a product of this activity.

The data catalog is established at this time and will be maintained and updated throughout the life of the system. This catalog lists all the data items used within the system, using standard name and number. Associated with these items will be the processes and files that use the items as those processing and files are developed. This ensures standard naming of items throughout the system and reduces the possibility of data redundancy within the system.

Although this activity continues through Design, the major effort would be expected during Preliminary Design, as soon as most fields can be specified and output documents tentatively formulated.

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

A process is the logic of how a particular set of functions within a subsystem is performed. This logic is mot easily described in terms of a flowchart.

The describing of processes will vary between a batch system and an on-line or real-time system. For a batch system, the actions will be grouped into a process according to a similar logic and intermediate results for inputs or transactions passing through the subsystem. For example, all inputs may pass through the same validation process. The processes are conceptually static with the transactions dynamically addressing them.

For an on-line or real-time system, an individual transaction is described by a string of specific actions which that particular transaction requires. For example, an inventory request could require a specific set and sequence of unique actions. Such action strings comprise processes. Conceptually, the transaction is static, and the processes are dynamically called to address that transaction.

The level of detail should be sufficient to portray the full allocation among manual and EDP resources Further analysis of any process should lead only to subprocesses of the same type. It is frequently the case that automating all parts of a system can cost several times what automation of 95-99 percent of the system costs. Handling of vary rare or unusual cases can often be performed more efficiently as a manual operation with only the results of the process input into the EDP system.

The various process flows are integrated into one subsystem flowchart which is a description of the overall subsystem logic. The collection of subsystem flowcharts is considered as being the System Flowchart. Exhibit 2.5-A shows a flowchart that could describe a system, or be a subsystem of a larger system.

(To Be Supplied.)

(To Be Supplied.)

In this activity, the processes identified on the System/Subsystem flowchart are expanded into descriptive narrative detail. The activity will be similar for both EDP and manual processes and for batch and on-line processing. The narratives should support the flowcharts and be easily related to specific blocks on the charts. They supply detail and explanation for the flowcharts.

These definitions are the source documents for developing programs and procedural specifications. They are, in fact, the program and procedural requirements sated in application-oriented ordinary language. Completeness and accuracy are the important considerations when developing these descriptions.

Validate the plan to check that it has been authorized, that the project number is available, the persons planned are available (See personnel staffing summary) and that projected costs have been correctly calculated.

If there is an error in the plan submitted, return it to person concerned with request for correction.

Draw the plan on a project planing sheet and number the tasks which have been assigned to certain individuals. Tasks of more than 35 hours per week have to be subdivided.

Code the planning and task input documents and have information punched.

Use punched cards as input for automatic checking in weekly run.

Check that task numbers assigned are correct and print a planning list.

If there is an error, the planning department will sort this out with the person submitting the plan.

This activity covers all area of failure, error, or compromise within the system and specifies appropriate remedies. However, there are three general area which requires somewhat different handling:

The results of this activity will be requirements for:

The above are requirements only insofar as they are necessary to meet stated objectives. For example, if it is determined that a processing delay of 8 hours is tolerable and that any problem can be corrected in less than 8 hours, then fallback procedures may not be needed.

(To Be Supplied.)

(To Be Supplied.)

This activity involves identification of all areas of the system where human engineering is required to optimize personnel effectiveness, comfort, and safety. These areas include work space layout, controls and displays, ambient conditions, training requirements, and task performance aids. For each area identified, the system characteristics required to bring human performance needs and system objectives into optimum alignment a should be specified. In most instances, this will entail trade-off analysis which may be supported by many other forms of analysis and study, including:

The human engineering characteristics identified here will subsequently be refined and incorporated in procurement and design specifications of input/output equipment, communication networks, work facilities, job aids, training courses and other items related to the personnel subsystem. Some human factors considerations are:

(To Be Supplied.)

(To Be Supplied.)

During this activity, the records currently being used by the existing system are evaluated against the information requirements of the new system. This results in the selection of records to be used for generating the data base of the new system, and in the establishment of a data base structure and a system for retrieving the data in the manner required.

At this point in time, the designers are primarily concerned with the logical structure of the data base. That is, how will it appear to programmers and users. It may be that, through the use of a sophisticated data management system, the physical structure will bear little relationship to the logical structure. The physical structure will be developed in later stages.

Likewise, the logical assessing methods,. (e. g., chain, list, etc.) should be described now, where the actual technique used can again wait (e.g., indexed sequential).

Re-analysis of the data item and group descriptions to permit more efficient processing and storage should occur with the possible modification of the descriptions; e.g., display to binary or packed. Also examined is the possibility of combining fields. The output should give a close approximation of the data base storage requirements.

This activity is not concluded until after the information content of a new system data base is finalized; however, it can conclude prior to a final decision concerning its physical implementation. It will be conducted in parallel with several other activities during Preliminary Design.

Personnel assigned to develop the data base structural and assess procedures can proceed through the Detail Design and developmental stages. However, they must interact with the new system design to incorporate additions to the information content of the data base.

It should be noted that this activity may be extremely large and complex for a large, integrated system, or alternatively insignificant, as for a small system using a few tape files.

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

During this activity, all communications equipment and facilities required by the operational system should be identified. These needs are then refines, combines, and adjusted to develop comprehensive specifications for communications network. the specifications must be review to assure consistency with the current "state of the art."

In the specifications of the communications requirements, consider the following factors:

(To Be Supplied.)

(To Be Supplied.)

This activity includes final negotiation with the hardware manufacturer for deliver and installation of the equipment and maintenance support. The relevance depends, of course, on whether the proposed system may dictate new hardware or must be constrained to existing hardware.

During this activity, processing statistics should be summarized; CPU and I/O device requirements of the subsystem under development should be determined. These requirements will be used to determine the CPU size and necessary speed. In addition, the general characteristics of the I/O and data base devices will be summarized. The hardware included will be:

It must be noted that the use of hardware may be a constraint. It should further be noted that, in some cases, the ordering of hardware may be delayed until the Detail Design stage.

Equipment should not be ordered until the Preliminary Design state is virtually complete. Delivery should be specified for an appropriate time during the Implementation stage. All too often, equipment is ordered before the system is designed and then delivered before it is needed. Considering that rentals may range between $10,000 and $100,000 per month, a poor decision or an ill-timed delivery can be extremely expensive. In addition the cost of programming (which often exceeds equipment rental fees) can cause total costs to skyrocket if the programming effort is not phased-in properly with the installation of the new system.

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

This activity involves analyzing the designed system and specifying the system software characteristics which will be required to support that system. Many of the characteristics may be common to most operating systems (such as indexed sequential accessing). However, some of the required characteristics may be unique (such as dynamic priority establishment) to few, if any, operating systems. This type of requirement must be specified very carefully because it may create the need for the manufacturer or the user to generate special computer system software.

Special care should be used in specifying only what is needed. This is true because the complexity and size of the software is increase with added features. An example of this would be multi-programming, where the operating system is significantly larger with this feature than without it.; therefore, do not request multi-programming unless you really need. it.

Some important software components are:

During this activity, the system should be closely examined to identify all processes that could be handled by existing system utility routines. Using existing system utilities and proven application routines will be considerably more efficient than developing ones. Common user-developed software (those processes that are common to more than one subsystem or program) should be centrally developed to eliminate redundant developmental effort.

In many situations, decisions must be made as to whether to make or to buy the system software. Commercially available packages may do a portion of the job. Sources other than the manufacturer should always be considered. In general, there are three basic approaches to answering the software questions, i.e.:

In making the decision on the approach to system software, there are many trade-offs which must be evaluated to make certain of the overall cost effectiveness of the system; e.g.:

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

A plan in now needed that is more detailed than that developed in the Definition Study. It should describe, in detail, the activities for the remainder of the effort, including all milestones and manpower requirements. Many methods such as PERT charting are available.

At this point it should be possible to produce a comprehensive plan for Detail Design and Programming, while it may be somewhat premature to provide concrete and detailed plans for Testing or Implementation and Conversion.

The plan for Detail Design and Programming should contain at least:

The basic framework for programming and testing will include a determination of:

The acceptance criteria and plan developed during the Definition Study should now be updated:

It must be remembered that planning must cover special conversion programs and manual functions as well as system programs.

Although Conversion and Implementation are the last stages in making a new system operational, the preparation for these stages must begin early and continue throughout the developmental effort. With the commencement of these stages, a severe impact on the organization may be felt because of the consequences brought about by reorganization of the new system. In addition, the manpower requirements for the conversion and implementation may be very large, particularly if large, manual files have to be converted into machine readable media. Among questions arising from conversion are:

Particular requirements may be created by the sheer volume of the files to be processed through conversion. The level of errors in the existing files may be very high and should be precisely specified.

For every file, it should be determined whether it is feasible to perform conversion within the general time and resource constraints. It will be disastrous if the system goes through development and then cannot be implemented because it is not possible to convert the files.

An analysis of the existing files by operations research personnel in conjunction with user personnel is a most useful approach to find, through sampling:

Analysis must be used to determine the impact of any error allowed to be carried from the old, into the new file. The costs of the effort required to correct the existing files prior to conversion must be evaluated. An understanding of precisely what is to be done about the problems encountered must be reached and formalized.

As a part of the determination of the feasibility of conversion, the manner in which the conversion is to take place must be specified. Among the factors to be considered are:

The requirements of implementation will differ, depending on the nature and size of the system, as well as the general approach to implementation. An initial determination must be made as to which basic implementation approach is to be used:

Since the system may have a radical impact on the functioning of the user organization, it is imperative that the potential impact be estimated. From the beginning of design, a governing consideration is how the subsystems will be carried into actual operation., Among the factors to be considered are:

A special consideration in planning my exist if there are to be significant hardware facilities installed for implementation. As the development proceeds there will be a number of important functions that must be performed to ensure successful installation. Among these are:

(To Be Supplied.)

(To Be Supplied.)

(To Be Supplied.)

This activity calls for the most accurate and complete picture of the system that can be provided, using the most current design information available.

During this activity, review all changes made to the system during preliminary design and assess their impact on the overall system. The overall developmental plan and milestones must be updated to reflect the current status.

Based on preliminary views of the system, broad estimates of cost will have been developed prior to this activity. In this activity, the more detailed system information now available should be used to refine the cost estimates. It is expected that highly reliable cost data will be produced at this time.

Previous to this activity, all the products are considered as being working papers and are highly subject to change. The Preliminary Design report is a final, technical report that should reflect the subsequent system design in a more formal, concrete way. Changes to this report should be few and made only after careful consideration.

Once originated, the report should be review by all appropriate parties and submitted for managerial approval. Management will:

After revision and approval, the Preliminary Design report becomes the base document for future development. Basic changes of design should not be permitted without complete review and approval. Failure to "freeze" design may lead to costly changes which are not well thought out with resulting delays, increased costs, user dissatisfaction and possible system failure.

(To Be Supplied.)