Data Analysis and the System Development Life Cycle

Data Analysis and the System Development Life Cycle

The framework and sequence of activities used for the development of systems, is called the system development life cycle. The processes and activities within this framework are usually performed according to a well defined and comprehensive sets of procedures called methodologies. These methodologies include specific activities for the analysis and design of both the data and process portions of the system.

While some of these activities can be uniquely designated as data or processes most overlap and combine aspects of both. As these methodologies developed, the activities defined by them become more and more separated into those specific to data and those specific to process. This differentiation of activities into either data or process has led to the rise of the term data analysis as opposed to systems analysis as a way of both categorizing the activities and of assigning responsibility for them.

We have used the term system development life cycle, and the implication of the name is that it is used specifically for system development, rather than for system maintenance or system enhancement. Although maintenance and enhancement are different from development in many respects, they are in reality subsets of the full development cycle of activities.

Maintenance is the term applied to those activities which correct flaws or errors in both systems design and implementation with respect to system requirements and system specifications. That is maintenance makes the system conform to original requirements.

System enhancement falls between system maintenance and system development in that it also corrects flaws in requirements and specifications. System enhancement adds to system capability by incorporation new or augmented requirements.

The major differences between the three kinds of life cycle lie in the scope of their activities, in the extent of the changes each produces, and in the considerations each must address with respect to the existing system implementation. Maintenance changes the existing system, enhancement adds to the existing system and development replaces the existing system.

Because the data related activities for development are the most comprehensive we will concentrate on the development life cycle, and point out the differences in those activities as they apply to both maintenance and enhancement.

Before we begin our discussion of data analysis and the system development life cycle we should set some perspective.

1) Since most business activities involve the gathering, manipulation, presentation or dissemination of data or information, any system development life cycle must concentrate on those activities.

These data specific activities should be clearly defined, and have clearly assigned responsibilities.

2) Since many business procedures are or soon will be automated, or semi-automated, any system development life cycle must acknowledge, account and provide for automation considerations.

This is especially true for data, in specific, for the design of the automated files, the physical storage of those files, and for the identification and specification of all file access and maintenance procedures and issues.

3) The development of business systems is a business function and as such should be subject to the same management and controls as any other procedure. Its processes and activities should be performed within a framework and according to a well-defined set of procedures.

The management of data, and the controls applied to it should be at least as stringent as those developed for either the business processes or any other business assets.

4) The development of business systems, as a business function, is subject to the same types of changes which affect other business functions, and the systems and procedures which govern how it operates are subject to the same change agents as any other business systems or procedures.

Although business data, and specifically business data files change less rapidly, and less frequently than do business procedures, those changes which do occur have a more severe impact, and thus data file changes must be closely monitored and controlled.

What is a System Development Life Cycle

In order to accomplish any given set of tasks effectively one must have a work plan or procedure. Without such a procedure or work plan, activities are performed in a haphazard manner and with little if any coordination. The results are that the various intermediate products rarely fit together into a cohesive whole, and worse yet the finished product rarely meets the initial specifications. In some cases because of a lack of a work plan there are no initial specifications.

The overall work plans for systems development are called system development life cycles, and the detail plans are called methodologies. In some cases, the system development life cycle is also called a methodology, but for our purposes we will make a distinction between the two.

A Definition

A method is a means or manner of procedure, a regular and systematic way of accomplishing something. An orderly and systematic arrangement. Procedures according to a detailed, logically ordered plan.

A Definition

A methodology is a system of principles, practices, and procedures applied to a specific branch of knowledge.

The Purpose of a Methodology

Methodologies, specifically system development life cycle methodologies, provide the framework, and the sets of procedures within which the myriad of development tasks can be performed. Most methodologies cover the entire span of development activities from project initiation through post implementation review.

Depending upon the methodology, they may or may not include specific activities for data. In many cases, identification of data element requirements, and specification of data file design is incorporated into the procedural design and specification activities. This data-related design and specification is not documented separately but often appears as an appendix in the procedural documentation.

Methodology

Generally speaking the analysis portions of a methodology must include and provide for:

• Business organizational analysis
  
• Business function analysis
  
• Business process and activity analysis
  
• Business data analysis

This analysis portion forms the first and perhaps the most critical phases of the development project. It is the analysis phase that identifies and documents the business requirements for change. In other words it is the analysis phase which defines the problem to be solved and the scope of the problem environment. In many cases these phases are the project itself since the information developed may show that no further work is either necessary, feasible or desirable. In all cases, the results of the analysis phases determine:

a) if there is a problem to be addressed
b) if there is a feasible solution to the problem, and
c) if developing a solution to the problem is cost beneficial to the user and to the firm as a whole.

Analysis projects are initiated to change the business procedures of a business, but more often they are initiated because the firm requires both procedural change and data change. This data change can come in many forms, from reorganizing the data to make access more efficient, to making wholesale additions to the kinds of data available for use by the business.

