Setting Up a Development Environment

During the Inception phase we decided which development tools we wanted to use. The following sections describe what we selected.

Language Tools

We decided to implement code in Java. Chris and Gary were going to write the code, and they were comfortable with Java. Java also provided the multi-platform capabilities that we wanted. Russell's programmers worked on several development platforms.

Choosing a Java development platform was not as easy as we thought it might be originally. We knew that it was possible to just use an editor and command lines to compile and run a program. This is much easier to do on a Unix system than on a Windows system but Chris and Gary used Windows as their main operating system.

We wanted to use an IDE for several reasons. Most IDEs have tools for constructing user interfaces easily. Java UI development can be tricky, especially when handling the different layouts and graphical objects such as trees and tables. So we especially wanted to use a GUI builder.

Most IDEs also provide integrated debugging, execution, and build capabilities. Deciding to use a Java IDE was an easy decision. But it was harder to decide which IDE to use.

There are several Java IDEs available ”many good ones are available for free. Our first choice was Forte for Java, now called Sun ONE Studio. We chose the Community Edition. It contained everything we wanted, and it was free. We all downloaded the Java development kit and the Forte software from the Sun Java Web site and began to use it. Our experiences with Forte were mixed. We liked the GUI builder, but the environment seemed sluggish and we had problems with intermittent crashes. We used it throughout the Inception phase and into the Elaboration phase, and then we switched. We discuss our experiences with switching IDEs in Chapter 6.

Requirements Management Tools

The product depends upon good requirements ”and requirements continually change. If we have learned nothing else in the last two decades, we have learned that we are fooling ourselves when we think we can capture all of the requirements at the beginning of a project and that they will remain stable throughout the project. Any project, regardless of size, needs a way to manage requirements. When we talk about managing requirements we mean:

• Capturing requirements so they can be transmitted to team members in a consistent manner

• Retrieving and modifying requirements so that changes are easily identified

• Prioritizing requirements to aid the planning process

• Tracing requirements to tests, code, and other relevant artifacts in our development process

We had only a few requirements for the PSP Tools project. We managed them using Microsoft Word documents and a Microsoft Excel spreadsheet. While this worked for us, we recommend a more formal system for any commercial undertaking, such as Rational RequisitePro.

Configuration Management and Version Control Tools

Configuration management and version control is fundamental to developing software for every project, yet many development teams try to work without any configuration management strategy or tools. If we had to choose just one tool for our project, it would be a configuration management tool.

Luckily, we had Rational ClearCase installed on our systems, so the choice was easy. ClearCase is perhaps the most advanced configuration management system available today, and it is useful on both small and large projects. We wanted to do a few basic operations: add files to version control, check files in, check files out, and merge files. Other configuration management tools probably would have worked for us if we had been working on just one project. But you seldom work on just one project.

Testing Tools

With a small team, it is especially critical that all team members become involved with quality and testing. A small team often does not have a dedicated quality staff, so everyone needs to pitch in and help test the software continuously. Even on a larger team, engineers have a responsibility to at least unit-test software before passing it on to the quality assurance department. We decided that different team members would test at different levels.

Chris and Gary were the developers, so they did the unit testing. Liz and Jas did usability and functional testing on the builds. Russell performed the acceptance testing. It is important to involve your user in testing your project from the beginning to ensure that you deliver the right product. ^[8]

^[8] See "Involving Your Customers in Your RUP Project" by Gary Pollice in The Rational Edge , April 2002.

We planned on using tools for all levels of testing. We had to balance the need for tools with the overhead of learning to use the tools. We had to ask what risks we were trying to mitigate by automating the tests and then decide whether it was worth the cost. There were few use cases in the application. Manual testing of the major scenarios would not require a lot of time. In fact, in our case, we thought that manual testing would require less time than creating and maintaining automated tests. We opted not to automate the use-case testing.

Gary and Chris wanted to produce clean, error-free code. They decided to create an automated test harness for unit testing. JUnit was their tool of choice. There were many testimonials to JUnit in the literature and in news groups. Gary had some experience with it, and it seemed straightforward to learn. Another point in favor of JUnit was that it was integrated into the Forte IDE. We'll have more to say about using JUnit and our testing in general in subsequent chapters.

Gary also had some experience with Rational PureCoverage, and planned to use it to produce basic code coverage metrics. He was interested in looking at the coverage statistics to determine if there were large pockets of unused, and possibly unneeded, code. If code does not get coverage during tests, it does not necessarily mean that the code is unused. It only means that it is not executed during the tests. However, as you attain a higher percentage of coverage during your tests, you can use the numbers to identify code that either needs testing, or is, in fact, not used at all.

Collaboration Tools

At about this time in the project, we discovered that Jas was leaving Rational. We soon realized that we needed a tool to help us manage communications. Even with just four or five people on the team, we couldn't keep track of which document was the latest, where the documents were, and who had worked on what most recently. We were lucky to have discovered the collaboration tool Groove, which we introduced in Chapter 4. We used Groove throughout the project to track enhancement requests and defects, to place software drops for testing, to make other files (requirements, test plans, instructions, and so on) available to all team members, and to manage our meetings.

Tools in Other Environments

We clearly spent a lot of time setting up our tool environment for PSP Tools. On most projects where you have an established team or environment you spend much less time on tool setup. Small projects that are part of a larger organization will already have an established common set of development tools that are used throughout the organization. You should always look for new tools that will help you do your job better, but you will not have to do much to prepare your basic tool set for your project.