the rational edge -- july 2001 -- rational java tools ...€¦ · rational java tools: bringing...

Rational Java Tools: Bringing Twenty Years of Development Experience to a New Platform

by Johanna AmbrosioReporter

Through its own internal efforts, and by working with partners throughout the industry, Rational is delivering a new set of tools to help ensure speed and quality development in the Java community -- much as it already has for the C, C++, and Visual Basic environments.

In the six years that Java has been available, the platform has attracted some 2.5 million developers worldwide, according to Sun Microsystems, Java's creator. Rational is working to make sure that those developers have access to a full lifecycle software development platform that includes modeling, change management, and other tools crucial for the corporate world.

"Rational's mission for the past twenty years has been to ensure the success of companies that depend on developing and deploying software," said Bill Taylor, Director of Product Marketing for Visual Modeling and Developer Tools at Rational. "If our customers choose Java as their execution platform, Rational will provide an enterprise lifecycle solution for them."

"We really are focusing much more on the individual developer than in the past," said Jack Greenfield, Chief Architect of the Practitioner Desktop Group at Rational Software. "Developers spend 80 percent of their day in the edit-compile-debug loop, and much of that happens in the integrated development environment. So we're recognizing that what developers need is a tight integration between their IDE, and the other tools they might use to do their job."

jprince

http://www.therationaledge.com/content/jul_01/f_javaEnhancements_ja.html

jprince

Copyright Rational Software 2001

What this strategy parses down to, Greenfield added, is providing "much tighter integration with the IDE than what people have seen from us before. In the past, we've had a number of point products assembled by the acquisition of a number of companies. The Rational Suite has been the mechanism to build tighter integration. We're now doing that around the Rose core."

Another long-term goal for Rational is to help raise the level of abstraction for developers, to isolate them as much as possible from having to know low-level details about how the underlying hardware and software works. Rational is already doing this, to a great extent, within Rose and its other tools by providing automation and other ways to let developers concentrate on the business logic instead of the details. (See Figure 1.)

Figure 1: Rose J Project Specification Screen. Rose J allows customers to concentrate on the actual application features and leave the Rose tool to worry

about small details. The forward engineering aspect is customizable, so customers can tailor the code

generation to the specific needs of their projects.

The company is moving to help Java developers -- indeed, developers using any of its tools -- to create software by using high-level business terms and definitions whenever possible.

Rational Suite Java Enhancements: Toward a Seamless Experience

Nowhere are these goals more apparent than in the Java space. Over the past several weeks, Rational has announced additional support within existing products -- including its Rational Rose modeling tool and Rational Suite -- integrations between its tools and leading integrated development

environments (IDEs), and agreements to develop new tools specifically geared to Java:

■ In v2001A of Rational Suite, enhanced Java development features support industry-leading IDEs from IBM, Sun, BEA, and Borland.

■ Rational Rose RealTime now supports the Java 2 Micro Edition (J2ME) platform and the Mobile Information Device Profile.

■ jRoundup.com, Rational's new online Java technology community, is already up and running.

■ Rational and Sun are developing the industry's first end-to-end lifecycle development solution for Java and Solaris as well as a standard to define mapping between Enterprise JavaBeans (EJBs) and the Unified Modeling Language (UML).

Rational's new Java IDE support includes integrations between Rational tools and IBM's VisualAge for Java, Borland JBuilder, Sun Forte for Java, and WebGain Visual Café. Developers can now have their favorite editor, debugger, and lifecycle tools all in the same place, thanks to the new integrations. They can also work in their IDE of choice and reverse-engineer code changes directly from that IDE into the Rose model, so the model and the code always stay in sync.

In addition, this means that Java teams can now communicate visually, sharing information through one language -- the UML -- and one tool, Rational Rose. Developers can also design their database for high-performing Java applications.

And this level of integration will only get better, Rational's Taylor said. "Our direction is to continue to work closely with leading IDE vendors in the market, to provide a seamless experience for the customer." For an example of how Rational's tools are integrated with partners' IDEs, see Figure 2.

Click here for enlarged view

Figure 2: Main Window of Sun Forte for Java, with Rational ClearCase Toolbar.

Specific Java-related enhancements to Rational Suite v2001A also include ease-of-use features that speed development. With the new Java design-pattern support, for example, developers can now use wizards to more easily create software that uses Java 2 Enterprise Edition (J2EE) technologies like Enterprise JavaBeans (EJBs), Servlets, and Java Server Pages (JSPs).

These new capabilities allow developers to step through the design and coding process much more quickly, with menu-driven access to selected

patterns that can be added to any visual model. They can stay focused on high-level design and coding, leaving low-level details for the tool to handle. Enterprise JavaBeans (EJB) and Servlet graphical user interfaces, too, are much easier to use, with easy navigation and selection of EJB versions 2.0 or 1.1, among other features.

In addition to these powerful new Java features, the Rational Suite offerings include enhancements to Rational Suite ContentStudio that expand the operating environment for Web developers: Now, customers can script JSP templates as well as ASP templates. They can also choose from a larger variety of J2EE application server platforms and can operate on the Solaris platform as well as on Windows NT.

"Our strategy is to give a Web development team that is using Java for their Web site everything they need to go from development to deployment -- and they can do that now," said Rachael Rusting, Group Product Marketing Manager for Rational Suite ContentStudio. "It supports building any Java application that someone would want." Prior to this release, ContentStudio, did not offer Java support.

J2ME Real-Time Development: Doing It with Rose

Rational's recent announcements on the real-time front reflect the fact that, with the recent addition of Rational Test RealTime, the real-time, embedded, and distributed market has become a strong and growing focus for Rational's new product development and integration efforts.

The goal here is two-fold: to continue to improve the tools given to developers in the embedded systems community, and to spread the technology within Rational's embedded solution into other market segments.

So say Marc Brown, Marketing Evangelist for Wireless and Embedded Solutions at Rational, and Andrew Lyons, Senior Product Manager for Wireless and Embedded Solutions at Rational.

Rational Rose RealTime can automatically generate up to 80 percent of an application's code and create the necessary test harnesses and stubs required for validation, directly from UML models. Part of this is due to the technology within Rose RealTime and Test RealTime, and part is because of the tight integration between Rose RealTime and the UML.

The idea is to spread that capability to as many markets as is feasible, Lyons said. "There are many applications that could benefit from this technology," he explained, "where we can add a lot of value to the development process by elimination of the many design errors that are so prevalent in today's software development efforts."

To take Rose RealTime into different markets, "the integrations you need are different," Brown said. "It's like drilling for oil instead of drilling a tooth at the dentist. All are drills, but they're different. We're going to take common pieces of the solution and integrate it with various market-specific attributes to provide the technology to the mass market."

The idea is that the same tools and technologies that help developers write real-time systems may also be applicable, say, to building business applications and user interfaces that have internal state and that must react to events under changing conditions.

The company is also aiming to develop more Java frameworks, or profiles, to help developers come up to speed more quickly in the real-time space. This is why Rational worked with Sun Microsystems to add J2ME and Mobile Information Device Profile support to Rational Rose RealTime.

Rose RealTime also now supports Java device developers using Sun's J2ME platform, and significantly speeds development by automatically generating complete Java executables directly from UML designs.

Another new push is to provide Rational real-time tools for the Solaris Operating Environment. One of these is Rational Test RealTime, which automates the testing of embedded, real-time, and distributed applications. This new Rational product manages the tedious and error-prone aspects of implementing, deploying, and executing an embedded test environment. It addresses all test levels, from individual software and UML model components to overall system testing -- including unit, integration, and validation testing -- on various host environments and for any embedded target.

Rounding Up a Java Community

Another piece of Rational's commitment to Java developers can be found online, at a new site called jRoundup.com, which includes one of the largest collections of vendor-neutral Java information on the Web. Hosted and created by Rational, the site features content from experts at BEA, Borland, Sun, and IBM, among others.

"We intend jRoundup to become a favorite resource for the global community of Java developers," said Rational's Greenfield. "Rational and other industry leaders are engaging the Java community as a whole by providing information, content, and discussion relevant to the day-to-day work of Java developers."

The site features several thousand downloadable, and free, applets, servlets, and beans, as well as hundreds of articles. There are short Java tips, in-depth features, information about books, useful links and much more. jRoundup also provides a community and gathering place for software development professionals, including threaded discussion groups and other resources. Customers can submit their own articles and tips for publication.

Lifecycle Support for Solaris

Rational and Sun are also working to deliver a set of e-development tools for customers writing to the Solaris Operating Environment (OE), helping speed time to deployment. In combination, these Rational products and Sun tools and technologies provide developers writing for the Solaris OE

with the first single, unified development environment that supports the full range of Solaris and Java products, including Java2 Platform, Standard Edition (J2SE), J2EE, and J2ME.

With this environment, developers can build on the platform they are using to deploy their software, thereby avoiding the cost of additional testing and transition time. The intent is to help developers speed Java-based applications to market, improve software quality, and reduce total cost of ownership.

The Rational portion of the toolkit includes Rational Suite Development Studio, which features Rational Rose for modeling and Rational ClearCase and Rational ClearQuest for change management and defect tracking, respectively. Also part of the solution for Solaris is Rational Test RealTime, which automates testing of embedded, real-time, and distributed applications.

Models for Java

To help make models available for the Java community, Rational and the Java Community Process recently announced Java Specification Request 26 (JSR-26). It defines a standard mapping between the architecture of Enterprise JavaBeans (EJB) and the Unified Modeling Language (UML). This mapping is called the UML Profile for EJB.

This standard will allow tools from multiple vendors to work together by using a common format for the transfer of models. It sets a standard for how EJBs are modeled and represented in the UML.

"This is a start," said Rational's Greenfield. "We will develop modeling specifications for the entire J2EE platform. This enables us to tailor the models that people build to the target platforms."

"JSR-26 is the way to model a platform-specific design for using EJB. We're also developing mappings between the platform-specific models and the high-level, platform-independent models," Greenfield said.

"We're bringing the tools close to where the developer lives, integrating with the IDE, and then using model-driven development methods to automate engineering tasks," Greenfield said. "This is the basis for our entry into the Java space. We're automating the design, construction, and deployment of J2EE artifacts using JSR-26."

Strategic Partnerships Are Key

No company can go it alone, especially these days -- and Rational is working with four of the leading Java suppliers in the industry to make sure its products and technologies are best-in-class and that the products really work with each other on a deep and meaningful level. It would be impossible to reach this level of integration with the popular IDEs unless Rational were working closely with the owners of the IDEs. Consequently, without these partnerships it would also be impossible to reach Rational's end-goals of raising the level of development abstraction for the industry

as a whole.

IBM

From IBM's perspective, the relationship with Rational spans three business concerns -- marketing, technology, and sales, said Adrian Mitu, Marketing Manager for WebSphere application development tools at IBM. "The first thing we did was to enable forward- and reverse-engineering from Rose into VisualAge for Java."

When that integration "met with quite a bit of success in the market," both companies decided to "look more closely at what is do-able in this area. We ended up creating a relationship," he explained. As part of that relationship, IBM will embed ClearCase LT in future versions of the VisualAge for Java product, Mitu said.

The two companies are also working together on using the Rational Unified Process (RUP) for WebSphere. From IBM's Web site, customers can download a guide on how to develop WebSphere applications using the RUP, according to Mitu.

"The Java community has asked for a couple of things from our Java tools," he explained. "One was support for modeling tools. One of the most important requirements was to support application modeling tools. So, how do you model an application and then start to develop it in Java? And, after you make some modifications, how do you later rework it to an application model? That same argument also extends to data modeling. As you develop the Java application, how do you derive the data models needed to support the running application and have the proper database? These are issues that VisualAge for Java can now address much better because of the integration with Rational Rose."

IBM is also looking into integrations with Rational testing tools. As Java becomes more mainstream, Mitu said, "it's critical to have Java projects managed with the rest of the enterprise. We're improving that by providing better support for external software configuration management systems such as Rational ClearCase. The next frontier is testing: How do you line up integration and system testing in the lifecycle for Java tools? That's currently in the works." Other aspects of testing that IBM is interested in exploring with Rational include stress and performance testing, he said.

"From our perspective, Rational is a solid choice when it comes to end-to-end application development lifecycle support," Mitu said, "from modeling and SCM to testing. They've got all the infrastructure needed for high-quality software development."

Sun

For Sun, "the pieces that Rational helps us fill out are at the front end and back end of the development environment," said Scott Clinton, Group Manager of Software Development at Sun Microsystems. "Things like defining requirements for applications, requirements management, and

modeling tools." Rational tools help Sun's Java customers on both sides of the equation -- in the development process as well as "to validate that the applications are working well. You need to meet the performance requirements of customers," he added.

At this point, mostly what Rational and Sun have "talked about publicly is the integrations" of the tools, Clinton said. In other words, Sun is broadening its IDE and other software to include more Rational solutions, and Rational is extending some of its individual tools, as well as its Rational Suite, to embrace the Solaris OE and Sun's Forte for Java IDE. The two firms are also collaborating on standards for those integrations.

Rational's tools are key now, "especially as Java moves from early adopter to mainstream" in Corporate America, Clinton said. "We need to have more mature tools to help build those Java applications as they become larger and more complex. Process becomes more important because you have larger teams, so you need to leverage the process to make development more efficient. And you need to manage the code and content being delivered."

That said, however, Clinton added, "When you're working with partners, the opportunities are open. Never say never, right?"

Borland

The primary work here to date has been to integrate Rational Rose into Borland's Enterprise Studio, Java Edition. Borland also bundles the RUP into its suite.

"Rational Rose provides visual design and modeling capabilities for the Borland customer, and RUP delivers a set of software best practices," said John Carroll, Business Development Manager at Rational. The intent is to launch "other facets" of the relationship in areas outside of this, but these announcements haven't yet been made, he added.

BEA

At BEA, the focus is on making sure that Rational's modeling products are working "seamlessly" with the WebLogic Server solution, said Kempton Izuno, Global Alliance Manager for BEA. There has also been a lot of interest, particularly from larger customers and systems integrators, in the endorsement of RUP for J2EE, he added.

Nor will the relationship stop here, Izuno said. "As BEA extends its products, we can see further work with Rational in terms of product integration, interoperability, and field co-marketing."

That Rational is addressing the Java market is "fantastic," Izuno said. "Clearly, a lot of companies have endorsed the Rational approach to developing software, which is language- and platform-independent. This brings Rational's proven methodology to the Java platform."

Online Resources: Rational Java Products and Strategy

Product Information

http://www.rational.com/products/rs/wn_2001a.jsp -- A quick overview of new Java features in Rational Suite v2001a http://www.rational.com/.../800-024650-000_may032001.pdf -- A detailed overview of Rational Suite v2001a's new features ( 66-page .PDF file) http://www.rational.com/products/dstudio_rt/wn_2001a.jsp -- Rational Suite DevelopmentStudio RealTime v2001A's new features, including those related to Java http://www.rational.com/products/rosert/wn_roseRTv2001a.jsp -- What's new in Rational Rose v2001A

Whitepapers

http://www.rational.com/.../rose/java_whitepaper.pdf - "Enterprise Java and Rational Rose:A Rational Whitepaper" http://www.rational.com/products/whitepapers/340.jsp - "Large-Scale Development of Java and C/C++ Applications with Rational Apex"

Community

http://www.jroundup.com/ - One of the largest collections of vendor-neutral Java information on the Web, including thousands of downloadable applets, servlets, and beans, plus hundreds of articles.

