System Development Life Cycle - Design

The third phase of the System Development Life cycle, and the subject of this book is system design - or to use a different set of terms the proposed environment analysis. Systems analysis is the decomposition of the current environment into its component pieces for examination and study. The design process is development of a plan for the building up of a larger harmonious unit from component parts. Most design techniques use a top-down approach, performing successive decompositions of the desired and expected final product to determine the component composition and structure of that final product.

From this decomposition the designer can determine where and how the existing components must fit, which components must be changed and how those components must be changed to fit the new design, what new components must be built, and what old components must be discarded. The final plan shows why and how all the component parts must fit together.

Because design can be considered a special form of analysis - analysis of the future or proposed environment - many of the tools and techniques of the analyst are used by the designer as well.

The difference being that the analyst uses these tools to describe what is whereas the designer describes what will be. The analyst works with components as they are today, the designer works with many of the same components, most of which however have little tags on them indicating how they must be changed.

Because of its goals, system design works best in a top down manner. Once completed however, that design is implemented from the bottom up. All of the components are changed on an individual basis, and these changed components are assembled with new components into successively larger and more complex subassemblies until the final product is completed.

To understand the process of design, one must understand that its aim is to describe the future as it should and will be. To put the process of system design in context, we will use the analogy of the construction trades. The analogy between the system designer and the building architect is illustrated in a series of charts created by John Zachman of the IBM Los Angeles Scientific Center. These charts were published in a paper by Zachman entitled "A Framework for Information Systems Architecture" (Table 4-1 and Table 4-2).

The construction of a building starts with the architect. The architect must first understand what the building is intended for - the use to which it will be put. He or she begins by extensive discussions with the owner or builder, to determine what is needed, and what shape would be most pleasing to the owner or builder. Are they looking for a tall thin structure or a short squat on, one that will stand out from all its surroundings, or one which will blend in harmoniously? Are they looking for a structure that is round, square, a polygon, or pyramidal?

