![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
We were recently working on a high-risk application development project with many challenges, including:
- A strong date constraint (launch a prototype of the application in two months)
- A very tight deadline (a fully functional, interactive, integrated version of application to be available in four months)
- Incomplete requirements
- An inexperienced client team when it came to application development
- A geographically dispersed application development team
- An application development team with varying skills.
Despite these challenges, we aimed to be responsive to the client, to minimize the risks to the project, and ultimately be successful. To achieve our aim, we were looking to maximize any advantages we had. Our team had experience with many different tools and methodologies that we had used in the past, including the IBM Rational method and toolset. We could have chosen any of these tools; however, given the nature of the project, we felt that the Rational method and tools would provide us with the best advantages.
With the Rational toolset, we knew that we would not only benefit from each tool's individual capability, but we could also capitalize on how well the tools integrated with each other to achieve additional benefits. Based on the project's needs, we selected the IBM Rational Unified Process (RUP), IBM Rational Application Developer (RAD), and IBM Rational ClearCase and ClearQuest. This article describes how we used these tools to be more effective, and just as important, it describes how the team suffered setbacks in cases where we could not use the tools.
Our client wanted to see results very quickly. While they didn't have a clear vision of what this application would look like in total, or all of what it would do, they had some hard dates that they needed to meet, and they had gathered some essential use cases. They asked us, "How quickly can you begin development?"
Besides the challenges of the client demands, we also had to account for the flexible nature of our work environment. We were a geographically dispersed team. Because there was limited space at the client location for all our team members, some workers were located at the client site, the development team was located at our IBM facility, and other worked remotely, often from home offices. Locating the developer staff at IBM meant that we could quickly ramp up the development environment (since there was no development environment already set up at the client location that we could take advantage of).
We started the project with the Rational Unified Process (RUP), because RUP was a strong fit with this client, who wanted to attack the highest risks and wanted us to deliver the highest value as early as possible. We timeboxed each phase of our RUP project, which meant we were able to accurately state the project schedule, the resources required for each phase, and thus what the project cost would be at the end of each phase. Our client also found this approach very valuable.
We started development soon in the project. Our client didn't want to wait until our extensive design work was complete before we started developing. They had some requirements and wanted to see working application code that they could show to their stakeholders as soon as possible. RUP aided us here: We developed the application in multiple, timeboxed iterations, which meant that we planned fixed start and end dates -- along with a well-defined plan with goals -- for each iteration. We delivered something new with each timebox, and what we were not able to complete within a timebox, we would move into another iteration. This kept the project moving forward.
We didn't require every tool offered by IBM under the Rational brand, but our needs led us to select a range of capabilities.
First, we wanted a tool to help us with the Rational Unified Process. Some team members were new to RUP. Theoretically, RUP can be used as a concept without installing the tool itself. But the RUP tool is extremely useful in helping us manage the process and identifying key roles, artifacts, and relationships we needed. The RUP tool helped us understand and communicate the roles, tasks, and responsibilities of the team.
We wanted a strong integrated development environment (IDE) to develop and unit test our code. We selected Rational Application Developer (RAD) for application development and unit testing, not just for the rich functionality it provides, but because it supported our other tool choices.
We needed an effective way to manage the code. It was essential to have an effective tool to manage our software development artifacts, given our geographically dispersed team and our need to support parallel development streams. Due to compressed timelines, we wanted a tool that could support the developers working on the next release while other developers were delivering fixes for the current release. As well, we wanted a centralized repository to manage the code for the team. ClearCase provided us with all this.
We needed a better way to test and fix our code. The customer assumed much of the responsibility for testing. However, we performed quality assurance tests throughout the project. Early on, our developers used RAD for the initial unit testing before we turned the application over to the customer. Later, we used Rational Robot and Rational Test Manager to ensure the application was performing well.
We needed an efficient way to track defects and manage change. For this, we selected ClearQuest. We were able to take advantage of the ClearQuest Web tool to provide access to our distributed team.1 This tool allowed our team members at the distributed locations to access the full ClearQuest simply via their Web browser. After we delivered builds to the customer and they completed their testing, we captured reported defects in ClearQuest, assessed and assigned them to the developers, then packaged and delivered the fixes in subsequent releases, all of which were tracked in ClearQuest.
With ClearQuest, we could provide up-to-the minute project metrics to our client, an ability that became very critical towards the end of the project when we were under pressure to deliver the final builds. Because the customer had access to our ClearQuest Web tool and defect repository, the customer did not have to acquire and configure their own ClearQuest infrastructure.
Why not use the entire Rational toolset?
As consultants for the Rational brand in Canada, we could certainly describe how you can use all Rational tools in a given environment. However, this is a case study, and for a number of reasons, we did not require all of the tools. Here are a few reasons:
For requirements: We gathered requirements manually. We didn't use RequisitePro because our client strongly felt that the requirements as they defined them were sufficient for us to begin development. In addition, our business analyst at the time was not familiar with RequisitePro and was proficient with documenting the requirements manually. Given our time constraints, we weighed the pros and cons and decided to not use this tool.
For architecture: Much of the architecture of the system was done using standard word processing and drawing tools. This was due mainly to our wanting to use tools that the client's architect was familiar with. Also, at the time, our architect was not familiar with Rational tools for modeling parts of the IT system.
For function testing: We did functional testing manually. The client was responsible for function testing, and they already had an approach they were happy with.
We needed to ramp up our team with the appropriate application development tools quickly. While the Rational toolset is rich in capability, it is not trivial to set up and integrate. But we had two strong advantages. The first was acquiring an existing centralized Rational infrastructure that helped us quickly ramp up the development environment. The infrastructure had been set up and tested for another project, so it was there for us to use. The second advantage came when we were able to add a Rational toolset Subject Matter Expert (SME) to our team. Because the tools are rich in functions, some of the newer people on our team would have needed a great deal of time to understand how to best use the tools. But our SME was able to develop their skills quickly and focus their education in specific areas they needed in order to be productive.
We faced a number of challenges, both technical and business-related.
Because our development environment was spread over multiple locations, network bandwidth and connectivity to the customer site and to the remote development sites provided us with difficulties we would likely not have experienced if everything was situated on a local area network (LAN). Virtual private network (VPN) technology also constrained our ability to use the tools easily and effectively.
On top of that, some of our test servers were constrained in terms of capacity, thus limiting our team's effectiveness. Ideally, we would have liked to increase the capacity of these servers, but this was not an option during the project. So we had to manage this situation as best we could.
Client test processes and tools
Our client wanted to be responsible for testing the application. But some of the client's choices regarding their test process presented us with challenges. For instance, regarding defect tracking, the client wanted to use their own custom tool. While the client was comfortable with this tool, this decision slowed down our overall ability to track, report on, and close defects, because there was no automated integration between their testing tool and ClearQuest. So we had to manually extract the defects from the client's tool and then enter them into ClearQuest ourselves.
Also, the customer's perception of testing progress was marred by the limitation of their home-grown reporting tool. The tool couldn't provide them a clear picture of their testing progress. This led to other problems, such as when they would occasionally test functions that had been fixed or when they tested functions with known issues.
With regards to actual testing procedure, the client had an informal testing process and did not use automated testing tools. The client had no test scripts and no way of tracing back what they were testing to what was an initial requirement. They would sometimes add new requirements instead of proper defects to the defect log. To compound matters, new testers were introduced to the testing of the application partway through the project, and the lack of a formal process or effective tools to test with made their work difficult.
Our project realized productivity benefits because of the linkages among the various Rational tools that we adopted for our project. These integrations allowed our dispersed team to work together effectively despite being physically apart.
For example, during the Construction phase iterations, our test manager was located at the client site, where clients submitted defects via ClearQuest. Our lead developer would review these defects and, for those related to the release being tested, assign them via ClearQuest to the appropriate developer for repair. Our developers, who were located at the IBM facility, would see these assigned defects in their ClearQuest view and would use ClearCase and RAD to check out and repair the code. Once the defect was repaired and unit-tested in RAD, they would check the code back in with ClearCase and update the ClearQuest record to indicate that the defect was ready to be re-tested. After the infrastructure specialist completed the daily build, the test manager would then validate the repaired defect and update the ClearQuest record accordingly.
The end result was a fast development process with high-quality software releases.
What to consider when using Rational tools on your project
Infrastructure: there are a number of things to consider in terms of infrastructure. Infrastructure constraints are a key one. As best as you can, try to determine early in your project if the infrastructure you will be using poses any constraints on you that prevent you from being effective. Determine if there are any network or firewall constraints that may prevent the tools from being used properly. Are there any capacity issues that need to be addressed (e.g., lack of disk space to install the tools)? Do you have someone who can properly handle the administrator role?
Another consideration is infrastructure cost. Have you accounted for the additional costs for software licenses, infrastructure, and support you may need for your project? For example, if you need another server for ClearCase, or you need more memory for the machine that will run one of the Rational test tools, have you factored those costs into your plan?
Training: Training also needs to be considered. Lack of training or training at the wrong time will impact your team's productivity and may limit the effective use of the tools. If time is a constraint, and it usually is, you may want to consider self-study courses or find an experienced mentor. Additionally, RUP comes with built-in tool mentors that can provide guidance. It is important to note, however, that nothing beats classroom education.
Usage model: What is your usage model? By this, we mean how is your team going to use the tools in a way that can best make you productive? Do your processes support your usage model? If you don't consider this and you don't have a good approach, then you can potentially lose out on some of the benefits the Rational tools can provide.
Integration with other tools. Once you start introducing non-Rational products, there may be additional time and effort needed to integrate all the various tools together. For example, in our case, we would have benefited from having some additional effort spent on integrating the client's custom tools with ours.
New tool adoption rate. Just as servers have only so much capacity to run software, your team members only have so much capacity to learn about new software! You don't want to introduce too many new tools to your team, especially if time is constrained. Consider the time available for team education and the time pressures already on your team, and use this to guide you in determining how many of the Rational tools you want to adopt.
Size and complexity of your project. Longer projects and projects with complex requirements will benefit more from Rational tools than small, simple projects. For example, as the amount of reporting you have to do increases (either the frequency or the complexity of your reporting), you will see more advantages in having integrated Rational tools than if you had to do things manually. With regards to return on investment (ROI), you may find that as the size of your software development projects increases, the resources spent acquiring and learning to use the tool are recovered by the productivity gains you can achieve.
Business constraints. You may not suffer from any technical constraints when it comes to using Rational tools. In our case, we had a client who didn't want to be buying new software. On your projects, you may find team members who are comfortable with using non-Rational tools to do their work and who may not want to switch from using these tools.
On the whole, we were able to achieve greater productivity and greater efficiency with the Rational tools we used. The integration of the tools, the productivity features of each of the tools, the ability to do parallel development, the ability to assign and track defects effectively, even the Web features: all of these capabilities allowed us to achieve more. That said, there are a number of things to consider before you jump on a bandwagon. But if you take all of this into account, your team will achieve the benefits that these tools promise
1 As described at http://www-1.ibm.com/support/docview.wss?uid=swg21175862, the ClearQuest Web features help teams "reduce their administration and support costs by leveraging common Web components for all their Rational® Team products. Another benefit is that customers can install the New ClearQuest Web feature on more than one operating system platform."
Iterative development: http://www-128.ibm.com/developerworks/rational/library/may06/ritchie/index.html
IBM Rational ClearCase: http://www-306.ibm.com/software/awdtools/clearcase/
IBM Rational ClearQuest: http://www-306.ibm.com/software/awdtools/clearquest/
Change and Configuration Management: http://www-306.ibm.com/software/rational/offerings/scm.html
Introduction to software quality: http://www-306.ibm.com/software/rational/offerings/testing.html
A Certified Project Management Professional (PMP) and an IBM Certified Specialist for the Rational Unified Process, Rose Ritchie has more than fifteen years of IT experience, much of that as a project or program manager for complex application development and system integration projects, primarily in the financial services industry.
With twenty-two years' experience in designing, creating, and implementing complex IT solutions, Bernie Michalik has performed in a wide variety of roles, from leading large teams in the creation of large-scale infrastructures to individually developing custom software for global clients. His experience covers a wide variety of methodologies.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
