Real World FLi P Fusebox Lifecycle Process Michael

Real World FLi. P Fusebox Life-cycle Process Michael Smith, Tera. Tech, Inc. michael@teratech. com http: //www. teratech. com 301 -424 -3903 x 110 Copyright Tera. Tech 2003 1 www. teratech. com 1/48

Overview • • What is FLi. P? General Concepts Why use FLi. P? Common client communication problems and project snafus • Wireframing, Prototyping, Devnotes, Sign-off • How to get started in your organization • Q&A 2 www. teratech. com 2/48

Speaker Information Who am I? • Michael Smith • President of Tera. Tech, Inc Rockville MD – http: //www. teratech. com/ – tt. Web. Report. Server, CFXGraphicserver • MDCFUG, CFUN-03, Fusebox Conf • Articles in CFDJ, Fusion Authority • Winner CFDJ award Best CF Consulting 3 www. teratech. com 3/48

More About Me • • 22 years programming 7 years with Cold. Fusion 4 years with Fusebox Also work with SQL, Java. Script, HTML, VB, Oracle, Access • Teach one-on-one and custom classes • On site and custom development • Fusebox and Process Methodology 4 www. teratech. com 4/48

What is FLi. P • Fusebox Life cycle Process • Plans your development and client communication • Contains – – – Wireframe HTML Prototype + Devnotes Sign off Circuit mindmapping Fusedocs 5 www. teratech. com 5/48

What FLi. P achieves • Organize project process • Dramatically improves client-programmer communication • Better management of client expectations • Improves programmer-programmer communication • (Including communication with myself from 6 months ago!) 6 www. teratech. com 6/48

Benefits of Standardization • • Better team communication Cheaper maintenance Fewer design time bugs New team members can pick up code faster • Save time thinking about how to organize project 7 www. teratech. com 7/48

Why FLi. P? • Works well in practice • Parts useable independently • Community support “Fusebox began and continues to be guided by a developer community concerned with making their projects more successful, their clients happier, and their own work less frustrating and more rewarding. ” 8 www. teratech. com 8/48

Fusebox has evolved… Prior to Fusebox 3, the term, "Fusebox", meant both an application framework and a set of "best practices" for web software development. Architectural Framework (Fusebox) Development Methodology (FLi. P) 1998: Fusebox 1 & 2 2001: Fusebox 3 With Fusebox 3, a clear distinction is made: Fusebox is an application framework. FLi. P is a lifecycle 9 methodology. www. teratech. com 9/48

Common Project problems • • • Poorly defined requirements Scope creep Communication problems between client and team Code hard to understand, Non-working code Changes hard to follow Outdated code vs comments Duplicated code - Reinventing the wheel Inconsistent design approach Random order of development process Late requirements 10 www. teratech. com 10/48

FLi. P goals • provide a structured approach to determining what clients want • make it possible for developers to write code once • give clients exactly what they want and expect • document decisions made • determine acceptance testing before coding • overcome the Mythical Man-Month problem 11 www. teratech. com 11/48

More FLi. P goals • support both traditional and distributed team development • offer a structured documentation/ program definition language • scale from small and simple to large and complex • support wide variety of developer skill sets and levels 12 www. teratech. com 12/48

Two approaches - Traditional en t g oy m st in De pl Te in g gg bu di ng De ite ch Co ct ur e n sig De Ar Re qu ire m en t s Traditional Many methodologies focus on writing code (and debugging), which takes up the greatest amount of the project time. 13 www. teratech. com 13/48

Two approaches - FLi. P t en oy m De pl in g st Te ng di Co ur e ct ite ch Ar Re De qui sig rem n en ts / FLi. P spends a great deal of time on requirements, design, a architecture, understanding that clients can only tell you wh they want when they see it. 14 www. teratech. com 14/48

Start Traditional Finish In many methodologies, the farther along the project is, the fewer people can contribute to it. www. teratech. com 15 15/48

Start Let's "FLi. P" that around Finish With FLi. P, as a project progresses, more developers can contribute to it. 16 www. teratech. com 16/48

