APPLICATION TO SOFTWARE ENGINEERING

Software projects have a notorious reputation for going out of control. We mentioned in Chapter 1 the US Navy's A-12 attack plane. (By the way, while the first edition of this book was being written, the A-12 project was canceled !) One of the elements cited in the A-12 cost overrun was software; and increasingly, as software intrudes into more and more areas of our lives, and as we use software to do increasingly complex (not to mention life- threatening !) tasks , we find that software projects go haywire.

That this should be so is hardly surprising. Software development as a discipline is less than 50 years old. When you compare it with something like the construction of buildings which has been going on for several thousand years, it seems only to be expected that software development should still have the status of a cottage, almost a craft industry. It is one of the few labor- intensive industries remaining, and to all intents and purposes, every element of a software product is still handmade. (Even pre-processors or code generators require handcrafted input!) This is not to say that there have been no efforts to move the discipline forward. A rash of methods appeared during the 1970s and 1980s, and as a result of this it was judged that software development had now achieved the status of an engineering discipline. Hence the phrase software engineering. Note that in the process, a lot of phraseology from other disciplines “ for example, sub-assemblies (from manufacturing), architecture, build (from the construction industry) “ drifted into the software engineering vocabulary.

We talked in Chapter 2 about making a list of jobs to get you to the next horizon. Software development has already defined the main horizons for you. There is the concept of a product development life cycle (PDLC) and the horizons correspond to phases in the PDLC. Anyone who has ever worked on a software project will be familiar with PDLCs. In large organizations PDLCs are an end unto themselves and departments exist to maintain them. For the purposes of this chapter, we are going to assume a software development life cycle consisting of six phases. These six phases are:

1. A plans and requirements phase.

2. High-level design. This will include the commencement of user documentation and test plans.

3. Low-level design.

4. An implementation phase. This will include coding, unit testing, integration, integration testing and the completion of test plans and user documentation.

5. Alpha test “ a test of the system, preferably by an independent team, using the test plan.

6. Beta test “ a real-life test by a controlled group of final users of the system.

Note

Don't worry if your software development life cycle doesn't correspond exactly to the one we are using here. Once you have seen what we do, you will see that it will fit easily on to whatever life cycle standard is used by your organization. The rest of this chapter shows structured project management operating on the project as a whole and within each of the phases.

Plans and requirements

Visualize what the goal is; set your eyes on the prize

The first step on all software projects is (or should be) a statement of requirements; called in our PDLC a requirements specification (RS). The RS gives the requirements that the software system to be developed will satisfy . Thus it describes:

• what the system will do

• how it interacts with the world outside it

• the performance levels expected of it

Properly written, the RS is a statement of the prize. There are various ways you can approach writing a RS.

• At its most basic, the above three items constitute a checklist for a RS.

• There are also numerous checklists in the literature; as well as an increasing number of methodologies for identifying, documenting and tracking requirements. All of these fancy tools have their place and can help, particularly in controlling the vast amount of information which results from a system development effort.

• My company, ETP, offers a consultancy service called AAD (accelerated analysis and design) which is basically a 5 “10 day brainstorming session in which all of the requirements and some of the design of a system can be carried out, provided that all the decision- makers on a project are involved.

Also, irrespective of what checklists or tools you may be using, you should still go through the visualization described in Chapter 1.

Make a list of the jobs that need to be done

Treating the RS as the first horizon very quickly enables us to identify the jobs we have to do to get there. This list is very straightforward, and is probably something like:

• get the RS written

• one or more levels of review (internal/external)

• one or more levels of rework

• sign-off

Visualizing the prize enables us, to some extent, to see beyond that first horizon and build our job list. We know what the next big horizons are because our PDLC gives them to us. Also the last few jobs to be done (put the software on to a disk, ship it, install it at the user site, etc.) are very apparent. The bit in the middle will be a trackless waste of pretty much Polar proportions , and all you can do at this stage is to estimate it. Estimation is discussed in detail in Chapter 14.

There must be one leader

There is nothing more to say here over and above what was already said in Chapter 3.

High-level design

We have reached the first horizon: the RS is written and, more importantly, we can picture the goal in shining detail. However, our immediate interest now focuses on getting a high-level design (HLD) done. If the RS describes what the system will do, what it looks like on the outside, the HLD describes what the major bits of the system's internals look like “ the heart, lungs, liver, and so on.

Visualize what the goal is; set your eyes on the prize

The HLD can be pictured as a block diagram showing your system's major components . Eventually this block diagram will decompose into many smaller blocks, right down to the program or module level, but for the moment it just has the big blocks.

Make a list of the jobs that need to be done

A cycle similar to that for the RS; that is, write, review, rework, sign-off is probably all that is required here.

Low-level design

Second horizon reached. We must now decompose the HLD down to a sufficient level of detail that the system can be coded.

Visualize what the goal is; set your eyes on the prize

In our PDLC we have done our design in two jumps, HLD and LLD (low-level design). Irrespective of how many jumps you take to get there, and what you call these jumps , you must end up with a picture of your system. The picture is a block diagram showing all the components of the system to be built, right down to the smallest one. For large systems this may occupy many pages and have its own internal hierarchy. This now becomes the prize.

Make a list of the jobs that need to be done

The familiar cycle of write, review, rework, sign-off is what you need. I try to make it a rule never to commit to delivering anything until the LLD is complete. Most customers are happy with this, or if they insist on a fixed-price, cast-in-concrete estimate sooner than that, you make it clear to them that they are going to pay a heavily-loaded price, so that you can allow for your own risk and exposure (we discuss this problem again in Appendix 1 in the section Build in contingency).

Your job list will be a living thing, constantly changing to adapt to circumstances. New jobs will appear, jobs will complete, jobs will be found to be unnecessary and jobs will end up differently from what you originally envisaged. (This is why a computerized project planning system is very useful.) All these changes are good, routine stuff. Your list will be highly detailed for the short horizon and less so for the longer one.

Tell people what's going on

The only new point to be made here is this: if, during the design process, something emerges which significantly modifies expectations, then it needs to be made public. Good surprises you can keep secret until the moment you feel is best for you and your purposes. Bad ones, unfortunately , have to be made public, so that the outside world can adapt to the new situation.

Implementation

Design is complete and so we move on to writing and testing the code.

Visualize what the goal is; set your eyes on the prize

The goal is now a working system. If you are building your system as a series of increments , each having gradually more functionality than the previous one “ always a good way to proceed because of the fallbacks it allows you “ then this phase will contain a number of mini-phases each of which will represent an horizon along the way.

Alpha test

Your system is complete and works to the developer's satisfaction. The test plan is now run against the system, preferably by somebody other than the developers.

Visualize what the goal is; set your eyes on the prize

The goal is a working, bug-free (insofar as is humanly possible) system or product.

Beta test

Your system or product is released to a limited number of users/customers. It operates under field conditions and corrections/enhancements are made to it by the developers.

Visualize what the goal is; set your eyes on the prize

The goal is what you labored for all this time: a system or product that the users love and/or that sells in thousands.