Requisitos, trazabilidad y validación de sistemas con IBM Rational DOORS

Transcripción

1 Mejores Prácticas en el desarrollo de software para productos 25 Marzo 2010 Requisitos, trazabilidad y validación de sistemas con IBM Rational DOORS Francisco J. López Minaya Rational Technical Solution Architect francisco.lopezminaya@es.ibm.com

2 Productos cada vez más inteligentes e innovadores en cualquier área Smarter automobiles Smarter health care Smarter devices Smarter hybrid vehicles Smarter energy Smarter defense systems 2

3 Qué retos se nos plantean? Dónde nos duele? Sistemas cada vez más complejos: más información. Cliente exige productos de mayor calidad y libres de fallos Equipos de trabajo geográficamente distribuidos: diferentes formas de trabajo, diferentes formatos Equipos de trabajo no distribuidos pero de diferentes disciplinas Cambio constante. Gestión impacto de cambios Regulaciones y estándares exigen demostrar evidencias Generación de documentación 3

4 IBM Rational DOORS Plataforma de colaboración Centralizar, organizar, estructurar, trazar y gestionar los requisitos del producto Información actualizada accesible para todos los miembros del equipo. Facilita la colaboración y comunicación entre ellos. Acceso controlado, permisos de acceso Trazabilidad Establecer relaciones entre requisitos, entre requisitos y pruebas, entre requisitos y diseño software, entre requisitos y diseño hardware (diseño mecánico, eléctrico, etc) Demostrar que el sistema final cumple los requisitos de cliente Demostrar que el sistema final está probado Control de los procesos de desarrollo/construcción y verificación&validación desde los requisitos Customer Requirements Application Development Traceability Specifications Full Coverage Design Implementation Integration Testing System Testing Acceptance Testing Test and Verification Coverage Gestión del cambio Análisis de impacto de cambios, seguimiento del estado de los cambios Flexibilidad Fácil implementación de cualquier proceso de desarrollo

5 Acceso controlado y organización de la información

6 Acceso simultáneo a la información Modo de apertura: Sólo lectura Edición compartida Edición exclusiva acceso sólo lectura, permite editar a otros usuarios permite editar a varios usuarios simultáneamente edición exclusiva del documento

7 Acceso remoto a través de DOORS Web Access Todo el equipo trabaja con la misma versión de requisitos Revisión y edición de requisitos vía web Visualización y exploración de la trazabilidad Distribución de requisitos y comunicación con el resto del equipo utilizando URLs http Comunicación con usuarios de DWA o DOORS a través de los foros de discusión 7

8 Proceso de desarrollo de sistemas System/Product definition Stakeholder Requirements System/Product V&V Acceptance Tests System Reqs System Arq. (SysML) System Tests Subsystem HW Reqs Subsystem SW Reqs SW Integration Tests HW Design: Mechanical Design, Electrical Design,.. SW Design (UML) Code generation Code SW Component Tests Unit Tests Hardware Software

