Clickframes Project Lifecycle

From Clickframes

Development teams can use Clickframes in a variety of ways. We've designed Clickframes to provide independent value for designers and business analysts, developers and testers. This means you can introduce Clickframes at any point in the software development lifecycle. So if the business analysts aren't ready to (or can't) use CLIPs, the developers can sit down, write an appspec, and use Clickframes to accelerate coding. Likewise, QA can create an appspec when it's time to start writing tests, and use it to generate manual test scripts or even customized automated tests.

Clickframes Soup to Nuts

Within the Clickframes team, we look at projects in five stages. You don't have to do it this way, but it works for us:

  • Concept
  • Model
  • Code
  • Test
  • Deploy

We don't use Clickframes at all for the concept phase - that's where we're writing project briefs, interviewing users, and generally getting a sense of what the system should do. We don't try to capture all the details, but we do try to get the big picture down - it's important to know whether your web site is selling used cars or booking hotel rooms.

We start to use Clickframes in the model phase. We create an initial version of the appspec (our "first cut at the truth") and use CLIPs to share the application design with clients, potential end-users, and anyone else who should be providing feedback. We use this feedback to iterate the model, gradually refining the appspec.

At some point, the appspec is sufficiently refined to let us start the Code phase. That doesn't mean we're done modeling, and the appspec will continue to evolve as the project proceeds. Developers will ask questions, business requirements may change (it happens), and functionality may be cut. The CodeSync features built into the Clickframes plugins mean we can start developing as soon as a reasonable portion of the application is modeled, and generate more code later as the design fills out.

Likewise, the Test phase doesn't necessarily follow-on from the Code phase. Once the appspec has been refined enough, and some actual code has been written, you can generate and start customizing an initial set of test scripts. This gives the development team fast feedback, and keeps delays to a minimum (since the QA team can start working immediately).

And finally, when everything is done, you Deploy. Clickframes doesn't do this for you (you'll have to set up your own server), but we've done our best to get you there!

Throughout the project, we emphasize the appspec as the single source of truth. So when analysts, developers and testers learn something new about how the application should behave, they go back and update the appspec. As the project proceeds, major changes should become more and more infrequent, but the appspec will become more and more detailed. It's the medium for communication between all the different roles on the project, and since people sometimes don't communicate that well, we've tried to make updating the appspec a useful (and time saving!) activity for all concerned.

Clickframes and Agile

Clickframes works well in an Agile framework because it's built around the idea of rapid iterations. In the lifecycle described above, it's a slightly different kind of iteration than some teams practice, since our approach to software development is pretty heavy on formal user studies and iterative design work. We think this is just as iterative as any other approach; we're just using different media to produce the first few iterations.

If you want to start from use cases and user stories, Clickframes supports that too. Just iterate your appspec as desired and run the code and test generation plugins as often as you want.