There’s a fierce debate over the best project definition methodology: prototyping, modeling, or storyboarding. Small countries have waged war over less. Last month, Shelley Doll wrote an article that described the upside of framework prototyping. Many Builder.com members, however, responded by identifying the negative aspects of prototyping, relaying ghastly tales of miscommunicated expectations.
To eliminate this weakness, some members advocated the use of drawings or screen paintings to illustrate system architecture and behavior. Others suggested using small-scale modeling. So, which approach is really best? More importantly, which yields the highest return?
All these methodologies have an important, albeit different, place in the software engineering process. In fact, I tend to use all three on every project.
There are as many different methodologies for engineering software as there are projects to design with them. Developers tend to adopt methodologies that most closely match their own personalities, and then follow those methodologies until forced to do otherwise. I always lean toward methods that utilize a waterfall approach. Being brought up in the early days of programming—having started with COBOL assembly and BASIC on a Tandy TRS-80—I favor a top-down, structured approach to programming. Don’t get me wrong; every so often I get adventurous and take either an object-oriented (OO) approach or experiment with extreme programming. However, more often than not, you’ll find me sketching out a development plan with an older, sequential style (my software development crutch, perhaps). At any rate, here’s how I differentiate between the purposes of prototyping, modeling, and storyboarding.
Identifying risk and measuring technical feasibility
When using a waterfall-based methodology, I generally use prototyping to scope the magnitude of risk and to experiment with new technology; the prototype is developed as a proof of concept. It’s also a very valuable risk assessment tool. If a team can’t get a project to succeed on a small scale, the risk of failure on a larger scale is high. The prototype is used primarily as a gauge for identifying risk and measuring technical feasibility. Viewing prototyping in this light eliminates many of the weaknesses commonly associated with the approach. For example, one weakness is a tendency to put off technically challenging design issues until the end. If the prototype is viewed as a feasibility study, the challenging design issues are handled up-front.
I am currently involved in designing a system that will eventually be implemented on a very large scale. The customer wants a simplified version of the product—a proof of concept, if you will—rolled out in a very short amount of time. One of the technical challenges is building a Web-based interface for multiple PDAs. The prototype consists of a database engine, a Web server, and the hardware/software support needed to facilitate data exchange between the PDAs and the database engine. Prototype development centers on the Web-based PDA interface to scope the project in terms of risk and technical complexity. This is prototyping’s true role: identifying risk and measuring feasibility.
Communication is the key
I use storyboarding and screen mockups to help define business rules, establish functional requirements, and sometimes simply to understand a project from a customer’s perspective. I didn’t always use storyboarding. In my early days, I used to program the system to my own internal vision—that is, how I saw the software functioning, basing large portions of the design solely on the bells and whistles I could build in. This is typical of the CMM Level 1 development that occurred throughout the mid-80s.
At the project’s conclusion, the customer would have a system that was packed full of “special features” with screens that looked great to me. From the customer’s perspective, the system was cumbersome and difficult to use with a lot of useless bells and whistles. Storyboarding and screen painting eliminate many poorly communicated requirements, especially when distilling the business rules and establishing the GUI’s look and feel. “Could you draw me a picture, please?” is a part of my signature block; I reiterate it frequently during the initial stages of every development effort. The corollary is, “Step over to my whiteboard for a moment, please.”
Building the system specifications
Prototyping and modeling often are used synonymously, but nothing could be further from the truth. A prototype is a working system, displaying core functionality but on a smaller scale. Conversely, a model displays all pieces of the system without the inherent functionality. I liken a model software system to a snap-together model car; all the pieces are present, but the model has no real functionality—the horn doesn’t even honk. It’s merely a scaled-down representation of something bigger. I like to build a paper model of the entire system to ensure I have the software specifications down. Once the customer has approved the “model,” the team assembles storyboards and screen paintings.
Let it work for you
To recap briefly, I use storyboarding to help define business processes, establish the business rules, and assist with determining identities and the relationships between them. Modeling is used to build a paper system to ensure that I’ve interpreted the requirements correctly and have a valid system blueprint. Once the paper model has been approved, screen paintings ensure I understand the look and feel the customer desires. Lastly, a system prototype focuses on core functionality. This ensures I have worked out the core logic and identified any technical risks, if any exist. Once all this preparation is complete, I dive into the project with reasonable assurance that it will be completed successfully.