Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

December 5, 2002

Making Enterprise Process Stick

You've decided your company needs a software process, but now what?

by Daniel Pilone

Typically, this column discusses why software process is important and what it can do for the enterprise. Code reusability, consistent designs, and quality testing can help organizations make better use of their resources through a more disciplined approach to strategic software development. What's glaringly omitted, however, is how to actually make a software process work. How much process do you need? Can you swap this artifact for that one? Do you even need most of the artifacts, or should you concentrate on filling up index cards?

The following case study shows one way to make those decisions and put a tailored process in place across the enterprise, project by project. I'll assume that you've decided your business needs a process, but may not have figured out which one. As this case study illustrates, there may not be a "right one."

Getting Started

To begin, my team comprised seven C++ developers of varying skill levels. The project, however, was to be written in Java. The organization wanted a more disciplined software process, but the development culture was informal. Management was very willing to listen to developers but had specific needs of its own that had to be met, namely: accurate scheduling; "sufficient" documentation of both software and functionality; and reliable, traceable testing and bug fixing. These requirements are important for aligning IT capabilities with the strategic goals of management.

For better or worse, none of the developers had any process experience. We began with a one-day crash course on process basics. We discussed key concepts such as the unified modeling language (UML), design, use cases, code reviews, iterations, and unit testing. As we covered each section, I tried to summarize what Rational Unified Process (RUP) and Extreme Programming (XP) said about the topic and opened a discussion on how we intended to proceed. For example, RUP suggests a multipage use case, while XP recommends index card-sized "user stories." The developers, with an instinctive aversion to documentation, voted to try the user stories approach. I expressed my concern but agreed to try it for the first iteration.

To help internalize our process and test some of our decisions, we performed a quick sample iteration. To keep it simple, we decided to make it one week long and move outside of the actual domain of the application. We would run through a full iteration of use case authoring, design, implementation, testing, and deployment for a typical automated teller machine (ATM). However, we would use the real tools and environment whenever possible.

We began by doing our use case survey as a group and capturing the use case model with our UML tool. We wrote a sample use case, developing what would become our use case template for subsequent iterations. This effort took nearly a full day of our five-day iteration. While developing our use case, everyone felt it lacked the detail needed to realistically enter the design phase. We continued to expand our use case from our original XP style user story to a more RUP style with preconditions, post conditions, and alternate flows. We wrote the use case using O'Reilly's DocBook (an XML markup based on SGML) and committed it into our ATM source repository.