News

http://www.rational.com/news/javaone/index.jsp - Rational's news room, including all the recent product and partner announcements

Rational's Java partners

http://www.rational.com/media/partners/sun/Sun_DS.pdf - Rational and Sun alliance (four-page .PDF file) .http://www.rational.com/news/press/pr_view.jsp?ID=8084 - Borland expands e-business development platform. http://www.rational.com/partners/alliances/compaq/faq.jsp - IBM and Rational Software - Accelerating e-business, Alliance Question and Answer .http://www.ibm.com/software/.../support/rup.html - How to develop IBM WebSphere applications using the RUP.

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 2001 | Privacy/Legal Information

Improving Software Development EconomicsPart IV: Accelerating Culture Change Through Common Sense

by Walker RoyceVice President and General ManagerStrategic ServicesRational Software

This is the fourth and final installment of a four-part series of articles that summarize our experience and discuss the key approaches that have enabled our customers to make substantial improvements in their software development economics. In the first article, I presented a framework for reasoning about economic impacts and introduced four approaches to improvement:

1. Reduce the size or complexity of what needs to be developed.

2. Improve the development process.

3. Use more proficient teams.

4. Use integrated tools that exploit more automation.

In the second and third articles, I discussed the discriminating techniques that have succeeded for organizations that have achieved quantum leaps

jprince

http://www.therationaledge.com/content/jul_01/f_sdev4_wr.html

in software capability. In this final article, I discuss some of our key observations in collaborating first-hand with leading software development organizations and some of the patterns of success for transitioning project teams to these new techniques, methods, and processes.

Improvements in the economics of software development have been not only difficult to achieve, but also difficult to measure and substantiate. In software textbooks, trade journals, and product literature, discussions of this topic are plagued by inconsistent jargon, inconsistent units of measure, disagreement among experts, and unending hyperbole. If we examine any one aspect of improving software economics, we end up with fairly narrow conclusions and a limited value observation. Similarly, if an organization focuses too much on improving only one aspect of its software development process, it will not realize any significant economic improvement, even though it may improve this one aspect spectacularly. The key to substantial improvement is a balanced attack across each of the four interrelated dimensions listed above.

In the software marketplace, the track record has been that three out of four projects don't succeed. Project managers and organizations tend to "play defense," which typically results in an over-emphasis on risk management. In Rational's experience, the organizations that have truly achieved a quantum leap in improving their software economics are the ones that have demonstrated judicious risk management and savvy success management by playing offense, attacking each of the four dimensions aggressively.

Profiles of Successful Organizations

Figure 1 illustrates the target project profiles that result when a software organization attacks all four dimensions of our simplified software economics framework. These organizations execute projects with a profile similar to that of the upper shaded region using a modern iterative process, capable teams supported by an integrated environment, and a component-based architecture that reduces the complexity of custom development through the use of an architectural pattern with a rich supply of existing components.

Figure 1: Target Project Profiles for OrganizationsPursuing Improvements Along Four Dimensions

Today, roughly 60 percent of the industry still operates according to the conventional project profile. About 30 percent has transitioned to the modern project profile. Less than 10 percent is already achieving improved software economics and experiencing results similar to the target project profile. Organizations that have succeeded are deploying software products that are constructed largely out of existing components in 50 percent less time, with 50 percent less development resources, maintained by teams 50 percent the size of those required by legacy systems.

In making the transition to new techniques and technologies, there is always apprehension and concern about failing. Maintaining the status quo and relying on existing methods is usually considered the safest path. In the software industry, however, where most organizations succeed on only a small percentage of their software projects, maintaining the status quo is not always safe. When an organization does decide to make a transition, two pieces of conventional wisdom are usually offered both by internal champions and by external change agents: (1) Pioneer any new techniques on a small pilot program; (2) Be prepared to spend more resources (money and time) on your first project that makes the transition. In our experience, both recommendations are counterproductive. The organizations that succeed take the opposite approach: They implement the changes on a business-critical project, and they explicitly plan to demonstrate the business improvements (in resources or time required) on that first critical project.

Keys to Success

Why does the bold approach succeed? Our experience shows that meaningful organizational change depends on A-players and committed middle-level managers. A-players are typically assigned to the front lines, working on business-critical projects. These are the projects that will have the most impact on near-term business. Most organizations cannot afford to assign A-players to non-critical pilot projects.

Middle-level managers are important because they lay out resource plans and schedules. When they propose to improve a process by making a change, and then sell their proposal by giving the change initiative as the reason, it is a sure sign that these leaders (and their teams) believe that a new method, process, technique, or tool will make a difference. On the other hand, if a manager accountable for performance proposes that a project will take more time or need more people because of a new approach, this is usually a sign that the project is incorporating a change that the manager and team only half-heartedly support. The change may have been mandated, or it may have come about because of some line of reasoning the team has not completely bought into. The first team, which believes that a certain change will achieve better results, will usually do whatever it takes to make that claim come true. Ownership by the right people is the key to success. Look for it.

Successful software management is hard work. Technical breakthroughs, process breakthroughs, and new tools will make it easier, but management discipline will continue to be the crux of software project success. New technological advances will be accompanied by new

opportunities for software applications, new dimensions of complexity, new avenues of automation, and new customers with different priorities. Accommodating these changes will perturb many of our ingrained software management values and priorities. However, striking a balance among requirements, designs, and plans will remain the underlying objective of future software management endeavors, just as it is today.

Improving software economics is not revolutionary; numerous projects have been practicing some of these techniques for years. However, many of the disciplines suggested here will require non-trivial paradigm shifts. It is important to be prepared for these shifts in order to avoid as many sources of friction as possible. Some of these changes will be resisted by certain stakeholders or by certain contingencies within a project or organization. This resistance must be overcome to transition successfully to a modern software management process and supporting methods and tools. In some cases, distinguishing objective opposition from stubborn resistance will present a challenge.

The following paragraphs discuss some rough indicators of a successful transition to a modern culture focused on improved software business performance. These are things to look for in order to differentiate projects and organizations that have made a genuine cultural transition from those that have only put up a facade.

Lower and Middle Level Managers Are the Key Performers

Hands-on management skills vary, but competent first-line managers typically spend much of their time performing, especially focused on understanding the status of the project first-hand and developing plans and estimates. Above all, the person managing an effort ought to plan it. This does not mean approving the plan; it means participating in its development. In independent project assessments we have performed, a good indicator of trouble ahead is a manager who did not author the plan or take ownership in it. The stakeholders affected by this transition are software project managers and team leaders.

Requirements, Designs, and Plans Are Fluid and Tangible

The conventional software development process focused too much on producing documents that attempted to describe the software product and too little on producing tangible increments of the products themselves. Major milestones were defined solely in terms of specific documents. Development organizations were driven to produce tons of paper to meet milestones rather than expend their energy on tasks that would reduce risk and produce quality software. An iterative process requires actual construction of a sequence of progressively more complete systems that demonstrate the architecture, enable objective requirements negotiations, validate the technical approach, and address resolution of key risks. Ideally, all stakeholders will focus on these real milestones, with incremental deliveries of useful functionality and commensurate increases in objective understanding of the tradeoffs among requirements, designs,

and plans rather than speculative paper descriptions of the end-item vision. The transition to a less document-driven environment will be embraced by the engineering teams; it will probably be resisted by traditional product and project monitors.

Ambitious Demonstrations Are Encouraged

The purpose of early lifecycle demonstrations is to expose design flaws, not to put up a facade. Stakeholders should not overreact to early mistakes, digressions, or immature designs. Evaluation criteria in early release plans are coarse goals, not requirements. If early engineering obstacles are over-emphasized, development organizations will set up future iterations to be less ambitious. On the other hand, stakeholders should not tolerate lack of follow-through in resolving issues. If negative trends are not addressed with vigor, they can cause serious perturbations later on. Open and attentive follow-through is necessary to resolve issues. The management team is most likely to resist these demonstrations (especially if the project was oversold) because they will expose any engineering or process issues that were easy to hide using the conventional process. Customers, users, and the engineering team will embrace them for exactly the same reason.

Good and Bad Project Performance Is Much More Obvious Earlier in the Lifecycle

In an iterative development, success breeds success; early failures are extremely risky to turn around. Real-world project experience has shown time and again that it is the early phases that make or break a project. It is therefore of paramount importance to have absolutely the right start-up team for the early planning and architecture activities. If these early phases are done right with good teams, projects can be completed successfully with nominal teams evolving the applications into the final product. If the planning and architecture phases are not performed adequately, however, all the expert programmers and testers in the world will probably not make the project successful. No one should resist early staffing with the right team. Most organizations, however, have scarce resources for early lifecycle roles and are hesitant to make the necessary staff allocations.

Early Iterations Will Be Immature

External stakeholders, including customers and users, cannot expect initial deliveries to perform up to specification, to be complete, to be fully reliable, or to have end-target levels of quality or performance. On the other hand, development organizations must be held accountable for, and demonstrate, tangible improvements and positive trends in successive increments. These trends usually indicate convergence toward specifications. Objectively quantifying changes, fixes, and upgrades will help all stakeholders evaluate the quality of the process and environment for future activities. Objective insight into performance issues occurs early in the lifecycle in almost every successful project. This is a sign of an immature design but a mature design process. All stakeholders will initially be concerned over early performance issues. Development engineers will

embrace the emphasis on early demonstrations and the ability to assess and evaluate performance tradeoffs in subsequent releases. Although customers and users may have difficulty accepting the flaws of early releases, they should be impressed by later increments. The development team will accept immaturity as a natural part of the process.

Detailed and Complete Artifacts Are Less Important Early, More Important Later

It is a waste of time to worry about the details (traceability, thoroughness, and completeness) of the artifact sets until a baseline is achieved that is useful enough and stable enough to warrant time-consuming analyses of these quality factors. Project leaders should avoid squandering early engineering cycles and precious resources on adding content and quality precision to artifacts that may quickly become obsolete. Although the development team will embrace the transition to this approach wholeheartedly, traditional contract monitors will resist the early de-emphasis on completeness.

Real Issues Surface and Get Resolved Systematically

Successful projects recognize that requirements and designs evolve together through a process of continuous negotiation, tradeoff, and bartering toward best value; they do not blindly adhere to some ambiguous contract clause or requirements statement. On a healthy project that is making progress, it should be easy to differentiate between real and apparent issues.

Quality Assurance Is Everyone's Job, Not a Separate Discipline

Many organizations have a separate group called Quality Assurance. We are generally against the concept of separate quality assurance activities, teams, or artifacts. Quality assurance should be woven into every role, every activity, and every artifact. True quality assurance is measured by tangible progress and objective data, not by checklists, meetings, and inspections. The software project manager or delegate should assume the role of ensuring that quality assurance is properly woven into the process. The traditional policing by a separate team of inspectors should be replaced by the self-policing teamwork of an organization with a mature process, common objectives, and common incentives. Traditional managers and quality assurance personnel will resist this transition, but engineering teams will embrace it.

Investments in Automation Are Viewed as Necessary

Because iterative development projects require extensive automation, it is important not to under-invest in the capital environment. It is also important for stakeholders to acquire an integrated environment that permits efficient participation in an iterative development. Without this, interactions with the development organization will degenerate to paper exchanges and many of the issues of the traditional process. These

investments may be opposed by organization managers overly focused on near-term financial results or project personnel who favor a narrow project focus over a global solution that serves both the project and the organization's goals.

Recommendation: Select the Right Project, the Right People, and the Right Goals

In our experience, the most successful organizational paradigm shifts resulted from similar sets of circumstances. Organizations took their most critical project and highest caliber personnel, gave them adequate resources, and demanded better results. If an organization expects a new method, tool, or technology to have an adverse impact on the results of the trailblazing project, that expectation is almost certain to come true. Why? Because no organization manager would knowingly cause an adverse impact on the most important projects in an organization, to which the best people are assigned. Therefore, the trailblazing project will be a non-critical project, staffed with non-critical personnel of whom less is expected. The expectation of an adverse impact ends up being a self-fulfilling prophecy.

The best way to transition to improved software economics is to take the following shot:

Ready: Understand modern processes, approaches, and technologies. Define (or improve, or optimize) your process to support iterative development in the context of your business priorities. Support the process with mature environments, tools, architectural patterns, and components.

Aim: Select a project critical to the organization's business. Staff it with the right team of complementary resources.

Fire: Execute the organizational and project-level plans with vigor and follow-through.

In this series of articles, we have presented key lessons about improving software economics that we have learned through twenty years of working, in the trenches, with thousands of customers. When all the buzzwords and cosmetics are stripped away, most of our advice boils down to simple (un)common sense.


Bridging the Chasm Between Strategy and Execution

by Sid FuchsDirector of Professional ServicesStrategic Services OrganizationRational Software

Have you ever seen the commercial that depicts consultants briefing a customer, and the customer responds that he wants them to begin delivering on their proposed solution immediately? The consultants, with puzzled looks on their faces, tell the customer that they don't deliver solutions; they only talk about them. He'll have to get another company, they explain, to actually do the work. This commercial is about the chasm between strategy and execution. So is this article, but I'll try to dig into the topic a little deeper.

Traditionally, managers view the world as divided into two groups of people, positioned on opposite sides of that chasm: those who can think strategically and come up with new concepts, and those who can implement others' ideas. Managers recognize that both types are necessary, and that without the other, neither group would be of much value to a results-oriented organization.

Often, however, managers cannot figure out how to get these two groups working together effectively. And this gap severely limits a company's ability to make changes and deliver results based on a mission or strategy. We've seen it time and time again: the charismatic CEO who is a great communicator, a visionary, a leader in all respects, but who has an organization rife with operating problems, miscommunication, and an inability to respond to competitive pressures. On the flip side, we've

jprince

http://www.therationaledge.com/content/jul_01/m_crossingChasm_sf.html

probably all worked with people who can focus on the tasks at hand but have trouble seeing the big picture. The problems multiply if a company's mission or corporate strategy is continually changing -- one day it's client/server, next day e-business, then applications, networked computers, and so on. In an environment like that, with continually changing corporate messages and strategies, productivity comes to a halt unless you have people with both conceptual and practical qualities.

Of course, that's the environment we find in many small high-tech firms today. These companies need people who can think strategically, then go out and get it done. In these settings, the days of specialists who are deep into a single area are fading, as pressures to deliver results with smaller teams in a shortened time frame are becoming the standard. Small high-tech firms need everyone on the team to be both thinkers and doers, able to help define the path or plan, then execute and deliver results against that plan. In larger, more traditional companies, however, where people are more sharply divided into strategists and executors, the key for managers is still to figure out how to get these people working together seamlessly.

Engineers vs. Scientists - Why Both Are Needed

A classic and time-honored example of the great divide we have been discussing is the professional battle between scientists (abstract thinkers) and engineers (builders). As I worked my way through college to earn my BS and MS in Engineering, it was clear that engineers believed the physics and chemistry students were off creating stuff that no one would ever use. We in the engineering profession, however, were building things that would benefit mankind and change the course of the world as we knew it! The scientists and the engineers each believed that their problems were more difficult and more important than those of our counterparts on the other side. However, looking back on this situation, it's apparent that without the scientists who help create and discover new technologies, engineers would be hard pressed to solve many of the problems challenging them today.