9 Gestión de Trazabilidad con DOORS User Reqs System Reqs Subsystem Reqs Tests (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 (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 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 The procedures shall include a mechanism for addressing incomplete requirements The procedures shall include a mechanism for addressing ambiguous requirements The procedures shall include a mechanism for addressing conflicting requirements The design input requirements shall be documented by a designated individual(s) The design input requirements shall be reviewed by a designated individual(s) The design input requirements shall be approved by a designated individual(s) The approval, including the date and signature of the individual(s) approving the requirements, shall be documented Questions Summarize the manufacturer's written procedure(s) for identification and control of design input From what sources are design inputs sought? Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) intended use user/patient/clinical performance characteristics safety limits and tolerances risk analysis toxicity and biocompatibility electromagnetic compatibility (EMC) compatibility with accessories/auxiliary devices compatibility with the environment of intended use human factors physical/chemical characteristics labeling/packaging reliability statutory and regulatory requirements voluntary standards manufacturing processes sterility MDRs/complaints/failures and other historical data design history files (DHFs) For the specific design covered, how were the design input requirements identified? For the specific design covered, how were the design input requirements reviewed for adequacy? (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 1.1. Identify and development impacted elements due to a change in another element 1. Capture design and related information activities and define responsibility for implementation. Traceability Reports: consistency 1. Capture with design driving and related design information elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, Impact or result Reports: other design elements affected 1.2. Reference external information sources 1.2. Reference external information sources 1.3. Reference external documentation in, input to the design and development process. Links to impacted design elements 1.3. Reference external documentation Create backward traces to design elements within and across any organizational 2. Store design and related information The plans shall be reviewed as design and development evolves. procedure 2. Store design and related information 2.1. Identify and tag design information The plans shall as unique be updated design as design elements and development evolves Identify and tag design information as unique design elements The plans shall be approved as design and development evolves. Traceability Reports: Procedure Attribute 2.2. Organize design elements 2.2. Organize design elements Create backward traces to design elements within and across any project milestone Organize by Design Control Guidance Element Organize by Design Control Guidance Element Organize by inter-relationships (c) Design Input Traceability Reports: Milestone Organize Attribute by inter-relationships 2.3. Ensure all design elements are 2.1. available Each manufacturer shall establish procedures to ensure that the design requirements relating Create to backward a traces to design 2.3. Ensure elements all design within elements and are across available Design Control Store design elements by Design device Control are appropriate Guidance and Element address the intended use of the device, including the needs of the user Guidance Elements Store design elements by Design Control Guidance Element Store design elements and their and historical patient. values Store design elements and their historical values 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating Traceability to a Reports: Linked design elements 3. Manage all user needs device are appropriate and address the intended use of the device, including the needs of Create the user forward impacts 3. to design Manage elements all user needs within and across any organizational 3.1. Identify the source of the user need and patient. procedure 3.1. Identify the source of the user need 3.2. Identify all user types (groups) 2.3. The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure 3.2. Identify Attribute all user types (groups) 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements Identify the customer (s) 2.5. The procedures shall include a mechanism for addressing conflicting requirements Create forward impacts to design elements within and across any project milestone 3.4. Profile the expected patients 3.4. Profile the expected patients 3.5. State the intended use of the 2.6. product The (family) design input requirements shall be documented by a designated individual(s). Impact Reports: Milestone 3.5. State Attribute the intended use of the product (family) 3.6. Capture the acceptance criteria 2.7. for The each design user need input requirements shall be reviewed by a designated individual(s) Create forward impacts to design 3.6. Capture elements the acceptance within and criteria across for each Design user need Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements shall be documented. Impact Reports: Linked design elements 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement Questions Associate changed design elements with related elements 4.2. Identify the associated user need 4.2. Identify the associated user need 4.3. Capture requirement description and attributes Summarize the manufacturer's written procedure(s) for identification and control Link ofchange Design Object 4.3. with Capture affected requirement design element(s) description and attributes 4.4. Capture acceptance criteria design input. Traceability Links and Reports 4.4. from Capture affected acceptance design criteria element(s) 4.5. Assign responsibility for each requirement From what sources are design inputs sought? 4.5. Assign responsibility for each requirement Do design input procedures cover the relevant aspects, such as: (Mark all that Impact apply and Links and Reports from affected design element(s) 4.6. Manage incomplete requirements 4.6. Manage incomplete requirements list additional aspects.) Associate design element changes with decisions, rationale, and approval authority 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements intended use information 4.8. Manage conflicting requirements 4.9. Approve all requirements user/patient/clinical Change Decision Objects 4.9. with Approve following all requirements Attributes: performance characteristics safety Disposition Attribute 5. Manage acceptance 5. Manage acceptance 5.1. Ensure the acceptance of every user need limits and tolerances Decision Attribute 5.1. Ensure the acceptance of every user need 5.2. Ensure the acceptance of every design input requirement risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.3. Document the results of every user need acceptance toxicity test and biocompatibility Owner Attribute 5.3. Document the results of every user need acceptance test 5.4. Document the results of every design input requirements electromagnetic test compatibility (EMC) 5.4. Document the results of every design input requirements test 5.5. Make acceptance results available compatibility with accessories/auxiliary devices Management Approval Attribute 5.5. Make acceptance results available compatibility with the environment of intended use Provide associations within and across any organizational procedure 6. Manage change human factors Change Design Object 6. Traceability Manage change Link on Procedure Attribute 6.1. Maintain history of design element changes physical/chemical characteristics Change Design Object Impacts 6.1. Maintain Link history on Procedure of design Attribute element changes Make complete change history available labeling/packaging Make complete change history available Maintain history within and across any organizational reliability Provide associations within and across any project milestone procedure Maintain history within and across any organizational procedure Maintain history within and across any project statutory milestone and regulatory requirements Change Design Object Traceability Link on Milestone Attribute Maintain history within and across any project milestone Maintain history within and across any Design voluntary Control standards Guidance Elements Change Design Object Impacts Link Maintain on Milestone history within Attribute and across any Design Control Guidance Elements 6.2. Capture frequency and nature of element changes manufacturing processes Provide associations within 6.2. and Capture across frequency Design and Control nature Guidance of element changes Elements Provide rationale for change sterility Provide rationale for change Describe decisions made MDRs/complaints/failures and other historical data Change Design Object Traceability Link to traced design elements Describe decisions made Identify approval authority for the change design history files (DHFs) Change Design Object Impacts Link Identify to linked approval design authority elements for the change Capture date, time, and signature of approving For the specific authority design covered, how were the design input requirements 1.3. Mange identified? the change process Capture date, time, and signature of approving authority 6.3. Identify impacted elements due to a change For in the another specific element design covered, how were the design input requirements reviewed for Design Change Module 6.3. Identify impacted elements due to a change in another element Create backward traces to design elements adequacy? within and across any organizational procedure Create backward traces to design elements within and across any organizational procedure Design Change Reports Create backward traces to design elements within and across any project milestone Create backward traces to design elements within and across any project milestone Object History Object History Reports Versions Baselines 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 Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 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) 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 Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 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 Trazabilidad total en una única vista

10 Matrices/Vistas de trazabilidad Representación semi-gráfica de la trazabilidad Contenido dinámico, actualizado en tiempo real con la creación de nuevos links Vistas de trabajo, útiles en el día a día: requisitos cubiertos, requisitos no cubiertos, impacto de cambio, etc. Pueden incluirse directa y automáticamente en un report, evitando malgastar tiempo en formateo, construcción y mantemiento de estas matrices. Estas matrices son las evidencias de implementación o verificación/validación exigidas por el cliente o por las diferentes regulaciones o normativas a cumplir en nuestra industria. Construcción muy sencilla, a través de un asistente

11 Creación de relaciones de trazabilidad Nuevo Link Creación n con drag & drop

12 Trazabilidad entre requisitos de varios niveles Stakeholder Reqs (UAV-) System Reqs (SRSUAV-) Flight Mngmt Reqs (FMS-) Missile Control Reqs (MCS-)

13 Trazabilidad entre requisitos y elementos de diseño software

14 Trazabilidad entre requisitos y elementos de diseño hardware Diseños mecánicos, eléctricos, informes técnicos asociados con el requisito

15 Trazabilidad con las pruebas

16 Análisis de impacto de cambios Evaluación del impacto de cambios de forma rápida y fiable a través de links Un cambio en impacta en y en

17 Completitud, progreso del proyecto Fácil detección de requisitos no satisfechos, sin prueba asociada, etc Los huecos muestran los requisitos no satisfechos, trabajo que falta por hacer

18 Beneficios Gestión de trazabilidad con DOORS Control de los procesos de desarrollo, construcción y validación y verificación del producto a partir de los requisitos Cumplimiento con estándares y normativas CMMI: trazabilidad bi-direccional FDA, IEC 61508, DO-178B: trazabilidad hasta código La gestión de la trazabilidad con DOORS facilita actividades de análisis como: Análisis de impacto de cambios Control y seguimiento del progreso del proyecto Cobertura de pruebas

19 Problemas en el ámbito de la documentación Los ingenieros malgastan su tiempo: formateando documentos recopilando información de diferentes fuentes manteniendo la documentación actualizada Retrasos en los entregables por tiempo malgastado en edición Las prisas y la edición manual aumentan el riesgo de errores Contaminación de la información por mala edición Errores en formato Documentación de baja calidad Hoy se actualiza documentación que mañana estará obsoleta Studies by AIIM and Ford Motor Company estimate that knowledge workers spend 15-25% of their time on non-productive information-related activities. IDC whitepaper: High Cost of Not Finding Information 19

20 IBM Rational Publishing Engine (RPE) Automatiza la generación de documentación desde productos Rational y desde otras aplicaciones Permite crear documentos extrayendo información de múltiples fuentes en una única generación. Permite obtener documentos en diferentes formatos de salida (MS Word, PDF, HTML, XML) en el mismo proceso de generación Permite definir la estructura, contenido y formato de los documentos de forma independiente del origen de la información y del formato de salida: RPE Document Template Definición de plantillas de forma rápida y sencilla mediante un entorno gráfico intuitivo y fácil de utilizar: RPE Document Studio. Reutilización de plantillas: Shared Template Library Plantillas predefinidas listas para su utilización

21 RPE Múltiples fuentes y formatos de salida DOORS TAU ReqPro ClearCase ClearQuest RQM Rhapsody Change RRC System Architect Rational Publishing Engine HTML MS Word PDF XSL-FO Generic XML 21

22 Resultado

23 Demostración 23

24 Modelo de Datos Ejemplo Marketing Reqs Stakeholder Reqs System Reqs System Tests Hardware Design Software Design

25 Francisco J. López L Minaya Rational Technical Solution Architect francisco.lopezminaya@es.ibm.com Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 25