The Software Engineering Process and Relational Databases

This chapter introduces some concepts that are essential to our presentation of the design of the database. We begin by introducing the idea of "software engineering" — a process of specifying systems and writing software. We then take up the subject of relational databases. Most databases in use today are relational, and the focus in this book will be to design a relational database. Before we can actually get into relational databases, we introduce the idea of functional dependencies (FDs). Once we have accepted the notion of functional dependencies, we can then easily define what is a good (and a not-so-good) database.

What Is the Software Engineering Process?

The term "software engineering" refers to a process of specifying, designing, writing, delivering, maintaining, and finally retiring software. There are many excellent references on the topic of software engineering (Schach, 1999). Some authors use the term "software engineering" synonymously with

"systems analysis and design" and other titles, but the underlying point is that any information system requires some process to develop it correctly.Software engineering spans a wide range of information system problems. The problem of primary interest here is that of specifying a database. "Specifying a database" means that we will document what the database is supposed to contain. A basic idea in software engineering is that to build software correctly, a series of steps (or phases) are required. The steps ensure that a process of thinking precedes action — thinking through "what is needed" precedes "what is written." Further, the "thinking before action" necessitates that all parties involved in software development understand and communicate with one another. One common version of presenting the thinking before acting scenario is referred to as a waterfall model (Schach, 1999), as the process is supposed to flow in a directional way without retracing. An early step in the software engineering process involves specifying what is to be done. The waterfall model implies that once the specification of the software is written, it is not changed, but rather used as a basis for development. One can liken the software engineering exercise to building a house. The specification is the "what do you want in your house" phase. Once agreed upon, the next step is design. As the house is designed and the blueprint is drawn, it is not acceptable to revisit the specification except for minor alterations. There has to be a meeting of the minds at the end of the specification phase to move along with the design (the blueprint) of the house to be constructed. So it is with software and database development. Software production is a life-cycle process — it is created, used, and eventually retired. The "players" in the software development life cycle can placed into two camps, often referred to as the "user" and the "analyst." Software is designed by the analyst for the user according to the user's specification. In our presentation we will think of ourselves as the analyst trying to enunciate what the users think they want. There is no general agreement among software engineers as to the exact number of steps or phases in the waterfall-type software development "model." Models vary, depending on the interest of the author in one part or another in the process. A very brief description of the software process goes like this:

1. Step 1(or Phase 1) : Requirements. Find out what the user wants or needs.
2. Step 2 : Specification. Write out the user wants or needs as precisely as possible.
3. Step 2a : Feedback the specification to the user (a review) to see if the analyst (you) have it right.
4. Step 2b : Re-do the specification as necessary and return to step 2a until analyst and user both understand one another and agree to move on.
5. Step 3 : Software is designed to meet the specification from step 2.
6. Step 3a : Software design is independently checked against the specification and fixed until the analyst has clearly met the specification. Note the sense of agreement in step 2 and the use of step 2 as a basis for further action. When step 3 begins, going mback up the waterfall is difficult — it is supposed to be that way.Perhaps minor specification details might be revisited but the idea is to move on once   each step is finished.
7. Step 4 : Software is written (developed).
8. Step 4a : Software, as written, is checked against the design until the analyst has clearly met the design. Note that the specification in step 2 is long past and only minor modifications of the design would be tolerated here.
9. Step 5 : Software is turned over to the user to be used in the application.
10. Step 5a : User tests and accepts or rejects until software is written correctly (it meets specification and design).
11. Step 6 : Maintenance is performed on software until it is retired.

Maintenance is a very time-consuming and expensive part of the software process — particularly if the software engineering process has not been done well. Maintenance involves correcting hidden software faults as well as enhancing the functionality of the software.