• How Web 2.0 changes software delivery teams and processes
• How Web 2.0 changes the way IBM operates as a tools vendor
• How Web 2.0 changes application lifecycle management

Some of the people who enjoyed the presentation were lucky enough to get one of our free USB sticks with a free version of Rational Team Concert.  If you weren’t one of the lucky ones, you can download a free copy of Rational Team Concert right here on the Jazz.net site.

Brian Bryson
Rational Quality Manager

• Does the team have a good understanding of the outcomes that the project needs to deliver?
• Does the team understand and agree on how those outcomes will be delivered?
• What does each person need to do, and by when?
• Can we be confident that we are all working to the same requirements? And when the requirements change, are we adapting to the change in a consistent, coherent way?
• How far along are we in meeting our requirements? What is left to do?  Where are the greatest risks?

With the introduction of  Collaborative Application Lifecycle Management (C/ALM), it has become easier to answer many of these questions.

Below is a short video showing a simple example of a business analyst using this solution to develop a set of business requirements and relating them to Release, Iteration, and Test plans. All members of the team (analyst, developers, and testers) use their normal tool of choice, thus ensuring that the developed solution is delivered and validated as defined by the requirements. The demo is not exhaustive. See the C/ALM features page for more detail.

The products used in this demo:

• Rational Requirements Composer 2.0
• Rational Team Concert 2.0.0.2
• Rational Quality Manager 2.0.0.1 ifix 2

To learn more about supported product versions, see the C/ALM versions page.

Process used:

• IBM Practices for Agile Delivery

For further information:

• RRC product Help: Creating and monitoring C/ALM associations
• Video:  RRC 2.0: Working in Collaborative Application Lifecycle Management
• Demo: Use RRC & Rational Quality Manager to align business with IT
• Presentation: Implementing Agile Requirements using RRC with C/ALM

This year, in addition to the standard conference tracks, there will be a new track called “Collaborative Application Lifecycle Management”. This track will feature the latest IBM Rational solutions and best practices that ensure effective collaboration, automation, and reporting across the software delivery lifecycle. The focus of this track highlights how teams can deliver more than the sum of their parts through team-based collaboration.

Get a jump start on your submission today by visiting the Innovate 2010 site and exploring the Call for Papers ideas and track descriptions. I hope to see you there!

Seth Packham
Jazz.net Website Team

With Rational Requirements Composer, we aim to help teams be more effective when they are …

• Running fast-paced projects
• Employing lean, light-weight requirements practices
• Involving a high degree of stakeholder participation and interaction

Let me explain these in reverse order.

Customer/stakeholder involvement

Project success is judged by your customers and other stakeholders. Good project leaders will help teams to identify, engage, and communicate with their stakeholders through the life of a project. Who are your stakeholders? Certainly your sponsor, who is paying the bills, and the end users of whatever you are building are stakeholders. In larger organizations the customers are often in the lines of business, and while they may be business experts, they typically are not experts in technology (this is one factor driving an increasing use of intuitive visual notations as means of bridging the IT/line-of-business communication gap).

Use scenarios in multiple notations to uncover customer needs

Your stakeholders probably include marketing/product management; and don’t forget the operations/production teams who have to live with what you produce. In larger organizations, there are many other corporate stakeholders, for example the keepers of your project governance process and your compliance/legal department. Project team members themselves are also stakeholders: developers, independent testers, documentation team, user experience professionals, etc. The better each person understands the organizational context, business goals, and reasons why one thing is more important than another, the more value he or she can deliver as part of the project.

These stakeholders all have something to bring to requirements definition. Together they understand more of the possibilities and constraints than the project team alone can identify. Your project is more likely to deliver valuable outcomes if you involve them early and often in expressing the business context, clarifying the goals, and validating the work done to date. This is challenging enough even when teams and their stakeholders work in the same building. It’s worse for many teams, who are continually crossing boundaries that impede effective collaboration: organizational, geographical, cultural, and linguistic.

