|
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.
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 is 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 & Noble will reveal book after book 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 is 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 is 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 is essential to know what data is expected by
the application and what data is generated by the application. When an application
expects data, it is 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 is 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 is 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 is 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. | 
Disclaimer
