19.2.2 Software Language

Machine language, sometimes referred to as object or machine instructions, is the actual binary instructions that a computer will execute. Assembler code usually corresponds to machine instructions on an equal basis, i.e. one assembler line of code usually generates one machine instruction. Although assembler code is easier to write than machine code, most programmers find it relatively cumbersome. Next is a high-order language (HOL) instruction, or line of code. High level languages translate human instructions into machine language. These languages are a number of levels (at a high level) away from the actual bit manipulation. Popular HOLs currently in use include BASIC, JOVIAL, C++, JAVA and Ada. Compared to assembler language, HOLs have the advantages of being much easier to read and write, but do not always make optimal use of a computer's capacity. An instruction written in assembler or HOL is often referred to as a source line of code (SLOC), to differentiate it from a machine instruction. This term will become important in the subsequent discussions on software sizing and software cost models.

Although most large programs today are written in assembler language or HOL, there is a growing trend toward programs that even more closely resemble the spoken language. Programs for spreadsheets, word processors, and similar applications are often written in a very high-order language (VHOL). VHOLs allow a person with little or no programming background to interact with a computer. There are programs that enable a computer to accept vocal instructions directly. Scientists in the field of cybernetics postulate that in the future computers will have the capability to accept thought commands as inputs.

19.2.3 Software Development Cycle

Regardless of how software is programmed, it must proceed through certain steps, or phases, of development. This section defines the basic software development cycle. Major phases and software development activities are defined, as well as key milestones for the measurement of progress.

An example of a popular software development process is the eight-phase process used in developing software for most Department of Defense (DoD) weapon systems, as described in DoD-Standard 2167A, "Defense System Software Development." This process, when done sequentially, is based on the waterfall model of software development, as described by Barry Boehm. Per NASA’s Handbook, the process depicted by the model involves development through specific, sequential stages. There are specific objectives to be accomplished in each phase; each activity must be deemed successful for work to proceed to the subsequent phase. The process is usually considered non-iterative. Each phase requires the delivery of particular documentation products (Contract Data Requirements List (CDRL) Items). Many of the phases require successful completion of a government review process. Critics of the "Waterfall" Model, in fact, find that the model is geared to recognize documents as a measure of progress rather than actual results.

The eight major activities described in DoD-STD 2167A are shown Figure 19-1 as a schematic overview of the Waterfall Model, representing concurrent hardware and software development. The maintenance phase was added to the end of the software development phases to represent the operation and support needed for the complete software life cycle.

Figure 19-1. Software Waterfall Model Development Phases

It is evident from Figure 19-1 that software development comprises much more than writing code. In fact, according to William G. Cheadle in his article entitled "DoD-STD-2167 Impacts on Software Development," writing code accounts for only about twenty percent of the entire software development process and phases 2 through 4 can account for 60% of the entire SW development effort.

An understanding of the above process requires a comprehension of the software hierarchy and terminology used. A system is partitioned into various subsystems, which are further partitioned into computer software configuration items (CSCIs) and hardware configuration items (HWCIs). A CSCI is a program, or group of programs which satisfies a common end-use function and is managed separately. Since CSCIs may contain over 100,000 lines of code, they are further partitioned into computer software components (CSCs) and computer software units (CSUs). CSUs are the lowest-level software entities and usually contain between 100 and 200 lines of code.

Systems Concept/System Requirements Analysis

The initial System Requirements Analysis activities involve exploring and defining concepts to satisfy a valid requirement using hardware, software, and personnel resources. The system operational requirements, as defined by the Government, are translated into preliminary specifications. During system design activities, the contractor may investigate several alternative approaches that would satisfy Government requirements, but generally selects and documents one specific system architecture to be used. The system may be designed to use one central computer, or a number of computers distributed throughout the system could share the processing tasks. The contractor will identify the computer resources he will require and the database(s) that will be used or that will need to be developed.

