We have experience in all aspects of product development, from the capture phase (RFP, Proposal, BAFO), to requirements elaboration (Spec Read, assignment to capabilities, derived requirements, allocation, USE Cases/Scenarios, RTM), to design (functional diagrams, system architecture, PD, DD, UT), to test (CFI, GFI, installation) and finally maintenance.

Our specific experience includes:

• Software Languages: Ada, C++, Java, Fortran, Basic, Z80, Intel, SEL-Gould
• Operating Systems: Windows (95, 98, NT, 2000), Unix (Solarus, Redhat, Linux), Multibus II, Versabus, VMEbus
• UML, Case, Rational Rose, TogetherJ
• S/W Development Models: Waterfall, Spiral, Combination
• SEI/CMM, ISO9000
• Specifications: MIL-STD 1644, MIL-STD 2167A
• Java Specific: (J2EE, JCE, EBJ, Struts, JUNIT, JDBC, RMI, JSP, SQL)

Aviplex has a long history of developing complex products through the whole life of the product's design. Our experience benefited from being able to oversee and participate in the transition from using functional product development models to the latest object-oriented development model [See A Brief History]. Now we favor a customized approach that uses a combination of functional, object-oriented and other development techniques to develop your product in a highly effective manner. Which exact approach is right or your program? That is dependent upon particulars of your program. Let us know a little about your application and we would be delighted to submit our ideas on how we can help you.

An Insider's Brief History of Functional and OO Design Development
Fifteen years ago program designs were developed along purely functional lines. If your task was to simulate an F/A-18 military airplane for purposes of training pilots, you could expect that the modules that you would develop would directly correspond to functional parts or observable effects in the actual aircraft. This approach proved comfortable to all participants in the design throughout all phases of the design development. Representatives of the contracting authority, who understood the aircraft and the training objective, assisted in the requirements resolution and preliminary design phases of the simulation development, and were pleased as the design elements that they were familiar with in the aircraft had direct counterparts in the evolving design. Subject matter experts arrived during the detailed design phase of the program, and continued to encounter functionally oriented components. Finally, during the closing phases of the program, as the design was tested and validated by representatives of the simulation user community, evaluation personnel tested functional components familiar to them.

The onus for the departure from purely functional design development came from the government. For many years the government had been commissioning aircraft simulations for various different aircraft in their arsenal. Each new contract for an aircraft simulation was developed as an independent simulation with no advantage derived from previous aircraft simulations. The government began to insist that new aircraft simulations attempt to reuse portions of previous aircraft simulations, saving these later simulations both time and expense. The main barrier to the reuse of previous aircraft simulation code was that there was no standard for the partitioning of simulations. The government embraced a new design approach, called Object-Oriented design engineering, as the standard for design development that accommodated design reuse.

The early provocateurs of Object-Oriented design engineering mislead us about its application. They espoused that in order to undertake a new design using purest OO techniques; you had to forget everything that you previously knew about designing. They said that the OO design was of necessity a completely new and different design, inheriting nothing from any previous experiences that you had had. First indications of discomfort with this approach occurred immediately when the contracting authority's representatives had difficulty mapping requirements into the unnatural objects we had developed. Detailed design development proceeded smoothly expanding the OO objects that we had specified. The approach proved unworkable when we entered the testing phases. The customer's initial reaction pretty much summed it all up, "What do you mean, the airplane has no wings?" The validation of the aircraft simulation relied heavily upon personnel who were familiar with the actual aircraft; in order to draw upon their expertise we were forced to return to dealing with functional objects again.

Successful integration of the customer into the development process dictates that the development process preserve functional attachments at crucial customer intensive points in the development process. The standardized development process that I now like to use is an amalgam of functional and object-oriented processes tailored to serving the customer's and our own design objectives.