A software development organization is set apart from others by its software development method—however, it is not just the method, but whether or not the method is used correctly and for the right reasons. Many software organizations believe that software development is all about writing coding. Many believe it is all about testing. A few believe that you must have a disciplined procedure and even fewer manage to apply such a procedure effectively.

In a recent edition of Crosstalk, The Journal of Defense Software Engineering the following statistics regarding software acquisition by a U.S. government organization were published:

Use of the UML

ES3 uses the Unified Modeling Language (UML) in the production of all development documentation. The UML was adopted as a standard by the Object Management Group in 1997. The promotion and use of standards such as the UML benefits all our customers since standards are generally proven devices for their purposes, standards are often understood by the professional community, and standards are well-defined and well-documented. The UML is a proven descriptive language for describing software systems in such a way that they can be more effectively maintained. Since the UML is a standard, locating professionals to maintain software solutions developed by ES3 is easier for ES3 and our customers.

Requirements Analysis

Most software projects are started from a vague, over simplistic statement of the problem for which a software solution is desired. Such a statement is inadequate to begin designing software. The developer must interview the customer and users and also include research of regulations and existing procedures to determine all software requirements. Software requirements generally do not attempt to re-state the problem. Software requirements are concise statements of software characteristics that must be present in an acceptable software solution for the problem in question. All discovered software requirements are recorded in a Requirements Specification.

The Requirements Specification along with the original statement of the problem provides the information necessary to design a software solution. In the specification, requirements are categorized as entity requirements, behavioral requirements, operating environment requirements, performance requirements, and design requirements as summarized below:

• Entity requirements - pertain to "static" characteristics of the system and the data on which the system operates. Entity requirements are separated from other requirements to lay the groundwork around which behavioral requirements can be specified. An example of a definition requirement might be, "A file folder has at least one (1) section and up to six (6) sections." Obviously there would also need to be a definition (requirements) for a section. While an entity requirement may be read this way, UML class diagrams and object diagrams are actually used to specify the requirements. Using such diagrams results in a compact presentation of the requirements in which relationships between entities can easily be discerned.
• Behavioral requirements - specify required behaviors of the system. Behaviors may be stipulated by the user or generated internally by the system. Behavioral requirements are usually specified in terms of the entity requirements. To continue the previous example, notice that nothing has been said about adding or removing sections from a file folder. Such information is the subject matter of behavioral requirements. A behavioral requirement might be, "When one (1) or more pages are added to a file folder, they should be placed in the History section, if the file folder does not have a History section, the system will create the History section in the file folder." To make behavioral requirements more digestible, we document them using UML state machines and use cases.
• Platform requirements - specify the environment in which the software must operate. Usually there are requirements regarding the operating system under which the software must operate. For web-based applications, the web-browsers with which the software should function must also be specified. In some cases there are requirements placed on acceptable RDBMS systems or other major sub-systems that should be used by the software. For example, "All persistent data must be stored in an Oracle (version 8 or better) database."
• Performance requirements - state the resource consumption requirements. If a system must be able to perform certain tasks in a certain amount of time, there would be at least one performance requirement. Other resources of concern are memory, disk space, network bandwidth, etc. An example performance requirement might be, "When viewing a page in a document and requesting to view the next page, under normal conditions, the image for the next page must be completely displayed within 0.5 seconds (wall-clock time) after the request." In this case the term normal conditions would have to be explained somewhere and should describe a state of the computer systems used to run the software so that the requirement can be verified effectively.
• Design requirements - provide restrictions on the procedures used to develop the software. An example design requirement might be, "All custom software will be constructed using C++."
• Requirements are written to ensure that other software developers will be capable of using the requirements specification to design and validate the software. Requirements are often not understood or even reviewed by the end-users or customer. Since the requirements analysis cannot be accomplished without working closely with prospective users and the customer, there is generally no formal review of the documented requirements.

Design

