This is a continuation of the TeraTech Development Approach from last month.

7. Develop Common Web Services

One significant advantage of moving applications to the new version of ColdFusion is the opportunity to reuse code and share common services between applications. It is possible to build and deploy components such as a common security access management tool that will serve all agency Web applications. As new applications are added to the platform their business and data functions will be examined for possible use as common business functions availabe to other applications.

8. Testing

The integrated Fusebox-based application system is extensively tested and debugged to ensure that the system produces the same results as the original system. Where possible, the legacy system test plan is used for testing of the new system functions. We use the Rational testing tools, including Test Manager and Rational Robot to facilitate and document our test cases and results. These test plans are comprehensive for the new and converted systems and will be re-usable in the regression testing of futures releases of the software.

This is a continuation of the TeraTech Development Approach from last month

5. Web Site Design in Fusebox

The system methodology used for NJ Sullivan development is Fusebox 4.1 running on ColdFusion MX version 6.1. The design model to be employed is the Model-View-Controller (MVC) pattern.

With Fusebox and MVC there is a separation of the data from the presentation and business rules. A plan for the Fusebox model is developed from the form prototype by the system architect.

Detailed module functional requirements are prepared by the architect using the standard Fusebox "Fusedoc" model. (www.fusebox.org)

6. Develop Database Access Components

During Web site construction the data access model is tranlated into database access components using ColdFusion components. These data construcs enable the re-use of common data queries and update logic by all system functions.

This is a continuation of the TeraTech Development Approach as continued from last month.

4. Web Form Prototype

If all system requirements are encapsulated in the existing model, a prototype can be developed directly from the legacy forms and reports. A model of the system functions is prepared in HTML to illustrate the proposed form flow and processing.

The prototype contains no dynamic data. All data displayed is hard coded on the source forms. All links are local HTML forms that enables the demo to be executed on any computer with a browsers. The following features were implemented in this prototype:

-Develop a "wireframe"(skeleton view) of the system forms

-Select style sheets from the available set of NJ Sullivan style sheets that will support a general look and feel and be acceptable to the end users.

-For legacy systems, copy and imitate the layout of the existing system menu structure and forms.

-Attempt to copy the layout and flow of existing legacy forms where appropriate, recoding for section 508 issues.

-Employ common Web navigation patterns when the legacy form flow was inappropriate for a Web site. This results in minor changes in process flow due to the introduction of additional forms to simplify form processing.

The Web mockup is presented to the users for comment and correction. Since the Web site has been modeled on the legacy system form flow users are able to quickly understand how the proposed system will work. User request for changes or enhancements are made to the HTML prototype and agreed to before system development begins. The process of review and modification typically requires at least three iterations.

The Prototype becomes the basis for user acceptance of the new system design and function. The NJ Sullivan Task Order Managers can used the prototype as a benchmark for the identification of the formal requirements for the system. Based on the prototype the system architects are able to document the formal requirements artifacts needed to document the planned system, to develop system decision and flow diagrams, and develop accurate schedules for coding and deployment. It is also the model for he development of the formal system test scenarios.

This is a continuation of the ongoing TeraTech Development Approach from last month.

3. Database Review

The data structures from step 1 are reviewed by the architects to determine if any redesign is required for the new system. The following factors will be considered:

-Normalization of the data structures

-Change the databse platform (ie convert from MS Access to SQL Server)

-Data cleanup or correction

