Acquisition Practices

Acquisition practices of software systems are related to the following topics already discussed:

• Military Standard 498

• Acquisition trends for systems, including acquisition reform

• The move toward commercial practices

• Various software development approaches

• Reuse of software

The bottom line is that software system acquisition practices are changing, and the expectation is that continuous modifications in current practices are likely to be on our agenda, judging from our history, well into the twenty-first century.

Two of the most recent trends with respect to software acquisition can be identified as

• The emergence of a software acquisition capability maturity model construction

• Simulation and modeling for software acquisition (SAMSA)

For the former, a structure parallel to the Software Engineering Institute (SEI) capability maturity model is being developed, along with key process areas (KPAs) that relate to the software acquisition process. In the latter area, a notable effort is that of Boehm and Scacchi at the University of Southern California [12.50] who indicate that ''there are substantial opportunities to rethink how the acquisition of software-intensive systems should occur in ways that address the recurring problems.'' SAMSA activity is predicated on the notion that it is important to make the acquisition of future softwareintensive systems more agile. This can be achieved by reengineering the various software processes across their overall life cycle. SEI's vision for this type of effort is embodied in an approach called VISTA (Virtual Information SysTem Acquisition). VISTA refers to a process whereby ''an evolving series of ever more complete and operational systems versions are acquired through a series of short acquisition life cycles.'' The VISTA approach is based largely on the construction of models and simulations of software development life cycles. Readers with a further interest in this trend should contact the authors cited before.

A significant approach to trying to improve our overall ability to build and field software systems is embodied in GSAM—Guidelines for Successful Acquisition and Management of Software Intensive Systems [12.51]. GSAM attempts to articulate success paths, and thereby mitigate against ''repeated inappropriate or unsuccessful practices.'' These paths might also be called ''lessons learned'' as well as ''best practices.'' We note from a previous discussion of the work of the Defense Science Board in 2000 [12.40] that best practices also represented an area of special focus in that context. GSAM also suggests some key principles, as summarized below:

1. Focus on the real customer.

2. Talk about the program content and not its politics.

3. Understand the full life cycle of the program and its needs.

4. Determine baseline requirements and the scope of the project as soon as possible.

5. Tackle the program as a series of small steps in order to achieve incremental successes.

6. Assume meaningful measurements for cost, schedule, and quality management.

7. Identify and manage key program risks.

8. Capture and utilize data and best practices from earlier programs.

9. Emphasize and sponsor improvement efforts, and assure that managers ''walk the talk.''

12.3.6 I-CASE (Integrated Computer-Aided Software Engineering)

For a number of years, software vendors have provided tools for software engineers under the general title of computer-aided software engineering

(CASE). The purpose of such tools, of course, has been to increase the productivity of software engineering projects. The Air Force's Software Technology Support Center (STSC) has been cataloging and analyzing these tools, for which a representative list is provided in Exhibit 12.4. Formal reports from the STSC on these tools have included the categories of

• Requirements analysis and design

• Software estimation

• Source code static analysis

• Reengineering

• Documentation

• Project management

• Test preparation, execution, and analysis

• Software engineering environments

Starting around 1990, the DoD formally entered the CASE arena by sponsoring a program known as Integrated Computer-Aided Software Engineering (I-CASE). They issued a request for proposal (RFP) to industry for the purpose of developing a suite of I-CASE tools. The Air Force's Gunter Air Force Base in Alabama became the agent for the I-CASE procurement. As of 1991, the I-CASE development environment was described [12.52] as a central database repository encyclopedia with connectivity to a variety of tools for:

• Requirements analysis and specifications

• Project management

• Quality assurance

• Prototyping

• Code generation

• Configuration management

• Cross development

Exhibit 12.4: Selected Computer-Aided Software Engineering

(CASE) Tools

Name of Tool

Vendor

BACHMAN/Analyst CARD tools Corvision Design Aid II EasyCASE Professional

Yourdon/CGI Systems Inc. Evergreen CASE Tools, Inc.

Bachman Information Systems

CARDTools Systems Corp. Cortex Corp.

Name of Tool

Excelerator Series IEW/Workstations Integrated Systems Engineering Toolset

Information Engineering Facility ISE Eiffel

Maestro II

MAGEC RAD System

Micro Focus Cobol Workbench

MicroSTEP

Natural Engineering Series

Objectmaker

Objectory

Oracle CASE

Paradigm Plus

POSE

ProKappa

Prokit Workbench

Promod CASE Tools

RDD-100

RTrace

Silverrun

Softbench

Software Engineering Toolkit Software Through Pictures

Statemate Sterling Developer System Architect System Developer I superCASE Synon/2E TAGS Teamwork TreeSoft

Visible Analyst Workbench

Vendor

Intersolv

Knowledgeware Federal Systems LBMS, Inc.

Texas Instruments Interactive Software Engineering

Inc. Softlab Inc. Magec Software Micro Focus Syscorp International Software AG of North America Mark V Systems Objective Systems Oracle Corp. Protosoft, Inc.

