Use case modeling has become a very popular object-oriented analysis technique, since Jacobson first published his ideas on the subject nearly seven years ago. The "non-technical" nature of use cases allows users to participate in a way that is seldom possible using the abstractions of object modeling alone. Use cases help the analyst get a grip on specific user needs before analyzing the internal mechanics of a system, providing a basis for early prototyping and a means of driving units for incremental delivery.

With the most hectic times of the Y2000 issue arriving soon, now is a good time to revisit the topic of ethics for Y2000 projects and one of the issues those projects will create for the future.

The New Year is the perfect time for IT organizations to set such lofty goals as improving their software development. For many, that means attempting to move up a level in the Software Engineering Institute's Capability Maturity Model (CMM). As you may know, a CMM assessment provides organizations with an objective report of how they're doing in terms of software development and whether or not they've improved.

If you cannot truthfully say, "I am building software today as well as software can ever be built," you should be looking for a better way. This is the essence of software process improvement (SPI). Despite the apparent simplicity, many software organizations struggle to achieve significant and lasting improvements in the way they conduct their projects.

As we move into 1999, contingency planning is going to take on a much larger role in Y2000 plans. Companies will begin to realize that, despite some claims to contrary, no organization knows the actual state of their operating environment subsequent to 1 January 2000. Likewise, the status of the telecommunications, utility, transportation, and government infrastructure on 1 January are all unknown.

Self-fulfilling prophecies happen all too frequently in IT projects. The process goes like this: Someone involved with the project doesn't agree that one of the steps being asked for is necessary, the project manager coerces them into agreement, the step never happens, and the project fails.

Selecting the right team size -- small -- is the key to a successful project. By successful, I mean one that comes in on time, on budget, with good quality. Further, one that actually completes faster with less effort than the same project attacked with a large team.