Section 13.1. Established Project Management Methodologies

13.1. Established Project Management Methodologies

Like any engineering, manufacturing, or product development project, a software project must cope with the conflicting requirements of time, resources, and functionality. However, software projects are often somewhat special in that they exhibit a number of problems not normally found in other industries. In particular, enterprise software is tightly coupled with the internal organization, processes, and business model of the enterprise, as we discussed in Chapter 1. Naturally, this means that the interfaces between enterprise software and human users have a much higher complexity than interfaces between human users and other types of complex technologies.

Take, for example, a sports car with an extremely sophisticated engine, anti-sliding system, and exhaust reduction systemat the end of the day, the interfaces exposed to the user are relatively simple: the user controls the technology through the use of the steering wheel and brakes and is typically not aware of the highly complex technology hidden under the hood.

Compare this, for example, to a software system such as a CRM system or an ERP package. Such a system requires much more complex user interfaces, and interaction with such a software package is much more direct and frequent in the day-to-day business of the end user. Thus, enterprise software projects usually require much tighter interaction with customers during the development phaseafter all, it is the customer's business that we are modeling one-to-one, with all the corresponding details, day-to-day operational processes, and special cases.

Unfortunately, enterprise software projects very often suffer from the I can't tell you what I want, but I will recognize it when I see it phenomenon. Early project management methodologies that were developed specifically for software development projects where not able to cope with this issue. Most notably, the popular waterfall development model implicitly assumes that customer requirements are fixed at the beginning of the projects and that changes to these requirements are the exception, not the norm. The phases of the waterfall model include requirements specification, high-level and detailed design, coding, module and integration testing, and acceptance testing. The waterfall model is based on full documentation at the completion of each phase, which must be formally approved before the next phase is entered. The final delivery is one monolithic result.

Because of the limitations of this approachin particular the inability of the waterfall model to cope with unstable requirementsa number of more evolutionary approaches for software project management have emerged over the past 20 years. These more incremental or iterative models are built on a philosophy of interaction and change, which is much better suited for coping with unstable functional requirements. These models are typically based on frequent releases, which are used as the basis for getting early and continuous customer feedback. Instead of delivering the first work result after months or even years (as in the waterfall model), the iterations of these evolutionary approaches typically last only a few weeks (or even days).

An early representative of these development processes was James Martin's Rapid Application Development (RAD), which is based on incremental stages. Each increment represents a short-duration waterfall. Barry Boehm developed one of the first fully evolutionary models, widely known as the Spiral Model, which is based on a set of full development cycles that continually refine the knowledge about the final product and help control project risks.

A number of very complex and sophisticated development process models have been commercialized in the past decade. Most of these models are based on an iterative approach in combination with some form of object-orientation, such as using UML as a formal modeling language. Probably the most prominent representative of this class of development processes is the Rational Unified Process (RUP), which is now owned by IBM. RUP is iterative, depends heavily on visualization through UML, and uses component-based architectures. In the same arena of relatively heavyweight iterative development processes, we would also find Dynamic Systems Development Method (DSDM), Microsoft Solution Framework (MSF), and Catalysis.

In the wake of the fast-moving Internet revolution of the late 1990s, a number of approaches emerged that took a much more lightweight approach to iterative software development, often referred to as agile development. In 2001, several representatives of this school of thought issued the Manifesto for Agile Software Development.^[1] A prominent representative of these new lightweight methodologies is Extreme Programming (XP), which heavily relies on peer programming (i.e., two developers jointly working on a piece of code based on user stories, one focusing on the coding, the other on the design and testing of what is being developed) and write-test-cases-before-writing-the-actual-code. With XP, all new code is immediately integrated, and comprehensive test runs are executed every couple of hours.

^[1] www.agilemanifesto.org

Robert Martin's dX method aims at covering the middle ground between heavyweight methodologies such as RUP and lightweight methodologies such as XP. dX is a minimal implementation of RUP, based on index cards, an amalgamation of use cases and CRC cards (Class-Responsibility-Collaboration). Figure 13-1 provides an overview of some of the existing methodologies and how they relate to each other.

Figure 13-1. Different project management methodologies cover a variety of different requirements. They range from lightweight to heavyweight approaches and from linear to iterative models.

Add Service Orientation to Your Favorite Project Management Methodology

All of these methodologies have their strengths and weaknesses, and their suitability heavily depends on the project contextincluding scope, complexity, and duration of the project, quality requirements, strategic importance, resources available, stakeholders involved, and so forth. This makes it difficult, if not impossible, to give generic recommendations for the right approach. Your methodology choice will depend on your own experience and established best practices. However, given the complex nature and frequently changing business requirements that we find in the context of enterprise SOA projects, we assume that the chosen approach will support iterative development, which is essential for coping with complexity and unstable requirements. Given the strategic importance of enterprise SOA projects, we expect the chosen methodology will tend a little bit more toward the side of the heavyweight processes.

Nevertheless, it is important to realize that SOA-driven project management does not require a new methodology. The proposals for incorporating aspects of service orientation into your project management are based on the assumption that you are choosing an established methodology, which will then be enhanced to make use of service orientation on the project management level.