Using Agile Processes and Modeling To Build Enterprise Applications

Abstract

Software development methodologies have been with us for a long time now. These methodologies typically tend to include a process, modeling techniques, or both. Some examples of the past and present methods include Structured Systems Analysis and Design Methodology (SSADM), Object Modeling Technique (OMT), the Rational Unified Process (RUP), and many others. Recent studies have shown us that the traditional approach of doing big requirements up front (BRUF) or big design up front (BDUF) using a waterfall approach such as SSADM not only can result in a significant waste of time and effort but also can cause many software developments projects to be challenged and/or fail entirely. This article looks at alternative approaches to BRUF and BDUF that can help minimize some of this wastage for enterprise software application development.

Most of material in this article has been taken directly from the book, Agile Java Development With Spring, Hibernate and Eclipse.

The Problem

One organization that actively researches causes of failures in software development projects is The Standish Group. For example, its CHAOS report from year 2000 reflects that 23% of software projects in that year failed and 49% were challenged. This organization has been publishing similar reports since 1994. As another example, 1998 showed similar results, in that 28% projects failed and 46% were challenged. Another set of statistics published by The Standish Group is even more astonishing; these show the usage of features built into applications. According to The Standish Group, 45% of an application's features are never used, 19% are rarely used, 16% are sometimes used, 13% are often used, and finally, 7% are always used. These numbers simply boggle the mind because a big percentage of features built by developers are almost never used!

While this is just one source of information, it does match what I have seen in my 20-year career in information technology. Now that I have reviewed some problems with BRUF and BDUF, I'll look at the potential solution.

One Solution

The Standish group also provides ten factors for success. Called the CHAOS Ten, some of the top factors include executive support, user involvement, experienced project manager, clear business objectives, and minimized scope. My personal experience with cancelled, challenged, and/or failed projects matches very closely to these four success factors.

In 2001, seventeen methodologists came together to unify their methodologies under one umbrella; they jointly defined the term, Agile. The outcome of this was the Manifesto for Agile Software Development, a set of values and principles for these agile methods. The term agile incorporates a wide range of methods; these include Extreme Programming (XP), Scrum, Feature Driven Development, Agile Modeling, Crystal, and a few others. Many methodologies tend to include both process and modeling, since they often are complementary techniques.

Since agile methods tend to follow a common set of principles and values, one unpublished benefit of agile methods is that you have the option to pick and choose from various techniques and tailor them to your environment. In this article, I will do just that, as I look at using Extreme Programming (XP) and Agile Model Driven Development (AMDD) for enterprise application development. While XP provides a full software development lifecycle, AMDD provides guidelines for modeling. However, the focus of this article will be slightly more on AMDD than XP, since XP is a full lifecycle process with social aspects to it that are outside the scope of this article.

Using XP for a Software Development Process

XP is a disciplined and streamlined, full lifecycle development process created by Kent Beck, Ward Cunningham, and Ron Jeffries. There are entire books on XP, so I'll provide a summarized version of my interpretation of this method.

XP projects typically begin with the users providing requirements in the form of a few to several dozen user stories to make a good release. User stories are one- to three-sentence feature requests written by the customer (end user, business analyst, or another project stakeholder). The user stories are then prioritized by the customer and grouped into iterations (in a release plan) with the highest priority user stories developed first. The result of each iteration is a small release consisting of production-ready (that is, acceptance tested) code for the user stories implemented in that given iteration. Figure 1 shows a rather simplified visual representation of an XP lifecycle.

Figure 1. A simplified representation of the XP lifecycle

A common theme found in Agile methods is the notion of shorter and more frequent cycles for various aspects of software development projects. In the XP world, this includes the following:

• Shorter releases (for example, two to three months)
• Shorter iterations (for example, one to three weeks)
• Shorter build times (for example, ten minutes)
• More frequent integrations, anywhere between once to a few times per day, or even automatic continuous integration every time code is checked in

The other important aspects of XP include having the development team (developers, testers, project managers) in the same room with the customer or a representative, on-site. The idea is to have easy access to each other, since communication is a key factor for success on XP projects.

XP also emphasizes simplicity. For example, Kent Beck states in his book, Extreme Programming Explained (2nd Edition), "What is the simplest thing that could possibly work?" For designing software applications, this is reflected in the form of incremental design or as Scott W. Ambler (Agile Modeling) likes to call it, "just-in-time design." The idea behind this is to do some big-picture architecture and design up front but leave the detailed design for when it is needed, for example, during an iteration.

There are many other aspects to XP that I have not covered here in the interest of brevity; some of these include pair programming, sustained pace, collective code ownership, and so on. Also, it is important to note that XP isn't an all-or-nothing proposition. In other words, you don't have to adopt all of XP's practices in your project. For example, in a recent email conversation with Mike Cohn (author, User Stories Applied, Addison-Wesley), he wrote, "I encourage teams to start with Scrum but to then 'invent XP' meaning I want them to come up with the appropriate XP practices for their environment." In short, if XP is something you are interested in using, I encourage you to research XP either via related books or Web sites such as extremeprogramming.org, xprogramming.com, and xp123.com.

Next, I will look at some modeling techniques.

Using AMDD for Modeling Guidelines

According to thefreedictionary.com, a model is "A preliminary work or construction that serves as a plan from which a final product is to be made ... used in testing or perfecting a final product."

In this article, I use the word model loosely instead of using words such as diagrams and/or artifacts, since it also ties into the term, model driven development (MDD), explained later in this article.

Agile Modeling, created by Scott W. Ambler, is a set of values, principles, and practices for modeling in an agile manner. AMDD is a subset of Agile Modeling and provides effective (and agile) practices for Model Driven Development; one example of MDD is the Object Management Group's (OMG) Model Driven Architecture (MDA). Instead of creating extensive models, AMDD recommends creating "good enough" models. AMDD encourages modeling activity at two levels: initial modeling (for example, before an XP-style release begins), and model storming (for example, during impromptu design discussions in an iteration).

The initial modeling activity typically includes requirements and architecture-related modeling. For example, the requirements modeling may include usage models such as user stories, a domain model, and user interface (UI) models such as UI prototypes and a storyboard (also known as UI flow map) . The architecture modeling can include a high-level architecture diagram accompanied with some initial discussions about scalability, reliability, security, and so on. I like to refer to the models produced from this exercise as release-level models since these tend to be higher level and conceptual in nature and impact the application as a whole, for that given release. For individual iterations, the models have more details and tend to be more physical in nature. Some examples of models in this category include CRC cards, UML class diagrams, and so on; these can be viewed as iteration-level models. Figure 2 shows some of the choices of models available to us using AMDD with an XP slant.

Figure 2. Choices of release- and iteration-level models

There really isn't much more to AMDD than this, so let's look at how you would use it in practice by reviewing some examples of release- and iteration-level models next. But first, let's define a sample application you can use to demonstrate your examples. Let's assume that a fictional organization wants to build a time sheet system to manage its hourly staff. To get things started, the customer may define a problem statement:

Problem Statement: Our employees currently submit their weekly hours worked using a paper-based time sheet system that is manually intensive and error-prone. We require an automated solution for submitting employee hours worked, in the form of an electronic time sheet, approving them, and paying for the time worked. In addition, we would like to have automatic notifications of time sheet status changes and a weekly reminder to submit and approve employee time sheets.

Next we may give our application a name. "Time Expression" seems like a catchy name, so let's go with that. Now, we are ready to move forward with some release-level modeling.