We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Methodology and The Government Information Factory (GIF)

Originally published July 1, 2004

The government information factory is a framework and architecture for the development of the information needs of any governmental agency. As such, there are multiple development methodologies found within the government information factory itself to support the creation of different sections or components.                                      

Waterfall Methodology (SDLC) The first methodology found within the GIF is the classical waterfall or SDLC – systems development life cycle – as defined by Ed Yourdon and Tom DeMarco in their work on structured programming.

The SDLC shown above consists of collecting of requirements, synthesis of those requirements into a statement of the work, analysis needed to turn the requirements into a system, the design itself, programming to embody the design, testing of the programming, integration of the code that has been created, and finally the implementation. The SDLC methodology has been called the “waterfall” methodology because the output from any given step in the methodology “pours over” into the next step. The steps in the SDLC are sequential.  There is a very prescribed and disciplined order in the way that the different steps are followed.

Spiral Methodology                                                                                                          The second development methodology found in the government information factory is that of the spiral development approach. In this methodology, there is a repeating pattern of development that recurs. The figure below shows the spiral development approach to development.

The figure above shows that approximately the same steps are done in the spiral approach as are done in the SDLC, but the difference between the two methodologies is that, in the spiral approach only a few requirements are collected and synthesized. The intent of the spiral approach is to quickly build a small part of a system in rapid succession. The SDLC attempts to gather all requirements before commencing with systems development, while the spiral approach, purposely, does not attempt to gather all of the requirements for a system. Prior to development of the system, the SDLC takes a long time to complete, while the spiral approach produces results very quickly, albeit partial results.

From the standpoint of development activities, there is not much difference between the SDLC and the spiral development methodologies. The difference is in the approach taken to gather the requirements and to doing many different iterations of development.           

Heuristic (Informal Methodology)                                                                                      A third approach to development is that called the heuristic approach. The figure bellow details the heuristic approach to development.

This figure shows that a very fast, informal development process occurs. The results of the development are analyzed, and then the results of that analysis suggest the next path of development to be followed. At the end of every development cycle the results that are obtained are used to suggest the next phase of development. Such an approach can be called the heuristic approach to development.

The SDLC is a very formal process, the spiral approach is a less formal approach, and the heuristic approach is an informal approach. The SDLC takes a long time to execute, the spiral approach takes much less time to execute, and the heuristic approach is very quick to execute.

The difference in the approach to requirements is the single largest difference between the three different methodologies. The SDLC requires that ALL requirements be identified before any development begins.

Massive amounts of requirements must be met before development commences. The implication here is that the requirements that are gathered are static and finite. If the requirements change before the system development commences, then the entire system may have to be redesigned. If all of the requirements are not present then the design of the system is in jeopardy.

Once the requirements are identified, they are reshaped into various forms of process models – data flow diagrams, HIPO charts, functional decompositions, etc.

In the spiral approach to development, there is heavy dependence on requirements being shaped into a data model, which is then used as a basis for the rest of the development cycle. There is much less emphasis on complete processing requirements being in place when developing the systems under this spiral development approach.

Under the heuristic approach to development, almost no requirements are in place when development commences.

In this case, management has only a small need as the starting point for development. There really are no formal requirements to be gathered when development of a heuristic nature is begun. In fact, one of the goals of heuristic processing is to discover what the requirements are.

One of the considerations about which methodology fits which circumstance depends entirely upon the nature of requirements. The SDLC methodology fits very nicely when an operational system is being built.

In an operational environment there is a certain repetition as to what is being done. In most cases operational systems apply automation to an otherwise manual process. The processes that are being automated have been done manually for a long time. In this case it is not a big problem to identify the process that needs to be automated. The SDLC meets the needs of the case where the activities that need to be automated are able to be identified and articulated before development occurs. 

The spiral development approach works well where there is a general direction (represented by a data model) but where all requirements are not known. The users operate typically in a “give me what I say I want, and then I can tell you what I really want” mode. The users operate in a mode of discovery. They say – “Now that I see what is possible, I can tell you what I really want,”

