Pruebas de Software. Ingeniería del Software I Universidad Rey Juan Carlos. Verificación de Software: Validación de Software:

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Pruebas de Software. Ingeniería del Software I Universidad Rey Juan Carlos. Verificación de Software: Validación de Software:"

Transcripción

1 Pruebas Software Universidad Rey Juan Carlos César Javier Acuña Introducción Verificación Software: Determinar si los productos una fase dada satisfacen las condiciones impuestas al inicio la fase Validación Software: Evaluación un sistema o uno sus componentes durante o al final su sarrollo para terminar si satisface los requisitos. 2 1

2 Introducción Verificación Estamos construyendo correctamente el producto? Validación Estamos construyendo el producto correcto? Las permiten validar y verificar el software 3 Introducción Pruebas (test): «una actividad en la cual un sistema o uno sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación algún aspecto» Caso Prueba (test case): «un conjunto entradas, condiciones ejecución y resultados esperados sarrollados para un objetivo particular» 4 2

3 Introducción Defecto (fect, fault, «bug»): «un fecto en el software como, por ejemplo, un proceso, una finición datos o un paso procesamiento incorrectos en un programa» Fallo (failure): «La incapacidad un sistema o alguno sus componentes para realizar las funciones requeridas ntro los requisitos rendimiento especificados» 5 Introducción Error (error): La diferencia entre un valor calculado, observado o medio y el valor verdaro, especificado o teóricamente correcto. Un fecto Un resultado incorrecto Una acción humana que conduce a un resultado incorrecto. 6 3

4 Introducción Error Equivocación l programador = 5 Sistema gestión aeropuerto Accinte (seguridad) Defecto (calidad) S.Aproximación Xyx//??? Fallo (fiabilidad) 7 Introducción Probar exhaustivamente el SW es imposible Es imposible evaluar todas las posibilidas Un proceso prueba será exitoso cuando encuentre errores Los errores no son siempre fruto la negligencia l programador 8 4

5 Introducción Recomendaciones Cada caso prueba be finir el resultado salida esperado El programador be evitar probar sus propios programas, ya que sea (consciente o inconscientemente) mostrar que funcionan sin problemas Se be inspeccionar a conciencia el resultado cada prueba, así, por scubrir posibles síntomas fectos 9 Introducción Recomendaciones Al generar casos prueba, se ben incluir tanto datos entrada válidos y esperados como no válidos e inesperados. Las ben centrarse en dos objetivos (es habitual olvidar el segundo): Probar si el software no hace lo que be hacer Probar si el software hace lo que no be hacer, es cir, si provoca efectos secundarios adversos 10 5

6 Introducción Recomendaciones Se ben evitar los casos sechables, es cir, los no documentados ni diseñados con cuidado No ben hacerse planes prueba suponiendo que, prácticamente, no hay fectos en los programas y, por lo tanto, dicando pocos recursos a las. 11 Introducción Recomendaciones La experiencia parece indicar que don hay un fecto hay otros, es cir, la probabilidad scubrir nuevos fectos en una parte l software es proporcional al número fectos ya scubierto. Las son una tarea tanto o más creativa que el sarrollo software. Siempre se han consirado las como una tarea structiva y rutinaria. 12 6

7 El Proceso Prueba Planear Planear Plan Diseñar Diseñar Configuración (casos y procedimientos) Ejecutar Ejecutar Información sobre proyecto Información sobre software (ERS, diseño, etc) Configuración Resultados software revisada Resultados esperados Correcciones DESARROLLO DESARROLLO Acciones preventivas (formación, mejora procesos, etc) Predicción fiabilidad Depuración Depuración Análisis Análisis errores errores Errores: histórico e informes Evaluar Evaluar Estadística errores 13 Técnicas Diseño Casos Prueba Utilizamos técnicas para conseguir una confianza aceptable en que se tectarán los fectos existentes Equilibrio entre los recursos empleados y la confiabilidad los casos prueba Elegir los casos prueba que puedan representar a los mas. La elección no be ser al azar 14 7

8 Técnicas Diseño Casos Prueba Existen tres enfoques para el diseño casos prueba: El enfoque estructural o caja blanca El enfoque funcional o caja negra El enfoque aleatorio consiste en utilizar molos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir ellos los casos prueba 15 Técnicas Diseño Casos Prueba Caja blanca Entrada Salida Caja negra Entrada Salida Funciones 16 8

9 Pruebas Estructurales El diseño los casos be basarse en la elección caminos importantes que ofrezcan una seguridad aceptable. Se utilizan criterios cobertura lógica Es conveniente construir un diagrama flujo control (flowchart) 17 Pruebas Estructurales Abrir archivos; Leer archivo ventas, al final indicar no más registros; 1 2 Limpiar línea impresión; WHILE (haya registros ventas) DO 3 Total nacional = 0; Total extranjero = 0; 4 WHILE (haya reg. ventas) y (mismo producto) IF (nacional) THEN Sumar venta nacional a total nacional ELSE Sumar venta extranjero a total extranjero ENDIF; Leer archivo ventas, al final indicar no más registros; ENDWHILE; Escribir línea listado; Limpiar área impresión; ENDWHILE; 7a 5 6 8,9 10,11 7b Cerrar archivos. 12,