Are they conservative, bold, or middle of the road? Do they want a structure which replaces an existing one, only more modern and up-to-date, or do they want to add additional capability, (i.e. mix office, plant, and residential on one complex?

Are they looking for a single, unified structure, or many smaller, more independent ones?

The architect begins by taking these basic requirements and developing very general pictures, usually in water color, which depict these basic requirements, the structure and framework, the scope and magnitude of the project. It will show the general shape, style and size of the proposed complex, and will attempt to place it, generally in context of its surroundings, showing, its relationships to other buildings as to size, architectural style and its placement on the intended property.

If these general plans are approved, or after they are modified and approved, the architect then renders floor layouts, lobbies, plazas and other features. These plans, still on a general basis, show where and how the various owner internal space requirements and needs are intended to be met. They show space access, style and decor, and how the internal space will be used to support and fulfill the general structure requirements and the individual needs of the various occupants and their customers and clients.After these plans are approved, the next step is to render blueprints, in fine detail, floor by floor, with all piping, ductwork, electrical and support members properly and precisely placed. These plans may be in several levels, must start with general floor layouts, and progress in successively more detailed plans to individual occupant plans. This general to detail progression of plan (or design) development is to ensure that the individual parts of the structure:

1. fit together seamlessly
   
2. are complete (that no pieces are lost in the mass of plans)
   
3. do not impinge or impact each other in a negative manner (that electric light fixtures are not placed in the same space as the air duct vents, etc.)
   
4. can be worked on by groups of contractors individually with their specific areas of work highlighted
   
5. can be completely specified with all supporting materials and notation which is specific to them (that the overall plans don't become a confusing mass of detail

Generally speaking, there may be many versions of these plans, some highlighting the electrical wiring and box placement, others highlighting the heating and air-conditioning ductwork and vents, and still others highlighting, phone and other communications wiring, wall members, door placement, and window locations, still others highlighting the placement of plumbing lines for water, restroom and sanitary facilities.

From these detailed plans, materials specifications are drawn and construction schedules and sequences are specified. A general contractor may be hired, or the architect may act as the general contractor.

For each type of construction (electrical, concrete, masonry, plumbing, etc.) workmen are hired and assigned specific tasks.The work is done, sometimes, in parallel, sometimes in sequence, but always according to the master plan.As with any project, the builder starts with the lowest level and works up. Floor three cannot normally be placed before floor two.

The development of a new system is undertaken in a similar manner. System designers, along with analysts and user liaisons, working with models and narratives, develop the concepts and ideas, the context, structure, framework and detail plans for the new system. They are the architects, the planners, and controlling force of the design process. They specify design, structure, usage and materials. They translate business context, functional requirements, process, activity and user task requirements, along with business data and information requirements into meaningful design.Their relationship to the application development groups is one of architect/consultant to contractor, and their relationship to user management is one of architect to employer. They can design, suggest, modify and implement, but the end product, in the final analysis, must meet the needs of its occupants, not vice versa.

When the design is successful, all parts work in harmony, each piece performing its required function.

Any system development life cycle must recognize this and allow for design as a multi-level undertaking in the same manner that it must allow for the analysis of the existing environment to occur in a multi-leveled manner. As with the analysis phase, although there can be many iterations of design, for practical purposes we usually restrict ourselves to three.

The first is identified as the general or business environmental design level and it concentrates on the firm wide functions, processes and data models. This has been called by some, enterprise design. This type of design project has the widest scope in terms of numbers of functions covered, and looks at the highest levels of the corporation. This level of design corresponds to the strategic level of the management pyramid. This design level establishes the general context within which the individual functional and system frameworks can be developed. this design level also establishes the standards which will be followed in the design process, the methodology which will be employed, the technology which may (or must be used), and the financial and other resource constraints which will effect the design team.

The second, is identified as detail business or client environmental design, and concentrates on the functions , subfunctions, processes and data of the individual client or user functional areas. This design is narrower in scope than an enterprise level design, and may be limited to a single high level function, such as human resources, finance, operations, marketing, etc. This level of design corresponds to the managerial or administrative level of the managerial pyramid. This design level defines the specific functional and system framework for the design which is being developed.The third, is the most detailed, and can be considered as the application level which addresses the design of the user processing systems. This type of project has the narrowest scope and usually concentrates on a single user functional area. It is within this level of design that individual tasks are addressed. This type of project corresponds to the operational level of the managerial pyramid. This design level defines and describes the specific procedures which will be developed and the resources, in terms of data, information, personnel and materials, which are needed by each procedure.The design phase uses the results from phases one and two to devise and design a proposed environment for the user. This proposed design presents the user with a revised function model, a revised process model and a revised data model. It is this phase which produces the final products of the analysis and design process.

We have illustrated why we feel that the design should be developed in a leveled manner - the general business level, the detailed business level and the application level. Regardless of the level being addressed or the methodology employed, each design level should

include the following activities (as illustrated in figure 4-1):

1. Proposed function design
   
2. Development of the proposed function model
   
3. Proposed process and activity design
   
4. Development of the proposed process model
   
5. Proposed data Source and Usage design
   
6. Proposed data analysis
   
7. Development of the proposed data model
   
8. Development of project implementation cost projections

One of the terms which is used extensively in systems development projects is "integration." Just what is integration, and what do we mean when we say a system is integrated? How do we design an integrated system? As always we should begin with a definition.To integrate is to make into a whole by bringing all parts together. to unify, to join with something else. The organization of all parts into a harmonious whole.

It would seem then that by definition all systems are integrated since a system is a harmonious whole as well. It would seem further that the process of system design is also the process of integration.But we have said that integration is the bringing together of all parts - in a system what parts are we talking about? What do we bring them together for? How do we bring them together? And finally why must we bring them together at all? Why do we need to design systems?

Another question and equally important in our discussions is - when is a system fully integrated? At what point is a system complete?

As we begin to answer these questions we will also introduce a few more concepts.

Goals of system design

There are various goals which are common across most system design projects. These are:

1. to increase the level of integration among the functions, systems, processes, activities, tasks and procedures of the firm
2. to increase the level visibility management has into the activities of the firm, and to increase the level of control that management has over those activities
3. to increase the responsiveness of the firm's systems and to increase their flexibility such that systems and procedural changes can be accomplished when business changes warrant.
4. to concurrently decrease the conditions which cause changes to the firms systems and procedures when business changes occur. In other words, to make the firms systems and procedures more independent of change.
5. to increase the level of standardization and conformity between systems and procedures
6. to increase the level of systems and procedural documentation
7. to increase the quality, accuracy, consistency and timeliness of the information needed by the business.

All systems by definition are integrated. But to paraphrase one of the animals in George Orwell's Animal farm - all systems are integrated but some systems are more integrated than others.

Systemization began with early efforts to apply a concept known as methods and procedures analysis to business activities. These methods and procedures analysts examined the tasks performed in offices and factories and developed improved, that is more efficient and more effective ways of accomplishing them. As new and improved procedures were developed for more and more of these tasks, they were collected into larger procedure sets to reduce the redundant activities, and to make each activity more unified with the whole. Activities were separated and rearranged to accomplish the tasks in a faster, more efficient, and more controlled manner.

As more and more procedures were collected under one control mechanism, and as more and more procedures were developed in a mutually supportive, interrelated and interdependent manner the systems became larger and larger and more and more integrated.The larger the system became, the more integrated the system became. The more integrated a system became the wider its span of control, and the wider the base of company functions it supported. The drive to integration has led some to design systems which attempt to incorporate all procedures which appeared to be even remotely connected under a single control umbrella.

To accomplish this integration, to design these super large systems, various mechanisms have been developed to assist the system designers in their tasks. These mechanisms have not concentrated on the procedural level, nor on the activity or even the process level, instead they have attempted, with varying degrees of success, to focus on the framework level.

The most completely integrated systems are those which attempt to look at the corporate environment from the highest or broadest perspectives, from a top-down, cross-functional, or cross business unit perspective.

To illustrate: a completely integrated system would be one which looks at Human Resources, rather than Payroll and Personnel as separate processes, or at General Ledger rather than at Balance Sheet, Accounts Payable and Receivables, etc. Completely integrated systems are modeled along functional, business and strategic lines rather than along process and operational lines.

Completely integrated systems recognize the interdependency of user areas and try to address as many of these interrelated, inter-dependent areas as is feasible. These integrated systems are usually oriented along common functional lines, common data requirements or along some other business thread which can serve to tie all of the separate processes together in a unified manner.

Integrated systems are usually developed using a top-down design since it is easier to determine overall requirements, and because integrated systems development makes it necessary to understand at a very high corporate level, the interdependencies and interrelated nature of the various applications which must be hooked together.

The most completely integrated systems are very difficult to design and generally require more time to implement than if the separate parts were developed in a less integrated manner.

Since integrated systems cross functional, and thus user boundaries, many user areas must be involved the design and implementation phases. A multi-user environment is much more difficult to work with, since although the system will be integrated, the users are normally not. Each user brings his or her own perspective to the environment, problems and requirements, and these differing perspectives may often conflict with each other. The designer must resolve these conflicts during the design process, or during the later review and approval cycles. In addition to the conflicting perspectives, there are normally conflicting system design goals, and more importantly conflicting time frames as well.

There are no hard and fast guidelines which distinguish candidate systems for integration. Systems which appear to be totally Stand-alone, that is systems which may appear to be totally complete in an of them selves, can be integrated with other systems if the correct integration mechanism is found. There are no size or complexity distinguishing characteristics.

The level of integration which a firm can introduce into its systems is dependent upon the following issues:

1. The location of the firm on the growth cycle. Firms in the early stages of the cycle should not attempt to develop highly integrated systems, whereas firms in the late stages should always strive for them.
   
2. The ability to assemble all interested and relevant users, and the ability to get them to agree to participate, compromise where necessary, and to jointly fund the project.
   
3. The commitment from user management to devote the time and resources to a complete top-down analysis the commitment of that user management to participate in the design of the new system.
   
4. The ability to get all users to share the stored data, and to share the tasks of data acquisition and maintenance.
   
5. User understanding of the processes and functions which the system would ultimately be designed to service.

As businesses change and as the need for systems changes occur on a more and more frequent basis, firms are taking the opportunity to expand the scope, control capabilities, and level of integration of those systems. This desire to move these systems further up into the corporation, further out on the growth and maturity curves, and to incorporate more and more information capability into them, makes it more and more necessary, and in fact imperative to redesign the framework of these systems, the manner in which the individual procedural components operate separately and interdependently, and the manner and type of resources which are used in the performance of those procedural operations.

Thus we see that we cannot repair, nor even in many cases renovate these systems, but we must completely redesign them from all perspectives. Because we are effecting change, we must work with the existing environment, we must include those items of change which have been identified during the analysis as needing to be included, and we must include all of the items which we can anticipate will be needed in the future.

One mistake which I believe many system designers make is to forget the timeframes within which they work. The existing systems were developed in the past and could not be changed fast enough or completely enough to keep up with the rapid pace of business changes. In many cases changes were not made in a coordinated manner and thus change made in one area to correct one problem, may have caused problems which did not previously exist in other areas.

Once the decision has been made to examine and correct the accumulated problems within the systems and to include the back log of changes which had not yet been made, the analysis, examination and study and design process starts. But these processes and the resultant development, implementation and testing periods also take time - perhaps as much as one to three years.

During the time when the system is being changed the corporation continues to change. The existing systems must still be modified to accommodate the more pressing business changes, and the backlog of changes not included in the new design process begins to build again. The relationship between the business change curve and the system design time frames is illustrated by figure 1-1.

Thus by the time the new system is in place, it is operating amid an environment which is different from that which existed when it was begun, and a new backlog of changes is waiting to be added into the new system. This never-ending process is typified by the three system life cycle components of system development, system enhancement, and system maintenance. The differences between the three components is in the scope and scale of the changes being made, and the impact of those changes.

All Data Processing projects can be assigned to one of three major categories, development, enhancement, and maintenance. Although the phases involved in each of type of project are approximately the same, they vary in degree of difficulty and scope. Even among projects within the same category, there may be large differences in scope and difficulty. Generally, however, each of these types of projects requires some degree of analysis, design, coding, testing and implementation.

Applications maintenance and enhancement projects differ from Development projects in one substantial way. That being that the analysis and design personnel assigned to these projects must also assess the impact of the proposed change on an existing system.

These maintenance or enhancement projects, usually leave large parts of the base system intact. The remaining parts are either modified, or "hooks" are added to the additional code. The requests for maintenance or enhancement changes normally originate with the user, although they may originate with the development team itself. There are numerous reasons for these system modification requests, among them are changes to the business environment, user requested additional capability, correction of erroneous Processing, and user requested refinements, or cosmetic changes, to the existing system.

Those changes which originate from alterations to the business environment are the most difficult to implement, followed closely by those which add new capability. The implementation difficulties arise because these types of changes not only require new analysis of the user area but also re-analysis of the original system design to determine where, and how, the changes can, and should, be made. maintenance or enhancement which is necessitated by correction of erroneous Processing, User desired refinements, or other cosmetic changes, usually require little in the way of new analysis.

The analysis and redesign efforts required by business environment changes and additions of new Functionality can be almost as extensive as that which was required in the original systems development.

The most difficult aspects of any change to an application system are those which are directed either toward changes in underlying system design and the resulting processing logic, or toward changing the structure and contents of the Data base.

When the maintenance or enhancement project is directed at a system in a database environment, and the database must be changed, that analysis must not only cover the application in question, but also any other applications which use the same data base and in particular the same data records or data elements. In some cases, the immediate enhancement or maintenance project will require data which should logically be captured by a different, unrelated, application. The "chain reaction" or "cascading" of changes can increase the scope and impact of the initial request by orders of magnitude. The greater the integration or interdependence, the greater the potential impact of any change.

We can see from the above discussions that it is not enough to have analyzed and to understand the individual procedural changes but we must also understand the impact of the changes on the system, the direction in which system design must be taken and the reasons why those directions are valid.

We must understand the various ways in which frameworks for these new systems can be developed and what are the mechanisms for increasing the level of systems integration.In chapter one we stated that a system design 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, monetary and data (forms, reports and reference materials) resources which are used by each procedure. The limitations or constraints in terms of time, personnel, budgets, data and standards upon each procedure.Because the quality and strength of the framework is critical to the success of the design project, we will discuss various techniques for understanding framework perspective and for creating sound system frameworks.

One final point which needs restating here. Of the three components of system design, only two are observable, and based upon physical reality. Of the two only one is consistently real - the individual procedures. While some of the resources are physical - the people, and money, the data is conceptual - hard to visualize, hard to identify and describe.

Because we are building a plan, in advance of implementation, a set of specifications which we want to be able to verify and validate, we must rely heavily on narratives and even more heavily on diagrams and pictures which describe that which we wish to put in place. These diagrams and narratives form models of the proposed environment, an environment which does not and will not exist until we are sure of what we wish to develop.

These models provide us with something to look at in lieu of reality. They provide us with a mechanism for understanding, testing and validating. There are many different types of models, many different types of diagrammatic notation. We should remember as we use them however that there are limitations to notation, and limitations to any model. No model can fully represent reality or even one aspect of reality. The more conceptual the component to be modeled, the more difficult it will be to model it.

We must therefore remember that while we must stress clarity of notation, we must also remember to separate modeling notation from model content. If we need to change the notation of the modeling technique we are using to improve content and clarity of meaning then we should be free to do so. If by mixing and matching different notational styles we improve clarity of content we are free to do so. Most notational styles exist to assist the designers, not to restrict them.

We must also remember that models are usually built to allow us to isolate certain components within the design for examination and study, and that they also allow us to separate structure from detail. Certain types of models only allow certain levels of detail, and certain types of models will only portray certain aspects of the design. Models show us how the pieces fit together, and what the final structure will look like when all the pieces are in place. they allow us to make changes easily and quickly without impacting the real world.

One last system design concept before we move on to other topics. One term which is used very frequently, and very inconsistently is the term "logical." We have logical data models, logical systems, logical designs, logical this and logical that. Logical has become one of those overused terms which have lost their meaning through inconsistent usage.

In as much as I will need to use the term logical to qualify certain aspects an components of the design process I will present the definition I use for logical and the general context within which I will use the term.

The definition of logic is:

• A mode of reasoning which is based upon the relationship of element to element to whole in a set of objects, individuals principles and events.
• A thing which is logical is that which shows consistency of reasoning, and is reasonable based upon earlier statements or events.
• A logical system or logical design is one which is built upon consistency, and based upon a consistent line of reasoning.
• A systems which is based upon a framework where all of the elements have a reasoned relationship between them and all fit together based upon a common set of reasoning can be considered to be a logical system.

Logic is built upon rules which determine underlying fact and cause and which provides the basis for drawing reasoned conclusions. All logical models must be explainable and consistent. They must be based upon facts and reality, easily discernible, and easily provable. All cause should have effect, all effect should have cause. All components of the model must have a reason for existence.

Thus we can see that logical systems, integrated systems, even the concept of a system itself are all based upon the need and desire to develop a framework within which business activity can be performed in a harmonious, interrelated, interdependent manner, where all components are brought together according to a unified line of reasoning, according to a common set of rules, or because of some unified thread.