Beruflich Dokumente
Kultur Dokumente
Outline
Overview of DOORS
Introduction Key concepts and elements Using DOORS
DOORS - Introduction
Requirements Engineering
Requirements Development
Elicitation Analysis Modeling & Specification Verification & Validation
Requirements Management
Change Control Version Control Tracing & Impact Analysis Status Tracking
Key challenges
Communicate requirements to all project stakeholders to keep everyone on the same page Control changes to requirements, assess impact of proposed changes, and communicate approved changes Analyze requirements coverage to ensure customer satisfaction or compliance to regulations/contracts
Barry Boehm76, 88
56% of all bugs can be traced to errors made during the requirements stage
Satisfies
Satisfies
Tests
Tests
Acceptance tests
8
Tests
Standards
Functional tests
Unit tests
Projects
Documents Folders DOORS Database Explorer: Allows you to organize your data in the same way that you might organize it in MS Windows Explorer > explorer type navigation
10
11
12
13
On the Left: Module Explorer allows you to navigate and see the structure
Right hand pane shows Heading and Text in a Document-Centric Format the way youre used to
14
Objects
Documents (or Formal Modules) are collections of Objects Objects may be used for
Requirement text Headings Graphics Any other information
15
What is an Attribute?
Attributes are additional defined characteristics of a requirement; they provide essential information in addition to requirement text
Source Priority Verifiability Accepted Who specified this requirement? What is the priority of this requirement? Is the requirement verifiable? Has this requirement been accepted by the developers?
Review
Safety Comments Questions
You can define attributes that will support your process and make your database more productive for you
Attribute Have:
Attribute Name Type
Access Definition
Default Value
Change Characteristics
19
Attributes can be assigned to: Documents (Modules), Objects (Requirements), and links
Object Attributes
Attributes allow additional information to be associated with each requirement
20
Filters
Filters allow you to reduce the information in the display to an essential set that interest you
Filters support your analysis of the requirements
21
Filters are saved when you save the View Views are Dynamic Reports of your Data
22
Views
Views define the layout of your data Columns, filters, sorts, window position, etc. Drop-Down list on left side of tool bar for easy access to your views Defaults for Users or Documents can be set
23
Using Views
24
Links in DOORS
A relationship between two requirements (objects) is established using a link
From (Source)
25
To (Target)
Using DOORS
28
29
Tracking changes
Change History
Previous Baseline
Current Version
31
Support for:
Distributed teams Requirements reviews Managers
32
?
User submits Change Proposal
34
or across projects.
35
Satisfies
Satisfies
Tests
Tests
Acceptance tests
36
Tests
Standards
Functional tests
Unit tests
37
Coverage Analysis
User requirements Functional requirements Design specifications
% Complete ?
Satisfies
Satisfies
Tests
Tests
Acceptance tests
Tests
38
Standards
Functional tests
Unit tests
Coverage Analysis
User requirements Functional requirements Design specifications
Gold plating ?
Satisfies
Satisfies
Tests
Tests
Acceptance tests
Tests
39
Standards
Functional tests
Unit tests
Analyzing Impact
User requirements Functional requirements Design specifications
What if ?
Satisfies
Satisfies
Tests
Tests
Acceptance tests
Tests
40
Standards
Functional tests
Unit tests
41
Derivation analysis
Why is ?
User requirements Functional requirements Design specifications
Satisfies
Satisfies
Tests
Tests
Acceptance tests
Tests
42
Standards
Functional tests
Unit tests
Impact/derivation analysis
User Reqts
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, 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 Input 2.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 user and patient. 2.2. Each manufacturer shall maintain 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 user and 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 of design 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 use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.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?
Technical Reqts
2.
Design
1.1.1. Create backward traces to design elements within and across any organizational
Test Cases
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 elements 1.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 Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure 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 Control Guidance 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 Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design and development 1.1. Identify impacted elements due to a change in another element activities and define responsibility for implementation. 1. Capture design and related information 1. Capture design and related information with driving design elements Traceability Reports: consistency 1.1. Input electronically formatted data 1.1. Input electronically Impact Reports: other design elements affected formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external information sources 1.2. Reference external information sources Links to impacted design elements in, input to the design and development process. 1.3. Reference external documentation 1.3. Reference external documentation
3.
4.
5.
6.
The plans shall be reviewed as design and development evolves. Store design and related information 2. Store design and related information procedure The plans shall be updated as design and development evolves. 2.1. Identify and tag design information as unique design elements 2.1. Identify and tag design information as unique design elements Attribute Traceability Reports: Procedure The plans shall be approved as design and development evolves. 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Design Input Attribute Traceability Reports: Milestone 2.2.2. Organize by inter-relationships 2.2.2. Organize by inter-relationships 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to backward a 1.1.3. Create traces to design elements within and are across Design Control 2.3. Ensure all design elements are available 2.3. Ensure all design elements available device are appropriate address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Design Control Guidance and Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements andhistorical patient. values 2.3.2. Store design elements and their 2.3.2. Store design elements and their historical values Reports: Linked design elements Traceability 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a forward impacts to design within and across any organizational device are appropriate and address the intended use of the device, including the1.1.4. needs Create of the user Manage all user needs 3. Manage elements all user needs and patient. procedure 3.1. Identify the source of the user need 3.1. Identify the source of the user need 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 3.2. Identify all user types (groups) 3.2. Identify all user types (groups) Attribute Impact Reports: Procedure 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer 1.1.5. Create forward impacts to design elements within(s) and across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Attribute Impact Reports: Milestone The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6. product (family) 3.5. State the intended use of the product (family) 2.7. The design input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and across Design Control 3.6. Capture the acceptance criteria for each user need 3.6. Capture the acceptance criteria for each user need 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input requirements design elements Impact Reports: Linked shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 1.2. Associate changed design elements with related elements 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and Linkof Change Design Object 4.3. withCapture affected design element(s) control 4.3. Capture requirement description and attributes requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. from Capture acceptance criteria affected design element(s) Traceability Links and Reports 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. affected Assign responsibility for each requirement design element(s) Impact Links and Reports from 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical with following Attributes: 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity and biocompatibility 5.3. Document the results of every user need acceptance test 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute 2.10.3.9. compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Link on Procedure Attribute Change Design Object Manage change 6. Traceability Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain of design Attribute element changes Link history on Procedure Change Design Object Impacts 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history available 1.2.3. Provide associations within and across any project milestone 2.10.3.14. reliabilityprocedure 6.1.2. Maintain history within and across any organizational 6.1.2. Maintain history within and across any organizational procedure Link on Milestone Attribute Change Design Object Traceability 2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across any project milestone 6.1.3. Maintain history within and across any project milestone 2.10.3.16. voluntary standards Change Design Object Impacts Link on Milestone Attribute 6.1.4. Maintain history within and across any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control Guidance Elements 2.10.3.17. 6.2. Capture frequency and nature of element changes manufacturing processes 6.2. Capture frequency natureGuidance of element changes 1.2.4. Provide associations within and across Design and Control Elements 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide fordesign change elements Linkrationale to traced Change Design Object Traceability 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made Link to linked design elements Change Design Object Impacts 2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the change 2.10.4. For the specific design covered, how were the design input requirements identified? 1.3. Mange the change process 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in the another element 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone
43
Functional Spec
2.
Design Spec
Test Cases
1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design and development 1.1. Identify impacted elements due to a change in another element activities and define responsibility for implementation. 1. Capture design and related information 1. Capture design and related information with driving design elements Traceability Reports: consistency 1.1. Input electronically formatted data 1.1. Input electronically Impact Reports: other design elements affected formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external information sources 1.2. Reference external information sources Links to impacted design elements in, input to the design and development process. 1.3. Reference external documentation 1.3. Reference external documentation
3.
4.
5.
6.
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 elements 1.1.1. Create backward traces to design elements within and across any organizational 1.1.1. Create backward traces to design elements within and across any organizational The plans shall be reviewed as design and development evolves. Store design and related information 2. Store design and related information procedure procedure The plans shall be updated as design and development evolves. 2.1. Identify and tag design information as unique design elements 2.1. Identify and tag design information as unique design elements Attribute Traceability Reports: Procedure Traceability Reports: Procedure Attribute The plans shall be approved as design and development evolves. 2.2. Organize design elements 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Design Input Attribute Traceability Reports: Milestone Traceability Reports: Milestone Attribute 2.2.2. Organize by inter-relationships 2.2.2. Organize by inter-relationships 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to backward a 1.1.3. Create traces to design elements within and are across Design Control 2.3. Ensure all design elements are available 2.3. Ensure all design elements available 1.1.3. Create backward traces to design elements within and across Design Control device are appropriate address the intended use of the device, including the needs Guidance of the user Elements 2.3.1. Store design elements by Design Control Guidance and Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements andhistorical patient. values 2.3.2. Store design elements and their 2.3.2. Store design elements and their historical values Reports: Linked design elements Traceability Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a forward impacts to design within and across any organizational 1.1.4. Create forward impacts to design elements within and across any organizational device are appropriate and address the intended use of the device, including the1.1.4. needs Create of the user Manage all user needs 3. Manage elements all user needs and patient. procedure procedure 3.1. Identify the source of the user need 3.1. Identify the source of the user need 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 3.2. Identify all user types (groups) 3.2. Identify all user types (groups) Attribute Impact Reports: Procedure Impact Reports: Procedure Attribute 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer 1.1.5. Create forward impacts to design elements within(s) and across any project milestone 1.1.5. Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Attribute Impact Reports: Milestone Impact Reports: Milestone Attribute The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the 2.6. product (family) 3.5. State the intended use of the product (family) 2.7. design input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and across Design Control 1.1.6. Create forward impacts to design elements within and across Design Control 3.6. Capture the acceptance criteria forThe each user need 3.6. Capture the acceptance criteria for each user need 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input requirements design elements Impact Reports: Linked Impact Reports: Linked design elements shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 1.2. Associate changed design elements with related elements 1.2. Associate changed design elements with related elements 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need Linkof Change Design Object 4.3. withCapture affected design element(s) 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control Link Change Design Object with affected design element(s) 4.3. Capture requirement description and attributes requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. from Capture acceptance criteria affected design element(s) Traceability Links and Reports Traceability Links and Reports from affected design element(s) 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. affected Assign responsibility for each requirement design element(s) Impact Links and Reports from Impact Links and Reports from affected design element(s) 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical with following Attributes: 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Link on Procedure Attribute Change Design Object Change Design Object Traceability Link on Procedure Attribute 6. Traceability Manage change Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain of design Attribute element changes 6.1. Maintain history of design element changes Link history on Procedure Change Design Object Impacts Change Design Object Impacts Link on Procedure Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history available 1.2.3. Provide associations within and across any project milestone 1.2.3. Provide associations within and across any project milestone 2.10.3.14. reliabilityprocedure 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational Link on Milestone Attribute Change Design Object Traceability Change Design Object Traceability Link on Milestone Attribute 2.10.3.15. statutory and regulatory requirements 6.1.3. Maintain history within and across any project milestone 6.1.3. Maintain history within and across any project milestone 2.10.3.16. voluntary Link on Milestone Attribute Change Design Object Impacts Change Design Object Impacts Link on Milestone Attribute 6.1.4. Maintain history within and across any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control standards Guidance Elements 2.10.3.17. 6.2. Capture frequency natureGuidance of element changes 6.2. Capture frequency and nature of element changes manufacturing processes 1.2.4. Provide associations within and across Design and Control Elements 1.2.4. Provide associations within and across Design Control Guidance Elements 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide rationale for change Change Design Object Traceability Link to traced design elements Change Design Object Traceability Link to traced design elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made Change Design Object Impacts Link to linked design elements Change Design Object Impacts Link to linked design elements 2.10.3.20. design history files (DHFs) 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the change 2.10.4. For the specific design covered, how were the design input requirements identified? 1.3. Mange the change process 1.3. Mange the change process 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element 6.3. Identify impacted elements due to a change in the another element Design Design Change Module adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone Object History Object History Object History Reports Object History Reports Versions Versions Baselines Baselines
44
OLE Support
DOORS provides OLE support on Windows
You can embed an OLE object Use edit-in-place to make changes after embedded
You can link an OLE object Changes are made to the file in its original location Embed or link in a DOORS object: Table, Spreadsheet, Equation, Chart/graph Picture, Audio clip, Video clip The choice is only limited by what is installed on your system
46
Double-click
Launches source application
48
MS-Word
MS-Word
Automate d import
Spreadsheet
Interleaf
FrameMaker
HTML
RTF ASCII Spreadsheet Interleaf FrameMaker
Page Layouts can be created and saved Reports combine Views and Page Layouts
51
Print Preview
52
Modeling Tools
Simulation Tools
Coding Tools
Testing Tools
Documentation Tools
Project Management Tools
Metrics Tools
53
Lifecycle traceability
Business Process Modeling CM & Defect Tracking CASEwise (Corporate Modeler), Popkin (System Architect) Telelogic (Synergy), Merant (PVCS VM, Dimensions), Rational (ClearCase & ClearQuest), Intasoft (AllChange) Distributive SW (MetricCenter), Predicate Logic (TycoMetrics) Microsoft (MS Project), Primavera (Primavera Enterprise) Telelogic (Tau SDL Suite), Rational (Rose RT) , Artisan (Real-time Studio), ILogix (Rhapsody)
Software Modeling
Telelogic (Tau UML Suite), Rational (Rose), CA (Paradigm Plus), Embarcadero (GDPro), Togethersoft (TogetherJ), Aonix (Software Through Pictures)
Telelogic (Tau TTCN Suite), Mercury (TestDirector), Compuware (QA Director), T-Plan (T-Plan), Verecomm (TestExpert) Mathworks (MatLab), I-Logix (StateMate), Foresight Systems (Foresight), Virtual Prototypes (VAPS) Parametric Technology (WindChill), MatrixOne (eMatrix), IBM (Enovia), SDRC (Metaphase) Strategic Thought (Active Risk Manager) Galorath (SEER)
Software Testing
PDM/E-PLM
54
Constraints
No impact on schedules Compliance with Mobility - AMPS/PCS process Compliance with TL 9000 requirements Use of Mobility standard tools
Engagement Model: Collaboration & Co-ownership Spirit of Continuous Improvement with Clear Targets Focus on Technical Excellence
56
Test Management
Req. to Test Traceability
Tester Activities
APX-TMS
PacketIN Targets
Success Criteria
Reduction in Effort (THCM) Reduction in defects (end customer) Increase in multi-use of artifacts Increase in degree of automation
Data-driven approach
Metrics definition and automation Benchmarking data & monitoring Data collection, analysis and ongoingimprovement
57
Proposed
Requirements
Release to Field
Source*: Boehm, Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc. 1981. Boehm, Basili. Software Management. IEEE Computer, January 2001. 58
AFT: Benefits
AFT Increases quality and productivity while reducing the cycle time via:
Common scenario-based representation throughout development cycle
Cumulative $
Projected ROI
$200-500K in the first year $1-2M in each subsequent year
Distribution of savings: Reduction in field defects accounts for 35% of the expected savings Effort reduction accounts for 65% of the expected savings
Developer Activities
FTF 002 SRD support in DOORS DOORS 001 DOORS Infrastructure DOORS 003 XML Generation FTF 006 Use Case Syntax Check
ROSE
FTF 008 Rose Model Jumpstart FTF 007 Test Case Generation
SE Activities
DOORS
Test Management
FTF 004 Req. to Test Traceability
Tester Activities
APX-TMS
60
D-INTA
T-INTA
Tester
ROSE
Rose Model Hand-off CCMS Publ. Model Hand-off WEB
TMS
61
Industry data:
Use cases improved developer productivity by 40% (DaimlerChrysler) 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases
FTF 004
Generate XML: UC, POTR, Links Querying TMS Data Generate/ Update Surrog. Module Auto-Generate DOORS-TMS Links
SE
DOORS
DXL
XML File
Developer
Models Annotated with Req.; Run a Report Models Annotated with Tests; Run a Report
Traceability Report
63
Innovate the Way The Team Works Together: Process Flow for High Quality
Requirements written in DOORS Early Comments to SE
High Quality Review
Design
(Augmenting Rose)
Test
(Augmenting TMS)
XML representation of requirements for downstream tools Test coverage reports (traceability support) Metrics Reports
Test cases generation Design model jumpstart from requirements tool use case view and Optimized coverage UML sequence diagrams Choice of algorithms Design-to-unit test traceability support Tool-based requirements traceability Design to requirements Gaps & coverage traceability tool and Change notification reports Impact analysis Guidelines for legacy code Test reuse reengineering
Adds functionality to standard Mobility tools Provides Glue Software Scalable integration architecture
66
Summary
DOORS & AFT provide the ability to
Capture, manage, and communicate requirements and their changes Support the approval process of changes Verify requirements early in the lifecycle
67
Demo
FTF 010 Rose - based Design FTF 009 CM (CCMS) for Rose Models FTF 018 Design to UT Traceability
Developer Activities
FTF 002 SRD support in DOORS Demo DOORS 001 DOORS Infrastructure DOORS 003 XML Generation FTF 006 Use Case Syntax Check
ROSE
SE Activities
Demo
FTF 008 Rose Model Jumpstart FTF 007 Test Case Generation Demo
DOORS
Demo
Test Management
Tester Activities
APX-TMS
68
QUESTIONS? COMMENTS?
Backup
Demo
72
73
74
75
76
DOORS Extensions
77
Backup AFT
Start
1. System prompts user for 2. User enters 3. System sets
Fail
Success
79
80
81
Which option?
If all branches never rejoin, then all of these generation options are equivalent If some Extensions rejoin the main scenario, then All Steps might yield a smaller number of complex scenarios All Transitions guarantees exhaustive coverage of nodes and links
Success
Failure
Do you want simple tests? Do you want to minimize the number of tests?
82
INTA
Read requirements generate all combinations Tools generates all possible combinations with all header info Fill in details
83
Read requirements. Generate Oneliners Wait for cron job Fill in Header info Fill in details
Read Requirements. Tools generates test for all POTR and fills in the header information. Fill in details Clone new tests Delete tests for <non testable requirements>
Do you get all POTR requirements? Do you need to add tests not related to requirements?
Note: The cells on the left and right are step comparison. In the manual step a person needs to worry if they have created a test from all requirements. Using the tool, a one-liner for each is created, this removes the worry and allows them to create additional tests by cloning existing ones.
84
New Use Case added New Scenario added Changes in an existing scenario steps
New Actors are automatically imported; Make sure to generate test cases from make sure to import any new scenarios any new scenarios Inspect and manually delete Manual Change - manually rename the actor in Rose, all existing scenarios are updated automatically
86
AFT/TMS usage: MSG; CHAM (metrics); US; FW; PM; UL; XGW; PAM (metrics)
DOORS: DNS; DTMF; Faster Barge Rose Designs: n/a (designs 100% complete; AFT not applicable to SPA work) AFT/TMS usage: metrics collection only
87
Practices
Use Cases
drive iterations
Visual modeling
validate model against scenarios Collaborate on analysis
89
90
Do early test planning and load definition as outcome of upfront collaboration on defining iterations, use cases, scenarios and feature componentization
91
92
Get testers involved early to provide feedback and drive the testability of requirements and the design
Derive the related design scenarios early
Allocate the scenarios to components with high cohesion and low coupling
Define the corresponding test loads
93
Summary
Get it right the first time
Early collaboration: collaborating during the reviews maybe too late collaborate during the definition and artifact creation phases
94
References
Release documentation http://edgeweb2.cb.lucent.com/afti/Deliverables/sti_deli v.htm AFTI References page http://edgeweb2.cb.lucent.com/afti/References/default.h tm Agile RUP summary and some useful papers http://www.stc.lucent.com/~dmm/misc/agile_rup.html
95