Development Methodologies

In most real-world problems, the requirements of a system are never complete at the start of the solution. Customers always want changes to be incorporated during the life cycle of the project development and beyond. This often leads to chaos right through the different phases of the software and continues into production. Methodologies have evolved to discipline the software development process and make software development more manageable, resulting in a predictable solution. But most of the methodologies are heavy in nature and don't solve the problem of software development effectively. Most of the methodologies are predictive in nature (that is, all parts of the software are planned to minute detail), which involves a lot of time. This works fine until the changes to the requirements start rolling into software development. Apart from being predictive, most heavy methodologies are process oriented.

The lightweight methodologies work toward eliminating these deficiencies. In the next section, we go over one of the most popular lightweight methodologies that's evolved in the last few years: extreme programming or XP. Following that, we discuss the Rational Unified Process (RUP) methodology, which might not be categorized as light, but answers some of the questions posed by the heavyweight methodologies. RUP is extensive in nature, but at the same time it can be used in parts, too.

Extreme Programming—Core Practices

Extreme programming (XP) was developed in response to the situations mentioned earlier. XP gives an effective solution to all systems in which a change in requirements is a routine affair. XP is adaptive in nature, accepting changes throughout the development life cycle. The foundation of XP is based on the following values: simplicity, communication, feedback, and courage. Based on these four values, the XP outlines 12 core practices for a successful execution of a project. Most of these practices are time tested but are often forgotten. XP makes the most of these core practices by integrating them intelligently. The core practices advocated by XP are as follows:

• Emphasis on teamwork— XP, unlike heavy methodologies, is people oriented rather than process oriented. The emphasis is on every contributor being part of the team, including the customer, who oversees the entire development. The presence of an onsite customer improves communication because he can address the requirement questions as and when they appear.

• Planning game— Also known as the planning process, this helps to steer the project to be on time and cost effective. This stage determines what will be achieved and in what timeframe. The planning game may involve multiple plans; that is, a release plan and multiple iteration plans. A release plan may contain the software features to be delivered and the total time for delivering them, whereas a iteration plan outlines short-term goals; that is, those on a weekly or biweekly basis.

• Testing— XP believes in continuous testing for keeping the developed software in a stable condition right through the development stage. It forms the foundation of development and all programmers are responsible for writing test cases for their code. The XP customer defines the acceptance tests that the developers have to take into consideration.

• Small releases— Because iteration planning forms the core of the planning game, it allows XP projects to roll out releases at regular intervals. There are frequent builds, as frequent as daily, through the development life cycle and these builds are also made for the end user.

• Simple design— XP emphasizes a simple design that conforms to current user requirements without much thought about what the customer's future needs would be. XP believes in evolution of the software through refactoring.

• Refactoring— This provides design improvement and accommodating new business requirements, thereby adding business value in every iteration. This is complemented by continuous testing.

• Continuous integration— XP advocates multiple builds during the course of development, and this is made possible by continuous integration of the components developed by the team. This keeps the team in sync and helps developers find out about loose ends between them at a very early stage.

• Metaphor— This is a common vocabulary for system names for effective communication within the team.

• Code ownership— There's no single owner for a piece of code and more than one programmer is aware of every single piece of code. This enables changes to be incorporated at the earliest possible time without waiting for the original developer.

• Pair programming— XP advocates using two programmers for developing a business function. This improves every facet of the development life cycle—better design, better testing, and better code.

• Coding standard— This facilitates easier development and maintenance. It complements collective code ownership.

• No overworking— XP emphasizes regular working hours over a long period of time, which sustains the same zeal in the entire development effort.

As you can see, some of the steps have been adapted from other methodologies. The software evolves through the many steps, relying on simple design and improvements through the many cycles of re-factoring and adding business value in every iteration. This helps to build a very disciplined and adaptive design methodology for complex enterprise problems.

• Ant (http://jakarta.apache.org/ant/). This is an XML-based open source utility that aids in continuous integration.

• EJBgen (EJB component classes generator shipped with WebLogic Server). It also comes with several other utilities that aid in development and deployment.

• JUnit (http://www.junit.org/). This is a unit-testing tool.

• JMeter (http://jakarta.apache.org/jmeter/). This is for doing performance testing.

Rational Unified Process

The Rational Unified Process (RUP), as its name suggests, was developed at Rational. It complements the Unified Modeling Language (UML). This process is a framework that can be used to model different processes that constitute the software system. Table 5.5 lists the fundamental workflow processes that govern the RUP.

Table 5.5. RUP Workflow Processes

Process	Description
Business Modeling	Understanding the business needs
Requirements	Translating the business needs identified into well-defined requirements that identify a possible software system
Analysis and Design	Translating the requirements into a system architecture
Implementation	Translating the design into software that conforms to the requirements
Testing	Validating the software against the requirements
Configuration Management	Maintaining versions of the different elements that constitute the software solution
Project Management	Managing the different teams through the development life cycle
Environment	Runtime environment maintenance
Deployment	Rolling out the software for production use

These processes are not governed by time. They extend during the different phases of the project. RUP defines four phases through which the processes in Table 5.5 are executed. The phases identified by the RUP are

• Inception— Determines the project objectives

• Elaboration— Helps in a complete understanding of the problem at hand

• Construction— Builds software artifacts

• Transition— Adds improvements to the developed software

RUP helps manage projects through the many iterations of the processes listed in Table 5.5 from inception to the transition phase. The four phases help to define milestones during the software development and also define a boundary for producing different artifacts. The biggest advantage of this process is its capability to respond to changes in the business needs.

RUP, similar to XP, provides an excellent process framework for developing J2EE applications. For a detailed discussion of RUP and the tool support for incorporating in WebLogic Server development, refer to the Web site http://www.rational.com/products/rup/index.jsp.