alm integration in a web 2.0 world

© 2009 IBM Corporation

Session SLI11

ALM Integration in a Web 2.0 World

Steve AbramsSenior Technical Staff Member

Lead Architect, OSLCCTO Team IBM [email protected]

Session SLI11

© 2009 IBM Corporation

IBM Rational Software Conference 2009

SLI11 – ALM Integration in a Web 2.0 World

Tool Integration. Ouch.

N^2 Point-to-point

Closed APIsVendor lock-in

Tight Coupling

Lockstep upgradesVersion incompatibilities

2



3

The Internet – an inspiration for an architecture

Amazingly scalableIntegrates information on a massive scaleInfinitely extensibleCollaboration on unprecedented scaleWorld-wide information visibility

Web Pageshtml, css, js

Audio/Videomp3, divx, mov

Documentspdf, doc

Indexgoogle, yahoo

HTTPget/put /post



4

So what if…

All data are resources with URLsResources have representationsRepresentations specified independently of tools as standards

Links are embedded URLs

Multiple Tools access data

REST (Representational State Transfer)

Diagrams

Requirements

ChangeRequests

GlobalIndex

HTTPget/put /post


SLI11 – ALM Integration in a Web 2.0 World 5

Open Services for Lifecycle CollaborationAn initiative aimed at simplifying tool integration across the software delivery lifecycle

Community Driven – specified at open-services.net

Specifications for ALM Interoperability

Inspired by Internet architectureLoosely coupled integration with “just enough” standardizationCommon resource formats and services

A different approach to industry-wide proliferation

Open Services for Lifecycle Collaboration

Barriers to sharing resources and assets across the software lifecycle

Multiple vendors, open source projects, and in-house toolsPrivate vocabularies, formats and storesEntanglement of tools with their data

Core Services

DiscoveryAdministration

(users, projects, process)

Query

Data Warehousing

Storage

Collaboration

Additional Services

Open Lifecycle Services

Data

REST API

Task Specific Logic

CoreLogic



6

Open Services for Lifecycle CollaborationPutting the approach into practice

Step 1: Internet URLs for resources

Step 2: Shared resource formats

Step 3: Shared resource services



OSLC is trying to avoid

A vendor-led “partners” program

Brittle integrations based on tight partnerships

Mandatory repository (design time or run time)

“Boil the ocean” metamodel design

Requiring a common code base or technology

Premature standardization



Why does IBM Rational Care?• Good for our business

• Stable interfaces to overlapping products

• Dramatically reduce integration, support, maintenance costs

• Reduce time-to-market

•Good for our customers• Freedom of choice• Flexibility of incremental adoption• Improved productivity

• Good for our Industry• Interoperability increases the value of

every offering• Spark innovation around the edges• Enable new business opportunities• Grow the pie

2004 20122008

Current Course

Pre-Standards

Fragmented standards maintain lock-in

Business value limited

Common standards promote interoperability

Business value of every offering rises

Inte

grat

ion

M/W

Rev

enue



The first wave of Jazz integrations

Quality team collaboration

RationalQuality Manager

Coordinate quality assurance plans, processes and

resources

Business expert collaborationElicit, capture, elaborate, discuss

and review requirements

RationalRequirements

Composer

RationalTeam Concert

Core team collaboration"Think and work" in unison and provide real-time project heath

Architect Developer

REST API

QualityManagement

REST API

Requirements Management

Change & Configuration Management

REST API

AssociationChanges; notification

Tester finds defects,generates work item

Defect statusDefects closed against

requirements

Requirement linked to work item

Analyst Tester



Open Services for Lifecycle Collaboration (OSLC)Loosely coupled integration

Change MgmtSystem

Test ManagementPOST, Query, etc

change requests

Test management system can interface with any OSLC-compliant change management system



JIA: Enables deeper integration

Rational TeamConcert 2.0

Rational Quality Manager

POST, Query, etcchange requests

Jazz Foundation Services

Jazz Dashboard Application



Open Services for Lifecycle Collaboration

An open community of vendors and users focused on specifications for integrating software delivery lifecycle data and tools

Integration through technology-neutral services based on Internet standards and protocols

Participate at open-services.net



Rules of Engagement

13

Open forum for participationCreative Commons LicensingPatent Non-Assert



What is the specification process?Minimalist/additive approach

Not a “complete” definition for a given area

Scenario driven

Scoped -- specification versions

Open participation, but active core group(topic lead is driver)

Identify Scenarios

Iterate on working drafts

Call it a spec

Gain technical consensus, collect non-

assert statements



Open Services for Lifecycle Collaboration (OSLC)Loosely coupled integration

Change MgmtSystem

Test ManagementPOST, Query, etc

change requests

Test management system can interface with any OSLC-compliant change management system



OSLC Change Management 1.0 SpecificationKey scenario elements

1. Create Release Plan - An analyst defines requirements in a requirements definition tool. He links his requirement to a Plan Item in a Change Management tool. He can traverse the link and prioritize the release plan.

2. Align Plans - This scenario involves aligning what (requirement) with 'when' (plan). It includes the alignment of requirements with development and test efforts.

3. Find and Fix a Test failure - A tester executes a test and discovers a defect. The defect is created in the change management system with bi-directional links back to the test execution. The development team triages and fixes the defect. The tester monitors the status of the defect using his dashboard. When he sees the defect is fixed and the build is ‘green’ he deploys the build then verifies and closes the defect.

