|
1. Examine Proc Doc 2. Examine Sys Doc 3. Interview Developers 4. Interview Users 5. Examine Code I 6. Examine Code II 7. Determine Truth 8. Generate Test Cases 9. Run Test Cases 10. Review Test Output SDP Template SQPP Template SCMP Template WBS Template |
We've heard a lot lately about how the high-tech industry is booming, and even how the high-tech industry is somehow responsible for the booming U.S. economy. Well, there's a cloud behind the silver lining. The American software industry is headed for disaster if it doesn't change its ways. Consider the 1950's American automotive industry. American cars were very popular; new models were introduced every year; there was virtually no foreign competition; every family had to have one (or two); the workers, managers, and owners of auto companies all did well. A few spoilsports (such as Vance Packard, author of "The Waste Makers" circa 1960) complained about big cars, big engines, lack of concern for safety, planned obsolescence -- but who listened? It seemed that the good times would last forever. And then along came Ralph Nader, pollution standards, and the energy crisis. And Americans could no longer afford to buy new cars every couple of years (actually, they never could, but nobody had paid attention). By the 1970's, the American auto industry was fighting for its life. It didn't know how to build high-mileage, safe, reliable cars, and almost went out of business as it struggled to learn. The same companies who had fought safety and fuel economy standards tooth and nail, who had complained about "government interference" in the "free market" (never mind that the oil depletion allowance and government financing of the interstate highway system had played a major role in the growth of the auto industry) went to the government with their hands out, asking for help against "unfair competition." By the 1980's, GM lost money on its car business. Ford struggled. Chrysler would have been bankrupted if not for a government bailout. Now let's examine the American software industry. It easily beats software industries in most other countries. Its products are very popular, and are updated regularly. Those products are advertised as helping businesses and individuals enter the information age, as helping schoolchildren learn, and helping people prepare for good jobs. Software companies -- owners, managers, and employees -- are all doing well. Of course, there are a few whiners. They wait for new releases -- and wait, and wait. When releases finally appear, they complain about bugs, crashes, and machines freezing up. They complain about software which practically takes a Ph.D. to install (and sometimes re-install, and re-install). They complain about having to buy high-priced updates every year or two, which introduce features few people use, which hog memory and disk space, are little more than bug patches, and take a lot of re-learning to use. The government occasionally intervenes, but when it does, it's accused of "interfering" in the "free market". Never mind that one of the first electronic computers, ENIAC, was built for the U.S. Army Ballistics Laboratory -- or that the push to make ICBM nose cones smaller and lighter created the demand for integrated circuits -- or that the first purchasers of supercomputers were government agencies that modeled weather, built bombs, or flew spy satellites -- or that the internet was INVENTED by the Department of Defense! Does any of this sound familiar? In the mid 1980's, the Software Engineering Institute, funded by the Department of Defense, developed the Capability Maturity Model, or CMM (CMM is a trademark of the Software Engineering Institute). The CMM is slowly being adopted by the Defense community, but is also gaining the attention of many commercial companies. It has five levels. Level One is the starting point -- the chaotic, undisciplined, budget-busting, schedule-breaking way typical of most (software) companies. Level Two has six major areas -- requirements management (ensure you're building what the user wants, and track changes to those requirements); project planning (have a plan and schedule); project tracking (check progress against schedule); configuration management (as you change requirements or code or documentation, keep versions consistent); quality assurance (have an independent group or person ensure you're following your standards and plan); and subcontractor management (make sure your subcontractors follow the standards you set). Most of this is project management 101, the way most companies operate (unless they develop software). Level Three ensures all aspects of software development (requirements, design, code, test, documentation) follow a standard, internally consistent process which is itself documented. Again, most non-software companies do this. Even custom homebuilders have standard procedures they follow when building a house. Levels Four and Five are more sophisticated -- they use statistical process control to measure and eliminate defects, and focus on refining processes to make them less bug-prone. Level Five Organizations can even predict approximately how many bugs they will find during testing. Space shuttle software is usually Level Five (as should any software be, if people's lives depend on it.) Forty years ago, most manufacturers were at the equivalent of Level Two, maybe Level Three. They needed to go to Levels Four and Five to be competitive with the Germans and Japanese. Today, most software manufacturers are still at Level One. Let's hope they see the light before history repeats itself. Cut To The Chase -- How Do You Do Assessment (Step 11)? |