Project teams are most effective when they work with a common understanding of priorities and requirements.  Developers need deep visibility into requirements; independent testers need to prove that the requirements are being met.  The first results of the Jazz Collaborative ALM project now make possible new levels of team alignment and information visibility among the users of Requirements Composer, Team Concert and Quality Manager.  More on this below.

With Requirements Composer you can:

• Use the best notations for expressing your ideas (using UI storyboards, process diagrams, use case diagrams, text, office documents, your favorite mind mapper, snapshots of whiteboards, etc.)
• Tie this information together in meaningful ways for yourself and the rest of the team (using links, collections, attributes, tags)
• Make team activity visible, including conversations, what’s changing, history, and the artifacts themselves (using dashboards, review and approval workflow, threaded group comments)
• Make it easy for stakeholders to get involved (using the web client, review and approval notifications)
• Align and inform development and test activities with customer needs and requirements (using Collaborative ALM integrations)

Lean practices

Many teams use documents and spreadsheets to capture and organize requirements – and then struggle with the limitations of this approach. With Requirements Composer we aspire to help these teams bridge their information islands, better organize, use and reuse this information.  We are doing another kind of bridging as well: in the business domain, requirements information is typically document-oriented (presentations, diagrams, documents); in the solution domain, it is typically record-oriented (work items, defects, test plans, test cases).

Lean means “just enough” process and just enough documentation; the right balance differs by organization and project. For example, in long and complex projects (for example if you are building a jumbo jet, or you have to prove compliance with a large set of policies) you can increase your chances of success if you use a high-end requirements management tool like Rational DOORS.

With Rational Requirements Composer 2.0 we are primarily targeting teams building and evolving IT systems needing more than documents and spreadsheets for their requirements but less than Rational DOORS.  RRC is applicable to teams using waterfall, iterative, and agile-at-scale methodologies.

Alternatively, teams managing requirements in DOORS or Rational RequisitePro can use Rational Requirements Composer to improve their requirements definition practices. You can find more information on integration scenarios in our wiki.

Fast paced

For a long time Rational (and many others) have advocated the use of iterations in project methodologies. Each iteration gives your team opportunity to reflect on what’s been done thus far, get additional validation from customers and other sponsors, learn more about what the project needs to deliver, and prioritize the work for the next iteration. We have had this dynamic in mind as we’ve built Rational Requirements Composer.

Many requirements get fleshed out just-in-time, often as part of solution design.  We see with on our own team: our user experience (UX) professionals use Requirements Composer storyboards to describe important user scenarios and flesh out detailed requirements as they engage in conversations with customers, marketing, and other project team members.  Maybe you have sat with them and provided your own feedback in the Users First lounge at a Rational conference.  Rational Requirements Composer helps us iterate quickly and make changes consistently in our project artifacts while still seeing and using prior versions; our UX team love Requirement Composer’s UI sketches and storyboards in particular, because they provoke good requirements-focused conversations with both non-technical and technical people; and the way we’ve built in reuse and inheritance, changes can be made in one place and consistently applied across many wireframe mockups.

Early design of the RRC 2.0 review and approval workflow; from a storyboard employed in the Users First Lounge at the Rational Software Conference 2009 in Orlando Florida

Collaborative Application Lifecycle Management

Jazz is a vision, an architecture, a community, and a growing set of interrelated tools that bring teams together in productive collaboration across the project and application lifecycle.  Through the Jazz Collaborative ALM project we are defining cross-role and cross-tool scenarios according to these guiding principles:

• Enable users to weave a ‘web’ of ALM resources that they can use to collaborate, navigate, and track status
• Enable transparency with dashboards that support viewlets from other repositories
• Let users work in the tool that best suits their role and minimize the need to use a separate tool
• Allow our customers to choose the tools that best suit their needs by providing flexible and open integrations

