IBM Software Group
Collaborative Application Lifecycle Management
(C/ALM)
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
Welcome to the Technical Exploration Center
● Introductions
● Access restrictions
● Restrooms
● Emergency Exits
● Smoking Policy
● Breakfast/Lunch/Snacks – location and times
● Special meal requirements?
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
2
IBM Software Group
Introductions
● Please introduce yourself
● Name and organization
● Current integration
technologies/tools in use
What do you want out of
this Exploration session?
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
3
IBM Software Group
Agenda
●
●
●
●
●
●
●
Introduction to Collaborative Application Lifecycle Management (C/ALM)
Lab Overview
Module 1
Update the Product Backlog
Module 2
Plan the Sprint
Module 3
Sprint
Module 4
Respond to a Test Failure
Session Summary
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
4
IBM Software Group
Objectives
● Explore how the Rational tools support collaborative application lifecycle
management by
 Enabling teams to collaborate in real time in the context of the work they are doing,
especially in globally diverse environments
 Enabling projects to be managed more effectively by providing visibility into accurate project
health information drawn directly from actual work
 Automating traceability and auditability by managing artifacts and their inter-relationships
across the lifecycle, empowering teams to deliver more value
● Provide a hands on experience using Rational Team Concert and Rational Quality
Manager to automate the software delivery process
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
5
IBM Software Group
Introduction to Collaborative Application
Lifecycle Management (C/ALM)
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
ALM Integrations... a blessing and a challenge...
 Integrations are the #1…
Reason customers buy Rational products.
Problem after they purchase.
Brittle integrations
Need to fully and
seamlessly integrate the
work of testers, business
analysts, and developers
It is hard to enact a
process
Inconsistency among
products – user
interface,
underlying logic,
storage
Little or no project visibility –
project management and reports
need to span multiple repositories &
time zones
Proprietary
repository
API’s
High maintenance
and
administration
costs
 Our customers have requested integrations for many years, this is not new.
 What’s new is our approach to solving the problem via the Jazz Integration
Architecture.
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
7
IBM Software Group
Integrations the old way
Tool A
Tool E
Tool F
Tool B
Tool C
Tool D
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
8
IBM Software Group
The Internet – an inspiration for an architecture
● Amazingly scalable
● Integrates information on a massive
scale
Index
google,
yahoo
● Infinitely extensible
Audio/Video
mp3, divx, mov
Documents
● Collaboration on unprecedented scale
Web Pages
pdf, doc
html, css, js
● World-wide information visibility
HTTP
get/put/post
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
9
IBM Software Group
What does Internet inspiration mean?
● Data specified independently of tools
Global
Index
● All data are resources with URLs
● Multiple Tools access data
Requirements
● References are embedded URLs
Change
Requests
● Resources have representations
Diagrams
● Unprecedented extensibility
● Independent search and query
● REST (Representational State Transfer)
HTTP
get/put/post
Semantic web
“Linked data”: http://www.w3.org/DesignIssues/LinkedData.html
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
10
IBM Software Group
Inspired by the world-wide-web
The evolution of software delivery: Surf the “ALM web”
Jazz Integration
Architecture
Architecture
Open Services for
Lifecycle
Collaboration
C/ALM scenarios
public on Jazz.net &
open-services.net
Data
Workflow
Proven architecture and principles of the Internet
● Presentation / Semantic Split
● Open, Extensible and On-Demand
Open Approach to define the SDLC Data model
● Cohesive, open and customizable data model for the whole
Software Delivery Life cycle
● Collaborate openly on common resource definitions
“Outside-In” scenarios
● “Real-World” End-to-end lifecycle
● Role-based, task-based user experiences
All three of these areas must be addressed
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
11
IBM Software Group
Team collaboration based on middleware services
Built on an extensible platform and common repository
Tool A
Tool B
Tool C
Tool D
Tool E
Tool F
Events &
Services
Team Collaboration Services
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
12
IBM Software Group
Software
Development
Governance
Collaborative Application Lifecycle Management
 Project status,
charts, reports
 Multi-repository
data warehouse
 Web based UI
Enterprise
Architecture
Project Health & Dashboard
Project & Iteration Plans
Reports, Feeds
Software Development Discipline-Specific Capabilities
Requirements
Management & Definition
Collaborative
Development
Enterprise Build
Management
Quality Management
Automation & Scanning
Asset Management
 Discipline-specific