Scope of resource descriptions and services (CM 1.0)Change requests, collections of change requests

Working group membershipAccenture (Randy Vogel, Gary Dang), IBM (Steve Speicher, Andre Weinand, Steve Abrams, Carolyn Pampino), Tasktop/Eclipse Mylyn(Mik Kirsten, Robert Elves)

Specificationshttp://open-services.net/bin/view/Main/CmHome

Implementing productsImplement the services -- RTC 2.0, RCM/CQ 2.0 Use the services – RQM 2.0, Eclipse MylynPlanned: Implement the services – Rational (Telelogic) ChangeUse the services – RRC 2.0

Milestones:11/05/2008 - Introduce topic

02/21/2009 - Complete scenarios

11/17/2008 - First draft specs created

04/15/2009 - Start convergence

05/29/2009 - Finalize CM 1.0 spec



Key Technical Areas of Contribution

Web UI delegation with cross-site messaging supportLeverages existing standards

Various resource creation modelsAccommodates interactive and batch models

Service discovery and descriptionConsumers of services need to know very little to get started (a URL)

Resource format definitionsXML and JSON formats for: ChangeRequests, Collections and Errors

Simplified query modelCan be encoded in a URL, limited capability

Uniform way to request resource propertiesEnables clients to optimally make requests (just enough, all in one request)



Service Discovery



UI Delegation forResource Creation andSelection



Use Delegated Work Item Picker



Use Delegated ClearQuest Record Picker



Change Management – Change Request ResourceXML Representation Summary: ChangeRequest? Element

<ChangeRequesthref = xsd:anyURI > Content: (dc:title, dc:identifier, dc:type?, dc:description?, dc:subject?, dc:creator?)</ChangeRequest>

Property Representation

{dc:title} The required title string. Note that this element comes from the DC namespace, allowing tools unaware of the change management domain to access this element. This is sometimes also referred to as the headline or summary of the request.

{dc:identifier} The required, read-only identifier string. This is assigned by a change management system when a request resource has been created.

{dc:type} The optional type string. The type of request that is represented, such as: defect, enhancement, etc.

{dc:description} The required description string. This element comes from the DC namespace, allowing tools completely unaware of the change management domain to access this element.

{dc:subject} The optional subject string. The DC namespace defines this element to be a collection of keywords. The subject element will contain keywords and tags assigned to this request.

{dc:creator} The optional creator element, identifying the originating user of this request.

{dc:modified} The optional modified date time (format insert)



Simple Query

Query Syntax The following sections describe the basic query syntax.

Comparison Operators= test for equality of a term,

!= test for inequality of a term,

< test less-than,

> test greater-than,

<= test less-than or equal,

>= test greater-than or equal,

in test for equality of any of the terms.

Boolean Operatorsand; conjunction

Query Modifiers/sort; set the sort order for returned items

Full text searchoslc_cm:searchTerms; a list of terms to apply to a full-text search processor



Software Project Management



OSLC Estimation and Metrics 1.0 Specification

Key scenario elements1. Calibrating - Analyse past projects to define estimation model parameters that reflect the actual capabilities of a development organization. 2. Initiating - Develop the initial project parameters of scope, cost, schedule, and quality. Ideally base the estimate on similar completed

projects. 3. Monitoring and Controlling - Capture metrics and compare them with control limits. Take corrective action when an unacceptable variance

occurs 4. Re-Estimating - Periodically, e.g. at the end of each iteration, re-estimate the project based on the actuals. 5. Closing - Capture the final project metrics and record them for use by future projects.

Scope of resource descriptions and services (Metrics 1.0)Software metrics definitions, Software metrics, Software estimates

Working group membershipAccenture (Vikrant Kaulgud), Galorath (Lee Fischman), IBM (Arthur Ryman, Joakim Waltersson, Murray Cantor, Andy Berner, Steve Abrams), Price Systems (Kishore Gagrani), QSM (Larry Putnam)

Specificationshttp://open-services.net/bin/view/Main/MetricsHome

Implementing productsAnticipated Tara, Focal Point, and Galorath, Price Systems, and QSM products

Milestones:03/10/2009 - Introduce topic

tbd - Complete scenarios

tbd - First draft specs created

tbd - Start convergence

Tbd - Finalize CM 1.0 spec



Lessons Learned

Keep it Small, Scoped, Simple

Have meaningful deadlines

Scenarios are key

Implementation and Spec Co-Evolve

Engage with your colleagues

Remember: We are all learning

Keep the door open until you ship



Open Services evolution

3Q 4Q 2Q

RSDC 2008

FeedbackInterviews with 25+ customers, partners, competitors, open source community, analysts

Feedback on the vision, business implications, advice on approach with community

Expanded topics:Quality management and test execution tool integrations

Project management and estimation/measurement tool integrations

Requirements definition tool integrations

Asset Management publish and search

Complete OSLC Change Management 1.0 specification

1Q

Process/infrastructureCommunity terms and process

IP policy

open-services.net

Initial topic & workgroupCollaborative ALM scenarios for integrations between change management, quality management, and requirements management tools

Propose and refine OSLC Change Management 1.0 specification draft



© Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

alm integration in a web 2.0 world

Technology

netsli11 alm integration

ibm rational care

open services

pie sli11 alm integration

ibm corporation

alm interoperability

simplifying tool integration

lifecycle collaboration