< Zurück | Inhalt | Weiter >

Part II

Developing Business Logic

Chapter 11

Balancing Acts:

An Imaginary Scenario


In this chapter, the authors wax poetic on practical software development methodologies, and attempt to introduce a simple, or maybe simplistic, example application for use in future chapters.



We want to share with you some thoughts on practical software development. We are not covering anything specific to Linux or Java in this chapter; there will be no commands to type or syntax to learn here. You may skip ahead to the next chapter—but at your own peril. Those who know and use good soft- ware process won’t need this chapter, but many programmers don’t fall in to that category. In fact, some who think they are using good process may be using too much or too little for their actual situation.

If you are relatively new to the corporate world, or have only worked for one or two companies in your career to date, you may get a taste of how soft- ware is done in other corporate cultures. If you are a seasoned programmer with many such experiences, see if this doesn’t sound all too familiar.


You will also see the requirements for a simple budget application that will be used in succeeding chapters. It has little to do with real budgets, but lots to do with a simple application that we can use to demonstrate various Java technologies.


Financial planning is something that everyone does. The basic tool of financial planning is the budget. But unlike the home budget, the budget of a large cor- poration is managed at multiple levels within the organization. Sure, at some level, the board, the CEO, and the CFO decide that “we will spend X million dollars for operations for this quarter,” but that is the start of the process, not the end.

From there, the feeding frenzy of middle management begins. And keeping track of things becomes an important aspect of financial control and corporate governance.

Realistically, any large business will already have processes and tools in place that meet this need. We are not expecting that what we develop here will be anything that a business will actually adopt to manage this process. Rather, our goal is to illustrate some methods of software development that actually work to build real Java application. The outline of methods and code could be used to address many classes of enterprise software.


There is a science of Software Engineering. The development of software can be made an engineering discipline, with mathematical rules and metrics of success. Every aspect of a complete system can be worked out in detail before- hand so that you know, well before a line of code is written, what the outcome will be.

That’s not what we’re talking about here.

We are talking about software development not as it happens at NASA, medical device companies, and in factories where nuclear missiles are made. In those contexts, the potential costs of error are extremely high, ranging from the multibillion dollar loss (and public embarrassment) of crashing a spacecraft into Mars, on through having heart pacemakers fire off incorrectly, right to ending life as we know it on this planet. In such cases, no matter how much the correct

11.3 How to Develop Software 265


software costs, you pay it because the consequences of not doing it perfectly are far too high.


Our discussion is not meant to be scholarship on the topic of software develop- ment methodology; instead, it is meant to show simple, basic processes that can bring a reasonable amount of control to a software development project. These steps are, to name a few, requirements gathering, specification, object analysis, database design, development iteration (code, unit test, repeat), and so on.


But most of us who write software do not deal with such consequences. Most of us are keeping track of purchases and payments. We’re recording pro- duction data. We’re tracking manifests and updating inventories. We are the great unwashed mass of MIS software developers. Here we, too, want to do it perfectly right. But every time we go to management and tell them how much it will cost and how long it will take, the little “mass layoff” vein throbs in their foreheads. We are always being told to do it faster and cheaper. And so we find ourselves, again and again, tilting at the windmill of quality.

So where does that leave us? When we go to management with the text- books of software engineering, they either laugh or scowl. Clearly, the money people are not prepared to support the cost of doing it right. So what do you do? The best that you can. The one thing we can tell you for certain is that the formula for success is not “start writing code and trust to luck.”

It is fair to say that even the minimal software development method should include the following steps:

• Requirements gathering

• Use case specification

• Class discovery and problem domain decomposition

• Technical requirements specification (architecturing)

• Testing

• Code and release management

• Production and operations support

• Bug and enhancement tracking

This list, when done in that order, has been referred to as the classic “waterfall” model—each step is done in its entirety (or largely so) before proceeding on to the next step.

Or at least that’s the ideal which programmers have often pursued.

The problem is that the process involves people, and people, especially those responsible for the requirements, a) are sometimes unimaginative and 2) keep changing their minds. They start out with some requirements, based on what they think they’re going to need. But they just aren’t imaginative enough to think of how terrible their system will be for the average user. They also keep changing their minds as to what they want.1

The “iterative” approach has been tried as a way to address this problem. Rather than wait for all requirements to be spelled out perfectly, with the itera- tive approach you jump right in with what you do know, build that, but expect changes to come. The sooner you get a working product or prototype into the hands of the users, the sooner you’ll get feedback on what works, what doesn’t, and what is really wanted (“what works” is used here not in the testing sense, but in the usability sense).

Note, however, that in the iterative approach, one still gathers require- ments, develops designs for the code and the tests, develops them, tests (and fixes) the code, and releases it. It’s just that one does that on a much smaller and more rapid basis. You get something runnable sooner, and continue to modify it.