The Software Development Plan (SDP) is one of the deliverable products that result from the analysis and design activities. This document presents an integrated plan for managing the development effort. It usually summarizes the overall software structure and basic functions, as well as the planned approach to project management. It can be a useful document for obtaining an overview of the effort to be estimated.

The Systems Requirements Review (SRR) is held at the conclusion of requirements definition activities. The objective of this review is to determine how adequately the contractor has identified and defined overall system requirements.

Software Requirements Analysis

The primary objective of this phase is to define requirements for each CSCI as completely as possible in order to eliminate uncertainty at the beginning of the design phase. The customer's requirements are assigned to CSCIs, and the pattern of interaction (interface requirements) among the various components is specified. The requirements that each CSCI must meet during testing are also specified. System analysts assess the information flow with the software; that is, how data move and are transformed during its input, process, and output. They also look at the structure of data, or how various elements of data are logically related. This involves understanding how data will be organized, accessed, modified, and processed.

The Software Requirements Specification (SRS) is the primary deliverable product developed as a result of software requirements analysis. An SRS will be developed for each CSCI. This specification will describe the goals and objectives of the software, and the problems the software is designed to solve. It will provide details of each function that the software will perform, and what procedures it will use to perform them. It should provide specific criteria to be used to validate the software, that is, specify the criteria to be used to determine whether or not the software is "successful".

The Software Specification Review (SSR) marks the end of this phase. This review evaluates the SRS for each CSCI, and the Interface Requirements Specification (IRS). The objective of this review is to determine if the contractor is ready to proceed with preliminary design.

Preliminary and Detailed Design

During software design, the objective is to develop functionality based on the requirements determined above, so that the writing of code will easily follow. Software design is divided into two phases, Preliminary and Detailed design; each CSCI is defined in successively greater detail. The model will be quite general at first, but as design proceeds, the procedural detail will become more and more similar to source code.

In the Preliminary Design Phase, the contractor develops an overall design approach including mathematical models and determines how control of various functions and data will flow through the software. The overall structure or architecture for each CSCI is determined. Each CSCI will be divided into Computer Software Components (CSCs). The general processing that will be performed by each CSC is determined, and test plans and requirements for each CSC are developed. Preliminary Design Review (PDR) is held at the end of this phase, and is intended to determine if the contractor is ready to proceed with Detailed Design. Separate PDR reviews are sometimes held for each CSC.

In the Detailed Design Phase, each CSCI is further subdivided by splitting the CSCs into Computer Software Units (CSUs). Ideally, each CSU should perform only a single function, and should consist of approximately 100 SLOC. Data requirements, algorithms, interfaces, and required testing are all defined down to this unit level. The end result of detailed design is a "code to" document, a complete modular lower level design for each CSCI. This detailed design is a "blueprint" from which to write code. Critical Design Review (CDR) is held at the end of the detailed design phase. The design phase ends with successful completion of the System Design Review (SDR). This review is held to evaluate how well the contractor has allocated technical requirements to the hardware and software.

Coding and Computer Software Unit (CSU) Testing

During Coding and Unit Test, the actual programming of deliverable code occurs. Pseudocode is converted into formal Order Language Statements or Source Code. This Source Code is then compiled (translated into machine readable form) and each unit is tested as planned in previous phases. This code and unit test activity is the effort most people associate with software development. In terms of proportion of schedule and cost, however, programming probably represents only 17 to 25 percent of the overall effort. Large, complex software projects do tend to experience manpower peaks in this phase, as the activity lends itself to subdivision and parallel effort. On large projects, the components can be subdivided, with many people working on small subtasks simultaneously.

Computer Software Component (CSC) Integration and Testing

The previous phases define requirements and allocate those requirements to successively lower level components of the overall software system. Once the coding or programming of the lower level units is complete, this process reverses itself, and effort is focused on integrating and testing successively the higher levels of the system. The software development contractor now has to check the algorithms and logic for each CSC, and integrate the functions that were specified for each CSC in its respective requirements document.