Conversion and data correction plans are prepared based on this analysis and then discussed with NJ Sullivan Database Administrators (DBA's).

This is continued from last month in a continuation of TeraTech's Development Approach

2. Discussion with users to review these artifacts produced in step 1 results in the discover of unneeded system functions and begins the process of identification of the new functionality missing from the legacy system. It is not unusual to find that the legacy systems are fairly complete models of the functionality needed in the new system.

Unless the users are significantly displeased with the presentation flow of the legacy system a new model can be developed from the legacy data and forms very quickly. Where users need new functions or major revisions to the legacy system flow, methods for New System development are employed to discover how those functions should work.

This is a continuation from last months discussion on Application Architecting, FuseCoding, Unit Testing, Application Integration, and Deployment in TeraTech's Development Approach.

The TeraTech methodology centers on the practice of documentation of our work and the placement of all development artifacts into a repository along with the source code.

1. System Decomposition

-Capture all system froms using a screen to capture and saved as BMP images and printed for analysis. -Map the form hierarchy for the system in a graphical tool such as Visio. -Reverse engineer the database -- Microsoft Visio is used to capture the tables and re-construct the relationships in that data. -Examine the SQL queries and identify business rules. -Review user guides fro system functional requirements. -Review system test plans for verification of system operations.

Various system diagrams and processing state diagrams are developed to clarify how the existing system functions.. Formal design artifacts will be developed, such as use-case diagrams, state management diagrams, and action diagrams when appropriate for discussion of complex business functions.

This is a continuation from last months installment of the TeraTech Development Approach.

6. Unit Testing

As each fuse is coded, it is unit tested against the test harness. This gives the coder a way to ensure the correct behavior is produced by the fuse, without being in constant contact with the architect.

7. Application Integration/Final Testing

As the fuses are completed, they are returned to the architect, who integrates them into the final application. Daily builds are employed, gradually transforming the prototype into a working application.

After developer system integration testing, the new release is deployed to the NJ Sullivan center for final user acceptance testing following standard NJ Sullivan testing procedures.

8. Deployment

Deployment is the least exciting phase of the FLiP project. Thanks to the high degree of communication between the client and architect, and the architect and coders, deployment should hold no surprises for anyone.

This is a continuation from the ongoing discussion of TeraTech's Development Approach.

4. Application Architecting

Once the prototype is finished and approved by the system owners, the application architect constructs the application design or schema, identifying fuseaction and organizing them into circuits. Each fuseaction's behavior is broken down into a set of fuses, and the architect writes a Fusedoc and a test harness for each fuse to be produced. Once the design has been constructed, coding can begin.

5. FuseCoding Each coder employed on the project is sent one or more fuses and their corresponding test harnesses. The coder writes each fuse according to its Fusedoc. By using the Fusebox framework, the coder's work does not rely on the rest of the application. Each fuse can be coded and tested on its own, and can be plugged into the rest of the application. This step can be accomplished by one coder or many coders.

This is a continuation of the series in TeraTech's Development Approach from last month.

3. Prototype/Front End Development

A FLiP prototype is a clickable model of the finished application with dummy data and no backend behind it. Prototyping is the largest stepn in the FLiP cycle, generally taking up to 70% of the project's elapsed time for new systems. The result of prototyping is something that looks exactly like the finished application, with no functionality just client side screens. The objective is to discover exactly what the client expects from the application, and how they want it to look.

Prototyping is typically done in plain HTML. The finished prototype will become the application's user interface, so the traditional sense of a prototype being a minor, throw-away version is not the case. All the effort made in this step is used in the final application.

The Prototype becomes the basis for user acceptance of the new system design and fuction. The NJ Sullivan Task Order Managers can use the prototype as a Benchmark for the identification of the formal requirements for the system. Based on the prototype the system architects are able to document the formal requirements artifacts needed to document the planned system, to develop system decision and flow diagrams, and develop accurate schedules for coding and deployment. It is also the model for the development of the formal system test scenarios.

This is a continuation from the TeraTech Development Approach from last month.

1. Personas and Goals

Who will use this software? Why will they use it? A persona is a precise description of the application's user. Understanding the goals of the system users and owners (personas) and regular communication with them is essential for the design of good Web applications.

2. Wireframe

Wireframing is a way to quickly model the proposed actions that will be performed by the application. The result of wireframing is a clickable model or skeleton view of the application that provides a coherent process flow which gives the architect a clear road map for designing the site and gives users an early "test drive" of the application flow. This helps prevent having to develop pages that hadn't been thought of later in the development process.