Some people will complain that this makes for more expensive rework, but we (and others) would disagree. You are refining the process. Your reworks are less expensive than if you went to the work of building the entire system only to have some key requirement(s) change—there can be a lot more “wasteage” there.

Be aware, however, that the iterative approach is not just “whipping the

horses to run faster.” It is not just the waterfall model run at high speed. Rather, it is using the early iterations of the product as a sort of a “living” requirements specification, one that you can show to people and that they can try out, in real- world scenarios, and on which they can give feedback. Don’t expect to be able to compile complete requirements, but don’t give up on talking to your end


1. Did you notice that we tried to hint at that ever-enjoyable mid-project shifting of require- ments as we went from a) to 2), changing our numbering scheme midway? Minimal humor, admittedly, but if you’ve lived it, you understand.


11.4 What Makes a Good Requirement 267

users and other stakeholders either. Requirements are still key to delivering a solution.

So with either approach, you’ll start with requirements. Let’s look at the art of requirements.


A good requirement is one that states a need but not a solution. Sounds simple, but it’s easier said than done—especially with solution-oriented technical types. A typical first cut at a requirement might be something like “Our budget application should store its data in the database.” While it sounds reasonable,

it is really a solution posing as a requirement.

The first step in refining such a requirement is to ask the simple question: “Why?” The answer we’re looking for is not “Because we’ve paid so much for our database software,” nor is it “Because we all know SQL.” Rather, it should be something dealing with reliability, fault tolerance, the need for transactional integrity, and so on.

Sometimes you may have to ask the “why” question more than once, to refine the requirement(s). “Transactional integrity” is, in a way, a solution. You could ask, “Why do we need that?” For some projects it may be appropriate to ask this, because there may not be a real need for it after all.

But don’t overdo it. Push any requirement in a business setting far enough, and you could get something like “To make money.” That’s not a helpful re- quirement. You’ve gone too far. Part of the art of requirements is recognizing when to stop asking why.

A more detailed description of a requirement is that it should be SMART—Specific, Measurable, Attainable,Repeatable, and Testable. Consider the following.

A common concern among users of almost any application is that it be “fast” or “responsive.” While we can sympathize with the concern, it will need some refinement before it can be considered a (good) requirement. Applying the “Specific” and the “Measurable” aspects of SMART, we need to specify what constitutes “fast enough.”

We can try “No button press in the GUI will delay more than .1 second before providing some evidence of activity to the user, or more than .5 second before completing its operation.”

Sounds more formal, and more specific, but is it realistic (i.e., attainable)? If the “button press” is one that updates a database across a network, what effect will network traffic have? What about the size of the operation? If the button press starts an operation that is dependent on the size of some data set, what’s the largest it could be and how long will that take?

Depending on how obsessive you or some colleague will be in enforcing these requirements, you would do well to add a few “weasel words” to give you some flexibility in the requirements. Phrases like “on average” or “most” will help. Notice, though, that such words are also the cause of much ambiguity, working against the “Specific” and “Measurable” aspects of good requirements. Use them sparingly, if at all.

We should also consider the “testable” aspect of our requirement for speed. Will we be able to measure this? Can we do so repeatedly? Consider the effect of network traffic on response times. Under what network load will the tests be done and the real usage occur? If you want to test under “normal” network loads, how can you control this (for the sake of repeatability)?

It really is an art to craft good requirements. Moreover, a good require- ment for one organization may not work well for another. Some teams, groups, or companies want to be very precise in their use of requirements, viewing them almost like legal contracts for what will be delivered. Such requirements, how- ever, would be greeted with derision in other, more informal, organizations. It’s not that the one will produce good software and the other garbage (well, they might). It’s more a matter of style. Excessively formal organizations will drown in the details and spend way too much time (and money) arguing over the minutiae of the requirements. Overly informal groups will get sloppy with their requirements and not reap the benefits of building the right thing the first time. As is so often the case in life, the answer lies in striking a balance between two forces, one pushing for exactitude and the other pulling you to get going and do something.

So let’s keep going.


There are many people to ask about the requirements for a software project or product. Ask yourself the following questions:

• Who is going to use the software that you develop?

• Who is going to use the data that comes from the use of the software (i.e., who will read the reports generated from the data collected either directly or indirectly from the running of the software)?

• Who is going to support the software and who will support the machines on which it will run?

All these people can be considered “stakeholders” in the project.

So where do you start? That’s a political more than a technical question. Start with your boss and with whoever is the major backer of the project. Then ask your customers. For in-house IT projects, the “customers” are usually very accessible; for software products, the customer’s point of view may need to be represented by marketing and/or customer support people who have had direct contact with the customer base.


Let’s take a look at how such requirements might evolve. We’ll look at the situation through the eyes of a fictional IT guy named Bob.2


11.6.1 Monday Morning, 10 A.M.

11.6.2 Back at His Desk

11.7.1 Documenting

11.7.2 Stakeholder Buy-In

11.7.3 Prototyping