Design, chemicals, materials, and other areas that capture the focus of the scientific community play a key part in the engineering field. Of course, if engineers were not able to take the results and products of the scientific community and put them to good use, then there would not be much point for a scientist to work hard at discovering the complex chemical compound that solves a medical mystery, for example. The point is that it takes both vision and strategy and execution and implementation to make the world go round.

Bridging the Chasm

So how do you develop the ability to move from strategy to execution within a business environment? This is my specialty. The charter of the Strategic Services Organization at Rational Software is not only to help customers plan and strategize their software development deployments, but also to assist in delivering against these plans. Unfortunately, I don't have a single recipe for success, but below are some practices and

techniques that I recommend.

Combine the Tactical (the How) with the Strategic (the What)

In most planning sessions I have attended, the majority -- if not all -- of the participants think of themselves as strategists. What happens at many of these meetings is similar to sitting down and drawing up plans for your dream house without consulting a contractor. You may devise the most elaborate, modern, attractive home, but what about reality? When you deliver your plans to the contractor, you may find it is going to cost twice as much and take three times as long as you thought, and that some of your plans are not achievable.

When holding a planning session, it is important to have tacticians as well as strategists in attendance. This will keep the outcome of this meeting -- the plan for moving forward -- reality based and improve its chances for success. It is also important to understand that a second-order mission for the strategists is to push the tacticians' envelope and not take "no" for an answer until all parties agree that what has been proposed cannot be done. Challenging the tacticians to develop new and innovative ways of approaching projects will only improve the organization's capability and performance.

Start with the End in Mind and Think Like a Chess Player

When setting out to plot strategy or devise a plan, start by thinking about the results that you want to accomplish. Too often we put plans in place that don't allow us to get from point A to point B. The results should be realistic and achievable, and they should be associated with a quantifiable metric. Creating a vague, overly broad goal to improve performance, for example, doesn't give you much to go on and is almost impossible to execute against.

In addition, never confuse activity with results. This simple phrase makes a powerful statement. How many times have we done something without any awareness of what the results would be, or whether there would even be results? Every activity should end in a clearly stated result, whether it be a deliverable or a control gate to the next activity. Once you understand what results are needed, it will become clear what steps you must plan to achieve them.

In projects that lack clearly defined goals, there may be a high level of activity, but not all of it leads to achieving the goals. This "Brownian Motion," 1 as I call it, wastes resources and adds little value to organizations focused on achieving goals.

It's also important to think strategically as you move through a project. Chess players approach the game not only by thinking about their current move, but also by simultaneously considering future moves, based on their opponents' options. The same approach is optimum in business: Anticipating reactions is a key to keeping your plan on track and reducing

the time it takes to analyze your implementation. Experience and careful observation are key ingredients in being able to do this effectively; both people and organizations do, over time, follow patterns in the way they respond to events.

Leverage Your Team's Talents and Assign Responsibilities

When staffing your team or company, make sure you have a healthy mix of strategists and implementers. It is important for management to understand which people fit in which category and also to identify players who perform well in both categories. To use a football analogy, if you are going to execute a pass, you don't want your fullback going down field instead of your receiver. Maintain a balanced mix of talent on your team and use people appropriately. Not only will you get better results; your team members will also feel a greater sense of accomplishment if they are operating in areas in which they can excel.

In addition to identifying the tasks required to execute against the plan, it is just as important to tie people's names to the task and hold them accountable. Don't assign an action item to a group: If you do this, you won't know who is responsible. Instead, assign it to an individual and establish a delivery date, what is to be delivered, and the criteria for success.

As in a software development project, each person on the team should have a specific role: analyst, tester, developer, project manager. Process tools like the Rational Unified Process (RUP) can assist with identifying not only tasks, but also which role should be responsible for these tasks, including inputs and outputs required to achieve success.

Plan and Work in Increments

Nothing can slow down a solid start out of the gate like taking on too much at one time. It's the proverbial "trying to put a river in a coke bottle" that overwhelms people and results in teams not having a clear picture of where to start. Starting with a high level of abstraction in order to understand the big picture and establish success criteria is great, but eventually, you will have to break down this high-level view into manageable chunks that each contribute to meeting the goals. When identifying these tasks, make sure to establish control gates with checkpoints to help determine progress and whether goals have been met.

How does one do this? Take advantage of your team's experience and brainstorm with them. It's important not only to define the tasks, but also to define the ones that make the most sense and can actually be performed, given your particular constraints and demands. Brainstorming with your team is a "force multiplier" that can provide checks and balances, as well as innovative ways of solving a problem. It also provides the team with a sense of ownership that will help drive the project in the right direction.

Get Everyone on the Same Page

No matter how good the message or how good the plan, if everyone on your team is not pulling in the same direction, then failure will occur. Moving from strategy to execution means enabling everyone on the team to understand where the team is going and what each person's roles and responsibilities are. To use another football analogy, the playbook is the plan, but the team can only win if everyone can perform all the tasks that lead to a well-defined result: first down, touch down, etc. Football practice, for me at least, was a constant learning process with respect to both communication and refining techniques.

Both at the start of the implementation and throughout, communication is key. Never underestimate how easy it is for teams to fall a little off track if inter- and intra-team communication is lacking. I find that most of the obstacles our clients encounter, whether technical, interpersonal, or business-related, can be overcome if people just talk to each other. It's human nature to assume the worst when a problem arises, but I have found that worst-case scenarios rarely play out. Most problems can be resolved, especially if the team understands the situation and what needs to be done.

Avoid Changes in Strategy for the Wrong Reasons

