Collaborative Lifecycle Management Information Model

The leading ALM solution from IBM is the Collaborative Lifecycle Management (CLM), which consists of Rational Requirements Composer (aka Rational DOORS NG), Rational Team Concert, Rational Quality Manager, and Rational Design Manager. The Jazz platform is strategic for implementing the Rational solution for CLM. The Jazz platform is all about collaboration; it allows individual products to integrate better and more easily, and allows the users of those products who take on distinct roles to work more effectively together than has historically been possible. The Jazz platform supports a more collaborative approach to ALM tools and their users. The approach is open. It leverages the standards used by the Internet. Just as the internet works with data spread around the world, the approach is to allow development team data to be spread around an organization, and yet to have development artifacts as easily accessible as surfing the world-wide-web. Through the support for OSLC, integrations can be provided for Jazz-based products. Additionally, third-party vendors and customers can consume or provide their own OSLC interfaces to support heterogeneous environments made up of Rational, third party, and/or customer solutions. The combination of Jazz and OSLC provides the ability to have unprecedented collaboration, transparency, automation, and traceability.

What’s wrong with Change Management State Schemas?

The artifact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CQ the complete lifecycle was managed in the complex schema. In CALM the state is distributed over a network of linked and related artifacts. User research on the use of schema-based change management systems identified user pain points

  • Complex information schemas modeling artifact types and lifecycles all in ONE schema.
  • Weak integrations across lifecycle tools with demands on data synchronization across repositories. Most schemas reference other schemas on the same installation. 
  • Limited plan information allows teams to plan changes and work using agile methods
  • Support for centralized deployment or multisite synchronization
  • Support for rich client installation at every user desktop

 

Research at our enterprise clients reports on similar pain points in establishing a state schema, resulting in years in negotiating a corporate-wide schema in ClearQuest that managed the lifecycle of Change Requests as a single state model.

Link
Collaborative Lifecycle Management Information Model

What’s new with Collaborative Lifecycle Management?

The artifact information model used by the Collaborative Lifecycle Management solution, adopted and extended in the IoT Collaborative Engineering solution, is radically different compared to classic change management and lifecycle tools like Rational Clear Quest. In CLM the state is distributed over a network of linked and related artifacts. 

  • An application or system lifecycle is composed of multiple domains and disciplines; Requirements, Designs, Tests, Change Requests, and Plans
  • Each discipline defines a set of core artifact types. For example, managing tests needs the specification of Test Scripts, Test Cases, Test Suites, Test Plans, Test Results.
  • Each artifact has a state. A Requirements may be New, Reviewed, Approved, Implemented, Verified, and Delivered. Or even Duplicate or Withdrawn. The state forms a state model.
  • Artifacts have relations, or links, to other artifacts of the same or other domains. A Requirements is validated by a Test Case. A Defect is planned for an Iteration.
  • Artifacts have relationships. A Software Requirements satisfies a Subsystem Requirements, that in its turn satisfies a System Requirements, that in its turn satisfies a Stakeholder Requirement.
  • Artifacts have attributes that classify the type. A System Requirement, Subsystem Requirement, and Software Requirement all have shared and unique attributes. Some are mandatory, others are optional.
  • Links have types that carry semantic meaning. A link between two works items may, for example, be a Parent, Child, or Blocks.
  • The semantic interpretation of the link provides insights into the state of the systems. Identifying all Requirements in the current Iteration that has Blocking defects is a good insight into the readiness to release and any unstable/unavailable content of the release.
  • The artifact and state models are defined by the client organization and are tailored to implement the development process adopted.
  • The artifact link models are defined by the client organizations
  • Considering links to be URLs allows artifacts to be distributed over multiple services, locally or globally, and provides flexible centralized or distributed deployment options.

Link
Collaborative Lifecycle Management Information Model

Let’s consider an example by walking the structure in the diagram

  • A Requirement is a part of a larger Requirements Module or Collection specifying a system or an application 
  • A Requirement is implemented as a Story
  • The Story may be decomposed into Tasks and there may be Defects in the emerging implementation
  • The Story is planned for an Iteration in a Release
  • A Requirement and Story is tested by a Test Case
  • A Test Case will generate a Test Result in a Test Iteration / Milestone
  • A failing Test Case will result in a Defect on a Story
  • All tests are a part of a Test Plan testing a Release
  • Implementing a Story will create a Change Set of changes in a versioned File
  • Changes to a File is organized by Streams making sure that only related changes go into a Build
  • A Build is made up of Change Sets on versioned Files in a Stream
  • A Workspace is a collection of Streams that are integrated into a Build
  • Tests Cases generate Test Results on a deployed Build 

Formulating an ALM User Experience Strategy

Based on our research we formulated the ‘ALM Principles’ that was validated by our sponsors

  • Development is not an island unto itself; it provides a service to the business
  • There are cycles within cycles many of which are ripe for automation
  • A Solution is created by a social network of people producing artifacts
  • Solutions never die, they are refined and maintained for years
  • Assets are Investments

Reporting on Collaborative Lifecycle Management

In 2009 I co-led the publishing of the CALM Redbook together with Carolyn Pampino and a group of Rational SMEs. The Redbook provides a blueprint for Collaborative Application Lifecycle Management by using an end-to-end reference scenario for deploying the new Rational products and ‘Agility at Scale’ into an existing enterprise environment. The scenarios produced for the Redbook cover Change Management, Requirements Management, Enterprise Integration Builds, and Test Management. It also discusses metrics for team success in Application Lifecycle Management.

 


“ALM is the thread that ties the development lifecycle together” – Forrester analyst Carey Schwaber”