 | Level: Introductory Brenda Cammarano, Market manager, IBM Rational
15 Apr 2005 from The Rational Edge: Geographically Distributed Development (GDD) is a mode of software development that allows businesses to coordinate project teams located in different regions, countries, and time zones. This article presents a generic scenario that illustrates how GDD operations proceed over a 24 hour cycle, unifying the efforts of teams based hypothetically in Bangalore, India, and Denver, USA.
 Geographically Distributed Development (GDD) is rapidly transforming IT strategies and software and systems development processes across enterprises, large and small. GDD embraces a wide variety of scenarios in which the personnel involved in a software or systems development project are extended beyond the traditional setting of a single building or campus. Typical GDD situations involve companies with geographically distributed sites -- city-wide, regionally, nationally, and internationally -- as well as partner relationships and various outsourced relationships. Successful GDD allows teams to develop high-quality software and systems faster, and at a lower total cost, leading to improved business agility and a greater capacity to handle the pressures of globalization and competition.
But the challenges of realizing those competitive advantages are significant. Chief among them is the need to communicate accurately and unambiguously across the barriers imposed by firewalls, distance, time zones, national borders, languages, or cultures -- or all of these factors. These issues are further compounded by the need to manage all dimensions of the software development lifecycle -- requirements, change and assets, testing, coding, etc. -- in a distributed environment via a repeatable process, while maintaining effective security.
Part I of this article introduced GDD and its business requirements, and presented an overview of how the IBM Software Development Platform can support a successful GDD strategy. Part I also touched on key strategic considerations like what projects are best-suited to a GDD approach.
Now, in Part II, I present an example scenario that illustrates some of the many possibilities for applying IBM Rational tools to support GDD.
Laying the groundwork for GDD
As I discussed in Part I, the distribution of teams across time and space introduces challenges and increases complexity throughout the software and systems development lifecycles. Among the issues that grow more complex in GDD situations relative to co-located teams (that is, teams that are located under one roof or in nearby buildings) are the implementation of standards, methodologies, processes, and best practices; portfolio management; effective requirements management; efficient knowledge and work transfer methods; and robust software change management. Increasingly, development organizations are turning to software tools to help standardize and guide their processes and improve team collaboration; given the complexities of GDD scenarios, the value of tools is potentially even greater.
Every GDD project embodies unique business and stakeholder needs. These needs, in turn, define the goals of the effort and the manner in which responsibilities for subtasks are allocated. For example, the way you choose to manage change to requirements in a GDD environment could differ greatly for a new system project compared to a legacy maintenance contract involving a third party. This is why GDD tools implementations are unlikely to be "one size fits all" solutions. Tools for GDD scenarios need to be configurable, because customizable product infrastructures and flexible ways to integrate the tools involved are necessary in order to optimally support different business needs.
But while every GDD project is unique, there are some commonalities. In many GDD scenarios, both local and remote development resources are involved. The kinds of roles and tasks that are most efficiently performed locally are those with a high degree of "client-facing" activity, such as business modeling, requirements definition, and deployment. Work that can be efficiently performed remotely includes code development and testing -- disciplines that relate primarily to the development team rather than the customer of the application. Both local and remote sites may need their own test / integration and change management processes. And while overall project management responsibility resides at the local level, some level of project management is often required at remote sites as well.
Network performance and server infrastructure is also a big factor in deciding how best to organize a GDD project. GDD project managers need to consider:
- The need and the ability for remote sites to maintain database servers, replicas of data repositories, and the like.
- The extent to which remote users, such as small teams in separate locations or individual developers working from home, will need to create, display, modify, and delete various project assets ranging from requirements documents to use case models, from code to test plans.
-
The potential for remote sites and users to utilize "thin client" technologies like Citrix, Windows Terminal Server (WTS), or Web clients. Thin clients can give distributed teams more flexibility and mobility, but may not support all the features of a tool's native interface.
Additional factors like network topologies and security policies can further complicate the configuration and deployment of GDD tools. Business needs and infrastructure capabilities will combine to help shape the optimal tools deployment for a specific GDD environment.
A GDD scenario
The GDD deployment scenario described here illustrates just one of many ways that IBM Rational tools can support a distributed team today. Our hypothetical customer is Alcrohm Corporation, a Fortune 1000 supplier of aluminum alloy products.
The project in question involves both ongoing maintenance and major enhancements to an enterprise-scale, custom software application. This mission-critical application unifies customer relationship management (CRM), proposal management, and contact management capabilities for sales and support teams in all three Alcrohm divisions (Industrial Products, Consumer Packaging, and Automotive Parts). The current version is a traditional desktop client/server application with a user interface written mostly in C++. Alcrohm must continue to maintain this code base in the immediate future. However, in parallel with the maintenance effort, Alcrohm plans to implement a new version of the application that will be accessible via a standard Web browser, coupled with Java server-side code and business logic. The new version will be much more cost effective to deploy and manage because it will eliminate the need for client installation and updates. It will also fit better with Alcrohm's longer-term goal of embracing service-oriented architectures (SOAs) across its global IT infrastructure.
Utilizing a 24-hour, 7 days-per-week (24x7) delivery model, the project involves two separate geographic locations: on-site, at Alcrohm's central offices in Denver, Colorado, USA; and off-site, at an overseas development center located in Bangalore, India. We'll call the on-site location "Site A" and the off-site location "Site B."
This kind of GDD scenario offers Alcrohm cost and schedule advantages like variable staffing, reduced labor rates abroad, and reduced time-to-market by keeping the project moving "around the clock" (that is, while development teams in the eastern hemisphere are at home or asleep, teams in the western hemisphere are awake and in the office). But with these benefits come increased risk. The project involves significant technical difficulties that would test even a co-located team's ability to collaborate efficiently, understand requirements, and deliver high-quality results. Alcrohm has chosen to put robust, integrated tools and processes from IBM Rational software in place to address these challenges and support a successful outcome.
Establishing roles
The in-house development team at Site A will focus on new feature development and related testing as well as build / deployment. The remote subcontractor at Site B is tasked with maintenance development and unit testing on the existing client/server application. That high-level breakdown of responsibilities has a pivotal impact on what roles, tasks, and ultimately tools will operate at each of the two sites.
Tasks to be performed at Site A include:
- Capturing requirements, creating requirements documents, and managing requirements
- System architecture and modeling
- Business analysis and high-level system design
- New feature development
- Component, functional, and system testing on pre-release builds of the new application
- Functional and system testing on maintenance releases of the current version of the application
- All build and deployment activities
- Project and portfolio management
Tasks to be performed at Site B include:
- Maintenance coding on the current, client / server version of the application
- Unit testing of components modified during maintenance coding
- Creating and modifying requirements for the maintenance phase of the project
After successful unit tests are run against the maintenance releases under development at Site B, Site B hands-off the code to Site A, which executes validation, functional, and system tests. Project specifications and changes to requirements, models, and diagrams related to maintenance releases of the existing application are communicated from Site A to Site B. Project management is a core competency handled at Site A, where all components of Alcrohm's application and resource portfolio are monitored.
These strongly partitioned roles allow Alcrohm to gain experience with GDD in general, and its off-site partner in particular, with comparatively low risk. If all goes well on this project, Alcrohm may choose to utilize other distributed development models in the future, such as component development of new features.
Determining asset locations and access
Now let's look at what assets will be needed at both sites. A key objective for Alcrohm is to be able to reference assets across the two sites. What tools are used and how they are deployed will depend largely on where critical development assets will be created and where they will be utilized.
Requirements for both versions of the application will be captured locally at Site A. Site A therefore needs read / write access to the requirements, as well as to business models and use case diagrams. Updating of requirements attributes, as well as most of the changes made to requirements, will also take place at Site A. Site B also needs read/write access to requirements. As they maintain the existing application over time, the Site B team will need to add requirements, modify existing requirements, add supplementary information to requirements documents, and assign attributes, such as priority, difficulty, and status. Team members at Site B will also need the capability to trace the relationships among requirements so they can gauge the impact of changes.
Both sites will require access to the shared code base, though the two teams will work on different branches. Both sites will also need to view, create, and modify change requests, enhancement requests, and defect reports.
To achieve this high degree of shared access, both sites will replicate critical data on local servers.
Deploying IBM Rational tools
Having determined what assets are needed at each site, Alcrohm then needs to find a way to distribute them. IBM Rational tools provide a wide range of possibilities for supporting communication and collaboration between Alcrohm's two sites. In fact, the products to be used on this GDD project are some of the same tools that many enterprises like Alcrohm already rely on to ensure high-quality results in their more traditional, co-located development projects:
- IBM Rational Unified Process®, or RUP® -- To support a robust, repeatable process. For many GDD projects, including this scenario, it's best to establish the workflows among disciplines first, and then configure the tools infrastructure to help automate the workflows. RUP embodies best practices and provides guidelines that support standardized, integrated, and repeatable processes, all of which are critical to the success of distributed teams. RUP also defines a shared vocabulary and clearly specifies project roles and responsibilities, all of which promote a common vision across distributed teams. And because it is Web-based, RUP readily supports distributed efforts. RUP then becomes the foundation for rolling out other tools.
- IBM Rational ClearCase® -- For secure asset management and overall process control. Without robust, secure asset management capability, most GDD projects would be too risky to undertake. Asset management ensures that only authorized persons can view or change project assets; it also provides the ability to reliably recover work lost in the event of an authorized user's mistake, such as the accidental deletion or overwriting of source code files. Asset management further provides the foundation for change control, auditability, reproducibility of builds, and traceability from executables or code versions back to requirements, change requests, and so forth. GDD teams require seamless coordination of assets and changes to assets across the distributed environment, along with the ability to work on different branches of a project simultaneously, to accelerate deployment via 24x7 development models.
In GDD scenarios like Alcrohm's, where one or more distributed development teams each host a repository, IBM Rational ClearCase MultiSite provides a robust and scalable solution to the problem of distributed asset management. Alcrohm will utilize Rational ClearCase MultiSite in combination with Rational ClearCase to reliably replicate and synchronize data repositories containing arbitrary binary or text objects, from requirements, to code, to executables, and everything in between. Team members at each site work with their local copy of the repository, so WAN or intranet performance issues are minimized. Branching and merging features simplify the synchronization of changes made to the same files in more than one location, thus effectively supporting a 24x7 development work cycle. The existence of multiple replicas of project assets also helps minimize the downtime, rework, and other impacts of server outages or even disasters. IBM Rational ClearCase MultiSite also provides a browser-based interface that allows administrators to manage all replicas from their local site.
- IBM Rational ClearQuest® -- For change request management and defect tracking. Whether the team is distributed or co-located, development assets are the focal point of activities and an increasingly valuable part of what a business delivers to its customers. The ability to efficiently manage and track ongoing change to development assets in response to defects, enhancement requests, new requirements, and so forth is especially critical on GDD projects. Unanswered questions and confusion about the status of defects are the last thing distributed teams need, because uncertainty invariably leads to costly delays and bugs that slip through the cracks.
To provide optimal support in its GDD environment, Alcrohm will complement IBM Rational ClearQuest with IBM Rational ClearQuest MultiSite, a proven, robust, and flexible tool that synchronizes change request data to local repositories across multiple locations. This not only makes it far easier to keep distributed sites up-to-date, but provides a backup repository in the event a server becomes unavailable.
- IBM Rational RequisitePro® -- To effectively communicate and manage requirements. The problems that stem from poor requirements definition and communication in co-located development projects are magnified when teams are geographically distributed. Indeed, poorly defined or inadequately communicated requirements are among the most common reasons why GDD projects fail. It's no surprise that incorrect assumptions about what is to be built often leads to the wrong solution -- especially when the people involved may not even speak the same language. To mitigate this concern, Alcrohm will use IBM Rational RequisitePro for requirements management. RequisitePro uses a database to organize and track requirements, and to assign attributes like priority, status, and difficulty level to them. Microsoft Word documents are used to record requirements and to provide vital context information. Related requirements can be linked, which makes it easier to analyze the impact of a change on the project's scope and resources.
For access to requirements from Site B or other remote locations, Alcrohm will leverage the Rational RequisiteWeb browser-based interface. This will enable team members at Site B to view, create, and modify requirements stored at Site A, as well as trace the relationships among requirements, without the need to maintain their own repository or install another client on their desktops.
- IBM Rational® TestManager -- For functional and system testing at Site A. The quality assurance team at Site A needs a comprehensive solution that can manage all aspects of testing, from initial test case planning to test development, execution, and analysis of test results. Rational TestManager provides all these capabilities, along with integration to Site A's requirements database that links test cases with requirements to ensure all requirements are tested prior to deployment.
- IBM Rational® Purify Plus -- For unit testing by developers at Site A and Site B. Rational PurifyPlus is a complete runtime analysis solution that enables developers to write more reliable code. Rational PurifyPlus can also help improve performance by providing output that highlights application bottlenecks. Coverage detection flags untested parts of the code.
- IBM Rational® Software Modeler -- For visual modeling and design at Site A. Modeling tools visually communicate all dimensions of the application infrastructure to stakeholders at all sites. Rational Software Modeler supports the Unified Modeling Language (UML), the industry standard modeling language and the most familiar modeling notation worldwide -- a significant advantage when different languages and cultures are involved. As requirements change, the related architecture must be updated. To address this concern, Rational Software Modeler is integrated with Rational RequisitePro to make it easy to associate requirements with corresponding model elements. Updating models to reflect new requirements lets developers at either site see the impact of changes to requirements at a glance. Developers at Site A can also leverage Rational Software Modeler for model-driven development with UML.
- IBM Rational Portfolio Manager -- For portfolio management. Project management requires a way to effectively plan, track, and manage all aspects of GDD project and resource portfolios. Rational Portfolio Manager captures vital project data, such as cost, quality, and completion measurements that help management evaluate, calculate, and communicate all aspects of the project portfolio. These capabilities are essential to assessing and balancing the risks and benefits of GDD efforts while ensuring they are aligned with business priorities and creating business value.
- IBM Rational ProjectConsole -- For automated tracking of project metrics across the development lifecycle, from requirements definition to change requests to defect reporting. Rational ProjectConsole provides an up-to-date view on project status and quality, so you can make qualitative assessments to keep the project on track and manage risk.
Synchronizing repositories
In order for team members to share assets across a distributed environment in a 24x7 development model, the work done at each site must be kept synchronized and replicated with the other site. As mentioned above, Alcrohm will utilize IBM Rational ClearCase MultiSite and IBM Rational ClearQuest MultiSite, respectively, to keep the project's versioned assets and change management assets synchronized. Replication and synchronization of the ClearCase and ClearQuest repositories will automatically take place twice each day, at times corresponding to the end of the work days at the two sites (07:00 and 19:00 Denver time).
The built-in replication capabilities of IBM Rational ClearCase MultiSite and IBM Rational ClearQuest MultiSite keep the synchronization process streamlined and simplified. The ClearCase MultiSite and ClearQuest MultiSite databases are replicated at the same time. This ensures that links among assets remain up-to-date. Figure 1 illustrates how this arrangement works.
Figure 1: IBM Rational tools and asset repositories
Alternatives for anytime / anywhere access
In some GDD environments, it may be feasible to consider providing Web-based access to shared repositories, and / or employ Citrix technology to centralize the execution and administration of development tools. These kinds of "thin client" alternatives can enable distributed team members to access project assets wherever they are located.
In the Alcrohm GDD environment, both Site A and Site B have sufficient server capacity and administrative resources to enable all the IBM Rational tools at both sites to be accessed via their built-in interfaces wherever the highest degree of functional capability is required. Yet the project still makes significant use of Web clients. In particular, team members at Site B rely on the RequisiteWeb client to access requirements.
In addition to RequisitePro, many other IBM Rational tools support Web-based or Citrix-based client options. For example:
- Remote users can access the change management capabilities of IBM Rational ClearCase via a Web-based interface.
- The IBM Rational ClearCase Remote Client feature lets remote users access versioned objects over a WAN.
- Administrators can manage distributed ClearCase repositories from any location via a Web browser, via the IBM Rational ClearCase MultiSite Administrator Web interface.
- IBM Rational ClearQuest provides a Web-based interface that enables remote users to access and update change requests.
- IBM Rational ProjectConsole dynamically creates a project Web site with a graphical dashboard based on metrics you collect from both Rational Suite and third-party products.
The tools in action: A day in the life of the Alcrohm GDD project
Now that we've determined the breakdown of roles and assets, and deployed tools and processes across our hypothetical GDD environment, let's take a look at how the tools work together in an everyday context. The workflow progression and status transitions we'll describe are entirely customizable, by the way. In a different scenario they might work differently depending on the needs of the project.
The work day dawns at Site A in Denver as night falls at Site B in Bangalore. We look in on the Alcrohm GDD project at a point where -- among many other activities -- a planned maintenance release of the current application is well underway. The effort is on track as the scheduled date to bring the new version into full production draws near.
At 07:00 Denver time, the IBM Rational ClearCase and IBM Rational ClearQuest repositories at Sites A and B are automatically synchronized using IBM Rational ClearCase MultiSite and IBM Rational ClearQuest MultiSite, respectively. As he eats breakfast, Site A's SCM administrator uses the Web browser on his home computer to access the replicas remotely via the Rational ClearCase MultiSite Administrator Web interface. He verifies that the scheduled replications completed without errors.
The flow of activity we will track begins as a business analyst, working at Site A, enters a new requirement for the upcoming maintenance release of the application into IBM Rational RequisitePro.
The project manager responsible for the maintenance release, who also works at Site A, gets an e-mail notifying her of the new requirement. To check on the impact of this change, the project manager reviews a "Current Workload" graph she's created in IBM Rational ClearQuest. The graph shows her the existing workloads of all the developers at Site B, from the standpoint of the number of change requests each is currently working on.
Again, using Rational ClearQuest, the project manager enters a change request and assigns it to a developer at Site B. The new request will appear in that person's "to do" list the next time he logs into ClearQuest. And upon assigning the change request, its status automatically changes to "Assigned."
Now that a new requirement has been added, it's important to ensure that it will be tested via a new test case. The project manager utilizes the integration between Rational RequisitePro and IBM Rational TestManager to access the new requirement from within Rational TestManager. When she creates the new test case it is automatically linked to the requirement.
Also notified via e-mail of the new requirement is the system designer on the maintenance project. Using IBM Rational Software Modeler, the designer edits the project model to update the use case diagram to reflect the new requirement. First, he checks out the specific files to be updated. Once he's associated the new requirement with the correct model element, the update is complete and he checks the files back in. Integration between RSM and IBM Rational RequisitePro automatically maintains connections between model elements and requirements. To make the updated model available to interested stakeholders at both sites via a Web browser, whether they have Rational Software Modeler on their desktops or not, the designer uses IBM Rational Software Modeler's Web publishing feature.
Another team member notified via e-mail of the new requirement is the system architect. From her desk in Denver, she checks out the appropriate files using IBM Rational Software Modeler and its integration with IBM Rational ClearCase. After updating the system architecture diagram and the appropriate sequence diagram, she checks the files back in. She, too, uses the Web publishing feature to make the new diagrams equally accessible to team members at both Site B and Site A.
Now we look ahead to the evening in Denver, which of course is morning in Bangalore. At 19:00 Denver time, the IBM Rational ClearCase and IBM Rational ClearQuest repositories at Sites A and B are once again automatically synchronized using IBM Rational ClearCase MultiSite and IBM Rational ClearQuest MultiSite. As his colleague did earlier, Site B's SCM administrator uses the Web browser on his laptop to access the replicas from his home and check on the replications.
As developers arrive at Site B to begin their work day, they log into IBM Rational ClearQuest using its native Windows interface to scan their "to do" lists for new change requests assignments. Developers working remotely from Site B can check for new assignments via IBM Rational ClearQuest's browser-based interface.
The developer to whom the project manager at Site A assigned the new change request sees that he has a new "High Priority" work item. He first accesses the updated use case diagram and sequence diagram to see how the new change will affect the application as a whole, as well as the components he is working on. Like any team member at either site, if the developer needs to verify the correct workflow process or "next step," he can access RUP using his Web browser to check visual diagrams that show the interactions among each project discipline throughout the development lifecycle.
Next, using the Web-based interface to IBM Rational RequisitePro, the developer views the details of the new requirement. He adds a comment to the requirements document, and then creates a discussion entry to pose a question. Rational RequisitePro automatically tracks the discussion thread so any authorized team member can easily see the comment and subsequent replies.
Since the new change request has a high priority and will affect other work he is doing, the developer decides to work on it immediately. To determine what part of the code needs to be modified, and hence what files he'll need to check out, he views the updates made by the system designer and architect at Site A.
From his secure personal IDE workspace, he uses IBM Rational ClearCase to check out the code to be updated and, over the course of the day, makes the necessary modifications. When he's ready, the developer uses IBM Rational PurifyPlus to unit test the updates. Rational PurifyPlus informs him of any memory leaks, and ensures that every line of code is tested. Once testing is complete, he checks the code back into IBM Rational ClearCase and delivers the changes to an integration stream, again without needing to leave his IDE. He also updates the appropriate record in IBM Rational ClearQuest to indicate that the state of his activity is "resolved" and the new code is ready for functional testing. These built-in workflow management features help prevent work transfer problems.
The next time the project's repositories are replicated and synchronized (at 07:00 Denver time), the developer's changes, along with all other modifications made to the code base, are delivered to Site A.
Site A's build team begins the day by creating a new code baseline and promoting it to a build release using Rational ClearCase. The QA team then performs functional, system, and performance tests on the new build using IBM Rational TestManager. Tests that fail result in the creation of a defect record in Rational ClearQuest. Integration between Rational TestManager and Rational ClearQuest allow the QA manager to enter defects directly from Rational TestManager. The project manager can then use Rational ClearQuest to assign defects to developers at Site B. For defects that have passed testing, the statuses of the corresponding change request records are automatically changed to reflect that the defects were fixed. Developers at Site B can also use Rational ClearQuest to check on the status of the change requests assigned to them.
Next, the build team uses Rational ClearCase to deliver changes to the integration stream. The new baseline is merged and compared with the current baseline. When the time comes to deploy a new version of the application, a release engineer can use Rational ClearCase to create a new system "build" and route it to the testing group for final certification before deployment to the production environment.
Meanwhile, to keep the project on track towards the fast-approaching deployment date for the next maintenance release, the project manager uses IBM Rational ProjectConsole to monitor all dimensions of development, such as the number of priority defects, the number of requirements outstanding, and the volume of code changes. These quantitative metrics help ensure that the new release is ready on time and is fully tested. If issues arise that might jeopardize the schedule, project management can proactively take steps to mitigate risk at every level.
Many GDD alternatives
The GDD scenario we've worked through in this article is one of the more common models that organizations are using or contemplating today. However, it is just one of many possible scenarios for leveraging IBM Rational tools in distributed software and systems development environments. Other GDD approaches that our customers frequently employ include componentized team development and tightly coupled co-development. In the former case, distributed teams "own" the development effort for one or more discrete components of an application. The teams then collaborate to bring the final system together. Tightly coupled co-development comprises teams at geographically dispersed sites that all work on the same software components, thus achieving a 24x7 development cycle for reduced time-to-market.
Some GDD models require software development tools that support the entire software or systems development lifecycle from proposal through deployment in a distributed context. Others, such as componentized team development, may require only configuration management and development tools to work across the distributed environment.
In short: there's a whole lot more to the story of how IBM Rational software can save time, cut cost, reduce risk, and improve quality on your next GDD project. We will present more of this story in future articles.
About the author | 
| | As a market manager at IBM Rational, Brenda Cammarano is responsible for the Geographically Distributed Development (GDD) solution within the Rational brand. She is responsible for the complete strategy for bringing this solution to market which reflects a deep understanding of clients' needs and how IBM products can best work together to serve them. In this effort, she draws upon her experience as a former senior technical evangelist for the Rational Enterprise Suite, a programmer/analyst in object-oriented engineering, and a key player in product management and technical marketing organizations for several high-tech companies in the Greater Boston area. |
Rate this page
| |