How many times have we seen a company's corporate message change dramatically but not necessarily for the better? This "flavor of the month" syndrome creates a very difficult environment for teamwork and often leads to poor results and frustration. I'm not saying that strategy should never change (it must, if a company is going to stay competitive in today's world), but the reason for change needs to be sound. Is the company impulsively playing defense or "catch up" and reacting to a competitor or a market trend? Or is the company making wise changes because of core competencies, new technologies, or acquisitions? Organizations that make frequent strategic changes for defensive reasons probably don't have a firm understanding of their mission, the market, and their competencies to begin with.

Learning From Experience

As you gain more experience in your field of expertise, it should become easier to bridge the gap between strategy and implementation. Each time you execute against a plan, you are building a knowledge base from which to draw from the next time you are faced with a similar challenge. It is also important to understand the value of the role that each person plays in the organization and to make sure the organization is well balanced with a healthy mix of thinkers and doers. In an ideal scenario, everyone would be able to do both, but that is rarely the case in real life.

1 The BBC's "Science Shack" editor, Adam Hart-Davis, (http://www.bbc.co.uk/science/scienceshack/) explains Brownian motion as follows: "Brownian motion is caused by the bumper car like tendency of molecules to crash into each other. … molecules in a liquid or a gas are constantly moving around, jostling and bumping each other. Put a small particle into this environment and the chances are that, at any one point in time, it will be hit more on one side than another. The extra hits on this side have the effect of jettisoning the particle off in the opposite direction.

"The effect was first seen by Robert Brown in 1827. He saw through his microscope that tiny pollen grains floating in water were constantly jigging about. At the time no one knew about molecules so Brown assumed the pollen grains must be alive. It wasn't till 50 years later that Einstein proved this movement was due to the constant bombardment of the pollen grain by water molecules."



Requirements Management: Your Insurance Policy on Large-Scale Projects

by Dan GonosChief TechnologistElectronic Data Systems (EDS)

Most people think requirements definition starts after the contract is signed. But the bigger the project, the more important it is to begin defining and tracking requirements immediately upon getting involved with the project -- when you're evaluating the Request For Proposal (RFP). On projects for which development timeframes are measured in years, or even decades, the ability to track requirements is properly seen as a mission critical component of your business strategy, not just a first step in the software development lifecycle.

The Challenges of Big

It's a truism in the software business that the bigger the project, the later and further over budget it goes. One reason, surely, is that whatever requirements are submitted up front, even if they are comprehensive and well-defined, often tend to fade out of the picture as the job grinds on. Many of us have experienced first-hand how big projects frequently seem to lose their focus, especially when distributed teams are each working on their own bits and pieces. The reference point, especially for developers, tends to become "the last deliverable," not the ultimate goal as defined contractually. When this happens, business objectives, too, can gradually become unclear. And if you don't know where you're going, then where are you going to get to?

"Finding out when you get there" is not the way to make money and satisfy clients as a systems integrator or software consultant. You need to

jprince

http://www.therationaledge.com/content/jul_01/m_requirements_dg.html

know exactly where you're going, and you had better be able to point to the map once in a while. That's why it's absolutely essential to define requirements clearly, track them religiously, and stay focused on them steadfastly, before you even respond to that RFP.

When managed in a disciplined way, your project's requirements become a vital tool for maintaining communication among all participants, rolling with changes, adjusting schedules, and controlling costs. Leave requirements to chance, and your project will quickly drift off course.

My Project

I'm a Chief Technologist at EDS. We're a large company, and we take on some very big projects. But even by our standards, my project is truly immense. Basically, it entails building a new computing infrastructure from the ground up to support one of the largest social services environments in the US, encompassing eighteen California counties. When completed, our system will help these counties deliver public assistance programs like cash assistance, food stamps, and employment services benefits to more than three million clients. The system will be accessed by over 30,000 users, ranging from clerks to directors, at 700-plus geographically dispersed sites throughout the State of California.

Taking Requirements Seriously

Needless to say, this project entails custom software development on a level that's highly unusual -- even for EDS. But that's literally not the half of it. Each of those eighteen counties administers its programs separately, and has its own unique management practices. From the user's perspective, we will in effect build eighteen different implementations of a single system, each with its own set of requirements.

Now that's a major requirements management challenge. But it's not the only one on this project. Public policy changes that impact our system happen routinely at all levels of government in response to court cases and legislation; over the course of this project, that will necessitate thousands of changes to requirements.

Obviously, if we don't do a good job defining and managing requirements, this project might never get done! (How would we know when to stop?) But our motivation to pay attention to requirements goes much deeper than that. Our contract with the CalWIN Consortium, a consortium of 18 California counties, is fixed price. Therefore, if we build something that isn't what the client asked for, then we have to fix it on our nickel. For this reason alone, we would be serious about requirements management around here, I can assure you. We're also confident that we have the methodology, the tools, and the discipline it takes to make that kind of contractual obligation work for us.

Starting Smart

When EDS decided to bid on this project, we knew that effective requirements management would be pivotal to our success. We began

tracking requirements right from the RFP, both to enable us to identify high-risk or unclear requirements, and to give us a head start once we got the job. (And it probably didn't hurt our chances for the client to know we were already thinking proactively about project management.)

We chose Rational RequisitePro as our requirements management tool for several reasons: myself and other key staff were familiar with it and knew it could do the job; it's flexible enough to be adapted to our EDS project management methodology; and it can scale well enough to handle the deluge of requirements and users this project entails.

Starting with a Methodology

At EDS, every project starts with our company methodology: the project management processes that form the core of how we get the job done. We put these processes in place first, and then worry about implementing tools to facilitate them.

A business process methodology should always be the starting point for choosing and configuring project management tools -- not the other way around. You need to know what you want to do first, before you tell some tool to go do it for you. That means you need to select tools you can readily configure, so you can integrate them with how you plan to do things.

For example, our EDS methodology includes an explicit operational definition of what constitutes a requirement. To wit:

A requirement is a condition that must be met for the client to find our products or services acceptable.

The ideal set of requirements is solution-independent; that is, it is stated completely in terms of the client's business needs. This gives EDS the greatest flexibility to satisfy the requirements.

Our methodology also defines activities for managing requirements. These include:

● Planning for the requirements management process.

● Obtaining source information from which to derive requirements.

● Development of requirements.

● Validation of requirements.

● Incorporation of requirements into the requirements baseline.

● Evaluation and refinement of the requirements management process.

By following this methodology, we can manage requirements effectively. The benefit our client derives from our efforts is the receipt of a product or service that adds value to their organization. This results from a clear understanding of the client's needs and expectations. It also leads to fewer

product or service design and construction errors, thereby lowering or eliminating costs associated with rework. (This is critical because project estimation often does not factor in "rework time.")

In short: the effectiveness of your requirements management process is inversely proportional to the need for rework associated with faulty requirements, and directly proportional to the accuracy of your estimates pertaining to total lifecycle cost and schedule.

The Role of Tools

At EDS, our methodologies drive the project, and the tools we choose support our methodologies. Rational Requisite Pro turns out to be a good fit with how we need to manage requirements. Likewise, other Rational tools are a good match for our change and issue management procedures, and for the way we do modeling, planning, and testing. But again, we never think "automation first, process second." We focus on defining a solid change management process, a solid deliverables approval process, a solid software validation process, and so on. On different projects, different tools might be appropriate.

In the current stage of our project, we're tracking roughly 12,600 functional and technical requirements. By the time we're close to completion that number will be nearly 16,000. All of the 200-plus staff members on the project interact with the requirements management system in one way or another as part of their jobs.

After we put tools in place to support our business processes, we continuously strive for improvement by refining those processes and reconfiguring the tools. This is another reason why we invariably choose tools that are flexible and offer a comprehensive, easy-to-use feature set. One thing I like about ReqPro, for instance, is that it's simple to add and delete attributes as the project evolves. We do this frequently, because we strongly believe in incorporating lessons learned from previous phases of the project. If it's broke, fix it -- don't perpetuate foolishness!

The Value of Requirements Management

Since my project began 18 months ago we've hit every major project milestone. All our deliverables have been submitted and approved on time, and we're well within our budget.

Calculating a Return on Investment (ROI) to illustrate the value of our requirements management process wouldn't demonstrate its true worth to the project as a whole. And good requirements management is obviously not the only thing that's gotten us to this happy place. But our focus on requirements has been critical to our success in tremendously important ways. In particular:

● Requirements management facilitates the software lifecycle. Our close management of requirements is a form of "adult supervision" to help all developers on all

teams stay focused on business objectives from deliverable to deliverable. Whether they work for the client, EDS, or one of our subcontractors, our developers consider the client's requirements and the software design specifications together as they work. They have to, or they'd never hit the mark.

● Requirements management enables us to cope with both rapid and gradual changes over a long period of time. As I mentioned above, our requirements change constantly in response to court cases and legislation. Faithfully tracking and categorizing requirements enables us to much more easily identify the specific requirements that are impacted by a legislative maneuver. Otherwise, we'd be continually digging through the program specifications, or even the code! And that holds equally true for changes driven by our defects management process, through client feedback, new technical input, etc. Because we have requirements under control, we're much better equipped to efficiently and appropriately revise components in response to all forms of change. Which, I don't need to remind you, can make or break your bottom line on even the smallest project.

● Requirements management helps you relate deliverables to contractual obligations. On a behemoth project like mine, for which requirements change constantly and the development lifecycle will take approximately four and one-half years, our ability to track requirements relative to deliverables is paramount. We must specify precisely what requirements a deliverable will embody. That's how we can verify that we built what the client really asked for -- not what they thought they asked for, or what we thought they asked for. This allows us to cleanly settle issues of accountability should a dispute arise.

A Must for Project Management

I can only imagine (fortunately…) what my project would look like if we weren't focused on managing requirements. For one thing, we'd find it next to impossible to plan and determine the features of a deliverable, because we'd have no way to ascertain what the requirements were, or how they could be measured and quantified. And if we weren't able to communicate the latest requirements effectively to our development teams in the first place, then we'd find it much more difficult to manage the development cycle. Furthermore, if we weren't able to track test cases relative to the latest requirements, we'd never know whether we tested all the functionality. Without the ability to quickly ascertain the impact of a court case or legislative change, we'd waste countless person-days

creating functionality that might or might not meet the client's needs. Plus, without a valid set of requirements, there'd be no way to monitor and control "feature creep," so we'd likely miss delivery dates and run over budget. Who knows, we might never complete the job! In other words: No requirements management equals a project out of control.

Back to Basics

Another way to think about requirements management is that a shared understanding of requirements keeps the lines of communication open, so everyone can work together to build the system that best meets the client's objectives -- on time and within budget.

If, on the other hand, you overlook requirements management, the scope of your project will slowly transform itself, through lack of attention and guidance, into something the client didn't ask for. Hoping they won't notice, or that they'll like your ad lib better than the script, are risky bets.

As the Chief Technologist, I'm squarely in the line of fire if deliverables don't meet requirements and EDS has to start fixing things for free. That's why I view our requirements management as "life insurance." Because when it comes to requirements, why take unnecessary risks?



Interview

A Conversation with Detlev J. Hoch, Cyriac Roeding, Gert Purkert, Sandro K. Lindner, and Ralph Müller

Authors of Secrets of Software Success: Management Insights from 100 Software Firms Around the World*

In addition to a book review, this month The Rational Reader brings you a conversation with the team that investigated more than 100 global software companies and 450 top executives to write Secrets of Software Success. Published last year by Harvard Business School Press, the book is a study of what it takes to build a successful software business. If what the authors have to say inspires you to read their thorough analysis of the software industry's best practices in Secrets of Software Success, be sure to note Chapter 5:"Software Development: Completing a Mission Impossible," as well as a brief history of the software business in Appendix II.

How does your study differ from others that have been undertaken on the software industry?Our study covers the software industry as a global phenomenon, rather than just as a Silicon Valley offspring. While other books have closely looked at the success factors in individual firms like Microsoft, our study examines success factors for the industry at large. We traveled over two million miles around the world to conduct 450 interviews with top executives in 100 software firms, including both large companies like SAP, Oracle, and Andersen Consulting, and smaller and younger companies with high future potential such as Intershop and Broadvision. Another distinguishing aspect of our study is that it examined three separate industry segments: mass market product companies, enterprise solution firms, and professional services firms -- and delivers both quantitative data and qualitative insights on the key management practices that breed success in each of these areas. Our findings deliver both a powerful empirical confirmation of certain key management principles, and also reveal some counterintuitive findings about what it takes to win in this industry.

Do the management insights you've gleaned apply to industries outside of software as well?Absolutely. Beyond the obvious relevancy for CIOs of larger IT user organizations in many industries, the software industry holds a lot of important lessons for a wide range of other industries. In addition to the software executives we interviewed for our survey, we also talked to 50 top executives from ten different industries across the U.S. and Europe from the automobile, banking, insurance, retail, packaged goods,

jprince

http://www.therationaledge.com/content/jul_01/rr_interview_hbsp.html

entertainment, telecommunications, pharmaceuticals and biotechnology, and petroleum industries. All of these managers emphatically said the software industry served as an outstanding model for them, with insights highly transferable to their own businesses. As companies around the world become increasingly knowledge intensive, they will all find themselves facing similar challenges to those of the software industry.

One of the biggest requirements for success is great leadership -- yet you say few leaders can claim to have all the skills needed to lead a successful company in the software industry.To be sure, the number of visionaries in the software industry is impressive -- but many of today's start-up companies, and even the software giants, are not led by a single leader. Many companies we surveyed, from SAP to Oracle to Cambridge Technology Partners, are led by leadership teams. The fact is that the challenges for software leaders arising from the extreme pace and uncertainty in the industry are so diverse that it often takes more than one leader to tackle all the tasks, which range from risk-taking, preparing for uncertainty, setting and reaching extremely high goals, and building highly dynamic organizations, to creating a culture that attracts and retains talent.

Some of the success factors sound fairly obvious -- such as great leadership and the importance of retaining top people. What did your survey find that was different?It's easy for the casual observer to see the larger factors that have determined success. But what our survey revealed was that the secret of success in this industry often lies in the details -- including company facts and stories, which require a closer look to understand. For example, it is obvious that a company should properly train its partners. But the way, for example, that SAP set up its global Partner Academy -- an "institute of higher education" for training its partners in dozens of weeks-long courses, the first of its kind. That's a detail that illustrates how far successful companies can go in outperforming the average.

What do you mean when you say that success in the software industry depends on a very difficult balancing act?What we found in our survey was that success depends on simultaneously striking the balance within and between key management areas, from internal areas such as leadership, people management, and product development to external areas like marketing and partnering. In partnering activities, for example, software leaders must give away market share to partners to stimulate overall market growth while they simultaneously retain a healthy share for themselves to maintain short-term profitability. In software development, the challenge is to build high-quality products while keeping the time to market as short as possible. Leaders must also maintain the balance between key areas, such as marketing versus development. These areas hold different priorities depending on the kind of firm you lead -- and knowing which ones to focus on most closely is critical to success.

Did you find that success factors varied for software companies depending on region, economic environment, and culture?No -- in fact, whether the company was in the Silicon Valley in the United States, or Bombay, India, or Tel Aviv, Israel, or Munich, Germany -- the

key factors for success were basically the same around the globe. Where we did find substantial differences was across the three main industry segments: professional services, enterprise solutions, and mass-market products.

But don't these three segments share the same business dynamics -- low entry barriers, fast innovation, the threat from new entrants?While they do share common dynamics, our global survey also showed that the differences between software product and professional services businesses are quite substantial. For example, while product companies must monitor their market share in terms of copies sold, professional services firms must concentrate on their capacity utilization rate. Interestingly, we found the approaches differ not only within key management areas, like marketing, but even in the relative importance of the key management areas. While strategic and marketing issues are most critical to the overall success of product companies, superior human resource management and software engineering are most important in professional services.

What did your survey reveal about development processes? Do they dampen creativity, as many people believe?Our survey revealed exactly the opposite. The successful companies in our survey said that strict processes -- ranging from very clear team structures to extensive stakeholder involvement to "daily builds" and software reuse -- largely eased frustration for programmers and made their work more enjoyable. They also helped reduce boring rework and bug detection, at the same time boosting product quality and shrinking time to market. Overall, the successful companies we studied delivered software with about one third fewer defects than their competitors -- largely attributable to their development processes.

What did your survey reveal about how quickly software companies go global?Contrary to common belief, US companies "go global" faster than the Europeans. In our survey, we found that the US companies go overseas within an average of 2.6 years after starting, while the European players wait 3.7 years, more than 40% longer. But there are some outstanding European players in the globalization race as well -- not only well-known giants like SAP, but many start-ups too -- that could serve as role models for other European firms. Intershop is one. Within half a year, CEO Stephan Schambach moved the entire company, headquarters and all, to Silicon Valley. The internationalization cost Intershop $10 million -- more than its annual revenues at that time -- but it was worth the cost. Not only was the US market much larger, but both competitors and potential partners of the company were located on the West Coast.

Several books and media stories have pointed to cannibalization as a key ingredient for success. Did the facts from your survey validate this theory?Our survey confirmed that the cannibalization rate was one of the strongest and most distinguishing differences between successful and unsuccessful companies. More than half the lower-performing companies waited beyond the growth and cash cow phases, until the downsizing phase, in fact, to replace their old products with new ones. In stark

contrast, three-thirds of the successful companies introduced a new product during the growth phase of the previous one. This made the product obsolete -- "eating up" its market to a great extent. SAP has been a great advocate of cannibalization. At the end of the 1980s, the company had a near-total hold on the market with its R/2 package. Yet in 1992, SAP came out with R/3, a completely new software product. The result? Sales shot from less than $500 million in 1992 to $1.5 billion in 1995.

Your book says that outstanding marketing is the critical requirement for success in the software product business. What are some of the key tactics the best companies use?Successful marketing requires much more than just spending a lot of money. Many software firms actually spend more of their budget on marketing than fast-food giant McDonald's -- but only a few of them spend it effectively. The firms that succeed insist on communicating a clear value proposition to customers, and that makes all the difference. Rather than advertising product features, successful firms advertise company brands. They cannibalize their own products up to twice a year, before the first version ever reaches the cash cow phase. They apply creative software entry-pricing techniques to build their customer base. They also take innovative approaches to PR, often letting their partners pick up the tab for extravagant promotions. And they establish and communicate completely new platforms, build marketing alliances, and preinstall software -- to reach, sustain, or take over the pole position and become the "category killers."

It seems like every day brings new announcements of partnerships in all kinds of industries. What makes software partners exceptional?Partnering has taken on a completely new dimension in the software industry compared to other industries, in the number, equality, and importance of partnerships. The successful firms in our survey averaged four times as many partners as their competitors. This held true not just for large companies like SAP, Oracle, and Baan -- but also for small companies like Great Plains Software, a $60 million revenue enterprise solutions company in Fargo, North Dakota, which counted over 1,000 smaller, localized IT consulting companies as implementation partners. Software companies have also created a new level of equality between partners -- players depend on independent partners who are not controlled or owned. In terms of importance, successful firms rated the need for partners for their flagship product almost 30% higher than competitors. They also gave away a large share of total revenue to their partners to build and maintain market leadership. For example, Baan gives away 80% of the total revenue value of the Baan Web to its partners.

With a turnover rate of 21%, software companies must become talent motivation experts just to survive. What can they teach other industries about what it takes to retain the best talent?Common belief assumes turnover rates of more than 10 to 15 percent represent a threat to the corporate culture and employee motivation. Our survey, however, found that many companies in the software industry have learned to view this as an opportunity rather than a problem. As long as leaders manage to retain their very best people, high turnover can lead to positive aspects such as the infusion of new ideas and high energy, and

access to new customer and recruiting networks. One Silicon Valley company we surveyed has devised a system for calculating the "walk away value" of its top employees in order to make sure managers work hardest on retaining those most likely to leave. The best companies also ruthlessly test cultural attitudes during recruitment, and set up processes that allow them to integrate, train, and utilize new employees as quickly as possible.

But what about stock options? So many stories have been written about these tools as powerful incentives for attracting and keeping workers in this industry.Most people think that the opportunity for becoming rich via stock options is the main tool for recruitment and retainment in the software business. But while financial rewards were certainly important, our survey confirmed that the potential for great wealth was not the main reason that software workers joined particular companies. Company culture was in fact one of the most important factors workers assessed when choosing an employer.

Among the future trends you predict is a new form of coopetition among product and project players that could radically alter business relationships in the industry. How will this play out?Driven by the customer's need for reduced complexity and less trouble with implementation, an increased demand for one-stop shopping is developing. Thus, product and professional services companies will enter a race for becoming this one shop. And new players like processing services providers, Internet services providers, and telecommunications giants line up for that race as well. The outcome of this competition will be affected by two important events: 1) the adoption of componentware leading to a "productization of services" -- the replacement of costly integration and custom programming by standardized reusable components; and 2) an increase in outsourcing services provided directly or via networks, which will lead to a "servicization of products" -- the replacement of product sales with subscription contracts for "all-in-one" service packages.

Do you foresee more industry consolidation as we head into the future? And what will this mean for innovation?All indications are that we will see even more industry consolidation, bringing further market concentration. But unlike other industries, where consolidation may stifle innovation and start-ups, the promise of acquisition makes new ventures want to set up shop -- even if they normally could not compete with the big players. It's a contradiction of normal events, a paradox, that could lead to a unique form of "consolidation" in the software industry: a few large and powerful players, plus many small new players who set up shop to be acquired for their innovations. Furthermore, as the industry matures and consolidates, we will see a reduction in complexity and increasing government regulation.

*Harvard Business School Press, 2000ISBN: 1-57851-105-4Cover Price: US $27.50(336 pages)

Read Philippe Kruchten's review of Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, and the Unified Process, 2/e, by Craig Larman.


Book Review

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, and the Unified Process, 2/e by Craig Larman

Prentice Hall, 2001ISBN: 0130925691Cover Price: US $(600 pages)

Programming is fun, but developing quality software is hard. In between the nice ideas, the requirements or the 'vision,' and a working software product, there is much more than programming. Analysis and design -- defining how to solve the problem, what to program, capturing this design in ways that are easy to communicate, to review, to implement, and to evolve are the concerns that lie at the core of this book. This is what you will learn.

The Unified Modeling Language (UML) has become the universally-accepted language for software design blueprints. UML is the visual language used to convey design ideas throughout this book, which emphasizes how developers really apply frequently used UML elements, rather than obscure features of the language.

The importance of patterns in crafting complex systems has long been recognized in other disciplines. Software design patterns are what allow us to describe design fragments and reuse design ideas, helping developers leverage the expertise of others. Patterns give a name and form to the abstract heuristics, rules, and best practices of object-oriented techniques. No reasonable engineer wants to start with a blank slate, and this book offers a palette of readily usable design patterns.

But software design looks a bit dry and mysterious when not presented in the context of a software engineering process. And on this topic, I am delighted that in his second edition, Craig Larman has chosen to fully embrace and introduce the Unified Process, showing how it can be applied in a relatively simple and low-ceremony way. By presenting the case study in an iterative, risk-driven, architecture-centric process, Craig's advice has realistic context. He exposes the dynamics of what really happens in software development and shows the external forces at play. The design activities are connected to other tasks, and they no longer appear as a purely cerebral activity of systematic transformations or creative intuition.

jprince

http://www.therationaledge.com/content/jul_01/r_applyingUMLpatterns_cl.html

jprince

And Craig and I are convinced of the benefits of iterative development, which you will see abundantly illustrated throughout.

So for me, this book has the right mix of ingredients. You will learn a systematic method for doing Object-Oriented Analysis and Design (OOAD) from a great teacher, a brilliant methodologist, and an "OO guru" who has taught it to thousands around the world. Craig describes the method in the context of the Unified Process. He gradually presents more sophisticated design patterns, which will make the book very handy when you are faced with real-world design challenges. And he uses the most widely accepted notation.

I'm honored to have had the opportunity to work directly with the author of this major book. I enjoyed reading the first edition, and was delighted when he asked me to review the draft of his second edition. We met several times and exchanged many e-mails. I have learned much from Craig, even about our own process work on the Rational Unified Process and how to improve it and position it in various organizational contexts. I am certain that you will learn a lot, too, in reading this book, even if you are already familiar with OOAD. And, like me, you will find yourself going back to it, to refresh your memory, or to gain further insights from Craig's explanations and experience.

In an iterative process, the result of the second iteration improves on the first. Similarly, in a second edition, the writing matures,. Even if you have the first edition, you'll enjoy and benefit from this one. Happy reading!

- Philippe KruchtenRational Fellow

Read this month's Rational Reader interview: A conversation with the authors of Secrets of Software Success


Testing Embedded Systems: Do You Have The GuTs for It?

by Vincent EncontreDirector, Embedded and Real-TimeAutomated Testing Business UnitRational Software -- Toulouse, France

This article offers a general introduction to testing embedded systems, including a discussion of how embedded systems issues affect testing process and technologies, and how Rational Test RealTime provides solutions for these issues. Many thanks to Paul Szymkowiak, Rational's process engineer involved in the testing portion of the Rational Unified Process®(RUP®), for his improvements to my original text, for his continuous support, and for his glossary of real-time embedded terminology at the conclusion of this article.

In order to settle on a common set of concepts, let's start with some definitions.

What is testing? Testing is a disciplined process that consists of evaluating the application (including its components) behavior, performance, and robustness -- usually against expected criteria. One of the main criteria, although usually implicit, is to be as defect-free as possible. Expected behavior, performance, and robustness should therefore be both formally described and measurable. Debugging literally means removing defects ("bugs"), and is thus not considered part of the testing process directly. Testing is one of the detective measures, and debugging one of the corrective measures of quality.

What exactly is an "embedded system"? It's difficult, and highly controversial, to give a precise definition. So, here are some examples. Embedded systems are in every "intelligent" device that is infiltrating our daily lives: the cell phone in your pocket, and all the wireless infrastructure behind it; the Palm Pilot on your desk; the Internet router your e-mails are channeled through; your big-screen home theater system; the air traffic control station as well as the delayed aircraft it is monitoring! Software now makes up 90 percent of the value of these devices.

jprince

http://www.therationaledge.com/content/jul_01/t_testembedded_ve.html

Figure 1: The World Runs on Embedded Software

Most, if not all, embedded systems are "real-time" (the terms "real-time" and "embedded" are often used interchangeably). A real-time system is one in which the correctness of a computation not only depends on its logical correctness, but also on the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred. And for some systems, identified as safety-critical, failure is not an option.

Thus testing timing constraints is as important as testing functional behavior for an embedded system.

Even though the embedded systems testing process resembles that used for many other kinds of applications, it is impacted by some issues important to the embedded world:

● Separation between the application development and execution platforms

● A large variety of execution platforms and thus of cross-development environments

● A wide range of deployment architectures

● Coexistence of various implementation paradigms

● Tight resources and timing constraints on the execution platform

● Lack of clear design models

● Emerging quality and certification standards

A more detailed discussion of these issues is found near the end of this article.

These issues greatly affect testability and measurability of an embedded

system. This explains why testing such systems is so difficult and consequently is one of the weakest points of current development practices. So it is no wonder that, according to a recent study: 50 percent plus of embedded systems development projects are months behind schedule and only 44 percent of designs are within 20 percent of feature and performance expectations, and all this even when 50 percent plus of total development effort is spent in testing.

In the rest of this article, we will:

● Go through a generic test iteration from which we will derive a minimal set of desired testing technology.

● Instantiate this iteration to address the testing of complex systems as found in the embedded world; based on these considerations we will add capabilities to our ideal testing technology.

● Moving one step further, examine what makes embedded systems so difficult to develop and test, and assess how these issues add to the list of features that need to be fulfilled by the technology used to test them. Rational Test RealTime will be used as an example of a product that implements a large portion of this ideal technology.

A Generic Test Iteration

The first step we will consider is to identify the granule to be tested. I use the word granule to avoid other words such as component, unit, or system, all of which have less generic definitions. For example, in the Unified Modeling Language (UML) a component is a piece of an application that has its own thread of control (that is, a task or a Unix process). I also like the word granule as the root for granularity, which translates well over the wide range of elements that can be tested: from a single line of code up to a large distributed system.

Preparing the Granule Under Test

So, first identify the granule to test, then transform it to a testable granule, or granule under test (GuT). This step consists of isolating the granule from its environment by making it independent with the help of stubs and, sometimes, adapters. A stub is a piece of code that simulates two-way access between the granule and another part of the application. Next, build a test driver. This will stimulate the GuT with the appropriate input, measure output information, and compare it with the expected response. An adapter is sometimes used to allow the GuT to be stimulated by the test driver. Stimulation and measurement follow specific paths through gates in the GuT: we will call them Points of Control and Observation (PCOs), a term that comes directly from the

telecommunications industry. A PCO can be located at the border of, or inside, the GuT. Examples of PCOs for a C function granule are:

● Point of Observation inside the granule: coverage of a specific line of code in the function.

● Point of Observation at the border of the granule: parameter values returned by the function.

● Point of Control inside the granule: change of a local variable.

● Point of Control at the border of the granule: the function call with actual parameters.

Stubs and even test drivers can be other parts of the application (if they are available) and don't necessarily need to be developed for testing a C function or a C++ class. The GuT can be accessed or stimulated through another part of the application, which then plays the role of stub or test driver. Stubs and test drivers constitute the test harness environment of the GuT.

Defining the Test Case

Defining a test case is a matter of figuring out:

● The appropriate PCOs: this depends on the kind of testing to be performed, such as functional, structural, load, and so on

● How to exploit these PCOs: which information to send and to expect to receive through them, and in what order, if any

The type of test as well as sent/expected information is driven by the requirement set for the GuT. In the case of safety-critical systems, formal and precise requirements are an essential part of the development process. While formal requirements are an important motivation source for tests, they don't always explicitly identify the tests that will discover important flaws in the system. Using the formal requirements, and for less critical applications when specific requirements are lacking, the tester must consider an appropriate set of tests to conduct (also referred to as "test ideas") to identify some requirements for testing the GuT. These requirements can then be translated into concrete test cases that take advantage of available PCOs. By "concrete," we primarily mean executable.

Usually, requirements themselves are not formal and do not naturally translate into formal test cases. This translation process often introduces errors in which test cases do not accurately reflect requirements. Specification languages have become more formal since the introduction of UML, and it has now become possible to express formal requirement-based test cases to avoid the translation pitfall. Rational QualityArchitect and a part of Rational Test RealTime provide good examples of using such model-based testing techniques.

Unfortunately, not all requirements are described using UML: in the

embedded world, the most common formal description technique for a test case is simply to use a programming language such as C or C++. While C or C++ are universally known (which reduces the learning curve), they don't do a good job of taking into account test case needs such as PCO definition or expected GuT behavior. As such they make it difficult for someone to define and implement comprehensive, formal test cases. This problem has been addressed by the design of specific high-level testing languages, which are well adapted to specific testing domains such as data-intensive or transaction-based testing. Rational Test RealTime proposes a mix of native 3GL and dedicated high-level scripting languages, bringing the best of both worlds: reduced learning curve and efficiency in defining and implementing test cases.

Another extremely valuable and productive way to implement one or more test cases is to use session recorders: While the GuT is stimulated (either manually or by its future environment), particular Points of Observation record information passing in and out of the GuT. This information is automatically post-processed and translated into an appropriate case to be replayed later. An example of such a session recorder is found in Rational Rose RealTime where model execution leads to the generation of a UML sequence diagram reflecting trace execution, which is then used as input to Rational QualityArchitect RealTime.

Each test implementation must bring the GuT to a particular starting state that allows the test to be run. This part of a test is known as the preamble. Symmetrically, at the end of the effective test and whatever the result, the test implementation must bring the GuT to a final stable state that allows the next test to execute. This part of the test is called the postamble.

Deploying and Executing the Test

Once implemented, the test case is then integrated with the test driver and stubs. It is important to note that stub definition and implementation is an integral part of the test, enabling the test case to be realized. The test case forms the informational (vs. the operational) part of the test, and is validated during test harness execution.

Observing Test Results

Results from test execution are monitored through Points of Observation.

At the border of the granule, typical types of Points of Observation include:

● Parameters returned by functions or received messages.

● Value of global variables.

● Ordering and timing of information.

Inside the granule, typical types of Points of Observation include:

● Source code coverage, providing details about which software part of the GuT has been covered.

● Information flow to visualize exchange of information with respect to time between the different parts of the GuT. Typically this kind of flow is represented as a UML sequence diagram as in Rational Test RealTime.

● Resource usage showing nonfunctional information such as time spent in the various parts of the GuT, memory pool management (as exemplified in the Rational PurifyPlus family), or event handling performances.

All these observations can be collected for a single test case and/or aggregated for a set of test cases.

Deciding on Next Steps

Once all test output data have been gathered and test results synthesized, there can be one of two outcomes: One or more of the test cases failed, or all of the tests passed.

Test cases can fail for a number of reasons:

● Nonconformance of the GuT to the requirements.You'll have to go back to the implementation -- or worse, to the design -- to fix the problem in the GuT. This includes fixing implicit requirements such as "zero-crash" reliability.

● The test case is wrong. This happens much more frequently than you might think. Tests, like software, do not always work as expected the first time they are executed. Modify the test case definition and/or corresponding implementation to fix the problem.

● Test case implementation cannot be executed. Again, like software, everything seems correct, but you cannot deploy or start or connect your test harness to the GuT. You'll need to analyze the failure using debug and diagnostic tools.

If all tests have passed, you might want to consider these courses of action:

● Reevaluate your test. If you are early in your test process, you might question the value and goal of your test. Tests are supposed to find problems (especially early in the development effort), and if you don't get any, well…

● Increase the number of test cases. This should increase visibility of, and confidence in, the reliability of the GuT. Some may object that reliability is part of requirements, and they are correct. However, level of reliability is often directly correlated to the level

of coverage of the GuT by the overall set of test cases.

Some may object that each necessary reliability test should correspond to a formally stated requirement, and they are arguably correct. The problem is that some reliability requirements are implicit, which means there won't be formally stated requirements for them. Furthermore, it has been observed that the actual reliability of the GuT is often directly correlated to the level of coverage of the GuT by the overall set of test cases: A sufficient number of tests is necessary to validate reliability.

Arguably, the most widely-used type of coverage is code coverage, as implemented in Rational Test RealTime. While not a complete approach to test coverage by itself, basing our testing on code coverage helps to define additional test cases that will increase the coverage up to a level agreed in the requirements. This part of testing is often referred to as structural testing: Test cases are based on the content of the GuT, not directly on its requirements.

● Increase the scope of the test by aggregating granules. You'll then apply this generic process to a larger portion of your system, as described in the next paragraph.

When to Stop Testing?

This is a perennial question for the software practitioner, and it is not the ambition of this article to solve it! However, here is one heuristic that can be used: Consider the safety criticality of the system under test. Can the system be deemed safety critical or not? For nonsafety-critical systems, testing can be stopped based on more or less subjective criteria such as time-to-market, budget, and a somewhat reactive assessment of "good-enough" quality. However, for safety-critical systems, for which failure is not an option, the decision to stop testing cannot afford to be made on subjective criteria. For these systems, the good-enough "quality bar" remains very high. We will see in the "Emerging Quality and Certification Standards" section near the end of this article some recommendations dealing with this issue.

Requirements for a Generic Testing Technology

From the generic test iteration previously described, we can infer a minimal set of features that must be fulfilled by testing tools. They must:

● Help to define and isolate the GuT.

● Provide a test case notation, either 3GL or visual or high-level scripting, supporting definition for PCOs, information sent to and expected from the GuT, and preamble/postamble.

● Help to accurately derive test cases from requirements or test ideas.

● Provide alternative ways to implement test cases using session recorders.

● Support test case deployment and execution.

● Report observations.

● Assess success or analyze failure.

Needless to say, Rational Test RealTime supports these features. But Rational Test RealTime is also going beyond these requirements to address the testing of complex systems as found in the embedded systems domain.

Generic Architecture and Implementation of Complex Embedded Systems

Embedded systems are complex systems that can be composed of extremely diverse architectures ranging from tiny 8-bit micro-controllers up to large distributed systems made of multi-processor platforms. However, two-thirds of these systems run on a real-time operating system (RTOS), either commercial off-the-shelf or in-house, and implement the concept of threads (a thread is a granule with an independent flow of control) that extend to the RTOS task or process. In the UML, this concept is referred to as a Component, while a node refers to an independent processing unit running a set of tasks managed by an RTOS. Any communication between nodes is usually performed using message-passing protocols such as TCP/IP.

The vast majority of developers of embedded systems use C, C++, Ada or Java as programming languages (70 percent will be using C in 2002, 60 percent C++, 20 percent Java, 5 percent Ada). It is not unusual to see more than one language in an embedded system, in particular C and C++ together, or C and Java. C is supposed to be more efficient and closer to the platform's details, while Java or C++ are (supposedly) more productive thanks to object-oriented concepts. However, it should be noted that embedded systems programmers are not object devotees!

In the context of embedded systems, a granule can be one the following (sorted by incremental complexity):

● C function or Ada procedure

● C++ or Java class

● C or Ada (set of) module(s)

● C++ or Java cluster of classes

● an RTOS task

● a node

● the complete system

For the smallest embedded systems, the complete system is composed of a set of C modules only and doesn't integrate any RTOS-related code. For the largest ones (distributed systems), networking protocols add another level of complexity.

The next section will show how this generic architecture impacts various aspects of the test effort.

Six Aspects of Testing Complex Embedded Systems

Depending on the type of the granule, and according to common usage in the industry (we will discuss this usage later in this section), it is common to consider testing from six different aspects to evaluate whether the application's behavior, performance, and robustness match expected criteria. These aspects are:

1. Software unit testing2. Software integration testing3. Software validation testing4. System unit testing5. System integration testing6. System validation testing

What follows is a discussion of each of these six aspects in relation to testing complex embedded systems.

1. Software Unit Testing

The GuT is either an isolated C function or a C++ class. Depending on the purpose of the GuT, the test case consists of either:

● Data-intensive testing: applying a large range of data variation for function parameter values, or

● Scenario-based testing: exercising different C++ method invocation sequences to perform all possible use cases as found in the requirements.

Points of Observation are returned value parameters, object property assessments, and source code coverage. White-box testing is used for testing units, meaning that the tester must be familiar with the content of the GuT. Unit testing is thus the responsibility of the developer.

Since it is not easy to track down trivial errors in a complex embedded system, every effort should be made to locate and remove them at the unit-test level.

2. Software Integration Testing

The GuT is now a set of functions or a cluster of classes. The essence of integration testing is the validation of the interface. The same type of Points of Control applies as for unit testing (data-intensive

main function call or method-invocation sequences), while Points of Observation focus on interactions between lower-level granules using information flow diagrams.

As soon as the GuT starts to be meaningful, that is when an end-to-end test scenario can be applied to the GuT. First, performance tests can be run that should provide a good indication about the validity of the architecture. As for functional testing, the earlier the better. Each forthcoming step will then include performance testing. White-box testing is also the method used during that step. Software integration testing is the responsibility of the developer.

3. Software Validation Testing

The GuT is all the user code inside a component. This can be considered one of the activities that occur toward the end of each software integration or build cycle. Partial use-case instances -- also called partial scenarios -- begin to drive the test implementation. The test implementation is less aware of and influenced by the implementation details of the GuT. Points of Observation include resource usage evaluation since the GuT is a significant part of the overall system. Again (and finally), we consider this step as white-box testing. Software validation testing is still the responsibility of the developer.

4. System Unit Testing

The GuT is now a full system component -- that is, the user code as tested during software validation testing plus all RTOS- and platform-related pieces: tasking mechanisms, communications, interrupts, and so on. The Point of Control protocol is no longer a call to a function or a method invocation, but rather a message sent/received using the RTOS message queues, for example.

The similarities in their message-passing paradigms implies that the distinction between test drivers and stubs can, from the perspective of the GuT, be considered irrelevant at this stage. We will call them Virtual Testers because each one can replace and act as another system component vis-à-vis the GuT. "Simulator" or "tester" are synonyms for "virtual tester." Virtual tester technology should be versatile enough to adapt to a large number of RTOS and networking protocols. From now on, test scripts usually: bring the GuT into the desired initial state; then generate ordered sequences of samples of messages; and validate messages received by comparing (1) message content against expected messages and (2) date of reception against timing constraints. The test script is distributed and deployed over the various virtual testers. System resources are monitored to assess the system's ability to sustain embedded system execution. For

this aspect, grey-box testing is the preferred testing method. In most cases, only a knowledge of the interface (the API) to the GuT is required to implement and execute appropriate tests. Depending on the organization, system unit testing is either the responsibility of the developer or of a dedicated system integration team.

5. System Integration Testing

The GuT starts from a set of components within a single node and eventually encompasses all system nodes up to a set of distributed nodes. The PCOs are a mix of RTOS- and network-related communication protocols, such as RTOS events and network messages. In addition to a component, a Virtual Tester can also play the role of a node. As for software integration, the focus is on validating the various interfaces. Grey-box testing is the preferred testing method. System integration testing is typically the responsibility of the system integration team.

6. System Validation Testing

The GuT is now a complete implementation subsystem or the complete embedded system. The objectives of this final aspect are several:

● Meet external-actor functional requirements. Note that an external-actor might either be a device in a telecom network (say if our embedded system is an Internet Router), or a person (if the system is a consumer device), or both (an Internet Router that can be administered by an end user).

● Perform final non-functional testing such as load and robustness testing. Virtual testers can be duplicated to simulate load, and be programmed to generate failures in the system.

● Ensure interoperability with other connected equipment. Check conformance to applicable interconnection standards.

Going into details for these objectives is not in the scope of this article. Black-box testing is the preferred method: The tester typically concentrates on both frequently used and potentially risky or dangerous use-case instances.

Deciding How to Address These Aspects

Now that we have defined these six aspects, how do we use them? There are plenty of criteria that are used to decide:

● Whether all these aspects apply to your systems.

● Whether all the aspects should be performed for all or only some parts of the systems.

● The order in which the aspects should be applied to the selected parts.

The answers to these questions depend heavily on the kind of embedded system you are developing: safety-critical or not, time-to-market, few or millions deployed, and so on. A future article will provide guidelines to help you with this selection process.

Another way to address these testing aspects is to melt them into one. Validation testing can be considered as unit testing a larger GuT. Integration can also be checked during validation testing. It is just a matter of how you can access the GuT, which kind of PCOs you can insert and where, and how you can target a specific portion of the GuT (possibly very remote) from the test case. But let's also leave that to another discussion.

Additional Requirements for a Complex Systems Testing Technology

In order to address the challenge of testing complex embedded systems, the testing technology must add the following capabilities:

● Manage multiple types of Points of Control in order to stimulate the GuT. Do this using: function call; method invocation; and message passing or RPC though different language bindings such as Ada, C, C++ or Java.

● Offer a wide variety of Points of Observation such as: parameters and global variable inspections; assertion, information, and control path tracing; and code coverage recording or resource usage monitoring. Each of these Points of Observation should provide expected vs. actual assessment capabilities.

How Embedded Systems Issues Affect Testing Process and Technology

In this section, we will highlight the specific issues of embedded systems and assess how they affect the technology used to test them. We will use Rational Test RealTime as our example testing tool.

Separation Between the Application Development and Execution Platforms

One of the multiple definitions for an embedded system is the following: An embedded system is any software system that must be designed on a platform different from the platform on which the application is intended to be deployed and targeted. By platform, on the development side, one typically means an operating system such as Windows, Solaris, HP-UX, or Linux. It should be noted that the percentage of Unix and Linux users is much higher (40 percent 1) in the embedded systems domain as compared to other IT systems domains. For the target, platforms include any of the devices mentioned earlier. Why the constraint? Because the target platform is optimized and tailored exclusively for the end-user (a real person or another set of devices), it

will not have the necessary components (such as keyboards, networking, disks, and so on) for the development to be carried out.

To cope with this dual platform issue, the testing tool must provide access to the execution platform from the development platform in the most transparent but efficient way possible. In fact, the complexity of such access must be hidden to the user. Access includes test-case information download, test execution remote monitoring (start, synchronize, stop), and test results and observation upload. In Rational Test RealTime, all target platform accesses are controlled by the Target Deployment technology.

In addition, Rational Test RealTime is available on Windows, Solaris, HP-UX, and Linux, the development platforms that leading companies in the device, embedded systems, and infrastructure industries are using.

A Large and Growing Variety of Execution Platforms and Cross-Development Environments

The execution platform can range from a tiny 8-bit micro-controller-based board to a large distributed and networked system. All platforms need different tools for application development due to the profusion of chip and system vendors. It is increasingly common that multiple platforms are used within the same embedded system. From a development perspective, this kind of environment is referred to as a "cross-development environment."

The large variety of execution platforms implies the availability of a correspondingly large set of development tools such as compilers, linkers, loaders, and debuggers.

The first consequence of this is that Points of Observation technology can only be source-code based. As opposed to Object Code Insertion technology used by the Rational PurifyPlus family and available for a small set of native compilers, Rational Test RealTime uses source-code instrumentation to cope with the number factor. Of course, ten years of experience in this technology has resulted in highly efficient code instrumentation.

Another direct consequence of this variety is that cross-development tool vendors tend to offer Integrated Development Environments (IDEs) to hide complexity and make the developer comfortable. It's a strong requirement that any additional tool be closely integrated into the corresponding IDE. For example, Rational Test RealTime is well integrated into WindRiver's Tornado and GreenHills' Multi IDEs.

Another characteristic is that, driven by the dynamic computer-chip industry, new execution platforms and associated development tools are released extremely frequently. This imposes a requirement that testing technology be highly flexible to adapt to these new architectures in record time. A Rational Test RealTime Target deployment for a new target platform is usually achieved in less than a week, often within two days.

Tight Resources and Timing Constraints on the Execution Platform

By definition, an embedded system has limited resources over and above the application it is supposed to run. This is especially true about tiny platforms where: available RAM is less than 1 Kb; the connection to the development environment can only be established using JTAG probes, emulators, or serial links; or when the speed of the micro-processor is just good enough to handle the job. The testing tool faces a difficult trade off: Either have test data on the development platform and send data over the connectivity link at the expense (usually unbearable) of performance, or have the test data interpreted by the test driver on the target platform.

The technology used by Rational Test RealTime involves embedding the test harness onto the target system. This is done by compiling test data previously translated into the application programming language (C, C++ or Ada) within the test harness, using the available cross-compiler, and then linking this test harness object file to the rest of the application. This building chain is made transparent to the user by using the Rational Test RealTime command line interface in makefiles. Optimized code generation, smart link map allocation, and low memory footprint all work to minimize required resources by the test harness on the target platform while providing the following benefits:

● Timing accuracy is improved and real-time impact on performance is reduced by using in-target location.

● Host-target communication is minimized by avoiding any data information circulating on the connectivity link during the test-case execution. If necessary, observation data are stored in RAM and uploaded with the help of a debugger or emulator when the test case is strictly finished.

Even if cross-development environments are becoming friendlier, a large part of the embedded systems currently shipped are still tricky enough to develop and test that they give most of us headaches. The goal of Rational Test RealTime is to simplify the tough routine of the embedded systems developer.

Lack of Widespread Use of Visual Modeling

Embedded developers like code! Unfortunately, post-secondary graduates are not well trained in visual modeling, and they tend to believe that code is the "real stuff." Although visual modeling, through languages such as the UML, has made a lot of progress toward incorporating embedded knowledge into a design, a majority of embedded systems programmers still love doing most of their work using plain old programming language. And Java is not bringing too many people to design!

To enable developers to work in the way they prefer, Rational Test

RealTime is focusing on helping them design test cases based on the source code of the application, by providing wizards such as test template generators and API wrappers. Making sure the test can apply to the application is the main benefit of this code-based test building process. The drawback is that there is no guarantee that the test case reflects the requirement it should check. Clearly, broader adoption of visual modeling would reduce the gap between requirement and test case, and, along with other Rational products, Rational Test RealTime is also paving the way for this technique named "Model Driven Testing" by offering a Rational Rose RealTime UML sequence diagram to test-case compiler.

Emerging Quality and Certification Standards

For a certain category of embedded systems -- safety-critical systems -- failure is not an option. We find these systems in the nuclear, medical, and avionics industries. Stepping on the zero-failure objective long time ago, the aircraft industry and government agencies (such as the Federal Aviation Administration in the US) joined to describe Software Considerations in Airborne Systems and Equipment Certification, referenced as the RTCA's DO-178B standard.2 This is the prevailing standard for safety-critical software development in the avionics industry worldwide. As one of the most stringent software development standards, it is also becoming partially adopted in other sectors where life-critical systems are manufactured, such as automotive, medical (FDA just released a standard close to DO-178B), defense, and transportation.

DO-178B classifies software into five levels of criticality related to anomalous software behavior that would cause or contribute to a system function failure. The most critical is level-A equipment, in which failure results in a catastrophic failure condition for the overall system. DO-178B includes very precise steps for making sure level-A equipment is safe enough, in particular in the testing area. Rational Test RealTime meets all mandatory DO-178B test requirements, for all levels, up to and including level-A equipment.

Summary

In this article, we have presented an overview of six aspects of embedded systems testing. Considering the full spectrum from very small to very large systems, and the specific characteristics and constraints of embedded systems, we have deducted a set of requirements that an ideal technology must possess to address the testing of embedded systems. Large portions of this ideal technology are exemplified by Rational Test RealTime, the new Rational test offering to the embedded, real-time, and networked systems domain.

This article is a general introduction to the testing of embedded systems, and will be followed over the course of the year by more articles focusing on some of the topics discussed.

Terminology

by Paul Szymkowiak

Unfortunately, many terms used in the software engineering world have different definitions. The terms used in this article are probably most familiar to those who work in the real-time embedded systems domain. There are, however, other equivalent/related terms that are used in software testing. We provide a mapping in the following table.

Terms Used in This Article Equivalent/Related Terms

Granule under Test (GuT): A system element that has been isolated from its environment for the purpose of testing.

Related terms: Test Item, Target, Target of Test

Point of Control and Observation: A specific point in a test at which either an observation is recorded of the test environment, or a decision is made regarding the test's flow of control.

Closest equivalent term: Verification Point

Preamble: The actions taken to bring the system to a particular stable starting state required for the test to be executed.

Pre-condition, Setup

Postamble: The actions taken to bring the system to a particular stable end state required for the next test to be executed.

Post-condition, Reset

Virtual Tester:1. Something external to the GuT that interacts with the granule during a test.2. An instance of a running test, typically representing the actions of a person.

Related terms: Test Script or Test Driver, Test Stub, Simulator, Tester

Test Harness: An arrangement of one or more test drivers, test-specific stubs, and instrumentation combined for the purpose of executing a series of related tests.

Related terms: Test Suite, Test Driver, Test Stub

Footnotes

1 "Critical Issues Confronting Embedded Solutions Vendors," Electronics Market Forecast, http://www.electronic-forecast.com/, April 2001.

2 DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics - RTCA, http://www.rtca.org/, January 1992.



Building a Rational Software Configuration Management Environment for the IBM e-Business Platform

by Eric Carr, ManagerJian Wei, Senior Consultant Experio Solutions

As applications that support critical business processes continue to grow more complex, there is a growing need to maintain control over development environments with effective software configuration management (SCM). In this article, we will explore the advantages and the steps involved in integrating Rational ClearCase® with both IBM VisualAge® for Java™ (VAJ) and Macromedia Homesite™ to create an environment with SCM capabilities.

Note: Although we strongly believe that every CM environment needs an effective change control system -- ClearQuest, in our case -- our main focus in this article will be on the integration of ClearCase within the CM environment.

jprince

http://www.therationaledge.com/content/jul_01/t_rationalSoftConfig_ec.html

Despite widespread industry acknowledgment that orderly processes enable productivity, it’s not unusual for software development organizations to have either undefined or loosely observed processes and procedures. Organizations like these represent the "Initial" level (Level One) of the CMM®, or Capability Maturity Model, developed by the Carnegie Mellon Software Engineering Institute (see sidebar).1 As the CMM explains, for these companies, "The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort."

How does an organization move beyond this chaos? First, managers must understand that they need the control an SCM tool can bring to any software development environment. A tool alone, however, is not enough. The organization also needs to clearly define processes, procedures, and policies in relation to its unique development environment. Then, once a plan is in place, it can use SCM tools to enable development teams, business analysts, and managers to move out of CMM Level One. If they hope to remain competitive, management will need to invest the time, energy, and money required to define, track, control, and manage their specific software development process.

Closing the SCM Gap

IBM is one of the leading e-business companies, and the WebSphere Application Server, Domino Server, IBM HTTP Server, and DB2 Universal Database lie at the heart of their e-business offerings. Their leadership position is based on several key factors:

1. IBM’s products run on multiple platforms (NT, Windows 2000, Sun Solaris, AIX, AS400, etc.)

2. IBM’s products are able to interface with most backend systems, such as Oracle, SQL, DB2, SYS390.

3. IBM has standardized its product development efforts around the J2EE industry standard.

The company’s e-business development tools do, however, have a few shortcomings; software configuration management, for example, is not integral to the offering. Although IBM’s VisualAge for Java (VAJ) has an internal version control engine -- ENVY -- for tracking development efforts within VAJ, most organizations use other technologies for Web development. This leaves an SCM gap for organizations using IBM’s e-business development environment.

To help organizations fill this gap, IBM announced last year that it would standardize on Rational ClearCase and Rational ClearQuest, a defect-tracking and change management tool, to create a strategic SCM solution. This means that organizations using IBM’s e-business tools -- along with other development tools -- can now define, track, and control their software development efforts.

Why did IBM choose Rational? The answer is very simple: Rational is one of the few companies that provides a full line of product offerings for the entire software development lifecycle.

Planning an SCM Environment

The key to creating an optimum SCM environment with Rational ClearCase and ClearQuest is the old adage, "Plan the work, then work the plan." Companies can get the most from these tools by doing some pre-implementation planning, focusing on how and what developers, business analysts, testers, and managers will need to do their work. The planning process should include:

1. Understanding and documenting current software development processes and procedures.

2. Re-defining processes in which errors or misunderstandings can occur.

3. Establishing clearly defined roles and responsibilities.

4. Establishing policies that govern the ways in which each development environment will function.

5. Identifying how Rational products will help in the software development lifecycle.

6. Creating a CM (configuration management) plan. Software teams

should not attempt to implement the ClearCase architecture and design within the development environment until a CM plan, policies, and procedures are in place.

The clear vision that results from this planning process allows organizations to architect and design the following items:

1. Hardware and software requirements.

2. ClearCase and ClearQuest integration with VAJ and other development tools.

3. An SCM environment using either Base or Unified Change Management (UCM).

4. ClearCase objects (VOBs, Projects, Promotion Levels, etc.).

5. Individual or shared environment areas.

6. A plan for populating the ClearCase SCM environment.

7. Client and server patch level updates.

8. A production baseline and a baseline naming convention.

9. An employee training plan.

10. An implementation plan for development tools (e.g., WebSphere Studio or IBM VAJ) that can carry development efforts through to production. These tools allow managers to control when and what code is moved into production (see Figure 1).

11. A plan for how developers will use VAJ Team versus a local repository (see Figure 2).

Figure 1: SCM Architecture for the IBM e-Business Development PlatformClick here to view larger image

Figure 2: Plan for Repository Use in an IBM VAJ Environment

Case Study: Integrating Rational ClearCase with

IBM VisualAge for Java and Macromedia Homesite

The following is based on our experience with an actual client.

Company Profile

● A Midwestern, Fortune 500 banking company, the 22nd largest in the US

● $42 billion in assets

● Ranks among the top twenty US bank holding companies in small business lending

● Ranks first among the nation's top fifty bank holding companies in commercial loans as a percent of total assets

Business Issues

● Loosely followed processes and procedures for development

● Difficulties maintaining correct versions of code in transition from test to production environment

● Difficulties handling change requests

● Difficulties ensuring that developers are using the correct version of the code

Resolution

Our client recently purchased the Rational Suite to use both the tools and methodology for change control, requirements gathering, Q/A testing, and much more. Based on the business issues described above, the bank’s primary goal was to gain better control over their Web development efforts. We assisted them with planning and installing Rational ClearCase to help achieve this goal.

Since this client was at Level One on the CMM scale, we decided that the

best strategy was to use the Rational ClearCase UCM approach. The client’s primary e-business development tools included IBM VAJ, IBM WebSphere Studio, and Macromedia Homesite. Our objectives were to tightly integrate Rational ClearCase with VAJ and Homesite and to streamline ClearCase UCM operations to perform directly within VAJ and Homesite workspaces.

Our first step was to implement Rational ClearCase. Below are the procedures we followed.

Set Up the Rational ClearCase Server

1. Apply latest patches to ClearCase server (v4.0 or later).

2. Create a project VOB (Versioned Object Base).

3. Create VOB components, each corresponding to an IBM VAJ project.

4. Create a ClearCase VOB component for the HTML and JSP elements developed in Homesite.

5. Create a ClearCase project containing all the components with an initial baseline. ClearCase will automatically create an integration stream for the project.

Set Up the Rational ClearCase Client

1. Apply latest patches and verify connectivity to the ClearCase server (v4.0 or later).

2. Join the ClearCase project. ClearCase will automatically create a development stream.

3. Create a development view to work with the development stream. Each view is represented as a network drive mapped on the local machine. Each VOB component becomes a directory under the drive mapping (e.g., L:\VAJ_VOB). The component directory is equivalent to a SCCI (Microsoft Software Configuration Control Interface) working directory.

Prepare IBM VAJ

1. Apply the latest patches and e-Fix to IBM VAJ Enterprise Version 3.5.

2. Install Rational ClearCase integration options to IBM VAJ under Start>Program Files>ClearCase Administration>Rational Integration with VAJ.

Integrate Rational ClearCase with IBM VAJ

1. Start the VAJ Remote Application Access API.

2. Select VAJ project in VAJ workspace and click Tools>External Version Control>Add to Version Control to launch the integration process.

3. Select SCCI interface and follow the wizard (treat the ClearCase component in the development view as if it is a SCCI working directory).

4. A green arrow will appear next to your VAJ project to indicate that it has been added to version control. Arrows will also appear next to any types in your project. Arrows will not appear next to packages. Rational ClearCase functionality, including UCM options, will then become available underTools > Rational ClearCase Additional Tools.

Figure 3: Integrating Rational ClearCase with IBM VisualAge for Java and Macromedia Homesite

Click here to view larger image

Integrate Rational ClearCase with Macromedia Homesite

1. Create a Homesite project directly under the development view (e.g., L: drive).

2. Add the Homesite project under version control, and it will automatically pick up all the file elements in ClearCase (you should have everything loaded into the ClearCase server to establish an initial baseline first).

3. If you see a green arrow next to the project and the file elements underneath it, then the integration was successful.

Was This Integration Worth the Effort?

Our experience on this project confirms our belief that a repeatable configuration control process makes an e-business development team fundamentally more efficient and more resilient in the face of changes. In this case, integration of Rational ClearCase with IBM VAJ and Macromedia Homesite allowed the client’s project managers to enforce a well-defined Rational UCM process with minimum overhead for the development team. Now, the development team is much better equipped to respond to change

requests. The baselines established in ClearCase clearly indicate which versions of the software are in production, UAT testing, QA testing, integration testing, etc., and this ensures that developers always start their work with the right version of the software components (e.g., Java Class Files). Ultimately, this translates into big cost savings because of the drastic reduction in re-work.

There are other advantages as well.

● From the project manager’s perspective, the ClearCase check-in/check-out mechanism associated with the activity-based, automatic tracking of change sets, provides better control over the dynamic development environment. A project manager can easily track the overall project progress, as well as each developer’s ongoing efforts, and the major releases/baselines in relationship to the project plan.

● With ClearCase and UCM in place, organizations can even generate a bill of materials based on the change sets of activities that go into each major release.

● There’s a big payoff in ease of maintenance, too. Because a ClearCase baseline represents a snapshot of the development environment, the support team can easily schedule regular backup and server tuning. And if various development workspaces ever go down, the development artifacts can be quickly recovered.

What was the investment? In addition to the Rational ClearCase license and installation cost, this project took three experienced consultants eight weeks to draft a detailed configuration management (CM) plan, implement and document all the integration links (e.g., SCCI interface to VAJ repository), establish and test drive various ClearCase setup strategies, and finally put the entire development environment under ClearCase configuration management control.

Our observations, as well as our client’s feedback, indicate to us that all the efforts and investment were well worth it. Rational ClearCase will pay for itself because it gives project stakeholders tremendous control over the e-business development environment.

As more and more IT organizations pursue ISO or CMM certification, Rational’s ClearCase tool, along with the underlying UCM process, is worth consideration. This technology lays a solid foundation for a repeatable configuration management process, and it can support an overall process improvement effort as well as regulatory mandates in some industries.

Lessons Learned

It is important to educate clients on an ongoing basis about the importance of SCM. We stress that SCM is not optional, but is instead a key element in building a robust e-business infrastructure.

Early in the project described above, we made a conscious decision to use Rational’s ClearCase UCM process because it represents the best practice in the industry, and it is well documented in the Rational Unified Process® (RUP®). Using UCM allowed us to focus on resolving the technical issues without affecting the overall project plan. This was a key advantage, given our eight-week timeframe and resource constraints.

We also found that having a designated Rational contact person from the client team was crucial to ensure proper knowledge transfer and continuity of support. It would have been even more beneficial if that person had also been involved early in the process, while we were defining the project approach and deliverables.

In terms of the integration itself, integrating Rational ClearCase with Homesite is extremely intuitive and easy. Although the current level of integration between Rational ClearCase and IBM VisualAge for Java via the Microsoft SCCI interface is cumbersome and slow at times, we expect that with the intensified partnership between IBM and Rational, the integration mechanism will become faster and easier in later versions of IBM VAJ and Rational ClearCase. IBM has indicated that it may retire the SCCI interface and VAJ built-in ENVY version control engine in favor of Rational ClearCase, and that it will use a Standards Committee endorsed standard such as Web-based Distributed Authoring and Versioning (WebDAV).

From a network administration standpoint, we have found that ClearCase tends to generate a large volume of network traffic and has a relatively high demand on round trip response time. We were able to resolve all the network timeout problems by experimenting with different network settings; the network packet size seems to be the most significant factor on this project. Rational support has advised us to be cautious when adjusting the network packet size, as it may corrupt ClearCase VOBs.

Overall, we were satisfied with the experience we had with Rational technical support. IBM technical support was also helpful with the VAJ to ClearCase integration.

What’s Next?

Today’s Web sites typically include four major functional areas: content delivery, personalization, data mining, and e-commerce application. Many high-end content management tools such as Vignette can provide integrated services for the first three functional areas. But given the dynamics of content and content template changes, there is a great and ever-growing need for configuration management. We highly recommend that organizations take a broad view of their Web site and introduce CM to manage not only application code (Java, HTML, JSP, and so forth) but also Web content. Rational’s latest product, Rational Suite ContentStudio, offers tight integration with the Vignette V/5 platform. In our view it is a logical step for any client who has made an investment in either Rational

ClearCase or Vignette to take advantage of the features offered in Rational Suite ContentStudio, and to build a truly integrated CM methodology for the entire Web site.

Configuration management is only one aspect of managing the software development lifecycle. To fully exploit the level of control and efficiency that the Rational Unified Process (RUP) can give to an IT team, we suggest that organizations look into integrating ClearCase with other Rational products, such as RequisitePro for business requirements management and ClearQuest for change management. Using ClearQuest with ClearCase provides an even more powerful UCM process than ClearCase alone to integrate activities with artifacts in the development lifecycle. As most of our clients tend to purchase the entire Rational Suite, we feel that integrating the full set of products as well as the entire RUP process is not only beneficial but also very cost effective.

Experio Solutions, a Hitachi company, is a single-source company delivering dynamic and sustainable end-to-end business solutions designed to accelerate business performance for growth-oriented organizations. As an IT consulting firm, Experio consultants average more than 12 years of experience, designing and implementing practical business solutions enabled by technology. Headquartered in Dallas, the company has 18 offices throughout the US.

For more information, visit http://www.experio.com

Footnotes

1Also see http://www.sei.cmu.edu/cmm/cmm.html



Leveraging Points of Integration in Rational Suite: An Introduction

by Brenda CammaranoSenior Technical EvangelistRational Suite

Rational Suite® offers many points of integration, but until now, details about them have been dispersed across diverse Rational sources: white papers, online documentation, technical documents, and product manuals. Last winter, I launched a project to bring all this information together in one place and will soon publish a comprehensive white paper about points of integration on Rational.com. This Rational Edge article previews the first section of that paper. It focuses on using Rational Administrator to set up projects and covers the basic architecture of the Suite integrations. In future articles, I will write about the integrations themselves, including the steps required for establishing them.

Using Rational Administrator to Set Up Projects

Rational Administrator is a tool that’s included in the Rational Suite for creating and configuring centralized projects for software development teams. It is used by the project lead to set up and manage Rational projects and to facilitate points of integration for Rational tools.

Before you set up a project with Rational Administrator, you must make two major decisions:

● Which Rational tools will be included as part of the project.

● Whether the project will be associated with a Unified Change Management (UCM) project so you can track changes to requirements, design models, documentation, components, test cases, and source code. This is because the Rational Administrator is where you not only create projects, but also where you associate them with a UCM project previously created in Rational ClearCase. You can use the Rational Administrator to configure the UCM policies for your Rational project.1 UCM policies are established as

jprince

http://www.therationaledge.com/content/jul_01/t_leveraging_bc.html

follows:

1. Use UCM to manage files that have been changed and tracked to activities. These activities are created in ClearQuest to manage the project’s tasks, defects, and requests for enhancements. Files modified, such as models or source code, are associated to a specified activity and then tracked by UCM.

2. Establish the first tier of configuration management for requirements and test assets. This is called baselining. A baseline is a logical grouping of project files at a specific point in time. Baselines allow teams to capture the progress and relationships of software artifacts at key project milestones, which might refer to releases or development iterations. Figure 1 shows that the Requirements and Test Assets for the Webshop project have been configured for baseline configuration management.

Once you decide on which tools to configure and what UCM policies you want established, the Rational Administrator will create an .rsp (Rational Suite Project) file to store all the pertinent metadata for the project and for each tool’s database. The file also contains pointers to these databases, so they can actually reside anywhere on the network.

Setting Up a Project File

The following tool data are available for inclusion in your project file:

● Rational RequisitePro project, which manages requirements documents through Word and a dynamically-linked database.

● Rational ClearQuest database, which maintains change-request information for software development, including enhancement requests, defect reports, and documentation modifications.

● Rational TestManager datastore, which stores application testing information such as test assets, logs, reports, builds, computers, users, and groups.

● Rational Rose models, which store visual models for business processes, software components, classes, and objects.

When you configure a project, you need to follow certain association guidelines:

● Configure zero or one TestManager datastore (includes a database and series of flat files). This cannot be shared among multiple projects.

● Configure zero or one ClearQuest database. A single ClearQuest database can be shared among several projects.

● Configure zero or one RequisitePro project. (This is all you will need, but note that you can associate different RequisitePro projects to a Rose model; you can also use multiple RequisitePro projects as "test input" sources in TestManager.)

● Configure zero, one, or several Rose model files. (Although you can share a Rose model among multiple projects, it is not advisable.)

● Configure one Suite Synchronizer rules file.

Once your project is configured, only the Rose model references can be modified. Although modifications can be made to the .rsp file through Notepad, these modifications will not necessarily be recognized by integrations within each product.

Figure 1 shows the Rational Administrator screen for a configured project called "Webshop."

Figure 1: Configured Project Files for “Webshop”

Understanding the Architecture Supporting Rational Suite Integrations

Projects that are set up in Rational Administrator use the Rational Suite Extensibility Interface. This architecture exposes an internal structure that allows the customer to deploy on different computers (or domain servers) within the structure’s network. It provides an opportunity to optimize network traffic as well as access to artifacts.

Rational’s integration architecture also separates the UIs (user interfaces) of each tool from the application-server functionality that is responsible for semantic understanding and persistent storage of the artifacts appropriate to the tool. This structure optimizes each domain server, which stores and manages data for requirements, visual models, test assets, and change requests within the project.

By separating UI from server functionality and then implementing a common Rational Suite Extensibility API across all of these servers, Rational provides a unique and powerful architecture for a project's artifacts -- a single way to access artifacts of all types (see Figure 2).

Figure 2: Architecture Supporting Rational Suite Integrations

Domain Structure

In a project hierarchy, each of these domains is associated with a specific project. Figure 1 shows that for the Webshop project, a RequisitePro domain has been established, and a ClearQuest database, Test datastore, and Rose model domain have all been configured for the project.

Figure 3 shows a Rational Administrator display when additional projects are registered, in this case ClassicsRetail Stores, Classics Warehouse, and Classics HTTP Performance. Each project has established project-specific domains for RequisitePro data, modeling data, and testing data, yet all projects share the same change management domain (CLSIC). This demonstrates that change management artifacts can be shared across projects.

Figure 3: Rational Administrator Displaying Multiple Rational Suite Projects

Rational Synchronizer

The initial integration offering of Rational Suite introduced a utility called the Rational Synchronizer. The Rational Synchronizer contains a set of rules that control the synchronization of artifacts within and between project domains. As Rational Suite has become more seamlessly integrated, the Rational Synchronizer has a less important role, but it is still offered as a project utility.

Benefits of Product Integrations

Now you know the basics about setting up a project in Rational Administrator and understand the architecture behind Rational Suite’s point integrations, but what are the real benefits?

From a management perspective, the most sweeping benefit is that Rational product integration unifies software teams; it helps improve organizational proficiency and capability while addressing the specific needs of each individual in a specialized role. Product integration breaks down communication barriers that so often hamper collaborative work among project team members. By using a Rational Suite Project, all team members have instant access to, and insight into, all the important project data that they need to fulfill their project responsibilities.

On a very practical level, Rational integrations can help team members:

● Easily transform requirements into test cases and automatically verify functionality.

● Append test results to bug reports, thereby saving hours of attempts to recreate user errors.

● Assess the integrity of application architectures early in the project lifecycle.

● Design and code an application based on system requirements.

● And much more. These are just a few of the many tasks addressed through Rational integrations.

All of these advantages add up to more automation and less time attending to tedious administration. That means our customers can get a

handle on the complexity of software development and also optimize and maximize individual productivity while unifying their teams and maximizing team productivity.

Footnotes

1Configuring UCM policies simply involves determining which assets in your project you would like under UCM control. It’s like setting up the rules of the project for UCM. UCM policies are covered in the Rational Unified Process (RUP) and are described as follows: "CM policies are used to monitor and safeguard project assets, and to enforce software development practices. Project policies should improve communication amongst the team members and minimize problems encountered when integrating their work."



On Climbing Big Mountains

by Joe MarascoSenior Vice PresidentRational Software

I have been thinking that building a large software system is very much like climbing a big mountain. Surprisingly, I find that many of the lessons I learned from climbing reasonably big mountains -- of the Alpine, not Himalayan, variety -- apply. Both activities require the coordinated efforts of a team of highly qualified people under circumstances they can foresee and plan for, but not control. Success in both cases is a probabilistic calculation. This article explores this comparison in more detail.

Planning

For both activities, good planning increases the chances of success. The first step in good planning is to understand the scope of the task. For a mountain climbing expedition, this consists of understanding the height of the mountain, the relative difficulty of the terrain, special weather conditions, and so on. One can hardly imagine a climbing team, when asked about the height of the mountain they are about to scale, responding, "We'll know when we get to the top!" In a similar vein, we should expect a software team to understand the scope of the job they are about to undertake: How big is this mountain? How many lines of code, how many special device drivers, what fancy user interfaces, what performance characteristics, etc., will be required? In neither case can we foresee every possible "gotcha," but the salient features of the problem must be identified and written down so that they are addressed in subsequent planning.

A second step in planning is to review the scope of the project and the major obstacles to success and to identify the size and skill set of the team necessary to accomplish the objective. My experience in both domains tells me that the smallest possible team is best. All participants need to have a minimum skill level so they don't drag the team down. For

jprince

http://www.therationaledge.com/content/jul_01/k_mountain_jm.html

example, if the expedition warrants having a medical doctor as part of the team, the doctor should be a good climber and not a burden as the team makes its way to the summit. In both domains, participants who can play multiple roles are more valuable than specialists; when things get difficult, flexibility is an incredible asset in a small-team environment.

Selecting the Team

When identifying potential team members, it is important to evaluate candidates along several dimensions. Clearly, you are going to recruit specialists as required; if you must traverse a difficult, crevasse-riddled glacier, then you are going to need a good ice climber. In a similar vein, if you are producing a product with real-time requirements, you are going to need a runtime expert. In addition, as mentioned above, there should be a strong effort to choose overall competent climbers and engineers; in drafting for professional sports, this is the philosophy of picking the best athletes as opposed to drafting for position players. Finally, you need to gauge character; in addition to assessing skills, you need to evaluate how each individual will work as a team member, and how each person will bear up to stress and adversity. It is important that the prospective team member be a good climber and partner in foul weather as well as in fair. Since foul weather is certain at some time or other on most climbs, one can even make the case that performance under those conditions is the most important criterion.

One factor above all else helps to factor risk: experience. The more people you can add to the team who've been up this kind of mountain before, the better. Climbers who have done many, many mountains are sure to have better judgment, based solely on Darwinian considerations! This is known as the "Alaskan Bush Pilot Algorithm": When choosing amongst alternatives, pick the pilot who has been in business the longest. Experienced sailors have a saying that "Excellent sailors use their excellent judgment to keep them out of situations requiring their excellent skills." The same applies to mountaineers and software managers. It is better to avoid problems through savvy than to solve them through heroic efforts. The single easiest discriminator for judgment is experience. Look for people who have done it before and who have been successful. All other things being equal, take those people who have survived a tough mountain over those who haven't climbed at all.

Can you imagine attempting Everest without Sherpas?

Organizing the Team

Having put together a prospective pool of climbers/engineers, the team leader now needs to think about how to assemble the sub-teams. In climbing, this means allocating two, three, or four people to each rope.

It is a given that no one climbs unroped on a mountain of any significance. In addition to the great danger this would present to any climber foolish enough to desire it, it also represents risk to the rest of the party. They would have to take extraordinary measures to rescue their colleague from even the smallest of missteps. Likewise, in large programming projects,

lone-wolf behavior is very risky. At least two on a rope should be the rule.

For teams on which three or more engineers need to collaborate, pay attention to composing the right mix. You always need a strong lead climber, and the mix of skills and personalities needs to be distributed so that you don't wind up with one rope that is much weaker than the others. The guiding principle is balance: No one rope should be unbalanced, and the ensemble of teams should also be well-balanced. If you can't construct reasonable sub-teams from the pool, you need to analyze why, and either add to or prune the pool until you can.

The goal should always be the smallest number of small parties. Four teams of three or four players each can accomplish great things. Remember, in software engineering as in climbing, there is an insidious logistical pyramid silently at work -- the more people you attempt to put on the summit, the more people you need to support the effort organizationally. The growth tends to be exponential with the height of the mountain.

Scheduling

Another aspect of planning is scheduling. Once you sketch out the team, you can begin to figure out how much food and what kind of climbing gear you require. The software equivalent is figuring out how much development hardware and software you will need, and at what time. In order to make the resources come out right, you need some idea of how the team will progress up the mountain. Remember, there are three possible ways to go wrong: 1) not enough resources; 2) too many resources; 3) the wrong kind of resources, which translates to useless weight to carry. If the climb is going to take ten people four days, that is one set of resources; if it is fifteen people for two weeks, that is another matter entirely.

