The well-known software development processes can be grouped into two categories: lightweight processes – better known as agile processes – and heavyweight processes. “Light” or “heavy” refers to the degree of process formalization, i.e., how many documents and models are created. Heavyweight processes are used particularly when large teams develop complex applications. In contrast, lightweight processes are suitable for smaller applications and accordingly smaller development teams.

The wide choice of different process models reflects the large range of different software development projects. No single process model is equally suitable for all projects. The types of inherent risks tell us what process model to go for. Web applications differ from traditional, non-Web-based applications in a variety of features. On the one hand, there are characteristics that traditional applications lack completely and on the other hand characteristics that are particularly pronounced in Web applications. This influences the suitability of conventional software development process models.

Agile Development Process Model

We use agile development processes in the development of Web applications. Agile processes are built on the foundation of iterative development. To that foundation they add a lighter, more human-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. We will use the example of Extreme Programming (XP) in the rest of the section to describe the suitability of agile development processes for Web application development projects. We, however, are open to use of any one of many agile development processes in practise, depending upon the specifics of the project. XP is built around four core values – communication, simplicity, feedback, and courage. These four core values are the foundation for an XP project.

The first XP core value, communication, is a fundamental task of building software systems. In heavyweight software development process models, this task is accomplished through documentation. In XP personal communication is more important than any document. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. Customers must communicate their needs and desires; developers must communicate the ramifications of various options; and both must communicate with management to paint an accurate picture of a project’s state. Only through excellent communication can every faction in the development process know what the product is for, and work together effectively for its successful delivery.

The second XP core value, simplicity, encourages starting with the simplest solution and refactoring to better ones. In an XP project the focus on designing and coding is on the needs of today instead of those which will arise 6 months later. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Possible future visions and requirements are ignored. Instead the developer only designs and implements practical stuff for the next release.

The third XP core value, feedback, guides the project along the way. Within XP feedback is related to different dimensions of the development. Programmers need direct feedback about the state of the system after implementation changes. Customers need a concrete feedback about the current state of their system in a way that they can steer the development. The main goal of this core value is to stop problems at the earliest possible point during the development process.

The fourth XP core value, courage, means that developers, managers, and customers should not be afraid to try new ideas and approaches. Sometimes a chance must be taken to achieve the desired results. Communication will raise a flag if something is not going to work.

In an XP project, the project flow is divided into the releases it creates. Creating such a release takes typically not more than a few months. These rapid successive releases represent the first characteristic of XP. The creation of a release begins with a release plan. The actual development follows in several consecutive iterations. Changes to the requirements or newly added requirements can lead to another release plan at any time. A successfully completed acceptance test leads to the delivery of the release.

The iterations in which actual development occurs each begin, in turn, with an iteration plan. An iteration generally takes a couple of weeks. In any case, it shouldn’t take more than four weeks. Both the release plan and the iteration plan are seen as a task to be handled jointly by the developers and the contractor. The technique used in this context is known as the planning game. Within the planning game, the contractor is responsible for setting priorities for possible further developments, while the developers are responsible for estimating the cost and time of these further developments to create a prioritization basis.

Suitability for Web Applications

XP has established itself as an accepted approach for the development of Web applications. We briefly describe below how XP can meet the challenges specific to a Web application development project.

Handling Short Development Cycles

A fact found in multiple empirical studies is that the development time of Web applications is extremely short; it does not normally exceed six months, and its average duration is less than three months. Competition is extremely fierce in the Web. Immediate presence is given priority over long-term perspectives. In addition, there is an extreme necessity to be faster than others on the market to ensure sufficient market shares. A new functionality introduced by a competitor for the first time causes an enormous pressure for others to also offer this functionality. Otherwise, there may be a risk to quickly lose substantial market share.

Rapidly successive releases are one of the characteristics of XP projects. Iterations also allow to structure short development cycles. Since the process is lightweight, XP meets this requirement nicely.

Handling Changing Requirements

