Soluciones Telelogic

Transcripción

1 Simo 2003 Gestión Integrada de Requisitos Antonio Rodríguez Perales Soluciones Telelogic PRIS Taller sobre Pruebas en Ingeniería del Software, Sitges 3 octubre 2006 Antonio Rodríguez Perales antonio.rodriguez@telelogic.com

2 Telelogic: Una compañía en la que puede confiar Financieramente Saludable En el mercado durante los últimos 22 años Crecimiento continuo en 2004/2005 Con beneficios, balance de caja positivo, sin deudas Presencia Global Oficinas en 22 países en todo el mundo Soporte 24x7 Desarrollo Global Liderazgo de Mercado Soluciones lideres para todo el ciclo de vida Herramientas lideres en su clase Más de licencias en todo el mundo Lideres en la definición de los estándares: UML, BPMN, SysML,..

3 municaciones Gracias a Nuestros Clientes Militar Aeroespacial Transportes Automóviles Finanzas Seguros Comercio

4 Un líder del mercado reconocido System Architect and Focal Point.. have propelled Telelogic s application lifecycle management (ALM) capability further up the value chain.. and ahead of the likes of Borland, IBM, Microsoft and others. - Bola Rotbi Ovum Market LEADER 2004 Magic Quadrant LEADER 2005 METAspectrum LEADER 2004 Technology LEADER 2005 Technology Innovator 2005 Technology LEADER 2005

5 Gestión Integrada del Ciclo de Vida E L M A L M

6 Soluciones Integradas Lideres en su Clase Dashboard: Panel de Control de los Procesos de Desarrollo Métricas de Proyecto y Alarmas Soporte a CMMI, six sigma, ITIL, PMI, ISO SYSTEM ARCHITECT: Arquitectura Empresarial y Modelado de Procesos de Negocio Líder del Mercado (Gartner y Meta Group) Soporte BPMN, IDEF, BPEL, Framewoks: Zachman, TOGAF, ETON, FOCAL POINT: Soporte a la Toma de Decisiones Gestión de Productos Evaluación de Requisitos y Priorización Análisis de mercado y de valor

7 Soluciones Integradas Lideres en su Clase DOORS: Gestión de Requisitos Líder del Mercado para Gestión de Requisitos Lider Tecnólogico según Yphise TAU: Herramienta UML2.0 líder por Gartner, IDC, VDC Análisis y diseño, simulación y pruebas Soporte a TTCN-3 (Testing & Test Control Notation) SYNERGY: Gestión del Cambio y Configuración Gestión Global del Cambio Gestión de Configuración basada en Tareas Líder Tecnológico (Yphise ; Ovum 2004) Logiscope: Analsis Estático de Código y Cobertura Pruebas Métricas, reglas de estilo y cobertura de las pruebas

8 PRIS Taller sobre Pruebas en Ingeniería del Software, Octubre 2006 Acción especial RePRIS, financiada por el MEC y FEDER, TIN E

9 Gestión Integrada de todo el Ciclo de Vida ALM: Application Lifecycle Management Change Management WorkFlow User Requirements Specification Functional Specification Requs. Manag. Acceptance testing System testing Design Integration testing Test Management Change Management WorkFlow SW Configuration Management Workflow

