4.0    Identifying the Ada 95 Transition Activities

Once the transition needs assessment is completed, PEOs and PMs can begin to identify the activities that are most appropriate for their program needs. This section addresses four distinct transition scenarios, each addressing the technical activities, management activities, timing issues, and the associated risks for the scenario. PEOs/PMs need only review the sections that pertain to their specific situation to develop a set of transition activities for their effort. These scenarios, along with their respective section, are listed below:

For each scenario, the process of identifying an organization's specific activities for the transition involves four steps as shown in Figure 4-1. Using the guidance provided in this section, PEOs/PMs will concurrently identify technical and management activities that will be critical in establishing the direction and intent of the transition effort. These activities are then measured against timing criteria to determine if they are appropriate for the current life cycle phase of the program. Depending on the program's life cycle phase, a PEO/PM may elect to postpone or otherwise alter the transition activities that were defined in the previous two steps. The results of all three steps are analyzed to obtain a complete understanding of the associated risks. These risks are studied in the processes discussed in Section 5 to assess their impact and develop appropriate mitigation strategies.

Figure 4-1. Identifying the Transition Activities

Based on the results of the needs assessment completed in Section 3, PEOs/PMs may need to supplement the activities presented in this section with additional technology transition activities that are more general in nature (e.g., developing detailed training plans, developing an acquisition plan, creating a transition project WBS).

Guidance is provided to assist the PEO/PM in documenting the technical and management activities in Sections 4.1 and 4.2 of the template. Table 4-1 provides an example of how a PEO/PM completes the template sections for a sample technical activity. This approach can also be used to document management activities. The technical and management activities and their associated tasks are provided for each transition scenario. The program constraints are specific program requirements and must be developed by the PEO/PM in accordance with their transition effort.

Table 4-1. Sample Technical Activities

The PEO/PM may begin populating the risk matrix in Section 5.1 of the template with the appropriate timing and program risks identified for each transition scenario. Table 4-2 provides an example illustrating how a PM/PEO begins documenting the sample risks.

Table 4-2. Sample Program Risks


4.1    Conducting an Ada 83 to Ada 95 Transition

The transition to Ada 95 from Ada 83 is the most straightforward transition type presented in this guide. It involves the lowest risk and the fewest technical challenges. Table 4-3 provides a summary of the recommended technical and management activities presented for this transition type.

    

Table 4-3. Ada 83 to Ada 95 Activity Summary

4.1.1    Defining Technical Activities

The Ada 83 to Ada 95 transition is a relatively simple process, similar to upgrading to a new compiler version. The major activities, as listed in Table 4-3, are:

Each of these activities are described in the paragraphs that follow. Refer to Table 4-1 for an example of how defined technical activities should be added to the transition planning template in Appendix A.

Compiler availability and maturity should be monitored by PEOs/PMs before any acquisition is made. Core language throughput, performance, and code quality and correctness are desired for all projects; managers should evaluate the maturity of these basic 95 features. Use of the Ada 95 annexes may be the motivating factors for the transition to Ada 95, but vendors will not initially supply all of the annexes. Consequently, PEOs/PMs need to work with their prospective vendors to ensure that the features of the language critical to the transition effort will be supported in a timeframe that meets the program's requirements. Compiler maturity can bemonitored in several ways. The following test suites all provide value in measuring a compiler's capabilities:

The AJPO validation process of the candidate compiler should be monitored to ensure that the minimum validation requirements are satisfied. The ACVC addresses standards compliance. Managers should also check with vendors to assess results of the ACES and other compiler tests such as the PIWG compiler evaluation benchmarks sponsored by ACM SIGAda. If the compiler has passed these tests, the manager can request an evaluation copy of the compiler, and then recompile their Ada 83 code with the Ada 95 compiler. The PM should review vendor release schedules to ensure timely availability and to assess the resulting impact on the project schedule.

Another issue associated with the maturity of Ada 95 compilers and tools is the availability of bindings. The availability of Ada 95 compatible bindings should be reviewed with each potential vendor. Interfaces such as those to SQL, GUIs, and POSIX (available from the AdaIC bindings list) and those to specific hardware should be investigated for compatibility with the Ada 95 compiler, particularly when changing vendors. Costs can be incurred if existing interfaces need to be replaced or redeveloped to be compatible.

When compilers and bindings are approaching an acceptable level of maturity, acquisition options can be more fully explored. In most cases, compilers can be acquired through an organization’s existing Ada vendor. Most Ada 83 vendors plan to supply an Ada 95 migration package to simplify the upgrade process. Managers should work with vendors early on to communicate their technical and scheduling needs. Alternatively, a compiler can be acquired from another vendor offering a more convenient release schedule. However, there is a risk that Ada code compiled by one vendor’s compiler may not compile error-free with another vendor’s compiler.

