The Funds Management Modernization System (FMMS) consists of the modernization of Secretary of the Air Force, Funds Management SAF/FM Headquarters (HQ), Major Command (MAJCOM), and installation-level funds management systems. FMMS is first of several phases planned to modernize the entire Air Force budget systems environment. The overall set of modernization phases is referred to as the Future Budget System (FBS).
FMMS will build upon the business process re-engineering of the Planning, Programming and Budget System (PPBS). FMMS will track the chronology and funds management of all Air Force money from initial Presidential budgets through final disbursement to the work centers. FMMS will be deployed in parallel with the existing system for concurrent use.
FMMS will re-engineer a series of legacy Management Information Systems (MIS) into a single, comprehensive system. The re-engineering effort will include migration from character-based interfaces executing on RS6000s and Unisys 2200s to Graphical User Interfaces (GUI) executing in a client/server environment consisting of microcomputers running MS-Windows and workstations running UNIX.
The planned implementation strategy will utilize an iterative software development model for FMMS. The current plan requires three major releases during the life of the project. These incremental releases are composed of the following phases: training, analysis, design, implementation and testing. Formal training will be supplemented with Ada 95 mentoring activities during all phases of each release on an as-needed basis. The project is currently in the implementation phase of the first incremental release.
The Single Agency Management for Pentagon Information Technology Services, Air Staff Systems Directorate, PPSB Support Division (SAM-GAP) team is responsible for the project. They are supported by mentors supplied by the Ada Joint Program Office (AJPO). The mentors provided Ada 95 expertise and transition support.
FMMS is an AJPO Ada 95 early adopter project. The FMMS project will stress the Ada 95 tools and environment to find strengths and weaknesses. This report provides enumeration of those findings, which were ascertained during the first incremental release.
A majority of the issues identified during the development effort did not result from the choice of programming language. Rather, they were the typical issues seen on any project that implements new technologies. Many lessons have been learned. Some were new to the team and the mentors, while others confirmed long-held software engineering maxims. The following summarize the major lessons learned while supporting this project:
- Ada 95 has been successfully used to demonstrate the proposed system.
Ada 95 binding to OLE and Win32 is feasible and practical.
- Utilization of CORBA via the OIS IDL-Ada 95 compiler is feasible and practical.
- Interfacing to SYBASE via OIS ODBC bindings is feasible and practical.
- Rational APEX interfacing to GNAT is feasible and practical.
- A mapping can be, and has been developed from Rational's Object-Oriented Software Engineering (ROSE) tool to an Ada 95 implementation.
- Mentoring support was essential for success through all phases of the project.
- Many of the challenges the project faced can be directly traced to the need to adopt multiple technologies simultaneously. The same was true for integrating multiple tools.
- Tool maturity can foster a mind-set, which can enhance or impact good software engineering.
- Tool maturity can impact delivery schedules.
- Tool requirements and possible tool alternatives must be identified prior to initial development.
- Continuous access to domain experts and end users must be provided.
2.2 Project Introduction and Overview
The "current system" is actually an aggregation of several automated systems and manual processes. The headquarters (HQ) Chronology, Funds Baseline, Funds Release, and Reprogramming systems will be modernized, along with the Command Budget Automated System, Increments II and IV (CBAS II and CBAS IV) at the Major Command (MAJCOM) and installation levels.
Over the years, the legacy systems that support the current system evolved into "stove-piped" systems. Often, communication between these systems, as well as any consideration of common data elements, were added as an afterthought. Over the years, these systems have been transitioned between databases, programming languages, operating systems, and hardware platforms. As requirements continue to evolve, the resulting morass of code is inflexible, brittle, hard to understand, and difficult to modify. To some extent, the business processes held captive by these inflexible systems have been driven 'cart before the horse' into inefficiency.
The legacy systems that will be made obsolete by the modernized system exist to meet mandatory requirements given by the Office of the Secretary of Defense (OSD) and Congressional reporting requirements, as well as to comply with the law. Therefore, requirements for these systems are derived from OSD and Congress. These requirements are subject to change with very short timelines for compliance.
FMMS will replace the following four HQ legacy systems: Chronology, Funds Baseline, Funds Release, and Reprogramming; and the MAJCOM legacy systems: CBAS Funds Control components. These systems may be regarded as the major system components of the HQ and MAJCOM legacy Funds Management system.
The software system is under development by SAM-GAP personnel. Many of the staff members have had previous Ada 83 programming experience or training. The software development began in early January 1996, followed by two weeks of Ada 95 training in late January. Primary development of the first release occurred from February 1996 and is still ongoing.
This section lists major goals of the project sponsors and an analysis of the accomplishments in that area.
- Streamline efficiency because data entered at one level will be available electronically at all levels.
The main streamlining effort will be at the single point of data entry. Four legacy systems will be phased out and FMMS will take their place.
The funds' modernization effort provides an excellent opportunity to improve the automated budget system, as well as improve current functional budget processes.
"Functional Process Improvement" and "Business Process Re-engineering" will be conducted for budget functional areas.
Functional process improvements submitted by customers to improve processes will be implemented, if they are possible.
Reusable software assets will be produced and incorporated.
- Exploit the benefits of modern technology.
FMMS will take advantage of the efficiency enhancements offered by modern technology to include, but not be limited to, client/server architecture, a "Windows" type environment, integration with state-of-the-art commercial off-the-shelf (COTS) software, and on-line help facilities.
The system software must operate in an open systems, client/server environment, and must be GUI-based.
Two distinct categories of software exist: all software is PC Windows-based for the client, and all software is UNIX-based for the server.
FMMS will also be more readily able to incorporate new hardware/software/database technology to reduce dependence on a particular vendor.
- Improve the reliability and maintainability of the FMMS code.
Replacement of the transformational process with an additive, iterative progression strategy.
Lower software maintenance costs. The new system is implemented in Ada 95. This eliminates the need for multiple language maintenance and the accompanying reliability problems. Additionally, an effort was made during development to exploit the Ada 95 features which enhance reliability (e.g., strong typing) and enhance the inherent readability of Ada code with thorough comments and documentation.
Rational Object-Oriented Software Engineering (ROSE) and Rational APEX are being utilized to capture design and implementation information. These tools comprise a common software engineering workbench. Both tools support the Object-Oriented facilities of Ada 95.
- Interfaces between classified and unclassified systems.
A one-directional exchange of data between the future unclassified to classified Funds systems is required. Transferring data from an unclassified to a classified system will allow an automatic interface since no classified data is enroute.
- Interfaces between FMMS and external systems.
Data transfer will occur periodically between the FMMS and external systems.
- Quicken the maturity of Ada 95 tools.
FMMS utilizes Rational APEX/ROSE tools to assist the software designers and implementors.
The project contributed to the maturity of the GNAT compiler by exercising an extensive list of the new features of Ada 95.
This project helped to highlight the current deficiencies in tool support for X-based GUI development. Object-Ada 7.0 GUI-Builder is still immature.
- Demonstrate the applicability of Ada 95 to distributed client/server architectures.
OMG CORBA IDL is converted to Ada 95 via the OIS Orbix product.
OLE is utilized as an interface mechanism to the office automation suite.
ODBC acts as an intermediary to the SYBASE database engine.
- Show the usage of Ada 95 in COTS integration.
Security measures will be implemented using Ada 95 interface capabilities to the Fortezza COTS product, which is written in C.
- Multiple Site Development.
Multiple site development has not started yet. Some of the designers and programmers have had Ada 95 training and have utilized the development environment at HQ.
- Usage of Ada 95 in Information Systems Support.
Utilization of the Information Systems Annex F has not occurred. This usage will probably occur when multiple-site development begins.
- Portability.
The IBM PC compatible target compiler is ObjectAda 7.0, which is currently in beta release. This compiler is rudimentary at present. GNAT 3.04a is now used in the software development on the PC-based platforms.
The UNIX platform uses Rational APEX, with Rational Ada being the target compiler. The Rational Ada compiler is currently not available. Therefore, Rational APEX uses GNAT 3.05 via its Remote Compiler Integrator 1.6.1B tool.
Portability issues have not been fully addressed yet, because the target compilers are not available. Different versions of GNAT are used on both the PC and UNIX platforms. These different versions have not caused any appreciable impact.
A transition from the GNAT compiler to the respective target compilers will take place later in the project development cycle.
Discussion
An object-oriented development methodology is being used, and Ada 95’s features are being exploited wherever they provide benefits. The object-oriented approaches are enforced with a variety of products. The principal products are from Rational Inc.
A significant number of new Ada 95 features are being used in the project. These include:
- Subprogram Access - The OLE implementation required callbacks, which were implemented using the subprogram access feature of Ada 95. The Visual Basic screens were prototyped using OLE and Ada.
- Hierarchical Library Units — The major portions of the system were created as object-oriented “subsystems”, as described by Grady Booch. These real-world high-level abstractions were easily reflected in the software by the use of Ada 95 package hierarchies. Often, the package hierarchy reflected the tagged type’s inheritance hierarchy. Partitioning the system into subsystems reduces compilation time. Hierarchical library packages may be generated from the object diagrams in the Rational ROSE model.
- Tagged types - Ada 95's object-oriented programming (OOP) capabilities are provided by "tagged types". These were heavily used in implementing the “common selection criteria” software. Tagged types are the default data type generated by the Rational Rose tool. The designer has the option of overriding this default by selecting other Ada data types.
- Aliased types, 'Access attribute, and Access parameters - Used to acquire memory pointers to static data or pass references to the data to other Ada units. Use of these facilities included interfacing to COTS software and, most prominently, to the ODBC bindings.
- Class-Wide Programming - Class-wide dispatching of objects in the OOP.
- New String Packages - Several new string manipulation facilities of Ada 95 were used in the system, most notably the unbounded strings.
- Pragma Import - This pragma allows access to existing code written in languages other than Ada. External routines for connecting and communicating with the Fortezza system are to be accomplished via this pragma.
- Interfaces.C - This package and its child packages provide appropriate types and operations to facilitate the inclusion of C functions in an Ada 95 program. In the past, more difficult, non-portable, compiler-specific solutions were often required to achieve multiple language interfacing.
Lessons Learned
- Ada 95 is a stable technology.
Ada 95 training and mentoring have reduced the number of Ada 95 issues. A primary factor in the success of the first development cycle is the Ada 83 experience of key members of the development team. Any Ada 95 issues can easily be resolved with ongoing mentoring in the development cycle.
- The lack of a debugger complicates the development process.
Primitive methods of debugging are being used by the development staff. The adding of Ada.Text_IO messages hampers the time it takes to debug a relatively simple problem.
Discussion
Eight full-time Ada 95 developers are currently assigned to the FMMS project. Five of the eight developers are SAM-GAP personnel and the remaining three Ada 95 developers are provided by a contractor. All of the developers had some experience with Ada 83 and object-oriented development. Additional development staff are currently assigned to database, security, and other support issues.
Lessons Learned
- Staff turnover requires coordination and planning.
Staff turnover has been a constant challenge to the project, primarily due to the use of Department of Defense military personnel. This situation highlights the need for adequate project documentation. Also, the use of an integrated software engineering environment is essential to maintain consistency.
- Staff turnover requires constant evaluation and mentoring.
The constant replacement of members of the development staff with new personnel having disparate backgrounds causes many problems for the project. Each new member arrives with a different level of expertise ranging from extremely light programming experience with little Ada knowledge to extensive programming experience with a full understanding of Ada. These problems are further complicated by the fact that no further formal Ada training is scheduled. It is the mentor's responsibility to evaluate the background and capabilities of new personnel and to maintain a consistent and complete understanding of the technology throughout the team. This is accomplished through one-on-one discussions, short presentations, suggested readings, and continuous question and answer sessions.
- Maintaining the team's skill set is vital in the face of constant staff turnover.
The one advantage of the team being composed partially of military personnel is that team rotation schedules are known in advance. Since each team member has a unique set of technical skills, it is easy to look ahead and plan for the loss of a particular skill set. One method used to mitigate the loss of team skills to a planned military rotation or retirement is to ensure that each military member of the team is paired with a civilian contractor. This helps to ensure a smooth transition and prevent the loss of important technical skills.
Discussion
The first Ada 95 training was provided in late January 1996 at the CACI Pender site by Mr. Pat Rogers of Software Arts and Sciences. The training lasted one week and was attended by members of the development staff with prior Ada experience.
A second class was provided by C.J. Kemp and Associates and was targeted toward those members of the development staff with no Ada experience. This class was two weeks in duration and covered the entire Ada 95 language. In addition to the development staff, the two-week class was also attended by management and support staff.
The instructors and students were both pleased with the training experience and the resulting competence gained from the training periods.
Once the Ada 95 training was complete, a one-day overview of Object Oriented Development with Ada 95 was presented by Mr. Brad Balfour of CACI. This was intended to assist the developers in bridging the gap between understanding Ada 95 syntax and semantics and being able to implement an Object-Oriented solution in the Ada 95 language.
Lessons Learned
- Ada 95 training must match the educational needs of the students.
The focus of Ada 95 training courses varies greatly. It is essential to choose an appropriate class. For the FMMS project it was determined that two distinct groups of developers existed. One group had previous Ada 83 and object-oriented experience and the other had no Ada experience. Two different classes were provided, with different perspectives:
- The application developers with no Ada 83 experience attended the Ada 95 class for non-Ada programmers.
- The application developers with Ada 83 experience attended the Ada 95 class for Ada 83 programmers.
- Additional training must be provided when required.
This project benefited greatly from instruction in the OIS CORBA IDL. The developers had not used this environment before and training shortened the learning time required to begin full-scale development.
Training should be provided in the code generation aspect of Rational ROSE. This would allow the users to tweak the model to produce the code necessary for optimal implementation.
- Ada 95 training is not sufficient to produce an object-oriented Ada 95 programmer.
Most, if not all, of the currently available Ada 95 classes are at the basic level of describing the syntax and sometimes the semantics of the language. Few courses deal with designing solutions using Ada 95 and discussions of trade-offs among language features is rare.
Discussion
Full-time on-site mentoring was provided for the duration of the project. The mentoring effort began in December 1995 with a visit to SAM-GAP to gather information needed to develop the Ada 95 transition plan and project schedule. During late December and early January 1996 the transition plan was developed and arrangements were made to provide Ada 95 training for the project. On-site mentoring support at SAM-GAP began in mid-January and will continue for the duration of the project.
Mentoring activities included the following: assisting with object-oriented analysis and design; providing a mapping from, and object-oriented design to, Ada 95 language constructs; assisting with design and code reviews; evaluating tools; providing formal lectures on Ada 95 and object-oriented topics; leading informal discussions; researching topics; reviewing presentations; and identifying potential areas of reuse.
Lessons Learned
- Ada 95 mentors were essential to mitigating the risk of Ada 95 introduction.
All of the developers had been provided with Ada 95 training. Some of the developers had had prior Ada 83 programming experience. Nonetheless, the mentors were essential in working with the development team to produce an object-oriented Ada solution. Two areas seemed to require the most assistance. (See also the Lessons Learned regarding Training.)
- The first was the gap between object-oriented design and an appropriate Ada implementation.
- The second was the task of evaluating the trade-offs between potential Ada implementations.
These issues were not addressed in the Ada training the team received. With mentoring assistance, the team was able to quickly overcome both problems after being shown potential solutions. This indicates that the raw talent was present, but that specific, detailed instruction was essential to progress.
- Mentoring support must match the needs of the project.
Two distinct levels of Ada proficiency were identified following the completion of Ada 95 training.
- The group with prior Ada experience required much less attention from the mentors and were very productive with minimal intervention.
- The group with no prior Ada experience required more intense mentoring including formal presentations of material that was either missed in class or was covered in too little detail. This second group was then given a series of exercises to ensure a complete understanding of the language.
2.8 The Development Environment
Discussion
The hardware development environment consists of a PC with Windows NT version 3.51 and a Sun SPARC workstation for each developer. The Sun SPARC workstations are either a Sun SPARC 5 or Sun SPARC 10, and are the platforms for the UNIX development. The data server is a Sun SPARC 1000. The Sun Solaris Common Desktop Environment version 1.0.1 provides the developers an interface to the UNIX operating system.
The UNIX software development environment includes the following:
- GNU GNAT 3.05 Ada 95 compiler.
- OIS Ada Connect 2 provides ODBC functionality.
- OIS Orbix Ada (Beta) is the Ada 95/CORBA IDL connection.
- Rational APEX 2.0.8D is the syntax-driven editor. Bundled with APEX are the following tools:
- Rational Asis / Asis95 1.6.1 D,
- Rational Coverage Analyzer 1.6 A, and
- Rational RCI 1.6.1 B.
- Rational Ada Analyser 2.0.1.
- Rational ROSE Ada 2.7.6 Booch object modeling tool.
The PC software development environment includes the following:
- GNU GNAT 3.04a Ada 95 compiler.
- Microsoft Visual Basic Enterprise 4 Graphical User Interface (GUI) development kit.
- Microsoft Visual C++ 2 compiler, which is used to create the OLE/CORBA interface.
Lessons Learned
- Extensive knowledge is required to interface to Microsoft OLE.
The Win32 APIs need a thicker binding because of the difference in typing models used by C and Ada 95. Good software engineering, combined with an object-oriented development method, mitigates the maintenance burden. An interface layer may be required, such as an object-oriented subsystem or a package of abstracted operations. Training in OLE should occur prior to attempting any implementation.
An Ada 95 binding similar to Microsoft Foundation Classes would make the OLE interfacing easier. In other language environments, developers rarely use the OLE API for GUI development.
- The common bus for the distributed architecture is OMG CORBA.
Ada 95 has been successfully utilized in distributed CORBA frameworks. Objects to be distributed over the network are defined in Interface Definition Language (IDL). Orbix for Windows and Orbix/Ada were used successfully to generate PC-based OLE automation servers. The PC-based clients and the server-based distributed objects were implemented using Ada 95. Client/server integration was accomplished successfully.
- OLE was integrated with CORBA and Ada 95.
Ada 95 may be used successfully to interface OLE automation servers. OLE automation servers are needed to integrate numerous office automation products and other commercial off-the-shelf software.
The OLE engine was used as an interim mechanism for the GUI to speak to the CORBA bus. The GUIs were prototyped in Microsoft Visual Basic. The connection to the CORBA bus was via the OLE interface.
- Thomson ObjectAda has good and bad points.
Thomson ObjectAda and GUI Builder can transition the Visual Basic development to Ada 95. The resulting Ada 95 code is very clean and readable. The Thomsom development environment is not production-ready, due to missing components, required workarounds, and lack of documentation.
The FMMS project was lucky to have a very talented staff; otherwise, the initial porting would have had limited chance of success.
- Win32 can be utilized in an Ada 95 implementation.
Ada 95 may be used successfully to develop GUI executables capable of running under Windows 3.1 (with Win32s), Win95, and WinNT. Ada 95, Win32 APIs, and a standard dialogue editor were used to develop GUIs capable of running on either 16-bit or 32-bit operating systems.
2.9 Software Analysis and Design
Discussion
The FMMS project consisted of the re-engineering of an existing system. The stated requirements, which were successfully met, were:
- Rehost the software to the new environment providing the same functionality as the current system.
- Improve the system maintainability and reliability through reimplementation in Ada 95.
The resources allocated to the developers to determine specific requirements were existing source code, a users manual, and a few documents describing data formats. Domain experts and system users were present for the SAM-GAP team throughout the initial development effort, and continue to provide assistance to the developers.
Due to the short development schedule and nature of the requirements specification (source code of the old system), an iterative development process was used. For this reason, a formal system design was not created prior to beginning implementation.
Instead, requirements were immediately captured in use cases. After many weeks, the overall structure of the legacy code and system requirements became clear. At this point, it became possible to develop a fairly compact and elegant design for the system.
The initial Ada design originated from the use cases. This initial code was redesigned to make appropriate use of Ada 95 features, as opposed to the "C-Ada" created during requirements extraction.
Lessons Learned
- Access to users and domain experts is essential during requirements analysis and design of a re-engineering project.
Extracting requirements from source code is a difficult and error-prone process. Any support from users and domain experts during this phase would have been very helpful. When support was provided late in the project, it was clear the project schedule could have been further condensed and several useful enhancements could have easily been inserted during development if user or domain expert input had been allowed earlier.
- The use cases provided the basis for the current build.
The use cases are a powerful mechanism for software development. The major hindrance has been verifying with subject matter experts what are the real business processes that have been captured in the use cases. The use cases are new to the development staff and users.
Ongoing interactions with development staff and the user community are allowing the use cases to be refined and reduced in scope. The good working relationship has allowed both enterprises to make the new technology workable.
The FMMS project has successfully constructed an Ada 95 development environment. The system architecture required use of numerous tools which were easily incorporated into the development environment. No difficult problems were encountered in interfacing the new Ada 95 system with existing hardware and software.
The FMMS project has successfully created a demonstration that shows end-to-end connectivity of all the tools in the environment. This demonstration was used as the basis for current development in this iteration phase. Other lessons will be gathered after completion of the iteration, when a design and implementation review is completed.
Support for MS Windows-based GUI development is scarce but should improve soon. The Thomson product is available, but not fully mature. The maturity issue is also true of other products in the environment, but progress is being made!