10 Pruebas Estructurales Cómo dibujar un grafo flujo Señalar sobre el código cada condición cada cisión tanto en sentencias If-then y Case-of como en los bucles While o Until. Agrupar el resto las sentencias en secuencias situadas entre cada dos condiciones. Numerar tanto las condiciones como los grupos sentencias, manera que se les asigne un intificador único 19 Pruebas Estructurales Criterios Cobertura De Sentencias: Se trata generar los casos prueba necesarios para que cada sentencia o instrucción l programa se ejecute, al menos, una vez. De cisiones: Consiste en escribir casos suficientes para que cada cisión tenga, por lo menos una vez, un resultado verdaro y, al menos una vez, uno falso

11 Pruebas Estructurales De condiciones: Se trata diseñar tantos casos como sea necesario para que cada condición cada cisión adopte el valor verdaro al menos una vez y el falso al menos una vez. De cisión/condición. Consiste en exigir el criterio cobertura condiciones obligando a que se cumpla también el criterio cisiones. De condición múltiple. En el caso que se consire que la evaluación las condiciones cada cisión no se realiza forma simultánea. 21 Pruebas Estructurales La cobertura caminos es el criterio mas elevado Cada camino be ser probado Caminos prueba: ejecutar cada bucle por lo menos una vez Utilizando caminos prueba se pue cuantificar la cantidad caminos (permite asignar correctamente los recursos) 22 11

12 Pruebas Estructurales Complejidad Ciclomática McCabe (V(G)) Empleada para terminar el Nº caminos inpendientes. Valor la métrica es un buen criterio V(G) a-n+2, siendo a el número arcos y n el número nodos r, siendo r el número regiones cerradas c+1, sindo c el número nodos condición 23 Pruebas Estructurales 1 a1 a2 a3 2 a4 3 Región 1 a5 a6 a7 4 Región 2 a9 a8 5 Región 3 a10 a11 6 a12 Región a13 a Región

13 Pruebas Estructurales Para elegir los caminos inpendientes a probar se utiliza el método l camino básico Consiste en realizar variaciones sobre un camino prueba típico que llamamos básico Pruebas Funcionales Particiones o Clases Equivalencia Las cualidas que finen un buen caso prueba: Cada caso be cubrir el máximo número entradas Debe tratarse el dominio valores entrada dividido en un número finito clases equivalencia que cumplan la siguiente propiedad: la prueba un valor representativo una clase permite suponer «razonablemente» que el resultado obtenido (existan fectos o no) será el mismo que el obtenido probando cualquier otro valor la clase 26 13

14 Pruebas Funcionales El método consiste entonces en: Intificación las clases equivalencia Creación los casos prueba correspondientes Intificación las Clases Equivalencia Intificar las restricciones al formato y contenido los datos las entradas Intificar las clases equivalencia: De datos Válidos De Datos no Válidos o Erróneos 27 Pruebas Funcionales Existen algunas reglas que ayudan a intificar clase: Si se especifica un rango valores para los datos entrada, se creará una clase válida y dos clases no válidas Si se especifica un número valores, se creará una clase válida y dos no válidas Si se especifica una situación l tipo «be ser» o booleana (por ejemplo, «el primer carácter be ser una letra»), se intifican una clase válida («es una letra») y una no válida («no es una letra») 28 14

15 Pruebas Funcionales Si se especifica un conjunto valores admitidos y se sabe que el programa trata forma diferente cada uno ellos, se intifica una clase válida por cada valor y una no válida. En cualquier caso, si se sospecha que ciertos elementos una clase no se tratan igual que el resto la misma, ben dividirse en clases menores. Desarrollar los casos prueba Este proceso consta los siguientes pasos Asignación un número único a cada clase equivalencia 29 Pruebas Funcionales Hasta que todas las clases equivalencia hayan sido cubiertas por (incorporadas a) casos prueba, se tratará escribir un caso que cubra tantas clases válidas no incorporadas como sea posible Hasta que todas las clases equivalencia no válidas hayan sido cubiertas por casos prueba, escribir un caso para una única clase no válida sin cubrir

16 Pruebas Funcionales Ejemplo: Especificación Código área: número 3 dígitos que no empieza ni por 0, ni por 1. Nombre intificación: 6 caracteres. Ornes posibles: "cheque", "pósito", "pago factura", "retirada fondos". 31 Pruebas Funcionales Ejemplo: Condición entrada Clases válidas Clases inválidas Código área (1) 200 código 999 (2) código <200 (3) código >999 (4) no es número Nombre para intificar la operación Orn (8) «cheque» (9) «pósito» (10) «pago factura» (11) «retirada fondos» (5) seis caracteres (6) menos 6 caracteres (7) más 6 caracteres (12) ninguna orn válida 32 16

17 Pruebas Funcionales Casos válidos: 300 Nomina Depósito (1) (5) (9) 400 Viajes Cheque (1) (5) (8) 500 Coches Pago Factura (1) (5) (10) 600 Comida Retirada Fondos (1) (5) (11) Casos No Válidos 180 (2) 1032 (3) XY (4) <CR> (6) Regalos (7) Casa (12) 33 Pruebas Funcionales Análisis Valores Límites (AVL) Exploran las condiciones límites un programa. Técnica Complementaria a las Clases Equivalencia. Diferencias: Más que elegir «cualquier» elemento como representativo una clase equivalencia, se requiere la selección uno o más elementos tal que los márgenes se sometan a prueba