Integration Testing

CSCIs are tested during the next phase, and the tested software is then integrated with the hardware it controls. This integration process and testing of the integrated system is conducted by the contractor. This phase concludes with the Test Readiness Review (TRR).

System Testing

The integrated system will have to undergo System Testing. The objective of testing in this phase is to determine if the system meets the customer’s requirements and user needs. If the system as a whole meets all the customer's requirements as defined in the system specifications, then it is ready to be delivered. The final reviews in the process are the Functional and Physical Configuration Audits (FCA/PCA). The final test in the development phase is the Operational Test and Evaluation, which is conducted by the organizations that are to use the system in order to determine how well the fielded system will actually work.

Software Development Cycle Summary

During the first phase, Systems Concept/System Requirements Analysis, system level requirements are partitioned to CSCI and HWCI-level requirements. Each CSCI now follows its own development cycle following the phases shown in Figure 19-1 as CSCI-level activities. During the Software Requirements Analysis phase, the specific requirements of a CSCI are defined in detail. During the next two phases, Preliminary Design and Detailed Design, the requirements are refined to the CSC and CSU levels respectively. Ideally, the software is now completely designed and is ready to code. The last three phases involve writing source code (e.g., FORTRAN language statements) for each CSU and testing the CSU; testing aggregates of CSUs which form CSCs, and testing the overall CSCI to insure the CSCI requirements are met. After CSCIs are tested, the last phase, System Test, determines whether the aggregate of hardware and software meets system requirements. Once the system becomes operational at a site, development is essentially complete and the program enters the maintenance part of the life cycle.

Per the Computer Science Telecommunications Program course material website at the University of Missouri, Kansas City, the term waterfall is an analogy to the fact that the development process is allowed to move in a forward direction only. When a software developer takes on a contract to build a software system using the waterfall model it usually agrees to provisions to deliver documents at the completion of each phase by a particular date. Therefore, the model has been termed a legalistic document driven approach. Obviously there are problems with the strict adherence to the waterfall model.