Now, the interesting thing is that in order to do this work, you need to know:

● What route you are going to take;

● What the intermediate stopping points are;

● About when you plan to get to each intermediate point with a given number of people.

That is all you need to draw up a schedule and calculate what you require to get the job done. You don't need to know every detail of how you are going to get to each stopping point. That's a good thing, because any plan that depends on that information is highly risky: most of those details are unknowable with any certainty before you actually get on the mountain. Even if you plan them down to the gnat's eyelash, they will all change as you make progress. Barring contingencies that force a route change, however, the overall stopping points, or milestones, should not change much.

Milestones are useful for two things: to get a gross idea of how you are

going to do the job and what resources you will need; and to monitor important progress. If you thought it was going to take you two days to get to your first base camp and it takes you six, then you had better sit down and think about the rest of the endeavor. That the team's morale is still wonderful and that the base-camp is the best-designed one you have ever seen are largely irrelevant, considering that the whole project is likely to take (at least) three times as long as planned.

Milestones or Inchpebbles?

So I advocate rough, bottoms-up planning with consensus from the team about how long it is going to take to achieve significant milestones. And I believe in taking very seriously the time it takes to actually get there. For this to be useful, the milestones cannot be too close together nor too far apart. On a climb of a day or two, the milestones are typically on the order of a few hours apart. For a climb in the Himalayas with a duration of weeks, my guess is that significant milestones are days apart. For a software project that has a duration of eighteen to twenty-four months, somewhere between three and six months feels right. All these translate to about six significant milestones for the project, give or take a few. If you are using an iterative development approach, the implication is that about six iterations will get you there. If it actually takes many more or many fewer iterations, that probably indicates that the granularity was wrong for the project-level planning.

