Chapter 3 Section 7
The Adoption Process and Personnel Risks Areas

• Transitioning from Ada 83 to Ada 95
• Transitioning from Another Language to Ada 95
• Becoming Informed about Ada 95 Adoption

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 are:
1. Failing to fully assess the impact of the new technology,

2. Adopting the technology (and tools) prior to their readiness,

3. Adopting the technology (and tools) too late and missing out on their competitive advantage, and

4. Unanticipated social and environmental issues from the transition.

Issue: What Are the Necessary Steps to Analyze and Mitigate the Risk of Failing to Assess the Impact of the New Technology?

Preparing an Ada 95 adoption impact analysis is the first order of business when planning to move to Ada 95. By failing to fully assess the impact of the new technology, the PEO or PM may underestimate the nature of the transition and assume that the new technology can be incorporated with no significant impact to budget or schedule. If this happens, there is significant risk of the project coming in late and/or over budget. Although it is possible to transition to a new technology (such as Ada 95) and maintain budget and schedule, this can only happen if the risks are identified early and managed carefully. PEOs and PMs must remember that changing programming languages will affect the design, test, integration and support phases as well as the coding phase of the software life-cycle. The conversion can be smooth, but only when it is an informed adoption.

The impact analysis should include the following project- and organization-specific information:

• What parts of the project's development process are affected when moving from Ada 83 to Ada 95?

• What is the effect on the project's development environment?

• What impact will the learning curve and training needs have on the project schedule?

• What is the effect of Ada 95 on project planning?

>Information buying - the acquisition of information about the risk in order to be able to plan better - is the primary risk reduction technique if this situation occurs. By becoming aware of others' efforts to adopt Ada 95 and their results, PEOs and PMs will be able to avoid making the same mistakes that the early Ada pioneers have made. PEOs and PMs should take the following steps:
• Invest in training and consulting,

• Use local Ada meetings, conferences, magazines and the Internet to learn about others' Ada 95 experiences,

• Hire Ada-experienced people, and

• Seed the experienced people on transition projects.

Issue: What Are the Necessary Steps to Analyze and Mitigate the Risks of Adopting Ada 95 Technology and Tools Before Their Readiness?

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:
• 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.

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.



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 schedule);

• 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

Issue: What Steps are Necessary to Avoid Adopting the Technology (and Tools) Too Late to Enjoy a Competitive Advantage?

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:

• 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 experience), and

• The impact of upgrading the language technology with the support tools found in the software development environment.

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.

Issue: What Can Be Done to Avoid Unanticipated Social Issues Arising from the Transition?

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 ones.

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.

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:
1. The impact of the paradigm and mindset shifts from one language (culture) to another, and

2. The impact that changing programming languages has on secondary technology (e.g., tools, environments, training, development methods, and standards).

Issue: How Best Can the Risks of the Paradigm and Mindset Shifts from One Language (Culture) to Another Be Managed?

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., its culture).

• Provide mentors with Ada experience who can help guide the development team.

• 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".

Issue: How Best Can the Risks on Secondary Technology Be Managed?

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.

Issue: What Are the Best Sources of First-Hand Information on Ada 95?

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:
• 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.

For detailed contact information on these sources, see Appendix A.

Issue: Who Can I Contact with Questions, Comments and Lessons Learned?

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