Editor's Notes

I once worked for a large software company that, like many large software companies, used a commercially available e-mail system. It allowed attachments and let us communicate inside and outside the LAN, and that was about all I needed my e-mail system to do in the early '90s. Then one day, the founding executive who served as the company's CIO decided he had HAD it with the company that manufactured this e-mail system. Next week, we would all be switched to a different system in order to demonstrate our independence from THAT software vendor. Touché!

The ensuing company-wide meetings to review the changes and retrain the employees led to lots of water cooler discussions concerning e-mail features we once cared little about. But more significantly, we began discussing the company's leadership. What principles were at work here? How could familiarity and comfort (i.e., productivity) be sacrificed, if only for a short ramp-up period, in the interest of pure politics?

This month, Ian Spence offers a program for ensuring that when a large organization makes such a change, it is 1) necessary and 2) both well managed and understood in terms of its effect on the organizational culture. What's important, he says, is sound leadership, and an ability to address and explain the key elements of a simple formula: pain + desire = change.

Have you been looking for creative ways to train your organization on Rational technology? We have an interview with Rational University's Mark Brown, who describes the benefits of pairing Web-based instruction with classroom training. Plus, Brenda Cammarano returns with another installment in her integration series, "Points of Integration Between Rational TestManager and Rational ClearQuest."

For those of you considering ways to better leverage the Rational Unified Process (the RUP), Philippe Kruchten explains "Agility with the RUP," effectively challenging the notion that agility is only possible with the minimal guidance in so-called "lightweight" methods. And D.J. DeVilliers examines the RUP's versatility in depth, offering a variety of ways for introducing the RUP into a development organization.

Yes, we also have more books for you. Our own ace Web developer, John Prince, not only keeps The Rational Edge on a sound technical footing every month -- he writes, too! See his review of Doug Tidwell's XSLT. And Christina Howe, Rational's senior Web manager, reviews The Laws of the

Web: Patterns in Information Ecology.

The results of last year's November-December reader survey are in! I've offered a brief overview of the data you provided, based on more than 600 responses. But don't wait for another survey to let us hear from you.

Happy iterations,

Mike PerrowEditor-in-Chief

Copyright Rational Software 2002 | Privacy/Legal Information

Principles of Process Improvement

by Ian Spence

Technical LeadProcess and Project Management TeamRational Services Organization, UK

Nothing is more difficult than to introduce a new order. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new. -Niccolò Machiavelli, 1513 A.D.

Changing the software development process is hard enough when you are only addressing a single, small pilot project. It becomes exponentially more difficult when the target is a large project, program, department, or organization.

This article takes a look at what makes large-scale process changes so difficult, discusses the role of formal Process Improvement Programs in effecting organizational change, and presents a selection of experience-based principles that can be applied to improve a program's chances of success.

Process Change Is Organizational Change

Before we start to discuss Process Improvement Programs and their effects, we should take a step back and look at the basic concepts that shape any software development organization. The whole organization is based upon four fundamental concepts, as shown in Figure 1.

Figure 1: Concepts that Shape a Software Development Organization

There are a number of fundamental interrelationships among these four concepts:

● Projects create and change Products.

● Projects draw on resources from Organizational Units.

● Organizational Units organize resources and support Customers, Projects, and Products.

● Customers consume and commission Products.

● Customers provide the market and requirements for the Products produced.

Missing from this model is the infrastructure that binds all of these concepts together: the Organizational Culture (see Figure 2).

Figure 2: Organizational Culture Is the Infrastructure of a Software Development Organization

In its purest form, organizational culture can be thought of as the philosophy and practices that drive the form the organization takes, the products it produces, and the customers it attracts.

For organizations engaged in the business of software engineering, the organizational culture comprises a combination of the underlying business culture and business procedures, the larger company culture, operational procedures, and the software development environment. The latter encompasses all of the things a project needs to develop, deploy, and maintain a product, such as processes, tools, guidelines, templates, and technology.

It is also the area that most directly affects the software engineering business's performance, and the one most organizations choose to address when attempting to achieve performance improvements. The key message of this article is that the software development environment, and by implication the software development process, cannot be changed in isolation from the organizational culture. Any significant change to the development environment will, and should, have an impact upon the other areas of the organizational culture.

In fact, to produce lasting improvements in a software development

organization's performance, we must:

● Embed the need for improvement directly into the heart of the organizational culture.

● Adopt a holistic approach that will continuously improve the support provided for all aspects of the organization.

Often, the most effective method for producing fundamental change within the software development environment is to change the underlying software development process. This means embarking on a program of organizational change.

Why Is Organizational Change So Hard?1

Organizations must change in order to keep pace with the changing environment around them. Living in denial and freezing the organization simply causes necessary changes to pile up until they cause a crisis. So why is organizational change so hard to achieve and crisis so prevalent?

Unfortunately, people resist change. In fact, whether because of inertia or fear of the unknown, people will often actively oppose change, or at least slow it down to what they feel is a manageable pace. In order to change an organization, you must understand these forces and channel them to enable, rather than oppose, change.

In his 1995 paper "Affecting Organizational Change,"2 Roger Hebden expresses the forces of change as a simple formula:

pain + desire = change

The fundamental tenet of this formula is that change is ultimately driven by emotions. Pain and desire are the forces that drive us to make a change and to accept it. Pain is the catalyst that initiates a change, and desire is the force that pulls us toward a goal. A successful transition entails understanding and managing the perceived level of pain and the desire for a solution. This is what D.Connor calls pain management and remedy selling.3