There is nothing wrong with each sub-team having some finer granularity tasks if that helps. It is up to each team leader to organize his rope to make sure his party arrives in synch with the others.

Monitoring and Record Keeping

Most experienced team leaders I know keep some records in real time. For climbers, a small pocket notebook and stubby pencil usually come out at rest points, and some notes are written down. When we examine these notes after the climb, we find that, although we did not capture a lot of information, it is always very much to the point. Typical notations are about arrival times, discrepancies from planned arrival times, and unusual conditions. Sometimes they are informal notes on how the individuals and teams are performing. When you're planning a climb, notes like these about similar mountains can prove useful for adjusting initial estimates. For software projects, similar notations can be useful for gaining insight into actual project performance.

Handling Risk

Project plans also need to address contingencies. In climbing, the two variables that represent forces majeures are surprises in the selected route and the weather.

If the route chosen beforehand turns out to be too risky, an alternative route needs to be selected. This usually occurs because the ice or rock is not in the same condition it was in the last time this route was explored. A good plan uses natural stopping points in the climb to assess options and

choose among alternative routes. The software development analogy is to assess technical direction continuously, and then, based on the results achieved with each iteration, change the route slightly for the next iteration. Note that the goal, the mountain's peak, is a constant. However, changing conditions may affect our judgment as to the best way to get there. It is rare that there is only one path, and the superior mountaineer distinguishes himself by finding the right path in the face of new data.

