The Changing Landscape

If we had the luxury of working on PSP Tools full time, the project would have lasted just a couple of months. Many of the issues we faced might not have arisen or they would have been much less important. But the fact is that it took us a while to complete the project. It took us over a year of starts and stops, stalls and accelerations. During that time, the technology and practices for developing software with the Java platform changed, as did the tools for many other parts of the software development process.

This part of the chapter discusses the main changes, as we see them, and how we might do things differently if we were starting over.

Team Communication and Collaboration

There are several tools to host projects for distributed teams . Today, we would select one of them at the beginning of the project. These were available when we began PSP Tools. We didn't make good use of them, in part because we didn't realize at the beginning of the project that we would need them.

Teams tend to overuse tools. Our team used Groove heavily. Groove is a great tool, but we used it in place of other, more appropriate, tools. In the next release, we will look for an open source community for hosting the code and artifacts, one that provides the capability for version control. A community such as SourceForge (http:// sourceforge .net) would be our choice today.

One general guideline we can provide in the area of group tools is: Make sure that all your team members who need to use tools for a specific purpose have access to the tools and to the artifacts the tools operate on. For example, because Jas didn't have access to some of the testing tools the rest of the team used, it was impossible for us to have a consistent way to automate tests. When everyone works for the same company and uses the same network, this problem goes away. For us, not being on the same network was often a roadblock that we spent a disproportionate amount of time working around. If you are faced with this situation, consider adopting a tool that everyone can use, even if it has fewer features than another tool that isn't available to everyone.

Changes in RUP

RUP 2003 was released just before we finished the project. This version of RUP has more new features and improvements than any earlier version. In a future project, we look forward to using at least these features: more flexible plug-ins, Process Views and MyRUP.

Earlier versions of RUP allowed you to use RUP plug-ins to enhance the guidance in the knowledge base for specific domains, technologies, and tools. Until version 2003, you had to adopt all of a plug-in or none of it. This release lets you select specific core components of RUP and components of the different plug-ins when you publish a RUP configuration.

When you publish a configuration, you can also publish a Process View . A Process View filters the content of the RUP configuration to produce a view of the knowledge base appropriate to just one role or for one purpose (for example, you can create a getting started view). The Process Views let your team tailor views of the process to your needs, hiding those parts of RUP that you don't normally use (you still have access to the hidden parts). Figure 11.5 shows the standard Process Views delivered with standard RUP.

Figure 11.5. RUP Process Views ^[*]

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

Gary says that he would create two Process Views for our team if we were starting with RUP 2003. He would create a roadmap to the parts of RUP that were appropriate for our team. Such a view would be analogous to our Development Case, presented as a set of specific pointers to the appropriate places in RUP.

He would also create a general practitioner view containing the minimal RUP content that everyone on the team would share. There would be a few links to specialized areas like modeling, design, and so on. Team members would start with that view and use the MyRUP feature to add useful links.

MyRUP is a personalization feature for RUP users. It lets you create a copy of a Process View and then modify it by adding or removing links. In addition to links to RUP, you can add links to anything on the Internet or on a file system.Figure 11.6 shows such a view.

Figure 11.6. A personal view created with MyRUP ^[*]

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

With RUP 2003, we would also:

• Create a thin plug-in that integrates some of our material directly into RUP. ^[2]

  ^[2] Thin plug-ins are produced with a small amount of effort using a tool called RUP Organizer. This tool lets you add or replace information in RUP as long as you don't change the underlining structure of the RUP model. To change the underlining structure, you need to use the RUP Modeler tool. RUP Organizer has more than enough capability for projects such as PSP Tools.

• Create a team Process View pointing to our artifacts, such as the RequisitePro database and XDE models. This would allow us to access artifacts immediately while using RUP to get process guidance.

IDE

There are many good IDEs available for developing software today. Eclipse, IBM WebSphere, Borland JBuilder, and Sun ONE studio are examples of ones we recommend for Java development. In many ways, selecting a development environment is like selecting a personal computer. Be happy with what you choose and realize that tomorrow, it will be superceded by a new model that costs less and has more features.

If your team is new to Java, or even to object-oriented programming, we recommend that you try the BlueJ IDE, available from www.bluej.org. BlueJ was developed at Monash University in Australia, with support from Sun Microsystems. While it doesn't have all of the special features for working with J2EE applications, Web services, and so on, it does present a simple, easy-to-use way of developing Java programs. Once you master the object-oriented concepts and Java, you can switch to a more full-featured environment.

Our advice is to choose an enironment that you adopt one that gives you full access to the underlying Java platform and one that doesn't lock you into using it forever. Remember our experiences with the GUI Builder in Forte. It was nice until we switched to Eclipse. We had to live with the Forte code, even though it wasn't implemented in the way we would have liked to write it.

If we were beginning PSP Tools today, we might spend more time testing the different IDEs than we did for this project. We are fairly certain that we wouldn't change IDEs in mid-project again.