Chapter 3 Section 7
The Adoption Process and Personnel Risks Areas
In addition to the new opportunities presented by Ada 95, any
technology adoption effort has associated risks. To reduce or manage the
risks, the PEOs, PMs and their staffs must understand them. This section
describes the risks surrounding the adoption process and personnel areas - and
discusses strategies to mitigate those risks. Specific Ada 95 adoption issues
will be raised and answered in an issues- and answers-based forum.
The major risks to the successful adoption of Ada 95 are common to most new
technology adoptions, especially when moving from one programming language to
another. This subsection looks at those technology adoption risks that can
sabotage the entire transition effort and therefore should be a PEO's and a
PM's priority. Successfully managing these risks reduces the likelihood
of project failure; not attending to these critical issues can impair the
entire transition effort.
Most of the risks associated with transitioning from one programming
language to another are simplified or eliminated, because Ada 95 is an
incremental upgrade to Ada 83. Among the remaining risks that the PEO
and PM must manage, the ones dealing with the adoption process and personnel
- Failing to fully assess the impact of the new
- Adopting the technology (and tools) prior to their
- Adopting the technology (and tools) too late and missing
out on their competitive advantage, and
- Unanticipated social and environmental issues from the
When adopted too early, the technology may fail to live up to its
advertised promises. PEOs and PMs should have their staff, Research,
Development and Engineering Center (RDEC), or contractors assess the
technology's readiness to control the timing of the Ada 95 adoption.
To assess this risk, PEOs and PMs should:
These pilot efforts and technology studies will reveal many characteristics of
the technology. Based on these characteristics, PEOs and PMs can judge if it
is too early or too late to begin the technology adoption. Table 6 provides
PEOs and PMs with information on which characteristics indicate that it is the
right time for their organization to adopt Ada 95.
- Sponsor pilot project efforts and prototypes to evaluate the new
technology and tools in a realistic usage scenario.
- Ensure that the PM Office is highly informed about the current state of
Ada 95 technology. To manage an Ada 95 adoption effort well, the PM office
should become highly involved in the Ada 95 community.
- Understand the impact of Ada 95 on their software engineering environment.
Other tools may need to be upgraded in concert with the adoption of Ada 95.
The lead-time to coordinate with vendors' schedules must be accounted for in
the project's schedule.
- Buffer their projects from changes in tools and technology during the
readiness risk assessment by acquiring tools incrementally.
Table 6 : Balancing the Issues of Adopting Ada 95 Too Early and Too Late
The key to mitigating the risk of adopting too early
is to use information buying techniques. PEOs and PMs should use
the following techniques:
- Benchmarking and quality evaluation of tools to assess the readiness
of the technology and tools;
- Measuring the upward compatibility of existing Ada 83 software to become
informed about the impact of Ada 95 on existing code;
- Ensuring that the project's success does not depend on the new technology
being adopted (i.e., the project can still be accomplished with the previous
technology, even though the old technology may increase budget or
- Working to measure and monitor pilot projects so that project estimation
tools can be refined to reflect early Ada 95 experience;
- Coordinating the impact of upgrading the language technology with the
support tools found in the software development environment so that the entire
set continues to work together; and
- Incrementally adopting the tools and technology across parts of the
project. This will ensure that problems are dealt with locally so that they
don't ripple across the entire project
Failing to adopt competitive technologies in a timely manner may be
riskier than switching to the new technology. In an era of migration to
single common systems, downsizing defense budgets, and fee-for-service
programs, the defense industry is becoming increasingly competitive. It is no
longer enough for a project to come in on time and on budget. The program may
find itself competing for funding against similar systems in other departments
as the DOD migrates toward fewer standard systems. Technology innovations are
spurred on by the constant need for people to do more with fewer resources. If
PEOs or PMs fail to keep up with technological advances, they risk being
unable to perform their mission. This may lead to other groups being chosen to
provide the same services - possibly faster or on a smaller budget. It is
important for organizations competing for limited resources to use new
technology to enhance their competitive edge.
Timing is essential to determining when the technology is mature enough for
use (minimizing the risk of early adoption), but is not yet in use by all
competitors (maximizing the competitive gain from the technology). One of the
more suitable risk reduction mitigation techniques consists of a series of
studies that helps to determine the intersection point of these two technology
curves. Based on the characteristics defined in Table 6, PEOs and PMs, in
cooperation with RDECs and Federally Funded Research & Development Centers
(FFRDCs), should monitor the maturity of Ada 95 with respect to their own
project needs. Items to monitor include:
Within the DOD, when "competitors" may actually be part of the same
overall organization, it is also possible to reduce risk through cooperation.
Risk may be amortized over several organizations (e.g., within a PEO) by
joint Ada 95 adoption efforts in which the costs and lessons learned are borne
jointly by two or more groups.
- The readiness of the technology and tools,
- The upward compatibility of existing Ada 83 software (to become informed
on the impact of Ada 95 on existing code),
- The adaptation of project estimation tools (to reflect early Ada 95
- The impact of upgrading the language technology with the support tools
found in the software development environment.
Remember that people are involved in the adoption process.
Any change can be difficult for an organization. PEOs and PMs should make sure
that the adoption of Ada 95 is a participatory process and that their software
developers are prepared for and actively involved in the transition planning
as well as implementation phases. While this may seem to be a "soft" issue
compared with the availability of compilers or the performance of Ada run-time
kernels, one of the most important lessons of previous technology adoptions is
that the social and environmental changes are often the most important
Risk transfer will be a useful technique to mitigate the risk of social
disruption. In this case, the PEO and PM must actively involve
everyone (the staff, development contractors and support contractors) in the
adoption of Ada 95. Ensuring that everyone participates in the process will
also serve to ensure that the adoption is driven by the team and not
imposed from above. This will result in the team owning the adoption effort
and tailoring it to their current culture.
The Software Engineering Institute (SEI) can provide detailed
information about handling change within an organization. Much of its
work in this area has helped many organizations institute process improvement.
PEOs and PMs should contact the SEI for additional information and help
with this aspect of Ada 95 adoption.
Transitioning from Another Language to Ada
PEOs and PMs should consider the adoption of Ada 95 to include the
adoption of Ada 83, since Ada 83 is the core of Ada 95. In addition to
the risks discussed in the previous subsection, there are
also the following:
- The impact of the paradigm and mindset shifts from
one language (culture) to another, and
- The impact that changing programming languages has on
secondary technology (e.g., tools, environments, training, development
methods, and standards).
When transitioning from another language to Ada 95, the paradigm and
mindset shifts are greater than they are when moving from Ada 83 to Ada 95.
Each programming language brings with it a large collection of
techniques and methods that reflect "how software ought to be built" using
that language. Changing from one language to another is not as simple as
switching from one make of automobile to another. Rather, it is more akin to
switching from driving a car to piloting a jet.
PEOs and PMs should take the following steps to make sure that their staff and
contractors/developers successfully adopt the Ada 95 culture:
- Support technology transfer efforts that educate the developers not only
to the syntax of the new language but also to the way it should be used (i.e.,
- Provide mentors with Ada experience who can help guide the development
- Hire experienced Ada personnel and seed them on the development team as
group leaders who are responsible for showing the entire team how to create
software "with an Ada mindset".
PEOs and PMs should have their staff, RDEC or contractors/developers
assess the impact that changing programming languages has on secondary
technology. The areas to be assessed include:
- The design method - For example, Ada 95's support for OOP may cause
the development team to examine an object-oriented method for design.
- Technology transfer - Many of the courses taught have programming
language-specific elements, even though the courses are not about a particular
language; courses on testing are a good example.
- Documentation and process standards - For example, MIL-STD-2167A or
MIL-STD-498 may describe concepts such as "modules" in programming language-
specific ways; these must be tailored to Ada 95.
- Software Engineering Environment - Coordinate the impact of
upgrading the language technology with the support tools found in the software
development environment so that the entire set continues to work together.
Many tools including CASE tools have language-specific elements.
PEOs and PMs may find many sources of information at little or no
cost, including those listed below. Fortunately for those
transitioning to Ada 95, "buying" does not always involve spending large sums
of money. Information is often free, although some time must be spent
acquiring it. Some information sources provide direct first-hand information,
others provide lists and pointers to direct information. PEOs and PMs should
avail themselves of the following sources of information:
For detailed contact information on these sources, see Appendix A.
- Government Information Sources
- The AdaIC and the Ada 95 Project Office are good sources. The AdaIC provides
pointers to many direct sources of information; it should be the first item on
any PEO's or PM's shopping list. The AdaIC can provide its information by
phone, fax, mail, e-mail, bulletin board, or via the Internet. The Ada 95
Project Office can also provide first-hand information on Ada 95 and direct
adopters to other sources.
- User Groups - A number of national,
local and international user groups meet regularly to share information on Ada
usage. These organizations typically offer free membership or charge only a
nominal membership fee. Local groups meet monthly or bimonthly with speakers
and discussions on Ada-related topics. PEOs and PMs should make sure that
they and/or their staff regularly attend such meetings to exchange ideas with
other project managers. ACM SIGAda is one such international organization
with local chapters in many cities.
- Conferences - There are
both Ada-specific conferences and general software conferences that feature
Ada as one part of a larger theme. PEOs and PMs should make sure that they or
their staff attend at least one major Ada conference each year to exchange
information with other managers, tap into the experience of professional
consultants, and acquire up-to-date information from tool vendors. Tri-Ada,
sponsored by ACM SIGAda, is the largest Ada conference held in the U.S. each
year. Other notable Ada conferences include the Washington Ada Symposium
(WAdaS), the Annual Conference on Ada Technology (ANCOAT) and the Ada-Europe
conference, which rotates each summer to a different European city.
- Magazines - The most well-known
Ada-specific magazine is Ada Letters. This bimonthly publication
features articles on technical and non-technical topics. Ada is also featured
in many other magazines devoted to software issues. PEOs and PMs should
have their staff prepare summaries of information on Ada found in software
magazines. They should also ensure that their technical staff monitors the
technical articles in these magazines on a regular basis.
- Electronic Sources -
Often the most immediate and up-to-date source of Ada 95 information will be
found on-line (especially via the Internet). Several kinds of information
sources exist: files of information, which may be downloaded from
several repositories; newsgroups or discussion groups, where
questions may be asked and answered; electronic mailing lists for
discussions on specialized topics such a bindings or reuse; information
browsers, such as the World Wide Web (and its browser Mosaic) and gopher,
which provide interfaces to large collections of interrelated information; and
electronic user groups such as Team-Ada, which are a collection of
volunteers who assist organizations using Ada via electronic mail.
- Ada Tool Vendors - Compiler and other tool vendors will provide
detailed information on their products. They also are a good source for
detailed tool performance measurements.
PEOs and PMs will find a large amount of support within the Department
of Defense for all Government Ada 95 users. The Ada Joint Program
Office (AJPO) is the central group within DOD that manages Ada technology. The
program office sponsors the AdaIC, which is specifically set up to answer
questions and collect lessons learned about Ada 95 adoption. Additionally,
PEOs and PMs may draw on the experience of FFRDCs to assist in the transition
to Ada 95.
Each source of first-hand information listed in this last section of
Chapter 3 is also a good place to receive answers to questions. These sources
also may act as forums where comments and lessons learned may be
distributed. For contact information on these sources, see Appendix A.
Previous Section - COTS, Legacy Software, and Multi-Language Development
Next Chapter - When To Initiate the Ada 95 Adoption Process
Table of Contents