Design Phase

As software supported more and more business activities, developers created many programs and files to perform different functions. Programs have to know how data is stored in files to be able to share information. Early software systems were much like patchwork quilts, with random pieces sewn together. Development was slowed for several reasons: (1) early programs were not documented, so developers had to read each other’s code to be able to share data; (2) as more and more programmers were working on the same systems, original programmer knowledge was not available; and (3) early programming did not follow any programming standards, so every program was different.

For all of these reasons, the waterfall approach suggested that someone in IT (a systems analyst or architect) draw a design of the programs and files needed by the system before coding started. These designs also began to document file exchange formats so that different programmers could be working on different yet related programs at the same time. The design phase also included documents called “program specifications,” which described to the developer what his or her program was expected to do. These were initially very brief and evolved into more complete documents over the years.

Construction Phase

Only after completion of the first three phases did coding or construction begin. This was another radical concept at the time. (It is interesting to note that although most IT professionals have always agreed that planning, analysis, and design should be done before coding—in practice, this is still one of the industry’s biggest weaknesses!)

Testing Phase

Early software didn’t reside in test vs. production states. When coding was done, the user was given the results. If the results were not correct, the code was changed. Methodologies recommended that code be tested before being used by business people. This was another radical concept.

For today’s BAs, the concepts introduced in the waterfall probably seem very obvious. Despite some negative publicity, many organizations still use waterfall or a modified waterfall approach very successfully. All later software development approaches and methodologies are measured against this original standard. No other approach has introduced as many key development precepts as the waterfall.

Information Engineering

Adds the importance of requirements models and introduces a data-centric focus Utilizes JAD to bring business stakeholders into design discussions

In the 1980s, several methodologies (built on the foundations of waterfall) moved the IT industry toward a more data-centric approach. The volume of data that was being collected and managed by organizations forced IT managers to focus on better strategies for data design and management. In addition, the relational database structure was becoming commercially available and promised to make data inquiry easier (Martin, 1986).

Information engineering (IE) was so named because it recommended a data focus and a more structured “engineering-like” discipline for software requirements and design. It brought together several diagramming techniques: entity relationship diagramming, data flow diagramming, flowcharts, decomposition diagramming, and structure charts (see Chapter 6 for information on these techniques). IE introduced the concept of traceability (although it wasn’t named until later) by showing how the various diagram components could be related to each other (e.g., a data store on a data flow diagram could be linked to an entity relationship diagram). These networks of linked diagrams were called a model. This was the beginning of business modeling, information modeling, object-oriented modeling, etc. IE also encouraged an “analyst” role and continued to suggest better requirements communication with business people. IE planning and analysis phases advocated the use of business language in models and requirements. IE’s popularity was driven by the availability of CASE (computer-aided software engineering) tools. The complexity of these tools drove them to virtual extinction, and therefore IE is rarely used today.

IDEF

Developed at the same time as IE but from a government perspective Reinforces the value of modeling requirements

The U.S. government, in managing large software development projects, evolved a series of software methodologies from manufacturing/engineering techniques. These approaches were also based on the waterfall approach with phases, deliverables, roles, and sign-offs. IDEF was a product of the Integrated Computer-Aided Manufacturing (ICAM) initiative of the U.S. Air Force. IDEF initially stood for ICAM DEFinition language; the Institute of Electrical and Electronics Engineers (IEEE) standards recast IDEF as “Integration DEFinition.” Like IE, this approach acknowledged information (data) as a key requirement component and used models to represent requirements. IDEF requires a more formal review and sign-off process than IE. Several methods were outlined for IDEF. Four of them were used for business analysis: IDEF0 (functional modeling), IDEF1 (information modeling), IDEF1X (database modeling), and IDEF3 (process description capture). IDEF0 functional modeling diagrams are still in use and supported by a few graphical diagramming tools.