ALM Integration in a Web 2.0 World

ALM Integration in a Web 2.0 World

Steve Abrams
Senior Technical Staff Member
Lead Architect, OSLC
CTO Team IBM Rational
sabrams@us.ibm.com

Session SLI11
Session SLI11

© 2009 IBM Corporation

IBM Rational Software Conference 2009

Tool Integration. Ouch.

N^2 Point-to-point
Closed APIs
Vendor lock-in
Tight Coupling
Lockstep upgrades
Version incompatibilities

SLI11 – ALM Integration in a Web 2.0 World 2

3

The Internet – an inspiration for an architecture

Amazingly scalable Index
Audio/Video
google, mp3, divx, mov
Integrates information on yahoo

a massive scale
Documents
Web Pages pdf, doc
Infinitely extensible html css, js
,

Collaboration on
unprecedented scale HTTP
get/put /post
World-wide information
visibility

SLI11 – ALM Integration in a Web 2.0 World

4

So what if…

All data are resources with URLs
Resources have representations Global Requirements
Index
Representations specified
independently of tools as standards Change
Requests
Links are embedded URLs Diagrams

Multiple Tools access data
REST (Representational State Transfer) HTTP
get/put /post



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

Open Services for
Lifecycle Collaboration
Barriers to sharing resources and Community Driven – specified at open-services.net
assets across the software lifecycle
Multiple vendors, open source projects, Specifications for ALM Interoperability
and in-house tools
Inspired by Internet architecture
Private vocabularies, formats and
Loosely coupled integration with “just enough” standardization
stores Common resource formats and services
Entanglement of tools with their data
A different approach to industry-wide proliferation

Discovery
Administration REST API
(users, projects, process)

Query Core Task Specific
Logic Logic
Data Warehousing
Storage
Collaboration
Additional Services
Data
Core Services
Open Lifecycle Services


6

Putting 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 Current Course

• Reduce time-to-market Pre-Standards

Integration M/W Revenue
Common standards promote interoperability

•Good for our customers Business value of every offering rises

• Freedom of choice
• Flexibility of incremental adoption
Fragmented standards maintain lock-in
• Improved productivity Business value limited

2004 2008 2012
• Good for our Industry
• Interoperability increases the value of
every offering
• Spark innovation around the edges
• Enable new business opportunities
• Grow the pie



The first wave of Jazz integrations
Rational Rational Rational
Requirements Team Concert Quality Manager
Composer Core team collaboration Quality team collaboration
Business expert collaboration
quot;Think and workquot; in unison and Coordinate quality assurance
Elicit, capture, elaborate, discuss
provide real-time project heath plans, processes and
and review requirements
resources

Changes; notification Association

Requirement linked Tester finds defects,
to work item generates work item
Analyst Tester
REST API REST API

Requirements Defects closed Defect status
Quality
against Management
Management requirements

REST API
Change &
Configuration
Management

Architect Developer


Open Services for Lifecycle Collaboration (OSLC)
Loosely coupled integration

Change Mgmt Test
System POST, Query, etc Management
change requests

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



JIA: Enables deeper integration

Rational Team Rational Quality
Concert 2.0 Manager
POST, Query, etc
change requests

Jazz
Dashboard
Application

Jazz Foundation
Services




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

Open forum for participation
Creative Commons Licensing
Patent 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
Iterate on (topic lead is driver)
Identify
working
Scenarios
drafts

Gain technical
Call it a consensus,
spec collect non-
assert
statements



Open Services for Lifecycle Collaboration (OSLC)
Loosely coupled integration

Change Mgmt Test
System POST, Query, etc Management
change requests

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



OSLC Change Management 1.0 Specification
Key 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 membership
Accenture (Randy Vogel, Gary Dang), IBM (Steve Speicher, Andre Weinand, Steve Abrams, Carolyn Pampino), Tasktop/Eclipse Mylyn
(Mik Kirsten, Robert Elves)

Specifications
http://open-services.net/bin/view/Main/CmHome
Milestones:
11/05/2008 - Introduce topic
Implementing products 02/21/2009 - Complete scenarios
Implement the services -- RTC 2.0, RCM/CQ 2.0
Use the services – RQM 2.0, Eclipse Mylyn
11/17/2008 - First draft specs created
Planned: Implement the services – Rational (Telelogic) Change 04/15/2009 - Start convergence
Use the services – RRC 2.0
05/29/2009 - Finalize CM 1.0 spec



Key Technical Areas of Contribution

Web UI delegation with cross-site messaging support
Leverages existing standards

Various resource creation models
Accommodates interactive and batch models

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

Resource format definitions
XML and JSON formats for: ChangeRequests, Collections and Errors

Simplified query model
Can be encoded in a URL, limited capability

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



Service Discovery



UI Delegation for
Resource Creation and
Selection



Use Delegated Work Item Picker


Use Delegated ClearQuest Record Picker



Change Management – Change Request Resource
XML Representation Summary: ChangeRequest? Element
<ChangeRequest
href = 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 Operators
and; conjunction
Query Modifiers
/sort; set the sort order for returned items
Full text search
oslc_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 elements
1. 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 membership
Accenture (Vikrant Kaulgud), Galorath (Lee Fischman), IBM (Arthur Ryman, Joakim Waltersson, Murray Cantor, Andy Berner, Steve
Abrams), Price Systems (Kishore Gagrani), QSM (Larry Putnam)

Specifications Milestones:
http://open-services.net/bin/view/Main/MetricsHome
03/10/2009 - Introduce topic
Implementing products tbd - Complete scenarios
Anticipated Tara, Focal Point, and Galorath, Price Systems, and QSM products 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 1Q 2Q

RSDC 2008
Feedback Process/infrastructure Initial topic & workgroup Expanded topics:
Interviews with 25+ Community terms and Collaborative ALM Quality management and
customers, partners, process scenarios for test execution tool
competitors, open integrations between integrations
source community, IP policy
change management, Project management and
analysts open-services.net quality management, estimation/measurement
Feedback on the vision, and requirements tool integrations
business implications, management tools
advice on approach with Requirements definition
Propose and refine tool integrations
community OSLC Change
Management 1.0 Asset Management
specification draft publish and search
Complete OSLC Change
Management 1.0
specification



© 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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ALM Integration in a Web 2.0 World

Similaire à ALM Integration in a Web 2.0 World (20)

Dernier

Dernier (20)

ALM Integration in a Web 2.0 World