Summary

As suggested in this chapter, software development is in a state of flux, with continuing initiatives to try to bring it from largely an art to a well-understood and repeatable engineering process.

Researchers and observers have given us much to contemplate, and new technologies as well as proferred solutions are in abundance. By adding new perspectives, they also add a ''confusion of plenty'' as we struggle to find the right answers that will improve the way we develop software. As final examples, we now look at some suggestions made by selected observers of the scene, followed by the ten commandments of software engineering.

First, we have the analogy provided by N. Augustine, a leader in government, industry, and academia:

Software is like entropy, it is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics, i.e., it always increases [10.27].

Second, we have the observations of E. Rechtin, previously the President of the Aerospace Corporation:

In architecting a new software program, all the serious mistakes are made on the first day.

A team producing at the fastest rate humanly possible spends half of its time coordinating and interfacing [10.28].

Third, we cite points ''Wirth'' noting, taken from an article by Niklaus Wirth, the designer of the programming language Pascal:

The way to streamline software lies in disciplined methodologies and a return to the essentials.

The most difficult design task ... is the decomposition of the whole into a module hierarchy.

The belief that complex systems require armies of designers and programmers is wrong [10.29].

Fourth, we are indebted to Frederick Brooks [10.30] for his many insightful contributions to software engineering, a few of which are cited here:

From this process [i.e., Wirth's top-down methods] one identifies modules of solutions or of data whose further refinement can proceed independently of other work.

A good top-down design avoids bugs in several ways

Adding manpower to a late software project makes it later (Brooks' Law)

Finally, we complete this chapter with this author's ten commandments for software projects:

Commandment 1. Formulate a software development plan and process that seem to work and stick with them.

Commandment 2. Maintain continuity of personnel and high-performance software development teams (see also Chapter 6).

Commandment 3. Adopt and adapt the notions of the Capability Maturity Model, coupled with a commitment to continuous improvement.

Commandment 4. Always do a detailed risk-assessment and -mitigation analysis at the beginning of a project, and at selected points during the project.

Commandment 5. Begin and maintain a program of software measurement and metrics, to include keeping statistics on all projects.

Commandment 6. Develop a modest but effective software engineering environment (see Chapter 12), including a supportive infrastructure.

Commandment 7. Review the status of every serious software development project at least twice a month and at times weekly.

Commandment 8. Manage the software requirements, including challenging requirements that do not make sense.

Commandment 9. Do not allow documentation to overwhelm and undermine the development of the software or the time of your key software designers and developers.

Commandment 10. Integrate your software engineering efforts and team with your systems engineering methods and team.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment