achieve successful software delivery in it outsourcing...

®

IBM Software Group

© 2006 IBM Corporation

Achieve Successful Software Delivery in IT Outsourcing – Outsourcer View

Terence Chow, Rational Brand [email protected]

IBM Software Group | Rational software

2


3

How’s Information Transform ……

How the customer

explained it

How the project leader

understood it

How the analyst designed it

How the programmer

wrote it

How the business consultant

described it

How the project was documented

What operations installed

How the customer was

billed

How it was supported

What the customer really

needed


4

IBM Rational Requirement Driven Quality Management Best Practice Process Model


5

IBM Offers A Unique SolutionThat Ensures Entire Lifecycle Collaboration and Traceability

Systems/Software Developm

ent Test and V

erificatio

n Covera

ge

� Full Coverage

IBM’s full life cycle coverage and traceability add resses� No common set of clear requirements shared by team

� Risk of missing critical requirements� Limited ability to assess requirements change impac t

� Limited ability to identify most critical requireme nts to test� Difficult to prove compliance (auditability)

Customer Requirements

Acceptance Testing

Specifications

DesignIntegration

Testing

System Testing

Implementation

RM QMCustomer

Supplier

Customer

Supplier

Customer

Supplier


IBM Rational raises the bar for Quality managementPredictability, consistency & efficiency in software delivery

Achieve common goals by optimizing how

people work

Increase controland efficiency by

integrating workflows

CollaborateContinuously improve

by measuring progressin real time

ReportAutomate

Improve knowledge and practice maturity with an environment that develops individual and team talent.


7

Challenge: Assigning and coordinating test plan ownership and events across distributed teams

Solution: Visualize commitments, reduce rework, track tasks and monitor events

Requirements, Application security

Testing

Individual Task ListTeam event log

Know what others are doing, know what others expect from you

Up-to-date work progress informationTask management for individual and team

Test Objectives, Case assignment and Signoff

Development Iterations


8

Analyst

Project Manager

QA Manager

Proof of process

Artifact Versioning

Challenge: Centralized QA team works with multiple stakeholders across lines of business

Solution: Keeping version history and managing approval process at different phases

All project stakeholders can review, refine and sign-off on all quality related artifacts

QA team maintains accurate project history with detailed artifact versioning

Requirements Signoff

Quality Certification

Ready for Release

Project A

Project B

Project C

Artifact Reviews and Approvals


9

Know you are testing the right things

Requirements driven testingKnowing what to test

� Requirements tracking built into the test management tooling

� Customizable attributes enable you to track what is important to your team

� Real-time impact analysis of requirements changes

� Traceability of test results to user needs


Base project decisions on qualitative risk analysis

10

Collaborative risk based testingRisk management and prioritization

� Risk assessments captured in Test Plan and Test Cases

� Collaboration planning of risk mitigation strategy

� Test Case will contain a risk failure score and a risk priority score

� Documented risk related decisions


11

Organizational Policies

� Assessing status�Standard

Objectives�Reuse across Test

Plans�All working toward

same objectives�Measures against

objectives

Drive continuous and measured improvement

Challenge: Multiple distributed project teams are competing for test lab assets

Solution: Plan and track quality management objectives against business objectives


12

Rational DOORS RationalQuality Manager

Business processes

Sketches and storyboards

Use cases

Rich text

Requirements Management� Identify and manage requirements

across their lifecycle� Align team collaboration around

business objectives and outcomes

Accelerate project delivery with history and context that team

members need

Traceable requirements definition and management Challenge: Managing a shared understanding of requirements, business and delivery risks

Solution: Reduce rework, focus meetings, and reuse requirements artifacts on future projects


13

Test productivity with constant access to quality metricsLifecycle quality perspective to proactively manage risk

Performance risks are always visible and quickly

resolved

Security risks are monitored continuously to ensure business continuity

Tracks software delivery through reports

Testing of requirements can be tracked to assure business needs

are realized

Change management and defect tracking fully integrated to assure

all changes are tested

Quality ManagerDashboard

Tracks real-time execution status


Make timely and better informed decisions to achieve business objectives

Measure effectiveness of processes and practices to improve organizational outcomes

Gain insight into projects that span geographical and organizational boundaries

Executive Dashboards

Quality & Performance Dashboards

Project Level Dashboards

Continuously Improve Your Process

You cannot Improve what you cannot Measure

Process Lead


15

✔ Stakeholder and team coordination reduces mistakes✔ Risk identification and management leads to educated

prioritization decisions✔ Test traceability linked to business requirements improves

customer satisfaction

✔ Running tests earlier leads to reduced repair costs✔ Running more tests in less time improves coverage✔ Reducing manual labor leads to fewer testing errors✔ Lab configuration automation improves efficiency and asset

utilization

✔ Real-time dashboards enable proactive risk management✔ Customizable reports facilitate ongoing process improvement

IBM Rational Quality ManagerA central hub for business-driven software quality

Mitigate business risk with collaboration

Improve operational efficiency with automation

Make confident decisions with effortless reporting

IBM Rational Quality Manager

CONTINUOUS test plan participate

AUTOMATED context GOVERNANCEuse case distributed access dashboardssynchronize EASY HANDOFF trace LABUTILIZATION functional PERFORMANCEsecurity compliance


16

Quality Assurance is nothing but DO THE THING RIGHT!

But, how about …..DO THE RIGHT THING?


17

IBM Offers A Unique SolutionThat Ensures Entire Lifecycle Collaboration and Traceability

Systems/Software Developm

ent Test and V

erificatio