This is a new way of doing integrations inspired by the way people collaborate over the the Internet. Requirements Composer 2.0, Team Concert 2.0 and Quality Manger 2.0 are the first to implement scenarios defined in C/ALM, including links between requirements, work items and tests; rich hovers that show information from the other end of a link (which may come from other tools); and dashboard viewlets that consolidate relevant information from across the tools.

Dashboard can include information from Team Concert and Quality Manager

Learn more

I suggest the following resources to learn more about Rational Requirements Composer (RRC) 2.0.

• Download Rational Requirements Composer and see for yourself.
• What’s new webcast [18 minutes] by George Decandio (Senior Development Manager) and Vishy Ramaswamy (Requirements Composer architect).  They made this recording at the end of September 2009 when we released the last beta.  Most of the major features of V2 were in this beta.  See also the New and Noteworthy tab, which summarizes the new features.
• The Collaborative ALM integrations with Requirements Composer, Team Concert and Quality Manager are based on Jazz Integration Architecture principles and the APIs defined as part of the cross-vendor Open Services for Lifecycle Collaboration (OSLC) initiative.
• The RRC product team use RRC in projects to develop RRC.  We talk about our experience developing the review and approval workflow for RRC 2.0 in the blog post Only 5% are Requirements and in this video.
• You may be interested in some of the other RRC product integration scenarios and their status.
• The jazz.net library includes a growing number of short RRC videos and and information about Collaborative ALM.
• There is a developerWorks primer on Storyboarding in Rational Requirements Composer.
• The release notes and product documentation are available in the RRC information center.
• IBM publishes announcement letters for each product and major release; you can find them for your country at the IBM offering information portal (search for “Requirements Composer”).

And to learn more about implementing a stakeholder-centered development approach, I recommend Outside In Software Development: A Practical Approach to Building Successful Stakeholder-based Products by Carl Kessler and John Sweitzer.

All joking aside, we recently we kicked off our design partner program for Collaborative ALM (C/ALM), and I provided the following introduction. Apparently it worked as I’ve had several requests for a recorded version. It’s just me talking to a couple of slides without any fancy demos, but I do manage to define Collaborative ALM and why you need it, AND I keep it under 5 minutes. This video is best viewed in full-screen mode.

If you are an IBM customer and would like to learn more about the design partner program for Collaborative ALM, please contact Erin Kelley O’Connor, Design Partner Program Manager (oconnore@us.ibm.com).

–
Carolyn Pampino
Collaborative ALM Lead

This is where OSLC comes into play. It defines a small but important set of methods for applications (or components thereof) to interact with each other. Complicated interfaces that impose a lot of requirements onto clients are unlikely to be used and are an obstacle on the way to the desired level of integration. So simplicity, stability, and standards compliance are key for such an interface, and are the driving factors behind OSLC. It shouldn’t take much more than an HTTP client and an XML or JSON parser to use the interface. Resource representations must be stable and self-explanatory; assumptions and out-of-band knowledge imposed on clients must be kept to a minimum. And it shouldn’t be a big effort to implement the interface.

Here, I am focusing on the Change Management part of OSLC (OSLC-CM) that allows you to query, link, fetch, create, and update change requests. OSLC is a community effort and the RTC Work Item team was part of the OSLC-CM specification group. Others in the workgroup included Mik Kersten and Robert Elves of Tasktop Technologies and the Eclipse Mylyn project; Randy Vogel and Gary Dang of Accenture, and Steve Speicher, Steve Abrams, and Andre Weinand from IBM. Version 1.0 of OSLC-CM is fully implemented in RTC 2.0.

Consuming OSLC-CM

Examples explain more than words alone, so let’s look at what we would leverage from OSLC-CM in RTC to implement a mobile web application which allows us to search for change requests.

Mobile Search UI

We have a UI where a user enters some search terms. The matching change requests can be found using a simple HTTP GET to the following URL (not escaped for better legibility), which contains the search terms as a parameter:

https://example.org/jazz/oslc/contexts/_QwUc0I_YEd6lV_dBYBhShg/workitems?oslc_cm.query=oslc_cm:searchTerms="syntax"

But how does our application know this URL? It looks quite RTC-specific and it contains this weird UUID segment. The OSLC specification describes a discovery chain (as known from AtomPub) where clients need to know just a single entry point to find all other necessary URLs. In the case of Jazz based products like RTC, this is:

https://example.com/jazz/rootservices

The root services document allows us to discover the query URL we need by following the references to the services document:

The Discovery Chain

So the required out-of-band knowledge to get at the query results is limited to this root URL plus some XML elements and their attributes that point to the catalog.xml, services.xml and eventually to the query URL. All of them are defined by OSLC. This means that our application will still work if RTC decides to expose querying under a different URL. The best part is that our application will also work with any other system that implements OSLC-CM 1.0 — ClearQuest, for example. We only have to configure this single entry point in our application.

Now, what does the search response look like? We have to get the change request title in order to show it in the list. As the application is written in JavaScript, JSON is our favorite representation because we get the JS object structure for free. OSLC-CM allows us to fetch resources in various formats like JSON, XML, and ATOM. In RTC, we also support HTML (for hovers) and there are more to come, like CSV or maybe PDF. Requesting the results in a specific format is done using the standard HTTP mechanism, by setting an “Accept:” header:

GET {query URL from the discovery document}?oslc_cm.query=...
Accept: "application/json"

The result is a JSON document that describes all attributes of the matching change requests. The document looks quite big, so we take a closer look at the transferred data size:

Transfer Size for Full Representation

We are developing a mobile application so we have to keep the data transfers small, as bandwidth is limited (and maybe expensive). For the result list, we only need the summary for now, and everything else just slows down our application (and the server as well).

OSLC-CM specifies a solution for this in the form of the oslc_cm.properties parameter. It defines the shape of a resource, which can be tailored to any specific need. We can limit the number of included attributes, but we can also inline reference resources to avoid separate roundtrips for fetching them.

GET {query URL from the discovery document}?oslc_cm.query=...&oslc_cm.properties=dc:title
Accept: "application/json"

Let’s take another look at the data and the transfer size:

{
    "oslc_cm:totalCount":4,
    "oslc_cm:results":
    [
        {
            "dc:title":"Specify new assertThat syntax",
            "oslc_cm:score":100,
            "rdf:resource":"https:\/\/example.org\/jazz\/resource\/itemOid\/com.ibm.team.workitem.WorkItem\/_oU16MH0YEd6xQ8_tWGUF5g"
        },
        {
            "dc:title":"Provide improved Assertion syntax",
            "oslc_cm:score":100,
            "rdf:resource":"https:\/\/example.org\/jazz\/resource\/itemOid\/com.ibm.team.workitem.WorkItem\/_of-MIH0YEd6xQ8_tWGUF5g"
        },
        {
            "dc:title":"Based on the assertThat syntax we should provide assumptions and theories support",
            "oslc_cm:score":63,
            "rdf:resource":"https:\/\/example.org\/jazz\/resource\/itemOid\/com.ibm.team.workitem.WorkItem\/_oehaoH0YEd6xQ8_tWGUF5g"
        },
        {
            "dc:title":"Implement new assertThat ",
            "oslc_cm:score":25,
            "rdf:resource":"https:\/\/example.org\/jazz\/resource\/itemOid\/com.ibm.team.workitem.WorkItem\/_obk0UH0YEd6xQ8_tWGUF5g"
        }
    ]
}

Transfer Size for Tuned Representation

The response document is now eighteen times smaller, only 850 Bytes instead of 15KB for the 4 results. Now we are ready to render the change requests, which doesn’t take more than a couple of lines of JavaScript. Note that we also get a reference to each change request’s URL, which we would use to get at the full data, again by a simple GET and Accept header.