The weather is a different thing entirely. When the weather turns on you unexpectedly, the whole nature of the enterprise changes radically. Now it is not an issue of getting to the top, but one of survival. Even if the party decides that further immediate progress is impossible, and that the correct strategy is to "hunker down" until the storm blows over, they may still perish if they run out of food before the weather abates. Because you have absolutely no control over the weather, you must view it with the utmost caution; the strength of your team can become irrelevant. More people die of ego on mountains than any other cause; failure to turn back at the right time can be fatal.

I think the programming analogy is when you find yourself dependent on things you can't control directly. This includes new, untested technology, scheduled miracles, required violation of known laws of physics, and internal and external suppliers and subcontractors. Ignoring changes of weather in these areas can lead to death, either instantly or in a painful and protracted fashion.

Decisiveness

I have never met a good climber who was indecisive. I have known climbers who confused recklessness with decisiveness. There is a difference. (I might also add that I have known old climbers, and I have known bold climbers. I have not known any old, bold climbers.)

I think the main thing I learned when climbing was that you don't have the time to agonize over decisions. That doesn't mean that you can afford to shoot from the hip. You often have to consider alternatives that are difficult, situations in which one wrong branch can mean the difference between success and failure, or, in the extreme, between life and death. Sometimes the choice is not obvious.