10 Primero, Validación Req. Usuario Analisis Diseño Pruebas (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. The plans shall be approved as design and development evolves. Traceability Reports: Procedure 2.1. Identify Attribute and tag design information as unique design elements 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 Create of 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 needand 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 requirements2.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 of Change 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 Maintain Link on history Milestone within and Attribute 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 Después, Verificación

11 Completa Trazabilidad DOORS: Gestión de Requisitos y Trazabilidad ChangeSynergy: Ordenes de Trabajo Ordenes de Trabajo Descomposición en Tareas heros CM Synergy: Tareas

12 Como podemos detectar eficientemente los errores del código? 80% de los errores están localizados en el 20% de los módulos de software La mayoría de los errores pueden ser detectados mediante inspección del código, utilizando procedimientos estadísticos La aplicación de métricas de calidad, reglas de programación y otras técnicas permite identificar posibles errores y módulos potencialmente peligrosos Proceso de Validación y Verificación seguirá aun detectando errores en el código!!

13 Logiscope Audit Revisión del código: métricas de calidad e identificación de módulos erróneos Ficheros Fuente Sistema De Calidad Medio Pobre Excelente Estabilidad Testeabilidad Bueno Capacidad de cambio Capacidad de ser analizado Gestión visual del sistema software goto if Ficheros Fuente Grafico de control Grafico de llamadas

14 Logiscope RuleChecker Prevención de errores: Detección de código potencialmente erróneo Código fuente resaltado Ficheros Fuente Reglas de programción Ayuda en HTML Reglas violadas Ejemplo: if(x=y){} prohibido, posible confusión con if(x==y){} Facilidad de mantenimiento: mismas reglas utilizadas para toda la compañía y subcontratistas Ejemplo: Una variable global siempre debe empezar por mayúsculas.

15 El numero ciclomático V (G) V(G) es el máximo número de caminos linearmente independientes dentro de una función V(G) = = 2 V(G) = e - n +1 Donde: e numero de arcos n numero de nodos V(G) es el minimo número de test unitarios necesarios para testear completamente una función

16 Test Unitarios Existen múltiples frameworks para la generación de Test Unitarios Por ejemplo, usando UML Testing Profile sd SequenceDiagram1 interaction TestCase2 {1/1} <<SUT>> sut : Player2 <<TestComponent>> tc : TestComponent1 Integer x; Ping(4) Pong(x) arbiter.asserttrue(x!= 4); x should b 4 so this test case should fail

17 Pruebas Funcionales El objetivo es comprobar que el sistema cumple con los requisitos y especificaciones Se utilizan a la vez para descubrir la presencia de defectos Se utilizan tanto técnicas de caja blanca como de caja negra, aunque estas últimas son las más apropiadas Test cases Test data Test results Test reports Design test cases Prepare test data Run program with test data Compare results to test cases

18 Pruebas Funcionales con Telelogic DOORS DOORS Test Tracking Toolkit

19 Requisitos conducen procesos de VERIFICACION DOORS: Gestión de Requisitos y Trazabilidad DOORS: Planificación Test Verificar que el sistema hace lo que debe hacer (requisitos), no que hace lo que hace (implementación) DOORS: Informes Test

20 Automatizar las Pruebas? Ser realista, es posible automatizar mis pruebas? Potenciales beneficios: Menos Tiempo Menos recursos Ejecución desatendida Reutilizable Reproducible Test complejos AUTOMATIC TESTING SYSTEM FOR MINUTEMAN MISSILE

21 Plataformas de Automatización UML Testing Profile sd SequenceDiagram1 interaction TestCase2 {1/1} <<SUT>> sut : Player2 <<TestComponent>> tc : TestComponent1 Integer x; Ping(4) Pong(x) arbiter.asserttrue(x!= 4); x should b 4 so this test case should fail TTCN3 (Testing and Test Control Notation) Executable Test Suite MTC PTC PTC T S I SUT

22 Integración con Especialistas en la Automatización DOORS: Gestión de Requisitos y Trazabilidad DOORS: Planificación Test DOORS: Informes Test

23 Logiscope TestChecker Representación gráfica de cobertura del código fuente goto Uncovered Code if Covered Code Evalúa el nivel del cobertura del código If ((A or B) and C) then else 100% Cobertura total 50% Cobertura del proceso de decisión then / else 11% MC/DC (Condición / Decisión) Cada combinación de A/B/C & then/else

24 Cobertura de las Pruebas Black box vs. White box Black box solo functional testing coverage Target La estrategia efforts Combinar ambos para conseguir los objetivos a tiempo coverage White box solo structural testing coverage Target efforts efforts

25 Gestión de Defectos DOORS: Gestión de Requisitos y Trazabilidad DOORS: Planificación Test CM Synergy: Tareas Peticiones de Cambio Requisitos tivecm ChangeSynergy: Gestión de incidencias y Ordenes de Trabajo Incidencias DOORS: Informes Test