Pain management means identifying and communicating what the fundamental issue is (our experience shows that the underlying problem is often in the organization's process or in the absence of one) and why change is necessary.

Remedy selling consists of two activities: solution selling and transition planning. It isn't enough to describe the ideal goal. To define a solution, you also need a path from where you are to where you are going, with some clearly defined intermediate milestones.

Change will not happen just because management says so. It is too easy to generalize about both problems and solutions. "Every project must follow the Rational Unified Process" is a sweeping generalization about how projects need to act; however, it does little to initiate change.

To successfully implement an organizational change, the adopting organization must:

● Identify change agents at various levels of the organization. This is the set of individuals who will take on the mission to make the change happen.

● Formulate the real nature of the problem. The change agents must understand the real nature of the pain and communicate it to the rest of the organization to raise awareness.

● Plan the changes in small, reasonable, and measurable steps describing both the goal, and the path to the goal. The plans must balance the need to achieve immediate, tactical improvements against the organization's longer-term strategic objectives.

● Communicate the changes in terms of tangible, quantifiable achievements and activities in a way that is understandable to all levels of the organization.

When any sort of large-scale organizational change fails, it can usually be ascribed to one of the following causes:

● Failure to incrementally implement the changes.

● Lack of management support.

● Lack of practitioner support.

● Lack of stakeholder support (i.e., customers, other departments, subcontractors, and suppliers).

● Lack of willingness or ability to deal with organizational change.

It is exactly these non-technical issues that derail many organizations' attempts to fundamentally change their software development environment.

Introducing the Process Improvement Program

Process changes affect individuals and organizations more deeply than changing technology or tools, since they strike at the heart of people's fundamental beliefs and values, changing the way they view their work and its value. In some cases they can even go as far as changing the organization's reward structure as well as the physical working environment, business culture, and politics. They also affect the way the organization works at the project level, the department level, and with other organizations. As Ivar Jacobson notes in Software Reuse: Architecture, Process, and Organization for Business Success,4 this kind of process change amounts to "reengineering your software engineering business."

The management, planning, coordination, promotion, implementation, and measurement required to support this kind of change requires a formal Process Improvement Program.

This program needs to address the following areas:

● People. This includes their competencies, skills, motivation, and attitude; everyone needs to be adequately trained and motivated.

● Projects. The projects interacting with the Process Improvement Program must feel that they are receiving direct benefit from their involvement, so they should understand both the potential effectiveness and the costs of the proposed changes.

● The process model. This should define dependent structures, activities, and practices as well as artifacts to be produced.

● Distribution mechanisms. This includes how the process will be described, promoted, and distributed.

● Supporting tools. New tools will inevitably replace old ones, and this will require customization and integration.

It should also take into account the broader stakeholder community, including:

● Managers who are responsible for the performance of the software development organization. Any Process Improvement Program must have executive support, so these people must understand why the process is being changed, the potential return on investment, when and how progress is being made, and that expectations need to be carefully managed.

● Customers, both internal and external to the company. These people may need to be informed that the organizational process has changed, because it could affect how and when their input will be addressed and how products will be delivered.

● Other parts of the organization may also be affected. Sometimes changes in one sector of a business may lead to resistance and skepticism from other sectors that may not understand the reasons for the changes. Even if they don't have a direct influence on the program, ignoring other parts of the organization may cause political problems.

The Process Improvement Program is primarily an agent of organizational change. Its primary method for facilitating change is by improving the underlying software development process and its supporting tool set.

An Experience-Based Approach to Process Improvement

Experience also shows us that a number of basic principles can be applied to improve the Process Improvement Program's chances of success:

● Run it as a business program -- think "return on investment."

● Understand the existing environment.

● Build on the best -- don't reinvent the wheel.

● Make measurable, incremental improvements.

● Focus on projects and products, not organization.

● Use mentors, not enforcers, to facilitate rather than obstruct.

● Distribute process ownership.

● Keep people informed and involved.

The rest of this section looks at each of these principles in more detail.

Run It as a Business Program -- Think "Return On Investment"

Manage and plan the Process Improvement activities just as you would all the other activities in the business: Set up milestones, allocate resources, and manage and follow up as you would for any other program. Think "return on investment" when scoping activities; focus on those things that will pay back more than what was invested.

Some Process Improvement Programs devote too much time and too many resources to developing extensive guidelines, customized processes, and additional process-related material before beginning a project. There are four major problems with this:

● People do not read extensive descriptions.

● Doing everything right from the beginning is very difficult. It's better to try out something small, adjust it, and then expand the scope.

● People with process knowledge should spend most of their time mentoring, not writing extensive descriptions.

● These activities produce no measurable return on investment. Creating process definitions will not improve anything unless you apply the process.

No organization can afford to wait years for the perfect process to be fully documented before realizing actual improvements or a return on investment. The Process Improvement Program, whatever its ultimate aim, must include a substantial payback on the projects it affects.

Understand the Existing Environment

Before embarking on any major Process Improvement Program, the current development environment must be clearly understood, including:

● Current processes and practices

● Current tool set

● Current roles and team structures

● Products to be supported and produced

● Organizational process maturity

● Dynamics and politics of the current organizational structure

Without establishing this baseline understanding, you cannot make decisions about which process improvements should have highest priority and how to measure improvements.

Build on the Best -- Don't Reinvent the Wheel

The Process Improvement Program needs a firm foundation to build on. There are three sources available to build this from:

● Things that the organization does well. Harvest best practices from the most successful projects.

● The leading practices and products of the industry.

● The experiences of the people involved in the program.

Remember that the objective is not to transform the environment in one fell swoop, but rather to improve things bit by bit. To this end, the Process Improvement Program must focus on the organization's core business, prove all proposals in conjunction with real projects, and ensure that it is improving, not degrading, the performance of the business.

Make Measurable, Incremental Improvements

Implement environment, process, and tool changes incrementally to avoid overwhelming project teams with too many new challenges all at once. Introducing a new environment one piece at a time will increase the probability of success, and if you have assessed the development organization carefully, then you will know which parts of the process to introduce first. Typically it is best to start with the most problematic areas.

For example, an appropriate approach might be to:

● Focus the first iteration on improving the way requirements are captured and managed.

● Focus the second iteration on the analysis and design of applications and their components.

● In subsequent iterations, develop and deploy more and more parts of the environment.

Focus on Projects and Products, Not Organization

Too many process improvement initiatives focus on the organizational structure to support the desired process before the process itself has been proven or accepted. The thinking is, "If I put all my pieces in the right places, then they will automatically work in the right way and produce the right things," or "If we build it, they will come." In fact, this approach is naive at best and disastrous at worst.

The organizational structure should depend on the process and not vice versa. The process you select should depend on the types of projects your organization undertakes and the types of products you produce. You can

establish an optimal organizational structure (an objective of the Process Improvement Program) only when a process is in place. The required organizational structure should grow organically from the overall success of the Process Improvement Program. In fact, to develop, establish, and deploy the products of the Process Improvement Program, a number of interim, transitional organizational structures are usually required.

The criteria for judging the effectiveness of an organizational structure are the same as those for the Process Improvement Program: the quality of the products produced and the efficiency of the projects that produce them. Focus on the products and projects within the organization before attempting dramatic restructuring of the organization itself.

Any process recommended by the Process Improvement Program must provide a firm foundation for the continued evolution of the organization's product set. The process must be scalable and capable of continuous improvement and evolution alongside the business that it supports. As the business grows and changes, the process will start to dictate and mold the underlying organizational structure.

Most successful Process Improvement Programs start as small, focused projects working within the existing structure. Remember: Consultants, centers of excellence, tiger teams, hit squads, and so on, are just tools to be deployed as part of the ongoing Process Improvement Program.

Use Mentors, Not Enforcers, to Facilitate Rather than Obstruct

Mentors act as drivers of change. Experience shows that using mentors is crucial if you want the implementation of a new process to succeed. Without them, there's a clear risk that people will fall back into their old habits.

Allocate sufficient resources, and plan mentoring activities carefully. The Process Improvement Program needs both the resources and the budget to enable the mentoring of the projects adopting and configuring the process. The cost of adopting the new process must not fall solely upon the adopting projects. As well as supporting the project's development staff, it is important that a process mentor works with, and supports, the project manager to ensure that the process changes progress in synergy with project work.

The mentor should focus on transferring both knowledge and responsibilities to project members and ultimately become dispensable and obsolete. Mentors must also remember their responsibilities to the Process Improvement Program, including:

● To harvest best practices from the projects they support.

● To make "just in time" process improvements and configurations.

● To promote the Process Improvement Program within the projects.

Some organizations adopt a hands-off, review-led approach to process improvement. Instead of actively engaging with the projects to promote and facilitate adoption of the new process, they rely on threats and reviews to ensure compliance. This "enforcer" approach is fundamentally flawed; the

involvement nearly always comes too late for the projects adopting the new process and consequently obstructs, rather than facilitates, adoption as well as project progress. In many instances, without a mentor as process driver, the whole implementation fails.

Distribute Process Ownership

Distributing ownership of the process among project members gets them more involved, reduces their opposition to the changes, and allows their experiences to be leveraged to the benefit of the whole organization. The resulting process is better when the "real experts" -- people actually working on the project -- develop it themselves. Distributing process ownership reduces the likelihood that projects will become too heavily dependent on outside consultants and helps project members feel like part of the program rather than its victims.

As soon as possible, appoint people on the projects to be responsible for each in-scope, core area of process improvement. They should be people who know the area well, can mentor other project members, and will champion the Process Improvement Program within the project.

They should have primary responsibility for configuring and publishing individual parts of the process, and they should also help those who own the different parts of the process to define, configure, and document the process.

Keep People Informed and Involved

The greatest threat to any organizational change is people's natural resistance to change. Introducing new processes and tools means that people have to modify the way they work, and many grumble about it, or worse. This creates the risk of a negative spiral: Negative attitudes can lead to poor results, which then lead to even more negative attitudes, and so on.

Some actions you can take to prevent negative attitudes from taking over are:

● Set realistic expectations. Do not oversell the new process or the new tools.

● Explain why the change needs to happen. Makes sure people know what problems the organization has that need to be solved. What changes in technology require a new process and new tools? How will people benefit from using these new tools and process?

● Inform everyone in the organization about what is happening. This information doesn't have to be very detailed; the important thing is to make sure people know about the changes.

● Remember stakeholders, such as customers or sponsors. If you are changing from a waterfall to an iterative development approach, for example, the stakeholders must understand how an iterative development project is managed and how progress is measured. With an iterative development project, they shouldn't expect a completely frozen design at an early milestone, for example, and they should also

know that requirements may be captured differently.

● Involve key people in the change work. Give them responsibility for parts of the process.

● Educate project people about the new process and tools. After all, they will need to understand both how the new process works and how to use the new tools.

The Process Improvement Program Is an Agent of Change

The Process Improvement Program is a change mechanism, not a department. Although it will initially have responsibility for supporting and maturing the software development environment that it produces, the Program must resist the temptation to overcentralize and start empire building.

As we have seen, the major issues involved in successfully effecting organizational change are political and personal rather than method-, tool-, or technique-related.

The program's management should keep in mind that:

● The support organization may already be in place. Most organizations already have teams charged with supporting components of the software development environment. These people have knowledge and experience that will be essential to implementing the Process Improvement Program effectively, and they should be brought onboard as soon as possible.

● Don't attempt to roll out changes before they have been established and proven. Many programs set up a mass of central teams and attempt to mandate the way that people should work before the process itself has been established or proven. For example, many organizations spend a great deal of money setting up and building reuse repositories before they have even proven their capability to produce and maintain any formal reusable assets.

● Don't get carried away with your own publicity. Transforming an organization takes time. The ultimate result of the Process Improvement Program may be to transition all teams to component-based development, or to set up the structures of a reuse business. But these things will happen only if they will result in overall process improvements, and they must be approached step by step.

● Any centralized solution is only a framework. As the software development environment matures, it is very tempting to start believing that there is a "one-size-fits-all" solution that can be mandated for all existing and future projects. Different areas of the process vary in response to different forces: The project management process may vary with the size and formality of the project, the design and implementation process with the technology chosen. Any centralized process must provide a common environment for the successful execution of projects while preserving the autonomy that the

projects need to be able to progress effectively.

Individual projects will also need to tune the process within the constraints laid down by the organizational culture. The process must encourage this, and provide a mechanism for the individual process improvements to be fed back to the Process Improvement Program and made available to the rest of the organization.

● Bootstrap the software development environment (i.e., "Eat your own dog food"). Use the concepts, methods, tools, and techniques of the proposed solution to build the solution itself. For example:

■ If you are proposing the introduction of business modeling techniques, then prove these techniques by modeling the software engineering organization.

■ If you are proposing that projects manage their requirements using a specific process and tools, then use these to manage the software development environment's requirements.

■ If you are proposing a specific project management approach, then use this approach to manage the Process Improvement Program.

In fact, this advice applies to most Program areas: Perform all activities using the new process that you want the organization to follow.

The Process Improvement Lifecycle

If you are truly successful in your Process Improvement Program, then process improvement itself will become one of the essential, underlying tenets of your organizational culture. The Process Improvement Program may never end; it will continue iterating through the basic cycle shown in Figure 3.

Figure 3: Process Improvement Program Phase Lifecycle

The Process Improvement Program itself consists of a number of phases, all of which follow the cycle shown in Figure 3. Each phase encompasses planning and implementation for a specific set of process improvements within, or extending, the underlying process framework. As the process establishes itself as a fundamental part of the organizational culture, the whole organization should move into a state of continuous process

improvement. See Figure 4.

Figure 4: Continuous Process Improvement

The early phases will focus on establishing the software development environment. Once that has been fully implemented, the later phases of the program will be concerned with tuning, maintaining, and supporting it. The quest for process improvement should be ongoing: We should always strive to learn from our experiences and continually evolve and improve both the process and the organizational culture.

The size, number, style, and duration of the phases within the program depend on a detailed knowledge of the organization being addressed, the state of its current processes, and the scope of the Process Improvement Program itself. The RUP contains detailed guidance and illustrations of typical process implementation patterns and approaches.

Another essential source of guidance is the Carnegie Mellon Software Engineering Institute. In addition to publishing the Capability Maturity Model® for Software, which itself acts as a framework for undertaking process improvement, the Institute has developed the IDEAL model to guide organizations in planning and implementing an effective software Process Improvement Program.5 Based upon the Capability Maturity Model, this model presents a more formal, and thoroughly documented, iterative lifecycle than the simple model shown in Figure 3.

Summary

To produce long-lasting improvements in software development organization performance, we must embed the need for improvement directly into the heart of the organizational culture and adopt a holistic approach that continuously improves support for all aspects of the organization. This means embarking on a program of organizational change.

The most effective method for producing fundamental change within a software development environment is to change the underlying development process through a Process Improvement Program. The Program should be set up and managed like any other business program, with a strong focus on return on investment and several phases of implementation.

Strategies for success include the following:

● Kick-start the Process Improvement Program by focusing on problem areas for which you can easily achieve positive results and people can

see benefits early on.

● Communicate the problems with today's organization; if people understand those problems, they will accept the need for change.

● Do not try to do everything at once. Instead, divide the implementation into a number of increments and, in each one, implement a portion of the new process together with supporting tools. Focus on areas in which the change will have the most impact.

● Build on the best. Don't throw away all the things the organization does well. Integrate these into whatever standard process you choose.

● Implement the process and tools in iterations of actual software development projects to verify the process and the tools early on in a real environment. The process must improve and evolve in partnership with projects that will use it.

● Distribute ownership of the process among project teams. This will produce a better process, get people more involved, and reduce resistance to change in the projects.

The project team members assigned to the Process Improvement Program should:

● Mentor and facilitate projects adopting the process.

● Work closely with projects to capture and document appropriate process improvements.

● Promote the new process within the organization.

They should not attempt to draft a perfect one-size-fits-all process. The process will always require local configuration and provides three things:

● A framework for projects to quickly instantiate their process.

● A common basis and minimal acceptance criteria for all projects.

● A library of tools and techniques that projects can apply.

Implementing a new process, new tools, and possibly new technology makes a software project's schedule more volatile. Be sure to allocate enough time and resources to implement the process, train people, and so forth during all iterations. And remember: Keep all stakeholders well informed and involved as you make progress with your Process Improvement Program.

References

Books and Articles

D. Conner, Managing at the Speed of Change. Random House, 1992.

J. Jellison, Overcoming Resistance: A Practical Guide to Producing Change in the Workplace. Simon & Schuster, 1993.

Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.

Roger Hebden, "Affecting Organizational Change." Rational Software, 1995.

Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber, "Capability Maturity Model for Software, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, February 1993.

Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, and Marilyn W. Bush, "Key Practices of the Capability Maturity Model, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, February 1993.

Robert McFeeley, IDEAL: A User's Guide for Software Process Improvement. Software Engineering Institute CMU/SEI-96-HB-001, February 1996.

Rational Unified Process

This article draws very heavily from the following sections of the Environment Discipline within the Rational Unified Process:

● Concepts: Effect of Implementing a Process

● Concepts: Mentoring

● Concepts: Managing Organizational Change

● Concepts: Environment Practices

● Concepts: Implementing a Process in an Organization

The Carnegie Mellon Software Engineering Institute

For more information on Process Improvement Programs and information on the Capability Maturity Model for Software and the IDEAL model, visit the Carnegie Mellon Software Engineering Institute Web site:

● http://www.sei.cmu.edu/ideal/ideal.html

● http://www.sei.cmu.edu/cmm/cmms/cmms.html

● http://www.sei.cmu.edu/sei-home.html

Notes

1 This section is extracted from the Rational Unified Process: Environment/Concepts/Managing Organizational Change, which in turn draws heavily upon Roger Hebden's paper, "Affecting Organizational Change." (See #2 below.)2 Roger Hebden, "Affecting Organizational Change." Rational Software, 1995.3 D. Conner. Managing at the Speed of Change. Random House, 1992.4 Ivar Jacobson, Martin Griss and Patrik Jonsson, Software Reuse: Architecture, Process and

Organization for Business Success. Addison-Wesley, 1997.5 See Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber, "Capability Maturity Model for Software, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, February 1993 and Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, and Marilyn W. Bush, "Key Practices of the Capability Maturity Model, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, February 1993.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Who Are You? How Are We Doing? A View from The Edge

by Mike Perrow Editor-in-Chief

The Rational Edge

Have you ever found it impossible to explain what you do for a living? After eighteen years of working in various facets of the high-tech industry, from customer support to technical writing, I can say with some confidence that I'm not the only one with this problem. At family gatherings, forget it. Even my most computer-literate relations have only one category for people who work in the software industry: "He does something with programming." Well, not exactly… And it's the same for my more technically savvy colleagues -- the software engineers, evangelists, and "thought leaders" I know at Rational and elsewhere. One SE told me recently that she explained her job in detail to her mom, who looked at her carefully, then nodded: "So my daughter's an editor!" Close enough.

I may be going out on a limb here, but there's one aspect of returning to work after a holiday break that isn't so bad: Our identities are partly restored. I, for one, can hold my head higher. I am no longer simply "that son-in-law who undercooked the turkey, who does something with programming." Here, I'm the editor of a monthly, online magazine for software professionals.

But do I know for certain that software professionals are reading it?

Good question. We conducted a survey to find out. As you may know, The Rational Edge turned one year old this past December. So to mark our first anniversary, we set out to learn more about your identities, to see how you describe your roles in software development, and to find out what

you like or dislike about this publication. We heard from more than 600 of you, which gives us a very good basis for moving forward with our plans for developing more targeted content and improving The Rational Edge over the coming months in ways you will appreciate.

Here's what we found out …

What You Do

Most readers of The Rational Edge serve in technical roles within their software development organizations. Only ten percent are in business leadership positions. Most of you said you were an individual contributor, a team leader, or a project manager. And of all the areas in the software development lifecycle, which would you guess was the most frequently selected? Modeling? Testing? (This was a "check ALL that apply" question.) No, more than two-thirds of you indicated some involvement with "Requirements Management." Modeling and testing registered relatively high, too, but these results suggest that, no matter where your specific expertise may lie, chances are you have something to do with requirements. Here's my guess: You're either tracking requirements, defining them, or communicating them -- with practitioners and project managers alike all involved in this team sport.

What's your job?

Individual contributor: 36%

Team lead: 29%

Project manager: 25%

Business unit manager: 6%

Executive level manager: 4%

What areas of the software development lifecycle do you work in? (Check all that apply.)

Requirements management: 68.9%

Architecture/system design: 65.0%

Application modeling: 54.5%

Business modeling: 49.4%

Data modeling: 46.5%

Testing: 46.1%

Writing code: 37.7%

Configuration management: 37.3%

Defect tracking: 35.7%

Engineering: 34.2%

Debugging: 28.3%

Consistent with the finding that most of our respondents play technical roles, you selected the role of "project manager" most frequently (thirty-

four percent) as the answer to "Where do you see yourself in five years?" Only four percent of you believe you'll retire during that time. Interestingly, most of you who are "project managers" today plan to be in that position five years from now -- slightly more than those who see themselves moving up to a director-level position. Apparently, you foresee enough challenges in that position to keep you engaged for the long haul.

Team Size

According to our survey, the average size of your software development organization ranges between six and fifty people working in various areas of the development lifecycle -- although ten percent of our respondents reported working for large development organizations, more than 500 strong.

What You Like to Read

As for other kinds of publications you like to read, again our findings were fairly consistent. You favor technology-oriented magazines, although your responses indicate a significant interest in the business side of the high-tech industry as well. More than half of you read technical journals like Dr. Dobbs Journal and Application Development Trends, and nearly half of you also read technical news sources like InternetWeek and Computerworld. But a high percentage of you (forty-one percent) stay up to date with the intersection between business and technology as well, via publications such as InformationWeek and Wired Magazine. And a full fourth of respondents say they read CIO, BusinessWeek, or other management-oriented publications regularly.

So, what kind of articles do you like most in The Rational Edge? Nearly fifty percent of you said you prefer articles either about strategies for improving software architecture and development process, or technical articles about development strategies such as applying UML concepts. Seventeen percent of you relish articles about specific Rational

technologies, too. Given these results, you can expect to see us continuing to deliver content on software architecture, the Rational Unified Process (RUP), the UML, configuration management, requirements, testing, etc. And we'll continue connecting these topics, when appropriate, to the tools Rational offers to facilitate these methods and strategies.

Your Additional Comments

Every month, The Rational Edge publishes reader questions with answers from our technical team members, so that you can all benefit from their practical advice. What you DON'T see, directly at least, are the suggestions we receive from readers that have resulted in improvements to the publication over the past year. For example, better navigation through our archived issues was the result of several reader suggestions (although we know we can improve more in this department). Likewise, reader demand prompted us to introduce PDF options for Edge content back in the summer, and that has helped the editorial staff maintain and share content as much as it has benefited our readers.

Last month's survey offered another opportunity for you to give us free-form commentary, and you had plenty to say. Below you'll find a variety of remarks -- the good, the bad, and … well, we didn't hear anything truly ugly. Generally, I have to say I'm delighted by the overwhelmingly positive response we received. The following selected comments are published in their entirety (no edits except for necessary spelling or grammatical corrections).

Excellent magazine. I can use the articles to promote adoption of RUP which in turn creates a pull on proper use of tools. But I would like to see more articles on solving what might be common problems -- such as "How do I get everyone on a large project to iterate?" or "What are the mechanisms in RUP and its supporting [sic] that provide high value integration?"

The Rational Edge provides a valuable bridge between the theory and the practice of software engineering, i.e. the ideal world and what actually happens in practice. As a relative novice in the realms of UML, risk driven development etc. I found myself having to spread my reading of the topics very broadly -- lots of books and articles, each having their own strengths and weaknesses, many of which just failing to go that extra mile and show a realistic project design from beginning to end and through several iterations. I have found The Rational Edge to be useful in filling in some of the gaps I have encountered during my learning.

More best-practices and lessons learned about successful software development (project mgmt, program mgmt, design/analysis, requirements engineering, technology change management, engineering management).

Would like to see more on Technical articles on Rose and database modeling. As well as Project management relates to modeling, this is weak area for PMs.

I like the fact that your articles respect the independence between your products and software engineering issues. Your commitment to software process is evident in every article.

More on architecture, please. It's the one area of RUP that I use all the time, but never seem to feel I ever get a handle on.

I love seeing what articles are in the new issue. I've seen a general improvement in the quality of the articles, and the timelineness of the topics. I think that this magazine is probably one of the overall best technical trade journals currently available. Keep up the great work!

I would like more articles by non-Rational employees. I am particularly attracted to articles on the development process and on project/team management.

As a software consultant, I find reviewing and reading the articles contained in The Rational Edge a very good use of my time. On more than one occasion, an article has helped me clarify my thinking or analysis regarding a deliverable that I need to produce for my project. I have also submitted a question to the subject matter experts at Rational and received a most excellent response. I consider myself to be a Rational Unified Process evangelist and the RUP methodology, supported by Rational tools, has contributed to my professional success. In other words, I can't praise Rational Corporation high enough! And thanks to the good folks at The Rational Edge.

Coverage on ROI, process improvement case studies, and custom configuration of tools and RUP would be really valued.

I am getting a lot of good information on requirements from your current issue [November 2001]. I would like to continue to see articles on requirements management as well as software development. I am

especially interested in articles on project management and how to utilize Rational products to manage projects.

Some additional samples in articles would be very helpful (e.g., UML diagrams).

The Rational Edge is an exceptional publication and one of the few I try to read cover to cover each month.

Ok… I hope you don't mind that I conclude this sampling of reader comments on a positive note. We received more than twenty-five pages worth of comments from you, and we promise to incorporate as many of your suggestions as possible into our plans for the coming year. In the meantime, do not hesitate to get in touch with me with additional suggestions (or article ideas!) at mperrow@rational.com.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Web-Based Training and Instructor-Led Training: A Perfect Combination

Rational University (RU), the education division of Rational Software, now offers Web-based training (WBT) courses via the new Rational Developer Network. RU is expanding its online offerings for 2002 as part of a bold initiative to embrace e-learning. We asked reporter Jane LaRoque to interview Mark Brown, head of RU's Web-based training initiative, to find out more about these new developments and how they will benefit Rational users.

Q. First, tell us about the Web-based courses that are available now and the response you've had to them.

A. Right now, we have eight courses available through Rational Developer Network:

● Principles of the Rational Unified Process

● Fundamentals of Rational RequisitePro, Release 2001A

● Fundamentals of Rational RequisitePro, Release 2002

● Fundamentals of Rational Rose

● Fundamentals of ClearCase/UCM

● Principles of Software Configuration Management with Rational ClearCase/UCM

● Principles of Object Technology

● Principles of Defect and Change Tracking with Rational ClearQuest

The response to these offerings has been really enthusiastic, which is why

we're eager to add more Web-based courses to supplement our overall curriculum. The content of the Web-based courses is the same as that of popular, instructor-led courses given at Rational training centers worldwide; we're just using a new delivery medium that allows us to reach more people. In all our courses, we ask customers for evaluations and monitor their feedback very closely. Each page (screen) in the new Web-based modules has a Feedback button, and there's also an evaluation form at the end of the module. We'll continue to gather suggestions and data and to make improvements as we develop new modules.

Q. What's your approach to WBT?

A. First, we divide the online courses into several, easily digested modules, and then divide the modules into lessons and activities. Basically, we tell you what high-level skills are covered in the module and what specific skills are included to support them. The sequence of the modules isn't rigid, however; we allow random navigation to any module or lesson. That makes it much easier for students at all levels of knowledge and background to find a comfortable starting place. There is also a course map that lists every page of every section. The newer courses also have an industry-standard "tree browser" that lists modules and sections.

The starting courses are primarily "principles of . . ." and "concepts of . . ." courses. They give people a feel for how these Rational products actually work before they even install or implement them. There are two types of courses -- some provide the basic concepts of software engineering best practices, and other courses cover the foundational skills for using the Rational products. The next series of courses we're working on will emphasize tools usage and mastery. We're designing the modules to be flexible so people with a little bit of background or a lot of expertise are equally comfortable.

How do you get to the WBT courses on Rational Developer Network?

It's easy. If you're a Rational customer with an active Maintenance agreement, you can go to www.rational.net and become a Rational Developer Network member. When you sign in, simply click on Training Central from the Rational Developer Network homepage. That will take you to descriptions and links for our courses. You can get started right away by registering for a course and paying with a credit card, or you

Q. What do you see as the main benefits of WBT?

A. Well, the biggest one is that people can take courses 24/7/365 by just connecting to the Internet. Once they register, we allow them to complete their courses over a ninety-day period in multiple sessions. Most courses take two or three hours total. There are exercises and pop-up menus that guide you through the material, and you can print what you need for review and reference.

can contact your local account representative to find out how you can purchase a group of WBT courses for yourself or your team. If you're looking for an instructor-led training course at a Rational Training Center, check out the course descriptions at Training Central, or go to www.rational.com/university.

Another big benefit to customers is that there are no travel costs. Plus, people don't have to leave the office, so downtime costs are also lower. Of course, now, cost is not the only factor people consider in traveling. Rational was already committed to expanding these WBT offerings before September 11, but the impact that's had on business just strengthened our resolve. We've found that our customers and staff are more cost-conscious and more reluctant to travel for safety reasons. While WBT doesn't entirely replace the value of instructor-led training, its flexibility and accessibility provide an optimal solution for businesses who must train their teams but also find their travel restricted.

Historically, technical publications have provided a lot of good information in text format, but it's static. WBT puts the information at your fingertips and constantly refreshes it for you. At the end of a course, you've really learned how to do something tangible with the latest software. And different users get different benefits. Experienced people can use WBT as a reference tool -- for a training refresh on something they're doing that day, or to look up a specific piece of information. New users can go through the entire course sequentially and repeat sections as needed. Someone who is considering a Rational product purchase can tour a course to see how it works. Another beauty of WBT is that it has infinite patience with people at all levels.

Finally, our delivery environment is Rational Developer Network, and when you add to the equation the dialog of peers and subject matter experts you can find there, WBT really provides a powerful way of keeping people informed and engaged in their work.

Q. Do the WBT courses and instructor-led training (ILT) cover the same territory?

A. The Rational WBT and ILT complement each other. The Web-based classes don't duplicate the instructor-led classes; they give participants the background to get more from their classroom time. The ILT courses immerse students in an educational experience by providing more in-depth material, a classroom environment away from daily

work pressures, and an expert instructor with years of experience using and deploying software development tools. When our instructors go to a customer site to do team training, they deliver the same basic course, tailored to the customer's project and environment. When used as introductory training prior to ILT courses, WBT can level the playing field so that when people sit down in the live class, they can all begin with the same basic information; they know the key concepts, terminology, and background information. They can walk in with questions and sample work, and ask tough questions. And instructors can dive right into the

meaty stuff and not have to take up time getting everyone up to speed. They can drill down into the detail and set up lab experiences to reinforce key ideas. We suggest that customers have a detailed discussion about their needs with their account reps when they set up the training.

Q. What else can you tell us about Rational's strategy and plans for Web-based training?

A. My philosophy is "e-Learning everywhere!" My team believes that learning should be seamless, meaning that technical publications, WBT, and Help text should be tightly integrated within a product. My background is in Knowledge Engineering, which is about structuring large amounts of information so it becomes usable. In designing Rational courseware, I put this background to work -- to get content, images, and technical stuff to work together in an understandable and memorable way. And then, our Web-based delivery really lowers the barriers to learning by giving people round-the-clock access to "just-in-time training"; if they have a problem, they can get right to an answer. The path might start at the Help text and then move into part of a training module.

As for the future, our plan is to develop more and better Web-based training. We've brought in a terrific, multi-disciplinary team of instructional designers, HTML wizards, and graphics specialists who work together to create some amazing things. We have the capability to deliver the full range of WBT courseware, from basic concepts to specialized training for individual roles, environments, or project types. We'll also be working on further integration with the Rational tools and the artifacts and discussions available on the Rational Developer Network.

Eventually, we hope to develop streaming video, Web seminars with individual experts, and group labs where people can work together in diverse locations. We plan to provide WBT in other languages for our international customers, too. In the future, we'll have a better tracking system for students so we can tailor courseware and reference materials to their learning history and individual needs. We also plan to build more toolkits for our technical support staff and instructors so they can easily assemble a customized course using various media in the classroom setting.

As I see it, Rational University is exploring the boundaries between WBT and ILT. We know that ILT scales linearly; you can only get so many instructors in front of so many people. WBT scales nonlinearly, and can reach thousands of people. Right now, I think we're moving into a "Golden Age of e-Learning" because the world has crossed the bandwidth line: Most people have access to a 56K modem or better, and computer hardware and software have advanced as well. Research studies have shown that unless people refresh about 20 percent of their skill set every year, they grow obsolete in about five years -- so WBT is the perfect foundation for ensuring survival and success.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Agility with the RUP

by Philippe Kruchten

Director of Process DevelopmentRational Software

What characterizes an agile software development process? Is agility about being fast to deliver? "Faster, better, cheaper" is a laudable goal, but faster in itself is not necessarily the right thing to achieve if it is detrimental to quality. Is agility about minimizing the size of the process used to develop software, the size of its description? Not really, or by that measure the null process would be the best.

Agility, for a software development organization, is the ability to adapt and react expeditiously and appropriately to changes in its environment and to the

demands imposed by this environment.

An agile process is one that readily embraces and supports this degree of adaptability. So, it is not simply about the size of the process or the speed of delivery; it is mainly about flexibility. In this article, I will explain how the Rational Unified Process® (RUP®) is a process framework that allows this flexibility.1

What Is the Rational Unified Process?

The RUP has several facets:

● It is a software development process.

● It is a catalog of excellent and field-proven software development practices.

● It is developed and commercialized like a software product.

● But it is first and foremost a software process framework.

The RUP was intentionally designed with a wide scope of applicability to accommodate variations in:

● Project size

● Application domain (business system, technical system)

● Technology used (language, platforms)

● Business context (in-house development, product development, independent software vendor, contractual development)

As a process framework, the RUP provides a systematic way to capture, organize, and deliver software engineering know-how. It relies on a simple and rigorous underlying process model to organize the know-how: It is more than just a collection of texts or books.

But this process framework is not just an empty shell. It comes prepopulated with a large amount of process know-how already captured over the last fifteen years by Rational folks (and people working for companies later acquired by Rational, and some of our partners, such as IBM, HP, and BEA). The RUP is not a closed, finite process, published once and for all, and it does not answer all the questions or solve all the problems of software development. The RUP framework is an open framework, which continues to evolve and is updated twice a year: Its structure is refined, the associated tool support is developed, and its content is expanded.

On one hand, the Rational process development group continues to add to and update the RUP's content as technology evolves and based on feedback from users of its installed base. On the other hand, many partner companies and individuals have adopted RUP to capture and organize their own process know-how, which they use for their own purposes, resell, or integrate with the framework delivered by Rational.

The RUP Framework

The RUP framework is organized around several simple, interconnected concepts:2

● It defines process roles, which capture the competence, skills, and responsibilities that individuals taking part in the development may be called on to use.

● It describes the work that each role performs in activities, decomposed into steps.

● These activities operate on concrete artifacts: models, code, documents, and reports.

● There is a wealth of associated guidance for the roles, activities, and artifacts, in the form of guidelines, templates, examples, and tool mentors, which explain how to perform a certain activity with a given tool.

● All of these process definition elements are organized into disciplines.

Presently the basic RUP defines nine disciplines, more than forty roles, and a hundred artifacts, and contains more than a thousand guidance pages. You can also find process "plug-ins" that add even more functionality and content. Some of its detractors call RUP a "heavyweight" process and depict it as a behemoth that forces you to do zillions of useless and unnatural things. We see it more as a rich palette of knowledge from which to choose what you need.

Let me give an analogy. With a well-chosen vocabulary of, say, 800 words, you can get along in many circumstances in many parts of the world. But if you are given a full-blown dictionary (like Webster's), first, nobody forces you to use each and every word it contains; second, you can adjust your level of speech to adapt to many other situations beyond the basic ones; and third, you can gradually enhance your vocabulary. Hopefully, the 800 words are a subset of the dictionary.

Adapting the RUP

The RUP is neither a dogma nor a religion. It does not define a rigid, "one-size-fits-all" recipe for software development. No, you do not need a minimum of forty people to fulfill the forty roles, and you do not need to develop more than a hundred different artifacts. You could quickly get into trouble if you were to try this. These process elements are defined in the RUP and provided in electronic form to provide the flexibility you need to adapt the process to the demands of your specific development environment.

The RUP embodies many proven software development practices. Rational has given high visibility to six of these:

● Develop iteratively.

● Model visually.

● Manage requirements.

● Control changes.

● Continuously verify quality.

● Use component-based architectures.

The RUP is also based on other key principles that are less visible and more easily forgotten. To mention only a few:

● Develop only what is necessary.

● Focus on valuable results, not on how the results are achieved.

● Minimize the production of paperwork.

● Be flexible.

● Learn from your mistakes.

● Revisit your risks regularly.

● Establish objective, measurable criteria for progress.

● Automate what is human intensive, tedious, and error prone.

● Use small, empowered teams.

● Have a plan.

A key concept in adopting and adapting the RUP is the development case. A development case is a tailored, project-specific instance of the RUP. By reference to the RUP framework, this process description defines and identifies the following:

● What will be developed.

● Which artifacts are really needed.

● Which templates should be used.

● Which artifacts already exist.

● Which roles will be needed.

● Which activities will be performed.

● Which guidelines, project standards, and tools will be used.

Producing a Development Case

The development case is usually produced by:

1. Selecting relevant elements in the RUP framework.

2. Eliminating unnecessary process elements.

3. Adding any missing company-, domain-, or technology-specific elements.

4. Tailoring some elements to the precise project context.

As the project unfolds, the development case captures some of the lessons learned by evolving itself in parallel with the software product being developed. Often guidelines or checkpoints for reviews are added to avoid repeating mistakes. The project evolves not only the software it produces, but also its own ability to develop that software.

In many cases, the development case is produced by referring to the generic RUP, but you can also create and deploy an instance of the RUP -- that is, a configuration of the RUP that is tailored to your own needs. A development case is not necessarily a big document.

If starting from a large process framework is an intimidating task, you might want to use a bottom-up approach and start with a minimal set of process elements -- the RUP essentials, which are the elements generally

found in ninety-five percent of software projects.3 The RUP essentials include:

● A vision for what you want to achieve.

● A plan.

● Some objective success criteria, such as a business case.

● A design.

● A list of risks.

● A list of defects or other kinds of change requests, and so on.

Iterative Development

Of the six best practices embraced by the RUP, the one that has the greatest impact on process agility is iterative development.

The RUP describes a versatile development lifecycle with four phases (Inception, Elaboration, Construction, and Transition), each one with specific objectives. Inside these phases, development proceeds in small iterations: Design a little, build a little, and test a little. This is a spiral process, as described by Barry Boehm.4

Building the software product incrementally allows not only for early risk mitigation, making tactical changes, and managing scope, but also for fine-tuning the process itself: that is, adjusting the development process, guidance, activities, and artifacts as you learn from previous iterations. So an initial development case is likely to evolve during the development cycle. This is done after each iteration by reflecting on what has worked, what has not worked, and how the organization and the process can be improved. Iterative development provides an ideal setting for a software process improvement process. Jim Highsmith describes an iteration as: Speculate, Collaborate, Learn.5

Iterative development requires some careful planning. The development case is only one facet of that planning, which must be done not only for the whole cycle, but also for each iteration. The project plan, revisited at each iteration, must reflect the instantiated process and explicitly define everyone's roles and activities. The mapping of roles to individuals embodied in the plan means that not everyone has to know everything about the RUP.

Process Engineering

The RUP framework achieves process agility, the capacity to adapt the development process itself, through one of its disciplines that covers the process engineering aspects. In other words, the RUP framework contains the role, activities, artifacts, guidance, and tools to evolve the RUP framework, to build a development case and evolve it throughout the project, and, if you wish, to create your own configuration of the RUP.

The role is the process engineer. The process itself and the development case are the artifacts being produced or modified.

Having an explicitly defined process rather than a vague reference to the literature and a handful of valuable principles is not an attempt to minimize the importance of people. The process does not make people replaceable pawns and does not justify employing less-qualified or less-experienced developers. A defined process also does not, by itself, make the products better along any dimension of quality.

Having a defined process:

● Allows people to communicate better, especially in larger, more distributed organizations, or across multiple organizations.

● Helps teams avoid reinventing process on the fly, arguing about the definition of what needs to be done and how, and debating about the criteria used to evaluate the quality of the result.

● Helps achieve greater consistency in the artifacts produced.

● And finally, allows the process to be used as an objective, concrete object of study and reflection in order to take the explicit step of improving it. When things are not working, having a defined process promotes objective discussion about the failures and weaknesses of the team rather than finger pointing.

In this process engineering effort, which is easier?

1. Starting from a blank slate, with a few key principles, and then building the process from the bottom up?

2. Or starting from a rich knowledge base and choosing, shrinking, modifying, and evolving existing recipes to fit the problem at hand?

With proper guidance (in the process itself) and some tool support, many organizations have found the second approach more efficient and scalable, because it allows them to benefit from the experience of many others, without excluding the integration of their own.

Agility does not always equate to "small." If your environment imposes a high-ceremony, over-the-fence approach, or requires that your organization be certified at CMM (Capability Maturity Model) Level 3,6 or demands that you deliver design documentation, agility means being able to rapidly accommodate these constraints, which is hard to do when starting from a very small process base. Waving your arms and saying that these are stupid or unfair constraints may not win you the contract.

Project, Process, Organization

The project comes first, with its constraints and environment driving your choice in the most adequate process configuration. The actual process you will use is subordinated to the needs of the project, not the other way around. Development cases can be reused from one project to another,

allowing a faster project start.

In larger organizations that have a method and tools department, an SEPG (software engineering process group), or a QA (quality assurance) department, some more ambitious process engineering can take place. Process know-how can be harvested across multiple projects and departments and then consolidated. To speed up project inception, a predefined, partly instantiated development case can be defined, containing company-specific templates and guidelines. This predefined development case is then fully instantiated by each project (or division, or department) to further tailor it to suit their needs.

The proper order is (1) project needs, which drive (2) process definition, which can be (3) supported and amplified by the organization. It is not, as we often see, first an organization-level process pushed down to the project level, which is then left to try to make the best of it on a given development cycle -- and usually ends up only paying lip service to this process that has fallen from the sky.

Toward Greater Process Agility

Creating the very first development case is often a hurdle, especially when an organization is small or newly created, and has not been exposed to much of the RUP philosophy. There are many choices to make, and as the scope of the RUP framework widens, there will be even more. Also, the process description elements in the RUP are not just standalone pieces; they are tightly integrated with many hyperlinks. So eliminating an arbitrary element is often like pulling one spaghetti noodle out of your plate when you have added too much Emmenthal cheese: It takes a lot of other noodles with it.

This is where process agility can be further improved by helping the project manager or process engineer make the right set of choices for the initial development case. There are several ways to attack this issue:

1. Predefined configurations. Provide predefined instances of the RUP framework, in which some of the choices have already been made for a given type of software development environment.

2. Componentized RUP. Organize the RUP framework to manipulate smaller chunks of process know-how: process components, for which the amount of coupling is reduced and well defined.

3. Tools for RUP configuration. Provide tool support for the construction of a RUP configuration.

4. Tools for process authoring. Provide tool support for process authoring, to allow the users to expand the RUP framework and create their own process components.

Predefined Configurations

An example of the predefined configuration is a variant RUP for Small Projects, in which many choices have been made to eliminate elements

(artifacts and the corresponding activities and roles) that are not likely to be found in small, "five-people-for-five-weeks" projects, or in projects whose artifacts have been merged or reorganized. Note that a RUP for Small Projects is indeed smaller than the generic RUP framework, but it is not a process reduced to a few high-level recommendations for beginners. This process still aims at providing full guidance on how to achieve quality results, and therefore still contains a lot of guidance. Remember also that software development is not just about programming; there are other important aspects, such as deployment, requirements management, and technical project management. Because of the wide range of factors that affect the project choices, only a few such configurations can be ready-made out of the box.

Componentized RUP

We recently reorganized the RUP framework to fully support the notion of process components, implemented in the form of process plug-ins (see Figure 1 as well as "The RUP: An Industry-wide Platform for Best Practices," in the December 2001 Rational Edge).

The framework contains a base RUP, or the very elementary process guidance that will figure in most configurations you can imagine: general definitions, concepts, and principles, as well as the definition of key best practices -- in particular, the definition of the iterative lifecycle or the use of key technology, such as the Unified Modeling Language (UML).

Figure 1: Componentized RUP: Base RUP with Process Plug-Ins

Process components can be added to this base RUP. A process component contains new process definition elements that are added to the base, but it may also redefine and specialize elements already existing in the base. For

example, the base may contain a simple project management discipline, and you might replace it with a more sophisticated project management discipline geared toward the management of a large project under government contract. Extensions are done by "dropping" a plug-in into a compatible base.

Beyond Rational Plug-Ins that provide the core software engineering guidance, very specialized Rational Plug-Ins bring know-how targeted at a given technology (e.g., J2EE), domain (e.g., real-time embedded systems, data warehousing), or tool (e.g., code generator).

The result is still a fully integrated, hyperlinked process, since each of these Rational Plug-Ins "knows" how to relate its own elements to the base. This approach is more like adding spaghetti noodles and cheese and ground pepper to a small initial serving.

Tools for RUP Configuration and Process Authoring

Additional plug-ins can be developed by process engineers using the Rational Process WorkbenchTM, a process modeling tool built on top of Rational Rose®, using UML to model the process. The practitioner -- a project manager, for example -- can configure an instance of the RUP using the RUP Builder, which allows the selection of appropriate and compatible plug-ins for a base RUP (see Figure 2).

Figure 2: Tools for RUP Configuration and Process Authoring

Toward A Process Marketplace

The concept of process components in the form of plug-ins opens the possibility of a process marketplace. Not all plug-ins have to be developed and marketed by Rational. By making available the very tools with which Rational developed the RUP, and by pushing toward a standardization of

the underlying process metamodel,7 Rational is opening up this possibility to others. The OO technology it relies on is powerful enough to allow a third party to replace parts of the RUP guidance with its own idea, further opening this marketplace.

Conclusion

Agility is the ability of an organization to adapt and react expeditiously and appropriately to changes in its environment and to demands imposed by the environment. An agile process is one that readily embraces and supports this kind of adaptability.

The Rational Unified Process contains the guidance necessary to adapt its framework to the initial project environment and to evolve it as a project unfolds. The RUP framework provides this agility by offering a wealth of process guidance to choose from, which prevents having to reinvent process and accommodates a larger scope of situations. A great part of the RUP's agility is derived from its iterative approach, which provides many feedback loops and opportunities to make ongoing tactical changes to evolve the process.

By introducing the concept of a base RUP that can be augmented and enhanced with process components and plug-ins and making available the tools to develop them, Rational provides greater flexibility in tailoring the RUP and opens a potential process marketplace.

References

Barry W. Boehm, "A Spiral Model of Software Development and Enhancement." IEEE Computer, Vol. 21, No. 5 (May 1988), pp. 61-72.

Tom Gilb, Principles of Software Engineering Management. Addison-Wesley, 1988.

James Highsmith, Adaptive Software Development. Dorset House, 2000.

Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. Addison-Wesley, 2000.

Object Management Group (OMG), Software Process Engineering Metamodel (SPEM), doc ad/01-03-08, 2 April 2001 (http://cgi.omg.org/cgi-bin/doc?ad/01-03-08).

Leslee Probasco, "Ten Essentials of RUP." The Rational Edge, December 2000 (http://www.therationaledge.com/content/dec_00/f_rup.html).

Rational Unified Process, version 2001. Rational Software, 2001.

Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley, 1999.

Note: This article appeared as Philippe Kruchten, "Agility with the RUP."

Cutter IT Journal, Vol. 14, No.12, December 2001, pp. 27-33.

Notes

1 See Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed., Addison-Wesley, 2000 and Rational Unified Process, version 2001.2 Object Management Group (OMG), Software Process Engineering Metamodel (SPEM), doc ad/01-03-08, 2 April 2001 (http://cgi.omg.org/cgi-bin/doc?ad/01-03-08).3 See Leslee Probasco, "Ten Essentials of RUP." The Rational Edge, December 2000 (http://www.therationaledge.com/content/dec_00/f_rup.html).4 Barry W. Boehm, "A Spiral Model of Software Development and Enhancement." IEEE Computer, Vol. 21, No. 5 (May 1988), pp. 61-72.5 James Highsmith, Adaptive Software Development. Dorset House, 2000.6 See http://www.sei.cmu.edu/cmm/cmm.html7 Object Management Group (OMG), Op.Cit.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Promises, Promises

by Karl Wiegers

Principal Consultant Process Impact

"What do you mean, you need five months to get the next release out? It can't possibly take that long. We promised it to marketing in three months. If you were really committed to this project, you'd get it done by then."

Sound familiar? Unfortunately, too many software projects are launched with the expectation that productivity magic will happen. Sometimes an ordinary team does get lucky, or an exceptionally talented and hardworking team pulls off a miracle. More often, though, miracles don't happen, leaving managers, customers, and developers frustrated and looking for scapegoats. Successful projects are based on realistic commitments, not on fantasies and empty promises. This article discusses several ways to improve your ability to make -- and keep -- achievable project commitments.

Making Project Commitments

A commitment is a promise that one party makes to another,1 and a software development project involves multiple commitments among business managers, customers, development managers, and individual developers. To be effective, these commitments must meet two basic conditions:

● We must make them freely. More powerful people can pressure us to say yes, but most of us are unlikely to take seriously an impossible commitment that is imposed upon us. Although some people will pretend to make a commitment they don't intend to fulfill in order to bring an unpleasant conversation to a close, such behavior undermines the commitment ethic.

● They must be clearly understood by all parties involved and explicitly made. Software development projects often have at least one formal, written commitment: a legally binding contract. Requirements that are agreed upon by all parties and allocated to a specific product release constitute another formal commitment. It is also helpful for managers to write a brief summary of each informal commitment that they exchange verbally with a team member. This both confirms their communication and establishes a shared expectation of accountability.

On software projects, even if you meet the two basic conditions for effective commitments, it's easy to make unrealistic promises. First, we developers are optimistic about our own talents and overestimate our personal productivity. We assume that we have forty or more hours of productive project time available each week, although the reality is perhaps only fifty or sixty percent of that.

Second, managers and customers who don't understand software development pressure us to give perfect estimates and meet their aggressive business expectations with little regard for the uncertainties we face. Often, we get incomplete or misleading information about the problem we're being asked to solve, limiting our ability to make meaningful estimates and commitments.

Finally, software requirements are volatile; for both technical and business reasons, they may change with each project iteration. We must have the freedom to renegotiate unrealistic commitments that turn out to be based on inaccurate information or premises that have changed.

Negotiating Commitments

Software developers often are asked to produce high-quality results in an unrealistic time frame. Negotiations are in order whenever there's a gap between the schedule or functionality that project stakeholders demand and your best estimate of what it will take to meet those demands. Whether you're discussing formal requirements or more informal task assignments, you can engage in good-faith negotiations with customers and managers about what constitutes achievable commitments. Principled negotiation, a method to strive for mutually acceptable agreements, involves four basic points:2

● Separate the people from the problem.

● Focus on interests, not positions.

● Invent options for mutual gain.

● Insist on using objective criteria.

Separate the People from the Problem. Negotiation is difficult when emotions get in the way. It's also hard to negotiate with individuals who wield more organizational power than you do. Before you dismiss a manager or customer as a slave driver who makes impossible demands, recognize his legitimate concerns and objectives, including commitments

others might have made that put him in a bind.

Focus on Interests, Not Positions. A product marketing manager who establishes a strong position in a negotiation ("This product absolutely must ship by October 15th") can find it difficult to make a change in that position. If you, the software team leader, define an opposing but equally entrenched position ("We can't possibly be done before January"), conflict is inevitable. Rather than reaching an impasse by defending your terrain, seek to understand the interests that underlie each party's stated position.

Perhaps marketing's real interest in this case is to have a demo version available for exhibiting at COMDEX. Your interest might be to avoid putting in massive amounts of unpaid overtime for three months. Maybe you can agree on a core set of features and reliability targets that would both satisfy marketing's primary interest and be achievable by the convention deadline. Delivery of the completed product could then be deferred to a more reasonable date.

Invent Options for Mutual Gain. Negotiation is the way to close the gap between polarized positions. Begin with a win-win objective in mind, and look for creative ways to satisfy each party's interests. Think of feasible outcomes to which you are willing to commit and present those as options.

If you can't commit to fully satisfying the demands someone is placing on you, then tell him what you are able to deliver. Could you make a more ambitious commitment if certain conditions were met, such as shedding your maintenance responsibilities on existing applications? If you're being pressured to work a lot of overtime to get the job done, will your employer grant you additional vacation time afterward?

Insist on Using Objective Criteria. Negotiations based on data and analysis are more constructive than those based on emotion. Data from previous projects and estimates based on a rational planning process will help you negotiate with someone who insists that his grandmother could finish the project in half the time you have proposed.

Once basic project requirements are set, one approach to making commitments is to have team members "sign up" for specific task responsibilities.3 Such voluntary, personal commitments, based on each person's internal vision and evaluation of what it will take to accomplish a goal, will motivate them to make the project succeed. A manager cannot impose this level of enthusiasm and commitment upon others.

Keep in mind that an estimate is not necessarily a promise. Some teams define target delivery dates that are more optimistic than their committed delivery dates, to compensate for imperfect estimates and accommodate unforeseen eventualities. In fact, a common reason for overcommitment is making "best case" commitments rather than "expected case" commitments; this happens when you forget that unforeseen obstacles often interrupt project plans.

Improve your ability to meet commitments by making more accurate estimates. Base your estimates on data of actual performance you collected from previous activities. Use planning checklists that identify all

the activities you might have to perform for common large tasks to avoid overlooking necessary work. Contingency buffers and built-in slack time can provide protection against estimation errors, erroneous assumptions, potential risks that materialize, and scope growth. Your committed delivery dates might be farther out than your managers or customers would like, but if you consistently meet the deadlines you set, then other people will know they can count on you.

Commitment Analysis Checklist

Before you make a commitment, use this checklist to analyze whether you are really in a position to say "Yes."

Commitment Criteria

All parties fully understand what is being committed to.

I have examined my assumptions as well as any external dependencies that will affect my ability to fulfill the commitment.

I have identified circumstances that could prevent me from keeping my commitment.

Likelihood that these circumstances will occur:

Not very likely Somewhat likely Very likely

I have determined that the commitment is realistic and achievable, based on what I know today.

I have documented the commitment, along with important assumptions and dependencies.

I have pledged to notify the other parties if anything affects my ability to deliver on the commitment.

Modifying Commitments

As we have noted, many projects involve formal agreements to implement a specific set of requirements by a particular date. Such commitments can fall by the wayside if the requirements turn out to be technically unfeasible or especially challenging, if they change, or if the stated requirements were just the tip of the real requirements iceberg. The essence of requirements management is to respond to changes promptly and appropriately. That means project stakeholders must alter their expectations and commitments in the face of evolving information.

An effective approach is to get the project sponsor to commit a certain amount of resources to the project and then monitor progress as the work unfolds. Inevitably, project realities (such as resources, technologies, budgets, or deadlines) will change, problems will arise, risks will materialize, or new functionality will be added. If it appears that some targeted deliverables will not get completed before the committed resources are exhausted, then all project stakeholders should collaborate on a decision: Should we postpone selected deliverables or expand the budget to complete the work? This incremental approach acknowledges the fallibility of software estimates while still offering a way to control costs.

If it becomes apparent that you won't be able to meet a commitment, it's important to notify all stakeholders in a timely way. Why pretend you're on schedule until it's too late to make adjustments? Ultimately, you'll disappoint everyone, including yourself. Instead, letting someone know early on that you won't be able to fulfill a commitment builds credibility

and respect for your integrity, even if the stakeholders aren't happy that the promise won't be kept.

Customer requests for modifications late in the process are often an occasion for renegotiation. Obviously, if your customer demands six new features for the next release late in the development cycle, then they can't expect to get the product by the original deadline. Here are some options you might explore:

● Can some of the lower-priority requirements wait for a later release?

● Can delivery be delayed?

● Can more development resources be channeled into this project?

● Will the customer pay extra to bring expensive consultants on board to implement the new features?

● Can you relax the product's quality goals in an attempt to save time, yet still meet the project's strategic business objectives?

It's also important to remember that rigid adherence to impossible or obsolete commitments can lead to serious problems. On one project I recall, the lead developer promised year-end delivery of a mission-critical application that was to replace two legacy systems. He steadfastly maintained that his team could get the job done without additional resources, but the year drew to a close without a delivery. The next year, his manager brought more team members on board, and the project made some progress. Again, the lead developer promised delivery by the end of that year but he still missed the deadline. Unwilling to admit that he couldn't achieve his commitment, he kept all the challenges he was facing to himself because he wanted to "save face."

In fact, his stubbornness had the opposite effect. His development team lost credibility with both customers and managers, and technology changes over the long course of the project rendered the new application largely irrelevant. Ultimately, when the system was finally delivered, it was nearly dead on arrival, and all stakeholders were profoundly disappointed. A more responsible leader would have estimated realistically and called for renegotiation of resources and deadlines. And when it became clear that pursuing the initial requirements amounted to throwing good money after bad, the lead should have given stakeholders the option to redirect or cancel the project.

Declining to Make Commitments

In failing to disclose vital information to stakeholders and to modify and renegotiate his commitments, the development team leader in our example violated some basic principles of professional integrity. Many well-intentioned people do likewise by accepting too many commitments. I once managed a capable and dedicated developer who always said yes whenever I asked her to take on a new responsibility. I soon learned, however, that she often didn't deliver on deadline. Her in-basket was overflowing, and there was simply no way she could complete everything

to which she had agreed.

Accepting more responsibilities that you can fulfill makes you appear to be unresponsive and makes others skeptical about the promises you make. A meaningful commitment ethic includes the ability to say "No."4 Here are some other ways to say "no" that might sound a little more palatable:

● "Sure, I can do that by Friday. What would you like me to not do instead?"

● "We can't get that feature into this release and still ship on schedule. Can it wait until the next release?"

● "That sounds like something I can do, but I'm afraid it's not as high on the priority list as my other obligations. Let me suggest someone else who might be able to help you more quickly than I can."

A track record of making realistic performance estimates and satisfying your commitments buys credibility that improves your future ability to negotiate problematic schedules or other commitments when there is an unexpected event or breakdown elsewhere in the commitment chain. Before you say, "Sure, no problem" to a request, use the Commitment Analysis Checklist in the Sidebar to think through carefully whether you should make the commitment.

Despite occasional pressure to promise the impossible, I practice a personal philosophy never to make a commitment that I know I cannot keep. Keeping that resolve is both part of being a professional and a way to be recognized as someone who can be relied upon. Once, when I was discussing plans with my department's aggressive and intimidating senior manager, he began pressuring me to agree to a timetable that my group had concluded was not remotely feasible. When I resisted, he grudgingly moved his objective out several months, but even that goal was pure fantasy. Finally I said point blank, "Fred, I'm not going to commit to that date." He was taken aback. I don't think anyone had ever before refused to make a commitment that Fred was pressing.

It would be unprofessional to commit to an objective that I knew was unattainable, I explained, adding that "We're not going to work any less energetically toward the objective if we have more time to do it, and our morale will be higher if we're not set up for certain failure." Reluctantly, he agreed to a reasonable target date, and he didn't try to pressure me that way again.

It's Your Call

The commitments you take seriously are those you make freely, when you are not under duress -- those you believe you can fulfill. Negotiate to make interpersonal and intergroup commitments explicit and realistic, and renegotiate if changes in circumstances won't allow you to keep them.

As a manager, don't pressure your team members to commit to requirements or delivery dates they don't feel are realistic. If you fear

someone is getting in over his head, discuss the commitment details, his assumptions, the risks of failing to meet the commitment, and other obligations that could get in the way. Stay on top of the promises you and your team members make to others by recording and tracking requirements and delivery dates, and also track the promises others make to you. Create an environment in which people can turn to you for help with negotiation and adjusting priorities. Unfulfilled promises ultimately lead to unhappy people and projects that never reach completion, so strive to build a strong commitment ethic in your team.

Notes

1 Watts Humphrey. Managing Technical People: Innovation, Teamwork, and the Software Process. Addison-Wesley, 1997.2 Roger Fisher, William Ury, and Bruce Patton. Getting to Yes: Negotiating Agreement Without Giving In, 2nd Edition. Penguin Books, 1991.3 Steve McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996.4 Naomi Karten. Managing Expectations: Working with People Who Want More, Better, Faster, Sooner, NOW! Dorset House Publishing, 1994.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Introducing the RUP into an Organization

by DJ DeVilliersProcess Consultant

When an organization is considering a new process or tool introduction, there are a number of issues to consider: Which combination of process and tools is best? What is the most suitable implementation approach? Is the organization fully committed to the success of this project? What is the organization's capacity for change? This article examines these issues based on personal experience with introducing the Rational Unified Process® (RUP®) and Rational Suite® in both small and large organizations.1

Implementation Approaches

An organization may take any one of several approaches to implement the RUP, depending on the project situation:

● Typical approach

● Distributed approach

● Fast approach

● Careful approach

● Organizational development environment approach

We will discuss each one below. Please refer to the Sidebar for definitions of terms.

Typical Approach

In the typical approach, the process and tools are first introduced through a three-to-four-month pilot project consisting of ten to fifteen people. Before

the project starts, the RUP is configured in a project-specific Development Case, and tools are selected. After the pilot project, the Organizational Development Environment (ODE) is prepared. During this stage, the new process and tools are evaluated by the Software Engineering Process Authority (SEPA).2 The Development Case and Guidelines developed during the pilot project are refined for the organization, and the pilot project team members prepare to serve as mentors for other projects (see Figure 1).

Figure 1: Typical Approach for Implementation

As its name implies, this is the most commonly used approach. It has its plusses and minuses (see Table 1), but it is especially applicable when the organization is skeptical about process change. Since there is a risk that the delivery date of the pilot project may be delayed, it is wise to select an urgent project for the pilot, keeping in mind the potential effects of a possible delay.

Table 1: Typical Approach Advantages and Disadvantages

Typical Approach

Advantages Disadvantages

● Rapid application of process and tools.

● Process can be fine-tuned.

● Projects can be mentored by the pilot team.

● Guidelines are based on actual experience.

● Process is initially scoped to one project.

● Pilot project delivery may be delayed.

● Difficult to maintain momentum.3

Distributed Approach

In the distributed approach, multiple pilot projects are targeted for the initial introduction of process and tools (see Figure 2). Because a larger "surface" of the organization is involved, process and tools can be applied to different domains or environments. The environment preparation phase will take longer because multiple evaluations, Development Cases, and Guidelines need to be harmonized. As in the typical approach, pilot project team members are used as mentors on future projects, and because more mentors are available, more projects can be started.

Figure 2: Distributed Approach for Implementation

This approach is applicable when the organization wishes to test process and tools under different scenarios (for example, mainframe versus Java skills or in-house versus contractual projects). Due to the increased effort and complexity, this approach is more expensive than the typical approach (see Table 2).

Table 2: Distributed Approach Advantages and Disadvantages

Distributed Approach

Advantages Disadvantages

● Process can be applied to different domains.

● More mentors available after pilots.

● Reduced individual project complexity.

● Risk of failure spread among projects.

● More mentoring effort up front.

● Environment stage takes longer.

● Might have to resolve process conflicts.

● More management complexity initially.

● Difficult to maintain momentum.

Fast Approach

In the fast approach, process and tools are introduced into projects without first verifying their effectiveness or building up experience with them (see Figure 3). It's important to relay the experiences of these projects to the SEPA in order to prevent the "ivory tower" syndrome.4 This approach carries a greater risk of failure because the organization does not have time to make mistakes, correct them, and then adapt to the changes.

Figure 3: Fast Approach for Implementation

This approach is effective when the current process is very similar to the RUP or the organization is already using some of the tools, which lowers the learning curve. This approach is also appropriate when the problems are so great that any change will be considered an improvement. (See Table 3.)

Table 3: Fast Approach Advantages and Disadvantages

Fast Approach

Advantages Disadvantages

● Projects can be started up very quickly.

● Learning curve is small if already using a similar process or tools.

● Process and tools are unproven within the organization.

● Risk of "ivory tower" syndrome.

● Tends to produce an unwieldy process.

Careful Approach

In this approach, the Development Case created by the initial pilot project is successively refined in multiple, sequential pilot projects (see Figure 4). Tools can be introduced incrementally in each project. Use of the new process and tools then spreads like an oil spill, as smaller projects enjoy progressively larger successes. The final preparation of the environment will be shorter, because the Development Case and Guidelines will not require much refinement. When using this approach, it is very important to ensure small successes rapidly (quick wins) in order to prove value and progress. Otherwise, the organization may lose sight of the goal, and the transition may eventually fail.

Figure 4: Careful Approach for Implementation

The careful approach is usually applicable when the organization's capacity for change is low or there are many changes to be made. In these cases, it is necessary to carefully plan and execute change in small increments. (See Table 4.)

Table 4: Careful Approach Advantages and Disadvantages

Careful Approach

Advantages Disadvantages

● Shorter environment development stage.

● Development Case is successively refined.

● Organization has time to adapt to change.

● Reduced complexity on individual projects.

● Greatest probability of success (if quick wins are achieved).

● Projects start up later.

● Process is scoped to one domain/approach.

● Can take too long to prove ROI.

● Difficult to maintain momentum.

Organizational Development Environment Approach

Organizations that are setting up an organizational development environment can run that project in parallel with the pilot project(s) described in the other approaches. Usually, this approach is combined with the typical approach, as shown in Figure 5. The SEPA's role is to coach and support the pilot project, while the pilot project provides feedback to the SEPA about the application of process and tools.

Figure 5: Organizational Development Environment Approach for Implementation

This approach can be used to relieve pressure on the pilot project, or when there is no development organization already in place. Combining this approach with multiple pilot projects significantly increases the managerial complexity of the project. (See Table 5.)

Table 5: Organizational Development Environment Approach Advantages and Disadvantages

Organizational Development Environment Approach

Advantages Disadvantages

● Pilot can be mentored by SEPA.

● Shorter environment stage.

● Easier to maintain momentum.

● Pilot feedback can be processed and disseminated directly.

● Pilot project has more overhead.

● Risk of "ivory tower" syndrome.

● More management complexity.

The Pilot Project

The goal of a pilot project is not only to deliver a product, but also to apply new process, technology, or tools. Important requirements include:

● Manageable Technical Risk. A pilot project should not involve too much technical risk, although risk is difficult to avoid when you are introducing a combination of new process, tools, and technology.

● High Priority. The project should have a high enough priority to ensure necessary management commitment and sufficient resources. A mission-critical project would certainly meet this criterion but also carry a high cost of failure (financial risk).

● Committed Resources. Many pilot projects fail when their resources are reassigned to other projects or their budgets are cut. Managers should commit sufficient resources for the duration of the project.

● Realistic Schedule. The project schedule must not be so constrained that the team must forgo the adoption of process and tools in order to meet it. Usually, the project manager is given some extra time to complete the project (ten to twenty-five percent of the original schedule).

If the pilot project has been started before a process introduction, it is important to position the project within the applicable RUP lifecycle phase. If the project is in Inception or early Elaboration, there is usually enough time to introduce process and tools without jeopardizing the delivery date. Waiting to introduce a new process or new tools at a later stage will destabilize the project, as the project team's focus will shift to accommodating the changes. This may lead to delayed delivery of the project, and in some cases could even lead to project termination if the team becomes swamped in complexity. A neat project startup provides the opportunity to set realistic expectations, ensure user availability, and form the project team. If the project has already been started, then these issues need to be addressed immediately.

Generally, process and tools are introduced during Inception and

Elaboration, as shown by the focus areas in Table 6. Inception focuses mostly on requirements management and project management. The goal of Inception in a pilot project is to get buy-in from the sponsors (of the organizational change rather than the product). In Elaboration, focus shifts to design and configuration and change management. Testing tools are introduced in Elaboration but will not be used widely until later. The major goal of Elaboration in a pilot project is to eliminate the risks associated with the new process and tools. During Construction, no new tools are introduced, and the project team focuses on developing the product and improving productivity. Stability, efficiency, and the product are the goals of Construction in the pilot project. During Transition, the team collaborates more with the SEPA, and focus shifts to evaluating the usage of process and tools in the project.

Table 6: Focus and Goals for the RUP Lifecycle Phases

Training and Mentoring

Training is a key to success, and all project team members should complete the RUP Fundamentals (two-day) training before the start of the project. Further training may be required on specific disciplines, depending on the team's skills and experience. For example, the designers may require UML training, or the users may require training in use cases and requirements management. If in-depth training focuses on the same domain as the pilot project, then the project team can prepare by working on a mini-project similar to the pilot, without fear of failure or wasting time. An important by-product of training is team building, which can occur only if the team is trained together.

Tool-specific training takes place just before the tool is to be used. In a project environment, this tool training is usually done in a workshop; it covers only functionality that is relevant to the project and focuses on the project artifacts.

Mentoring is necessary when introducing new technology or techniques to a project team. During a typical course the examples merely illustrate the application of theoretical concepts. Afterward, most people struggle to apply these new concepts directly to real-world problems. A mentor can discuss their questions and doubts, guide them toward answers, and review artifacts. Although mentoring cannot fully replace in-depth training, it is an effective way of balancing learning with practical experience without compromising quality or deadlines.

Implementation Plan

Introducing the RUP into an organization involves the following sequence of activities (see Figure 6):

1. Set goals and expectations.

2. Plan your delivery.

3. Instantiate the RUP.5

4. Train the project team.

5. Mentor the project team.

6. Evaluate progress.

These activities are discussed below. They may also be performed in iterations, as described by Philippe Kruchten7.

Figure 6: Introducing the RUP into an Organization

Activity 1: Set Goals and Expectations

Goal: Determine the scope and goals of the new process and tools introduction, and set the expectations of key stakeholders and the Rational team.

The Vision7 produced by this activity will be used as the measure during Activity 6: Evaluate progress. Goal setting is performed in a meeting between the sponsors and the Rational TEM (see Sidebar), who should agree upon the following:

● Business drivers for change (including stakeholders)

● Scope (organization or project level; which process and tools)

● Responsibility assignment (including driving the organizational change)

● Implementation approach (typical, distributed, careful, and so on)

● Priority of improvement areas8

● Project organization

● Pilot project(s)

● Commitment by both parties

● Training requirements

Activity 1 Summary: Set Goals and Expectations

Duration One day

Result Vision, including the items and activities9 that need to be scheduled during Activity 2: Plan Your Delivery.

Activity 2: Plan Your Delivery

Goal: Establish a delivery schedule that satisfies dependencies between the items and activities defined in Activity 1: Set Goals and Expectations, and available resources.

This is accomplished in a meeting between the Rational TEM and the Project Manager. Required tasks are:

● Identify key stakeholders.

● Schedule installation.

● Schedule training.

● Schedule mentoring.

Activity 2 Summary: Plan Your Delivery

Duration One day

Result A delivery schedule, describing which items and activities occur when, where they will take place, who should attend, and expected costs.

Activity 3: Instantiate the RUP

Goal: Produce a project-specific or organization-specific Development Case.

Exact timing of the steps in this activity depends on the selected implementation approach. This activity is typically carried out in parallel with others and consists of the following steps:

1. Train key stakeholders. The organization obtains a clear understanding of the RUP. Key stakeholders attend the RUP Fundamentals training (two days), and the Process Engineer attends the Implementing RUP training (two days).

2. Assess the organization. Assess the software development organization in terms of its current process, tools, roles, competencies, attitudes, market, technical trends, problems, and improvement areas. This assessment is performed by the Process Engineer(s) under the guidance of a Rational Software Engineering Specialist. The scope of the assessment depends on the chosen implementation approach and schedule pressure. This step might be initiated earlier to help set goals and expectations (see Activity 1: Set Goals and Expectations above).

3. Write the Development Case. The project-specific (or organization-specific) configuration of the RUP is captured in a Development Case. This artifact describes the combination of roles, artifacts, activities, and level of ceremony and formality to be used by the project (or organization). It is in the form of either a Word document or an HTML shell provided by the RUP.

Activity 3 Summary: Instantiate the RUP

Duration Two to ten days

Result Development Case (Word document or HTML shell).

Activity 4: Train the Project Team

Goal: Train the project team on both the standard RUP and the project-specific (or organization-specific) customizations defined in the Development Case (see Activity 3: Instantiate the RUP).

The team attends the RUP Fundamentals training (two days) and a kick-off session in which the Development Case is presented.10

Activity 4 Summary: Train the Project Team

Duration Two days for RUP Fundamentals trainingHalf day for the kick-off session

Result Staff is prepared to use the RUP and familiar with the Development Case.

Activity 5: Mentor the Project Team

Goal: Mentor the pilot project team regarding the use of the standard RUP and the specifics of the Development Case.

The mentoring is performed by a Rational Software Engineering Specialist, who answers questions, participates in and steers discussions, and reviews artifacts produced by the project team. If the organization also wishes to set up an ODE, the Process Engineer receives mentoring if necessary.

Activity 5 Summary: Mentor the Project Team

Duration Depends on the size of the project, number of pilots, implementation approach, and competencies. Typically one day per week for the first four to six weeks, less thereafter.

Result The project team is able to apply the new process and tools independently. It is often difficult to quantify success for this activity. Generally, the Rational TEM determines when to reduce the frequency of mentoring, based on his/her confidence that the team has reached self-sufficiency.

Activity 6: Evaluate Progress

Goal: Conduct an assessment of progress made by the project team (or organization) in adopting the RUP and determine next steps for further deployment of process and tools.

The evaluation is performed by a Rational Software Engineering Specialist(s), usually by interviewing key stakeholders. The next steps are based on the evaluation report and are determined during a discussion between the Rational TEM and the sponsors.

Activity 6 Summary: Evaluate Progress

Duration One to two days for interviews plus one day for the reportHalf day for the discussion

Result A follow-up assessment report is delivered to key stakeholders.

RUP Talk

Here is some of the terminology you'll encounter if you decide to implement the RUP.

Account Manager: The Rational employee who is commercially responsible for a given Rational Software customer.

Development Case: A document or Web site describing the particular RUP customizations to be used by a customer project or organization.

Guidelines: Documents produced before a project begins that capture decisions regarding existing standards or strategies. Guidelines are typically updated during the project, based on the team's experiences. Examples:

Success and Failure Factors

Based on our experience, we have compiled lists of the top reasons for both success and failure when instituting a new process and tools in an organization. Organizational change cannot be forcibly imposed; its introduction must be managed. How the change will be effected depends on many factors, such as skills, attitudes and motivation, existing process and tools, and organizational structure and culture. These process discriminants11 will determine the particular configuration of the RUP to be used by the project or organization as well as the most suitable implementation approach.

Top Reasons for Failure

Use Case Modeling Guidelines and Design Guidelines.

Organizational Development Environment (ODE): Organizational standards regarding process, tools, and techniques that all projects should use consistently.

Pilot Project: A "proof of concept" project for new process and tools. Organizations typically run pilot projects before full deployment in order to minimize the risk of failure.

Process Engineer: The person (or group) responsible for configuring the RUP by writing and maintaining the Development Case. The Process Engineer works closely with the Software Engineering Process Authority but does not necessarily belong to it.

Project Manager: The person (or group) responsible for planning, staffing, and monitoring the project implementation. The "project" could be either the pilot project or the full project to set up an Organizational Development Environment.

Rational Unified Process (RUP): An iterative, architecture-centric software engineering process developed by Rational Software. RUP is a Web-based description of roles, artifacts, and activities that enable the application of software engineering best practices.

Software Engineering Process Authority (SEPA):12 The person or group who owns the process and is responsible for providing process guidance and support to projects. A more formal SEPA, such as a staff department, would define process standards and perform project reviews.

1. Failure to introduce process and tools incrementally. A big-bang introduction forces change onto people and can destabilize the project if resistance is too great. People can lose motivation, which hampers them from dealing effectively with the complexity of having to learn and apply everything at once. Typically, someone eventually decides to rectify the situation, most often by reversing the original decision rather than reassessing the situation and determining the best way out.

2. Lack of management support. It is a well-known fact that organizational change has to be effected at all levels in an organization, starting with management. The pilot project should have visibility at the management level, and part of the organization's commitment to success is a management team that is willing to participate in implementing new process and tools.

3. Lack of buy-in from sponsors and stakeholders. When sponsors or stakeholders are not aware that progress is being made, they tend to become less motivated about a project. Having agents of change at all levels of the organization is important, and these people must be kept informed and involved. Be especially mindful of this when using the Careful Approach described above.

4. Unwillingness/incapacity for organizational change. When the organization is not committed to success, or it has chosen the wrong implementation approach, people lose motivation. If the organizational change is not managed well, or political forces become more important than the

Software Engineering Specialist: The Rational consultant with expertise in a particular field of software engineering. These consultants typically provide training and coaching as needed, determined by the Technical Engagement Manager.

Technical Engagement Manager (TEM): The Rational employee technically responsible for the successful implementation of the RUP and Rational Suite within a customer organization.

process and tools, then the project has very little chance of success. This usually goes hand-in-hand with lack of management support; management provides a poor example for the team.

5. Vision and change drivers are unclear. When the business drivers behind the change are not clear, it is difficult to convince people of the value of steps that must be taken to effect that change. People must know why the organization must change (drivers) and where the change is leading (vision) in order to build a strong foundation for the implementation.

Strategies for Success

1. Assess the project and the organization. Assess the organization to prioritize improvements and determine the best implementation approach. Assess the project to understand its unique characteristics and drivers so that the process is applied in the most beneficial and effective manner.

2. Implement process and tools incrementally. Take small steps, making a few improvements at a time, and book successes (quick wins) before starting on the next improvements. In this way, the project team will not become overwhelmed, and sponsors can be convinced that you are making progress. Do an organizational assessment to determine which improvements to tackle first. Be sure to steer each step toward the vision; stepping in a random direction is no better than not stepping at all.

3. Manage and plan. Environment activities should be managed and planned along with software engineering activities (Environment is one of the RUP disciplines). Often, project managers overlook environment activities, regarding them as secondary or overhead. In reality, these activities are just as complex and crucial as requirements analysis, design, or testing. Process management is as essential a part of any project as project management.

4. Use mentors. Mentors act as agents of change at the project level. Even with extensive training, people tend to fall back to their familiar way of working after some time. Mentoring is especially crucial in the first weeks of the project, until the team is accustomed to the new way of working.

5. Distribute process ownership. The people using the process are the "real experts." Their experiences and feedback should be captured and shared. Not following this advice may lead to the "ivory tower" syndrome; that is, there may be a clear, sometimes hostile,

divide between the process academics and those who actually apply the process.

6. Be pragmatic. Don't make the process too heavyweight. Too much documentation and ceremony can swamp a project. Use the most appropriate form for an artifact; even a rough sketch on a whiteboard can be an artifact. A Development Case should not be a completely rewritten process, but should contain only deviations from the standard RUP. Finally, keep in mind that you cannot always do things right the first time, so it is better to just do it than get stuck trying to do it perfectly.

7. Communicate. People don't like change, but by showing them proof of progress and setting realistic expectations, you can convince them that the change is a good thing. Identify key people (agents of change) at all levels in the organization, and be sure to keep them and the stakeholders informed and involved.

8. Train people. Training can be an especially effective tool for managing organizational change. Training on tools and techniques can be done through courses, workshops, boot camps,13 and kick-starts14. It is very important to mentor the application of the tools and techniques after training to ensure effective usage.

Conclusion

In this article, we have seen what needs to be taken into account when introducing new process and tools into an organization. A suitable implementation approach should be chosen based on how many resources and how much time are available for implementation. In the typical approach, a pilot project precedes broader deployment. Multiple pilot projects may be implemented, either sequentially or in parallel, to apply the process and tools in a broader context.

The implementation plan involves identifying and meeting with stakeholders to set the goals and expectations for the implementation; scheduling installation, training, and mentoring; configuring the RUP based on project-specific or organization-specific process discriminants; training and mentoring the pilot project team; and performing a follow-up evaluation.

Factors that often lead to failure include trying to change everything at once, lack of management support, and not keeping stakeholders informed. Ways of ensuring success are to employ pragmatism, common process ownership, training and mentoring, and effective communication.

The duration and effort estimates in this article reflect a typical project and organization. Use them as guidelines for planning your own implementation, but be sure to monitor progress and adjust your plan as necessary.

A final message: If you let people know that you enjoy what you are doing, then they will want to participate!

Acknowledgments

I would like to thank Gary Pollice, John Smith, Cindy VanEpps, Eric Lopes Cardozo, Catherine Southwood, and Marlene Ellin for their patience and help with this article.

References

1. Alistair Cockburn, Surviving Object-Oriented Projects: A Manager's Guide. Addison-Wesley, 1997.

2. Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. Addison- Wesley, 2000.

3. Walker Royce, Software Project Management, A Unified Framework. Addison-Wesley, 1998.

Notes

1 Note that the average figures in this article are based on experiences with large financial organizations. Smaller companies, or companies doing contractual software development, may have slightly different average figures.2 If there is not yet a formal SEPA, then a representative group can fulfill this role.3 This point warrants further explanation. Many pilot projects conclude and leave the organization asking, "So what's next?" At this point, it can be very difficult to involve other parts of the organization in the environment. Instead, the environment stage should be planned by all involved parties during the pilot. This ensures that the momentum built up during the pilot will be maintained; otherwise, the environment stage may take months to get up to speed.4 The "ivory tower" syndrome can occur when the group that defines standards and guidelines is detached from projects. It leads to excessive documentation that is not practically applicable to projects.5 Note: This activity is typically carried out in parallel with the other activities.6 The Rational Unified Process: An Introduction, 2nd ed., pg. 253.7 This is a document containing a description of the problem, the boundary conditions of the solution, and a list of what will be done to solve the problem. The purpose of the Vision is to achieve concurrence among the stakeholders.8 These are categories of improvements such as requirements, communication, or project planning.9 Examples of such items and activities are meetings, courses, workshops, reviews, and presentations.10 Depending on the selected implementation approach, the project team may actually create the Development Case during this workshop. In this case, the Write Development Case activity in Activity 3 would instead occur during Activity 4.11 For an in-depth description of process discriminants and their effect on process, see Software Project Management by Walker Royce, pg. 209.12 Also known as Software Engineering Process Group.13 A short period of intensive training followed by an evaluation.14 A way to combine training, team building, and a project kick-off by taking the team to a remote location for a few days, away from the office. These few days are spent learning, working, and having some fun.

For more information on the products or services discussed in this

article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Book Review

XSLT by Doug Tidwell

O'Reilly & Associates, 2001

ISBN: 0-596-00053-7Cover Price: US$39.95(473 Pages)

XSL, XSLT, XPointer, XPath, XQL, XHTML: Even if you're an XML developer, unless you make a point of staying up to date with the XML technology community, all these "X" words are apt to make your head spin! But once you recover from that initial sense of being overwhelmed, it's important to realize the potential increases in efficiency and productivity you can achieve by applying the technologies these "X" words represent -- and Extensible Stylesheet Transformations (XSLT) should be high on your list.

XSLT by Doug Tidwell presents this technology in a series of tutorials that cover beginning to advanced techniques. Even for the courageous reader, I would advise gaining some knowledge of XML before diving into XSLT, but Tidwell does include a brief introduction to XML in the first chapter. He explains that, because XSLT is not your typical procedural language, XSLT templates sometimes require "clever" maneuvers to get the results you want from them. In other words, it would be difficult to functionally map the language elements of XSLT to the language elements of a procedural language such as VB, Java, or C++. Tidwell demonstrates how to use recursion in an XSLT stylesheet to emulate a string replace function, for example.

Reading about these style differences in XSLT got me thinking about past projects and how I might rewrite them now. Would XSLT have made dealing with XML any easier? One simple XML project, for example, involved formatting an XML news feed as HTML for the Web. Let's say you have an XML document like the following:

<?xml version="1.0"?><articleList numArticles="10"> <article> <title>Some title here</title> <url>http://www.some_url.com/article1000.html</url> <source>Some publisher here</source>

</article> <article> <title>Another title here</title> <url>http://www.some_url.com/article1001.html</url> <source>Some publisher here</source> </article>…</articleList>

Using a procedural language, a series of loops, and some sort of XML parsing module, the project is doable. A bit of a hack maybe, but still doable. With XSLT, on the other hand, you could format the articles into HTML with a stylesheet as concise as the following:

<xsl:output method="html" indent="no">

<xsl:template match="/"> <xsl:for-each select="/articleList/article">

<xsl:text>Article Title: </xsl:text><xsl:value-of select="title"> <xsl:text>URL: </xsl:text><xsl:value-of select="url"> <xsl:text>Source: </xsl:text><xsl:value-of select="source">

</xsl:for-each></xsl:template>

In terms of lines of code and time to write, XSLT would be the clear frontrunner. Using it would mean introducing another technology into the mix, however, which might not be beneficial. I probably wouldn't use XSLT for such a small task, but on a larger project, transforming XML with XSLT to fit your needs could save you a bundle of time.

XSLT is tightly knit with another of those "X" technologies: XPath, which provides a mechanism for addressing parts of an XML document in a logical fashion. The book includes a fair amount of material on XPath, and I was pleasantly surprised to realize that by reading it, I was not only getting an introduction to XSLT, but I would also walk away with a basic understanding of XPath.

XPath models an XML document as a tree of nodes. The name comes from its use of "paths" in an XML document; this is similar to the structure of a typical file system.

For example, consider the following XML document:

<?xml version="1.0"?><book> <title>XSLT</title></book>

In this document, "/book/title" is the XPath representation for the book's title. XPath provides XSLT with a mechanism for pattern matching certain parts of the XML document for transformation. Without XPath, XSLT would have no way of traversing XML documents and locating specific data. XPath is an isolated specification, so other specifications, such as XPointer, may also use the functionality.

After a couple of warm-up chapters, Tidwell jumps right into the practical applications of XSLT as a translation tool. The book provides examples of common XSLT applications such as:

● Converting XML to HTML

● Converting XML to VRML (Virtual Reality Modeling Language)

● Converting XML to image formats such as SVG (Scalable Vector Graphics) or JPEG

● Converting XML to Java source code (or any source code for that matter)

● Sorting and/or reorganizing XML

● Importing Java class libraries to do pretty much anything your heart desires with your XML documents! (Except turning them into a toaster.)

Tidwell uses these examples as his main teaching tool. All are very detailed and fully developed enough to provide you with a great foundation for your first XSLT adventure. Although the book does also include brief explanations and summaries, the real meat in most chapters consists of long, incremental examples of XSLT code that Tidwell walks you through. I found myself skimming through examples I didn't think I'd want to apply in the near future and really delving into those involving more practical technologies such as HTML, XML, and Java class libraries.

Not looking for a book of examples? Then you may want XSLT as a reference anyway. In the back is a complete explanation of all elements and functions defined in the XSLT specification.

As a developer, reading this book can only benefit you. Although a handful of languages are able to translate XML, XSLT is the only one specifically designed for this task. And even if you never actually use XSLT, escaping temporarily into this realm and away from the world of procedural languages will enhance your creative and problem-solving capabilities. The book makes you rethink your projects, past and present. And if you do actually employ -- or want to employ -- XSLT, Tidwell's book can serve as both a valuable tool for deepening your knowledge and a practical reference for your development bookshelf.

- John A. PrinceRational Software

Copyright Rational Software 2002 | Privacy/Legal Information

Book Review

The Laws of the Web: Patterns in the Ecology of Information by Bernardo A. Huberman

MIT Press, 2001

ISBN: 0-262-08303-5Cover Price: US$24.95(105 Pages)

Having had responsibility for managing Web development at various companies since 1996, I was intrigued by the title of this book. I was curious to know what "laws" (or patterns) might have evolved during this five-year span and how I might be able to factor some of them into future site development efforts. What I discovered when I actually opened the book is that the book looks at people's Internet behavior from a sociological perspective and presents scientific studies on usage of the Internet as an information medium.

Huberman attempts to quantitatively measure and test theories of human behavior and social interaction and apply various mathematical methodologies to those patterns. The book begins with an introduction to the overall phenomenon of the Internet and the power of information. It then examines the Web-induced paradigm shift from permanent to transient data, which has resulted in information that is pervasive and easily reproducible. From there, Huberman goes on to conduct a sociological examination of this shift and its global implications.

The book examines several "regularities" that shed light on how information is stored and linked within the Web, how individuals use that information, and how they interact on a massive scale when seeking information on the Web. Huberman summarizes these regularities into six laws -- or theories -- relating to recognizable patterns of behavior and the methodologies he used to discover them. My understanding of these laws is as follows:

1. Power Law of Distribution. This law posits that, despite the seemingly arbitrary way in which the Web grows, there are clear patterns that reflect hidden regularities. You can determine the anticipated growth rate for a given site, for example, by creating a skewed distribution of current size, its growth (in terms of pages, visitors, etc.) to date, and the number of links per page, and then

applying a fixed mathematical formula (1/nß).

2. Small World Law. This law is analogous to the "Six Degrees of Separation" theory: It says that members of a large population are connected by short chains of acquaintances. In relation to the Web, this is based on the derivative of the shortest link path to various "small worlds" and communities. The mathematical model Huberman proposes for this law is useful for studying Web navigation; in particular, it has potential for improving search engine and e-commerce site designs.

3. Law of Surfing. The perceived value that a user gets with each click is randomly related to the previous one; therefore, the value of subsequent clicks is based on a probability factor. According to this law, one can then determine the number of pages that a user is likely to visit within a site by looking at the probability that any visitor will surf a given number of pages within any site.

4. Law of Congestion. This law relates to the way people weigh global good vs. cost/benefit to themselves as individuals. When people dine with a group, for example, and there is an unspoken agreement to divide the check evenly at the end of the evening, some people deliberately order an expensive meal, while some deliberately choose a cheaper one, thereby lowering the per person cost. When it comes to the Internet, users are not charged proportionally to their use, so some "greedy" individuals thoughtlessly consume as much bandwidth as they can. According to the law of congestion, this can create high-consumption patterns called Internet "storms." Often, when they encounter a storm, large numbers of users defer surfing until a later time; they relinquish bandwidth almost synchronously, thereby relieving the congestion. Although they don't do this deliberately to help others, these people are analogous to those who order the less expensive meals. This law of congestion is helpful in designing algorithms for speeding up traffic on the Internet.

5. The Free Ride Law. This is closely related to the law of congestion. When using network applications such as Napster and FreeNet, some people will download a lot of material and hog a lot of bandwidth without contributing anything in return. The author proposes several solutions, from market-based, fee-per-use architectures to alternate cost structures that require in-kind contributions.

6. The Law of Downloading. This law relates to the typical travel time between any two computers and its effect on site usability/performance. When a user clicks on a link and nothing happens, he or she will typically halt that download and click again to reload. This manual restart process needs to be factored into sites handling e-commerce, for example. Some sites use an automated reload mechanism that anticipates this user behavior and makes the download appear to be progressing more quickly.

In addition to the chapters devoted to each of these laws, there is a chapter called "Markets and the Web," which presents an interesting discussion on the evolution of the digital market place and examines the

impact of branding on site traffic and other variants.

Although The Laws of the Web offers a fascinating look at historical patterns and theory, if you want practical advice on Web site engineering and design, this is not the book for you. However, if you want a glimpse of how social dynamics apply to the Internet and are willing to examine probability models, then brush off your statistics book and start here.

- Christina HoweDirector, Internet ServicesRational Software

Copyright Rational Software 2002 | Privacy/Legal Information

Points of Integration Between Rational TestManager and Rational ClearQuest

by Brenda Cammarano Senior Technical Evangelist

Rational Suite

The first installment of this Rational Edge series provided an overview of the points of integration in the Rational Suite and explained how to set up projects with Rational Administrator. The next article in the series, on points of integration between Rational Rose® and Rational RequisitePro®, addressed specific points of integration between two specific Rational Suite® products and explained how users can leverage them to best advantage. This month's article follows a similar format, focusing on integrations between Rational TestManager® and Rational ClearQuest® in Rational Suite v2002.

Rational TestManager improves productivity for testing teams by providing centralized control of all test assets and activities, from test planning through design, execution, and analysis and by integrating legacy and proprietary testing into an open, extensible framework. Rational ClearQuest is a powerful, flexible, and scalable defect and change tracking system that efficiently captures, tracks, and manages all types of project change requests in any development environment.

For testers, the integration between these two products provides significant team unifying capabilities. It allows every team member to create ClearQuest defect records directly from the testing environment. And for each of these records, TestManager provides critical supplemental data that enables any developer to duplicate the problem and all team members to track defects more effectively and ensure their resolution.

Establishing the Integration

Establishing the integration between Rational TestManager and Rational ClearQuest is simple, using Rational Administrator:

1. Start Rational Administrator: Click Start, then click Programs > Rational Suite > Rational Administrator.

2. To create a new project, click File > New Project on the Administrator menu. A wizard will then lead you through a series of prompts to create a project. You will have the option to fully configure your project at this time (see Figure 1).

❍ Create a new test datastore or associate an existing datastore with the Rational Project under the Test Assets section.

❍ Create a new ClearQuest database or associate an existing database with the Rational Project under the Change Requests section. You can apply any ClearQuest schema to your ClearQuest database for the integration, but the TestManager packages must be applied to the Schema prior to upgrading your database. For additional information on updating the ClearQuest schema, consult Appendix B "Adding ClearQuest Integrations" in the Rational ClearQuest Administrator's Guide.

For additional information on configuring new and existing Rational Projects, consult Chapter 3, "Creating and Configuring a Rational Project," in the Rational Suite Administrator's Guide.

Figure 1: Screen for Configuring a Project in Rational Administrator

Now you can create a defect record through TestManager's Log Viewer. Note that when you do this, TestManager will attempt to connect to ClearQuest with the same userID and password that you used for logging into TestManager. Should the silent ClearQuest login fail, which can happen if the same userID already exists in ClearQuest with a different password, then TestManager will display the ClearQuest login dialog box, pre-populated with your userID, and ask you to supply the correct ClearQuest password.

Creating a Defect Record

Let's take a closer look at the specific capability you get when you implement the integration between Rational TestManager and Rational ClearQuest. Suppose you are a tester viewing in TestManager's Log Viewer the results of a test that you've just applied to a newly created feature function. You see a failure in one of the events, so you want to create a new defect record. This will communicate to development all the pertinent information on where and how to reproduce the bug, so that it can be fixed in a quick and efficient manner. Later on, you (or someone else on your team) can conduct further testing, applying the same testscript, to see whether the defect has been corrected.

Without leaving Log Viewer, you can create a defect record in Rational ClearQuest:

1. Open the test log in TestManager and click the Details tab.

2. Expand the log to show all events (Figure 2).

Figure 2: Expanded Rational TestManager Test Log Showing All Events

3. Right click on the event (line) in the log that indicates a problem, and then select Submit Defect. Rational ClearQuest will create the defect record, and Rational TestManager will automatically populate the record with information appropriate for the event you selected, as indicated in the following list:

● Suite Project

❍ Always populated.

● Build

❍ Always populated.

❍ Based on the build label selected when the test was executed.

● Log Folder

❍ Always populated.

❍ Based on the folder selected when the test was executed.

● Log

❍ Always populated.

❍ Based on the log selected when the test was executed.

● Test Case

❍ Populated only if a test case was executed and the defect was generated from an event in the log resulting from the execution of a test case.

● Test Script

❍ Always populated if the defect was generated from an event in the log resulting from the execution of a test script.

● Verification Point

❍ Only populated if the tester submitted the defect from a verification point event in the log.

● Test Input

❍ Only populated if a test case was executed and the test case has an associated test input(s).

Once the defect is saved in ClearQuest and you are returned to the TestManager log, you will see the defect ID displayed in the "Defects" field. And from ClearQuest, you can now generate reports showing related testing and defect details.

It's important to note that:

● You may submit a defect from any line in the log, regardless of whether the results are listed as a pass or a fail.

● The information that is transferred from the log to the defect is hard coded. You cannot alter the information in this integration.

● If you attempt to generate a second defect from exactly the same event line in the log, TestManager will ask whether you would like to open the existing defect or generate a new one.

Greater Convenience and Accuracy Throughout the

Development Lifecycle

What does this capability do for a testing team? Here are the big benefits:

● The biggest benefit is convenience: Everyone on the team gets a real-time window to create defect records directly from Rational TestManager. If you see a problem on a test log that you want to track, you don't have to switch applications to launch the process. It's much more convenient throughout the project, too. Every tester on the team has the ability to view accurate and timely information directly from TestManager and update the defect record as needed.

● Another big benefit is greater testing accuracy. With detailed information that shows you where the problem occurs and how to recreate the bug, you can save time, ensure that you're testing the right defect, and maintain effective communication about the problem across your entire team.

● With the integration between TestManager and ClearQuest, Rational Suite users can complete a full-circle product integration that spans the entire project lifecycle: They can track a project requirement with RequisitePro and associate the requirement with a test case through test inputs in TestManager; if they see a test failure in a TestManager log, they can create a defect record directly from that log in ClearQuest, and TestManager will automatically record all related data in the record to enable accurate testing and problem resolution later in the lifecycle.

Want to Know More?

For more detailed information on this integration, see the following:

● Online Help in Rational TestManager (search on "Defects")

● Online Help in Rational Administrator (search on "Integrations," "Test Datastores," and "Defects")

● Online Help in Rational ClearQuest (search on "Defects" and "Reports")

Acknowledgments

Many thanks to Sandy Wilkey of Rational Automated Testing for contributing to and reviewing this article.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Activity Diagrams: What They Are and How to Use Them

by Maria Ericsson Senior Process Developer

Rational Software

In its basic form, an activity diagram is a simple and intuitive illustration of what happens in a workflow, what activities can be done in parallel, and whether there are alternative paths through the workflow.

Activity diagrams as defined in the Unified Modeling Language1 are derived from various techniques to visually illustrate workflows; see, for example, Johansson et al.2. And much of the basis for the definition

of the activity diagram notation is found in Martin and Odell.3.

In the Rational Unified Process4, we talk about how you can use activity diagrams to visualize the workflow of a business use case. A complete workflow description will have a basic flow, and one or several alternative flows. This workflow has a structure that we can define textually, using informal if, if-then-else, or do-until statements of various kinds. For a simple workflow with a simple structure, such textual definitions may be quite sufficient, but in the case of more complex structures, activity diagrams help to clarify and make more apparent what the workflow is.

Historically, activity diagramming techniques have mostly been used in the business process modeling domain, but this article will also briefly discuss how you can use it in the system modeling domain.

The purpose of this article is to show how you can use activity diagrams within the Rational Unified Process for business modeling as well as system modeling. Activity diagrams are often mentioned almost as a synonym to business modeling. For a more complete introduction to what business modeling is we refer to Kruchten,5 and for details to Jacobson et al.6.

The reader of this article is assumed to be familiar with the basics of the

Unified Modeling Language (UML).

Basic Activity Diagram Notation

As is common for most notations, the activity diagram notation has some elements that are necessary for you to understand if you want to be "conversant" about activity diagrams. Those elements are presented in this section. The next section talks about additional goodies you may find useful. Figure 1 shows a basic activity diagram.

Click to enlarge

Figure 1: An Activity Diagram for the Business Use Case Individual Check-In in the Business Use-Case Model of Airport Check-in

Activity states, which represent the performance of a step within the workflow.

Transitions that show what activity state follows after another. This type of transition can be referred to as a completion transition. It differs from a transition in that it does not require an explicit trigger event; it is triggered by the completion of the activity that the activity state represents.

Decisions for which a set of guard conditions are defined. These guard conditions control which transition of a set of alternative transitions follows once the activity has been completed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a business use case.

Synchronization bars, which you can use to show parallel subflows. Synchronization bars allow you to show concurrent threads in the workflow of a business use case.

Advanced Notation

In more complex examples, you would often make use of the following constructs:

● Conditional threads

● Nested activity diagrams

● Partitions

Conditional Threads

Guard conditions can be used to show that one of a set of concurrent threads is conditional. For example, in the individual check-in example from Figure 2, the passenger checking in might be a frequent flyer member. In that case, you need to award the passenger frequent flyer miles.

Click to enlarge

Figure 2: Awarding Frequent Flyer Miles: a Conditional Thread in the Individual Check-In Workflow

Nested Activity Diagrams

An activity state may reference another activity diagram, which shows the internal structure of the activity state. Another way to say this is that you can have nested activity graphs. You can either show the sub-graph inside of the activity state (Figure 3), or let the activity state refer to another diagram (Figure 4).

Click to enlarge

Figure 3: A Nested Activity Graph Shown Within an Activity State

Click to enlarge

Figure 4: Alternative: Put the Sub-Graph in a Separate Diagram and Let the Activity State Refer to It

Showing the sub-graph inside the activity state is convenient if you want to see all details of the workflow in the same diagram. But if there is any level of complexity presented in the workflow, this can make the diagram hard to read.

To simplify the workflow graph, you may instead choose to put the sub-graph in a separate diagram, and let the activity state sub-graph details refer to that diagram.

Partitions

The contents of an activity diagram may be organized into partitions (swimlanes) using solid vertical lines. A partition does not have a formal semantic interpretation, but is, in business modeling, often used to represent an organizational unit of some kind (Figure 5).

Click to enlarge

Figure 5: An Activity Diagram Illustrating the Workflow of a Business Use Case that Represents a (Generic) Sales Process. In this example, the partitions represent

departments in the organization.

Documenting Business Use Cases

Background: A business use-case model describes the processes of a business and their interactions with external parties like customers and partners. The processes of the business are represented as business use cases, and the external parties are represented as business actors. Describing a business use case includes, among other things, giving it a name, a brief description, defining its performance goals, and its workflow. The most time-important and time-consuming aspect to describe is the workflow.

Which comes first, the activity diagram or the textual description of the workflow? This is somewhat dependent on how you are used to working, and whether you "think graphically" or not. Some prefer to outline the structure visually in a diagram first, and then develop the details in the text. Others start with a bulleted list of the activity states first, and agree on those (like a step-by-step outline to the use case), then define the structure using a diagram.

A valid question is also whether you really need both the textual document and the diagram. The activity diagram technique allows you to write brief descriptions of each activity state, which should make the textual specification of the workflow obsolete. Here, you need to be sensitive to your audience and the format in which they expect the specification.

To understand what an activity diagram adds to the understanding of a workflow, we present a sample workflow description, and then an activity diagram for that workflow (Figure 6). This example is a proposal process, taken from an organization that sells telecom network solutions, individually configured to each customer. We have simplified the example by removing the detailed text in most of the subsections, but tried to keep enough so you can understand the structure of the workflow. The full text of this example can be found in The Rational Unified Process, version 5.1.1.

Click to enlarge

Figure 6: An Activity Diagram for the Business Use Case Proposal Process

An activity diagram for the workflow is shown in Figure 6. We use basic notation only in this diagram. Activity states correspond to sections in the

Sample Basic Workflow for the Business Use Case Proposal Process (Figure 6)*

1.1 Initial Contact

This process starts with an initial contact between the customer and the company. This may happen in one of the following ways:

1.2. Initial Opportunity Work

1.2.1 Gather Preliminary Customer Requirements

1.2.2 Create Sales Plan (optional)

1.2.3 Perform Opportunity Analysis

1.3. Create Proposal Project Plan

1.4. Create Delivery Project Plan

1.5. Prepare a Quote

1.6. Compile Additional Information

1.7. Analyze and Finalize the Proposal

1.8. Present the Proposal

1.9. Obtain Customer Decision

Alternative Workflows

2.1 Business Opportunity Rejected

If, in 1.2., it turns out the business opportunity is rejected, the following actions may be taken:

workflow description:

The activity state "Initial opportunity work" consists of three sub-steps that can be done in parallel. This is illustrated in a sub-graph to this activity state. See Figure 7.

Click to enlarge

Figure 7: Sub-Diagram to the Activity State 'Initial Opportunity Work.' Creating a sales plan is optional, which is indicated

by a guard condition on the incoming transition.

An activity state can represent a fairly large procedure (with substructure), as well as something relatively small. If you are using activity diagrams to define the structure of a workflow, you should not attempt to explore several levels of activity graphs down to their most "atomic" level. This will most probably make the diagram (or set of diagrams, if you are using separate sub-graphs) very hard to interpret. You should aim at having one diagram that outlines the whole workflow, where a few of the activity states have sub-graphs.

Documenting Business Use-Case Realizations

Background: A business use-case realization describes how a particular business use case is realized within the business object model, in terms of collaborating business workers and business entities. A business worker represents a set of responsibilities typically carried by one individual. A business entity represents a "thing" that is created, managed, or used.

2.2 Unable to Meet Customer Requirements

If, in Perform Opportunity Analysis or Prepare a Quote, the company is unable to suggest a solution to the customer requirements, then the following actions may happen:

2.3 Critical Information Not Known

If at any point in the Proposal Process the company identifies some critical information not known or available then it does one of the following:

2.4. New/Incomplete or Incorrect General Customer Profile

If the company determines that the general customer profile is inaccurate for some reason, the following actions may be taken.

*(See Rational Unified Process, v.5.1.1 for more detail)

The realization of a business use case can be described textually, but is more commonly explained with diagrams -- collaboration diagrams, sequence diagrams, activity diagrams, or a combination. Which diagram type you choose depends on the complexity of the workflow and where you are in the process.

You are using the activity diagram to document business use-case realizations, rather than business use cases, if you are using partitions and the partitions are coupled to classes (business workers mainly) in the business object model (Figure 8).

Compared to a sequence diagram, which could be perceived to have a similar purpose, an activity diagram with partitions focuses on how you divide responsibilities onto classes, while the sequence diagram helps you understand how objects interact and in what sequence. Activity diagrams give focus to the workflow, while sequence diagrams give focus to the handling of business entities. Activity diagrams and sequence diagrams could be used as complementary techniques, where a sequence diagram shows what happens in an activity state.

Click to enlarge

Figure 8: The Same Workflow Presented in Figure 6, But with Activities Organized in Partitions

Just for Business Modeling?

Background: The use-case model is a model of a system's intended behaviors. A use case tells the story of how a user (represented as an actor in the model) can use the system to achieve a particular purpose. Describing a use case includes giving it a name, a brief description, and

defining the flow of events of the use case.

Just as you would use an activity diagram to show the structure of a workflow, you could also use it to show the structure of a flow of events of a system use case (Figure 9).

Click to enlarge

Figure 9: A Simplified Activity Diagram for the Use Case "Withdraw Money" in the Use-Case Model of an Automated Teller Machine (ATM)

In the first stages of identifying objects and classes based on the use cases (use-case analysis), activity diagrams can be useful when exploring responsibilities of analysis classes. You might use the activity diagram technique to draw a first sketch of class responsibilities, a sketch that you then throw away.

Summary

This article has given you an overview of:

● Basic and advanced elements of the activity diagram notation. Basic elements of activity diagrams are activity states, transitions, decisions, and synchronization bars.

● How activity diagrams allow you to show concurrent threads, and alternative threads, as well as conditional threads in a workflow.

● How you can use activity diagrams in business modeling. You can illustrate the workflow of a business use case. You can describe how a business use case is realized by business workers and business entities.

● How you can use activity diagrams in system modeling. You can illustrate the flow of events of a use case. You can define how a use case is realized by analysis classes.

References

1. OMG UML Specification.

2. H. Johansson, P. McHugh, J. Pendlebury, and W. Wheeler, III, Business Process Reengineering. Breakpoint Strategies for Market Dominance. John Wiley and Sons, 1993.

3. J. Martin and J. Odell, Object Oriented Methods: a Foundation, the UML Edition. Prentice Hall, 1996.

4. Rational Unified Process, version 5.1.1

5. Philippe Kruchten, The Rational Unified Process: An Introduction. Addison-Wesley, 1998.

6. Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineering with Object Technology. Addison-Wesley, 1994.

*NOTE: This article was originally published on Rational Developer Network, the learning and support channel for the Rational customer community. Rational Developer Network is now available to all Rational customers. If you are a customer and have not already registered for your free membership, please go to www.rational.net.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

What If We Used Common Sense?

by Joe Marasco Senior Vice President

Rational Software

We sometimes tend to get a little wrapped up in the jargon of our trade: process frameworks, iterative development, and the like. What would happen if we had to explain this stuff to "civilians"? This month we meet one such candidate: Roscoe Leroy.

Roscoe Arrives on the Scene

The first thing to know about Roscoe is this: Don't make fun of his name. "It shows my parents had a sense of humor. Besides," he always adds, "it could have been worse. They could have named me Leroy Leroy."

Roscoe, it turns out, is an old war buddy of my dad's. According to Roscoe, they both served under Patton, although my guess is that my dad served directly under Roscoe, and Roscoe served somewhat remotely under Patton. Mr. Leroy (one never calls him that) is one of those old salty dogs who has an opinion on just about everything. The annoying thing is that he is right so much of the time.

Of course, when he is wrong, the results are not pretty, because he is willing to back his convictions to the hilt. I have seen Roscoe push all his chips to the center of the table, confident that his poker hand was the best. The results were spectacular, but not always in the way Roscoe would have liked.

On the plus side, Roscoe's wisdom is simple and easy to understand. It comes in the form of very prescriptive advice. So long as you don't probe too much for deep theory, you'll be fine. Going with Roscoe is a leap of faith, one that we might all benefit from taking when the chips are down.

Roscoe's Qualifications

Roscoe has been there and done that. He boasts of having finished the eighth grade, but I have it on good authority that he graduated from an excellent high school some time in the thirties. My dad explained this discrepancy to me simply by saying that Roscoe felt it unnecessary to flaunt his education.

At various times, Roscoe has served in the military, fought oil well fires with Boots and Coots,1 and been a mining engineer. Those experiences made him a pragmatic kind of guy, but they also taught him how to perform under pressure. He does manage to get all the dirt out from under his fingernails if you invite him to dinner, but don't expect too much use of the salad fork.

Roscoe doesn't do math, really; he does arithmetic. Answers tend to come out of his mouth in whole numbers. When asked about this, his reply is along the lines of, "Well, it always comes down to how many sticks of dynamite you need to make the hole, and how many men you need to clean it up. I don't cut my dynamite in half, and I don't hire fractional people." When he puts it like that, you know you are done.

Chocolate Versus Vanilla

Roscoe showed up at my house a while back with a copy of USA Today under his arm. "Looks like even McPaper is starting to understand," he said, knowing I would be unable to resist taking the bait. When I asked him what he was talking about, he showed me one of the little squibs in the corner of the page: 52 percent of the population prefers vanilla ice cream, 48 percent chocolate. From my perspective, that registered pretty high on the "so what?" meter.

Then Roscoe offered the following. "Notice what it says below the little bar graph: Accuracy2 is plus or minus three percent. Now that is significant. For years they published these factoids without any indication of the error bars. We must be getting less stupid about polls, if they think they have to tell you the likely error."

I had to admit I had never thought about it that way. I also was intrigued by why Roscoe thought it was interesting.

Roscoe Explains

"Of course," he said, "three percent error is important, because the total spread in the preference is only four percent. So we can't be really sure. But I'll tell you one thing: I bet I know how many people they asked."

Certain that Roscoe had never taken a probability and statistics "seminar" that didn't involve poker chips, I was about to learn otherwise.

"Here's my guess," he continued. "They talked to about a thousand people. The error on a thousand answers is roughly the square root of a thousand, which is 31.4. Thirty one over one thousand is 3.1 percent, which of course is roughly three percent."

"Wait a minute, Roscoe," I jumped in. "The square root of a thousand is 31.6, not 31.4."

"There you go, letting your education get in the way again. Any fool can remember that the square root of ten is pi, which is 3.14. For a thousand, move the decimal point one place in the answer: 31.4, done deal."

Well, my math was more accurate, but seeing as how we were going to round off anyway, the difference did seem academic. And it did seem like a fairly reasonable calculation.

Roscoe Goes Deeper

"I'll tell you another thing," Roscoe continued. "You'll never see that kind of squib with an error bar of, say, one percent."

I thought about that for a couple of seconds, but Roscoe wasn't patient enough to wait for my thoughts on the subject.

"Doesn't take an Einstein to figure out why, either. If you use the same logic, you'll see that they have to talk to ten thousand people to get the error down to 100, or 1 percent. That's ten times as expensive as talking to a thousand people. So to push the error down from 3 percent to 1 percent, it costs you an incremental factor of nine."

"Ten," I thought to myself. Then I realized you could reuse the first thousand in the second sample. Never misses a trick, that Roscoe.

Roscoe's Calendar

By now I had developed a belief that Roscoe had learned about square roots. This was confirmed when I talked with him about projects and schedules. His assumptions about the number of weeks in various periods was, well, curious. The following table encapsulates my discovery.

Duration Roscoe's Duration

Two years 100 weeks

One year 49 weeks

Nine months 36 weeks

Six months 25 weeks

Four months 16 weeks

Two months 9 weeks

One month 4 weeks

When I asked him about three-month projects, Roscoe replied, "Don't like to do those."

It was clear from these numbers that some Leroy square root arithmetic was in the offing. You don't set out a pattern like that without some

underlying motivation. Another thing that was interesting was Roscoe's unwillingness to talk about time intervals of less than a week. "We ain't day laborers, son," he'd say. "I pay my engineers by the week. So that's the smallest interval I ever use when estimating."

Seemed about as reasonable as his argument about fractional people.

Roscoe Computes

"Actually," said Roscoe, "I can compute square roots lickity-split. And without a square root button on the old calculator."

"Fifty-three!" I shouted out, challenging him on the spot.

"No sweat," he said, talking and punching numbers simultaneously. "Fifty-three is close to forty-nine, so we'll start with a guess of seven. Seven into fifty-three goes 7.57 times. Now we know that since seven is too low, 7.57 must be too high, so let's take the average. In my head, that's 7.28. Then, 7.28 into 53 goes, well, gosh, would you believe it, 7.28 times. So I guess the answer must be 7.28."

For the guy to have extracted the square root to two decimal places with two divisions was impressive. But Roscoe had a different point of view.

"Too tiring," he said. "Prefer to work with round numbers. Sticks of dynamite and whole people…"

Roscoe Gets into Software

Just when I thought the world was safe, Roscoe fessed up. "They closed the mine, son," he said. "Looks like I need to find a new job. Think I could manage one of those software projects?"

Thank heavens the dot com frenzy has abated, I thought. How the hell would I ever explain that to him? On the other hand, he would certainly bring a fresh point of view to our business. We might actually learn something in the process.

"Sure, Roscoe," I replied. "Go off and learn about iterative development. That's the best place to start. Read up on that, talk to some people, and then come back to see me." I figured that would keep him busy for a while.

"I'll get back to you," he said, being careful not to let the screen door slam as he left.

Roscoe Reports In

About a month later, Roscoe showed up as usual, with no notice and a chip on his shoulder. I figured he had had enough time to understand the essentials, and I was interested in what he had to say.

"Well, there sure seems to be enough written about this stuff," Roscoe opined as he pulled up a three-legged stool. "In fact, it's amazing to me that you could know so much about something so screwed up."

I allowed that our success rate in software projects was not quite up there in the spectacular category. Roscoe was unimpressed.

"Seems like folks think this stuff is really hard. Shoot! Digging for coal is hard. This is just software, after all."

I said, well maybe we should use the word "difficult," not "hard," but Roscoe was not to be convinced.

"Hate to remind you, but the Egyptians built the pyramids. 'Course, they did have that fella Euclid3, who was nobody's fool. But, even today, the Amish can put up a barn in one day, for crying out loud."

"But," he continued, "there are some signs of hope."

Guess We Did Something Right

"It strikes me that the iterative development boys are on the right track. Although it's just a fancy name for what every cowboy carpenter4 does -- cut and try. Those boys know that they can't measure or cut that accurately, so they rough it out first, and then fix it until they're done. Of course you guys would call it 'successive refinement on subsequent iterations.'"

I detected a small note of sarcasm in Roscoe's summary. But he was not to be deterred.

"Of course, the cowboy carpenter has to be more careful than you guys. He knows that he can always take a little more off, but adding material back is hard. Learned that from his barber. So he always has to make his first cut the right way. Some big city comptrollers use that algorithm, too."

Now Roscoe always pronounces the "p" in comptroller so that you know that he knows the right word. But "algorithm" came out of his mouth sort of like "I'll-go-rhythm." Oh shoot, I thought. We are in big trouble. Roscoe has learned a new word.

"Roscoe, where did you pick up that word, 'algorithm'?" I asked.

"Well, son, I've been talking to some software architects…" he trailed off.

"Huh," I replied, "who told you to do that?"

"First of all, you did. You said talk with people. Hey, I may look stupid, but I know what I don't know. There's a big difference between reading a set of blueprints and producing one. So I went and palavered a bit with those good old boys."

"Fair enough," I said. "What did you learn?"

Roscoe Sums It Up

"Well, it makes sense to me. Basically, when you start a project you don't know spit, so the initial phases are important. After all, you don't want to build a fifty-dollar fence to keep in a ten-dollar horse, so understanding what it is you're trying to do just makes sense to me. Likewise, I like the idea of keeping the payroll down until you have a pretty good idea of what all those people are going to do. Otherwise, you're just paying them to chew tobacco until someone figures out what they should be doing."

I was starting to be impressed with Roscoe's appreciation of the situation.

"Then I got into the scheduling and estimating end of things. Some pretty smart fellas there. In particular, that guy Barry Boehm and that guy Walker Royce seem to have a handle on some of it. Although their Coconut model is a little high falutin' for me."

I cringed, but didn't have the heart to correct him. COCOMO and coconut do sound a little alike, after all. And there were lots of other interpretations you had to make in parsing Roscoe-speak, so this would not be too much of an additional stretch.

"Then I got around to reading some Kruchten and Booch, and even stumbled onto your name. Right here," he said, pointing to a page in a dog-eared copy of Grady's book, Object Solutions.5

Sure enough, he had me dead to rights. There I was, in black and white, in a footnote on page 136.

Roscoe Picks a Bone

"Well, it says here that you and that Kruchten fella have observed that the duration of an iteration in weeks seems to be equal to the square root of the size of the code to be developed, as measured in thousands of lines of code."

It was hard to argue with him. It was a direct quote. I figured I was in for it now.

"Hmm. I even talked with my architect friend, and he said there's a term for 'a thousand lines of code.' Claims it's called a KSLOC, for 'kilo source lines of code.' Whoosh!"

Roscoe was clearly warming to the task.

"Buncha B.S., I'd say. Like trying to estimate how big a project the pyramids are going to be, and using the 'brick' as your unit of measure. Only that would be ridiculous, so you invent the 'kilobrick.' Dumbest thing I ever heard of."

The man was gaining momentum, and I was not going to lie down in front of that locomotive just yet.

"But the real problem, as I discovered in talking with my architect friend, is that nobody knows how to count SLOCs or KSLOCs. Do you count every line, including comments? Do you count your headers and your source files, where there is obviously lots of repeated stuff? And how do you deal with those huge libraries that you're gonna use, but not write from scratch? Basically, you have a number that you can get from 'Dial-a-Prayer.'"

I made a note to talk to the architect about telling Roscoe about headers and such. I knew he didn't make that up on his own. But the man had a point: We had concocted a formula that was based on a number that was, to put it charitably, subject to some interpretation. The prediction would be no better than the definition we used for SLOCs.

Guess We Did Something Right, Part Two

Just when I thought Roscoe was going to write me off completely, though, he came up with a compliment, sort of.

"You did get something right, Joe. The square root is the key. The whole idea is that you don't want to have too many iterations, because each beginning and end of an iteration has overhead, which as we all know is just plain unproductive. On the other hand, you don't want to have too few iterations, because then you lose all the benefits of iterative development. It's like Goldilocks and the porridge -- it needs to be just right.

"Now, I think you were right to peg the iteration length to the square root of the size of the project. And picking the week as the unit of measure was surely the right thing to do, as it is the fundamental unit of labor measurement. All's you did wrong was get tangled up with that KSLOC idea. I've got a much simpler way to do it."

I listened. Carefully.

"The main problem is that you start from the wrong place. You need to use that Coconut or some other technique to negotiate the total time you are going to be allowed to have to complete the project. Management always wants it sooner, and you'll always wind up discussing a date, not the number of lines of code. You might get to barter the date against the size of the team, or against the feature set, for instance, but in the end what you will have that is fixed is the length of time.

"Once that's settled, it's easy. The duration of an iteration should just be the square root of the total duration of the project. Let me show you this little table I made up."

I was not surprised to see Roscoe's calendar make a guest appearance. Nor was his fondness for square roots absent from the proceedings.

Duration Roscoe's Duration Iteration Length Number of

Iterations

Two years 100 weeks 10 weeks 10

One year 49 weeks 7 weeks 7

Nine months 36 weeks 6 weeks 6

Six months 25 weeks 5 weeks 5

Four months 16 weeks 4 weeks 4

Two months 9 weeks 3 weeks 3

One month 4 weeks 2 weeks 2

Damn! Wouldn't you know it, when I went back and checked against my database of projects, Roscoe's estimates weren't that far off. As he would say, "plus or minus one stick of dynamite."

And no SLOCs. I was impressed.

Roscoe Admitted to SPM6 Fraternity

Based on this little exercise in figuring out how long an iteration should be, I deemed Roscoe competent enough to take on his first iterative development project. But I had a warning for him.

"Roscoe, listen up," I said. "You are going to find out that 'calling the shot' in software projects is incredibly slippery. If you come up with any ideas there, I'd be really glad to hear from you."

"Sure 'nuff," he said. "See you next month."

Editor's Note: Look for more wisdom from Roscoe Leroy in our February issue!

Notes

1 Boots and Coots used to be a colorful oil well firefighting outfit. Some time ago, while I was not paying attention, they "went legit." See http://www.halliburton.com/products/prod_enhan/h01004a.asp2 Sometimes the term precision is used instead, but precision and accuracy are not the same. Precision indicates the degree to which the measurement is reproducible. If you have a high precision measurement method and measure many times, most of the measurements will fall within narrow margins. On the other hand, accuracy is a measure of how close the measurement is to reality. Precision talks about measurements on the sample; accuracy reflects how close your measurement of the sample is to defining the properties of, in this case, the underlying population. Roscoe may appear to be sloppy in his use of these terms, but he is not; we shouldn't be either. Shooting for high precision is silly in the face of low accuracy, because high precision costs money, and we should never pay lots of money for an inaccurate result. Just remember, always, that high precision does not necessarily imply high accuracy.3 A good example of Roscoe not letting his education get in the way: Euclid came after the pyramids, by a lot. He lived around 300 B.C., and the pyramids were built circa 3000 B.C. Makes the pyramids seem even more impressive, doesn't it?4 What Leroy is referring to here is the kind of carpentry ranchers and farmers do -- building

rough structures like barns and fences. The other end of the spectrum would be fine craftsmanship, as exhibited by a professional woodworker or cabinetmaker.5 Grady Booch, Object Solutions: Managing the Object-Oriented Project. Addison-Wesley, 1995.6 Software Project Manager

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Reader Mail

Got questions or comments about something you've read in The Rational Edge? Send them to mperrow@rational.com, and we will try to get you an answer ASAP! All questions and answers that could be useful to other readers will be printed in this section.

Dear Rational Edge:

I thank you very much for the articles published in The Rational Edge and especially Ben Lieberman's UML Activity Diagrams series.

I have a question on the content provided in Ben Lieberman's article "UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior" [April 2001]. My question is based on Figure 5: Addition of Data Modification Flows and Validation Steps to the Maintain User Profile Use Case. In this figure he shows the data entry activities such as Update Name, Update Priority, and Update Address as transitions from the User Modifies profile activity. And he mentions in the article that these are part of the User Modifies Profile activity.

But the UML spec clearly says that the transitions from the activity happen only after completion of that activity. After an extensive brainstorming discussion with my colleagues, we think that the data entry activities should not be shown as transitions from the activity; instead we believe the User Modifies profile can serve as a connector to a diagram, which shows these data entry activities.

I would be pleased if you would consider these comments and reply.

Thank you,

Linga A MurthyDeveloper, Aztec SoftwareBangalore, India

Ben Lieberman responds:

You are quite correct to point out that UML requires that activity transitions occur only after the completion of a particular action. However, to better show that the Update activity is actually composed of three parallel "sub-activites," I have bent some of the transition rules.

Unfortunately, the UML standard only allows State object to have embedded sub-states; no such provision has been made for activity diagram actions. However, since I am knowingly violating some of the UML transition secifications, in the diagram I should have made more explicit what was meant by the splitter line. I updated my diagram to show how I envision this transition to be communicated to the diagram viewer:

Click to enlarge

The idea here is to show that each of the three data entry activities can occur independently, but collectively are part of the Modify User Profile presentation. Since a use case should only suggest implementation, not dictate it, the Modify User Profile may contain one data entry screen, or three, depending on the specific needs of the application.

As you can see in the updated diagram, the transitions are indicated by guard conditions specifying which data entry activity is actually being conducted.

I freely admit that the "letter of the law" is violated by this approach, since by definition the Modify User Profile activity cannot be complete by the time we are using one of the data entry activities (since we are considering them tied together). However, since it is my understanding that the UML standard is flexible, and I have seen very few examples of this type of application for activity diagrams, perhaps we should consider some amendments to the UML standard to better support the concepts of use case flow diagramming. In particular, it might allow the embedding of sub-activities within a parent activity. I am currently considering just such a proposal.

Sincerely,

Ben Lieberman Senior Software Architect Trip Network, Inc. ben_lieberman@hotmail.com

A reader from the UK asks:

Has anybody published any useful notes on how to organise Rose models for multiple, concurrent projects? E.g. one or more .mdl files, unitisation strategies, component modelling, etc.?

Terry Quatrani responds:

The best answer is to break the model up into control units and then place the control units under configuration control. Then you can use all the power of your CM system on your models (e.g. check in, check out, version, compare, merge).

Terry QuatraniUML Evangelist

And another question for TQ:

I am currently working to reverse engineer a Java project. Is there any facility provided by Rational Rose to forward engineer to another language?

Thanks,Sadhana Mungale

It depends on what version of Rose you have. If you have a professional version, then the answer is no...only one language is supported. If you have Rose Enterprise, you could reverse engineer an application, do the re-design to support a different language, and then forward engineer to the new language.

TQ

Dear Rational Edge:

I enjoyed Joe Marasco's article about learning a new programming language [Franklin's Kite, December 2001]. The part about the Animal Game brought back memories. I implemented a version on a BBS in the mid-80s. I still have its database.

My standard game is Othello (aka "Reversi"). If you store a high-scores table, it meets all of your requirements. My earliest versions were in BASIC, and I went on to write versions in Pascal, C, C++, and Java. I also have variations for different operating environments. For example, I have a DOS version, a Windows version, a Swing version, and a JSP version that runs online by outputting HTML. Fortunately, the JSP version shares the same underlying Java code as the Swing version.

Frank LaRosahelloNetwork

Dear Rational Edge,

In Robert Pierce's article "Keep Documentation Up to Date Throughout Development with Rational Rose" [December 2001], he states that Rational SoDA is able to generate multiple htm files with a customised SoDA template. I have checked out the online SoDA manual that you provided, but I couldn't find any help related to this. Could you tell me the next steps in doing this please?

Thanks,Macy Chin

Robert Pierce replies:

For creating html topics, you:

1. Run a SoDA Report

2. Generate HTML Topics using a macro

Run a SoDA Report

Run a SoDA report to generate a Word document containing all the skeleton information for all the API reference topics. To generate the SoDA report do the following:

1. From Rose, click Report > Soda Report…

2. Select your template.

3. Click File > Save As and navigate to the location where you want the automatically generated folders and topic files stored.

After running a SoDA Report, the final step is to clean up the SoDA Word document and split it into separate HTML documents (one per topic). You can do this with a macro. To generate the HTML topics, do the following:

1. In Word, turn on paragraph markers.

2. Click Tools > Macro > Macros and select "HTMLSplitTopics".

3. Click Run. HTML topics are created for each interface, object, property, and method.

For example, in Visual Basic:

Sub HTMLSplitTopics()'' HTMLSplitTopics Macro'Dim MyDoc As DocumentDim TemporaryDocument As DocumentDim BeginFound As BooleanDim TemporaryFilename As StringDim TemporaryPath As StringDim MyRange As RangeDim TopicSubDirectory As StringDim BeginsParagraph As ParagraphDim EndsParagraph As ParagraphDim MemberName As StringDim AvailableCharacters As IntegerDim fsConst TotalNameLength As Integer = 32Const HalfNameLength As Integer = 16

Set MyDoc = ActiveDocumentSet fs = CreateObject("Scripting.FileSystemObject")

TemporaryFilename = (MyDoc.Path & Application.PathSeparator & "temp.doc")MyDoc.SaveAs FileName:=TemporaryFilename

BeginFound = FalseFor Each CurrentParagraph In MyDoc.Paragraphs

If Not BeginFound And _ CurrentParagraph.Range.Words.Count >= 3 Then If (Trim(CurrentParagraph.Range.Words(1).Text) = ">!--") And _ (Trim(CurrentParagraph.Range.Words(2).Text) = "Begin") And _ (Trim(CurrentParagraph.Range.Words(3).Text) = "topic") Then Set BeginsParagraph = CurrentParagraph BeginFound = True End If End If

If BeginFound And _ CurrentParagraph.Range.Words.Count >= 3 Then If (Trim(CurrentParagraph.Range.Words(1).Text) = ">!--") And _ (Trim(CurrentParagraph.Range.Words(2).Text) = "End") And _ (Trim(CurrentParagraph.Range.Words(3).Text) = "topic") Then Set EndsParagraph = CurrentParagraph Set MyRange = MyDoc.Range(Start:=BeginsParagraph.Range.Start, _ End:=EndsParagraph.Range.End) MyRange.Copy 'determine TemporaryFilename TopicType = Trim(BeginsParagraph.Range.Words(5)) If TopicType = "main" Then TopicSubDirectory = Trim(BeginsParagraph.Range.Words(4)) TemporaryPath = MyDoc.Path & Application.PathSeparator & _ TopicSubDirectory TemporaryFilename = TopicSubDirectory & ".htm" ElseIf TopicType = "PME" Then TopicSubDirectory = Trim(BeginsParagraph.Range.Words(4)) TemporaryPath = MyDoc.Path & Application.PathSeparator & _ TopicSubDirectory TemporaryFilename = TopicSubDirectory & "pme.htm" Else 'TopicSubDirectory = Trim(BeginsParagraph.Range.Words(4)) MemberName = Trim(BeginsParagraph.Range.Words(6)) If Len(TopicSubDirectory) + Len(MemberName) <= TotalNameLength Then TemporaryPath = MyDoc.Path & Application.PathSeparator & _ TopicSubDirectory TemporaryFilename = TopicSubDirectory & MemberName & ".htm" Else If Len(TopicSubDirectory) <= HalfNameLength Then AvailableCharacters = TotalNameLength - Len(TopicSubDirectory) TemporaryPath = MyDoc.Path & Application.PathSeparator & _ TopicSubDirectory TemporaryFilename = TopicSubDirectory & _ Left(MemberName, AvailableCharacters / 2) & _ Right(MemberName, AvailableCharacters / 2) & ".htm" Else TemporaryPath = MyDoc.Path & Application.PathSeparator & _ TopicSubDirectory TemporaryFilename = Left(TopicSubDirectory, HalfNameLength) & _ Left(MemberName, HalfNameLength / 2) & _ Right(MemberName, HalfNameLength / 2) & ".htm" End If End If End If TemporaryPath = LCase(TemporaryPath) TemporaryFilename = LCase(TemporaryFilename) If fs.FolderExists(TemporaryPath) Then With Application.FileSearch .FileName = TemporaryFilename .LookIn = TemporaryPath .Execute If .FoundFiles.Count = 1 Then If .FoundFiles(1) = TemporaryFilename Then Set TemporaryDocument = Documents.Open _ (FileName:=TemporaryPath & _ Application.PathSeparator & _ TemporaryFilename) Else Set TemporaryDocument = Documents.Add TemporaryDocument.SaveAs _

FileName:=TemporaryPath & _ Application.PathSeparator & TemporaryFilename End If Else Set TemporaryDocument = Documents.Add TemporaryDocument.SaveAs _ FileName:=TemporaryPath & _ Application.PathSeparator & TemporaryFilename End If End With Else fs.CreateFolder (TemporaryPath) Set TemporaryDocument = Documents.Add TemporaryDocument.SaveAs _ FileName:=TemporaryPath & Application.PathSeparator & _ TemporaryFilename End If TemporaryDocument.Select TemporaryDocument.Range.Delete unit:=wdWord, _ Count:=TemporaryDocument.Words.Count

TemporaryDocument.Range.Paste TemporaryDocument.SaveAs FileFormat:=wdFormatDOSTextLineBreaks TemporaryDocument.Close BeginFound = False

End If End If Next CurrentParagraph End Sub

Hope this helps!

Rob PierceStaff Technical WriterRational Software Corporation

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information