However, what you cannot afford to do is to become paralyzed and continue to defer the decision -- the "paralysis by analysis" syndrome. You must take some time, consider the options, gather data, and then decide. Once you decide, you go forward and don't second-guess yourself.

This may mean walking a fine line in terms of team dynamics. It is critical to build consensus around important decisions. However, consensus building itself can lead to paralysis. At some point, it is the leader's responsibility to make the decision if there is an impasse. If the team has been correctly assembled, they will then execute, understanding that this "best" decision is better than no decision at all.

I once was perched on a rock trying to decide which of two ugly paths to

follow. My climbing partner humored me for a little while and then said, "Well, you can make a decision or you can sit here and freeze to death." It's the same thing in software development.

Common Goal and Focus

On a good climb, everyone agrees on the purpose. Usually, that means getting to the top. Everyone focuses on that. Anything that doesn't contribute to the goal is ruthlessly avoided: no side trips, no one going off to pick flowers, no one stopping for a half hour to take pictures, and so on. The team can agree beforehand that some of these activities are part of the climb, and thus sanctioned; however, it is very important that there not be confusion as to the principal objective and how it is to be attained.

The software development analog is staying focused on the objective, which is usually to build a software system. Interesting software side trips can sabotage the whole effort, especially if one sub-team ends up in a crevasse. On a related subject, don't worry about style points. Mountaineers don't award any. Getting to the top "ugly" beats an aesthetic retreat anytime. This is not a personal opinion; this is the way most of the world keeps score.

Taking the Long View

In talking about climbing a mountain, we often make the mistake of focusing on getting to the top, as though that were the only goal. Getting to the summit and then getting the whole team back down the mountain in one piece is the real objective. (In a similar vein, the objective of the space program in the sixties was not to put a man on the moon; it was to put a man on the moon and bring him back alive.) The software analogy for this mistake, to stretch the point a little, is to focus all the effort on the development necessary to ship the initial version of the product. This allows you to "plant the flag," as it were. (Sometimes we proclaim victory even earlier -- on shipping a first beta copy, for example.) I contend that the moral equivalent of climbing the mountain and getting back down safely is shipping a software product that you can support and maintain. It means putting together a product whose software is robust, whose documentation is complete and understandable, and whose support burden doesn't kill the rest of the organization. So when we plan a software project, we must plan to do the whole job, not just plant the flag at the summit.

Competition Can Cause Irrational Behavior

One of my sons, Dave, points out that the "purity" of mountaineering stems in part from the romantic notion of an isolated team striving against the elements to achieve a noble goal. He also points out that this ideal is often violated in the real world by competition between teams. There may be two or more groups striving for the same peak, all desiring to "plant the flag at the summit" first. (Some areas of scientific research suffer from a similar gap between the romantic ideal and the real world.) In software development, of course, the competitive pressures are even more intense, as the product under development is a competitive weapon that the rest of

the organization wants in its arsenal immediately. The effects of this pressure can be catastrophic; often, en route changes to plan in response to the competition cause the team to take risks that are too high, leading to failure or worse.

Common Causes of Failure

Why do some software projects fail? For some of the same reasons climbing expeditions fail:

● Trying to get to the summit too quickly.

Analog:Unrealistic schedule from the start.

● Trying to get to the summit with clearly inadequate resources.

Analog:Not enough good people or equipment.

● Climbing with a team that is too big; the logistical and communications burdens overwhelm the team.

Analog:Too many average people.

● Taking too long; teams that stay on the mountain too long lose their verve, energy, and desire -- fatigue takes its toll. Also, they may flat run out of resources.

Analog:Software projects that stretch out forever, taking so long that the requirements get changed, sometimes multiple times.

● Sticking to the wrong route in the face of new information.

Analog:Ignoring data from early iterations; failure to adjust the plan during the course of the project.

● Getting wiped out by circumstances beyond the climbers' control.

Analog:Supplier or subcontractor failure; failure of a key component that was really an R&D activity, not product-ready.

● Not having a reasonable plan that everyone understands, believes can succeed, and is totally committed to.

Comment:Usually the result of a top-down, hierarchically-mandated plan.

● Failing to execute, within tolerances, against the plan.

Comment:Sometimes results from the accumulation of many small slips, rather than any one spectacular failure.

● Losing gumption when the going gets tough; not understanding that adversity is part of the endeavor.

Comment:Just as bad at the office as on the mountain.

● Not having any reserve for emergencies.

Comment:Usually the experience of the senior players can provide

some of this reserve; they'll know what to do when the unexpected happens.

Ingredients for Success

What are the hallmarks of successful teams? Here are a few:

● Good planners, but not obsessive about it.

Comment:A small amount of good planning beats a lot of detail every time.

● Ability to move fast with small teams; get on and off the mountain before Mother Nature changes her mind and decides not to let you climb this one this day

.Analog:Get it done before the requirements change.

● Talent for assessing incoming data in real time and making appropriate changes to the plan at appropriate times.

Analog:Use iterative development, integrate early and often, and use the information to adjust your plan.

● Good balance between top-notch individual contributors and good team players and leaders; the key here is usually very wide communications bandwidth.

Comment:Need to have balance and shared mind-set.

● Monitor against plan at the appropriate granularity.

Comment:Need a sense of when you are getting in trouble, and what to do about it.

● Leaders display maturity and good judgment.

Comment:Knowing when to amplify and when to dampen is important.

● Stamina: Understand that overall extended performance is much more important than burst-mode performance. It is no surprise that most climbing leaders come into their own in their forties, not earlier.

Analog:It would be interesting to see the statistics on software leads.

● Toughness: Ability to bear down when things go badly.

Analog:Important when tracking down really hard bugs, for example.

● Focus: Team stays centered on a clearly-defined objective.

Comment:All members know what, why, when, and how.

● Creativity: Willingness to experiment and to experience genuine joy in what they are doing.

Comment:Just like the rest of life.

The Human Factor

Well, in some respects this comes down to saying that people are everything. For software projects, as in almost everything else worth doing, I'd like to paraphrase the novelist Irving Stone: "Give me men (and women) to match my mountains."



the rational edge -- july 2001 -- rational java tools ...€¦ · rational java tools: bringing...

Documents