Reshaping IT Project Delivery Through Extreme Prototypingby Satya Komatineni
Extreme Prototyping is an architectural process for developing applications, especially web applications, in terms of increasingly functional prototypes. At a high level, it breaks down web development into three distinct phases. The first phase is the static prototype, consisting of HTML pages and possibly a logical data model supporting those pages. The second phase is a coding process in your chosen web framework whereby the screens are fully functional using a simulated services layer. The third phase is where the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully-functional UI is developed with very little regard to the services other than their contract. This deliverable, much like the static HTML prototype, can be considered a prototype, albeit a dynamic one.
By using Extreme Prototyping, you will be able to substantially shorten the requirement cycle and also the development cycle. Extreme Prototyping will allow you to consistently estimate and deliver your projects faster, cheaper, and better. Extreme Prototyping achieves these results primarily by breaking down the dependencies between multiple teams and thereby allowing parallel development. Extreme Prototyping continues to put extra emphasis on executable deliverables.
The Three Bricks of Extreme Prototyping
If you imagine system development as a set of concrete deliverables, you can imagine an "Extreme Prototype" to consist of three bricks, as depicted in Figure 1.
Figure 1. The three bricks of Extreme Prototyping
The first brick is the Static Prototype. Based on this prototype, the UI brick and the Service brick can be developed fairly independently and brought together toward the end of the project for an integration alignment. The service contracts (or blades) should allow for a perfect alignment in any typed language.
The Anticipated Advantages of Extreme Prototyping
Iterative approaches such as Extreme Programming recommend building and delivering your working programs in small steps and doing so often, especially in terms of executable code that is delivered daily and weekly. Nevertheless, there are assumptions for this to work well. The team has to be small enough to handle the continuous feedback. If projects have a tendency to be cancelled, the partially-baked project is another reason to take that step; Extreme Programming works best when all the teams are fully committed to carry out the project to the end.
Extreme Prototyping with its three phase approach is orthogonal yet symbiotic to the iterative process. The static prototyping phase ensures project commitment from the business. The dynamic prototyping phase ensures speedy delivery without depending on a service layer implementation. Delivery and demo of the dynamic prototype to the users will provide feedback on a midpoint of the project. The service implementation phase, which can start in parallel with the dynamic prototype, has a clear service contract to fulfill. Iterations are can be employed within each phase as appropriate.
Many IT projects start with a requirement phase that delivers use-cases. Business users are expected to understand these use-cases and sign off. What happens more frequently in the field instead is that the business team gets lost in sticky figures, activity diagrams, and so on. So much time is spent elaborating on these use-cases that in the end, all the allocated budget (and more) is spent before writing a single line of code. The key is to wrap up the use-cases very quickly and use them to derive an HTML prototype that is as complete as possible. It is easier for business teams to validate and agree on a prototype. The clarity of prototypes will work as a catalyst to complete the use-cases and act as an antidote to the analysis paralysis.
Extreme Prototyping via static prototypes can also aid in budgeting and planning. Very often a business seeks an estimate for a project based on just a vision document. The estimate would include all the phases of a project including build and delivery. Estimates based on this document are subjective and will have a lot of variability. The anticipated cost may close the project down. Instead of putting an request for proposal (RFP) for the whole project scope, the business team could put together an RFP just for the Static Prototype. This will yield an estimate that has a mostly fixed cost, and the deliverable is readily reused in an eventual estimate. Subsequent phases can then be budgeted and planned.
Overview of the Complete Development Process
Here is an outline of an Extreme Prototyping process:
- Static Prototype phase
- Static Prototype
- Master or background pages
- Business rules, use-cases
- Extended Static Prototype phase
- All of the above
- Logical data model to support the screens
- Dynamic prototype (or Extreme Prototype phase)
- UI recoded/adjusted for the chosen web framework
- Working executable code
- Field validations work
- Navigation of screens will work
- Service signatures solidified
- A complete working UI with no implementation behind
- Service Implementation Phase
- API document
- Each service implemented by calling databases or other resources
Extreme Prototyping starts out like any other well-planned project with a Static Prototype, but distinguishes itself in the coding phase of the UI. Extreme Prototyping strives to see the UI deliverable as another prototype with a thoroughly spec'ed service layer. In this sense, the UI layer is defining an API for the service implementers. This is similar to how various JSRs are developed. One body defines the standard and the API, and number of companies implement that standard using the common API. The UI implementation will then be followed by the service implementation.