18 Pruebas Funcionales Más que elegir «cualquier» elemento como representativo una clase equivalencia, se requiere la selección uno o más elementos tal que los márgenes se sometan a prueba. Más que concentrarse únicamente en el dominio entrada (condiciones entrada), los casos prueba se generan consirando también el espacio salida Reglas: 1) Si una condición entrada especifica un rango valores, se ben generar casos para los extremos l rango y casos no válidos para situaciones justo más allá los extremos 35 Pruebas Funcionales 2) Si la condición entrada especifica un número valores, hay que escribir casos para los números máximo, mínimo, uno más l máximo y uno menos l mínimo valores 3) Usar la regla 1 para la condición salida 4) Usar la regla 2 para cada condición salida En esta regla 3 y 4, be recordarse que: los valores límite entrada no generan necesariamente los valores límite salida no siempre se puen generar resultados fuera l rango salida (pero es interesante consirarlo)

19 Pruebas Funcionales 5) Si la entrada o la salida un programa es un conjunto ornado (por ejemplo, una tabla, un archivo secuencial,...), los casos ben concentrarse en el primero y en el último elemento 37 Pruebas Funcionales Conjetura Errores Enumerar una lista errores comunes En función ella elaborar los casos prueba Es importante la intuición y la experiencia Ejemplos: El valor cero es una situación propensa a error tanto en la salida como en la entrada Cuando se introduce un número variable valores, centrarse en el caso no introducir ningún valor y en el un solo valor. También pue ser interesante un lista que tiene todos los valores iguales 38 19

20 Pruebas Funcionales Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificación También interesa imaginar lo que el usuario pue introducir como entrada a un programa 39 Pruebas Aleatorias Se simula la entrada datos habitual un programa. Se crean datos que sigan la frecuencia y la secuencia que tendrían en la práctica Se usan generadores : Descripción datos Secuencias entradas posibles Probabilidad ocurrencia 40 20

21 Enfoque práctico para generar los casos prueba Si la especificación contiene combinaciones condiciones entrada, comenzar formando sus grafos causa-efecto (ayudan a la comprensión dichas combinaciones). En todos los casos, usar el análisis valores-límites para añadir casos prueba: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase equivalencia. 41 Enfoque práctico para generar los casos prueba Intificar las clases válidas y no válidas equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente ( cada causa es una única clase equivalencia? Deben dividirse en clases?). Utilizar la técnica conjetura errores para añadir nuevos casos, referidos a valores especiales

22 Enfoque práctico para generar los casos prueba Ejecutar los casos generados hasta el momento ( caja negra) y analizar la cobertura obtenida (usar herramientas análisis cobertura) Examinar la lógica l programa para añadir los casos precisos ( caja blanca) para cumplir el criterio cobertura elegido. 43 Documentación l Diseño Pruebas Documentos relacionados con el diseño según IEEE std Plan Plan Especificación Especificación diseño diseño Especificación Especificación diseño diseño Especificación Especificación caso caso Especificación Especificación procedimiento procedimiento Ejecución Ejecución 44 Informes 22

23 Documentación l Diseño Pruebas Plan Pruebas Señalar: El enfoque Los recursos El esquema actividas prueba Los elementos a probar Las características Las actividas prueba El personal responsable Los riesgos asociados 45 Documentación l Diseño Pruebas Estructura Fijada en el estándar Intificador único l documento (para la gestión configuración). Introducción y resumen elementos y características a probar. Elementos software que se van a probar (p. ej., programas o módulos). Características que se van a probar. Características que no se prueban. Enfoque general la prueba (actividas, técnicas, herramientas, etc.). Criterios paso/fallo para cada elemento. Criterios suspensión y requisitos reanudación. Documentos a entregar (como mínimo, los scritos en el estándar)

24 Documentación l Diseño Pruebas Estructura Fijada en el estándar Actividas preparación y ejecución. Necesidas entorno. Responsabilidas en la organización y realización las. Necesidas personal y formación. Esquema tiempos (con tiempos estimados, hitos, etc.). Riesgos asumidos por el plan y planes contingencias para cada riesgo. Aprobaciones y firmas con nombre y puesto sempeñado. 47 Documentación l Diseño Pruebas Especificación l Diseño Pruebas Objetivo: Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e intificar las características que se ben probar con este diseño. Estructura Fijada por el estándar: Intificador (único) para la especificación. Proporcionar también una referencia l plan asociado (si existe). Características a probar los elementos software (y combinaciones características)

25 Documentación l Diseño Pruebas Estructura Fijada por el estándar: Detalles sobre el plan l que surge este diseño, incluyendo las técnicas prueba específica y los métodos análisis resultados. Intificación cada prueba: Intificador. Casos que se van a utilizar. Procedimientos que se van a seguir. Criterios paso/fallo la prueba (criterios para terminar si una característica o combinación características ha pasado con éxito la prueba o no). 49 Documentación l Diseño Pruebas Especificación un Caso Prueba Objetivo: finir uno los casos prueba intificado por una especificación l diseño las. Estructura Fijada por el estándar Intificador único la especificación. Elementos software (p. ej., módulos) que se van a probar: finir dichos elementos y las características que ejercitará este caso. Especificaciones cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; p. ej., la sincronización las mismas). Especificaciones todas las salidas y las características requeridas (p. ej., el tiempo respuesta) para los elementos que se van a probar

26 Documentación l Diseño Pruebas Estructura Fijada por el estándar Necesidas entorno (hardware, software y otras como, por ejemplo, el personal). Requisitos especiales procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso). Depenncias entre casos (p. ej., listar los intificadores los casos que se van a ejecutar antes este caso prueba). 51 Documentación l Diseño Pruebas 52 Especificación un Procedimiento Prueba Objetivo: especificar los pasos para la ejecución un conjunto casos prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito evaluar un conjunto características l mismo. Estructura Fijada por el estándar Intificador único la especificación y referencia a la correspondiente especificación diseño prueba. Objetivo l procedimiento y lista casos que se ejecutan con él. Requisitos especiales para la ejecución (p. ej., entorno especial o personal especial). 26

