- Let's Review that Process...
- Meet Neil & Gordon...
- Task List
- The Development Process
- ...One More Time
- System Design
- Agile Waterfalls
- Use Cases
- What If...?
- UML State Diagrams
- An Example
- Specification Components
- User Requirements
- ...One More Time
- Creating executables
- Compiled or Interpreted?
- Just-in-Time...
This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile Waterfalls
In the early days of software engineering, we tried to develop complete, detailed specifications before we started programming. This methodology was called the WATERFALL MODEL because each clearly defined stage of development (requirements, design, development, testing, implementation, maintenance) “flowed” into the next.
Finishing each stage before moving on to the next seems like a good idea, right? You’d think it would be efficient to know exactly what you need to do before you start to do it. The problem is, we never know exactly what a system needs to do, or how it needs to do it, until we’re actually using it.
The waterfall model frustrates users because it’s slow and inflexible, and it frustrates developers because the users “never know what they want”.
)
Frederick P. Brookes, in his 1975 classic The Mythical Man Month, said, “Plan to throw one away. You will anyway.” Pretty depressing idea, isn’t it?
The waterfall model does have its place, because in principle it’s still an efficient development model. Sometimes the system you’re working on is simple enough that you can know exactly what it needs to do in advance. Changes to existing systems often fall into this category, even though the system itself may be complex. (But be careful here... complex systems can be difficult to predict.) And, unfortunately, sometimes you’re working for a large organization that put its development methodology in place back in the Cretaceous period (about 1980), and it’ll dictate your process.
But we’ve learned a lot since then, and smart software engineers have developed new, more effective techniques. One of the best of these techniques is part of a methodology called AGILE DEVELOPMENT which, among other things, recommends that you only specify the little piece of the software you’re going to work on right this minute. There’s a lot more to Agile Development, some of which we’ll talk about in later chapters. But if you’re keen (and I hope you are!), you can read the original Agile Manifesto, published in 2001, at www.agilemanifesto.org, or check out Robert C. Martin’s excellent introduction.
)
Whether you’re developing the specification all at once or a little at a time, though, you need a place to start. A USE CASE, which is simply a description of how an actor (either a user or another software component) interacts with the system, is one of the best.