n Covera

ge

� Full Coverage

IBM’s full life cycle coverage and traceability add resses� No common set of clear requirements shared by team

� Risk of missing critical requirements� Limited ability to assess requirements change impac t

� Limited ability to identify most critical requireme nts to test� Difficult to prove compliance (auditability)

Customer Requirements

Acceptance Testing

Specifications

DesignIntegration

Testing

System Testing

Implementation

RM QMCustomer

Supplier

Customer

Supplier

Customer

Supplier


18

The Case for Requirements Management: Quality Improvement and Cost Savings

As much as a 200:1 cost savings results from finding errors in the requirements stage versus finding errors in the maintenance stage of

the software lifecycle.

Boehm ‘76, 88

56% of all bugs can be traced to errors made during the

requirements stagesave money effective requirement practicessave money effective requirement practices


19

Traceability in DOORS - drag-and-drop linking


1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element• Traceability Reports: consistency with driving design elements• Impact Reports: other design elements affected• Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure• Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements• Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure• Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone• Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements• Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements• Link Change Design Object with affected design element(s)• Traceability Links and Reports from affected design element(s)• Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information• Change Decision Objects with following Attributes:• Disposition Attribute• Decision Attribute• Rationale Attribute• Owner Attribute• Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute• Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone• Change Design Object Traceability Link on Milestone Attribute• Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements• Change Design Object Impacts Link to linked design elements

1.3. Mange the change process• Design Change Module• Design Change Reports• Object History• Object History Reports• Versions• Baselines














adequacy?


























Traceability view

“End-to-end visual validation in a single view”

User Reqts Technical Reqts Test CasesDesign















adequacy?







































adequacy?


























Stakeholder Reqts System Reqts Test CasesSubsystem

Traceability view

“End-to-end visual validation in a single view”














adequacy?







































adequacy?


























Stakeholder Reqts System Reqts Test CasesSubsystem1. 820.30(b) Design and Development Planning













adequacy?







































adequacy?







































adequacy?







































adequacy?














adequacy?
































































adequacy?







































adequacy?














adequacy?



















































Stakeholder Reqts System Reqts Test CasesSubsystem

Acceptance test

validating the product

StakeholderRequirements

Statement of need(Capability)

Operational use

satisfies

ComponentRequirements

Component test

evaluating components

SubsystemRequirements

Subsystem test

evaluating the subsystemssatisfies

SystemRequirements

System test

verifying the systemsatisfies

Acceptance test



Acceptance test



Acceptance test



Statement of need(Capability)

Operational use

satisfies


Component test

evaluating componentssatisfies


Component test



Component test



Subsystem test



Subsystem test


SystemRequirements

System test


SystemRequirements

System test



Simple document view of a database; or more complex for different role

See multiple requirements logically

Multiple Document Views


23

Increases customer confidence, validates alignment

Orphan reports & traceability reports show “missing” links

Traceability verification or “completeness”


What are Suspect Links?

… a change by this user here…

… shows up as a warning flag to this

user here.

If documents are linked …

�


“How are changes communicated?”Suspect links are visible directly in the document -

as indicators or as a full description

Never miss a change again


DOORS - Test Integration

� Test against requirements rather than what is built

� Integration withRational QualityManager


27

Centralized test management hub allowing full lifecycle support across all types of testing and platforms

StorageCollaboration

Search & QueryDiscovery

Administration: Users, projects, process

Presentation:Mashups

Best Practice Processes

Manage

Test Lab

Create

Plan

Build

Tests

Report

Results

Execute

Tests

IBM Collaborative Application Lifecycle Management

Test Management

Rational Quality ManagerQuality Dashboard

RequirementsManagement

DefectManagement

Open Lifecycle Service Integrations

FunctionalTesting Performance

TestingWeb Service

Quality

CodeQuality

Security andCompliance

Test Data Quality

Java System z, iSAP .NET

homegrown

Open Platform


28

© Copyright IBM Corporation 2009. All rights reserv ed. 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.

Learn more at:�IBM Rational software

�Rational launch announcements�Rational Software Delivery Platform

�Accelerate change & delivery�Deliver enduring quality

�Enable enterprise modernization

�Rational trial downloads�developerWorks Rational

�Leading Innovation�IBM Rational TV

�IBM Business Partners�IBM Rational Case Studies

�Ensure Web security & compliance�Improve project success�Manage architecture

�Manage evolving requirements�Small & midsized business

�Targeted solutions


29

Quality Management offers a centralized test management hub and full lifecycle support across all types of testing and platforms

Collaboration

Presentation:Mashups Discovery Query

Storage

Administration: Users, projects, process

Best Practice Processes

IBM Collaborative Application Lifecycle Management

Quality Dashboard

Test Management

Create Plan

Build Tests

Manage Test Lab

Execute Tests

Report Results

Requirements Management

DefectManagement

FunctionalTesting Performance

TestingWeb Service

Quality

CodeQuality

Security andCompliance

Open Platform

homegrown

Open Lifecycle Service IntegrationsJava System z, i

SAP .NETTest DataQuality


30

Unify the team through real-time, in-context collaborationA single, dynamic quality contract provides clear a nd accountable direction

� Unify the entire team with a shared view of quality assets�Central location for assets (e.g.,

business objectives requirements, resources, platform, exit criteria)

� Comprehensive dynamic planning and updates� Integrated process workflow, not

artifacts drives team activities, hand-offs, reviews/approvals and sign-offs

� Know what others are doing and what others expect of you�Task management for individuals and

team

achieve successful software delivery in it outsourcing...

Documents