The significance of software as part of our systems is underscored by establishment of the National Software Council (NSC) in 1995. This nonprofit organization was founded to ''propel software to the forefront of the national agenda and define the National Software Strategy to preserve U.S. competi tiveness and security into the 21st century'' [12.38]. Its statement of mission is to ''ensure that the U.S. software sector continues to make a strong and growing contribution to national economic prosperity.'' Thus, the NSC has embraced a rather large vision with potential impacts on a national scale.
The NSC tends to focus on the following three activities:
1. Identify and articulate national software issues
2. Provide a forum for analysis and discussion of software issues
3. Propose policy recommendations to achieve software goals
Clearly, the NSC has to work with people from industry and government to achieve its goals. Its initial prospectus appears to be very thoughtful and well-conceived. Under the able leadership of John Marciniak as the first President, it is likely that the NSC will have a very positive influence on the national agenda with respect to software. Readers are encouraged to track and participate in the future activities of the Council.
The previous section on systems engineering discussed the thrust in the DoD toward commercial practices and away from military specifications and standards. This clear trend is reflected as well in the software arena. As an example, in 1994, the Defense Science Board (DSB) examined the issue of the commercial acquisition of defense software [12.39]. This extremely interesting report summarized principal findings and recommendations in the following categories:
• Process credibility
• DoD program management
• DoD personnel
• Use and integration of commercial off-the-shelf (COTS) software
• Software architecture
• Software technology base
• Management control and oversight
The report is strong on the point that the way the DoD currently does business is not compatible with the extensive use of commercial practices. It therefore calls for major changes in current software acquisition and development processes and practices. Exhibit 12.3 [12.39] provides a selected list of some of the findings and recommendations in the DSB report.
Exhibit 12.3: Selected Defense Science Board Findings and Recommendations
• High life-cycle cost in time and dollars
• Incredibly long (13-15 years) development cycle
• Excessive acquisition agent involvement in design detail and process
• Contractor-government relationship based on mistrust versus mutual trust
• Approach tends to be design it all and then build it
• Little focus on design for reusability
• Requirements and source selection inflexibility
• Complicated regulations
• Program management does not encourage ''80% solution for 20% cost''
• Shortage of qualified software personnel in DoD
• Normally no COTS market analysis
• Insufficient advantage taken of commercial research and development (R&D)
• Reasons for trouble on development programs: —Poor requirements definition
—Inadequate process management and control by contractor —Lack of integrated product teams (IPTs) —Lack of consistent attention to software process —Too little attention devoted to software architecture —Focus on innovation rather than cost and risk
• Make necessary changes in acquisition regulations
• Establish overarching software life-cycle guidelines
• Renew software program management education and training initiative
• Require trade studies of the use of COTS
• Emphasize use of software architecture
• Strengthen software technology transfer
The DBS report is but one milestone of many that define a significant trend in software engineering and development—a fundamental belief that commercial practices will streamline the process and result in shortened time frames and decreased costs, without any performance penalties.
In November of 2000, another report was produced by the DSB Task Force on Defense Software [12.40]. The Board was asked to explore defense software in relation to the use of commercial practices, and also to develop a strategy that makes appropriate use of these practices. The DSB examined six previous major DoD-wide studies and the 134 recommendations contained in them. They also concluded that only a few of these recommendations had been implemented, an indicator of how difficult it is to get a very large enterprise, such as the DoD, to shift gears and make changes.
As part of their work, the DSB reiterated what they called disturbing statistics that apparently apply to both commercial and government information technology (IT) projects. These numbers, attributed to the Standish Group [12.41], are cited below:
• About 16% of all of the IT projects were completed on time and within budget.
• Some 31% of these projects were canceled before they were completed.
• Adding the above (which is 47%), we are left with about 53% of the projects that are both late and over budget, with the actual expenditure being greater than the budgeted expenditure by more than 89%.
• For those projects that were completed, computed above as 69% of the total, only about 61% had the original set of features that had been specified (39% did not).
The overall recommendations of this DSB Task Force can be summarized by the following, in terms of new actions to be taken by the DoD:
1. More stress should be placed upon past performance and the degree of process maturity.
2. Additional independent expert reviews (IERs) of programs should be initiated.
3. The software skills of acquisition and program management personnel need to be improved.
4. Best practices in relation to software should be collected, disseminated, and employed.
5. Contract incentives need to be restructured.
6. The technology base that supports software development is in need of strengthening and stabilizing.
We shall see, down the road, if, when, and how these recommendations are implemented.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.