After the selected compiler has been acquired, installed, and tested, developers can begin to rebuild the systems by recompiling their Ada 83 code with the Ada 95 compiler. Migration packages include diagnostics to allow detection of incompatibilities. The few incompatibilities between Ada 83 and Ada 95 (see the Adoption Handbook for full treatment) must be fixed manually. Software resulting from the resolution of upward incompatibilities must be retested to verify its functional validity and to ensure that the system meets performance requirements. A more detailed discussion of the upward compatibility risk is included in Section 5.2.6.

Optional Technical Activities:

Some PEOs/PMs may want to use new object-oriented (OO) features or the annexes after converting to Ada 95. This involves new development with associated schedule and cost requirements, as well as staffing and training considerations. While it is possible to address boththe language change and the use of new features simultaneously, it is recommended that these steps be conducted separately to minimize the risk associated with the introduction of excessive change.

4.1.2    Defining Management Activities

At the same time that technical activities are being identified, PEOs/PMs can begin defining management activities required to support the transition effort. A distinction is made between in-house and contracted efforts with respect to the required management activity. The transition management activities listed in Table 4-3 for both in-house and contracted efforts are relatively simple for the transition from Ada 83 to Ada 95. Refer to Table 4-1 for an example of how defined management activities should be added to the transition planning template in Appendix A.

In-house Transition Management Activities:

Management activities include identifying staff to perform the technical activities described, identifying and providing training as needed, and managing the transition technical activities using general program management guidelines. Managers should also allow for adequate testing time for both the compiler and realated tools and the application software in the transition schedule.

Contracted Transition Management Activities:

The PM needs to identify and select a contractor to perform the transition process, and must monitor the contractor to ensure an adequate level of performance and to verify the validity of resulting Ada 95 products. Guidance on selecting a contractor can be found in the Ada 95 Adoption Handbook.

4.1.3    Considering Timing Issues

After all technical and management activities have been defined for the transition effort, they must be balanced against the life cycle implications of their performance. Transitioning Ada 83 to Ada 95 is feasible for many projects no matter what phase of the life cycle the project is in, but there are different levels of risk involved. One risk is a function of whether new features or annexes are being used. If a system is already being tested or deployed in Ada 83 anddevelopers are not using special 95 features, then there is low technical risk in transitioning to Ada 95 at any time. If new features or annexes are utilized, then cost and scheduling risk is involved. Generally, transitioning to Ada 95 is least risky in the early phases of the system development life cycle and in the deployment phase; transition to Ada 95 is recommended during these phases. The greatest cost and scheduling risk is incurred when a change is made in the middle of the development cycle. In such cases, design and development must be revisited, sometimes with a significant impact on cost and schedule.

Training needs differ based on the life cycle phase the system is in. A transition to Ada 95 during the early life cycle phases may necessitate Ada 95 development training. A transition during deployment may require minimal maintenance training or no training at all. Training needs are higher for developers when the transition is conducted early in the life cycle. Training needs are lower after the development phase is complete.

All timing-related risks should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.

4.1.4    Identifying Risks

It is important that PEOs/PMs understand the risks associated with the defined activities and life cycle phase of their effort. Having defined the approach to be followed in executing the transition to Ada 95, PEOs/PMs must now identify and document all known risks so that the associated impacts can be assessed and appropriate measures taken to minimize their effect. Some of the more prominent risks involved in the transition from Ada 83 are discussed in the following paragraphs.

Ada 95 Feature Availability: Program Managers should be proactive and consult with their Ada 83 compiler vendors to let them know what Ada 95 features are needed. This tactic ensures availability of desired features and minimizes cost and incompatibility risks involved in going to a different vendor for the needed features.

Compiler/Tool Maturity: There is low technical risk involved in transitioning from Ada 83 to Ada 95, but there are cost risks involved in compiler and tool upgrade investments . Testing and revalidation take time, so there are potential scheduling risks involved there as well. These risks can be mitigated by timing the transition to coincide with full availability and maturity of the compiler, interfaces, and tools.

All activity-related roles should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.


4.2    Conducting a Procedural Language to Ada 95 Transition

PEOs/PMs may migrate their existing systems from another procedural language to Ada 95. This scenario most often occurs when major system upgrades are due or when new requirements arise that are best satisfied with an Ada implementation. Table 4-4 provides a summary of the recommended technical and management activities presented for this transition type.

    

Table 4-4. Procedural Language to Ada 95 Activity Summary