var response= eval("(" + responseJSON + ")");
var results= response["oslc_cm:results"];
for (var i= 0; i < results.length; i++) {
   var changeRequest= results[i];
   var title= changeRequest["dc:title"];
   var url= changeRequest["rdf:resource"];
   ...
}

While querying for text looks quite easy, what about more structured queries or creating a new change request? This is usually harder, especially in a highly customizable environment like RTC. Work item types and their attributes are freely configurable, and so are enumerations like “Severity.” A client cannot assume that there is a “Defect” type or a specific severity. OSLC-CM has three ways to address this:

1. Delegated UI: Instead of having all clients deal with the details of how to fetch the right value sets, finding out which attributes are required and so on, OSLC-CM specifies a way for change management service providers to expose ready-to-use HTML modules for creating and searching change requests that can be embedded into client applications. The URLs of these modules are found via the discovery document. Client applications are completely shielded from the implementation details of the module and will profit from any improvements and new features that may be added in the future. There is only a thin JavaScript interface to these components, e.g. to get the URL of the selected change request. The following screenshot shows the embeddable HTML module of a simple work item editor:
   

   Create Plan Item Module

2. Facades: Many clients have the need to work with conceptual values like a type “Plan Item,” a severity “High” or a state “Ready for testing.” In a freely customizable environment, these conceptual values must be mapped to actual Types, Severities, or States. This is what we call a facade. A client can work with the facade values and mapping these to the actual values is done as part of the process customization. An example from OSLC-CM is the UI module dialogs mentioned above. A client can express that the dialog should only be able to create plan items, and doesn’t have to worry about how the project is configured and which process is used. This screenshot shows the (admittedly small) UI of RTC 2.0 to map some facade entities to the concrete entities of a customized process:
   

   Facade Configuration

   Future work in the OSLC-CM area will push this concept even further. Clients will have a way to express what conceptual values they want to work with. RTC will then provide the mapping UI and the runtime bindings between the facade and actual values generically.

3. Metadata API: For the cases where both Delegated UI and Facades are not sufficient, OSLC-CM 2.0 will specify how to get at the metadata. This will allow us to build applications like a Work Item Editor that can handle any OSLC-CM compliant change request.

Implementing OSLC-CM

So far, we have seen what OSLC-CM does for consumers. With an increasing number of clients that work with OSLC-CM, it may become interesting for other change management applications to expose the same interface. OSLC-CM 1.0 was created with integration scenarios in mind and it doesn’t specify many attributes of a change request or complex meta-data structures. It focuses on linking and querying change requests, the two building blocks for surfacing interesting relationships between lifecycle resources. So the specification is rather small and was easy to implement for RTC.

The concept of a Delegated UI allows us to reuse existing components and to make them available in a standardized way. In RTC, we actually reused the existing Dojo-based widgets for this.

And finally, the discovery documents allow us to surface more functionality over time. Clients should be able to deal with the missing parts.

An interesting aspect of implementing OSLC-CM for RTC Work Items (and thinking in terms of resources and representations) was that many things fell into their place: An HTML hover is just another representation of a work item resource, and we leverage that both in the Web UI and the Eclipse UI and make it available to other parties via the Compact Rendering specification.

HTML Hover Representation

The CSV format as a mechanism to export query results to spreadsheets is also just another representation of a work item collection. The shape defined by oslc_cm.properties determines the exported columns in this case.

Where is OSLC-CM going?

Work has already started on OSLC-CM 2.0, which will specify more functionality for more demanding clients. There will be access to metadata, allowing clients to dynamically find out more about attributes, like their value sets and their type. More of the common change request attributes will become part of the specification.

RTC will also consume OSLC-CM in more places. Importing work items from arbitrary sources could be one application. Such an importer would create the work items using the OSLC-CM API, enabling it to import from Bugzilla, CSV etc. into any OSLC-CM compliant repository. OSLC-CM resources would also be supported as an import format, which brings it full circle: Transfer resources from any OSLC-CM compliant repository to any other.

