The new millennium will not tolerate nonstandard practices for the simple reason that they will not work. Delivering increments of functionality means that each succeeding layer must fit smoothly with the others: it is like trying to build a brick wall — the bricks must be of uniform size and shape to keep it from falling over.
Not to be overly harsh, but maverick programmers will not cause the organization to step up enforcement procedures; they will cause the organization to cull them out.
When running a tight train schedule, one does not coddle late passengers … one leaves them behind.
Owning Responsibility
Users, on the other hand, must step up to the plate and own the system being developed for them. No longer can the test organization serve as a staging area for new hires or misfits, following a random, spontaneous agenda that shifts with time and turnover. It must be an elite corps of experts who bring their professionalism to bear.
Nor can users hide behind the excuse that they are not technical and must rely on development to tell them how and what to do when. Nonsense. They must take the responsibility for articulating what they need, assuring that they get it, and deciding when to release it. They pay the price to have it developed; they will pay the price if it cannot be used.
SUMMARY
While no one questions that development technology is taking quantum leaps almost every day, few question the fact that our process for applying that technology can still be found in a 1950s textbook. This anomaly is crippling our ability to move into the next millennium, and must be exposed and removed. If something quits working, it needs to be fixed … or replaced.
Chapter 6: Back to Basics: Getting Systems
Development Right
Polly Perryman Kuver
OVERVIEW
The United States is the most computer-dependent country in the world. From custom software designed and constructed for unique functions such as a global tracking system to standard software for commercial use such as word processing and spreadsheets, the development life cycle is basically the same. The approaches to the life cycle vary according to the size, scope, and nature of the system. The biggest reason for the variance in approaches comes down to funding in the four major areas in which software is developed.
Commercial
The software development practices in the commercial world vary greatly from one organization to another and really fall into two categories. The first category is the product developer. Product developers are companies like Microsoft, IBM, Hewlett Packard, and many, many smaller companies. They produce software for mass use, and their products include everything from operating systems to browsers to financial packages. The second is the in-house information technology departments of industry and service companies, such as the automotive industry, the food industry, health care, and retail.
Product Developer
Software development at product development companies is rigorously managed.
For these companies, staying competitive, being on time, and keeping costs low is business survival. The formalities of the government projects give way to streamlined practices aimed at promoting productivity. Depending on the size of the company, requirement lists and specifications may resemble more of a task order than pseudo code. Version control may be maintained on a grease board as opposed to using a sophisticated configuration management tool. The concentration of effort is to keep the user documentation current, and the project plan includes a direction and focus for the product, ensuring that new features and capabilities keep up and surpass the competition.
In larger companies, coding standards and quality control exist and are continuously improved. In smaller companies, the coding team is compressed and the teams work closely, borrowing techniques from each other and standardizing modules on the fly.
Product developers rely on government and non-computer industry organizations to buy their products and thus stay in business.
It is from the product developer that much new technology is developed and displayed to a marketplace composed of large and small businesses and personal computer users. Funding for new development and maintenance of existing products
means business survival. Requirements change based on profit and loss statements, the direction of the computer industry, and development of new technology.
Documentation is put out on the Internet and made available for downloading. It primarily consists of installation guides, operations manuals, and user manuals. The quality and usability of the documentation has created a solid market for periphery books. These books are written and published outside of the computer companies that manufacture the products and are almost essential to users that want to gain product proficiency without spending hours aimlessly “playing” on the computer.
Information Technology Department
From the health care industry to large retail organizations, the only software developed is on an as-needed basis. If commercial off-the-shelf (COTS) software can be used, it will be. If COTS software can be modified for use, surround code will be written. If new software needs to be developed, a team is formed to develop it. The team leader generally sets the rules for coding and documentation that may interpret corporate guidelines much differently than the team leader on the last project.
In many cases, IT departments have created one or more and sometimes several
“quick and dirty” applications with little or no documentation. These applications may have been written to accommodate an immediate, but unplanned business need, such as specific membership data needed by sales representatives that might not be available through the current application set. There may be long-term plans for resolving a mass of temporary applications quickly put into place to accommodate combined data from company mergers. Seldom is there sufficient documentation to flesh out the inner workings of the system and, due to employee turnover, there may not even be anyone that understands why it was done the way it was. Survival of the business is based on users being able to do what they have to do in order to meet the business needs of the company. Funding for IT efforts becomes a competition with primary business products and services.
The result of these methods being used by IT organizations at one company after another is a complex web of applications with undocumented interface and application modules. The problems that this causes were brought to full light when these companies had to deal with the Year 2000 remediation effort. Even getting an accurate inventory of program assets was challenging and putting a quality program in place to ensure Year 2000 confidence of continuing operations too often included as many exceptions as audit criteria.
Government
When United States government agencies decide to install a new computer system, it is most often accomplished through a joint effort between the agency and one or more contractors. When a new computer system will include new software, specifically developed for the unique needs of the agency, the development effort is governed by extensive engineering and documentation standards. This is true even when the system will include a mix of commercial off-the-shelf (COTS) packages and new code. The value of these standards is as much in the level of communication they force during development as anything else.
The development team has a road map and the agency project team has tools to assess and evaluate the software during every phase of the development. During the requirements phase, the agency’
s needs and wants are analyzed, and the
technological methods and techniques for meeting the needs are determined and documented. There are formal presentations, weeks of scheduled reviews, negotiations, and compromise in order to stay within budget. In the end, there is a great ceremonial meeting where acceptance by the agency is given to proceed with the development of the system.
The design phase is often two-tiered. The first part of the design can be referred to as high level. It is at this level that the grand system and all of its subsystems are clearly defined. The requirements agreed to in the previous phase are clearly mapped to the system design. Decisions are made about how the system will be tested to prove it has met the requirements. Again, there are meetings, reviews, documentation, and a great ceremonial meeting to grant approval to proceed.
Another milestone is marked; the low-level design begins and will be followed by other ceremonial meetings at the conclusion of each subsystem design.
By now there are type A specifications, type B specifications, interface specifications, database specifications, project plans, configuration management plans, quality assurance plans, and programmer guidelines at a minimum. There are hundreds, and sometimes thousands, of pages documenting what the system will do, how it will do it, how it will be managed during development, and how it will be tested to ensure it meets the specifications. According to the standards used by the agencies, such as the FAA, the DOD, and the IRS, to name a few, all of this is supposed to occur before a single line of code is written.
During the coding phase, the system is documented in user manuals, operations manuals, and maintenance manuals. Detailed test procedures with expected results and text repeated from previous documents are put into place. Much of the text in the manuals is redundant to the specifications. It is these manuals that will survive when the system goes operational. In some agencies and for some systems, these manuals are maintained throughout the life of the system. In many, they are not.