Learning Oracle PL/SQL

9.1. Riding the Software Lifecycle

When you are faced with a new project, how do you begin?

When I was a young programmer, I remember reading a lot of books and papers that promoted different ways of designing and constructing programs. Often, authors presented the idea of a software lifecycle, which abstracts the overall software process into named phases. In hindsight, some of the ideas were pretty wacky, and about the only thing most authors agreed upon was that there should be a strong emphasis on defining the users' requirements: the more you know about what the users need, the easier the rest of the programming job will be. But that was the end of the agreement. Methods of eliciting and documenting these requirements, and of translating them into working systems, spanned an enormous philosophical chasm.

Today, after some (ahem) number of years as a software professional, I've had the chance to see a lot of the different things that people try to do, and I'm here to tell you that in the real world, the application of lifecycle thinking ranges from "disciplined" to "Huh?"

There do seem to be at least 10 job functions I've seen applied to custom development, although they don't necessarily occur in discrete phases. These functions are:

Definition of project scope

Textbook: Decision-makers draw functional boundaries around the required system.

Typical: Management decides how much they are willing to spend.

Project planning

Textbook: Project managers solicit staff input ...