Adjusting the Environment Again

The RUP hump chart illustrates an often-overlooked feature: At the beginning of each phase, there is a small spike in effort devoted to the development environment. In other words, don't set up your tools and procedures at the beginning of the project and expect them to remain static throughout the project. Even small projects completed in a short time frame are susceptible to changes in the environment.

Our project was more susceptible to changes because we were working on it part time and it took longer than it would have otherwise . Another factor that caused more changes to our environment was that for some of the time, we were working with early, unreleased versions of Rational tools because that was the environment we needed to work in for our regular work (our day jobs). Because we worked on teams for our regular jobs, we needed to change versions of tools in synchronization with our teams . We did not have the "luxury" of staying with earlier versions until our PSP Tools project was finished.

In Chapter 6, we discussed the changes in our development platform: we switched from Forte to Rational XDE and the Eclipse development environment. In the Construction phase, we made additional adjustments to address the needs and limitations of our team.

We have already discussed some of the characteristics of our team ”the geographical distribution, frequent traveling, and the fact that we did not all work for the same company. These factors affected our version control, defect tracking, and requirements management tools.

Version Control

Many artifacts can be placed under version control ”requirements documents, designs, models, user documentation, and source code. Configuration management and version control are each processes. As systems become more complex and you begin to build multiple versions and derivatives, and you reuse components , your tools must be capable of supporting the development process. We were not at this point with PSP Tools.

ClearCase was initially much more than we needed for our project, but our project grew to need more of its features. The major problem we had to overcome was that not everyone on the team had access to the Rational tool set. Jas was no longer with Rational, and the company he was with did not use Rational tools. Even with access, and even with the ability to set up a multi-site implementation, we were not all sharing the same secure intranet. How could we make sure that everyone had access to the latest version of all of the artifacts they needed?

Our solution was twofold. First, we realized that only Chris and Gary needed to change source code. We set up a ClearCase VOB (versioned object base) on the Rational network to store the latest versions of our source code. This enabled Chris and Gary to work independently of each other and to check source code in when it was ready. ClearCase provides powerful merging features, so we didn't have to worry about whether we had the latest checked-in versions of our code when we did our individual builds and were connected to the network.

The solution didn't address the issue of Gary's frequent traveling. He needed to work when he wasn't connected to the Rational network, and he had to communicate his changes with Chris. Many of his trips were longer than a week and he often worked at home for long stretches, where he does not have high-speed access to the Rational network. ^[1] In order for Chris and Gary to frequently integrate their work and deliver builds to Liz and Jas, they needed access to changed code regularly.

^[1] Despite the fact that Massachusetts is a high-tech hotbed, there are still pockets where high-speed Internet access is not available. Even satellite is not a possibility because he is surrounded by woods. There is a price to be paid for living in the country.

The first part of addressing this issue was for Gary to create a snapshot view ^[2] of the source directory on his computer. ClearCase snapshot views are copies of files that can be used when you are disconnected from the network. Gary would modify files while he traveled. You can change a file in a snapshot view without first checking it out. ClearCase calls a file in this state hijacked . When you reconnect to the network and update your view, ClearCase lists all the hijacked files and allows you to check in or discard your changes. ClearCase even gives you the option to merge your changes with any others that have been made while the file was hijacked.

^[2] ClearCase provides two types of views. With snapshot views, you copy files to your computer disk and you can work connected or disconnected from the network. To look at changes, you need to update your view. To use dynamic views, you need to be connected to the network, but you have instant access to all the changes made by your teammates.

The second part of our version control solution was to use the Groove workspace. When either Chris or Gary made changes, they copied the modified sources to a separate Transfer location on Groove and left a message for the other.

Groove also provided a solution for Jas's inability to access the Rational network. We set up a special area on Groove, labeled Drops for Testing . Whenever we created an integration build for testing, we placed the files in this area and left a message. Jas and Liz could copy the build from this area and begin working with it. This solution worked very well for us. This area also served as a "poor man's" version control system. We kept as many versions of the files as we desired here. The only cost was the space we used on each team member's computer.

