Software Documentation

Software Documentation

Software is now an integral part of the design, development, and manufacturing of our products. It is also an integral part of many of the products themselves since embedded controllers are used in an increasing number of applications. Because of the importance of software, it must be treated as another form of engineering, not as an add-on to the electromechanical area. This means that the standard development and documentation processes that are used for hardware must also be used for software.

The adherence to certain common development standards documents that the software is being developed in a consistent and predictable manner. Initial impetus for using a certain standard may come from the desire to receive certification (e.g. ISO-9000) or to meet bid specifications for a particular contract (e.g., a DOD contract). A more important reason for standards, including documentation standards, is to provide a common basis of understanding and communication between the developers and the acquirers of software. This understanding should result in quicker agreements on specifications, fewer change orders, and the production of better quality software.

A standard process of development and documentation will also help the software development organization itself. When dealing with embedded controllers, concurrent engineering can only occur if the mechanical, electrical, computer and manufacturing engineering areas are involved from the beginning of the product development process. Systems engineering must properly partition the product functionality among mechanical, electrical, and computer components. This partitioning must be documented so that the development team knows the boundary of each specialty. This, in turn, helps during product testing when determining whether a certain problem is hardware or software related.

Thus all software, whether it is of the embedded controller; information systems; or command, control, and communications type, must be documented.

Bar Codes

Bar code data capture has been around since the late 1940s. However, it is only since the adoption of the Universal Product Code (UPC) as the standard for retail and grocery stores in 1974 that bar codes have become an everyday, transparent experience for most people. Bar codes now appear on almost every item in the industrial or retail workplace.

Any bar code is a machine-readable graphic symbol consisting of a series of alternating bars and spaces printed to exacting specifications and tolerances. Reading, then decoding, a bar code is based on the use of optics by maintaining a line-of-sight between the bar code and the scanner. A bar code scanner is used to "see" the bars and spaces and then convert the visual graphic into an electrical signal pulse. The information in this electrical signal is processed by a decoder and passed into a given software application running on the host computer. Bar codes can be scanned with either fixed/mounted or hand-held devices. Whenever there is a need to track, identify, or enter item identification information into a computer-based system, bar coding provides an easy, efficient, and cost-effective method when compared to manual data entry systems.

Because the Modern Drafting Practices and Standards Manual is oriented principally toward industrial activities that may require optimum use of bar codes, this section will look at the practices related to Code 3-of-9, which is also known as Code 39, an acronym also used in the Automotive Industry Action Groupís (AIAG) standard bar codes. If bar codes are used in a business operation, in all likelihood the drafting function will be called upon to prepare the original artwork for each code used. This section will address the types of bar codes, the features and advantages of each, and the general rules of usage. Also provided is a glossary of unique terms and lists of standards organizations and trade associations influencing bar code use.