27 Documentación l Diseño Pruebas Estructura Fijada por el estándar Pasos en el procedimiento. Amás la manera registrar los resultados y los incintes la ejecución, se be especificar: La secuencia necesaria acciones para preparar la ejecución. Acciones necesarias para empezar la ejecución. Acciones necesarias durante la ejecución. Cómo se realizarán las medidas (p. ej., el tiempo respuesta). Acciones necesarias para suspenr la prueba (cuando los acontecimientos no previstos lo obliguen). Puntos para reinicio la ejecución y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para tener ornadamente la ejecución. Acciones necesarias para restaurar el entorno y jarlo en la situación existente antes las. Acciones necesarias para tratar los acontecimientos anómalos 53 Ejecución las DEPURAR PRUEBAS EJECUTAR PRUEBAS EJECUTAR PRUEBAS DEPURAR CÓDIGO SÍ (DEFECTO DE PRUEBAS) ALGÚN FALLO? ALGÚN FALLO? NO SÍ (DEFECTO DEL SOFTWARE) PRUEBAS ADICIONALES COMPROBAR TERMINACIÓN COMPROBAR TERMINACIÓN NO CONDICIONES ANORMALES CONDICIONES ANORMALES SÍ PRUEBAS ADICIONALES? PRUEBAS ADICIONALES? CRITERIOS DE COMPLECIÓN DEL PLAN DE PRUEBAS SÍ TERMINACIÓN ANORMAL NO EVALUAR RESULTADOS EVALUAR RESULTADOS TERMINACIÓN NORMAL 54 27

28 Documentación la Ejecución las ESPECIFICACIÓN DE LAS PRUEBAS CASOS PROCEDIMIENTOS EJECUCIÓN EJECUCIÓN Histórico Histórico (test (test log) log) Informes Informes incintes incintes... Histórico Histórico (test (test log) log) Informes Informes incintes incintes Informe resumen Informe resumen las las 55 Documentación la Ejecución las Historico Pruebas Documenta todos los hechos relevantes ocurridos durante la ejecución las. Informe Incinte: Documenta cada incinte (p. ej., una interrupción en las bido a un corte electricidad, bloqueo l teclado, etc.) ocurrido en la prueba y que requiera una posterior investigación

29 Documentación la Ejecución las Informe resumen Resume los resultados las actividas prueba (las reseñadas en el propio informe) y aporta una evaluación l software, basada en dichos resultados. 57 Depuración Es proceso localizar, analizar y corregir los fectos que se sospecha que contiene el software. Suele ser la consecuencia una prueba con éxito. Consecuencias Encontrar la causa l error, analizarla y corregirla No encontrar la causa. (casos prueba para puración)

30 Depuración Etapas: Localización l Error (mayor esfuerzo) Corrección l fecto Casos Prueba Correción Causas Causas Sintomas Errores 59 Análisis errores o análisis causal Cuándo se cometió? Quién lo hizo Qué se hizo mal? Cómo se podría haber prevenido? Por qué no se tectó antes? Cómo se podría haber tectado antes? Cómo se encontró el error? 60 30

31 Ciclo Vida Pruebas (V) Contrato. Contrato. Requisitos Requisitos usuario usuario Prueba Prueba aceptación aceptación Planificar Tipos: Alfa Beta Especificación Especificación requisitos l requisitos l software software Prueba Prueba sistema sistema Requisitos no funcionales Documentación Documentación Documentación diseño y arquitectura diseño y arquitectura Prueba Prueba integración integración Interfaces Mezcla con prueba unidad Tipos integración Especificación Especificación módulos o módulos o elementos elementos Prueba Prueba unidad unidad Exhaustiva Enfoque recomendado: Caja negra Cobertura Código Código 61 Pruebas Unidad Pue abarcar s un módulo, a un grupo pocos módulos o un programa completo Las unidad suelen ser realizadas por personal sarrollo Utilizar el enfoque práctico ya visto

32 Pruebas Integración Ligadas a la forma prevista integrar los distintos componentes l software hasta contar con el producto global que be entregarse Tipos Integración Incremental (ascennte y scennte) Se combina el siguiente módulo que se be probar con el conjunto módulos que ya están probados No Incremental Se prueba cada módulo por separado y, luego, se integran todos una vez y se prueba el programa completo 63 Pruebas l Sistema Verifica: Cumplimiento todos los requisitos funcionales, consirando el producto software final al completo, en un entorno sistema. El funcionamiento y rendimiento en las interfaces hardware, software, usuario y operador. Acuación la documentación usuario. Ejecución y rendimiento en condiciones límite y sobrecarga

33 Pruebas Aceptación Objetivo Comprobar si el producto está listo para ser implantado para el uso operativo en el entorno l usuario. Características Participación l Usuario Está enfocada hacia la prueba los requisitos usuario especificados Está consirada como la fase final l proceso para crear una confianza en que el producto es el apropiado para su uso en explotación 65 33

Tema 9. Pruebas del Software

Tema 9. Pruebas del Software Tema 9. Pruebas del Software 1. Definiciones asociadas 2. El proceso de prueba 3. Técnicas de diseño de casos de prueba 4. Pruebas estructurales 5. Pruebas funcionales 6. Pruebas aleatorias 7. Enfoque

