Fusebox Lifecycle Process (FLiP)
Compliments of Fusebox.org
The Fusebox Lifecycle Process (FLiP) is a process for developing web applications. FLiP grew out of some of the best practices employed by Hal Helms and other members of the Fusebox community in the early days of Fusebox. Although, as the name indicates, FLiP came from the Fusebox community, its use is not intrinsically part of a Fusebox application. In fact, the ideas found in FLiP may be successfully employed in non-Fusebox projects as well.
The fundamental idea behind FLiP is to use a process that is at all times closely tied to client feedback, and one which follows steps allowing inexpensive changes in the design, to steps where changes become progressively more expensive. The idea is to encourage change in the early stages, where it can be managed with the least expense possible.
It is also important to note that FLiP is designed for the technical aspects of the project, starting at a point when you are ready to begin building an application. For many simple web projects, FLiP may be sufficient from the start of the project. For more complex projects, other research techniques may be necessary to understand the business model before starting on the application development with FLiP.
The steps in FLiP are: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. Instead of designing feature based software, we design goal based software. This process helps deliver software desired by the end user.
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 of the application that doesn't look anything like the finished project, but gives the architect an idea of how the client will help the persona acheive their goals.
A FLiP prototype is a clickable model of the finished application with no backend behind it. Prototyping is the largest step in the FLiP cycle, generally taking up to 70% of the project's effort. The result of prototyping is something that looks exactly like the finished application, with functionality limited to the client side. The objective is to discover exactly what the client expects from the application, and how they want it to look. Often a tool such as DevNotes is used to facilitate communication with the client about the prototype. DevNotes is a tool that will be available soon to Lasso developers.
Prototyping is typically done in plain HTML, though if an alternative front-end technology (such as Flash) is being used the prototype may be done using that technology. 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.
Once the prototype is finished, 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. There are some fantastic tools and techniques to use during this step.
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.
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. It also allows the architect to employ any number of coders, none of whom need to know anything about the project as a whole in order to successfully contribute to it. However, if the development team is tightly-knit or consists of only one person, unit testing creates an elegant quality control system for the basic building blocks of the application, ensuring reliability of the entire project.
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.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 day should hold no surprises for anyone.
Copyright ©2017 LassoFusebox, All Rights Reserved.