| HOME Software Testing Data Mining and Warehousing |
|
INTRODUCTION The U.S. 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’s 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’s 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’s 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’s 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. The level of funding justified and made available for development is not extended to maintaining many of the systems or their documentation once they are migrated into production. This level of documentation may be warranted on mission-critical projects such as software for man- space travel. In most instances, it’s sheer overkill and can actually impede the development effort by forcing focus on documentation deliverables while coding and testing time are diminished. SYSTEM DEVELOPMENT -- WHAT IS RIGHT The integration of systems and the expansion of internal systems to communicate with external systems dictates that some consistency in the varying approaches needs to be established. Methodologies attempting to fill this need have sprung up everywhere. Browsing through any computer science section of Amazon.com, Borders, or Barnes and Noble will reveal guide after guide on the approaches that can be used. Government contractors hoping to secure work in the private sector as budgets of many agencies are cut, are coming forward declaring that they have the answers. They bring with them approaches developed for full-scale, complex efforts that are overkill for commercial systems development. The benefits of tools such as the International Standards Organization (ISO) quality standards, series 9000, and the Software Engineering Institute' s Capability Maturity Model (SEI CMM) are expensive to realize if the tools are not adequately tailored. For some profit-based companies, funding for the use of these tools is nearly impossible. Efforts are being made throughout the computer industry to find some common ground for the approach to software development. Industry leaders are standardizing interfaces to increase application portability, broadening the need for companies to know how their systems work. The point of all of this is perhaps viewed as reference material in much the same way as an encyclopedia. Use the information to get smarter and then apply the information with common sense. Keep in mind that some very smart people can be very good at telling others how to do things, but lack the ability and know-how to get the job done. People who have been in the trenches on small and large projects know and understand that there is a happy median that can and must be achieved. Get the Basics At a minimum, a description of each application, existing and planned, needs to be written down and maintained. Whether the application is a stand-alone database that allows queries to be made using a variety of personal computer products or code that will convert a legacy system to the latest and greatest technology, it’s critical to know what is going on in development. A good description of an application will include the following information. ++ Application purpose statement ++ Input and output requirements ++ Hardware requirements ++ Software environment requirements ++ Location of current version of source code or COTS installed ++ Version/last modified descriptions With this information, all else can be reconstructed on an as-needed basis. Application Purpose Statement The application purpose statement tells the business reason for having the software, the limitations and capabilities of the product, and the point of contact for getting questions answered about the product. This is a nontechnical statement that explains what the application is and what it does. It’s written at the application component level rather than system component level. For example, a financial system will in all probability include applications for general ledger, journal processing, and accounts payable. A purpose statement is written for general ledger, journal processing, and accounts payable. They can then be bound in one document but each needs to be clearly described independently of the others because they will be maintained and upgraded individually over time. The purpose statement needs to be text. Diagrams are nice, but are only supportive to the text because diagrams generally cannot contain all of the necessary information without becoming too complex to read. Input and Output Requirements It’s essential to know what data is expected by the application and what data is generated by the application. When an application expects data, it’s going to come from one of three sources: a file input, a program process, or a user. That information needs to be stated. If the application gets the information from a file or outside database, the file name and database tables need to be identified. When the application gets the information from a process within the program logic, the logic needs to be described. When the application gets the information from a user, valid values and ranges must be documented. When an application generates data, it’s going to either send it somewhere or keep it. If the application is sending the data somewhere, the target file name and database table need to be given. If it’s going to display the data, this needs to be explained. If the application only stores the data within the application to be used for queries and reports, rules governing update rotations, archiving, and purging need to be provided. The input/output information is best presented in a table format. The data items can be listed alphabetically, making it easy to find the data path for application maintenance and troubleshooting. Hardware Requirements This should be a very basic list of what equipment is needed in order for the application to run in any organization. The list should give the minimum requirements for processor capability and memory. Software Environment Requirements This list needs to specify any software components needed on the system in order to run the application. This includes the operating system release and version, database release and version, and any other applications the application being described needs. Location of Current Version of Source and Object Code or COTS Installed This piece of documentation becomes essential in maintaining the integrity in the development environment. The best way to have this information available and accurate is to use configuration management tools. Version/Last Modified Descriptions This piece of documentation specifically states what changes have been made to the application and when they were made. Additional information about who made the changes can be of value only if the coding organization is static. The " who did it" factor becomes meaningless in dynamic organizations. It’s best to have individual version reports for each release, rather than continuing lists of changes. This approach promotes more thorough documentation. SYSTEMS DEVELOPMENT -- IS THAT IT? Having the basic documentation enables a company to build any additional documentation that may be planned. In the government world, it can be used to generate as much paper as the project demands. In a commercial product development world, it provides sufficient information for technical writers to generate operations and user manuals. In IT departments, it ensures that code is managed and can be upgraded, converted, and used in constructive and productive ways. Within each organization, there needs to be a standardized format for the basic documentation. Peer and management reviews of the basic documentation should be included in the development schedule. The reviews may be conducted as formal meetings where everyone gathers in a room and goes through the documentation page by page, or as informal reviews where the document is distributed and comments are submitted to the authoring team. Procedures for maintaining and updating the electronic and hardcopy versions of the documentation must exist. SYSTEMS DEVELOPMENT SUMMARY Using a checklist as shown can help to get things started. The point is that basic documentation imposes order on every development effort. Increased order allows for more thorough and consistent management of development processes. More thorough and consistent management results in more realistic schedules and staffing for future development work, whether it’s new application development, legacy system conversions, maintenance work, or additional types of documentation for the marketplace. Basic Documentation Checklist Item No. | Category
Items: Business reason for application; Limitations and capabilities; Point of contact; Exaplanation of application components and what they do; Database tables used by application; Files used by application; Internal interfaces; Sending application with file names sent; External interfaces; Sending system with file names sent; Processor; Disk space; Memory; Printer name; Operating system; Database Send to interface applications Receive from interface applications Name of machine Name of directory Name of files Name of application Name of each program changed Recompile complete Description of changes made for each of the programs Name of database table change Description of changes made to each table Establishing a practice of basic documentation provides ancillary benefits in that contract employees can be brought up to speed faster and their work can be checked and managed better. New technology can be adopted into environments more readily. Short- and long-term planning and bids for funding can be developed more meaningfully and documented more completely. In all, just sticking with the basics creates a win- win situation for everyone from management, to developers, to users. == |
| Top of Page | More PM Articles | Prev: Some Myths about Managing Software Development | Next: | Info-Source.us |