Más detalles

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software Estrategias de Pruebas Relator: Sr. Eduardo Leyton G Pruebas del Software (Basado en

Más detalles

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de

Más detalles

1. Descripción y objetivos

1. Descripción y objetivos Pruebas 1 1. Descripción y objetivos Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: El correcto funcionamiento de los componentes del sistema.

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 5. Prueba del software

Fundamentos de Ingeniería del Software. Capítulo 5. Prueba del software Fundamentos de Ingeniería del Software Capítulo 5. Prueba del software Bubbles don t crash Bertrand Meyer Prueba del software. Estructura 1. Objetivos de la prueba 2. Importancia de la prueba 3. Principios

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

Más detalles

Prueba de software. Ingeniería de software Eduardo Ferreira, Martín Solari

Prueba de software. Ingeniería de software Eduardo Ferreira, Martín Solari Prueba de software Ingeniería de software Eduardo Ferreira, Martín Solari 1 Temario Prueba de software Estrategias, niveles y tipos de prueba Pruebas de caja blanca Pruebas de caja negra Proceso de prueba

Más detalles

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7: VALIDACIÓN

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7: VALIDACIÓN Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7: VALIDACIÓN TÉCNICAS DE PRUEBA DEL SOFTWARE Introducción Aspectos psicológicos de las pruebas Flujo de información de la prueba

Más detalles

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

Desarrollar el concepto del producto. Asignar requisitos de hardware y software. 1 1.1 1.2 2 2.1 2.2 3.. N

Desarrollar el concepto del producto. Asignar requisitos de hardware y software. 1 1.1 1.2 2 2.1 2.2 3.. N Fase de Análisis de Requerimientos Desarrollar el concepto del producto. Asignar requisitos de hardware y software. Realizar estudios de mercado. Sugerencia: www.anuies.mx para saber cuantas instituciones

Más detalles

6.3 CASOS DE PRUEBA CAJA BLANCA

6.3 CASOS DE PRUEBA CAJA BLANCA Tipos de Prueba: 6.3 CASOS DE PRUEBA CAJA BLANCA Prueba de la Ruta Básica Pruebas de la estructura de control Prueba de condición Prueba del flujo de datos Prueba de bucles 6.3.1 PRUEBA DE LA RUTA BASICA

Más detalles

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE 6.1 PRUEBAS DEL SOFTWARE Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente.

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Contextualizacion. La Actividad de Requisitos. La actividad de requisitos. Contextualización, gráficamente. Introducción

Contextualizacion. La Actividad de Requisitos. La actividad de requisitos. Contextualización, gráficamente. Introducción Contextualizacion La Actividad Requisitos Introducción Supongamos que este curso fuese un proyecto sarrollo software real. En qué estadio nos encontraríamos? Hemos finido el molo ciclo vida e instanciado

Más detalles

6.4 ESTRATEGIAS DE PRUEBA

6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

Más detalles

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra Hoy, la caja negra Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Niveles y Caja Negra Blanca A. Vargas Govea vargasgovea@itesm.mx Marzo 1, 2013 Contenido Tipos y niveles de

Más detalles

PRU. Pruebas. Ejercicio previo. Enunciado

PRU. Pruebas. Ejercicio previo. Enunciado PRU Pruebas 1 Ejercicio previo Enunciado Se tiene un programa que Lee tres enteros de un fichero Los tres enteros representan los lados de un triángulo Imprime un mensaje indicando el tipo de triángulo

Más detalles

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) Introducción 1. Como se indica en la Norma Internacional de Auditoría 401, "Auditoría en un contexto informatizado", los objetivos globales

Más detalles

METODOLOGÍA DEL PROCESO DE PRUEBAS DEL GOBIERNO DEL PRINCIPADO DE ASTURIAS METESPA

METODOLOGÍA DEL PROCESO DE PRUEBAS DEL GOBIERNO DEL PRINCIPADO DE ASTURIAS METESPA METODOLOGÍA DEL PROCESO DE PRUEBAS DEL GOBIERNO DEL PRINCIPADO DE ASTURIAS METESPA INDICE 1 Ámbito... 3 2 Alcance... 3 3 Políticas y Estrategias... 3 4 Visión General (Estructura la metodología)... 3 4.1

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

Ingeniería de Software Avanzada

Ingeniería de Software Avanzada Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Conceptos básicos de testing Una falla (failure) ocurre cuando un programa

Más detalles

Ingeniería del So8ware II

Ingeniería del So8ware II Ingeniería del So8ware II Tema 01. Construcción y Pruebas de So8ware Carlos Blanco Bueno DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN carlos.blanco@unican.es Este tema se publica bajo Licencia: CreaOve

Más detalles

PROGRAMACIÓN DEL MÓDULO/ASIGNATURA

PROGRAMACIÓN DEL MÓDULO/ASIGNATURA PROGRAMACIÓN DEL MÓDULO/ASIGNATURA DEPARTAMENTO: INFORMÁTICA GRUPO/CURSO: 2º MR / 2.015-2.016 MÓDULO/ASIGNATURA: SORE (SISTEMAS OPERATIVOS EN RED) PROFESOR: MIKEL VILLANUEVA, MARTA OTERO 1.- INTRODUCCION

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

1.1 Las pruebas en el desarrollo de software tradicional