pluggable modules
 Deep functionality
 Eclipse and web
UI based on need
 Integrated
Practitioner tools
Jazz Foundation Services
 Cross-discipline
integration
 Enterprise-scale
 Heterogeneous
vendor support
Cross-repository services
Presentation
Discovery
Storage
Query
Data warehouse
Process
Collaboration
Admin
Global Development and Delivery
IBM & Partner Ecosystem
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
13
IBM Software Group
Optimizing desired business outcomes
Architect
Business
Planning
& Alignment
Automated status reporting
derived from evolving
engineering artifacts can
improve productivity by 5-10%
Developer
Configuration
& Change
Management
Quality
Management
Business
Executive
Best practices in scope
management can improve
predictability of project
delivery by 20-30%
Analyst
Being able to collaborate
on work items, defects and
build errors can reduce
late rework by 25-50%
Source: Based on hundreds of client interactions of the IBM Rational Services Organization, as observed by VP Services, IBM Rational
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
14
IBM Software Group
What is C/ALM 1.0
● One of many projects contributing to Rational’s C/ALM strategy. C/ALM 1.0 will
provide integrations between
 Requirements Composer 2.0
 Team Concert 2.0
 Quality Manager 2.0
 all of which leverage Jazz Foundation 1.0.x
● C/ALM 1.0 builds on the Jazz Foundation integration support
 Common User Interface elements
 Collaboration in context with cross repository linking & queries
 Dashboards supporting transparency of C/ALM information
● Integration capabilities exist in each product
 When deployed together, the integration scenarios provide a C/ALM solution
 There is no additional software needed to enable the integrations
 We expect the integrations to deepen over time and to include many other products
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
15
IBM Software Group
Themes
● Connect the work of Analysts, Developers and Testers
● Enable users to weave a ‘web’ of ALM resources that they can use to collaborate,
navigate and track status
 In-context collaboration
 Navigation
 Transparency
● Enable our customers to choose the tools that best suit their needs by providing
flexible and open integrations
● Collaborate with and contribute to OSLC specifications and implementations
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
16
IBM Software Group
Collaboration fosters business alignment & high quality
Requirement links foster clarity
Developer
Rational Team Concert
Analyst
Tester
Rational Requirements
Composer
Rational Quality Manager
Developers link to requirements
from work-items
Testers link to requirements
from test plans and test cases
Analysts communicate
requirements with links to
development and test plans
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
17
IBM Software Group
Collaboration fosters business alignment & high quality
Defect links speed time to resolution
Analyst
Rational Requirements
Composer
Developer
Rational Team Concert
Tester
Rational Quality Manager
Test Execution Results link to
defects
Defects can link to
requirements
Defects link to Test Execution
results
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
18
IBM Software Group
Common UI elements aid in ease-of-use
Common banners
Dashboards in all products aid in transparency
Link Dialogs enable
cross-repository linking
Rich hovers
provide at-aglance, incontext
information
19
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
19
IBM Software Group
C/ALM Cross Product Query Viewlets
C/ALM queries leverage links to
provide answers to meaning
questions
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
20
IBM Software Group
C/ALM Mash-up Dashboard – RTC example
Developers have insight into
requirements in Rational
Requirements Composer
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
21
IBM Software Group
Link Creation independent of product choice
Quality
Manager
● A common ‘delegated’ approach to
artifact creation & linking in all
products.
 Product A asks Product B what artifacts it
can create or link to
 Product B provides the UI for creating or
linking to its artifacts
 Link types in Foundation
 OSLC implementations (Integrating
application uses a single URL)
● Provides choice and flexibility
 Project associations drive link choices
 Reduces the coupling between
applications, enabling independent
upgrades
 Minimizes a products knowledge about
the other repository artifacts
● Example: link RQM test execution
failure to an RTC defect
© 2009 IBM Corporation
URL calls RTC
link picker
Collaborative Application Lifecycle Management
RTC provides UI
details & semantics
22
IBM Software Group
Summer 2009 – Team Concert 2.0 & Quality Manager 2.0
CQ integrations included
● Quality Manager users can:
 Testers can link test cases to Team Concert plan items
 Testers can create / link to defects to Team Concert
 Submit defects to ClearQuest
 CALM Queries: Tests blocked by Defects, Defects blocking Test.
● Team Concert users can:
 Developers can navigate links to test execution results / test cases
 CALM Queries: Defects blocking Test.
 Link work-items and ClearQuest records