Computer Systems Advisors Intellicorp, Inc.

McDonnell Douglas Information

Systems Meridian Software Systems Ascent Logic Corp. Marconi Systems Technology Protocol/Zycad Corp. Computer Systems Advisors Hewlett-Packard Caset Corp.

Interactive Development

Environments i-Logix, Inc. Sterling Software Popkin Software & Systems, Inc. Cadware Inc.

Advanced Technology International Synon, Inc.

Teledyne Brown Engineering Cadre Technologies, Inc. +Software

Visible Systems Corp.

Other key features of I-CASE included open systems, Ada as a development language, and evolutionary development.

The contract for I-CASE was ultimately won by Logicon in 1994 from the Air Force's Standard Systems Center. The contract had a face value of over

$670 million over a ten-year period. The overall notion was to build a standard set of I-CASE tools that could be used throughout the DoD and its contractors. I-CASE has three essential parts:

1. A software engineering environment

2. An operational test environment

3. A run-time environment

Logicon brought its I-CASE product to the marketplace using the name LOGICORE.

I-CASE represents a major investment by the DoD to help solve the software development problem. As of 1995, the DoD issued a statement by the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence—C3I) reflecting its commitment to I-CASE [12.53]:

This statement confirms the Department's commitment to the I-CASE initiative and the need to aggressively exploit the advantages available now through the Air Force I-CASE contract. The contract is available to DOD components and any Federal Agency wishing to procure the I-CASE software engineering environment (SEE) or tools. . . .

It appears that I-CASE or some derivative thereof will be an increasingly strong force with respect to how we execute the complex tasks of software engineering.

12.3.7 Architecting

In the Defense Science Board report [12.39] on acquiring defense software commercially, considerable attention was focused on software system architectures. As the report points out, a software architecture consists of:

• Software system components

• The relationship between the components

• Rules for their composition (constraints)

In the same vein, documentation of a software architecture would contain, as a minimum:

• System functionality

• Software system components

• Interfaces, standards, and protocols

• An execution model consisting of: —data flows

—control flow

—critical timing and throughput considerations —error handling

A good software architecture was considered a ''prime enabler of flexibility and reuse'' and might reduce the costs of changes and upgrades by as much as 30-50% per year. Solid architectures were also seen as a key tool for:

• Evolutionary development (see Section 12.3.4)

• Early involvement of users with functional capability

• Ability to include changing commercial technology

• Assisting in the areas of requirements changes and product line management

Of course, a software architecture must be viewed within the context of an overall systems architecture (see Chapter 9), a point that was not strongly emphasized in the DSB report.

An overview article on software architectures claimed that there is appropriate and renewed interest in this subject [12.54]. This revival of interest has led many researchers to reconsider basic questions, such as the following:

• What is a software architecture?

• Are there generic forms of architectures?

• Are there sets of preferred architectures?

• What is the process whereby an architecture is developed?

• How can we promote the use of good architecting principles in both government and industry?

A variety of cases were cited in which the preceding and other software architecture issues were considered by, for example, the Air Force, (e.g., the CARDS and PRISM programs), industry, and the Software Engineering Institute (SEI) at Carnegie-Mellon University, with the latter apparently taking a lead role in these matters. However, other parts of the government are stepping up to this challenge. An example is the Defense Information Systems Agency (DISA) that set forth a technical architecture framework for information management [12.55]. This framework provided ''guidance for the evolution of the DOD technical infrastructure'' with respect to information management rather than providing a specific system architecture. The framework, known as TAFIM, was presented in a series of volumes, namely:

Volume 1: Overview

Volume 2: Technical Reference Model

Volume 3: Architecture Concepts and Design Guidance

Volume 4: DoD Standards-Based Architecture Planning Guide

Volume 5: Support Plan

Volume 6: DoD Goal Security Architecture

Volume 7: Information Technology Standards Guidance

Volume 8: DoD Human Computer Interface

Efforts of this type move us all in a positive direction in terms of developing a better understanding of the issue of software and information system architecting.

Finally, with respect to software architecting, we have two topics that have already been discussed in previous sections of this book. The first has to do with the architecting of systems, and the point is made that the same procedures for architecting systems are applicable to software architecting. Chapter 9 addresses these points, as does Section 12.2.4 of this chapter, dealing in part with the C4ISR Architecture Framework [12.16]. In addition, the Appendix illustrates how a software system may be architected. The second point is related to the IEEE standard that is concerned with architectural descriptions [12.56]. Although that standard does not demonstrate how to architect a software system, it does introduce the important notion of architectural views of software systems. These views, as per the three important system views as articulated by the C4ISR Framework, provide insight into the ultimate architecture and, by means of reverse engineering, it may be possible to infer a legitimate software architecting process. Until this is demonstrated, however, it is suggested that the reader follow the architecting process defined in Chapter 9.

Project Management Made Easy

Project Management Made Easy

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.

Get My Free Ebook


Post a comment