Design is a three-step process: external design, architectural design, and detail design. The goal of external design is to systematically analyze interfaces with external systems. Usually users are the most demanding external systems. During external design, little, if any, consideration is given to the architecture or details of the new software’s internals. This is the best approach since the systems with which the new software must interface already exist and have very definite interface constraints. Since the new software is under development, it is less rigid in its demands on external systems.

It is during external design that user interfaces are created and tested. Rapid Application Development tools are used to construct non-functional prototypes that can be demonstrated to and, in some cases, even test driven by users. Once the basics of user interfaces are determined through prototyping, a systematic analysis of the interface is performed and documented. The analysis is necessary since modern user interfaces are extremely complicated, allowing for many ways to perform any given task and providing visual cues (rather than text) for intuitive user interactions. A similar analysis is performed for non-user, external interfaces as well. The external design analysis is documented as part of the System Design Document.

The external design is an elaboration on the requirements analysis. Thus, many of the same techniques used to document the requirements are also used to document the external design. For example, the external design will specify at least as many use cases as does the requirements specification; however, the details of the user interface are now referred to or called out in those use cases. Such elaboration may lead to the introduction of new use cases. Like behavioral requirements, the specification of a use case in the external design is greatly simplified by the pre-definition of more static usability details. Static usability details are usually windows, window fragments, and other aspects from the previously developed prototypes.

The external design documentation is not intended for the layperson; however, it is of vital importance that potential end-users and the customer be able to review the final result of the external design analysis. Without such a review the users and the customer have no way of knowing whether or not they will be pleased with the system. Hence, the complete external design is presented to the customer and potential users in a formal Critical Design Review.

The requirements specification and external design supply all necessary information for developing a system’s architectural and detail designs. Developers work mostly without the customer during architectural and detail design. It is also during the last two stages of design when the development effort can be efficiently split up among multiple designers. While requirements analysis and external design focused on usability, architectural design focuses on maintainability. Both architectural and detail design work makes use of object-oriented technology. The work done during architectural and detail design is documented with the external design as part of the System Design Document.

The architectural design is documented using UML interaction diagrams and class diagrams. Interaction diagrams are used to determine the messages exchanged between objects. Analyzing message exchange gives insight into the classes that are needed to define the software system. Class diagrams supply the structural model that will be used to construct the system. Appropriate amounts of text supplement the interaction and class diagrams to communicate aspects of the design that cannot adequately be expressed otherwise.

Detail design is a refinement of the architectural design. Detail design is applied only to those aspects that represent significant risk to the correctness of the proposed architecture. Where necessary the design will be researched nearly to the point of construction to verify that the architecture is valid and robust. There is no expectation that the customer or end-users will review the architectural or detail designs.

Construction

Source code is produced during the construction phase. Whenever source code is written it must be tested. The developer who wrote the source code performs tests intended to verify that the source code performs according to specification (architectural and detail design). Any preparation for executing such tests is documented and saved along with the source code so that it can be used in regression testing when the system is modified. Since developers are working from the System Design Document, many people can work on the construction phase in parallel. The construction phase delivers source code and a collection of Unit Test Plans that together comprise the System Code Documentation.

System Testing

The system testing phase is intended to verify that the software will satisfy the users needs. In system testing, the software is compared to the Requirements Specification and the external design as documented in the System Design Document. A test plan must be created so that any testing done can be used later as regression tests. The test plan created for system testing is naturally called the System Test Plan. Analysts, not developers, can begin development of the test plan as soon as the external design for the product is stable. Test plan development proceeds in parallel with architectural analysis, detail design, and construction (see figure on first page). In most cases, test plan development is complete before the software is actually available. Thus, when the software is available there is no delay before system testing begins.

The System Test Plan is a collection of test suites. A test suite is made up of test cases. A test case calls out very specific, detailed actions that should be taken to perform the test. The test case is also related back to the external design or Requirements Specification so that the analyst performing the test can determine the expected results. When a problem is found, the analyst coordinates with the appropriate developer to get the problem resolved. In the event that a problem cannot be resolved it will be documented as a known problem so that the customer and the user base is aware of the issue.

User Documentation and Training

The following discussions explain the type of user documentation supplied by ES3 and the types of training and training materials we supply.

