backward, the basic tasks are also sometimes handled in very different ways. Some development models rely on a specification that’s extremely detailed and rigid. Others use specifications that change so fluidly it’s hard to know whether they use any specification at all. Iterative approaches even repeat the same basic tasks many times to build ever-improving versions of the final application. The chapters in the second part of this book discuss some of the most popular of those sorts of development approaches.
SUMMARY
All software engineering projects must handle the same basic tasks. Different development models may handle them in different ways, but they’re all hidden in there somewhere.
In fact, the strengths and weaknesses of various development models depend in a large part on how they handle these tasks. For example, agile methods and test-driven development use frequent builds to force developers to perform a lot of tests early on so that they can catch bugs as quickly as possible. (For a preview of why that’s important, see the “Counting Bugs” example earlier in this chapter and Exercise 4.)
The chapters in Part II, “Development Models,” describe some of the most common development models. Meanwhile the following chapters describe the basic software engineering tasks in greater detail. Before you delve into the complexities of requirements gathering, however, there are a few things you should consider.
The next chapter explains some basic tools that you should have in place before you consider a new project. The chapter after that discusses project management tools and techniques that can help you keep your project on track as you work through the basic software engineering tasks.
EXERCISES
1. What are the basic tasks that all software engineering projects must handle?
2. Give a one sentence description of each of the tasks you listed for Exercise 1.
3. I have a few customers who do their own programming, but who occasionally get stuck and need a few pointers or a quick example program. A typical project runs through the following stages:
a. The customer sends me an e-mail describing the problem.
b. I reply telling what I think the customer wants (and sometimes asking for clarification).
c. The customer confirms my guesses or gives me more detail.
d. I crank out a quick example program.
e. I e-mail the example to the customer.
f. The customer examines the example and asks more questions if necessary.
g. I answer the new questions.
Earlier in this chapter, I said that every project runs through the same basic tasks. Explain where those tasks are performed in this kind of interaction. (For example, which of those steps includes testing?)
4. List three ways fixing one bug can cause others.
5. List five tasks that might be part of deployment.
▶ WHAT YOU LEARNED IN THIS CHAPTER
● All projects perform the same basic tasks:
1. Requirements Gathering
2. High-level Design
3. Low-level Design
4. Development
5. Testing
6. Deployment
7. Maintenance
8. Wrap-up
● Different development models handle the basic tasks in different ways, such as making some less formal or repeating tasks many times.
● The basic tasks often occur at the same time, with some developers working on one task while other developers work on other tasks.
● Work sometimes flows backward with later tasks requiring changes to earlier tasks.
● Fixing a bug can lead to other bugs.
● The longer a mistake remains undetected, the harder it is to fix.
● Surprises are inevitable, so you should allow some extra time to handle them.
CHAPTER 2
Before the Beginning
It’s not whether you win or lose, it’s how you place the blame.
WHAT YOU WILL LEARN IN THIS CHAPTER:
● The features that a document management system provides
● Why documentation is important
● How you can easily archive e-mails for later use
● Typical types of documentation
Before you start working on a software project, even before you dig into the details of what the project is about, there are preparations you should make. In fact, some of these can be useful even if you’re not considering a software project.
These tools improve your chances for success in any complicated endeavor. They raise the odds that you’ll produce something that will satisfy the application’s customers. They’ll also help you survive the process so that you’ll still be working on the project when the accolades start rolling in.
Typically, you’ll use these tools and techniques throughout all of a project’s stages. You’ll use them while you’re gathering requirements from the customer, during the design and programming phases, and as you roll out the final result to the users. You’ll even use them after you’ve finished releasing an application and you’re considering enhancements for the next version.
The following sections describe some beginning-to-end tools that you can use to help keep team members focused and the project on track.
DOCUMENT MANAGEMENT
A software engineering project uses a lot of documents. It uses requirements documents, use cases, design documents, test plans, user training material, lunch menus for team-building exercises, resumes if the project doesn’t go well, and much more. (I’ll describe these kinds of documentation in later chapters.) Even a relatively modest project could have hundreds or even thousands of pages of documentation.
To make matters more confusing, many of those are “living” documents that evolve over time. In some projects, the requirements are allowed to change as the project progresses. As developers get a better sense for which tasks will be hard and which will be easy, the customers may want to revise the requirements to include new, simple features and eliminate old, complicated features.
As the project progresses, the customers will also get a better understanding of what the system will eventually do and they may want to make changes. They may see some partially implemented feature and decide that it isn’t that useful. They may even come up with new features that they just plain forgot about at the beginning of the project. (“I know we didn’t explicitly say you need a way to log into the system, but I’m quite sure that’s going to be necessary at some point.”)
CHANGE CONTROL
If you let everyone make changes to the requirements, how can you meet them? Just when you satisfy one requirement, someone can change it, so you’re not done after all. (Imagine running after the bus in the rain while the driver cackles evilly and checks the side mirror to make sure he’s going just a little faster than you’re running.) Eventually, the requirements need to settle down so that you can achieve them.
Allowing everyone to change the requirements can also result in muddled, conflicting, and confusing goals and designs. This is more or less how laws and government spending bills are written, so it shouldn’t be a surprise that the results aren’t always perfect. (“Yes, you can have a $3,000 study to decide whether people should carry umbrellas in the rain if I can have my $103,000 to study the effects of tequila and gin on sunfish.” Someone really should spend a few dollars to study whether that kind of budget process is efficient.)
To