Creating the PSP Tools Architecture


There was little architectural risk for our project. That didn't mean that we just started coding. Indeed, we designed an architecture, albeit an informal one. Chris and Gary met for a couple of hours in a room with a whiteboard and sketched out the user -visible parts of the application. This exercise helped them develop a shared understanding of what the user interface would look like. During this exercise, they also brainstormed about how to lay out the Java code.

They decided on a main PSP window, divided into two panes. The left pane would contain a tree view of all the tasks in the database for the current user . [7] We weren't sure exactly how to present the tree view, but we decided it would contain information for the current user only. We weren't sure whether we would change the display for an administrator; the requirements at that point called for a user with special privileges who could, for example, produce combined reports . Rather than trying to nail down the details, we came to a general understanding of the view and decided to defer a more specific design of the user interface.

[7] The current user is the term we used to identify the person who had logged into the PSP database.

The right pane was to contain the details of the item selected in the tree view. The major items in the database were tasks (which were really projects), times, and defects. But the times and defects were both associated with specific tasks, so it seemed natural for the right pane to contain task details.

During the design session, Chris and Gary drew a few diagrams on the whiteboard. Figures 6.6 and 6.8 show what they drew. [8] They describe some of the more important parts of the application. They also represent the thinking at the beginning of the Elaboration phase. In subsequent chapters we see how the thinking changed, and discuss the reasons for the changes.

[8] The diagrams have been copied from the notes Gary took at the session.

Figure 6.6. Initial sketch of the user interface

graphics/06fig06.gif

Figure 6.8. Initial package distribution layout

graphics/06fig08.gif

One could hardly call the sketch of the user interface in Figure 6.6 detailed, but it was a good starting point. When we compare it to the final main window from PSP Tools shown in Figure 6.7, it is surprisingly accurate. We weren't sure what the tabs would contain, how many tabs there would be, or exactly what would be in the tree for each task. At this point, we also weren't sure about how the different actions, like creating a new task, would be invoked. We were confident, however, that we would be able to get the right level of presentation ”perhaps not at first, but incrementally and iteratively ”as we proceeded through the Elaboration and Construction phases. You can see in Figure 6.7 that we included buttons for many of the actions rather than forcing the user to work with menu selections exclusively.

Figure 6.7. The actual PSP Tools user interface

graphics/06fig07.jpg

At our design meeting we also took time to lay out the major packages for our code. The sketch in Figure 6.8 can be used as part of the design model and part of the implementation model described in RUP. Our plan at the outset was to not worry about making the models look good. That is post-production work to us. While the customer worked with the product during and just after the Transition phase, we would schedule time to decide what we needed to turn into a persistent form for the next release.

We have mentioned this attitude of deferring things before. Liz calls this "programming by procrastination." It may sound like a bad idea, but it is another way of stating what some members of the agile community mean by "You aren't gonna need it" (YAGNI) and "Do the simplest thing that could possibly work." We think the real benefit of taking this approach is that it starts you moving and keeps you moving, especially during those times when you are tempted to spend too much time trying to get everything just right before continuing. The more experienced you are, the more you know how to achieve the right balance of appropriate caution and moving ahead. The best way to learn is by making mistakes yourself, or by working on a project with more experienced people to learn how they balance the risks to make decisions.

Login: Not as Simple as We Thought

We spent a lot of time during the Elaboration phase trying to decide how users would identify themselves to the system. This common problem is faced by both large and small software product teams . It isn't clear if there is an ideal solution that fits every case. Our preference was for a PSP Tools user to open a database and have the software automatically recognize the user. We thought we could use the user's login name , which we could obtain from the system software.

This wasn't a perfect solution. We imagined scenarios when the user would want to be logged in under a different name. For example, if you work on different projects in your organization, you might want different login names for each project, but you would not log in to the operating system using different names. So you would want distinct user names when using PSP Tools only.

We struggled with another question. Do you log in to PSP Tools or do you log in to a specific PSP Tools database? We considered scenarios that involved a single user who wanted to use different databases and different login names, for example:

  • If you log in to PSP Tools, when you open a database, what happens if you are not a member [9] of the database? Do you need someone who is a member of the database to add you?

    [9] We used the term member of a database or project to indicate someone who was able to modify the contents of a project database.

  • If you close one database and open another one, what happens if you aren't a member of the second one? Will it ask you to log in again or does it retain your original login ID?

  • What happens when you use different system login names, for example, if you use different computers on a regular basis?

  • Different privileges might be associated with your user name. Do you retain those privileges when you switch from one database to another?

These are difficult questions to answer, and it is even more difficult to arrive at a solution that satisfies all of the issues. We eventually decided that you log in to a specific database. When you open a database you will be asked to log in, even if you use the identical user ID and privileges for the database you are closing. This was a sufficient solution, relatively easy to implement, and we decided that in the normal use of the product, changing databases would be an infrequent occurrence.

When you open or create a new database in PSP Tools, you log in. For the first database opened or created in a PSP Tools session, the login name defaults to the user name obtained from the system. You can override this setting when you log in to PSP Tools. From that point on, as long as you don't quit PSP Tools, every time you open or create a new database, the default user ID becomes the last user (login) name used.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net