The SDLC concentrates on processing requirements. For this reason the SDLC is used to build systems with a limited, finite set of requirements.

The heuristic approach to development works well for systems that have no formal requirements.

A typical scenario for heuristic development is one where management feels that sales have been changing in recent months, but they are not sure what has happened. The information analyst is called upon to examine sales data and determine what trends are occurring.

The systems analyst looks at the data, first one way, and then another. It is typical that the systems analyst restructures the data in several ways before the insight becomes clear. Of course once an insight is achieved, the development process may go from a heuristic process to a spiral process or an SDLC process.

If there is an Achilles heel in the SDLC process, it is that the SDLC process requires all the requirements for processing to be gathered before the first stage of development is complete. 

In many cases it is very difficult to accumulate all processing requirements. The entire development process is put on hold for just a few more obscure requirements. This just doesn’t make sense from the standpoint of common sense. In the same vein, because it takes so long to gather requirements, some of the requirements change from the time they are gathered until development actually begins. For these reasons, then, the SDLC is a less than effective approach to systems development. 

A more effective general purpose approach to development is that of the spiral approach shown below:

The data model serves as an intellectual roadmap that allows different development efforts to coordinate their efforts, even though the development efforts may have no other connection. The data model is used to shape the first iteration of development. The second iteration of development builds upon the same data model. Upon completion, the results of the second iteration of development fit like a jig-saw puzzle with the results of the first iteration of development. When the third iteration of development is done, its results fit with the first and second iteration of development, and so forth. Even though the different iterations of development are done independently, they are unified by a common data model.

Because of this ability to weave together different requirements over time and space, the spiral development methodology is probably the best methodology for general purpose development of systems within the government information factory.

The heuristic development approach works in yet a different manner. The figure below shows how the heuristic development approach works.

There simply is no way to predict how long the heuristic development process will take, or how many iterations there will be. By the same token, there is no way to tell what the final results will look like. In fact, it is not even possible to tell whether there will even be any satisfactory results. In many heuristic efforts there never is a result that can be satisfying. There are absolutely no guarantees of success when it comes to the heuristic process.

From a scheduling process, the heuristic development process drives managers crazy because there is no way to tell how long the process will last and when it will end. Stated simply, heuristic processes cannot be scheduled and this, more than anything else, is the weakness of heuristic processes.

Because of the free-form, informal nature of heuristic development, it fits best with decision support systems and exploratory, analytical systems.

The significant differences between the different approaches to development are:

  • the gathering of requirements
  • the ability to schedule deliverables
  • the nature – size, shape, form – of deliverables,
  • the formalization of the process
  • the fundamental nature of processing – operational, decision support, etc.

An informal system can take the form of spreadsheets, note pads inside desks, numbers and diagrams on sheets of paper on walls, blackboards used to keep tally of activities or events, etc.

The informal part of a system develops up as the formal part of the system is being used. The growth of the informal part of a system is a sign of health of the formal part of a system.

In a sense, the growth of the informal part of a system is a requirements’ gathering exercise for the next iteration of development of the system. It is worthy of notice, that very infrequently will all of the informal requirements be gathered into the formal parts of the system.

There are certain similarities and certain dissimilarities between the three development methodologies – the SDLC, the spiral, and the heuristic. One of the marked differences is in terms of the permanence of the resulting systems. The SDLC and the spiral approach are used to produce programs and data structures that are meant to be enduring and reused frequently. The heuristic approach creates procedures and data structures that are designed to be used once and only once.

  • Bill InmonBill Inmon

    Bill is universally recognized as the father of the data warehouse. He has more than 36 years of database technology management experience and data warehouse design expertise. He has published more than 40 books and 1,000 articles on data warehousing and data management, and his books have been translated into nine languages. He is known globally for his data warehouse development seminars and has been a keynote speaker for many major computing associations.

    Editor's Note: More articles, resources and events are available in Bill's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Bill Inmon



Want to post a comment? Login or become a member today!

Be the first to comment!