Your SlideShare is downloading. ×
Pepita
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Pepita

1,992

Published on

Archivo de Postgrado Paul Ortega

Archivo de Postgrado Paul Ortega

Published in: Business, Travel
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,992
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
149
Comments
0
Likes
0
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. Análisis y Especificación de Requerimientos Maestría en Administración de Tecnologías de Información Sesion 5a Dr. Juan Frausto Solís ITESM, Campus Cuernavaca Septiembre-diciembre del 2002
    • 2. Contenido
      • Importancia de la Especificación de Requerimientos
      • Principios sobre Análisis y Especificación de Requerimientos.
      • Documento de Especificación de Requerimientos IEEE Std 830, 1998
      • Protagonistas en el Análisis y Especificación de Requerimientos
      • Características y Atributos de una buena Especificación de Requerimientos.
      • Enfoques para la Especificación de Requerimientos
      • VIA Tarjetas CRC
      • Actividad via Proyecto de Medio Término
    • 3. Importancia de la Especificación de Requerimientos I
    • 4. Especificación de Requerimientos Requerimiento: Característica o Restricción de un Sistema. Ingeniería de Requerimientos: Proceso sistemático utilizado para derivar una definición del sistema de software a ser desarrollado.
    • 5. Especificación de Requerimientos Especificación Análisis Definición Solicitud
    • 6. Identificación de Requerimientos
      • Por su origen:
        • Funcionales : Comportamiento de los distintos módulos .
        • No Funcionales : Re stricciones del sistema (tiempo de respuesta, almacenamiento, casos de uso, logística).
      • Por su aparición cronológica:
        • De análisis ( descubrimiento ) y diseño .
        • De mantenimiento .
    • 7. Errores de una mala ER
      • Encontrar soluciones sin haber entendido los problemas .
      • Problemas de gran escala :
      • Los s istemas multi-versión y multi-programador deben trata rse diferente que sistemas pequeños .
      • Teléfono descompuesto .
      • Requerimientos cambiantes .
    • 8. Errores de una mala ER
      • Frecuentemente el cliente no sabe que quiere ; se le invent an necesidades falsas.
      • Tareas mal identificadas .
      • Establecimiento de requerimientos como mero trámite .
    • 9. Costos Asociados por su Reparación Software Engineerign Economics, Boehm 1981 100 -200 Mantenimiento 50 Pruebas de Sistema 20 Pruebas de Módulo 10 Codificación 5 Diseño 1-2 Requerimientos COSTO DE REPARACIÓN ETAPA
    • 10. Análisis del Problema Algunas Preguntas Útiles
      • ¿ Qué hacer para obtener una ER completa ?
      • ¿Cómo descomponer el problema en fragmentos manejables?
      • ¿Cómo organizar la información para que sea entendida?
      • ¿Cómo comunicar se con todas las partes involucradas?
      • ¿Cómo se resolverán las necesidades en conflicto?
      • ¿ C u án do detener el an á li sis ?
    • 11. Captura y Especificación de Requerimientos 1 Entrevista con Usuarios / Cliente Identificar necesidades y deseos Modelado de casos de negocios, de uso,.. Bosquejo de interfaces Identificación de hardware 2 Escritura de requerimientos en modo estándar 3 Revisión, inspección y validación de requerimientos
    • 12. Beneficios de la Especificación de Requerimientos
      • Establecimiento de acuerdos entre proveedores y usuarios sobre la funcionalidad de l software.
      • B ase para estimación de costos y calendarizaciones .
      • B ase para validaciones y verificaciones .
      • Facilita n transferencia y portabilidad .
      • B ase para mejora continua del software.
    • 13. Buenas Prácticas en la Especificación de Requerimientos
      • S eguir guía s adecuadas para mejorar la práctica de especificación de requerimientos en forma objetiva.
      • S eguir estándares reconocidos y aceptados .
    • 14. Principios sobre Análisis y Especificación de Requerimientos II
    • 15. Proceso de Ingeniería de Requerimientos Reporte de Factibilidad Estudio de Factibilidad Análisis de Requerimientos Modelos del Sistema Definición de Requerimientos Definición de Requerimientos Documento de Especificación de Requerimientos de Software Especificación de Requerimientos Especificación de Requerimientos
    • 16. Especificación de Requerimientos de Software (SRS) ESPECIFICACION Descripción Técnica de las características del Sistema DEFINICIÓN Lo que el usuario espera que el sistema haga
    • 17. Tipos de Requerimientos Requerimientos Ambiente Físico Interfaz Factores Humanos Funcionabilidad Documentación Datos Recursos Seguridad Aseguramiento de Calidad
    • 18. Documento de especificación de requerimientos de Software IEEE Std. 830-1998 III
    • 19. Std. IEEE 830-1998 Objetivo: Brindar una colección de buenas prácticas para escribir especificaciones de requerimientos de software (SRS). Se describ e n los contenidos y las cualidades de una buena especificación de requerimientos ; se m ue stran ejemplos de especificaciones.
    • 20. Aspectos básicos de ER
      • Funcionalidad
      • ¿Qué debe hacer el software ?
      • Interfaces Externas
      • ¿Cómo interactuará el software con el medio
      • externo (gente, hardware, otro s oftware )?
      • Rendimiento
        • Velocidad, disponibilidad, tiempo de respuesta, etc.
      • Atributos
      • Portabilidad, seguridad, mantenibilidad, eficiencia
      • Restricciones de Diseño
      • Estándares requeridos, lenguaje, límite de recursos, etc.
    • 21. Partes del documento de E R
      • Introducción
      • Descripción
      • Requerimientos Específicos
      • Apéndices
      • Índice
    • 22. Partes del documento de E R
      • Introducción
      • Propósito
      • Alcance
      • Definiciones, acrónimos y abreviaciones
      • Referencias
      • Panorama General
    • 23. Partes del documento de E R
      • 2. Descripción
      • Perspectiva del producto .
      • Funciones del producto .
      • Características de los usuarios .
      • Restricciones .
      • Suposiciones y dependencias .
    • 24. Partes del documento de E R
      • 3 Requerimientos Específicos
      • Requerimientos Funcionales
      • Requerimientos de Interfaz externa
      • Requerimientos de desempeño
      • Restricciones de diseño
      • Atributos
      • Otros
    • 25. Evolución de una ER Los requerimientos deben ser establecidos tan completamente como sea posible desde las etapas iniciales  Refinamiento Posterior. Establecer procesos formales para cambios y modificaciones que permitan controlar, rastrear y reportar cambios futuros y pasados.
    • 26. Protagonistas en el Análisis y Especificación de Requerimientos IV
    • 27. Definición y Analisis de Requerimientos Usuarios finales del sistema, clientes Administradores e ingenieros Administradores de los contratos Arquitectos del sistema Desarrolladores de Software
    • 28. Características y Atributos de una Buena Especificación de Requerimientos V
    • 29. Características de las Especificaciones
      • De Forma
        • Modificabilidad
        • Legilibilidad
        • Organizada por referencia
        • Organizada por revisión
      • De fondo
        • Completez
        • Independendencia de Plataforma
        • Consistencia
        • Precisión
        • Verificabilidad
    • 30. Características y Atributos Documentación
      • Correctez
      • Completez
      • Consistencia
      • Estabilidad
      • Verificable
      • Modificable
      • Rastreable
    • 31. Enfoques para la Especificación de Requerimientos VI
    • 32. Enfoques para SRS
      • Tarjetas CRC
      • Modelado Operacional: DFD’s,Redes de Petri, Máquinas de Estado.
      • Logicos y Algebráicos: Z, LOTOS
      • Modelado de Sistemas
        • Modelo de Objetos
        • Modelo de Rumbaugh
        • Modelo de Booch
        • Modelo de Jacobson
        • Modelo Unificado
    • 33. Tarjetas CRC Un método informal para modelado de software VI-A
    • 34. Diseño Preliminar y Detallado
      • Modelado a pequeña escala
        • Para aplicaciones relativamente limitadas y poco complejas
      • Modelado a gran escala
        • Para aplicaciones complejas
        • Dos tipos de orienta ción.
          • Por descomposición. Se p arte de un modelo global del sistema (top down)
          • Por composición.- Se modela partiendo de lo que se conoce de las distintas partes del sistema. (bottom-up)
        • S e incluyen los tipos de diagramas que describen el sistema (clases, objetos, transiciones, etc.)
    • 35. Verificación y Validación
        • Identificación de defectos
          • De ambigüidad
          • De consistencia
          • De completez
        • Definición de equipo de revisión del proyecto
        • Diseño de pruebas
        • Diseño de prototipos (Versiones Beta)
        • Verificaciones Iniciales e Intermedias
    • 36. Verificación y Validación
      • Administración de Riesgos
      • Algunos errores comunes:
        • Desuso de variables
        • Anidaciones y bifurcaciones impropias
        • Variables no definidas
        • Recursiones no autorizadas
        • Cálculos erróneos
        • Ciclos infinitos potenciales
        • Violación de estándares
        • Inconsistencias
        • etc.
    • 37. Tarjetas CRC - ¿Qué son?
      • Tarjeta indexada que información de un objeto, una clase, su comportamiento y sus interacciones.
      • CRC – Class Responsabilities Collaborators
      • Introducidas por Kent Beck and Ward Cunningham
    • 38. ¿Porqué son útiles?
      • Son portables
      • Visualizar el funcionamiento del proyecto sin necesidad de software
      • Son útiles para el proceso de enseñanza del enfoque orientado a objetos
      • Pueden utilizarse como una metodología en sí mismo o como el “front-end” de una metodología en particular (Booch, OMT, etc)
    • 39. ¿Cómo son?
      • Normalmente miden 3x5 ó 4x6 pulgadas.
      • Tienen la siguiene forma:
    • 40. ¿Cómo se usan ?
      • Se usan normalmente en sesiones de experto del área/desarrollador o desarrollador/desarrollador en grupos no mayores a 6 personas para discutir sobre las características de la implementación.
    • 41. Sesión CRC
      • Orden de la Sesión:
        • Análisis del problema
        • Definición de clases
          • Tormenta de ideas
          • Filtrado de clases
        • Definición de superclases y subclases
        • Definición de responsabilidades.
        • Definición de atributos.
        • Operación en escenarios determinados.
    • 42. Actividad
      • Para tu proyectos de Medio término elabora los siguientes reportes:
      • Documento de Especificación de requerimientos de acuerdo con el estándar de la IEEE.
      • Reporte de Factibilidad de requerimientos. Identifica los riesgós a que se enfrentará el sistema (incluyendo nuevas tecnologías o nuevo uso de ellas). Evalúa la factibilidad de realización, de buen uso del sistema.
      • Reporte del Proceso de Ingeniería de requerimientos en formato libre, describiendo el proceso para lograr los documentos anteriores.
    • 43.  
    • 44.  
    • 45.  
    • 46.  
    • 47.  
    • 48.  

    ×