● Administrators can:
 Establish Quality Manager & Team Concert repositories as “friends”
 Link development and testing project areas
 Configure the ClearQuest Bridge for Team Concert
 Configure the ClearQuest defect provider for Team Concert
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
23
IBM Software Group
Fall 2009 – Add Requirements Composer 2.0
● Requirements Composer users can:
 Requirements sets link to Quality Manager test plans
 Requirements create / link to Quality Manager test cases
 Requirement create/link to Team Concert plan items
 CALM Mash-up Dashboards containing viewlets from Team Concert
● Quality Manager (2.0.0.1) users can:
 Link Test Plans to Composer requirements sets
 Link test cases to Composer requirements
● Team Concert (2.0.0.2) users can:
 Link plan items to Composer requirements
 Navigate links to Composer requirements
 CALM Mash-up Dashboards containing viewlets from Composer
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
24
IBM Software Group
Supported Versions
● Jazz Foundation 1.0 see Foundation 1.0 Release Plan
● July: RTC/RQM 2.0
● Fall: RTC 2.0.0.2, RQM 2.0.0.1 and RRC 2.0
● RTC / z support (releases trail RTC 2.0)
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
25
IBM Software Group
C/ALM 1.0 Supported Configuration 1
Single LDAP for user groups
Individual
application
servers.
Single Database
server hosting all
three databases
reduces
infrastructure &
provides database
back-up
User
synchronization
with LDAP
server
Documented on jazz.net: https://jazz.net/wiki/bin/view/Main/CALMJazzConfig
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
26
IBM Software Group
C/ALM on Jazz.net
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
27
IBM Software Group
Community: open-services.net
 Wiki and mailing lists
 License terms
 Encourage contribution to and
implementation of
specifications
 Specifications are created
under a Creative Commons
Attribution copyright license
 Covenant – specification
implementers are free from
patent claims by contributors
 Process Stages
 Scope (scenarios)
 Draft
 Convergence (IP covenant)
 Final Specification
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
28
IBM Software Group
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
29
IBM Software Group
Scenario for PoT Labs
● You will play the role of various members on a project (called SQUAWK) as they
work through the definition, prioritization, implementation, testing and fixing of a new
requirement:
 Bob: The product owner
 Scott: The Scrum master
 Deb: A developer
 Tanuj: The test lead
 Marco: The development lead
● The project follows the Scrum methodology.
● You will be using Rational Team Concert and Rational Quality Manager as the
project’s collaborative development environment.
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
30
IBM Software Group
Quick Scrum Overview
● “Scrum” is an agile process for software development. (Often spelled “SCRUM”,
although not an acronym.)
● Scrum roles:
 Scrum Master: Individual who maintains the processes (essentially a project manager).
Responsible for removing impediments to team progress.
 Product Owner: Represents the stakeholders
 Team: Cross-functional group of people who do the work
● Scrum concepts:
 Story: A brief description of a user need. Each story has a relative priority and complexity.
 Product backlog: A prioritized set of high-level requirements of work, usually described in
stories.
 Sprint: A 2-to-4 week period in which the team creates a potentially shipping product. A
Scrum project consists of several sprints.
 Sprint planning meeting: A meeting to determine which backlog items go into a sprint.
 Scrum: A short daily meeting where each team member shares what they accomplished
yesterday, what they will work on today and what, if anything is blocking their progress.
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
31
IBM Software Group
Sequence of events
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
32
IBM Software Group
Sequence of events – Lab 1
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
33
IBM Software Group
Sequence of events – Lab 2
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
34
IBM Software Group
Sequence of events – Lab 3
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
35
IBM Software Group
Sequence of events – Lab 4
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
36
IBM Software Group
Rational C/ALM Solution Components
Quality Manager
Team Concert
Requirements Composer
Collaboraitve Business-Driven Quality
Innovation Through Collaboration
Business Expert Collaboration
Coordinate quality assurance plans,
processes and resources
Unify by “thinking & working” in
unison with real-time project heath
Elicit, capture, elaborate, discuss
and review requirements
Quality Manager
offering
offering
offering
Requirements
Composer
Team Concert
Business
Partner Jazz
Offerings
Best Practice Processes
Search and Query
Security
Dashboards
Team awareness
collaboration
Events notification
JAZZ TEAM SERVER
Open Lifecycle Service Integrations
ClearQuest
Powered by
ClearCase
© 2009 IBM Corporation
Build Forge
Requisite
Pro
Asset Manager
Collaborative Application Lifecycle Management
38
IBM Software Group
Rational Team Concert: A closer look
Iteration Planning
Project Transparency
 Integrated iteration planning and execution
 Task estimation linked to key milestones
 Out of the box agile process templates
