Web application development grows rapidly towards regular IT. However, the main difference will stay: the web is all about communication, and human communication depends heavily on the use of emotion. As we all know, the strength of traditional IT development does not lay in creative design…

This dependency on emotion and creativity directly leads to a trade-off that bothers every web development company. How on earth can you mix the free spirit of the web with the effectiveness that modern application development asks for?

The best of both worlds

Web functionality can hardly be planned for, deadlines are neglected, budgets are overestimated and results do not fit the needs of a client: this really sounds like an average Internet project. However, the technical development method described in this document could prevent those problems, by using the creative and flexible nature of the web and the structural capabilities of more traditional development.

Web Unified Process

WUP (Web Unified Process) is a method for building web applications in a professional environment. The method uses UML (Unified Modeling Language) for its notation.

The WUP method guides developers and project managers into a more structural and flexible way of building web apps that suit the needs of the client. It differs from traditional processes in being much more practical, simple and directly designed from a web point of view.

This document starts with determining the outlines of the method, after which the details are described.

The outlines of WUP

WUP (Web Unified Process) is a method for building web applications. The method uses UML (Unified Modeling Language) and where applicable the UML WAE (Web Application Extension) for its notation.

The method tries to establish an iterative project rhythm, in which certain task scenarios are performed repetitively according to a plan. The development of an application is segmented into time periods called increments.

A description of the problem domain is the start of each project. The behavior of the future system is driven by UML use cases.

The aim of the method

In general, a development method is meant to guide the activities of a team of developers. Especially in projects that are relatively complicated, things tend to be forgotten or underestimated. A structural method can guide the less experienced members of the team and even the more experienced developers.

As a result, every member of the team has a clear view of the order of tasks he has to perform, which means that everybody knows when who is going to do what and why he is going to do that.

Rhythm

The process has the main responsibility to establish a rhythm, which helps to build project inertia. In practice, this inertia will keep up the flow or development speed of the project even in hard times. The method also offers criteria for monitoring and measuring the project’s process.

The WUP tries to provide a flexible approach for building web applications, without all the hassle of traditional methods. The process tries to prevent the creativity from being structured to death.

Most of all, WUP is practical. If you own a small web development company and want to get started with a project right away, just read the WUP manual and use the template documents.

The roots

The described process is partly based on iterative, incremental methods like Dynamic Systems Development Method (DSDM) and Extreme Programming (XP). These processes are widely used in usual IT projects, but for building web applications a more flexible approach is recommended.

The Rational Unified Process and the ICONIX Unified Process are also resources on which WUP is based. These methods are driven by UML, although not especially designed for web app development.

We don't reinvent the wheel

It’s a matter of fine-tuning: a method can’t be equally useful for regular IT and for web projects at the same time. Therefore, the WUP uses parts of the four methods to create a web-compliant way of working. Apart from this combination of methods, the WUP method is also based on extensive experience in the web development practice.

So, WUP does not pretend to be a completely new development method, but is merely meant to be a frame in which the web-compliant parts of existing methods and UML are put together. This results in a structural development environment in which both coders and designers can be creative.

When using WUP, please feel free to adjust the process to the specific needs of your company. No development method will exactly suit your own process, but it can provide some guidance.

The specifications

The method is meant to serve the larger web projects which are depending heavily on technical logic. The process relies on a strong architectural foundation.

This kind of projects is preferably object oriented (OO) and usually 3 tier. In a 3 tier architecture the software is strictly divided into three parts: the presentation tier, the business logic tier and the data tier. The separation of these parts leads to a system that is more scalable and easier to maintain.

Small teams

The WUP approach supports development in small teams best. The developer team should consist of a project manager, two or more developers and at least one functional decision maker. If the number of persons in a team exceeds, let’s say, twelve, it would be advisable to create more roles than the usual WUP role definition accounts for.

Time boxing

This team aims at delivering some functionality within a fixed time period, which satisfies the needs of the customer. The deadline is fixed, but on the fly the optimal functionality can be redefined. The project can be functionally steered, depending on the progress of the project and the needs of the customer.

This way of dealing with time, resources and functionality is called time boxing. Time boxing means effectively that time and money are fixed, but that functionality varies.

Every phase of the project is dealt with as a time box. There are usually four phases in an average web project: the conceptual phase, the analysis phase, the development phase and the post-deployment phase.

The conceptual phase

In the conceptual phase, a business concept is created. A concept describes the functionality of the future system on a marketing level, usually by marketing people, in no more than a couple of pages in writing. In the analysis phase the developers and the customer try to fill in the gaps in functionality of the concept, to create an initial functional design, a style definition, an interaction design and an initial technical design. In the development phase people actually start coding, testing and releasing. The final product is supposed to be delivered at the end of this phase. The post-deployment phase can include beta testing, performance tuning, maintenance and user training.

Iterations

Programming is usually more successful if done in steps, with each step focused on a limited readily achievable objective. Therefore, the development process runs iteratively. The steps or iterations are planned using the feedback on business value and priority of the requirements that the functional decision maker supplies. There will be small releases for every independent part of the system, to give an opportunity for that feedback.

Increments

A very complex system requires an incremental approach. An increment is a period after which a workable version of the system is released. After finishing an increment, the functional decision maker and the customer can decide whether and how to continue. Within an increment the development always runs iteratively.

The Unified Modeling Language (UML)

The start of a project is characterized by the determination of the problem domain. The entities of the problem domain are defined and used to construct a Domain Class Model according to the UML standard. From this model the object classes and data model are derived.

The external behavior that the system should exhibit is described in use cases. Use cases are small units of functionality, describing the interaction between an actor outside the system and the black-box system itself. Use cases are easy to read, for both customer and developers.

The functional decision maker defines the use cases. After that, the developers and the functional decision maker determine the actions inside the system that will lead to the completion of the use case. These actions are called stories. The stories are prioritized and estimated in complexity. The individual developers sign in on the realization of a specific use case and its stories.

The link between use cases and stories is described in more detail using sequence diagrams. These can be modeled using the WAE (Web Application Extension) for UML .

Use cases and stories supply an easy tool for project manager and functional decision maker to monitor and measure the progress of the project. Since the time needed to realize stories is estimated, it is very easy to estimate the total amount of days needed to finish the project. The duration of a project can be calculated using the team members’ individual capabilities or development speed.

Apart from use cases, the system must conform to technical system requirements. These constraints are typically expressed as a statement that begins with: “The system shall..”.

Feel free to use any parts of this tale

...because we don't pretend to have thought of all this ourselves, we don't want you to try and do the same. Use anything you like, and forget the stuff you don't appreciate. We hope you will please the world with outstanding web apps!