4.2.1    Defining Technical Activities

The activities presented for this transition type include two checkpoints during which the PEO/PM needs to make a decision between Ada 83 and Ada 95 depending on the maturity and functionality of existing Ada 95 compilers. Table 4-4 lists the major transition activities from a procedural language to Ada 95. They are:

Each of these activities is described in the paragraphs that follow. Refer to Table 4-1 for an example of how defined technical activities should be added to the transition planning template in Appendix A.

Ada 95 compiler availability and maturity should be monitored by PEOs/PMs before any acquisition is made. Core language throughput, performance, and code quality and correctness are desired for all projects; managers should evaluate the maturity of these basic 95 features. Use of the Ada 95 annexes may be the motivating factors for the transition to Ada 95, but vendors will not initially supply all of the annexes. Consequently, PEOs/PMs need to work with their prospective vendors to ensure that the features of the language that are critical to the transitioneffort are supported in a timeframe that meets the program's requirements. Compiler maturity can be monitored in several ways. The following test suites all provide value in measuring a compiler's capabilities:

The AJPO validation process of the candidate compiler should be monitored to ensure that the minimum validation requirements are satisfied. The ACVC addresses standards compliance. Managers should also check with vendors to assess results of the ACES and other compiler tests such as the PIWG compiler evaluation benchmarks sponsored by ACM SIGAda. If the system has interfaces, the PM should require an interface investigation to ensure that the Ada 95 compiler supports required hardware and software interfaces. This information is best acquired by working with the individual Ada compiler vendors. In addition, the PEO/PM should review vendor release schedules to ensure timely availability of required features and to assess the resulting impact on the project schedule.

Based on the results of their analysis, PEOs/PMs need to determine whether to make the transition directly to Ada 95 or to follow an incremental approach by first moving to Ada 83. The incremental approach reduces risk by employing mature and proven compilers/tools and by coding in Ada 83 so that the ultimate transition to Ada 95 is as smooth as possible. PEOs/PMs can ensure upward compatibility of Ada 83 development with Ada 95 by implementing, at project onset, the guidelines established by Erhard Ploedereder in his paper "How to Program in Ada 9X Using Ada 83", available through the Ada Information Clearinghouse.

Once a suitable Ada 83 or Ada 95 compiler has been acquired and installed, the selected transition approach can be executed. Regardless of whether the PEO/PM chooses to move to Ada 83 or 95, the use of pilot projects should be considered. These projects allow users to gain experience in Ada and can also be used by experienced programmers to ensure that there are no significant obstacles to fulfilling complex system requirements in Ada. (At this point, if the PEO/PM chose to begin with Ada 83, then the maturity of the Ada 95 compilers should be revisited. This verification step may result in cost and schedule saving.)

Once the pilot project is finished and sufficient experience obtained, the transition can be broadened into the entire system or into organization-wide transition projects using traditional transitioning techniques such as reengineering or conversion. Reengineering and conversion techniques include non-Ada specific issues that should be considered when re-implementing any system. The Software Reengineering Process Model, published by the DISA/CFSW Software Systems Engineering Directorate, provides excellent guidance on these issues.

If the decision is made to initially implement the system in Ada 83, the PEO/PM can follow the guidance presented in Section 4.1 to conduct a subsequent transition to Ada 95.

4.2.2    Defining Management Activities

At the same time that technical activities are being identified, PEOs/PMs can begin defining management activities that are required to support the transition effort. A distinction is made between in-house and contracted efforts with respect to the required management activity. The program management activities listed in Table 4-4 for in-house and contracted transition efforts are more challenging for the transition from a procedural language to Ada 95 because there are more technical activities to manage with commensurate scheduling risks and costs. Refer to Table 4-1 for an example of how defined management activities should be added to the transition planning template in Appendix A.

In-house Transition Management Activities:

Personnel and technical management activities are key to ensuring transition success from another procedural language to Ada 95. Program managers must be familiar with their staff's technical capabilities so that they can effectively identify key personnel to perform the transition activities, identify training needs, and provide training.

The development staff will benefit from training in Ada 95. (See the Adoption Handbook for full treatment of Ada 95 training.) Managers should realize that the paradigm shift involved in switching from another procedural language to Ada can be time-consuming and difficult for some programmers. For example, Ada uses data encapsulation and hiding of implementation details; unlike COBOL that openly displays such details at high levels.

The program manager needs to provide technical oversight of the transition to control the transition and to ensure product viability. This can be done by using expert consultants at significant checkpoints or throughout the effort. Consulting with Ada 95 Starter Teams for their insights and assistance should also be considered.