Who is using the RTC OSLC-CM* implementation now?

• OSLC-CM enables Mylyn to write a single connector that can work with any OSLC-CM compliant change management system
• Rational Quality Manager uses OSLC-CM to link test cases to defects and plan items, to find out which plan items are ready for testing and more.
• Rational Requirements Composer uses OSLC-CM to link requirements to change requests
• The Git integration uses OSLC-CM to link work items to Git change sets.
• RTC Build uses OSLC-CM to create work items from failed builds and to link build results to existing work items.
• RTC Work Items uses the OSLC-CM mechanism of exposing resources in different formats for rich hovers.

* Some clients use single change request attributes that are not specified by OSLC-CM 1.0

Learn more about OSLC and OSLC-CM

• OSLC Home: http://open-services.net
• OSLC on Twitter: http://twitter.com/oslcNews
• OSLC-CM Home: http://open-services.net/bin/view/Main/CmHome
• Details on the RTC Implementation: https://jazz.net/wiki/bin/view/Main/ResourceOrientedWorkItemAPIv2
• Carolyn Pampino on the RQM-RTC integration: http://jazz.net/blog/index.php/2009/08/26/sprint-alignment-for-developers-and-testers/
• Scaling Agile with C/ALM eBook: http://www.infoq.com/resource/articles/scaling-agile-with-calm/en/resources/InfoQ-IBM-ScalingAgilewithCALMeBook.zip

One of the biggest challenges for testers is staying in sync with the development plan. Agile teams look to integrate testers as an integral part of the team. What testers and development teams need is the ability to link their efforts within the context of a sprint.

Rational Team Concert enables agile teams to manage their Iteration (or Sprint) using a backlog of prioritized work-items. At the same time, Rational Quality Manager provides a collaborative environment for test planning, construction, and execution. Testers can create, manage and measure their effectiveness using Test Plans, Test Cases, Test Scripts, Execution Records and Results.

In the 2.0 versions of Rational Team Concert and Rational Quality Manager, testers can link test cases to development work-items. What’s particularly interesting in this integration is that testers can create these links without leaving the Quality Manager user interface. Developers interacting with the work-item in Rational Team Concert can see the link to the test case, and run queries to determine test coverage or test status.

In addition, this demonstration highlights the power of the Jazz Foundation and an implementation of the OSLC change management service. Some things to note:

• The web page banner for both products is new and uses the framework provided by the Jazz Foundation.
• You will see the tester interact with a ‘link picker’ that is used to locate a work-item in Team Concert and create the link between the test case and the selected work-item. The link picker is a dialog hosted in Quality Manager that ‘consumes’ the Team Concert change management service. All semantics in the dialog are ‘provided’ by Team Concert. The integration between Rational Quality Manager and Rational Team Concert is as simple as a single URL to call Team Concert’s link picker. This is an implementation of the OSLC change management service. The integration is simple, resilient, flexible, and open (by supporting the OSLC specification).
• The Rational Team Concert repository essentially ‘disappears.’ Because the Team Concert user interface comes to the tester, the tester doesn’t have to know the details about the repository. They don’t even have to leave their tool of choice! The number of context switches between products is drastically reduced (there aren’t any), and the creation of links between artifacts is reduced to the click of an “OK” button.
• The ability to provide a rich hover when the mouse ‘hovers’ over a link is provided by the foundation and each product adopts and provides rich hover support. In the demonstration, Team Concert adopted the rich hover for work-items. When a Quality Manager user hovers over a link to a Team Concert work-item, detailed information about that work-item is presented to the tester.
• Link types are used to describe the link between artifacts. Test case tests plan work-item. Plan work-item is tested by test case. These link types are used to provide interesting queries such as “All plan items with failing test cases”

