Introduction to an Integrated Development Methodology

This is the first of a two-part series that explains a process for applying a structured approach to application development through a defined methodology. Using a methodology can alleviate bottlenecks in production, deliver a concise product, and expedite time to market.

This first article covers the basics of methodology: what it is and its overall purpose. It also explores the use of modeling and how it supports certain phases of the methodology (you'll see examples of this in the next article). Finally, it presents an overview of the methodology that will be used throughout the remainder of this series.

In the second part of the series, you'll step through the methodology piece-by-piece and discuss how the outcomes of each step fulfill the needs for various players in the application development process (business managers, clients, project managers, technical managers, IT). The article will use example application to demonstrate how to apply a methodology.

This series is not intended to cover every aspect or low-level details of using a development methodology. Nor is this meant promote or tie this methodology to a specific technology, but way to customize your methodology for developing applications in any language, such as J2EE or Macromedia ColdFusion or Macromedia ColdFusion MX through ColdFusion. It is an atlas, or roadmap, meant to cover your cross-country trip to a better application. Using the following principles, you will decide how to navigate each town and village en route to your destination. Like every roadmap, there are always additions or other routes to be added.

Onto the Basics

In this article, you will explore three major topics as follows: the basics of methodology, the integrated methodology, and UML:

1. Basics of Methodology
   • Introduction to Methodology
   • Benefits of Methodology
   • Choosing the Right Methodology
   • Methodology Failures/Success
2. The Integrated Methodology
   • Background and Purpose
   • Steps
   • Users
   • Variances
3. UML
   • Using Modeling to Assist
   • How to Use UML

Basics of Methodology

Introduction to Methodology

Before you run off screaming at the thought of creating volumes of paperwork, let me assure you that methodology is not the mere creation of work. It is worth every minute and every cent you put into it. While "mountains of paperwork" is a common perception, methodology should really be thought of as a structured approach by which, through its steps, an organization can properly design, construct, and deploy quality applications on time and within budget.

A good methodology consists of attributes that satisfy both the technical and managerial aspects of systems development. It should support workflows that make sense in the context of producing a quality product. For example, using a visual modeling platform, which will be introduced later, the development team has the communications vehicle to represent different views of the system. These views will provide a common ground for each distinct stakeholder (business, client, and IT) to relate to.

It is important to understand that users have only one real question, "Can I use this system?" And that sponsors have only one real question, "Are my users happy?" Notice that neither of those questions is, "Does it work?" You may have developed a working product, but have you answered the real questions or delivered the needed product?

Too many times, developers perform tasks and produce deliverables that please no one but the project leadership (technical and managerial). Or they meet user wish lists without conforming to business-environment demands. An integrated methodology that addresses diverse agendas can ensure that the end product meets client, business, and IT needs. Clearly, a methodology cannot stand on its own. It needs to be supported by people who believe that the process is worth doing.

Benefits of Methodology

Why would you even want to use a methodology? One of the greatest benefits is the process of working through each of the individual steps. Each step performs a set of tasks and includes a set of deliverables. For example, a "Requirements Gathering" step might consist of a task such as gathering user expectations and user requirements. It might also include a set of deliverables, such as user expectations of site load and performance. Additional methodology benefits include:

• Constant awareness of the project status. Because a methodology allows for constant sign-off of steps and checkpoints, the client can be constantly informed about where things are in the project. Additionally, checkpoints encourage communication between the business and technical managers, which goes a long way toward minimizing surprises.
• Ability to Fire and Forget. During the design/modeling phases, the developer creates several visual views about the objects and processes that make up the application as well as the dependencies. Equipped with these views, a developer can much more quickly reacquaint him or herself with the project at a later date.
• Efficient Communication. These visual views also act as avenues for communicating the needs, state, functionality, and structure of the application through the entire organization.
• Efficient Use of Time and Money. The slated requirements and design steps of a development methodology offer a couple of key benefits. Some studies attribute as much as 85% of software revisions to poor requirements [Wiegers, Karl E., Software Requirements, quoting Dean Leffingwell, (Microsoft Press, 1999) 12]. Having proper requirements and a solid design phase will help minimize this number. Another report estimates the cost to change a requirement at about 200% more than initial cost of the requirement [Wiegers, Karl E., Software Requirements (Microsoft Press, 1999) 15]. While having slated requirements and design steps will not eliminate changing requirements, they will provide the necessary structure to ensure that requirements are mature before development starts.

As you examine the marketplace, you will notice that there are several methodologies available, each with its own suggested steps and approaches. The next section offers some guidelines on choosing the right one.

Choosing the Right Methodology

When you look at the software applications out on the market today, you see one common feature. They are all different. All chuckling aside, this is a profound statement. You'll see everything from a Web application that consists of one page that has one article displayed on it to an application that runs the re-entry of a space shuttle. Each application has unique needs or requirements. As a result, the exact same design and development approach will not work for every project. Thus the need for an integrated methodology, or a methodology based on principles that are used to determine what tasks to use and when.

There are several methodologies out on the market today, dealing with a number of environments, situations and audiences. The different methodologies suit applications with different needs and demands. Some of the differences that can be accommodated in a methodology include:

• Flexibility of the underlining architecture
• Maturity of requirements at certain stages
• Time span of projects.

To illustrate, consider at an application that has an extremely low tolerance for errors, such as an application for the space shuttle or an airplane. For such an application, a methodology that forces requirements to be completely defined up front, folds in testing at every level, and doesn't let the next step happen until confirmation by multiple senior consultants would be ideal.

I suggest, however, that you don't make a methodology decision based solely upon the technical issues. Remember to consider issues related to people, such as how easy is it to use and whether the steps and documentation are structured to truly assist those who have to use it.

The methodology presented in this article series can be used by, but not limited to, applications that fit the following descriptions.

1. Needs multiple iterations (releases)
2. Requires an adaptable methodology (both time and steps)
3. Is language independent

A good resource on the topic of choosing or classifying a methodology is the book Rapid Development by Steve McConnell.

Why remaining distant from the specific language used to build an application, in it is important to note that there is tie between a methodology and the development language used for the application. Methodologies each follow certain objectives and patterns such as building in iterations or in completely synchronized steps. These base objectives also provide a set of boundaries in which development languages must be capable of supporting. For example a methodology that supports the deconstruction of an application into individual modules (classes, object or packages) is geared to be used with a development language that has this sort of base unit in its language construct.

Methodology Failures/Successes

In discussing development methodology at a high level, let's discuss what makes a methodology implementation a failure or success.

First—failure. The prime suspect in failure is the use of a methodology that is too "heavy" or involved for the project. This often results in missed project deadlines and late deliverables. In one particular case study, the project and technical managers made a decision early on to follow a modeling and a very step-intensive methodology to the "T," even though it was not appropriate for the project. This created a ton of unnecessary paperwork, required a large number of administrators to facilitate the construction of paper deliverables, and pushed out the project release by months.

Conversely, another suspect in methodology failure is not using a methodology that is not robust enough for the project. During one of my assignments, I was presented with a project plan that showed the tasks that were needed and then told to construct my site. Because of the system complexity, this quickly turned into a code-and-fix approach.

Both of these projects were lead by great people that were competent at what they did. The issues lay not with understanding how to use a development methodology, but instead with viewing methodology as a set of fixed regulations to be followed regardless of the unique requirements of the project.

Success with a methodology begins with knowing that you need to find the one that fits your environment. The next key is understanding that it is all right to modify an existing methodology to fit your current environment.

I recommend establishing which methodological approach will be used at the start of every project, even if that means creating one yourself. Once that decision is made, you can then plan the resources necessary to manage it. Be aware, however, that changing a development methodology late in the game can be very costly and in some cases causes a reshuffling of the in-place infrastructure.

The Integrated Methodology

The integrated methodology on which this article series will focus has been derived from various methodologies (Spiral Methodologies, Unified Process Model), the long-term experience of senior people in the industry, recognized best practices (iterative development, small design teams), and the specific impacts that the Internet brings to the software development arena (short time frames, constantly changing in requirements). It is designed to be either language independent or tied to the language that is used. See the Variances section for an example.

Some of the core pieces of this methodology have roots in application development in the client/server environment. In addition, this methodology has seen use in many of the major accounts that the Macromedia Partner Enablement group works with, being refined with each assignment.

When this methodology is presented to clients and developers, it should be described as a skeleton that includes some major steps with flexible subtasks. All that is required is that the deliverables and checklists for each step are completed.

The following diagram shows the component steps for this methodology. The next article discusses each step in detail and provides examples. Please note a couple of things: each step is set up to provide base objectives, and each application uses its own subtasks to accomplish the objectives. Additionally, the interactions between users are not shown but are needed to successfully complete each step.

Figure 1: Methodology component steps.

Steps

Below is the list of steps for this methodology. While each step does have a main objective that applies across projects, each specific application that is built using this methodology sets its own subtasks. Each step includes a set of deliverables that are the responsibility of the respective project participants. For example, the architect will work with the final model (Step 4.1) to translate it into language-specific lingo, while the project manager will use the same model to communicate with the architect on the status and functionality of the system. How a step is executed or to what degree is not as important as what it produces.

I have also noted whether each step is programming-language dependent or independent.

1. Requirement Gather — programming-language independent
2.1 Physical Architecture — programming-language independent
2.2 Primary Model — programming-language independent
2.3 Project Plan — programming-language independent
3.1 Object Model — programming-language independent
3.2 Visual Model — programming-language independent
3.3 Process Model — programming-language independent
4.1 Final Model — programming-language independent
5.1 Translate Model to Programming Language — programming-language dependent
6.1 Construct Site — programming-language dependent
6.2 Build Technical Architecture (Optional) — programming-language dependent
7.1 Testing — programming-language independent
8.1 Deploy Site — programming-language independent
9.1 Reporting and Refinement — programming-language independent

Users

A variety of participants are involved for each step, some executing the step and other just using the end result. Possible participants include:

1. Client
2. Project Sponsor
3. Project Manager
4. Technical Manager
5. Architects
6. Technical Leads
7. Developers

Though Figure 1 presents this methodology as a top-down, stepped approach, in reality it is to be used iteratively, depending on the size of the project. While a small site will walk through each section without needing to break down the functionality into phases, a large site may need a different approach, for example, breaking down the requirement-gathering section into smaller phases such as content management and e-commerce.

Note the flexibility of this approach. Step 5 can be intermixed with steps 2, 3, and 4, which will cause the models to reflect the programming language in which the application is to be implemented in. For maximum flexibility, use language-independent models by waiting until step 5 to translate the models to the language on which you are implementing. This keeps the preceding models focused on describing the logic.

UML

Certain steps in the methodology call for the modeling of the system requirements. I use UML notation through this series, which stands for Unified Modeling Language. UML is a language unto itself that allows us to view the application before a single bit of code is written. The benefits to using UML include saving time in construction because potential flaws can be identified before they actually occur and achieving consistency in communication protocols between project participants. In the next part of this series, I will illustrate the types of UML models that I use to help describe the application.

How to Use UML

A good reference for looking at the UML is UML Distilled by Martin Fowler. This book offers a great introduction to a complex and feature-rich language. Using the UML language, you can create many different views into your application, such as state diagrams, deployment diagrams, and class diagrams. Each of these views helps clarify an aspect of the application.

Building a view for the sake of building it, however, is a sure way to waste time and effort. My style is what I call "UML Lite." I use 30–50 percent of the available diagrams to help streamline the modeling process. However, this doesn't prevent me from using an additional diagram if it is needed; it just keeps me focused on defining the core functionality of the application. To quote Ed Donohue, Director of Emerging Technologies at RS Technologies, "Elegant architectures are long remembered while the most complex quickly forgotten."