A point strongly related to the previous requirement is the fact that the requirements for a Web application often emerge only during its development, or that they are subject to major changes with regard to both its content and technology. One often has to deal with an unknown field of business and the business requirements can change dramatically as one gains a better understanding of that business in the course of the project. New requirements that result from a changed market situation have to be integrated rapidly to prevent the competition from gaining a competitive edge. As a consequence of these, it is often impossible to precisely define requirements. Incomplete or ambiguous requirements have to be accepted. A direct consequence of this requirement on a process is the strong integration of the customer into the development team. Due to emerging and unstable requirements, customers must be informed about the development progress in detail.

Simplicity, which represents one of the four core values of XP, means that any longer-term planning can only be very coarse and preliminary in an XP project. A foresighted way of working that tries to prepare today for the needs of tomorrow is rejected. Instead, the close integration of the customer, combined with a rapid delivery of results, allow to develop and continually adapt the requirements. This means that XP and other agile process models fully meet this requirement well.

Releases with Fixed Deadlines and Flexible Contents

An indirect consequence of the last requirement is the necessity to use a special kind of prototyping in the development process. More specifically, “disposable” releases are developed to detail and validate the customer’s requirements. The customer describes the basic functionality, and prototypes are rapidly developed for demonstration purposes. This means that prototyping drives the communication with the customer. The intervals between such releases are relatively short. The time plan for the sequence of releases and their evaluation is more important than planning the requirements for a release. This means that a release is not defined by previously specified contents, but merely by a fixed deadline by which the release should be ready. Single features that cannot be completed by that time simply move to the next release. The requirements for the next release have to be variable to account for continuous market observation and prioritization of features. Features can either be delayed to a later release or moved to an earlier one. This is normally not a big problem since the intervals between the releases are short and their deployment is simple and does not cause any cost worth mentioning.

A successful acceptance test precedes the publication of a release in XP. However, nothing in an XP project prevents moving contents from one release to the next. The entire release plan is flexible. Accepting new or changed requirements in the release plan, and subsequently moving requirements as well as the pertaining acceptance test to later releases means that XP meets this requirement well.

Tools for Managing the Development Process

Web applications are necessarily developed using a very flexible approach, characterized by a high degree of reusability, agile process methods, close customer contact, and a large number of intermediate products. With regard to the tools used and the (intermediate) results produced, one can also observe a transition from the document-driven approach in traditional (rigid) software development towards a highly tool-supported approach in agile development projects. Agile approaches increasingly require tools, e.g. for requirements management, planning, design/implementation, test planning and implementation, and error handling as well as continuous configuration management.

Project Management Tool

We use Redmine which is an open source, web-based project management and bug-tracking tool. It includes calendar and gantt charts to aid visual representation of projects and their deadlines. It supports multiple projects. It is cross-platform and cross-database. Following are some of the salient features : Multiple projects support, Efficient Tasks Management, Flexible role-based access control, Issue tracking system, Gantt chart and calendar, Documents & files management, Feeds & E-mail notifications,  Per project wiki, Per project and per task discussions,  Efforts tracking, and Scrum support.

Source Code Management Tool

A Source Code Management tool is an important tool to support an orderly project process. Since many Web projects start small and then successively grow, it is important to use source code management systems from the very start of the project. Changing to source code management later on would be costly and time-consuming. Moreover, the evolution history cannot be tracked unless one uses a tool from the start of the project.

We use Git for source code management. Git is a distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do. Several high-profile software projects now use Git for revision control, most notably the Linux kernel, Perl, GNOME, Samba, X.org Server, Qt, One Laptop per Child (OLPC) core development, VLC, Wine, Ruby on Rails, and the Android mobile platform. Its highlights include: Distributed development, Strong support for non-linear development, Efficient handling of large projects,  Repositories can be published via HTTP, FTP, rsync, or a Git protocol, Cryptographic authentication of history,  Snapshots directory trees of files,  Garbage accumulates unless collected, Pluggable merge strategies .