5.0    Managing the Ada 95 Transition Risks

Risk is an inherent factor in any software project. A critical element of effective project management is recognizing potential risks and then managing those risks to neutralize their negative effects. Along with the activities identified in Section 4, associated risks were described. PEOs/PMs must assess the impact that these risks will have on their programs and set a plan in action to control the effects that these risks might have on a program's quality, cost and schedule. This section describes a two step process that PEOs/PMs can employ to minimize transition risks. This process, shown in Figure 5-1, includes assessing risks and implementing steps to mitigate them.

Figure 5-1. Managing the Ada 95 Transition Risks

The objectives of this transition risk management process are to:

The guidance provided in this section provides the PEO/PM with the information necessary to complete the risk matrix found in Section 5.0 of the transition planning template.

5.1    Assessing Transition Risks

The activities identified in Section 4 may have risks associated with them that PEOs/PMs must address in their overall transition approach. It is important to understand what these risks are and to assess their potential impact on the success of the project. One method available to PEOs and PMs is to list all potential risks and rank them as high, medium, or low depending on the effect that they could have on the technical aspects, cost, and schedule of a program. This enables PEOs/PMs to consolidate and review all risks at one time. Different combinations of risks may alter the approach and set of activities that is employed to execute the transition effort. High-risk aspects of the transition must be effectively addressed by a mitigation strategy that minimizes their impact.

Table 5-1 associates the most commonly identified Ada 95 transition risks with the transition types detailed in this guide. The letter "L" represents a low level of risk, "M" represents a moderate level of risk, and "H" represents a high level of risk. As shown in the figure, the transition to Ada 95 from an existing Ada 83 base is a relatively low risk venture. The other scenarios present more challenges for the PEO or PM to manage.


Table 5-1. Common Ada 95 Transition Risks

PEOs/PMs should add or delete from this list of risks as their unique circumstances warrant. After customizing and assessing the list of risks associated with their program(s), PEOs/PMs should use this information to populate the first two columns of the risk matrix shown in Section 5.1 of Appendix A. This method of classifying risks facilitates the development of effective mitigation strategies by providing a complete view of all transition risks.

Table 5-2 builds on the risk matrix example started in Section 4. Using information contained in Table 5-1, the PEO/PM assesses the impact that these risks have on the success of the completion of the transition effort. It is also appropriate to add any additional risks that pertain to the program.

5.2    Mitigating Transition Risks

Once the risks associated with a particular transition effort have been listed and classified, PEOs/PMs can begin to develop plans to mitigate them. The following subsections describe the risks listed in Table 5-1 in more detail along with steps that can be taken to minimize their impact on the transition effort. The steps discussed in the following subsections should be added to the third column of the risk matrix as shown in Table 5-2. A more detailed discussion of the issues presented here can be found in Chapter 3 of the Ada 95 Adoption Handbook.


Table 5-2. Sample Risk Matrix

5.2.1    Ada 95 Compiler Maturity

Ada 83 vendors are building on ten years of experience and compiler technology. Early Ada 95 compilers will be significantly more mature and stable _ in terms of both compiler code quality and compiler reliability _ than were early Ada 83 compilers. Since Ada 95 is an incremental upgrade to the language, Ada 95 compilers are upgrades to Ada 83 compilers. Nonetheless, fully adopting an Ada 95 compiler that is not production-ready can severely impact a system's quality, cost, and schedule. Therefore, PEOs or PMs should ensure that the compiler they select fully performs as expected.

Risk Mitigation Steps:

To assess the maturity of available Ada 95 compilers, PM Offices and their contractors/developers should:

5.2.2    Ada 95 Tool Maturity

Some support tools for Ada 95 are already available. Some of these tools are incremental upgrades to support tools that are available for Ada 83 and others are new tools for Ada 95. There are, however, two issues that must be addressed with these tools. First, as with compiler maturity, insufficient or unreliable tool support will adversely affect the project. Second, without tools that fully support Ada 95, its new features cannot be capitalized on.

Risk Mitigation Steps:

5.2.4    Ada 95 COTS/OS Interfaces

Many systems are stand-alone and have no external interfaces, but for those systems with existing interfaces to COTS and operating systems, interfaces must be preserved and maintained to develop a fully functional system in Ada 95. PEOs and PMs will find that Ada 95 allows them to incorporate existing software of many kinds: reusable software written in both Ada and other languages, COTS and GOTS software written in many languages, and their existing legacy code. This increases quality and reliability and decreases project cost.

Work is already underway or completed to provide standard interfaces to:

The use of these common Ada 95 bindings reduces project risk by ensuring access to large amounts of COTS software. Reuse of COTS software not only reduces risk, but also increases the software’s portability and reliability. All of these risk reduction techniques have a positive net effect on the project’s cost and schedule.

Risk Mitigation Steps:

5.2.5    CASE Tool Support for Ada 95

In order to avoid schedule risk, PM Offices and Contractors/Developers must work with CASE vendors to ensure that Ada 95 supportive versions of their tool will be available in concert with project schedules. Upper CASE tools (which cover the early phases of the software life-cycle) are typically not language-dependent. Lower CASE tools (which cover the later phases of the software life-cycle) are language-dependent and need to be upgraded to effectively support Ada 95. Many of these kinds of CASE tools will either be bundled with the compilers or sold as a part of vendor-sponsored Software Engineering Environments (SEEs).

There are many CASE tools that work with Ada 83 and these tools can continue to be used with Ada 95; they simply won’t take advantage of the new features of the language. It will take some time until Lower CASE tools are modified by their vendors to both generate Ada 95 code (and/or read in Ada 95 code) and display it using a method’s notation.

Risk Mitigation Steps:

5.2.6    Upward Compatibility from Ada 83 to Ada 95

