Principles of Software Engineering

We started this chapter on the assumption that software development is a creative activity and that programming is not an exact science. From this point of view even the term software engineering may be considered unsuitable since we could preferably speak of software development technique, which term does not imply the rigor of a formal engineering approach. In our opinion it is a mistake to assume that programs can be mechanically generated by some mechanical methodology, no matter how sophisticated. When software engineering falls short of producing the expected results it is because we over-stressed the scientific and technical aspects of program development over those that are artistic or aesthetic in nature or that depend on talent, personal endowments, or knowhow.
Nevertheless, as there is technique in art, there is technique in program development. Software engineering is the conventional name that groups the technical and scientific aspects of program development. Smaller software projects usually take place within the constraints of a limited budget. Often financial resources do not extend to hiring trained software project managers or specialists in the field of software engineering. The person in charge of the project usually wears many hats, including those of project manager and software engineer. In fact, it is not unusual that the project manager/engineer is also part-time designer, programmer, tester, and documentation specialist. What this all means is that the formality and rigor used in engineering a major project may not apply to one of lesser proportions. In other words, the strictness and rigidity of software engineering principles may have to be scaled down to accommodate the smaller projects. In this sense we must distinguish between principles, techniques, and tools of software engineering. Principles are general guidelines that are applicable at any stage of the program production process. They are the abstract statements that describe desirable properties, but that are of little use in practical software development. For example, the principle that encourages high program reliability does not tell us how to make a program

reliable. Techniques or methods refer to a particular approach to solving a problem and help ensure that a product will have the desirable properties. Tools are specific resources that are used in implementing a particular technique. In this case we may state as a principle that floating-point numbers are a desirable format for representing decimals in a digital machine. Also that the floating-point techniques described in the ANSI standard 754 are suitable for our application and should be followed. Finally, that a particular library of floating-point routines, which complies with ANSI 754, would be an adequate tool for implementing the mathematical functions required in our application. Figure 1.1 graphically shows the relationship between these three elements.

 

Figure - Relation between Principles, Techniques, and Tools

2.1 Rigor

One of the drawbacks of considering a program as an art form is that it places the emphasis on inspiration rather than on accuracy and preciseness. But programming is an applied rather than a pure art. We may find it charming that Michelangelo planned his statue of David rather carelessly and ended up with insufficient marble for sculpturing the feet. But a client may not be willing to forgive an artistically-minded programmer who did not find inspiration to implement hyphenation in developing a word processor program. We must conclude that the fact that programming is often a creative activity does not excuse us from pursuing program design and development with the necessary rigor.

Some authors distinguish between degrees of rigor. The highest degree, called formality, requires that development be made strictly according to laws of mathematics and logic. In this sense formality is a high degree of rigor. One field in which the issue of rigor and formality gains particular importance is in software specifications. A logical formalism has been developed which allows the precise specification of software. The mathematical expressions, usually based on the predicate calculus, allow the representation of complete programs, or of program fragments, in symbolic expressions that can be manipulated according to mathematical laws. Some of the advantages of this methodology claimed by it advocates are the following:

1. Formal methods allow the software engineer to specify, develop, and verify a software system using a formal specification language so that its correctness can be assessed systematically.

2. They provide a mechanism for the elimination of program ambiguity and inconsistency through mathematical analysis, thereby discovering errors that could otherwise go undetected.

3. They allow a software problem to be expressed in terms of an algebraic derivation, thus forcing the specifier to think in more rigorous terms.

4. These methods will eventually make possible the mechanization of programming, thereby revolutionizing software development.

On the other hand, the detractors of formal methods of specification also have their own counter arguments:

1. Formal specifications are difficult to learn. Nothing short of a graduate course is required to obtain even a cursory understanding of this subject.

2. So far these methods have not been used successfully in practical program development.

3. Most programmers, even most software engineers working today, are unfamiliar with formal specifications.