1.1 Las pruebas en el desarrollo de software tradicional software Introducción La prueba del software es un proceso que se realiza por diversos motivos, concientemente o de manera casual, pero que se reduce a unos cuantos pasos: se ejecuta el programa (o parte

Más detalles

TEMA 2: DESARROLLO DEL SOFTWARE

TEMA 2: DESARROLLO DEL SOFTWARE TEMA 2: DESARROLLO DEL SOFTWARE EDI I Curso 2007/08 Escuela Politécnica Superior Universidad Autónoma de Madrid TEMA 2: DESARROLLO DEL SOFTWARE 2.1. Ciclo de vida del Software 2.2. Corrección de errores

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Introducción a las Pruebas de Software

Introducción a las Pruebas de Software Introducción a las Pruebas de Software Contenido Contenido El ciclo de vida de la Calidad. Conceptos Generales de Pruebas. Proceso de Pruebas de So7ware. Obje;vos de las Pruebas de So7ware. Beneficios

Más detalles

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA Programa: Algoritmo (secuencia no ambigua, finita y ordenada de instrucciones para la resolución de un determinado problema) traducido

Más detalles

Técnicas Avanzadas de Testing Automático

Técnicas Avanzadas de Testing Automático Técnicas Avanzadas de Testing Automático Marcelo Frias ITBA - Buenos Aires, Argentina CONICET Preliminares: Calidad Validación y Verificación Especificaciones y V&V Análisis estático y dinámico Inspecciones

Más detalles

CLASE # 5 TÉCNICAS DE CAJA BLANCA

CLASE # 5 TÉCNICAS DE CAJA BLANCA CLASE # 5 TÉCNICAS DE CAJA BLANCA 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA Basado Parcialmente

Más detalles

Apuntes de ACCESS. Apuntes de Access. Campos de Búsqueda:

Apuntes de ACCESS. Apuntes de Access. Campos de Búsqueda: Apuntes de ACCESS Campos de Búsqueda: Los campos de búsqueda permiten seleccionar el valor de un campo de una lista desplegable en lugar de tener que escribirlos. El usuario sólo tiene que elegir un valor

Más detalles

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Introducción al Proceso de Pruebas.

Introducción al Proceso de Pruebas. Introducción al Proceso de Pruebas. Javier Gutiérrez / javierj@us.es Introducción al proceso de pruebas Objetivo: repasar las ideas principales sobre las pruebas del software y, en concreto, las que usaremos

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Diseño orientado al flujo de datos

Diseño orientado al flujo de datos Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos

Más detalles

TESTING. Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves

TESTING. Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves TESTING Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves Definiciones Error: Equivocación cometida por un desarrollador. Ejemplos: un error de tipeo, una mal interpretación de un requerimiento

Más detalles

Enfoque del Marco Lógico (EML)

Enfoque del Marco Lógico (EML) Enfoque del Marco Lógico (EML) Qué es el EML? Es una herramienta analítica que se utiliza para la mejorar la planificación y la gestión de proyectos tanto de cooperación al desarrollo como de proyectos

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

ERP/ CRM GSET Balneario SPA

ERP/ CRM GSET Balneario SPA ERP/CRMGSET Balneario SPA Les Nuevas tecnologías y el sector Balneario- SPA Actualmente, los balnearios y SPA están en auge y son frecuentados por personas que buscan bienestar. El balneario, es un uso

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Seguridad Ferroviaria y Gestión RAMS en el Mantenimiento

Seguridad Ferroviaria y Gestión RAMS en el Mantenimiento Seguridad Ferroviaria y Gestión RAMS en el Mantenimiento Introducción Durante las últimas décadas y con el objetivo fundamental de garantizar su sostenibilidad, el sector ferroviario en Europa ha experimentado

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

www.fundibeq.org Además, se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión.

www.fundibeq.org Además, se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión. DIAGRAMA DE RELACIONES 1.- INTRODUCCIÓN Este documento describe los pasos del proceso de construcción e interpretación de una de las herramientas más potentes para el análisis de problemas y situaciones

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Contenido. Profesor: Ing. MSc. Eliomar Nieves

Contenido. Profesor: Ing. MSc. Eliomar Nieves Contenido Qué son las pruebas de software?... 2 Principios de la fase de prueba y validación de software... 2 Defectos vs fallas en las pruebas de software... 2 Tipos de defectos de software... 2 Clases

Más detalles

ESTE EJERCICIO ES DE TIPO MIXTO.

ESTE EJERCICIO ES DE TIPO MIXTO. junio, 1ª semana, nacional 2012 ESTE EJERCICIO ES DE TIPO MIXTO. ES IRRELEVANTE SI CONTESTA A LA PREGUNTA DE TEST O NO. SIN EMBARGO, SE DEBE ESCANEAR DICHA HOJA JUNTO CON EL RESTO DE LA CONTESTACIÓN DEL

Más detalles

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION

INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION INTRODUCCION AL DESARROLLO DE SISTEMAS DE INFORMACION. Los sistemas que el analista diseña día a día, la tecnología, las personas, que utilizan el

Más detalles

Verificación. 3.1 Marco de Referencia para el desarrollo de software

Verificación. 3.1 Marco de Referencia para el desarrollo de software Verificación 3.1 Marco de Referencia para el desarrollo de software Verificación es la acción de verificar (comprobar o examinar la verdad de algo). La verificación suele ser el proceso que se realiza

Más detalles

Ejemplos de conversión de reales a enteros

Ejemplos de conversión de reales a enteros Ejemplos de conversión de reales a enteros Con el siguiente programa se pueden apreciar las diferencias entre las cuatro funciones para convertir de reales a enteros: program convertir_real_a_entero print

Más detalles

Manual del Usuario CLIENTES y PROVEEDORES

Manual del Usuario CLIENTES y PROVEEDORES Manual del Usuario CLIENTES y PROVEEDORES Pantalla de Ingreso de Clientes (RESUMIDA) Ya entendido el manejo de la botonera de controles, que sirve para que el Usuario pueda controlar los modos de: Alta,

Más detalles

ANÁLISIS MODAL DE FALLOS EFECTOS (A. M. F. E.)

ANÁLISIS MODAL DE FALLOS EFECTOS (A. M. F. E.) ANÁLISIS MODAL DE FALLOS EFECTOS (A. M. F. E.) Y 1. INTRODUCCIÓN Este documento describe paso a paso el proceso de identificación, evaluación y prevención de deficiencias en los productos o servicios.

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Construcción y Pruebas de Software

Construcción y Pruebas de Software UNIVERSIDAD DE CARABOBO Facultad Experimental de Ciencias y Tecnología Departamento de Computación Construcción y Pruebas de Software Elaborado por: Gustavo Bazán Francisco Rosas Bárbula, Junio de 2012

Más detalles

Pruebas de Programas. Introducción Errores de software. Julio Villena Román. Un error en un programa puede ser algo muy serio

Pruebas de Programas. Introducción Errores de software. Julio Villena Román. Un error en un programa puede ser algo muy serio Laboratorio de Programación Pruebas de Programas Julio Villena Román jvillena@it.uc3m.es Introducción Errores de software Un error en un programa puede ser algo muy serio http://www.wired.com/software/coolapps/news/2005/11/69355?currentpage=all

Más detalles

Gestión de proyectos con MS Project

Gestión de proyectos con MS Project 1 Gestión de proyectos con MS Project Gestión de Proyectos: consiste en el Estudio y Planificación de un Proyecto en función de su alcance, así como en el Control y Seguimiento del Proyecto durante su

Más detalles

31.5.2008 Diario Oficial de la Unión Europea L 141/5

31.5.2008 Diario Oficial de la Unión Europea L 141/5 31.5.2008 Diario Oficial de la Unión Europea L 141/5 REGLAMENTO (CE) N o 482/2008 DE LA COMISIÓN de 30 de mayo de 2008 por el que se establece un sistema de garantía de la seguridad del software que deberán

Más detalles

RECOMENDACIONES. HALLAZGOS Objetivos especifico Justificación/Norma ANEXO

RECOMENDACIONES. HALLAZGOS Objetivos especifico Justificación/Norma ANEXO HALLAZGOS HALLAZGOS Objetivos especifico Justificación/Norma 1 No se estiman los presupuestos y calendario l proyecto En el objetivo específico 7 Verificar si se asigna los recursos necesarios para el

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

ASAMBLEA 37º PERÍODO DE SESIONES

ASAMBLEA 37º PERÍODO DE SESIONES Organización de Aviación Civil Internacional NOTA DE ESTUDIO A37-WP/50 AD/7 16/8/10 ASAMBLEA 37º PERÍODO DE SESIONES COMISIÓN ADMINISTRATIVA Cuestión 74: Informe sobre el uso del Fondo para tecnología

Más detalles

Aseguramiento de la Calidad

Aseguramiento de la Calidad ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-CAL 1: IDENTIFICACIÓN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA... 3 Tarea EVS-CAL 1.1: Constitución del Equipo

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

Parte 1 Múltiple Opción

Parte 1 Múltiple Opción Cada pregunta de la parte múltiple opción contestada correctamente tiene un valor de 1,5 puntos. Cada pregunta incorrecta de la múltiple opción resta 0,5 puntos. Esta parte consta de 25 preguntas por lo

Más detalles

www.fundibeq.org En estos casos, la herramienta Gráficos de Control por Variables" no es aplicable.

www.fundibeq.org En estos casos, la herramienta Gráficos de Control por Variables no es aplicable. GRAFICOS DE CONTROL POR ATRIBUTOS 1.- INTRODUCCIÓN Este documento describe la secuencia de construcción y las pautas de utilización de una de las herramientas para el control de procesos, los Gráficos

Más detalles

Ciclo de vida del software

Ciclo de vida del software Ciclo de vida del software Definición El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable,

Más detalles

GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL

GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL GESTIÓN DE CAPACIDAD DE SERVICIOS TI: UNA SOLUCIÓN DESDE ITIL Consultor Senior de Calidad SW Métodos y Tecnología Responsable de Área Ingeniería y Calidad SW Métodos y Tecnología 1 Palabras clave ITIL,

Más detalles

Figura (1) diagrama del PHVA aplicado a la Metodología a de las 5 S

Figura (1) diagrama del PHVA aplicado a la Metodología a de las 5 S 6.6 Seguimiento El proceso de seguimiento dentro de la implementación de la metodología de las 5 S, requiere, antes que nada, tener una comprensión clara y un concepto uniforme, de qué significa cada uno

Más detalles

DIPA 1009 - TÉCNICAS DE AUDITORÍA CON AYUDA DE COMPUTADORA

DIPA 1009 - TÉCNICAS DE AUDITORÍA CON AYUDA DE COMPUTADORA DIPA 1009 - TÉCNICAS DE AUDITORÍA CON AYUDA DE COMPUTADORA Introducción Los objetivos y alcance global de una auditoría no cambian cuando se conduce una auditoría en un ambiente de sistemas de información

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

www.fundibeq.org Además, se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión.

www.fundibeq.org Además, se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión. DIAGRAMA DE FLECHAS 1.- INTRODUCCIÓN Este documento sirve de guía para el proceso de planificación de proyectos. Describe desde la visualización de la secuencia de acciones a desarrollar en dichos proyectos

Más detalles

2 Métodos combinatorios

2 Métodos combinatorios 2 Métodos combinatorios Las pruebas pueden aplicarse de muchas maneras, es decir, existen diferentes formas de preparar casos de prueba. En este capítulo se presentan dos formas de prueba muy fáciles de

Más detalles

AGENDA 1. ANTECEDENTES 2. INTRODUCCIÓN A LOS CONTROLES DE APLICACIÓN 3. OBJETIVOS DE CONTROL DE APLICACIÓN IDENTIFICADOS EN COBIT

AGENDA 1. ANTECEDENTES 2. INTRODUCCIÓN A LOS CONTROLES DE APLICACIÓN 3. OBJETIVOS DE CONTROL DE APLICACIÓN IDENTIFICADOS EN COBIT EDMUNDO TREVIÑO GELOVER CGEIT, CISM, CISA AGENDA 1. ANTECEDENTES 2. INTRODUCCIÓN A LOS CONTROLES DE APLICACIÓN 3. OBJETIVOS DE CONTROL DE APLICACIÓN IDENTIFICADOS EN COBIT 4. TIPOS DE CONTROLES DE APLICACIÓN

Más detalles

UNIDADES DE ALMACENAMIENTO DE DATOS

UNIDADES DE ALMACENAMIENTO DE DATOS 1.2 MATÉMATICAS DE REDES 1.2.1 REPRESENTACIÓN BINARIA DE DATOS Los computadores manipulan y almacenan los datos usando interruptores electrónicos que están ENCENDIDOS o APAGADOS. Los computadores sólo

Más detalles

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS 4.1 Antecedentes históricos El lenguaje de programación BASIC (Beginner's All purpose Symbolic Instruction Code)

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación Sistemática de Layout, SLP por sus siglas en inglés. Se hará uso de la simulación para comparar el

Más detalles

Sesión tutorial introductoria sobre requisitos y trabajo en equipo. Sesión Técnica de Calidad de Software

Sesión tutorial introductoria sobre requisitos y trabajo en equipo. Sesión Técnica de Calidad de Software Sesión tutorial introductoria sobre requisitos y trabajo en equipo Sesión Técnica de Calidad de Software 12 de noviembre de 2008 Luis Fernández Sanz Universidad de Alcalá www.ati.es/gtcalidadsoft Definiciones

Más detalles

Parte 7: Análisis de los datos

Parte 7: Análisis de los datos Metodología de la investigación Curso 2008 Parte 7: Análisis de los datos Los ejemplos han sido tomados en su mayoría de la bibliografía recomendada para el curso Análisis de los datos El análisis de datos

Más detalles

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

INSTRUCTIVO PARA LA EVALUACIÓN DE ORGANISMOS DE CERTIFICACIÓN DE SISTEMAS DE GESTIÓN.

INSTRUCTIVO PARA LA EVALUACIÓN DE ORGANISMOS DE CERTIFICACIÓN DE SISTEMAS DE GESTIÓN. Página 1 12 INSTRUCTIVO PARA LA EVALUACIÓN DE ORGANISMOS PROCESO NIVEL 1: PROCESO NIVEL 2: 4. PROCESO EJECUCIÓN SERVICIOS DE ACREDITACIÓN 4.2 EJECUCIÓN EVALUACIÓN ELABORÓ: REVISÓ: APROBÓ: 2014-09-15 2014-09-15

Más detalles

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

Beatriz Pérez. Jornada de Testing en Vivo - 1, 2, 3 probando!

Beatriz Pérez. Jornada de Testing en Vivo - 1, 2, 3 probando! Beatriz Pérez Proceso de Testing Funcional Principales características Etapas Actividades y Entregables Roles Principales características Independiente del proceso de desarrollo Testing funcional de productos

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Técnicas Avanzadas de Testing Automatizado

Técnicas Avanzadas de Testing Automatizado Técnicas Avanzadas de Testing Automatizado Criterios de cobertura: Caja blanca/caja negra Clases de Equivalencia Valores de borde Cobertura basada en flujo de control CodeCover Mutación Jumble Criterios

Más detalles

Capitulo 3. Desarrollo del Software

Capitulo 3. Desarrollo del Software Capitulo 3 Desarrollo del Software 3.1 Análisis del sistema 3.1.1 Organización de la autopista virtual Para el presente proyecto se requiere de simular una autopista para que sirva de prueba. Dicha autopista

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

5.- ANÁLISIS DE RIESGO

5.- ANÁLISIS DE RIESGO 5.- ANÁLISIS DE RIESGO El módulo de Análisis de Riesgo se caracteriza por desarrollar una herramienta formativa para la gestión, que permite al usuario identificar, analizar y cuantificar el riesgo de

Más detalles

PREGUNTAS FRECUENTES DE ACL SCRIPTHUB

PREGUNTAS FRECUENTES DE ACL SCRIPTHUB PREGUNTAS FRECUENTES DE ACL SCRIPTHUB Qué es ScriptHub? ACL estará ofreciendo más de cien scripts de "mejores prácticas" en ScriptHub través de una amplia gama de asuntos y materias. Siempre se puede iniciar

Más detalles

CRM Customer Relationship Management

CRM Customer Relationship Management CRM Customer Relationship Management es la solución que ofrece IDSénia para gestionar su los clientes, como estrategia de negocio. Definición. Traducido como Gestión de la los clientes, es parte de una

Más detalles