System Development Life Cycle Phases

Assuming that the project proceeds in a normal and orderly fashion, it can be expected to follow the following general phases:

A. Project initiation
B. Analysis

1. General Business analysis
2. Detail Business analysis

C. Examination and study

1. Evaluation of existing system components
2. Problem identification
3. Feasibility analysis of alternative approaches

D. Design

1. Development of General Business System Design
2. Development of Detailed Business System Design
3. Development of procedural solution specifications

E. Implementation of the procedural solutions
F. Testing of the procedural solutions
G. Implementation of the procedural solutions into the normal business processing schedule (production)
H. Post-implementation review of results.

Although the preceding list contains many project phases, it can be simplified to:

Analysis
Design
Implementation

These three (figure 2-1) are bracketed by project initiation, and project conclusion and review. Additionally, all five activities include the administrative tasks of planning, scheduling, and control.

Each phase has its associated data activities (figure 2-1), each of which is designed to identify a specific aspect of business data, or to assist the analysis and design teams in defining that data, organizing that data, or determining the various implementation specific aspects of the physical data file storage. In some cases these activities are completely separate, and in other cases they are tightly interwoven into the procedural activities.

A definition

Analysis is the separation of an intellectual or substantial whole into its constituent parts for individual study; the stated findings of such a separation or determination."

A Definition

Systems analysis is, by extension, the study of, and separation of, a group of interacting, interrelated, or interdependent business functions, processes, activities or elements forming a complex whole into its constituent parts (the procedures which govern them) for individual study.

A Definition

Data analysis is that set of processes and activities whereby the user requirements are identified and the data elements necessary to satisfy those requirements are identified, defined, specified and organized.

A business system is intended to be an orderly, harmonious group of interacting, interrelated and interdependent procedural components. Each of these components, each of these procedures in turn generates, uses or disseminates data. All business procedures process data. All business procedures are data processing procedures - that is they all process data in some manner.

Over time, internal and external business changes cause gradual, individual procedural changes such that the component parts of the system either no longer interact harmoniously or those individual components can no longer be changed except with great difficulty. These changes also cause new or different requirements for data to arise. These new data requirements may be for additional data not previously available, for existing data to be made available in new ways, or to different parts of the organization, or it may be for changes or modifications to existing data.

When that point is reached the system itself, and all its component parts must be taken apart, modified such that all the parts work harmoniously and put back together.

During the process of modification, the disorderly, disharmonious, independently acting procedures are changed. At this time new procedures for new processes, activities and tasks are developed and can be added into the revised system.

A major result of this process are the additions, modifications and reorganizations made to the business data files which support those procedures. Sometimes these changes to the business data files are minor, sometimes radical, and in some cases extensive new files are added to the business data inventory.

Systems Analysis versus Systems Design

If systems analysis is the process of separating a system into its component parts (individual procedures) for study, examination, and repair or replacement, then system design is the process of taking those component parts after examining, studying and making changes to them, and putting them back together into a harmoniously interacting complex whole.

A Definition

Systems design is that set of processes and activities whereby the specifications as to how that data is to be gathered, maintained, processed into information and made available to the user who articulated those requirements.

One can see from the above that there are in fact substantially differences between systems analysis and system design. In fact it could be argued that we are not talking about two processes, but in fact three processes - analysis, examination and study, and design.

Systems analysis works with tangible things and activities and how they act and interact today. Systems analysis also works with data and procedures and their interaction. In many cases the analysis uncovers many areas of miscommunication of information. This miscommunication is due to differing definitions, differing interpretations, and differing use of organizational data. The analysis also frequently uncovers many inconsistencies in data, personal files which do not correspond to public corporate files, data which has been extracted from one context and used in another, and the use of different or at least highly modified procedures in different parts of the firm to perform the same activities.

These business activities can be observed, examined and described, and that description can be compared to the original for verification and validation. The description either conforms to reality or it does not. The analysis is correct to the extent that it is complete and to the extent that it compares accurately to the original. Systems analysis works in the present, and to an extent in the past. It works with, and attempts to understand and describe what is.

Examination and study works with the results of analysis, looking for ways to improve. It attempts to identify the problems with what is, and the opportunities for change. It also attempts to document the needs and requirements for what should be changed or added. The examination and study phase attempts to identify the sources of both procedural and data problems, and to the extent possible to identify which data to use, and which procedures to follow, when conflicts are identified.

Systems design on the other hand, works in the future. It is a plan for what activities should be performed in the future, how they should be performed (the procedures) and what resources are needed for the performance of those activities. Most importantly, it is the development of a framework within which those activities must be performed. That framework is what provides order and harmony to the whole. The design may be taken to any level of detail necessary, or possible to fully describe what must changes be made and how, when and where they must be made.