The 3 stages of FLi. P en t oy m De pl in g st Te ng di Co ur e ite ct ff ch -o Ar Si gn es ot vn De ot ot Pr W ire fra yp m e e Discovery Design Implementation Requirements/Design 17 www. teratech. com 17/48

Fusebox Project Life Cycle • • Wireframe HTML Prototype + Devnotes Sign off Architecture + Fusedoc Final Code Acceptance Test 18 www. teratech. com 18/48

FLi. P diagram Generate Wireframe Iterate with user Convert to fusebox skeleton Pages and Flow HTML Prototype Iterate with user Graphics and fields, Devnotes Sign-off Fusedoc responsibilites, IO Design Database Code Fuses (OK vs make change and resubmit dsp, qry, act, lay, fbx Test Fuses Fuseactions & Circuits testharness Mark up fuseactions in printout of prototype Integration Test Mindmap Compare to prototype Group fuseactions into Circuits, indentify fuses Deploy www. teratech. com 19 19/48

Wireframe • • • Blueprint of project – compare to house plans No layout or graphics Focus on page flow and exits Client can walk through site Helps with estimating costs Many tools available: – sourceforge wireframetool – Rebar – Adalon's wireframe edition 20 www. teratech. com 20/48

Wireframe • Provides a text-only walkthrough of the application from the client's POV • Can be done in front of the client • Helps concentrate on what the application should do, rather than how it should appear • Forms the basis for moving to the prototype • You control the level of detail and time spent 21 www. teratech. com 21/48

Sample wireframe 22 www. teratech. com 22/48

HTML Prototype • Is an iterative process whose end is an exact replica of what the look and feel of the application is • Guarantees that there is no miscommunication • Requires no/very little code • Continues until both client and architect agree that the prototype accurately and completely reflects what will be delivered 23 www. teratech. com 23/48

A good prototype is an exact replica of the finished application The prototype The deployed application 24 www. teratech. com 24/48

HTML Prototype • Exact layout and graphics for all pages • HTML and graphics will be reused in CF code • Lets client see final site look and feel – a photo album of future site. Can show all users. • Clickable – can walk through site • Dummy data • Not the real thing! Compare artists sketches to finished house. www. teratech. com 25 25/48

Using Dev. Notes with the prototype • Provides a simple mechanism for placing a context-sensitive, threaded messaging system on the bottom of each prototype page • Allows continuing communication to occur during the prototyping process • Documents the process by which decisions were made • Ensures that client requirements are not lost 26 www. teratech. com 26/48

Devnotes • Let you add written comments attached to each page • Tag in On. Request. End. cfm • Threaded discussion • Record of all changes made • Available from halhelms. com • Other flavors of Dev. Notes out there 27 www. teratech. com 27/48

Sample Dev. Notes Each message identifies who wrote it. Message threads can be removed when no longer needed. Such threads are removed from view, but remain in the database. 28 www. teratech. com 28/48

The critical point of FLi. P: prototype freeze • Neither architecting nor coding begins until the prototype is frozen • The prototype is only frozen when both client and architect agree that the prototype fully and completely represents what the finished application will look like and do • Answers the question, "When do we begin? " • Answers the harder question, "When do we end? " • Forms the basis for later acceptance testing, eliminating the "moving goalposts" problem 29 www. teratech. com 29/48

Formal Sign Off • Client decides when prototype is close enough to what they need • Sign off is formal end of changes • May bring up other needs or other parties who have to see prototype • As pages are signed off Dev. Notes are frozen • Page ok: “Yes” or “No”? – Do not use “Ok, With Changes” 30 www. teratech. com 30/48

Steps in architecting a Fusebox application 1. 2. 3. 4. 5. 6. 7. 8. 9. Identify fuseactions and XFAs that can be determined from the prototype Fill in fuseactions/XFAs that are non-visual Group fuseactions into circuits Determine fuses that can be reused or need to be written Split fuseactions into query, action, display Write Fusedocs for each fuse Write fuses Create test harnesses Integration / acceptance testing 31 www. teratech. com 31/48

Identifying Fuseactions in Prototype 32 www. teratech. com 32/48

Mindmap Circuits and Fuseactions 33 www. teratech. com 33/48

Circuit and Database design • Only design the site structure when signoff complete • Only design database when sign-off complete – Compare to doing at beginning • Use Query. Sims to fake out database if DBA is not finished with database design yet. 34 www. teratech. com 34/48

Fusedocs • All incoming and outgoing variables in fuses (including XFAs) are declared in an XML document known as a Fusedoc. • The Fusedoc sits at the top of every fuse and is wrapped in CFML comment tags. • It is written before the code is written, and provides a "contract" between the architect and the fusecoder. 35 www. teratech. com 35/48

Fusedocs rules 1. “Include everything a coder needs to write the fuse, and nothing more. ” • Environment variables – request. dsn • No database schema • No file dependences • Only one fusedoc per fuse 36 www. teratech. com 36/48

Sample Fusedoc <fusedoc name="act_Validate. Login. cfm"> <responsibilities> I check to see if the user can be authenticated. If so, I create a structure called Current. User and return to the fusebox with XFA. good. Login; else I create no structure and return to the fusebox with XFA. bad. Login. </responsibilities> <properties> <history author="hal helms" date="02 May 2002"> Built to illustrate Fusedocs </history> </properties> <io> <in> <string name="XFA. good. Login" /> <string name="XFA. bad. Login" /> <string name="user. Name" scope="form" /> <string name="password" scope="form" /> </in> <out> <structure name="Current. User" scope="Session" optional="TRUE" on. Condition="on XFA. good. Login"> <string name="user. ID" /> <list name="user. Roles" /> <string name="full. Name" /> </structure> </out> </io> </fusedoc> www. teratech. com 37 37/48

How to get started in your organization • Start with the parts of FLi. P you like • Can use any of wireframing, prototyping, devnotes, sign-off or fusedoc independently • Don’t ask formal permission – just start using the part of FLi. P you like best it on next project • Explain roadmap of process to client and benefits to them of communicating more 38 www. teratech. com 38/48

FLi. P Summary • Better client – programmer communication • More client communication! • A picture is worth a 1, 000 words, a simulation is worth 1, 000 words • Sign-off sheets used in acceptance testing • Sign off stops endless expensive enhancements 39 www. teratech. com 39/48

Roles in software development Client Team Programmer www. teratech. com 40 40/48

The client likes the process… • They – see what they will get before they get it – can track progress by having known deliverables – pay less in time and/or money since there is less risk to team – Their expectations are managed better so they are happier 41 www. teratech. com 41/48

The team likes the process… • They – can leverage their investment in tools and training – distribute pieces of a project based on skill sets and levels – reduce overall risk of project failure – develop faster and at a lower cost – Lower stress level due to knowing where in the process they are 42 www. teratech. com 42/48

The programmer likes the process… • The programmer – knows what they're building – can concentrate on writing code – has an active online community available – is able to reuse fuses and modules – enjoys coding again 43 www. teratech. com 43/48

How about a FLi. P book? • Fusebox 3: Developing Cold. Fusion Applications by Jeff Peters and Nat Papovich • Covers FLi. P and Fusebox framework • Full sample wireframe, prototype and code for thirdwheelbikes. com 44 www. teratech. com 44/48

Fusebox only book • Discovering Fusebox 3 by Hal Helms and John Quartovon. Tivadar • Consise coverage of Fusebox framework • No FLi. P 45 www. teratech. com 45/48

Resources • Fusebox core files are freely available from www. fusebox. org • Various sites have free tutorials, white papers, sample code, etc. – – – – www. halhelms. com www. techspedition. com www. grokfusebox. com www. secretagents. com www. bombusbee. com www. fusium. com Fusebox email list (very active and responsive) 46 www. teratech. com 46/48

Ready for some Fusebox training? • Tera. Tech offers classes in – FB 101 - Intro Fusebox – FB 201 – Intermediate Fusebox and FLi. P • All classes are available at Tera. Tech training center in Rockville MD or onsite at your organization. • One-on-One and Project mentoring also available 47 www. teratech. com 47/48

Questions? Email me at michael@teratech. com 48 www. teratech. com 48/48