Trazabilidad En El Proceso De Desarrollo De Sw

  • 2,483 views
Uploaded on

 

More in: Travel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,483
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
85
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Trazabilidad en el Proceso de Desarrollo de Software
  • 2. Contenidos
    • Introducción
    • Trazabilidad
    • Configurando la Trazabilidad
    • Conclusiones
  • 3. I. Introducción Proceso SW y Tra za bili dad Artefactos de Requisitos Artefactos de prueba Artefactos de Construccion Verificación Validación Asignación Rol 1 Rol 3 Rol n Rol 2 Actividad 1 Actividad 2 Actividad 3 Actividad n
  • 4. II. Trazabilidad
    • Definiciones:
      • Trazabilidad : El grado en el cual una relación puede ser establecida entre dos o más productos del proceso de desarrollo, especialmente entre productos que tienen una relación predecesor- sucesor o maestro-subordinado, por ejemplo, el grado en el cual se corresponden requisitos y el diseño de un sistema. (IEEE Std 610.12-1990).
      • Trace : Una dependencia que indica una relación histórica o de proceso entre dos elementos que representan el mismo concepto, sin reglas específicas para derivar uno desde el otro. (UML 2.0 2/8/2003)
  • 5. I. Trazabilidad Trazabilidad de Requisitos
    • Cambio en los Requisitos
    • Gestión de Requisitos es un área clave de proceso (KPA) para conseguir el segundo nivel de CMM (Managed level)
    • Trazabilidad de Requisitos : habilidad para seguir la vida de un requisito en ambos sentidos, hacia sus orígenes o hacia su implementación, a través de las especifica-ciones generadas durante el proceso de desarrollo. Es un factor de calidad [IEEE 830-1998]
  • 6. I. Trazabilidad Trazabilidad de Requisitos en CMMI
  • 7. II. Trazabilidad Información Necesaria y su Uso
    • Los enlaces de trazabilidad entre diferentes tipos de especificaciones soportan:
      • Verificar que la funcionalidad esperada ha sido incluida y que no existe funcionalidad superflua
      • Análisis de impacto
    • Las estructuras de contribución (enlaces entre stakeholders y especificaciones) permiten:
      • Mejorar la comunicación y cooperación
      • Asegurar que la contribución de cada individuo
    • Los fundamentos asociados a las especificaciones (alternativas, decisiones, suposiciones, etc.):
      • Mejorar la comprensión del sistema
      • Mejorar la gestión de los cambios
  • 8. II. Trazabilidad Problemas (Desafíos) en Trazabilidad
    • La Trazabilidad de Requisitos debe ser configurada de acuerdo con las características del proyecto (y de la metodología utilizada)
    • No existe consenso respecto de la información de trazabilidad que debe ser recolectada y de su uso. No existe unicidad de criterios en la definición e interpretación de los enlaces
    • Dos comunidades de trabajo e investigación: Ingeniería de Requisitos y Construcción de Software
    • Herramientas actuales
      • Orientadas al tratamiento textual de requisitos
      • No proveen mecanismos adecuados para configurar la trazabilidad
      • Problemas de integración entre herramientas: para gestión de requisitos y para construcción de software
  • 9. III. Configurando la Trazabilidad Tareas de Configuración
    • Seleccionar los tipos de artefactos que son relevantes desde la perspectiva de trazabilidad
    • Definir las relaciones de agregación entre artefactos
    • Establecer tipos de enlaces de trazabilidad que se registrarán, utilizando los artefactos seleccionados en la tarea 1
    • Definir criterios para derivar automáticamente enlaces de trazabilidad
  • 10. III. Configurando la Trazabilidad Ejemplo proyecto RUP: Tarea 1 Event Table Test Case Data Model Component Imlementation Model Class Analisis & Design Model Use Case Use Case Model Assumption Non-functional requirement Supplementary Specification Software Feature Vision Tipo de Artefacto
  • 11. III. Configurando la Trazabilidad Ejemplo proyecto RUP: Tarea 2 Vision   Software Feature Vision     Assumption Software Feature Software Feature Supplementary Spec.   Non-Functional Requirement Use Case   Use Case Event Use Case Model    Use Case Analysis & Design Model    Class Implementation Model   Component Data Model   Table
  • 12. III. Configurando la Trazabilidad Ejemplo proyecto RUP: Tarea 3 Stakeholder   — « responsibleOf »     Any Artifact Stakeholder   — « modifies »     Any Artifact Software Feature   — «traceTo»     Use Case Software Feature —« traceTo »     Table Assumption   — «supports»   Software Feature Use Case   — «validatedBy»   Test Case Use Case Event   — «traceTo»   Class Class   — «traceTo»    Component Class   — «traceTo»   Table Class   — «verifiedBy»   Test Case
  • 13. III. Configurando la Trazabilidad Ejemplo proyecto RUP: Tarea 4
    • Criterios usados para derivar enlaces de trazabilidad:
      • Coincidencia de nombre
        • Class   —« traceTo »   Component
      • Transitividad y Agregación
        • Software Feature —« traceTo »     Table
  • 14. III. Configurando la Trazabilidad Ejemplo proyecto RUP: Un Grafo de Trazabilidad « COMPONENT » Cliente « CLASS » Pedido « TABLE » Pedido « USE CASE » Elaborar Pedido « SOFTWARE FEATURE » Gestión de Pedidos « CLASS » Cliente « STAKEHOLDER » Juan Pérez, Encargado Almacén « VISION » Sistema Ventas on-line « USE CASE MODEL » Sistema Ventas on-line « ANALYSIS & DESIGN MODEL » Sistema Ventas on-line « IMPLEMENTATION MODEL » Sistema Ventas on-line « DATA MODEL » Sistema Ventas on-line « USE CASE EVENT » Cliente introduce datos pedido « USE CASE EVENT » Cliente introduce password « USE CASE » Atender Pedido
  • 15. IV. Conclusiones
    • Importancia de la trazabilidad
    • En la práctica, falta de consenso respecto de trazabilidad: información necesaria, explotación de dicha información, etc.
    • Especificaciones de requisitos y de pruebas (documentos de texto) versus especificaciones de análisis y diseño (modelos gráficos)