Software Development Approach

TeraTech Development Approach

TeraTech has adopted the standard Fusebox Lifecycle Process (FLiP) methodology for managing the design and development of new software systems.

The FLiP method described below is a process for identification of system requirements through an iterative engagement with the client and system users. It has proven effective in reducing the often expensive efforts to identify system requirements and obtain client approval and authorization.

Web design and implementation in ColdFusion with Fusebox has been greatly simplified with the development of the FliP. The TeraTech approach for new system development has combined some of the features of the FLiP process to create a robust and flexible set of design methods. FLiP provides a process for discovery of design requirements and obtaining client approval which reduces risks associated with traditional design systems.

The two Fundamental ideas behind FLiP

The first is to use a process that is, at all times, closely tied to client feedback.
The second is to encourage inexpensive changes in the design early in the process, resulting in a reduced need for changes later in the process, when those changes become progressively more expensive.

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.

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 step 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 function. 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.

4. Application Architecting

Once the prototype is finished and approved by the system owners, the application architect constructs the application design or schema, identifying fuseactions 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.

6. Unit Testing

As each fuse is coded, it is unit tested against its 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 a 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.

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 forms using a screen 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 data relationships.
Examine the source code to identify business rules.
Review user guides for 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.

2. System Review

Discussion with users to review these artifacts produced in step 1 results in the discovery of unneeded system functions and begin the process of identification of 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.

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 data structures
Change the database 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 (DBAs).

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 to local HTML forms which enables the demo to be executed on any computer with a browser. 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.

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 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. (http://www.fusebox.org).

6. Develop Database Access Components

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

7. Develop Common Web Services

One significant advantage of moving applications to the new ColdFusion environment is the opportunity to reuse code and share common services between applications. It will be possible to build and deploy components such as a common security access management tool which 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 available to other applications.

8. Testing

The integrated Fusebox-based application system will be 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 will use the Rational testing tools, including Test Manager and Rational Robot, to facilitate and document our test cases and results. These test plans will be comprehensive for new and converted systems and will be re-usable in the regression testing of future releases of the software.

Fill out our Consulting Request form and find out how TeraTech can help you.