We should note that there are other solutions available to a small development team. Online communities such as SourceForge host open source development projects providing version control support as well as defect tracking. Whatever solution you choose, make sure that you select one that works for your needs and does not lock you into an approach that will make future change difficult.

Defect Tracking

With the end of the Elaboration phase and the start of the Construction phase, we needed the ability to report and track defects. There are many possible solutions available to software development teams. The solutions range from free, open source software to commercially available tools. For our team, being on different networks was the driving factor in our solution. As you might expect, we used Groove again.

There was no defect-tracking tool available for Groove when we developed PSP Tools, so we created a simple one. ^[3] The Groove discussion tool is a versatile workspace component. We created a new discussion tool, just as we did to handle our engineering backlog. The Defect tab on our workspace used stylistic conventions to identify the defects, priorities, and status. This was simple enough for all of us to use and it was always accessible. Figure 8.1 shows a snapshot of our defect-tracking tool.

^[3] Like any product, Groove is continually evolving. Several new tools and product integrations have become available since we started. There may now be a defect-tracking solution.

Figure 8.1. Our Groove Defects tab

Additional Requirements Management

In Chapter 6, we discussed how we used Rational RequisitePro to store the PSP Tools feature requirements. When you begin to implement the use cases corresponding to the features, you can add the use case requirements to the RequisitePro project.

On each project, you may be tempted to delay using RequisitePro. For example:

• You may be concerned that you won't receive enough benefit from the tool to outweigh the extra time you will spend managing the tool.

• You may feel that your project is small enough that you can keep requirements in your head.

Fortunately, RequisitePro adds very little overhead to capturing requirements, so it's easy to start using it early on your project.

Whether you adopt use cases or use some other format, such as user stories, ^[4] to capture requirements, you can use RequisitePro to collect valuable information about your requirements. For example, RequisitePro maintains information about the relationship between different requirements. (RequisitePro calls this traceability .) You can use this information to determine whether all the features you planned for the release are represented by at least one use case. If a feature has no associated use case, then there is a danger that the feature will not be implemented. If you do not keep track of this information, it is easy to miss a commitment and end up with an unwelcome surprise toward the end of the project.

^[4] See Appendix C for a description of user stories.

Figure 8.2 shows a traceability matrix from RequisitePro. The columns are the features from the Vision that we designated for implementation in the first PSP Tools release. The rows are the use-case requirements from our use-case requirements document.

Figure 8.2. Traceability matrix from RequisitePro

The matrix shows that feature requirement FEA2.3 doesn't have a use case traced to it. This indicates an omission. The user is expecting to be able to record size information but there is no functional requirement in the use cases that describes this feature. We need to add to the set of use cases, either a new use case, or a flow of events in an existing use case, to satisfy the feature requirement. In our case, we implemented the code and then later modified the use-case document. The important point, though, is to make sure that you implement all the required features in the code.

One other feature of a traceability matrix appears in Figure 8.2. Notice the line through some of the arrows; for example, the arrow tracing UC2.3 to FEA2.1. This indicates that one of the requirements was modified. It means that we need to determine if the change has an impact on a part of the development effort. For example, we might have added additional data to the database identification information. This would require changes in both code and testing. Using a traceability matrix makes it easy to assess the impact of change.

We wrote and maintained a use case document starting early in the project. But because of the small size of the PSP Tools project, we didn't put the use-case requirements into RequisitePro until the later stages of the Construction phase. We weren't all connected to the same network and we didn't set up a Web interface for RequisitePro, so we felt that it was easier to maintain the use-case requirements document outside of RequisitePro for the majority of the project. We felt that it was important to put requirements into RequisitePro for Version 2, so that the people who worked on the next release would have a good starting place (even if we were those people).