Bruce Crozier
Business Software Analyst
Post-Development
Documentation
The
right way to produce good software documentation is as part of the development cycle.
In fact, documentation should be written at the same time as requirements and
code. As the requirements are refined to the point where coding can begin, the
documentation can begin as well. Unfortunately that’s not always the way things
work out. Sometimes project constraints result in software with no
documentation. Sometimes users receive software without documentation and no
recourse to get the developer to deliver it. Sometimes development is just done
poorly. When that happens it’s necessary to write documentation the hard way.
How hard it is depends on what resources I will have available. In some cases
the developers or experienced users may be available to interview. Whether or
not they are, it will probably be necessary to do a certain amount of “reverse
engineering” of the software. Reverse engineering begins with exploratory
“black box” testing of the application to get a concept of how the application
functions. As a picture of the application emerges, more structured testing is
developed to determine details and locate areas that will require highly
structured testing or even code interpretation. Reading code to determine
functional details, unless it is exceedingly well commented (which is
frequently not the case if documentation wasn’t written), is the most time
consuming and the last option. I’ve written core documentation for a full
featured ERP business package using all of these methods and it took many
months to complete. It is far cheaper to do the job up front, as the software
is being developed.
The Tax System Overview was written as part of that
documentation project. It’s “core” documentation, in that it is the foundation
on which other types of documentation and training media can be built.
Documentation is more than just a development project deliverable. It provides
quality assurance with the functional expectation for the software. It provides
the details for various forms of user reference material. It provides the
content for user training material. It may be used as the basis for marketing
text and media if the software was developed for sale. It may be used by
technical staff for reference when maintenance is required or additional
development planned. The form that it takes to satisfy each of these needs
varies. This overview is just one example of the form that documentation might
take. If you require post-development documentation I will work with you to
define the form of the documentation you need.
You may also want to consider utilizing online media
to document software, for training or marketing purposes. To learn more about
this production service go to:
Software Demonstration and Training Media