Contracted Transition Management Activities:

If in-house staff are unavailable to perform the transition tasks, the PM needs to identify a contractor to perform the transition process. This can be done by reviewing contractors' priorexperience and by requiring contractors to perform a pilot transition project on a critical subset of the system to demonstrate their capabilities.

The PM needs to ensure that contracted staff capabilities are equal to the technical challenges of the transition. This can be done by reviewing proposed staff capabilities for experience that demonstrates effective Ada usage, requiring training of contracted staff as needed, and considering incentive awards to motivate contractor personnel.

The PM needs to monitor the contractor to ensure technical performance and validity of resulting Ada 95 products. An independent verification and validation of the transition should be considered, particularly for complex transition efforts.

The PM should also consider placing some of the in-house technical staff on the transition team to learn Ada and to facilitate future maintenance or new Ada development.

4.2.3    Considering Timing Issues

After all technical and management activities have been defined for the transition effort, they must be balanced against the life cycle implications of performing them. Generally, the transition to Ada is recommended during the early or post-deployment phases of the system life cycle.

In-house Timing Considerations

Transitioning to Ada 95 from another procedural language is feasible throughout all phases of the life cycle, but the cost and scheduling risks incurred vary depending on the development life cycle phase of the project. Generally, cost and scheduling risk increases as the process progresses because previous analysis and design decisions must be revisited to effectively incorporate the use of Ada features. Table 4-5 summarizes the timing considerations for these transitions.

    

Table 4-5. Procedural Language In-House Transition Timing Considerations


Contractor Timing Considerations

The effects of transitioning to Ada 95 from another procedural language during the four major phases of the contracted software acquisition process are summarized in Table 4-6. Generally the transition cost, schedule, and technical risk increases as the procurement effort proceeds because previous efforts have to be reworked or duplicated to incorporate Ada.

    

Table 4-6. Contracted Transitions - Timing Considerations
for Procedural Languages

Risk mitigation is the same whether the transition is an in-house or contracted effort:

All timing related risks should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.

4.2.4    Identifying Risks

It is important that PEOs/PMs understand the risks associated with the defined activities and life cycle phase of their effort. Having defined the approach that will be followed in executing the transition to Ada 95, PEOs/PMs must now identify and document all known risks so that the associated impacts can be assessed and appropriate measures can be taken to minimize their effect. Some of the more prominent risks involved in the transition from procedural languages are discussed in the following paragraphs.

Legacy System Investments: One lower risk transitioning method involves the use of software wrapping techniques that help to preserve the investment in legacy software. Using this technique an Ada shell is developed, acting as the interface between the legacy code (which ispreserved intact) and the Ada compiler. Ada 95 has new features, including pragma interfaces and standard interface definitions to C, Fortran, and COBOL that make the wrapping alternative cost-effective and quick. This technique is detailed in the Ada 95 Adoption Handbook, and in other sources available through the Ada Information Clearinghouse.

COTS/OS Interfaces: Interfaces may exist between the procedural language and other software languages, and hardware modules. Interfaces should be investigated with the compiler vendor to ensure that they will be supported with the Ada compiler. Alternative interface sources can be identified through the Ada Information Clearinghouse, but the manager should be aware that interfaces will work with the least risk if developed by the same compiler vendor.

Tool Maturity: Availability, schedule, and maturity of Ada 95 tools should be monitored. The Ada compiler comes with a basic toolset, such as a linker and a debugger. Other tools, such as a source code analyzer, language sensitive editors, and CASE tools may not be initially available from vendors. Existing Ada 83 source code analyzers need to be upgraded to work with Ada 95. Language sensitive editors providing templates for Ada 95 developers also need to be upgraded, if developers are using the OO features and annexes. CASE tools also need to be upgraded to accommodate Ada 95 redesign and new development. Vendors will likely provide a cost-effective upgrade policy for their existing tools or managers can seek competitive products from other vendors. PEOs and PEOs need to assess costs and monitor the availability, performance, and features of Ada 95 tools before investing in them.

Differences in Real-time Models: Developers transitioning from another real-time language/system will need to learn the Ada 95 real-time methods. Analysis is needed is to map the existing real-time model to Ada 95 methods. Performance is an issue involved in transitioning any real-time system. Benchmarks testing speed, performance, and proof of concept ensure adequate performance and should be considered as a transition requirement.

Changing Paradigms: There are issues of transition from any procedural language to any OO language that are language-independent. A paradigm shift is required when moving from procedural to object-oriented techniques. PMs need to be aware that such a shift requires an investment in time and training to be successful. Performance is also an issue when implementing object-oriented systems. Benchmarks testing viability are recommended.

