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 keep changes from proliferating wildly and becoming hopelessly convoluted, many projects (particularly large ones) create a change control board that reviews and approves (or rejects) change requests. The board should include people who represent the customers (“We really need to log in telepathically from home”) and the development team (“The best we can do is let you log in on your cell phone”).
Even on small projects, it’s usually worthwhile to assign someone as the final arbiter. Often that person is either a high-ranking customer (such as the executive champion) or a high-ranking member of the development team (such as the project lead).
During development, it’s important to check the documentation to see what you’re supposed to be doing. You need to easily find the most recent version of the requirements to see what the application should do. Similarly, you need to find the most recent high-level and low-level designs to see if you’re following the plan correctly.
Sometimes, you’ll also need to find older versions of the documentation, to find out what changes were made, why they were made, and who made them.
FONT FIASCO
To understand the importance of historical documentation, suppose your application produces quarterly reports showing projected root beer demand. At some point the requirements were changed to require that the report be printed in landscape mode with a 16-point Arial font.
Now suppose you’re working on the report to add new columns that group customers by age, weight, ethnic background, car model, and hat size. That’s easy enough, but now the report won’t fit on the page. If you could bump the font size down to 14-point, everything would fit just fine, but the 16-point Arial requirement is killing you.
At this point, you should go back to the requirements documents and find out why the font requirement was added. If the requirement was added to make it easier to include reports in PowerPoint slides, you may be able to reduce the font size and your boss can live with slightly more crowded slides during his presentations to the VP of Strategic Soft Drink Engineering.
Another option might be to continue producing the original report for presentations and create a new expanded report that includes the new columns for research purposes.
It’s even possible that the original issue was that some developers were printing reports with the Comic Sans font. Management didn’t think that looked professional enough, so it made a font requirement. They never actually cared about the font size, just the typeface. In that case, you could probably ask to change the requirement again to let you use a smaller font, as long as you stick with Arial.
Unless you have a good document history, you may never know why and when the requirement was changed, so you won’t know whether it’s