This style of linking between repositories helps to break the silos between developers and testers by giving them insight into the status of each other’s work. Teams that adhere to the Agile policy that the work is not complete until the tests have passed can leverage these links to ensure coverage, understand the quality of the work-items and determine when they are done, done, done.

This is the first of several demonstrations that we’ll provide to showcase the new wave of Collaborative ALM integrations. And if you can’t wait for the next recording, you can read more about our Collaborative ALM solution by downloading the eBook, titled Scaling Agile with Collaborative Application Lifecycle Management from Infoq.com. (http://www.infoq.com/articles/scaling-agile-with-calm)

Now let me introduce Rational Quality Manager 2.0 to you — the new center of your test universe. As stated above, this release was driven by customers as we prioritized what was done based on your feedback. We simplified for the novice user and we also raised the level to fulfill management needs. This allowed us to accelerate the usage learning curve to provide faster time-to-value for the test organizations using Rational Quality Manager. Automations of repetitive tasks and reuse of artifacts will save organizations time and money, resources they can use to drive more quality into their products. Quality must be addressed upstream, early on, as we have always advocated in our own best practices: Test Early and Test Often.

One of the biggest concepts from customers was to “let a computer be a computer”. This is a concept of smart automations that will continue to drive Rational Quality Manager forward. One example of this is the cost of duplicate defects (once a duplicate is in the system, it takes an average of four to ten hours to determine that a duplicate even exists). Research done by IBM GBS has shown that if we could prevent duplicates, an average of $175,000 a project could be saved. So we provided the ability to search for derived related effects as you submit a defect in order to help you determine if it is a duplicate before entering into the system from Rational Quality Manager. Other smart automations include time saving features like copying a test case description to a manual test script when first creating the script, creation of stubbed test cases from requirements, and scheduling of activities initiated even from a build completion trigger.

We also have to provide mechanisms to allow consumers to make prioritized decisions early in their test process by leveraging concepts like risk based testing. In risk based testing, attributes of test artifacts are associated with risk thresholds, which are scored to help you prioritize your testing efforts as release cycles get more and more compressed. The goal here is to focus your efforts on the right things. When you capture this information in the system, you can more easily determine what to prioritize when two weeks are suddenly chopped off your test schedule, instead of scrambling to determine what you can’t test. You help yourself make those decisions via your process and risk scores.

Leveraging the context of Application Lifecycle Management and tying Rational Quality Manager into the Collaborative ALM initiative gives organizations the traceability between artifacts for the application lifecycle, the ability to provide not only team collaboration but organizational collaborations. Imagine this scenario: A completed build triggers a deployment of a test environment and executes tests that had previously identified defects in that same environment; then imagine receiving an automatic report telling you the defects that were retested. Imagine the time you’ve saved to focus on quality and to run other tests.

We bring this all together for customers with reports, dashboards, and metrics. Reports are your test organization’s primary deliverable to management. The reports provide status to management and drive the test team activity — Are we done testing? How much more do we have left to do? What is the overall quality of the product we are building? Adopting measures that align with MCIF allows us to continue to promote best practices to organizations and provide them the ability to not only focus on quality at the practitioner level but to communicate their overall quality status to all interested parties.

I would also like to call your attention to the online version of help for Rational Quality Manager, as it contains additional content from the version installed with your product. You have several options for viewing this additional content.

• You can view the most up-to-date version of Rational Quality Manager 2.0 Help.
• You can review and comment on our Rational Quality Manager Help in progress here on jazz.net. This is where we will continue to develop the Help after 2.0 is released.
• You can also replace the installed Information Center with the newer version. See “Customizing the help” for details.

Now we want to hear more from you. If you have opinions on how we should evolve Rational Quality Manager, please submit an enhancement request! Let’s take advantage of the transparency of jazz.net and take Rational Quality Manager to the next level.

Brian Massey
Product Manager Team Lead