Skip to main content

Currently Skimming:

3 Systems and Software Engineering in Defense Information Technology Acquisition Programs
Pages 47-78

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 47...
... model -- despite a body of work that is critical of the waterfall mentality, such as the Defense Science Board reports cited below, and the issuance of directives identifying models other than the waterfall approach as the preferred approach. The waterfall model discussed below remains at least implicit in the oversight structure and processes that govern IT acquisition programs in the DOD today.
From page 48...
... The evolution continued through DOD-STD-2167 and 2167A in the late 1980s, driven in part by strong criticism of the waterfall model and a growing appreciation for a model not so heavily influenced by hardware and weapons systems thinking. Brooks's seminal paper "No Silver Bullet -- Essence and Accidents of Software Engineering," published in 1987, was among the first to criticize the notion integral to the waterfall model -- specifically, that one can fully specify software systems in advance: Much of present-day software-acquisition procedure rests upon the as sumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it.
From page 49...
... 5 Barry Boehm, "A Spiral Model of Software Development and Enhancement," Proceed ings of the International Workshop on Software Processes and Software Enironments, ACM Press, 1985; also in ACM Software Engineering Notes 15(5) :22-42, August 1986; and IEEE Computer 21(5)
From page 50...
... . Today, many of the DOD's large IT programs therefore continue to adopt program structures and software development models closely BOX 3.1 Evolutionary Acquisition Versus Iterative, Incremental Development Because both are incremental development approaches, evolutionary ac quisition (EA)
From page 51...
... And although many stakeholders are permitted to express opinions at each assessment or milestone decision point in the governance and oversight process, the voice of the end user is seldom heard in this process. ITERATIVE, INCREMENTAL DEVELOPMENT This section begins with a brief history of iterative, incremental development drawn from Craig Larman and Victor Basili and from Alan MacCormack.8 It is provided as a way to situate agile and related approaches within a broader context and also to demonstrate that IID has a long history of being applied successfully for different types and scales of problems.
From page 52...
... Owing to shifting needs during the software development process, engineers had to abandon the waterfall model for an IID approach, using a series of 17 iterations over 31 months. TRW, Inc., also used the IID approach for government contracts in the 1970s.
From page 53...
... In the 1990s, the developers shifted away from the heavy up-front speculation still being used in the IID approach of the 1970s and 1980s. In 1995 at the International Conference on Software Engineering, Fred erick Brooks delivered a keynote address titled "The Waterfall Model Is Wrong!
From page 54...
... That survey also found that Scrum is the most popular ASD methodology, that ASD is a relatively new phenomenon to Microsoft, that most projects have employed ASD techniques for fewer than 2 years, and that ASD is used mostly by co-located teams who work on the same floor of the same building. A fair amount of research has been conducted on teams adopting ASD processes.14,15 From the academic research perspective, Laurie Williams 13 A
From page 55...
... Antón, "Toward a Framework for Evaluating Extreme Programming," Proceedings of the th International Conference on Empirical Assessment in Software Engineering, Edinburgh, Scotland, May 24-25, 2004, pp. 11-20; Lucas Layman, Laurie Williams, and Lynn Cunningham, "Motivations and Measurements in an Agile Case Study," Journal of System Architecture 52(11)
From page 56...
... Agile processes are fundamentally different from the practices adopted during traditional development, and represent much more than a mere time-compression of the waterfall development process. Several prac tices that are part of ASD are significantly different from the traditional waterfall software development process.
From page 57...
... SOURCE: Created with data from Laurie Williams, William Krebs, Lucas Layman, and An nie I Antón, "Toward a Framework for Evaluating Extreme Programming," Proceedings of the th International Conference on Empirical Assessment in Software Engineering, Edinburgh, Scotland, May 24-25, 2004, pp.
From page 58...
... The above descriptions are meant to give a flavor of what IID looks like in the context of various agile software methodologies. Although pure 18 Don Johnson, Office of the Deputy Assistant Secretary of Defense for Networks and Information Integration, "Challenges in Acquisition of Information Technology," presenta tion to the committee, December 8, 2008.
From page 59...
... , the core concepts of the methods are nonetheless applicable to defense IT acquisition. Of particular importance is the idea that the IID cycle must constantly obtain and reflect end-user feedback, especially for software development and commercial off-the-shelf software integration (SDCI)
From page 60...
... • Based on field feedback and updates addressing any other end-user concerns, the main release takes place. Release Start P + RM Coding Phase 1 Beta Candidate Release FIGURE 3.3.1 Development time line for some very large systems.
From page 61...
... The characteristics that can be established in such platform architecture include security and information assurance, operational availability, con tinuity of operations and disaster recovery, scalability, extensibility in provisioning, and extensibility in operations. These are all characteristics that are inherent attributes of an underlying architecture, and there is no reason that every IT program in a portfolio should be required to address them from the ground up.
From page 62...
... These increases provide ample reason for separating the COTS hardware components of an IT program from the software development and COTS software integration elements of an IT program. This is true both for infrastructure-based capabilities that have ample bandwidth to permit the use of centralized computing centers, and for deployed capa bilities where bandwidth limitations often dictate a deployed version of a virtualized computing, storage, and network utility infrastructure.
From page 63...
... Rather, as already argued in Chapter 2, a more effective approach is to establish a separate and distinct program governance and oversight regimen for IT programs that leverages the significant body of research available and the more than 20 years' worth of past recommendations and conforms to the widely adopted commercial best practices for development. IT programs can be defined to focus primarily on the acquisition of developmental software, COTS software integration, COTS hardware, COTS software, commercially available services, or combinations of these.
From page 64...
... However, the nature of the capability increments should differ for hardware and software components owing to the different issues driving them. Although some DOD IT programs are defined as exclusively COTS hardware acquisition programs (e.g., the acquisition of networking, com 22 William Perry, Memorandum from the Secretary of Defense to the Secretaries of the Military Departments, "Specifications and Standards -- A New Way of Doing Business," June 29, 1994, Office of the Secretary of Defense.
From page 65...
... This has created a compelling business case for virtualized computing, storage, and network infrastructure utility models in many enterprise environments. The existence of such infrastructure can decouple the time cycles of SDCI capability increments from the need to deploy or refresh hardware, allowing SDCI IT programs or portfolios of programs to deploy capability to end users with significantly increased speed and agility.
From page 66...
... To break this hammerlock on software-intensive IT programs, several aspects of the program structure and the governance and oversight regimen would need to be changed through the adoption of the following core principles: • Emphasis on shorter cycle times to deliver the best IT to the warfighter -- Time-boxed incremental deliveries of usable capabilities (also known as capability increments)
From page 67...
... To fully internalize these core principles, SDCI programs should be structured as IID programs with time-boxed capability increments of not longer than 12 to 18 months to deliver meaningful capability to end users. The recommended acquisition management approach for SDCI IT systems programs is shown in Figure 3.2.
From page 68...
... Integrated T&E / Voice of the End User Operations and Sustainment 4 to 8 Week Iterations Evolutionary Increment 1 A B C System Development & Business Case Planning & Analysis Deployment Demonstration (SDD) Development Integrated T&E / Voice of the End User Materiel Concept Development Operations and Sustainment Demonstration Decision 4 to 8 Week Iterations Integrated T&E 12 to 18 months Increasing Capability FIGURE 3.2 The acquisition management approach recommended by the committee for software development and commercial off-the-shelf integration (SDCI)
From page 69...
... System Development and Integrated Test and Evaluation / Voice of the End User Demonstration (SDD) Requirements Analysis, Requirements Analysis, Requirements Analysis, Re-prioritization and Re-prioritization and Re-prioritization and Planning Planning Planning Architecture Refine- Verification and Architecture Verification & ment Validation Refinement Validation Test Cases Testing Test Cases Testing Design Integration Design Integration Implementation Implementation Figure 3.3 broadside, editable 4 to 8 Week Iterations FIGURE 3.3 Time-boxed iterations within each capability increment.
From page 70...
... The content of early iterations should be focused on a combination of the most technically challenging elements of the capability increment and on functional capabilities with the greatest business or warfighting value. The voice of the end user should provide feedback on each iteration for the refining and prioritizing of requirements in order to institutionalize the learning and communications process vital to IID.
From page 71...
... For SDCI programs of any significant scope and scale, system architecture is likely to represent one of the most significant risks, and it should be addressed early in the program, even during the concept development phase in advance of entering the development of capability increments. Here again, however, caution and pragmatism must be exercised to prevent susceptibility to the demand that all requirements must be fully documented up front.
From page 72...
... Further, the continuous nature of T&E inherent in IID and the learning and communications process integral to IID will develop substantial T&E results as the iterations progress within a capability increment. Therefore, an integrated approach to T&E to include the voice of the end user; traditional development, testing, and evalua tion; operation testing and evaluation; interoperability certification; and information assurance certification and accreditation equities is a fundamental element of this modified acquisition management approach for IT programs.
From page 73...
... , as defined in Chapter 2, should have decision authority, derived explicitly from higher authority, to determine trade-offs among schedule, cost, and functionality. One of the most important tasks of the PM and PMT is to determine priorities in the IID development: what is in the first capability increment, what is in the second, and so on.
From page 74...
... Finally, since multiple time-boxed capability increments will fit within each budget cycle of the planning, programming, budgeting, and execu tion process, and to give end users confidence that their requirements will be addressed (thereby avoiding the unintended but real consequence of users trying to overload their requirements into the first capability incre ment) , IID programs should be provided with a stable budget profile across multiple capability increments.
From page 75...
... The capability increments for such a CHSS program should be driven by a combination of affordable investment profiles, technology refresh objectives, avoidance of technological obsolescence, and the time that it takes for installation across the production inventory objective for the program. Although Moore's law has historically operated on an 18-month time cycle, the useful life of networking, computing, and storage hard ware is at least two to three times that duration.
From page 76...
... This could lead to a strategy of deploying increment 1 of a capability to a third of the inventory objective in the first 18 months of the program, increment 2 to the second third of the inventory objective in the second 18 months of the program, and increment 3 to the final third of the inventory objective in the third 18 months of the program, and then initiating technology refresh on the first third of the inventory objective with an increment 4 in the fourth 18 months of the program, and so on.28 The structure of a CHSS IT program is as much a question of investment and business strategy as it is a question of technical strategy; all of these topics should be addressed early in the program and revalidated as capability increments proceed. The governance and oversight model for such an IID-based IT program can be substantially simpler than the current one described in Chapter 1.
From page 77...
... For COTS software programs, it becomes largely a COTS configuration effort. For COTS hardware programs, it becomes largely a COTS hardware integration effort or, at most, a ruggedization effort.
From page 78...
... B C System Development and Deployment Integrated T&E / Voice of the End User Operations and Sustainment 4 to 8 Week Iterations Capability Increment 1 A B C System Development and Business Case Deployment Planning and Development Analysis Integrated T&E / Voice of the End User Materiel Development Concept Operations and Sustainment Decision 4 to 8 Week Iterations Integrated T&E 12 to 18 months Increasing Capability FIGURE 3.4 The acquisition management approach recommended by the committee for commercial off-the-shelf hardware, soft ware, and services (CHSS) information technology programs.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.