All activity-related roles should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.


4.3    Conducting a Fourth Generation Language (4GL) and 3GL to a 4GL and Ada 95 Transition

Many 3GLs, such as Ada, co-exist with and supplement 4GLs. These 3GLs do not communicate directly with the 4GL, but instead use a "middle-ware" or wrapping approach to perform the communication with the 4GL. This section is divided into two categories: those in which Ada 83 is currently being used and those in which another 3GL is being used. For those systems that plan on expanding their use of 4GL calls to/from Ada, the transition to Ada 95 simplifies use of the middle-ware, making the development and maintenance of existing and future calls easier. Table 4-7 provides a summary of the recommended technical and management activities presented for this transition type.

The majority of activities presented in this section duplicate those activities discussed in Sections 4.1 and 4.2. The reader is directed to the guidance provided in these sections to begin a transition of this type.

    

Table 4-7. 4GL/3GL to 4GL/Ada 95 Activity Summary


4.3.1    Defining Technical Activities

The technical activities recommended for this type of transition follow those outlined in Sections 4.1.1 and 4.2.1 for Ada 83 and procedural language transitions, respectively. These specific activities are supplemented with two additional activities involving recoding and retesting the 4GL interface. The activities for each case are listed below:

Ada 83 to Ada 95

Other Procedural Language to Ada 95

The first step involved in this type of transition is to perform the activities that would be required in a standard language transition. Once this has been completed, the required 4GL interface must be redeveloped in Ada. The system must then be retested to ensure that the new code is functionally viable and that the interface between the Ada code and the 4GL is working correctly.

Refer to Table 4-1 for an example of how defined technical activities should be added to the transition planning template in Appendix A.

4.3.2    Defining Management Activities

Management activities are similar to an Ada 83 or other procedural language transition to Ada 95 with the addition of management and oversight of the interface development between Ada and the 4GL. Refer to Sections 4.1.2 and 4.2.2 for guidance specific to Ada 83 and procedural language transitions, respectively.

In-house Transition Management Activities

The technical activities involved in recoding the interface between Ada 95 and the 4GL must also be managed as part of the technical management activities.

Contracted Transition Management Activities

A contractor should be selected with the appropriate Ada 83 (or other 3GL), 4GL and Ada 95 experience. Contractors need access to existing software, including the application software, interface and 4GL software, and the operating environment as needed for developing, testing, and implementation purposes.

Refer to Table 4-1 for an example of how defined management activities should be added to the transition planning template in Appendix A.

4.3.3    Considering Timing Issues

There are no special life cycle timing considerations due to the 4GL component. Generally, transitioning in the early or post-deployment phases of the system life cycle is recommended. Refer to Sections 4.1.3 and 4.2.3 for guidance specific to Ada 83 and procedural language transitions, respectively.

All timing related risks should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.

4.3.4    Identifying Risks

The 4GL component introduces no additional risks to the transition as long as sufficient testing is conducted to ensure that the functionality of the interface has been maintained. Refer to Sections 4.1.4 and 4.2.4 for guidance specific to Ada 83 and procedural language transitions, respectively.

All activity related roles should be added to the risk matrix in Section 5.1 of Appendix A. Table 4-2 provides an example.


4.4    Conducting an Object-Oriented (OO) Language to Ada 95 Transition

PEOs/PMs may be interested in migrating their existing systems from another object-oriented language to Ada 95 to take advantage of Ada's inherent software engineering principles. Table 4-2 provides a summary of the recommended technical and management activities presented for this transition type.

    

Table 4-8. OO Language to Ada 95 Activity Summary

4.4.1    Defining Technical Activities

The technical aspects of the transition from other object-oriented languages to Ada 95 is relatively straightforward. If the development staff is familiar with OO techniques, then they only require instruction on the specifics of the Ada 95 object model and on the syntax of the Ada language. The transition activities listed in Table 4-8 are summarized below:

Refer to Table 4-1 for an example of how defined technical activities should be added to the transition planning template in Appendix A.

Ada 95 compiler availability and maturity should be monitored by PEOs/PMs before any acquisition is made. Core language throughput, performance, and code quality and correctness are desired for all projects; managers should evaluate the maturity of these basic 95 features. Use of the Ada 95 annexes may be the motivating factors for the to transition to Ada 95, but vendors are not initially supplying all of the annexes. Consequently, PEOs/PMs need to work with their prospective vendors to ensure that the features of the language that are critical to the transition effort are supported in a timeframe that meets the program's requirements. Compiler maturitycan be monitored in several ways. The following test suites all provide value in measuring a compiler's capabilities: