Collaborative Lifecycle Management Information Model

by

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

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 artefacts 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.

Whats wrong with Change Management State Schemas?

The artefact 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 complex schema. In CALM the state of is distributed over a network of linked and related artefacts. 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 allowing teams to plan changes and work using agile methods
  • Support for centralised deployment or multisite synchronisation
  • 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.

CQTR-1024x487

Whats new with Collaborative Lifecycle Management?

The artefact 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 of is distributed over a network of linked and related artefacts. 

CLM-InformationModel-1024x591

  • 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 artefact types. For example managing tests needs the specification of Test Scripts, Test Cases, Test Suites, Test Plans, Test Results.
  • Each artefact as a state. A Requirements may be New, Reviewed, Approved, Implemented, Verified and Delivered. Or even Duplicate or Withdrawn. The state forms a state model.
  • Artefacts have relations, or links, to other artefacts of the same or other domains. A Requirements is validated by a Test Case. A Defects is planned for an Iteration.
  • Artefacts form hierarchies. A Software Requirements satisfies a Subsystem Requirements, that in its turn satisfies a System Requirements, that in its turn satisfies a Stakeholder Requirement.
  • Artefacts has 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 a 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 artefact and state models are defined by the client organisation and is tailored to implement the development process adopted.
  • The artefact link models are defined by the client organisations
  • Considering links to be URLs allows artefacts to be distributed over multiple services, locally or globally, and provides flexible centralised or distributed deployment options.

Lets consider an example by walking the structure in the image below

  • A Requirement is a part of a larger Requirements Module or Collection specifying a system or an application 
  • Requirement is implemented as a Story
  • The Story may be decomposed into Tasks and there may be Defects on the emerging implementation
  • The Story is planned for an Iteration in a Release
  • Requirement and Story is tested by a Test Case
  • 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 organised 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 is integrated into a Build
  • Tests Cases generate Test Results on a deployed Build 

Formulating a 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 artefacts
  • 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 or 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 covers Change Management, Requirements Management, Enterprise Integration Builds and Test Management. It also discusses metrics for team success in Application Lifecycle Management.

PageLines