4 January 2010 - 14:53 It’s Never Too Late for a Little Functional Modeling… By Elizabeth Stoops, QA Analyst

Functional modeling of software is often considered a start-up step. Something to be done before ‘real’ work gets underway. Functional modeling is typically viewed as a tool to help the developers conceptualize the software they mean to write. The conventional wisdom is that functional modeling will provide a more cohesive picture of the final coded software and greater clarity on the look and feel of the final product. Functional modeling, while best used during the early stages of development, is nonetheless, a powerful tool when introduced in the middle of the development cycle. Unfortunately, when chaos strikes mid-project, functional modeling is generally the last solution considered, if it’s even considered at all.

While the largest benefit to a project from functional modeling comes when it is introduced from the think-tank stage, functional modeling can be used long after the code is written for requirements thought to be chiseled in stone. It is often at this middle stage of the product development cycle that testing finds that incomplete or ambiguous requirements have caused code deficiencies. These deficiencies yield a mid-cycle quagmire of rework escalating bugs and burgeoning budgets.

Try the following quick exercise: draw three large circles, one on top of the other. Draw two lines coming from the middle circle. Draw three small circles in the middle circle and draw two small circles in the top circle. Draw a triangle on top of the top circle and draw another circle at the top of the triangle. Draw a curved line in the top circle underneath your two smaller circles. Tada! You can fill in the rest to be a season appropriate picture.

To explain why functional modeling can help mid-development, it helps to understand the process that leads to the point where management is asking for a snowman and development is handing over an alien hybrid. This happens because when ideas become abstracted into requirements and words alone try to capture intricate ideas and logic, some implied functionality or features become lost. While everyone knows that it should be, for example, a system for tracking inventory, and while each person has the same general concept of how the end product should work, each person comes away with a separate idea of exactly how this is accomplished. As with our “Use Case” of drawing the snowman, the written instructions will not always produce the envisioned outcome. Typically, when a project enters the aforementioned mid-cycle quagmire, the “instructions” (a.k.a. requirements) are then re-written and the code reworked to represent those changes. These changes tend to add new dimensions to the software and disconnect previously connected code chains. The fixes cause more fissures in the program than they solve. This, in turn, necessitates new instructions, new rework and even more fissures. The effect…. forgive the pun, snowballs. The budget and time allotted for the project also snowballs.

Functional modeling can help if you’ve just received an alien hybrid, or even if you are on the second generation of the alien hybrid. When introduced mid-project functional modeling circumvents the costly snowballing cycle of churn. Instead of distilling complex relationships into words alone, functional modeling can start providing pictures to accompany the text. When in a mid-cycle quandary, functional modeling is a sure-fire way to avoid complete derailment as the hot fixes and redevelopment avalanche through the project. To put a project back on track, and sometimes even ahead, functional modelers create an image of the current software (this step will often help clarify where the holes and broken links in the software already are) and then, after new requirements are received, model the proposed fixes and changes to determine interaction with the current functionality. Before developers even begin coding, faulty interactions with the current code and the proposed changes can be discovered in the process of functional modeling. This prevents the effort and expense of coding contradictory or ambiguous requirements that will necessitate fixes or delivery with bugs.

Even better than improved requirements, completed functional models provide an expansive picture to the developers because each step in the software logic, for each variation, is made known to them through the model. The software and development team can use the models as instructions to implement all needed changes and fixes without cross-examining several sets of instructions and external specifications. They can code these instructions confidently, as the “bugs” have been found in advance of their effort and corrected in advance in the functional models.

Over 50% of the cost in any software development project is rework caused by the mid-cycle quagmire described here. The pressure to deliver coupled with the rework often makes it necessary to deliver a hybrid alien snowman with missing features.  By using the flexible and adaptable tool of functional modeling, even after the project has started, it is possible to deliver a robust, full size snowman on time; not a Calvin and Hobbes special or melting snow pile because the season has changed.