A majority of existing Ada 83 programs do not have to be significantly altered; the most common incompatibilities are automatically detected when the software is recompiled with an Ada 95 compiler. The most important upward compatibility issues have been summarized on a one page flyer that is available from the AdaIC. More comprehensive details can be found in the Ada 95 Upward Compatibility Guide V4.2.

Risk Mitigation Steps:

5.2.7    System Revalidation

As with any compiler upgrade, it is critical that measures be taken to ensure that the functionality of the system has been preserved after the transition to Ada 95.

Risk Mitigation Steps:

5.2.8    Investments in the Ada 83 Software and Tools

Current evidence suggests that the majority of Ada 83 software will be upwardly compatible and will run unchanged when compiled by an Ada 95 compiler. Of the fraction that is incompatible, the majority can be made upwardly compatible manually and by using some simple automated tools. PEOs and PMs should expect to continue using existing Ada 83 software both during and after their transition to Ada 95.

PEOs and PMs should also expect to make use of their existing investment in Ada 83 tools. These tools will be useful in the following two situations:

  1. Continue to use Ada 83 tools where appropriate _ During the process of Ada 95 adoption, there are two kinds of software that PEOs and PMs must be concerned with: Ada 83/Ada 95 compatible software and Ada 95 only software. Ada 83/Ada 95 compatible software is both upwardly and downwardly compatible and may be processed with both Ada 83 and Ada 95 tools. Ada 95 only software makes use of new Ada 95 features and may be processed only with Ada 95 tools. By maximizing the use of Ada 83/Ada 95 compatible software, PEOs and PMs can continue to make use of their existing Ada 83 tools during the transition period. As Ada 95 only software becomes dominant (i.e., as projects begin to make significant use of Ada 95), then projects can incrementally increase the Ada 95 toolsets and support.

  2. Upgrade to "next version" Ada 95 tools _ Since Ada 95 is an incremental upgrade and not a new language, tool vendors are building upon their Ada 83 toolsets and experience. As a result, many tool vendors are offering Ada 95 capabilities in the new versions of their Ada 83 tools, available under the standard maintenance license for the product. Therefore, projects which have paid for maintenance or support may be able to migrate to Ada 95 technology at a very low cost and with no loss of their investment in Ada 83 tools and environments.

    Ada 95 software needs no special effort to integrate, communicate with or call Ada 83 software. By simply compiling the Ada 83 software along with new Ada 95 code, the Ada 83 code is immediately available for reuse in the new Ada 95 environment. PEOs and PMs should, therefore, ensure that the Ada 83 code is upwardly compatible (see the previous section). Ada 95 is not a new language, it is an incremental improvement to Ada 83.

Risk Mitigation Steps:

To preserve their investment in Ada 83 software and tools, PEOs and PMs should:

5.2.9    Investments in Legacy Systems

PEOs and PMs are not expected to convert all of their legacy software to Ada 95. Instead, developers should exploit new Ada 95 features in order to interface their new Ada 95 software with the existing legacy code. This permits incremental upgrades and enhancements to be written in Ada 95, minimizing cost and project risk. Ada 95 has been designed to help projects continue to get maximum use from their legacy software as they incrementally migrate to their new language, environment and/or platforms.

PEOs and PMs should ensure that their development/contractor staff exploit Ada 95’s improved abilities to interface with software written in multiple languages. This allows for the reuse of existing legacy software and COTS software _ thereby reducing project cost and accelerating the schedule while reducing risk.

Risk Mitigation Steps:

5.2.10    Changing Software Engineering Paradigms

Ada 83 has always supported software development using Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD) methods. In addition, many projects have used Ada 83 in combination with functional decomposition methods (e.g., Structured Analysis and Structured Design or Information Engineering). Ada 95 adds new support for Object-Oriented Programming (OOP), further encouraging the use of Object-Oriented methods.

The use of object-oriented methods provides technical advantages when used with an OOPL such as Ada 95. However, if the contractor/development team is not experienced in object-oriented technology, then its use may increase project risk. If the project chooses to use an object-oriented approach, but has not previously applied one on a project, then risk is increased by adopting two technologies simultaneously. In this case, it is not recommended to transition to both Ada and OO methods at the same time.

The use of a modern software development method is critical to the success of a software development effort. It is very important that the contractor be fully trained in the selected methodology and have a well defined process and tools to support the methodology.

Risk Mitigation Steps:

PEOs and PMs must take active steps to mitigate this increased risk. These steps fall into four categories:

5.2.11    Differences in Ada 95 and Other Object Models

In addition, further risk can be experienced if the OO method is not tailored to Ada, but is based on Smalltalk or C++ (it must be remembered that although the basic OOP concepts are the same, the details of inheritance and polymorphism may differ).

Risk Mitigation Steps:

6.0    Bringing The Plan Together

At this juncture, the reader should have some understanding of:

Appendix A provides a transition plan template to help the PEO or PM get started on creating a transition plan. The PEO or PM should feel free to tailor the transition plan, by adding or removing sections, to suit their project's specific needs.

This transition plan focuses on the issues of transition to Ada 95. The PEO or PM still needs to be aware of and plan for normal project management stages (e.g., quality management, financial management, configuration management). Thus, the transition plan complements an overall project management plan for an organization.

Once the transition plan has been through a review cycle and is agreed to by management, the PEO or PM should execute the plan. Proper direction, project monitoring, and change control will help to ensure that the transition to Ada 95 is successful. If the reader desires more help or assistance in the transition to Ada 95 they can contact the Ada Joint Program Office, the Ada Information Clearinghouse, or their Ada compiler and tool vendors. Additional resources are provided in Appendix B.

Next Section - Appendices (A, B, C, and D)

Table of Contents