SCM
 Integrated stream management
 Component level baselines
 Server-based sandboxes
 Parallel development
 ClearCase connector
 Customizable web based dashboards
 Real time metrics and reports
 Project milestone tracking and status
Work Items
 Defects, enhancements
and conversations
 View and share query results
 Support for approvals and
discussions
 Query editor interface
 ClearQuest connector
Build
 Work item and change
set traceability
 Build definitions for team
and private builds
 Local or remote build servers
 Supports Ant and command
line tools
 Integration with Build Forge®
IBM Jazz™ Team Server
 Single structure for project related artifacts
 World-class team on-boarding / off-boarding
including team membership, sub-teams and
project inheritance
 Role-based operational control for flexible
definition of process and capabilities
© 2009 IBM Corporation
 Team advisor for defining / refining “rules”
and enabling continuous improvement
 Process enactment and enforcement
 In-context collaboration enables team members
to communicate in context of their work
Collaborative Application Lifecycle Management
39
IBM Software Group
Centralised Quality Management hub enabled by Jazz
IBM Collaborative Application Lifecycle Management
Rational Quality Manager
Quality Dashboard
Test Management
Requirements
Management
Defect
Management
Create
Plan
Build
Tests
Manage
Test Lab
Execute
Tests
Report
Results
Best Practice Processes
Administration: Users,
projects, process
Collaboration
Presentation:
Mashups
Security
Storage
Search & Query
Open Platform
SAP
Test Data
Quality
Functional
Testing
© 2009 IBM Corporation
Java
Open Lifecycle Service Integrations
Performance
Testing
Web Service
Quality
System z, i
Code
Quality
Collaborative Application Lifecycle Management
.NET
Security and
Compliance
homegrown
40
40
IBM Software Group
Rational Requirements Composer: A closer look
Rich Authoring Environment
Web Review and Approval
Wiki style interface
Categorize / Tag
Comment
Review / Approve
Rich Text Requirements
Use Cases
Glossaries
UI Sketching and Storyboarding
Process Sketching
© 2009 IBM Corporation
Collaboration Server
Share work instantly
Users / teams / authorizations
Linking between all artifacts
Versioning
Collaborative Application Lifecycle Management
41
IBM Software Group
© 2009 IBM Corporation
Collaborative Application Lifecycle Management
42
IBM Software Group
Collaborative Application Lifecycle Management
(C/ALM)
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
Module 1 – Update the Product Backlog
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
Agenda
●
●
●
●
●
●
●
Introduction to Collaborative Application Lifecycle Management (C/ALM)
Lab Overview
Module 1
Update the Product Backlog
Module 2
Plan the Sprint
Module 3
Sprint!
Module 4
Responding to a Test Failure
Session Summary
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
45
IBM Software Group
Objectives
● Explore the Rational Team Concert (RTC) web interface.
● Explore RTC dashboards and viewlets.
● Explore how RTC can facilitate and manage changes to project plans.
● Explore how RTC can manage SCRUM stories and product backlogs.
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
46
IBM Software Group
Sequence of events – Lab 1
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
47
IBM Software Group
Lab 1 Scenario
● You are “Bob”, the product owner, for this entire lab.
● You have a new story that you want included in the coming
sprint.
● You will create the new story, add it to the product backlog and
then reprioritize the backlog so that your new story becomes
the highest priority.
● All of Bob’s work will be done via the Rational Team Concert
web interface.
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
48
IBM Software Group
Lab 1 Concepts Learned
● The Rational Team Concert (RTC) web interface is a robust interface that can be
used as the primary interface for many team roles (essentially, anyone who does not
have a requirement to modify items under source control).
● RTC provides direct support for Scrum. Note: While this session uses Scrum, RTC
provides excellent support for a variety of development methodologies.
● RTC dashboards provide each team member with the information they require.
Projects, teams and individuals can have their own dashboards customized to their
needs.
● RTC makes it easy to manage a project's development plan.
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
49
IBM Software Group
© 2009 IBM Corporation
Module 1 – Update the Product Backlog
50
IBM Software Group
Module 2 – Plan the Sprint
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
Agenda
●
●
●
●
●
●
●
Introduction to Collaborative Application Lifecycle Management (C/ALM)
Lab Overview
Module 1
Update the Product Backlog
Module 2
Plan the Sprint
Module 3
Sprint!
Module 4
Responding to a Test Failure
Session Summary
© 2009 IBM Corporation
Module 2 – Plan the Sprint
52
IBM Software Group
Objectives
● Explore how a team using Rational Team Concert (RTC) and Rational Quality
Manager (RQM) can collaborate to integrate testers with the development team and
ensure test coverage.
● Further explore the RTC web interface.
● Further explore RTC dashboards and viewlets.
● Explore how RTC enables agile teams to manage sprint/iteration plans.
● Explore how RTC can be used to facilitate a sprint planning meeting.
● Explore how RTC can be used to track project status and find impediments to
progress.
● Explore using RQM to update the test plan, create new test cases and link them to
requirements.
© 2009 IBM Corporation
Module 2 – Plan the Sprint
53
IBM Software Group
Sequence of events – Lab 2
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Module 2 – Plan the Sprint
54
IBM Software Group
Lab 2 Scenario
● You will play three different roles in this lab!
● As Bob, the product owner, you will use the Rational Team
Concert (RTC) web interface to order and describe the highest
priority features to the team.
● As Scott, the scrum master, you will use the RTC web interface
to create a plan for the new sprint, add items to the plan and
create development tasks for each item in the plan.
● As Tanuj, the test lead, you will use Rational Quality Manager
(RQM) to add new test cases to the test plan and link them to
the stories they are testing.
● Finally, as Scott (again), you will use the RTC web interface to
ensure that all stories planned for this sprint have test cases
associated with them.
© 2009 IBM Corporation
Module 2 – Plan the Sprint
55
IBM Software Group
Lab 2 Concepts Learned
● RQM and RTC to give users of either tool visibility into data from the other tool, and
link items from either tool together. This helps all team members stay in sync.
● For teams using Scrum, RTC can be an integral tool in the sprint planning meeting. It
provides views (Product Backlog, Taskboard) and viewlets (Team Velocity) that are
essential to Scrum.
● RTC makes it easy to create new sprint/iteration plans and add work to them, or
move items from one plan to another.
● For Scrum, stories can link to one or more development tasks that can be used to
assign work to developers.
© 2009 IBM Corporation
Module 2 – Plan the Sprint
56
IBM Software Group
© 2009 IBM Corporation
Module 2 – Plan the Sprint
57
IBM Software Group
Module 3 & 4 –
Sprint! & Responding to a Test Failure
An IBM Proof of Technology
© 2009 IBM Corporation
IBM Software Group
Agenda
●
●
●
●
●
●
●
Introduction to Collaborative Application Lifecycle Management (C/ALM)
Lab Overview
Module 1
Update the Product Backlog
Module 2
Plan the Sprint
Module 3
Sprint!
Module 4
Responding to a Test Failure
Session Summary
© 2009 IBM Corporation
Module 3 – Sprint!
59
IBM Software Group
Objectives
● Explore how Rational Quality Manager (RQM) can be used to associate test
implementations (scripts) with test cases.
● Explore the Rational Team Concert (RTC) Eclipse interface from a developer’s
perspective.
● Understand uses RTC to accept work, complete development tasks and deliver
updated work to the team.
● Explore the team build features of RTC.
● Explore how all team members can monitor the status of team builds, regardless of
whether they use RTC or RQM.
© 2009 IBM Corporation
Module 3 – Sprint!
60
IBM Software Group
Objectives
● Explore how Rational Quality Manager (RQM) can be used to execute manual tests,
log test results and generate defects for the development team to fix.
● Explore how Rational Team Concert (RTC) can be used to triage defects and help
determine who should be assigned new work.
● Further explore how a developer uses RTC to discover new work assigned to them,
fix defects, deliver fixes to the team and work with team builds.
● Explore how a tester can use RQM to monitor the team build status, determine what
work is included in a new build and verify that defects have been fixed.
© 2009 IBM Corporation
Module 4 – Responding to a Test Failure
61
IBM Software Group
Sequence of events – Lab 3
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Module 3 – Sprint!
62
IBM Software Group
Sequence of events – Lab 4
Bob
(product owner)
Scott
(SCRUM Master)
Tanuj
(Test Lead)
Deb
(Developer)
Marco
(Development Lead)
Create the new story
Prioritize the backlog
Describe the highest
priority features
Define the sprint goal
Agree to items for the
backlog
Add development tasks
Align the test sprint plan
Check the team’s
alignment
Create script and
execution records
Develop “surfer
squawker”
Monitor the build status
Monitor the integration
build
Execute test & submit
defect
Confirm defect is fixed
Triage defects
Fix defect & deliver
change
Track status
© 2009 IBM Corporation
Module 4 – Responding to a Test Failure
63
IBM Software Group
Lab 3 Scenario
● You will play two different roles in this lab.
● As Tanuj, the test lead, you will use Rational Quality Manager
(RQM) to create and edit new test scripts and test execution
records for the test cases you added in the previous lab.
● As Deb, the developer, you will use the Rational Team Concert
(RTC) Eclipse interface to plan your work, complete your
development tasks, deliver your updates to the team and
execute an integration build on the team's build server.
● As Tanuj (again), you will use RQM to monitor the team build
status and deploy the built application (following a test script) so
that the application is ready for test.
© 2009 IBM Corporation
Module 3 – Sprint!
64
IBM Software Group
Lab 4 Scenario
● You will play three different roles in this lab!
● As Tanuj, the test lead, you will use RQM to execute a manual
test, denote that the test failed and generate a new defect
related to the test result.
● As Macro, the development lead, you will use the RTC web
interface to analyze the new defect, determine who should fix
the defect and assign the defect.
● As Deb, the developer, you will use the RTC Eclipse interface to
determine that there is a new defect assigned to you, analyze
the test result related to that defect, resolve the defect and
request a new team build.
● As Tanuj (again), you will notice the new build result, determine
what is fixed in that build, deploy the new build and verify that
the defect you created is indeed fixed.
© 2009 IBM Corporation
Module 4 – Responding to a Test Failure
65
IBM Software Group
Lab 3 Concepts Learned
● RQM test scripts implement test cases that can be linked to the drivers for those test cases (in
this case, stories).
● RQM includes a highly descriptive manual testing facility that provides the tester with the right
level of detail required to execute the test correctly.
● RTC queries make it simple for any team member to see what they need to work on.
● A change set is the fundamental unit of change and collaboration in your team environment.
Change sets are migrated between streams via two operations: accepting and delivering.
● This team did not require work items to be associated with delivered changes, but that could be
turned on.
● Developers can run "personal builds" on the team's build server to ensure that the code they
see in their workspace successfully builds using the team's build process. Ensuring compilation
in the IDE isn't always enough.
● Team members can request a "team build" that will grab the latest code on the team's
integration stream and build it on the team build server.
● Every team member has access to build data from team builds. This promotes communication
and collaboration among the contributors – on local or remote sites.
© 2009 IBM Corporation
Module 3 – Sprint!
66
IBM Software Group
Lab 4 Concepts Learned
● RQM's manual test facility allows the test to document step-by-step test results as
the test is being executed, including grabbing helpful screen snapshots that may be
useful in debugging.
● Test results can document the build that was used for the test, to aid in debugging.
● Defects can be created from test results and routed to the development team.
Defects created from test results are automatically linked back to the test result, to
aid in debugging.
● Testers can denote which defects are preventing (blocking) test cases from
succeeding…ensuring they don't waste time executing the same test and generating
duplicate defects. This also helps testers monitor the defects they've generated so
they know when it's worthwhile to run the test again.
● RTC queries make it easy for team leads to find new work and determine the
appropriate person for assignment.
● Change sets can be associated with work items to denote which artifacts were
modified to implement a work item.
© 2009 IBM Corporation
Module 4 – Responding to a Test Failure
67
IBM Software Group
© 2009 IBM Corporation
Module 3 – Sprint!
68
IBM Software Group
Contacts
● Perth
 Andy Rutherford
 arutherf@au1.ibm.com
● Adelaide
 Lee Kinsman
 lkinsman@au1.ibm.com
● Auckland
 Alan Kan
 alankan@nz1.ibm.com
● Brisbane
 Davyd Norris
 dnorris@au1.ibm.com
● Wellington
 Alan Kan
 alankan@nz1.ibm.com
● Canberra
 Joe Williams
● Melbourne
 Davyd Norris
 dnorris@au1.ibm.com
● Sydney
 Rafal Michalski
 Rafal.Michalski@au1.ibm.com
© 2009 IBM Corporation
Module 3 – Sprint!
69