Systems design must also address business data, its storage and its use. The design documentation must resolve the problems of conflicting definitions, conflicting use, inconsistent processing, questions of data ownership, data currency, and perhaps most importantly the questions of data responsibility; who must collect the data, who must maintain the data, who may access that data, and who determines when it is no longer of value to the firm. In some firms these issues are addressed when new data is identified and the systems are designed for its processing. In other firms these issues have been deferred for many years and are only addressed when the organization embarks on a system redesign project.

Obviously, the lines between systems analysis and systems design are blurry at best. Most authors have treated the two topics as one, and to the extent that design is a continuation of the analysis process, it is correct to do so. However it must be stressed that there are in fact, three processes.

These processes are not separable. Analysis, and examination and study are performed so that we can make modifications and come up with a new design. The reason for a new design is because we need to make modifications, and the scope and extent of those modifications were based upon analysis, examination and study. We cannot do any one without the other two, and in fact have little if any reason to do any one without the other two.

Most of those authors have presented systems analysis and system design in the form of a methodology - a fixed set of processes, activities and tasks which when accomplished will produce a design. To the extent that analysis and design are two ends of the same process they were also correct in developing a common methodology.

Design and analysis differ in distinct ways. First, their goals. The goal of analysis is to break down into component parts for examination. The goal of design is to construct from component parts.

System Components

Given the above the components of a business system consists of:

1) A framework which specifies the processes activities and tasks which need to be performed, and how those processes activities and tasks are related and interdependent. It also specifies the interprocess, interactivity and intertask rules to which all processes, activities and tasks must conform in order to operate in an orderly and harmonious manner

2) The individual procedures which specify in detail how each process, activity and task is to be performed and how each is to interact with all other related and interdependent processes, activities and tasks.

3) The physical, personnel, and monetary resources which are used by each procedure. The limitations or constraints in terms of time, personnel, budgets, data and standards upon each procedure.

4) The data which are the raw materials of business processes, the schemes under which that data is organized and the files in which that data is stored. Business data also includes the methods of presenting that data, either on screens, reports, forms, or other media. Business data, in keeping with our previous definition of data, also includes the definitions , explanations and agreements which provide common meaning and value to that data.

Although we have defined data as an integral part of a business system, and obviously it is, we must also recognize that business data transcends most business systems. A processing procedure is little more that a formalized series of instructions describing how to accomplish some task, and a system itself is little more that a framework for organizing those procedures so they work in an orderly manner. Within the framework of a given user application, there may be different kinds of systems, and different kinds of design environments. Each type of system and each type of systems environment has a different set of considerations and thus no one design approach will suffice for all.

Business data however represents both information and knowledge. Businesses can operate with inconsistent procedures, most do so every day. Businesses can operate with chaotic procedures, again most business have areas where their procedures are less than perfect. Business cannot operate without information, nor can they operate without correct information. That means that business cannot operate if the data from which they derive their information is defective. They cannot operate for long without consistently defined information, for to do so is to construct a corporate version of the tower of babel.

Business data is also the means for corporate communications, and to the data is correct business communications - both horizontally and vertically - will be clear and precise.

Systems versus Applications

There are two additional terms terms which are used somewhat interchangeably within the data processing community: system and application.

An application is the way in which a specific technology, such as data processing, has been used to solve a specific user business problem. Some examples of applications are: order entry processing, inventory record processing, payroll processing, personnel record keeping, customer statement generation, and accounts receivable or accounts payable processing.

In these examples, data processing technology has been used to support and accomplish a set of use area processing activities. These activities have not been wholly automated, only some of the highly structured, repetitive, well proceduralized, well defined, specific tasks of the data collection, filing, record keeping, calculation, printing and reporting have been taken over by the computer. Many of the other tasks within the same processes remain manual.

A system is the complete framework within which mutually supportive processes, activities and tasks operate. A good system is one in which these processes, activities and tasks operate in a cooperative, harmonious, efficient, orderly, timely and controlled manner. The processes, activities and tasks encompassed by a system may or may not be automated, and if automated may not be completely automated.

From the process perspective, new system development is undertaken for one or more of the following reasons. To enable:

1) new activities to be performed
2) existing activities to be performed in a more efficient, cost effective, rapid or timely manner
3) more iterations of a given activity sequence to occur in a specified period of time
4) greater management control
5) more efficient use of company resources
6) greater cooperation between the various activities which have to be performed.
7) a greater level of integration between system components
8) the use of new technology or the replacement of obsolete technology.
9) a faster response to future changes

From the data perspective, new system development is undertaken for one or more of the following reasons. To enable:

1) new data to be acquired
2) existing data to be enhanced or modified by the addition of new or modified coding structures
3) data to be more accessible, or to provide more flexible accessibility to data
4) greater management control over data
5) to add new data to existing files
6) to clean up, scrub or otherwise consolidate data from several files into one central file
7) a greater level of integration between system data files
8) the use of new technology or the replacement of obsolete technology as the means for storing company automated company