Software Development Lifecycle Models
| A running joke in the computer industry is that three things should never be seen in the process of being created: laws, sausage, and software. Their creation process is so messy and disgusting that it's best to just wait and see the final result. That may or may not be totally true, but with most old sayings, there is a grain of truth behind the words. Some software is developed with the rigor and discipline of a fine craftsman, some software with tightly controlled chaos, and other software is stuck together with duct tape and chewing gum. Usually, in the end, it's apparent to the customer what process was used. 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:
Each model has its advantages and disadvantages. As a tester, you will likely encounter them all and will need to tailor your test approach to fit the model being used for your current project. Refer to these model descriptions as you read the rest of this book and think about how you would apply the various testing techniques you learn under each of them. Big-Bang ModelOne theory of the creation of the universe is the big-bang theory. It states that billions of years ago, the universe was created in a single huge explosion of nearly infinite energy. Everything that exists is the result of energy and matter lining up to produce this book, DVDs, and Bill Gates. If the atoms didn't line up just right, these things might all be just quivering masses of goop. The big-bang model for software development shown in Figure 2.4 follows much the same principle. A huge amount of matter (people and money) is put together, a lot of energy is expendedoften violentlyand out comes the perfect software product…or it doesn't. Figure 2.4. The big-bang model is by far the simplest method of software development.
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. Notice that testing isn't shown in Figure 2.4. In most cases, there is little to no formal testing done under the big-bang model. If testing does occur, it's squeezed in just before the product is released. It's a mystery why testing is sometimes inserted into this model, but it's probably to make everyone feel good that some testing was performed. If you are called in to test a product under the big-bang model, you have both an easy and a difficult task. Because the software is already complete, you have the perfect specificationthe product itself. And, because it's impossible to go back and fix things that are broken, your job is really just to report what you find so the customers can be told about the problems. The downside is that, in the eyes of project management, the product is ready to go, so your work is holding up delivery to the customer. The longer you take to do your job and the more bugs you find, the more contentious the situation will become. Try to stay away from testing in this model. Code-and-Fix ModelThe code-and-fix model shown in Figure 2.5 is usually the one that project teams fall into by default if they don't consciously attempt to use something else. It's a step up, procedurally, from the big-bang model, in that it at least requires some idea of what the product requirements are. Figure 2.5. The code-and-fix model repeats until someone gives up.
A wise man once said, "There's never time to do it right, but there's always time to do it over." That pretty much sums up this model. 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. If your word processor or spreadsheet software has lots of little bugs or it just doesn't seem quite finished, it was likely created with the code-and-fix model. 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. As often as every day you'll be given new or updated releases of the software and will set off to test it. You'll run your tests, report the bugs, and then get a new software release. You may not have finished testing the previous release when the new one arrives, and the new one may have new or changed features. Eventually, you'll get a chance to test most of the features, find fewer and fewer bugs, and then someone (or the schedule) will decide that it's time to release the product. You will most likely encounter the code-and-fix model during your work as a software tester. It's a good introduction to software development and will help you appreciate the more formal methods. Waterfall ModelThe waterfall method is usually the first one taught in programming school. It's been around forever. It's simple, elegant, and makes sense. And, it can work well on the right project. Figure 2.6 shows the steps involved in this model. Figure 2.6. The software development process flows from one step to the next in the waterfall model.
A project using the waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they're ready to move to the next step. If the project isn't ready to progress, it stays at that level until it's ready. Notice three important things about the waterfall method:
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. By the time the software is delivered to the test group, every detail has been decided on, written down, and turned into software. From that, the test group can create an accurate plan and schedule. They know exactly what they're testing, and there's no question about whether something is a feature or a bug. But, with this advantage, comes a large disadvantage. 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. Remember from Chapter 1, "Software Testing Background," how the cost of bugs increases over time? What's needed is a model that folds the testing tasks in earlier to find problems before they become too costly. Spiral ModelIt's not quite utopia, but the spiral model (see Figure 2.7) goes a long way in addressing many of the problems inherent with the other models while adding a few of its own nice touches. Figure 2.7. The spiral model starts small and gradually expands as the project becomes better defined and gains stability.
The spiral model was introduced by Barry Boehm in 1986 in his Association for Computing Machinery (ACM) paper, "A Spiral Model of Software Development and Enhancement." It's used fairly often and has proven to be an effective approach to developing software. 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:
Built into the spiral model is a bit of waterfall (the steps of analysis, design, develop, test), a bit of code-and-fix (each time around the spiral), and a bit of big-bang (look at it from the outside). Couple this with the lower costs of finding problems early, and you have a pretty good development model. 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.
|
EAN: 2147483647
Pages: 233
- BGP PE-CE Routing Protocol Overview, Configuration, and Verification
- Case Study-Multi-Homed Inter-AS Provider Network
- CSC Architecture Benefits
- TE Basics
- Case Study 2: Implementing Multi-VRF CE, VRF Selection Using Source IP Address, VRF Selection Using Policy-Based Routing, NAT and HSRP Support in MPLS VPN, and Multicast VPN Support over Multi-VRF CE