WebSphere

Software complexity is ever increasing. The J2EE platform addresses application architecture complexity by providing a set of abstractions for multitiered enterprise apps. IBM Rational Application Developer for WebSphere software provides the developer with a rich integrated development environment and a set of tools targeting the artifacts needed for J2EE programs. But between the developer and the final application is another element of complexity: coordinating the software development team.

The challenges facing software development teams are also mounting. Business pressures drive teams to address new requirements quickly and deploy that software reliably from development to operations. Corporate governance standards increasingly require audit trails for any changes to a system. Traditional forms of collaboration, such as the face-to-face discussion, are vanishing as teams are distributed geographically.
Nowadays a change management system and process is necessary for the productivity of development teams. It can give every member of the team answers to the “Five Ws” regardless of their location or role in the project:

• Who requested the change? Who coded the change? Who reviewed and approved it?
• What changed in the source code? What set of changes went into this build? What am I supposed to do next?
• Where exactly – which components, which modules – were the changes made?
• When were the changes made? When were they first deployed?
• Why were the changes made?

A change management process that answers these questions keeps the development team aligned to the same goals, and aids rather than burdens the developers; it will go a long way toward addressing the challenges teams face.

Unified Change Management
There are two fundamental kinds of objects in change management: activities and artifacts. Activities describe and track the work done by a developer – a word used broadly here to include anyone on the team who produces artifacts. Artifacts are the persistent representation of the system, including source code, models, build scripts, documentation, test code, etc. Unified Change Management (UCM) is a capability for managing artifacts with IBM Rational ClearCase and managing activities with IBM Rational ClearQuest.

Activity-Based Development
Typically, more is asked of a development team than it can deliver. Remembering all the requests, and understanding which tasks were undertaken and why, is essential for high-performance teams. All the requests, whether they are new requirements, customer-reported bugs, or automated test failures, can be captured and tracked as activities. Rational ClearQuest is highly customizable and can reflect a wide variety of activity definitions and processes.

A simple process might involve a single kind of record – for example, a defect – with only a handful of fields, perhaps a unique ID, a concise one line headline, the owner responsible for addressing the issue, a longer description that might include steps to reproduce the problem, and a state representing where this activity is in its lifecycle.

A more complex activity process might use specialized activities for defects and enhancement requests, each with different fields, actions, and states. Groups of related activities can represent different aspects of the development process – customers report “problem” activities, developers produce “fix” activities, and testers verify fixes by completing “test” activities. Business rules can be written to create and assign the test activity automatically when the fix activity is completed, and perhaps the problem activity is only marked complete after the fix has been deployed into production.

The states of an activity and the actions used to transition between them are completely customizable, but UCM asks that each state be categorized into one of four state types: Waiting, Ready, Active, and Complete. These state types are used by the system to provide developers with their to-do list – the set of activities they should be working on. Waiting activities can’t start until some precondition is met, work can begin on ready activities, active reflects work is in progress, and complete indicates that there’s no work left. A complex activity process can map multiple states to each state type; for example, “fixed,” “no plan to fix,” and “not reproducible” could all be states of the complete state type.

Rational ClearQuest’s flexibility extends beyond the definition of record types, their fields, and state transition diagrams. The visual representation of each kind of activity can be defined using a rich set of controls. Business rules can be implemented to constrain the legal values for a given field when the activity is in a particular state, to supply default values for fields or change fields, to create new activities, or to interface with external systems.

The activity data is only useful if relevant activities can be found and Rational ClearQuest has easy-to-use query capability. However, the casual user may not know the best way to find a particular set of activities. Rational ClearQuest allows query definitions to be saved and shared across the team. Chart and report definitions can also be saved.

Developers organize their work on artifacts with activities regardless of the process implemented in Rational ClearQuest. As mentioned above, the activity state types are used to define a built-in to-do list query for every developer. Developers select activities from their to-do list to begin work. As the developer modifies artifacts the new versions are recorded in the activity’s change set.

Parallel Development
Whenever multiple developers are modifying a set of artifacts there’s a tension between integrating the changes from all the developers and providing each developer with a stable, albeit isolated, configuration on which to work. UCM projects define the way in which developers share changes with each other. A UCM project consists of a group of streams and policy settings that controls the workflow in the project. Think of a stream as a line of development with a known, stable starting point across a set of artifacts followed by a number of changes to those artifacts.
UCM organizes artifacts into components that are trees of directories and files under a single root directory. Each artifact has a history of versions that has been created over time, and similarly components have a history of baselines. A baseline is a stable “snapshot” of the artifacts in the component, and identifies one particular version of each file and directory. A stream selects a baseline for each component it wants to see, and then accumulates a set of activities that collects the changes made to files on that stream.

UCM offers three kinds of projects, offering different levels of integration and isolation:

• Single stream
• Traditional parallel development
• Stream hierarchy

Single stream projects are the simplest in UCM, and provide the least isolation between developers. They’re most appropriate for small teams working closely together, or teams where each developer tends to work on separate components. Developers each have their own file area – called a view in Rational ClearCase – containing the appropriate versions of the files in the project. Artifacts must be checked out before they can be modified, and these checkouts are private to the ClearCase view. However, when changes are checked in they’re immediately visible to everyone else in the project.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...