why do project fail? - ibm · pdf filewhy do project fail? 42% 37% 27% 26% 24% 24% ......
TRANSCRIPT
IBM Software Group | Rational software
1
Why do Project Fail?
42%
37%
27%
26%
24%
24%
0% 10% 20% 30% 40% 50%
Unclear or continually changing productdefinitions
Product does not meet customer or marketrequirements
Unrealistic schedule expectations
Projects not adequately staffed
Unclear or continually changing priorities
Unrealistic financial expectations
Source: AberdeenGroup, August 2006
IBM Software Group | Rational software
2
Why is requirements management so critical?
“Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure - bigger than bad technology, missed deadlines or change management fiascoes”
- CIO Magazine, November 2005
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Requirement
IBM Software Group | Rational software
4
Requirements Are Everywhere
RequirementsObjective
Goal
Aim
Reg
ulat
ion
Criterion NeedFeat
ureFunction R
ule
Risk
IBM Software Group | Rational software
5
Acceptance test
validating the product
StakeholderRequirements
V-Shape Requirement Development
Statement of need Operational use
satisfies
ComponentRequirements
Component test
evaluating components
SubsystemRequirements
Subsystem test
evaluating the subsystemssatisfies
SystemRequirements
System test
verifying the systemsatisfies
ITIL, ISO9001
Company Standard
confront
Implementation Outsourcing
Design Outsourcing
IT Outsourcing
IBM Software Group | Rational software
6
Requirement Database� Unlimited hierarchy of Projects/Folders supports scalability
Organize Your Projects
Deleted Folder
DOORS Documents
Folders
Projects
IBM Software Group | Rational software
7
Everything you need in one window!
Improves productivity, reduces errors, increases quality
Document Views
OLE
Context
Requirements
Spell check
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Requirement Relationship?
IBM Software Group | Rational software
9
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
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
User Reqts Technical Reqts Test CasesDesign
Traceability is the key to Requirement Managmenet
� Initial user requirements should be decomposed to detailed requirements, then to design, tests, etc.
� Decomposition creates traceability relationships
� Relationships define your traceability model
� Your traceability model is the basis for your process
� Enforce your traceability model; improve your process
IBM Software Group | Rational software
1010
Drag-and-drop to link within a document . . .
. . . or from document to
document�
Traceability; drag-and-drop linking
IBM Software Group | Rational software
11
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
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
Traceability view
“End-to-end visual validation in a single view”
User Reqts Technical Reqts Test CasesDesign
IBM Software Group | Rational software
12
•Increases customer confidence
•Detect missing links
•Creation and deletion of links is recorded in history
Traceability through an Orphan report shows “missing” links
Traceability Verification or “Completeness”
IBM Software Group | Rational software
13
StakeholderRequirements
SystemRequirements
SubsystemRequirements
ComponentRequirements
System test plan
Integration test plan
Componenttest plan
Acceptance test Plan
Imp
act
An
alys
is Derivatio
n A
nalysis
Derivation Analysis
Impact Analysis
Impact / Derivation Analysis
IBM Software Group | Rational software
14
StakeholderRequirements
SystemRequirements
SubsystemRequirements
ComponentRequirements
System test plan
Integration test plan
Componenttest plan
Acceptance test Plan
All requirements are allocated to subrequirements?
All requirements are tested without an exception?
Requirement Coverage Analysis
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Requirement Change?
IBM Software Group | Rational software
16
Suspect links are visible directly in the document -
as indicators or as a full description
Never miss a change again
Suspect Links
Clear on a right click
IBM Software Group | Rational software
17
structured,
linked and
traced,
Non-
integrated
project data
is imported,
to produce
reports of
managed
information
�
The Requirement lifecycle
IBM Software Group | Rational software
18
Problems (or Risk) of Outsourcing –Risks are not fully shifted to outsourcing as Stakeholders bear the risk of project failure.
� Requirements are not fully covered by testing
� Lack of defect management process
� Lack of validation and verification
� Lack of Project Transparency
IBM Software Group | Rational software
19
Although cancellation rates are downand fewer projects are troubled,
improving software development governance provides increased value to projects, producing about 30% more projects
that deliver expected value.
Source: Standish Chaos Report, Allinean ROI of Software Development
The unsuccessful failure rate for software projects is still alarmingly high
Software project results
� Project success rates average less than 55%
� Cancelled projects cost $81 Billion worldwide each year
� Of the 50% of projects which are successfully delivered, 28% of these projects are not yielding the expected planned value
Software project waste
� $55 Billion
� $38 Billion in lost dollar value
� $17 Billion in cost over runs
®
IBM Software Group
© 2006 IBM Corporation
How to Plan ?
IBM Software Group | Rational software
21
Quality management planFirst step to succeed
Structured plan to fulfill Software Sub-contact Management, e.g. Business Objectives, Requirements, Acceptance Criteria, Schedule, Attachments, & etc
Create snapshot to record of your progress.
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Test Coverage ?
IBM Software Group | Rational software
23
Test CoverageFind requirements that have or have no test case
IBM Software Group | Rational software
24
Test Coverage on updated (suspect) requirement
IBM Software Group | Rational software
25
Test Coverage on updated (suspect) requirement
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Defect ?
IBM Software Group | Rational software
27
Defect Management Transparent and centralised overview of development requests and status
List of defects with status
IBM Software Group | Rational software
28
Defect Management – DashboardProvide information about the project status
profile: know which projects are involved
Notifications, and defects will be displayed in dashboard
Customisable charts for project analysis
Know what is happening in this
project
IBM Software Group | Rational software
29
Defect Management – Vendor to fix defects
Vendor fixes defect and update
status
Important communication is kept in discussion
section
Find Potential Duplicates
IBM Software Group | Rational software
30
Defect Management – Audit Trail
IBM Software Group | Rational software
31
Defect Management – Traceabilityunderstand which requirement has defect
®
IBM Software Group
© 2006 IBM Corporation
How to Verify Quality ?
IBM Software Group | Rational software
33
Validation on Quality Management Plan
Reviewal and Approval
IBM Software Group | Rational software
34
Verification on Quality
Vendor provides step-by-step screenshots evidence as attachments.
Result Details
Test Execution overview
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Project Transparency ?
IBM Software Group | Rational software
36
Project Transparency - On demand reportingSnapshot views of project status from multiple perspectives
Customizable reporting enables sharing and communicationof vital project information
IBM Software Group | Rational software
37
Project Transparency - Finding overdue items
Over dueitem
IBM Software Group | Rational software
38
Project Transparency – Finding all outstanding defects
Have vendor fixed all the defects?
IBM Software Group | Rational software
39
Project Transparency – Acceptance Criteria
®
IBM Software Group
© 2006 IBM Corporation
How to Manage Multiple Projects ?
IBM Software Group | Rational software
41
Multi-Project SupportRepresentation of software projects
Different Project Area for different vendor
IBM Software Group | Rational software
42
Summary
Business Benefits:
� Requirement Coverage – Make Sure that Project is focusing on defined Requirement inside the lifecycle, not at the end.
� Defect Management – All parties have visibility on defects and all activities, Sub-Contractor will be notified when new defects raised. Can be traced to requirements.
� Validation and Verification – Review + Approval + Collaboration. Evidence to meet Acceptance Criteria.
� Project Transparency – Real-time Dashboard + Report.
� Business Stakeholders and subcontractors can be anywhere in the world and work around the clock.
Sub-Contractors
SubSub--ContractorsContractors
Quality Assurance
Quality Quality AssuranceAssurance
BusinessBusinessBusiness
IBM Software Group | Rational software
43
Centralized Quality Management Solution
ManageDefects
ReportResults
ExecuteTests
CreatePlan
BuildTests
IBM Collaborative Application Lifecycle Management
Quality Management
Rational Quality ManagerQuality Dashboard
IBM Collaborative Application Lifecycle Management
Requirement Traceability
Telelogic DOORSCollaborative Requirement Repository
Impact Analysis Test Requirement
Test Result
Bi-directional auto-synchronization
IBM Software Group | Rational software
44
Flexible Deployment
IBM Collaborative Application Lifecycle Management
Requirement Traceability
Telelogic DOORSCollaborative Requirement Repository
Impact Analysis
IBM Collaborative Application Lifecycle ManagementIBM Collaborative Application Lifecycle Management
Requirement Traceability
Telelogic DOORSCollaborative Requirement Repository
Impact Analysis
ManageTest Lab
CreatePlan
BuildTests
ReportResults
ExecuteTests
IBM Collaborative Application Lifecycle Management
Quality Management
Rational Quality ManagerQuality Dashboard
ManageTest Lab
CreatePlan
BuildTests
ReportResults
ExecuteTests
ManageTest Lab
CreatePlan
BuildTests
ReportResults
ExecuteTests
IBM Collaborative Application Lifecycle ManagementIBM Collaborative Application Lifecycle Management
Quality Management
Rational Quality ManagerQuality Dashboard
Customer Outsourcing
IBM Software Group | Rational software
45
Benefits
� Reduce outsourcing projects still have high failure rate � [DOORS] Requirement Repository to maintain the “Source of Trust”
� [DOORS] Requirement Integrity through Traceability
� Mitigate Potential risks of using Sub-contractors� [RQM] Real Time Quality Dashboard to increase Transparency
� [RQM] Test Coverage visibility
� [RQM] Defect Management
� Improve your winning chance when outsourcing projects�Real Time Monitoring & Tracking during lifecycle
�Full Lifecycle Traceability ensure No Missing Issue
�Highly Quality project delivery
IBM Software Group | Rational software
46