The development phases shown in Figure 19-1 do not always occur sequentially. Many modern development practices, such as prototyping or incremental development, will result in a different order of activities. (Also, these phases may be modified or combined in some instances. For example, in Military Standard 498, "Software Development and Documentation" (which replaced DoD-STD-2167A), the preliminary and detailed design phases have been combined into a single "software design" phase, and the requirement to have CSCs has been eliminated. 

19.2.4 Additional Modes of Software Development

According to Boehm, a new generation of software processes and products are changing the way organizations develop software. The eight-phase process described above is tailored to the standard waterfall, full scale development method that is most commonly used when discussing project planning and management concepts. However, other types of development that include COTS integration, prototyping, evolutionary acquisition, incremental development, spiral development, and technology insertion, plus reuse-driven software procurement approaches; and software process maturity initiatives lead to significant benefits in terms of improved software quality and reduced software cost, risk, and cycle time. The detailed nuances of how development proceeds under each of these modes of development is beyond the scope of this document. However, some general considerations that should be made for the estimation process under each of these modes is discussed below since the different software cost estimating models/tools described in Appendix 19D refer to these processes.

COTS Integration

According to Richard Stutzke’s paper "Cost Factors for COTS Integration" presented at the Tenth International COCOMO User’s Conference, Software developers are using increasing amounts of commercial-off-the-shelf (COTS) software products to construct new systems. These COTS products may be either components or standalone packages. They are considered to be ready to use and have been documented at some level of detail. They are also supposedly well tested, making them more reliable.

Software developers choose to use COTS products to decrease development costs, schedules and technical risks. Unfortunately, these goals are not achieved in many cases due to an incomplete understanding of all the factors involved. These factors include features provided and various associated costs, including license fees. For a more in-depth discussion of the many considerations peculiar to COTS software integration, cost estimating, and pricing, refer to Appendix 19E of this chapter.

The model pictured in Figure 19-2 is called the five-panel model and is extended from SEI’s Special Report [SEI-97-SR-019] titled "Workshop on COTS-Based Systems." The five panels represent various activities that address different aspects of turning a set of COTS components into a COTS-based system.

Figure 19-2. COTS Five Panel Model

The COTS Market panel deals with the market survey and analysis activities that determine what are the viable candidates for a particular component, from both a business and a technical perspective.

The Qualify panel activities investigate the hidden interfaces and other characteristics and features of the candidate products. The most difficult problem in this phase is to determine the characteristics of the available COTS products so that a product that best meets the requirements may be selected. The result of this discovery process is to reveal the necessary information to make a selection and identify possible sources of conflict and overlap, so that the component can be effectively assembled and evolved. Per the March 1998 STSC Crosstalk article on COTS, "Experience shows that the selection process for one major product can require three to six months of calendar time, multiple engineers and programmers, access to sophisticated suites of hardware and software environments, and will likely entail the purchase of vendor-provided training classes." Per Stutzke, "this phase concludes with the purchase of the selected products which can be accomplished using a wide variety of licensing schemes. The licensing scheme can affect the overall cost of the system. The biggest difficulty in dealing with licenses is there is no standard terminology in use by the various vendors, for example "annual" and "perpetual" are used by different vendors to mean the same thing."

The Adapt panel activities amend the selected components to address potential sources of conflict. The figure implies a kind of component "wrapping," but other approaches are possible (e.g., mediators and translators). According to the Crosstalk article, since COTS software does not require coding but does require integration with other components, it starts the life cycle as a partially developed component. The design, construction, and integration and test development stages must be recast to accommodate early COTS software integration and testing as well as to develop "glue" code: interface software, configuration files, scripts, utilities, and data files required to make the COTS software deliver its intended functionality. The proper development and testing of the glue code to make a COTS package work may not be a trivial undertaking. For more complex COTS software, the development of glue code might need to be treated in the same manner as the development of a traditional custom-coded software module.

The Assemble panel shows the integration of the adapted components into an architectural infrastructure. This infrastructure will support component assembly and coordination, and differentiates architectural assembly from ad hoc "glue". Referring again to the Crosstalk article, waiting until late in the development process to test and integrate COTS products, particularly those that are complex, will not give adequate time to master all their intricacies and complexities. COTS product testing and integration activities must be interwoven into more of the development process stages.

The Update panel acknowledges that new versions of components will replace older versions; in some cases, components may be replaced by different components with similar behavior and interfaces. These replacement activities may require that wrappers be rewritten, and they suggest the advantage of well-defined component interfaces that reduce the extensive testing otherwise needed to ensure that the operation of unchanged components is not adversely affected.

Rapid Prototyping Development

The Computer Science Telecommunications Program course material website at the University of Missouri, Kansas City describes prototyping as developing an initial "model", providing the prototype to the intended users, gathering feedback from the users, and including any revisions or refinements. If this process continues until the required system is developed, then the process would be considered evolutionary development. However, when the objective of the prototype is to determine or validate system requirements, then the process illustrated in Figure 19-3 (extended from James E. Tomayko’s course material website at Carnegie Mellon University) applies and is sometimes referred to as throw-away prototyping.

Figure 19-3. Rapid Prototyping Development Model

NRaD’s Manual refers to prototyping as a method to evaluate the feasibility of technical ideas and theories that has become increasingly popular and is a widely used development mode at various defense R&D centers. Developing a prototype is usually a distinct portion of the life cycle. Just as the prototype will provide insight into the design and implementation issues, the estimate and cost of producing the prototype will provide insight into the cost of the overall project. The University of Cincinnati, College of Business Administration course material website states that typically the prototype represents about 15% of the final project.

Developing a cost estimate for a Prototyping project should be accomplished in the same manner as for a full-scale development project. The primary cost savings resulting from prototyping is the lack of formal reviews and documentation required. Also, there is a minimum of systems engineering and formal testing involved.

Evolutionary Acquisition (EA)

Figure 19-4 (extended from the University of Illinois Department of Computer Science course material website) shows the basic elements of EA development.

Figure 19-4. Evolutionary Acquisition Model

The Computer Science Telecommunications Program course material website at the University of Missouri, Kansas City states that one of the shortcomings of the Waterfall Model is its incapacity to analyze the crucial activity of risk analysis. The Evolutionary Acquisition Model is pretty similar in content to the Waterfall Model except it encourages prototyping. Per the NRaD Manual, EA is becoming the rule more than the exception in large-scale development efforts, especially when the detailed specification is difficult or impossible to create. The thesis of "build a little, test a little" is seen as a way to develop systems that better satisfy user requirements and more easily take advantage of technical advances. The underlying factor in EA is to field a well-defined core capability quickly in response to a validated requirement, while using a phased upgrade program to eventually enhance the system to provide the full system capability. This process is also referred to as evolutionary prototyping. Documentation and the software structure may suffer with this approach, especially if the prototypes are created rapidly. EA can be considered a risk reduction approach and effective prototyping can increase the software quality.

The process for estimating an EA project can be accomplished in the same manner as for a standard waterfall project. An EA project requires the same formality as any other method of development. Estimates should be developed for each phase or development cycle of an EA project just as they would be for a large Full Scale Development project. During each phase of an EA project, two separate estimates will be required, an estimate for the current phase and an estimate for the total project as it is understood and defined at that time.

Incremental Development

The NRaD Manual refers to the incremental development approach as a top down implementation of distinct functional elements of the product. The development of each increment is accomplished as a separate waterfall type of development as illustrated in Figure 19-5 (extended from James Tomayko’s course material website at Carnegie Mellon University). This strategy allows visibility into potential design, interface problems etc., early in the development cycle. It also provides the opportunity to incorporate user experience into the final product. The incremental development methodology differs from the evolutionary approach in that under the incremental strategy the end product is well-defined.

Figure 19-5. Incremental Development Model

Estimates should be developed for the total project as well as for each of the increments. Each increment should be identified and sized. The estimates for each increment should be accomplished as for an individual waterfall development project. The estimate for the total project will have to show the overlapping of the increments. How the individual increments overlap may differ from project to project.

The establishment of size, cost, and schedule estimates for each increment will provide an overall estimate of the total project. As the first increments are completed, then the assumptions and estimates for the subsequent increments as well as for the total product can be revised to reflect a more accurate assessment.

Spiral Development

Barry Boehm created the spiral model in 1988 for software engineering because of the perceived inadequacies of the waterfall life cycle. The Computer Science Telecommunications Program course material website at the University of Missouri - Kansas City states that the spiral model encompasses features of the phased life cycle as well as the prototype life cycle. However, unlike those life cycles, the spiral model uses risk analysis as one of its elements. It also uses the waterfall model for each step so as to avoid any risks. It is a complex model that requires complicated diagrams (such as Figure 19-6) to be fully understood.

Figure 19-6. Spiral Development

The radial dimension in the figure shows the cumulative cost of the accomplishment of the steps at that time. The angular dimension shows the progress made in the completion of each cycle of the spiral. Every cycle of the model represents the same sequence of steps in the completion of the software. Each cycle of the spiral begins with the identification of the objectives of that portion of the product, an alternative way of implementing this portion, and the constraints on the application of the alternatives.

The first step is used to evaluate the risks involved with the objectives and constraints. The next step is determined by the remaining risks. If a detailed prototype is useful enough for future product evolution with low risks, then the next steps would be the series of evolutionary prototypes going toward the right in the figure. However, if previous prototyping has already resolved all of the performance risks, then the next step uses the waterfall approach.

The primary advantage of the spiral model is that it has a wide range of options to accommodate the good features of other life cycle models. It becomes equivalent to another life cycle model in appropriate situations. Also the risk-avoidance approach keeps it from having additional difficulties. The spiral model focuses its early attention on the option of reusing existing software. It prepares for life cycle evolution, growth, and changes of the software product. The spiral model has some difficulties that need to be resolved before it can be a universally applied life cycle. These difficulties include matching to contract software, relying on risk assessment expertise, and the need for more detailed steps. The risk-driven model is dependent on the developers' ability to identify project risk and therefore depends on the risk assessment skills of the developer. It is still fairly new compared to other models, so it has not been used significantly and the problems associated with it haven't been widely tested and solved.

The spiral model is best used for the development of large-scale systems. It can be used for reliable and mission critical systems. The risk-driven nature of the spiral model is more adaptable to the plethora of software project situations than the document-driven life cycles (i.e., the waterfall model) or the primarily code-driven life cycles (i.e., the evolutionary model). The spiral model would be inappropriate for use in small projects.

Technology Insertion

Referring to the NRaD Manual, Technology Insertion is the enhancement of an existing system through the introduction of new technology. The new technology for software systems is often the result of improved hardware. The new hardware is usually characterized by higher throughput, or increased memory size, and will often have an improved operating system.

New hardware often provides the opportunity to also introduce a new version of the application software. The new version is usually characterized by improved functionality. The new software version is typically comprised of a significant amount of new code and modified existing code.

Technology Insertion projects are usually conducted the same as new development projects and thus will follow the generic estimation process contained herein. The primary difference, however, is the amount of existing software that is planned for reuse. The software developers are often optimistic regarding the amount of existing code that can be used. Estimators should be conservative in regards to reused code estimates.

The developers may state that the target code to be reused will only need a 10-20% modification when in reality some of it may require a complete rewrite. One of the most common reasons for this development of new code is to take advantage of operating system and hardware enhancements. Another reason is that programmers who are new to the project may recode in accordance with more modern software engineering practices.

The uncertainty in the amount of effort for the reused code should be reflected in the cost/schedule risk analysis. A range of estimates should be generated that reflects the optimistic viewpoint and the conservative viewpoint. A detailed analysis of the existing code should be performed as early in the project as possible to ascertain the degree of rework actually required. An accurate estimate of the reuse effort will not be possible until the existing code is actually inspected by the programmer/analysts.

Software Maintenance

After software has been developed, it must be maintained or supported. Software maintenance involves much more than correcting errors not discovered during testing. It also involves adding additional capabilities, deleting obsolete capabilities, modifying the software to address a change in the environment or to better interface with the host computer, and other activities that are necessary after software is developed. Therefore, software maintenance may also be called "software redevelopment" since the activities are reiterations of all or some of the software development phases shown in Figure 19-1.

Software maintenance is defined as the process of modifying existing operational software while leaving its primary functions intact. Software updates result in a changed functional specification for the product but do not include major recoding of the software that substantially change the functionality of the available software. Major recoding is normally best treated as a separate, follow-on project.

According to Robert L. Glass and Ronald A. Noiseux in their book Software Management Guidebook, almost all software maintenance can be partitioned into three categories: corrective, adaptive, and perfective. Table 19-2 briefly explains each category and gives the relative percent of maintenance effort expended for each category. Note that corrective maintenance, the closest analogy to traditional "maintenance", accounts for only about 17% of the overall maintenance effort.

Software maintenance is not inexpensive. According to L. H. Putnam and A. Fitzsimmons in their article "Estimating Software Costs" and other sources, software maintenance costs often exceed the total cost of software development. Consequently, a discussion of software cost estimation would be incomplete without considering maintenance costs (see section 19.6.2). Therefore, in the subsequent discussions of commercially available software cost models, an assessment of their ability to estimate software maintenance costs is included.