• User’s Manual - The user’s manual consists of two parts: a user’s guide and a user’s reference. A user’s guide is a manual that describes how to use the product. A user’s guide usually consists of many examples and tutorials as well as detailed explanations of the motivations behind the software design. The user’s guide is intended for use by end-users who are unfamiliar with the system to which the guide applies.
• For more advanced users, a user’s reference may also be supplied. The user’s reference attempts to address every facet of the software that the user might ever be concerned with. In doing so, the manual usually delivers information in the most concise way possible. Teaching the user to use the applicable software system is not the goal of the user’s reference. Rather, a user’s reference is more intended to assist a user’s memory after they are familiar with the system.
• Both the user’s guide and the user’s reference will be published on-line and available via the World Wide Web.
• System Training Manual - Also delivered with our products is a System Training Manual. This manual is material to accompany a training presentation. The materials will cover all basic topics that are covered in the user’s guide and usually a few more advanced topics. It would be inadequate to discuss training and only discuss the system training manual. ES3 offers a complete suite of product support services including one-on-one training (on an as-needed basis), web-published manuals, help subsystems (not offered with all software), e-mail and telephone support by local staff, as well as local staff being dispatched when needed. This type of overall support is very important for products with the diverse user base represented by Hill AFB personnel.
• System Administration Procedures - The ultimate goal is to provide software that requires no support and can be easily administered by the customer/user directly. On the other hand, we recognize the computer/software technology has not yet attained this level of stability. For this reason, as mentioned in the previous discussion, we supply a complete staff to support and administer all deployed software and the computer systems and networks that software relies upon. As users become more comfortable with the software, more and more of the administration tasks demanded by deployed software can be turned over to the customer’s responsibility.

Designing COTS Integrated Software

ES3 will develop software that is intended to make any given software system’s dependency on a Commercial-off-the-Shelf (COTS) product negligible. That is not to say that the COTS product in use is not important, only that it could be swapped out for a competing package, with minimal cost, if such an action ever became necessary or desirable.

The concept is simple. Essentially the software is designed as if the designer created the COTS software as well. Assuming that the software is to be developed with object-oriented technology, we first choose objects to define our initial architecture assuming that the COTS product does not exist. Any object specified in the initial architecture for which the purpose can be satisfied using functionality from the COTS product will eventually be constructed in terms of the COTS product. Such objects are also noted in the design as "buffer objects". This procedure creates a layer of objects between the parts of the system that are actually needed as custom software and the COTS products as shown below:

When the COTS product needs to be replaced or upgraded, the only parts of the system that must be modified are the buffer objects. Because buffer objects are implemented in terms of the COTS product, they are mostly simple, easy-to-code objects. Similarly, rewriting them for other COTS products is generally not a large task.

ES3 also offers cutting edge software development technology. This does not mean that we can offer expertise in all technologies that have buzzwords associated with them. What it means is that we stay abreast of the rapidly changing software development community and try to separate the hype from the true advancements. Subsequently, new technologies are evaluated for usefulness in the work in which we are currently involved. If a fit is found, the new technology is applied right away. One recent example of this is called, "pair programming". The basic premise is as follows: There have been recent studies to indicate that programming done by pairs is more efficient than programming done by individuals. Don’t confuse this with the idea that you can have two people work on two different modules and therefore compress the calendar time required to produce the modules. Pair programming is having two people work on the same code, together, at the same time…usually at the same terminal. For a quick synopsis of pair programming studies refer to "All I Really Need to Know About Pair Programming I Learned in Kindergarten", printed in Communications of the ACM, May 2000, Vol. 43, No. 5. After reading about pair programming, one can theorized that one of the reasons that pair programming seems to be so effective is because the programmers are attempting to design as they code. With this in mind, "pair designing" might greatly assist the software design phase. In other words, two developers can be teamed together to work on the less mechanical aspects of software design. Early results are quite impressive. They seem to be right in line with the result sighted in studies thus far. Pair programming is just one example of how ES3 keeps its eye on the software development community.