At this point we could declare that because the scope of our book is the development of smaller size programs we will be satisfied with rigor and exclude formal methodologies from its contents. But the fact is that some smaller programs that deal with a particular subject matter can (perhaps should) be specified formally. Therefore, we exclude the consideration of formal methods of specification based purely on expediency. Our excuse is that this is a rather intricate subject, and that most program development done today still takes place without the use of formal methods of specifications.

Therefore we settle for the lowest level of rigor, which we define as the methodology for program development based on following a sequence of well-defined and precisely stated steps. In the programming stage of development rigor is unavoidable. In fact, programming is performed in a formal context of well-defined syntax and semantics. But rigor should also apply in every stage of the program development process, including program design, specification, and verification. A program developed according to a rigorous methodology should contain the desirable attributes previously mentioned. In other words, the results should be reliable, understandable, verifiable, maintainable, and reusable.

2.2 Separation of Concerns

It is common sense that when dealing with complex issues we must look separately at its various facets. Since software development is an inherently complex activity, separation of concerns becomes a practical necessity. A coarse-grain observation of any construction project immediately reveals three concerns or levels of activity: technical, managerial, and financial. Technical concerns deal with the technological and scientific part of the project. The managerial concerns refer to project administration. The financial concerns relate to the monetary and fiscal activities.

An example shows this notion of separation of concerns into technical, managerial, and financial. Suppose homeowners are considering the possibility of building a new garage. The project can be analyzed by looking at the three separate activities required for its completion. Technically, the homeowners must determine the size, type, and specifications of the garage to be built and its location within the property. A finer level of technical details could include defining the preparatory groundwork, the concrete work necessary for the foundation, the number and type of doors and windows, the siding, the electrical installation, roofing, as well as other construction parameters. The managerial aspects of the project may include supervising of the various subcontractors, purchasing materials, obtaining necessary building permits, and the timely disbursing of funds. Financial activities include evaluating how much the project would add to the value of the property, selecting the most desirable bids, and procuring a construction loan.
It is important to realize that separation of concerns is a convenience for viewing the different aspects of a project. It is an analytical tool which does not necessarily imply a division in the decision authority. In the previous example, the homeowners may decide to perform the financial activities themselves, while they delegate the managerial activities to a general contractor, who, in turn, leaves the technical building details to the subcontractors. Nevertheless, it is a basic rule of capitalism that whoever pays the bills gives the orders. Therefore the homeowners would retain the highest level of authority. They would have the right to request managerial or even technical information from the general contractor, who they may override as they see fit,

or even fire if they deem it necessary.
By the same token, the participants of a software development project should always be aware of the fact that separation of concerns does not imply any permanent delegation of authority. The fact that a software designer is assigned the task of defining and specifying the program does not mean that whoever is in charge cannot step in at any point in the project’s development and override the designer. In this respect two extremes should be avoided. In one case the participants in the project lose sight of where the final authority resides and are misled by the assumption that it has been totally and permanently delegated in their favor. This misconception often generates a take-it-or-leave-it attitude on the part of the project’s technical staff who seem to state: “this is what is best, and disagreement only proves your technical ignorance.” The other extreme occurs when authority is held so closely that the participants are afraid of showing their knowledge or expertise for fear of being ridiculed or overridden.

It is the task of those in charge of a project to make their subordinates aware of where final authority resides and of the fact that this authority will be used if necessary, perhaps even in a form that may seem arbitrary. Also, what are the delegated levels of decision and the boundaries within which each participant can be freely creative? This initial definition of the various levels of concern, responsibility, and authority is a most important element in the success of a software development project. We have seen that the notion of separation of concerns is related to separation of responsibilities; furthermore, it is related to specialization of labor. At the coarser level this determines the separation of activities into financial, managerial, and technical. Each of the groups can be further subdivided. For example, the technical staff can be divided into specialists in program design, coding, and testing. The coding personnel can be further specialized in low- and high-level languages, and the high-level language ones into C++, Pascal, and Cobol programmers. By the same token, the program designers can be specialists in various fields, and so can the managers and financial experts.