Chapter 2. The Software Development Process

What Effort Goes Into a Software Product?

What Parts Make Up a Software Product?

Software Development Lifecycle Models

The process used to create a software product from its initial conception to its public release is known as the software development lifecycle model.

As discussed previously, there are many different methods that can be used for developing software, and no model is necessarily the best for a particular project. There are four frequently used models, with most others just variations of these:

1.  Big-Bang

The beauty of the big-bang method is that it's simple. There is little if any planning, scheduling, or formal development process. All the effort is spent developing the software and writing the code. It's a process that is used if the product requirements aren't well understood and the final release date is completely flexible. It's also important to have very flexible customers, too, because they won't know what they're getting until the very end.

Try to stay away from testing in this model.

2.Code-and-Fix

A team using this approach usually starts with a rough idea of what they want, does some simple design, and then proceeds into a long repeating cycle of coding, testing, and fixing bugs. At some point they decide that enough is enough and release the product.

As there's very little overhead for planning and documenting, a project team can show results immediately.For this reason, the code-and-fix model works very well for small projects intended to be created quickly and then thrown out shortly after they're done, such as prototypes and demos. Even so, code-and-fix has been used on many large and well-known software products.

Like the big-bang model, testing isn't specifically called out in the code-and-fix model but does play a significant role between the coding and the fixing.As a tester on a code-and-fix project, you need to be aware that you, along with the programmers, will be in a constant state of cycling.

3. Waterfall

Notice three important things about the waterfall method:

(1).  There's a large emphasis on specifying what the product will be. Note that the development or coding phase is only a single block!

(2).  The steps are discrete; there's no overlap.

(3).  There's no way to back up. As soon as you're on a step, you need to complete the tasks for that step and then move onyou can't go back.^[1]

^[1] Variations of the waterfall model loosen the rules a bit, allowing some overlap of the steps and the ability to back up one step if necessary.

This may sound very limiting, and it is, but it works well for projects with a well-understood product definition and a disciplined development staff. The goal is to work out all the unknowns and nail down all the details before the first line of code is written. The drawback is that in today's fast moving culture, with products being developed on Internet time, by the time a software product is so carefully thought out and defined, the original reason for its being may have changed

From a testing perspective, the waterfall model offers one huge advantage over the other models presented so far. Everything is carefully and thoroughly specified.Because testing occurs only at the end, a fundamental problem could creep in early on and not be detected until days before the scheduled product release.

4. Spiral

The general idea behind the spiral model is that you don't define everything in detail at the very beginning. You start small, define your important features, try them out, get feedback from your customers, and then move on to the next level. You repeat this until you have your final product.

Each time around the spiral involves six steps:

(1).  Determine objectives, alternatives, and constraints.

(2).  Identify and resolve risks.

(3).  Evaluate alternatives.

(4).  Develop and test the current level.

(5).  Plan the next level.

(6).  Decide on the approach for the next level.

If you're a tester, you'll like this model. You'll get a chance to influence the product early by being involved in the preliminary design phases. You'll see where the project has come from and where it's going. And, at the very end of the project, you won't feel as rushed to perform all your testing at the last minute. You've been testing all along, so the last push should only be a validation that everything is okay.