Calidad Enfocada en el Desarrollo de Software

Presentación del tema: "Calidad Enfocada en el Desarrollo de Software"— Transcripción de la presentación:

1 Calidad Enfocada en el Desarrollo de Software
M.C. Juan Carlos Olivares Rojas Noviembre 2009

2 Competencias Conoce la importancia de la aplicación de la calidad en cada una de las fases en el desarrollo de un software. Genéricas Instrumentales: Capacidad de análisis y síntesis, Capacidad de organizar y planificar, Comunicación oral y escrita en su propia lengua, Conocimiento de una segunda lengua, Habilidades de gestión de información, Toma de decisiones.

3 Competencias Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético. Sistémicas: Capacidad de aplicar los conocimientos en la práctica, Habilidades de investigación, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.

4 Evidencias Actividades 10%
Aplicación de Estándares de Calidad en el Proyecto 30% (dos metodologías por equipo de trabajo presentando resultados al final de la unidad en fecha aun por especificar) Actividad Evaluadora Parcial 60%

5 Temario Qué es la calidad del software.
Cómo obtener calidad de software (métodos, metodologías, estándares). Cómo controlar la calidad del software. Costo de la calidad del software. Nomenclatura y certificación ISO 9001:2000.

6 Temario La norma ISO/IEC 9126.
Análisis de factores que determinan la calidad del software.

7 Temario Calidad desde el inicio (comunicación y planeación)
Calidad en el modelado (análisis y diseño) Calidad en la construcción (codificación y pruebas) Calidad en el despliegue (instalación, mantenimiento).

8 Calidad en la Comunicación
Problemas de comunicación Ley de Brooks Video de los castores

9 Trabajo en Equipos El problema de comunicación se da a través de la colaboración de varias personas en un proyecto. El capital intelectual como se ha comentado es sumamente difícil de controlar y estandarizar. La mejor forma de trabajar en equipo es a través de una buena cultura organizacional (principios y valores).

10 Técnicas de Discusión Para la toma de decisiones grupales, existen varios métodos que se pueden seguir como: votación (la decisión más votada gana), votación aprobatoria (cada miembro puede votar por más de una opción, la opción más votada es la que gana), suma de rangos (se otorgan ponderaciones a las opciones, siendo 1 para la menos votada, este proceso se realiza por participante, gana la opción con mayor puntaje) y desviación mínima (se selecciona la opción que tenga mayor puntaje y cuya desviación sea mínimo).

11 Técnicas de Discusión Estas técnicas se pueden mejorar a través de otras técnicas que ayudan a la toma de decisiones que a continuación se mencionan: lluvia de ideas, rueda de mesa (similar a la lluvia de ideas pero cada quien tiene un turno para exponer sus ideas de forma cíclica), análisis FODA (Fortalezas Oportunidades Debilidades Amenazas).

12 Técnicas de Discusión Para problemas más complejos se puede utilizar la técnica Philips 66. La cual consiste en hacer grupos de 6 personas que discutirán el problema por 6 minutos. Otra técnica compleja es el Proceso Delphi, la cual se utiliza cuando se desea aislar los miembros del grupo para aislar sus opiniones; o bien, cuando se necesita la opinión de expertos los cuales se encuentran alejados geográficamente.

13 Calidad en la Planeación
De las tres etapas de la planeación, el itinerario (calendarización de actividades) es la que generalmente se realiza. El seguimiento se da en prácticamente cualquier estándar de calidad (quizás en proyectos pequeños no se de con tanta frecuencia) La estimación es la etapa más complicada en cuestión del desarrollo de software y la estimación de costos no es la excepción.

14 Costos de la Calidad del Sw
El costo de la calidad tiene dos componentes: lo que se invierte en obtener buena calidad y lo que se paga por no lograrla. La primera componente es decidida por los desarroladores y puede ser controlada; la segunda no se puede decidir sino que se manifiesta en las fallas de nuestro producto.

15 Costos de la Calidad del Sw

16 Costos de la calidad del Sw
Entre los costos de prevención se incluyen: planificación de la calidad, revisiones técnicas formales, equipo de pruebas, formación. Entre los costos de evaluación se encuentran: inspección en el proceso y entre procesos, calibrado y mantenimiento del equipo, pruebas.

17 Costos de la calidad del Sw
Entre los costos de fallos se encuentran: retrabajo (revisión), reparación, análisis de las modalidades de fallos. resolución de quejas, devolución y sustitución de productos, soporte de línea de ayuda, trabajo de garantía.

18 Costos de la Calidad del Sw

19 Costo de la Calidad del Sw
Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para actividades categorizadas como prevención, Evaluación, Fallas internas, Fallas externas y Creación, respectivamente, tenemos que: Esfuerzo de Calidad = EoQ = (P+E+ Fi+Fe) Costo de Calidad = CoQ = (P+E+Fi+Fe) / (P+E+Fi+Fe+C) Esfuerzo de Mala Calidad = EoPQ = Fi+Fe Costo de Mala Calidad = CoPQ = (Fi+Fe) / (P+E+Fi+Fe+C)

20 Costo de la Calidad del Sw
Ejemplo: En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en administración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el proyecto, 420 en creación, 50 en inspecciones, 160 en pruebas, 30 en correcciones debido a inspecciones, y 150 en debugging antes de la entrega, y 90 en correcciones finales después de la entrega.

21 Costo de la Calidad del Sw
Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las horas de administración. Entonces tenemos: P=60+40, E=50+160, Fi=30+150, Fe=90, C=420, EoQ=580, CoQ=58%, EoPQ=270, CoPQ=27% y Overhead=280/1280=21,9%.

22 Costos de la Calidad del Software
Ejemplo Un ingeniero experimentado introduce 100 defectos por KLOC y el 50% de estos llegan a la fase de pruebas Un producto de 50,000 LOC entraría a la fase de pruebas con 2,500 defectos por ser encontrados Se requiere en promedio de 5 a 10 horas-programador para encontrar cada defecto, es decir, un total de 20,000 horas-programador Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en 25 meses El compilador detectaría el otro 50% de los defectos

23 Costos de la Calidad del Software
Ejemplo Asumir un rendimiento promedio del 70% en el proceso de aseguramiento de calidad. Un producto de 50,000 LOC entraría a la fase de pruebas con 750 defectos por ser encontrados Se requeriría un total de 6,000 horas-programador para encontrar todos los defectos Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en un periodo de entre 7 y 8 meses El ahorro sería de 1 año y medio de pruebas!!! © 2001 by Carnegie Mellon University

24 Calidad en QuarkSoft Tamaño Productividad Error Calidad
C ,344 LOC LOC/Hr % D/KLOC FourJs ,578 LOC LOC/Hr % D/KLOC Progress ,793 LOC LOC/Hr % D/KLOC Java ,086 LOC LOC/hr % D/KLOC Asumiendo un producto de 80 KLOC En promedio, los defectos encontrados en pruebas se llevan de 8 a 20 horas corregirlos cada uno

25 Calidad en el Desarrollo de Sw
En el 2006 el departamento de defensa de los estados unidos realizó el proyecto bug hunting en donde revisaron los errores del top 50 de proyectos de código abierto. Se encontraron los siguientes estadísticos

26 Calidad en el desarrollo de Sw
Proyecto Defectos Detectados Defectos Pendientes de Verificar Defectos pendientes de Inspección Líneas de código (KLOC) Defectos/KLOC Apache-httpd 2 4 25 0.217 Firebird 197 0.727 Firefox 352 65 168 0.126 FreeBSD 6 605 0.386 Gnome 349 12 48 0.085 KDE 1253 10 40 0.011 Mono 69 1 70 0.212 NetBSD 1267 196 1350 0.328 PHP 75 0.002 PostgreSQL 53 23 0.027

27 Calidad en el modelado ¿Cuántos diagramas debo crear? No existe una respuesta específica. ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticaoe

28 Calidad en el modelado ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados. ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

29 Calidad en el modelado Algunas recomendaciones para el modelado de software son: No tenga a los programadores esperando los modelos. Trabajar de una macrovista a una microvista(enfoque Top-Down). Se debe documentar en forma económica.

30 Calidad en el modelo Si es obvio no se debe de modelar.
Hacer hincapié en la especialización. Utilizar patrones de diseño. Reestructuración de códigos

31 Procesos de Negocio Proceso de negocios
Un proceso de negocios es un conjunto de pasos o actividades relacionadas en las que intervienen gente, información y otros recursos para crear valor. Los procesos de negocios se integran de pasos que se pueden identificar en el tiempo y el espacio Tiene un principio y un fin Proceso de negocios

32 Procesos de Negocio Procesos de Negocios Tienen entradas y salidas
Tiene un grado de formalización pero no necesitan ser totalmente estructurados Procesos de Negocios

33 Procesos de Negocio Procesos de negocios
Los procesos de negocios son la manera más común de mejorar el desempeño de los sistemas de trabajos ya que podemos cambiar el proceso de negocio cambiando, eliminando o agregando pasos al proceso o también cambiando los métodos de cómo se usan estos pasos Procesos de negocios

34 Proceso de Negocio Proceso de Negocios

35 Proceso de Negocio

36 Modelado Procesos Negocios

37 Modelado de procesos El modelado de procesos es en si mismo el proceso de negocio. Es la subdivisión del proceso de negocios en sus elementos básicos con el propósito de poderlos estudiar y mejorarlos

38 Modelado de Procesos de Negocios
El modelado de procesos es esencial en el desarrollo de los sistemas de información ya que nos ayuda a identificar el problema que el sistema de información deberá resolver y la manera en como deberá resolverlo

39 Función vs. Proceso Función: identificada por un verbo. Es continua.
Comercializar Fabricar Vender Expedir Comprar Proceso: identificado por verbo+sustantivo. Tiene un inicio y un fin. No es continuo. Tomar un pedido Ensamblar un pieza Facturar a un cliente Solicitar materiales

40 Procesos de Negocios Las aplicaciones empresariales están diseñadas para apoyar la coordinación e integración de procesos que abarcan toda la empresa. Ejemplos de estas Aplicaciones empresariales se muestran a continuación: Sistemas de administración de la cadena de suministro (SCM).

41 Procesos de Negocio Sistemas de administración de relaciones con clientes (CRM). Sistemas de administración del conocimiento (Business Intelligence). Sistemas Integrales que abarcan los procesos de la organización, llamados ERP (Enterprise Resource Plannig).

42 Procesos de Negocio Procesos de Negocio
Los Sistemas de Administración del Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento. Procesos de Negocio

43 BPMN Procesos de Negocio
Los Sistemas de Administración del Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento. Procesos de Negocio

44 BPMN Desarrollado por Business Process Management Initiative (BPMI).
Es un estándar: BPMN Business Process Modeling Notation. La especificación BPMN 1.0 fue publicada en Mayo del 2004.

45 Introducción El objetivo principal de desarrollar BPMN es proveer una notación que sea fácilmente entendible por todos los usuarios de negocio. Desde los analistas que crean los borradores iniciales de procesos hasta los desarrolladores técnicos que son responsables de implementar la tecnología que ejecutará dichos procesos. Y por supuesto, la gente de negocio que manejará y monitoreará estos procesos.

46 Introducción BPMN define un Diagrama de Procesos de Negocio (BPD), basado en la técnica de “flowcharting” (diagramado de flujos) que ajusta modelos gráficos de operación de procesos de negocio. Un modelo de procesos de negocio es una red de objetos gráficos, correspondientes a actividades y controles de flujo que definen el orden de ejecución de éstas.

47 • Flow Objects (objetos de flujo)
Elementos Un BPD (diagrama de procesos de negocio) se estructura con un grupo de elementos gráficos. Las cuatro categorías básicas de elementos son: • Flow Objects (objetos de flujo) • Connecting Objects (objetos de conexión) • Swimlanes (Carriles) • Artifacts (artefáctos)

48 Elementos: Flow Objects
Un BPD tiene un pequeño grupo de elementos centrales (tres), los cuales son los Flow Objects: Event (Evento) Activity (Actividad) - Gateway (Decisión)

49 Flow Objects: Event Un evento se representa por un circulo y es algo que “sucede” durante el curso de un proceso de negocio. Los eventos afectan el flujo del proceso y usualmente tienen un causa (trigger - disparador) o un impacto (result – resultado). Los eventos se representan con círculos con el centro abierto para permitir anotar diferentes disparadores o resultados.

50 Flow Objects: Event Hay tres tipos de eventos basado en cuándo ellos afectan el flujo: - Start (comienzo) - Intermediate (intermedio) - End (final)

51 Flow Objects: Activity
Una actividad (Activity) se representa por un rectángulo con sus bordes redondeados y es un término genérico para el trabajo que un organización realiza. Un actividad puede ser atómica o no atómica (compuesta).

52 Flow Objects: Activity
Los tipos de actividades son: - Task (tareas) - Sub-process (subproceso) Los subprocesos se distinguen por un pequeño + al centro y abajo en la figura. +

53 Flow Objects: Gateway Un Gateway es representado por la figura de un diamante y se usa para controlar la divergencia de la secuencia de un flujo. Determina las “tradicionales” decisiones, tanto de bifurcaciones, como uniones y acoplamientos de flujos. Las anotaciones al interior indican el tipo de comportamiento de control.

54 Elementos: Connecting Objects
Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. Existen tres Connecting Objects que proveen esta función de conexión. Sequence Flow Message Flow Association

55 Connecting Objects: Sequence Flow
Un Sequence Flow se representa por una línea sólida con el extremo sólido Es usada para mostrar el orden (secuencia) de la actividad dentro del proceso. Note que el término “control flow” generalmente no es usado en BPMN.

56 Connecting Objects: Message Flow
Un Message Flow se representa por una línea segmentada con el extremo sin relleno. Es usada para mostrar el flujo de mensajes entre dos participantes de procesos separados (business entities o business roles). En BPMN, dos “Pools” en el diagrama representan a dos participantes.

57 Connecting Objects: Association
Una Association se representa por una línea segmentada finamente con el extremo en punta. Se usa para asociar datos, textos u otros artefactos con flujos de objetos. Las asociaciones son usadas para mostrar las entradas y salidas de las actividades.

58 Ejemplo con formas básicas
Ejemplo de Proceso de Negocio Simple

59 Ejemplo con formas básicas y marcas internas en las formas
Segmento de un Proceso con más detalles

60 Elementos: Swimlanes Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de organización de actividades en categorías visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. BPMN soporta swimlanes con dos constructores principales: Pool Lane

61 Swimlanes : Pool Un Pool representa un Participante en un Proceso.
El Pool también actúa como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Los Pools se usan generalmente en el contexto de situaciones B2B. Nombre

62 Swimlanes : Lane Un Lane es una partición dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente. Los Lanes son usados para organizar y categorizar actividades. Nombre Nombre Nombre

63 Swimlanes : Pool & Lane Los Pools se usan cuando los diagramas involucran a dos entidades de negocios o participantes separados. Están físicamente separados en el diagrama. Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool.

64 Swimlanes : Pool & Lane Los flujos de mensajes son los mecanismos que muestran la comunicación entre dos participantes, conectando de esta manera a dos Pools (u objetos dentro de los Pools).

65 Swimlanes : Pool & Lane Ejemplo de BPD con Pools

66 Swimlanes : Pool & Lane Los Lanes son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio. Los Lanes son usados para separar actividades asociadas con una función específica de la organización. La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool.

67 Swimlanes : Pool & Lane Segmento de un Proceso con Lanes

68 Elementos : Artifacts BPMN fue diseñado para permitir a los modeladores y herramientas de modelado algunas flexibilidades para extender la notación básica y proveer la habilidad poder modelar diferentes contextos apropiadamente. No está limitado el número de Artefactos que se pueden agregar a un diagrama para que éste represente más apropiadamente al contexto del negocio. La versión actual de BPMN predefine sólo tres tipos de artefactos.

69 Elementos : Artifacts Data object Group Annotation Nombre [Estado]
Anotaciones de Texto permiten al Modelador agregar información adicional

70 Artifact : Data Object Los Data Objects son un mecanismo para mostrar como las actividades requieren o producen objetos. Se conectan a las actividades a través de asociaciones. Nombre [Estado]

71 Artifact : Group Un Group es representado por un rectángulo redondeado dibujado con línea segmentada El agrupamiento puede ser usado para propósitos de documentación o análisis, y no afecta la secuencia del flujo.

72 Artifact : Annotation Las Annotations son mecanismos para que un modelador pueda agregar información textual adicional para el lector del diagrama BPMN. Anotaciones de Texto permiten al Modelador agregar información adicional

73 Artifact Los modeladores puede crear sus propios tipos de artefactos que agreguen más detalle al proceso. Con bastante frecuencia se muestran entradas y salidas de actividades en los procesos. Sin embargo, la estructura básica del procesos, es especificada con actividades, gateways, y flujos de secuencia.

74 Artifact Segmento de un Proceso con Lanes. Sin artefactos.
Segmento de un Proceso con Lanes. Con artefactos.

75 Elementos centrales de los diagramas

76 Lista completa de elementos

77 Ejemplo

78 Elementos del Proceso

79 Usos Generales de BPMN Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos básicos que pueden ser creados con un BPD: • Collaborative (Public) B2B Processes • Internal (Private) Business Processes

80 Collaborative (Public) B2B Processes
Ejemplo proceso colaborativo

81 Ejemplo Proceso de Alto Nivel
Ejemplo de proceso de alto nivel el cual es básicamente una serie de subprocesos con tres puntos de decisión.

82 Ejemplo Proceso de Alto Nivel

83 Ejemplo Proceso de Alto Nivel

84 Ej. Proceso Interno: Más bajo Nivel

85 Modelado de Negocios con el UML
Modelo de Casos de Uso de Negocios Actores del Negocio Casos de Uso del Negocio Diagramas de Casos de Uso del Negocio Diagramas de Actividades Modelo de Objetos del Negocio Trabajadores del Negocio Entidades del Negocio Diagramas de Actividades (Detallado) Diagramas de Colaboración Diagramas de Secuencia

86 Modelo de casos de uso del negocio
Actor del Negocio Alguien o algo externo a la empresa que interactúa con ella. Ejemplos: Clientes, Proveedores, etc. Alguien o algo externo a la empresa que interactua con ella. Para comprender el contexto de un negocio, se debe conocer quien interactua con el negocio; por ejemplo, quien solicita un servicio o quien provee un insumo. Algunos ejemplos de actores del negocio son: Clientes, Proveedores y Socios. La Figura 1 muestra la notación UML de actor de negocio

87 Modelo de casos de uso del negocio
Caso de uso del Negocio Secuencia de acciones (actividades) que una organización realiza para obtener un resultado observable y de valor para un actor de negocio particular. Un caso de uso del negocio es lo mismo que un proceso de negocio Una secuencia de acciones que la organización realiza para obtener un resultado observable de valor para un actor negocio particular. Representan la funcionalidad provista por una organización como un todo. No hay diferencia entre procesos automatizados y manuales. Sinonimo de Proceso de Negocio.

88 Modelo de casos de uso del negocio
Diagrama de Casos de Uso del Negocio Es la representación de un grupo de casos de uso del negocio relacionados dentro de la empresa. Nos dicen que procesos de la organización proporcionan valor agregado y los individuos que interactúan con la misma. Describen completamente la organización en términos de casos de uso del negocio. Una secuencia de acciones que la organización realiza para obtener un resultado observable de valor para un actor negocio particular. Representan la funcionalidad provista por una organización como un todo. No hay diferencia entre procesos automatizados y manuales. Sinonimo de Proceso de Negocio.

89 Modelo de casos de uso del negocio
Diagrama de Actividades Es la representación de una secuencia de actividades dentro de un caso de uso del negocio. Provee una manera gráfica de documentar un caso de uso del negocio. Una secuencia de acciones que la organización realiza para obtener un resultado observable de valor para un actor negocio particular. Representan la funcionalidad provista por una organización como un todo. No hay diferencia entre procesos automatizados y manuales. Sinonimo de Proceso de Negocio.

90 Caso Empresa de Fabricación

91

92 D. A. Registrar Pedido

93 Modelo de objetos del negocio
Trabajador del Negocio Un Trabajador del Negocio (Obrero, Empleado o funcionario) realiza actividades dentro de un caso de uso del negocio, interactua con otros trabajadores del negocio y manipula entidades del negocio .

94 Modelo de objetos del negocio
Entidades del Negocio Una "cosa" manipulada o usada por los trabajadores del negocio. Son ejemplos de entidades del negocio: factura, pedido, plan de producción, etc Alguien o algo externo a la empresa que interactua con ella. Para comprender el contexto de un negocio, se debe conocer quien interactua con el negocio; por ejemplo, quien solicita un servicio o quien provee un insumo. Algunos ejemplos de actores del negocio son: Clientes, Proveedores y Socios. La Figura 1 muestra la notación UML de actor de negocio

95 Diagrama de Actividades Detallado
Cliente Comercial JefeTécnico JefeProducción Diagrama de Actividades Detallado

96 Diagrama de Clases Permite documentar la estructura interna del negocio. Cada clase en este diagrama representa un trabajador del negocio o una entidad del negocio. En este diagrama se visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio.

97 Diagrama de Secuencia Permite documentar la estructura interna del negocio. Cada clase en este diagrama representa un trabajador del negocio o una entidad del negocio. En este diagrama se visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio.

98 Diagrama de Colaboración
Permite documentar la estructura interna del negocio. Cada clase en este diagrama representa un trabajador del negocio o una entidad del negocio. En este diagrama se visualiza las relaciones entre los trabajadores del negocio y las entidades del negocio.

99 Procesos de Negocio

100 Pruebas y depuración La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

101 Depuración Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

102 Pruebas y depuración La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

103 Depuración Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

104 Depuración Es la detección, corrección y eliminación de errores de software. El tener un plan de pruebas ayuda a clarificar el proceso de depuración. El plan de pruebas debe de estar mucho antes de la construcción del software.

105 Depuración Existen muchos tipos de pruebas dependiendo de la labor y características de cada una de ellas. Pruebas Alfa: se realizan por el usuario final en un ambiente controlado. Pruebas Beta: se realizan por el usuario sin controlar el ambiente.

106 Depuración A continuación se mencionan algunas características deseables que deben contener los planes de prueba: Diseñar un caso de prueba para cada funcionalidad del software. Establecer como mínimo un caso de prueba de datos correcto.

107 Depuración Establecer como mínimo un caso de prueba de datos incorrecto. Ejemplo: Caso de Prueba de un módulo de raíz cuadrada. Qué el usuario ingrese un número mayor que 0.

108 Depuración Qué el usuario ingrese un número 0
Qué el usuario ingrese un número menor que 0. Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.

109 Depuración Al realizar la depuración de un programa existe la posibilidad de un 50% de cometer otro error. Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.

110 Depuración Se recomienda probar lo antes posible cualquier fragmento de código. Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.

111 Depuración Las pruebas de caja blanca también llamadas transparentes se concentran en lo que es el código fuente. No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos

112 Depuración Las pruebas de segmentos son bloques de instrucciones.
Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.

113 Depuración Son pruebas funcionales y no interesa como se realizan las cosas sólo que el resultado obtenido sea el correcto. Se recomienda que sean los usuarios quienes las realicen. Existen diversas filosofías de pruebas como la programación defensiva.

114 Depuración La programación defensiva es una técnica de probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás. Se codifica el esqueleto de la aplicación. Se realizan pruebas.

115 Depuración Se corrigen los errores y se vuelven a hacer pruebas.
Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.

116 Depuración Existen otros tipos de prueba como:
Pruebas de unidad: se encargan de un módulo de software en particular. Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.

117 Depuración Existen otro tipos de prueba como las de aceptación que están más involucradas en el concepto en sí que en el desarrollo. También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.

118 Depuración La mayoría de los IDEs modernos presentan frameworks para la depuración desde el clásico step by step o step over sobre cada uno de los módulos hasta la realización de pruebas de unidad. Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.

119 Guía Prueba de Programas
Se necesita especificar las salidas o resultados esperados. Un programador debe de evitar probar sus propios programas. Una organización no debe de probar sus propios programas.

120 Guía Prueba de Programas
Inspeccionar los resultados obtenidos de cada prueba. Los casos de prueba deben escribirse con condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas.

121 Guía Prueba de Programas
Examinar un programa para verificar que hace lo que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer. No realizar planeaciones asumiendo que no se encontrarán errores.

122 Guía Prueba de Programas
La probabilidad de la existencia de mas errores en una sección de un programa es proporcional al número de errores encontrados en esa sección. La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora.

123 Guía Prueba de Programas
Se debe de realizar una lista de verificación para inspecciones de prueba que contenga los siguientes puntos: Datos Declaración de datos Errores computacionales Errores de comparación

124 Guía Prueba de Programas
Errores de control de flujo Errores de Interface Errores de Entrada/Salida Se pueden utilizar métodos deductivos e inductivos para la prueba de software.

125 Depuración por Inducción
Se siguen los siguientes pasos: Localizar los datos pertinentes Organizar los datos Estudiar las relaciones Divisar las hipótesis Probar las hipótesis Corregir el error

126 Depuración por Deducción
Enumerar las posibles causas Usar procedimientos de eliminación Refinar las hipótesis restantes Probar las hipótesis restantes Si no se pueden probar las hipótesis entonces coleccionar más datos y repetir el proceso En caso contrario corregir el error

127 XP eXtreme Programming
Se tienen doce principios básicos: Planeación y requerimientos Entregas pequeñas e incrementales Metáforas de Sistemas Diseños simples Pruebas continuas Refactorización

128 XP eXtreme Programming
Programación en pares Propiedad colectiva del código Integración Continua Semanas de 40 horas Clientes como miembros del equipo Codificar con estándares

129 Extreme Testing Las programación extrema tienen las siguientes ventajas en lo que respecta al proceso de pruebas: Se gana confianza ya que el código debe cumplir las especificaciones. Se tiene el resultado final del código antes de codificar

130 Extreme Testing Se entiende mucho mejor las especificaciones y requerimientos de la aplicación. Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones.

131 Plan de Pruebas Se recomienda utilizar la metodología y formatos del estándar IEEE 829 para documentación de pruebas de software: Pasos que incluye: Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas)

132 Plan de Pruebas Introducción (en que consiste las pruebas del sistema)
Elementos a probar Características a ser probadas Características que no se probarán Enfoque Criterio de fallo o aceptación de los elementos

133 Plan de Pruebas Criterio de Suspensión y Reanudación de requerimientos
Entregables de las pruebas Tareas de las pruebas Necesidades del entorno Responsabilidades Equipo y necesidades de capacitación Agenda

134 Plan de Pruebas Riesgos y contingencias Acuerdos
A las pruebas se les ha empezado a llamar de manera formal verificación y validación. Existen metodologías más robustas como el TMMI (Test Maturity Model) Jfcunit Httpunit Jwebunit Dbunit Opensta

135 Plan de pruebas

136 Formato Plan de Pruebas
ID: 1 Nombre: Enviar artículo Probado por: Fulanito Descripción: Se introducen los datos del artículo y de los autores. Condiciones de Entrada: nombreArticulo=“Calidad del Sw” … Resultado Esperado: El sistema confirma la correcta recepción del artículo enviando un al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Resultado Obtenido: Se generan bien userid y password pero el correo no llegó. Criterio de Aceptación: No.

137 Práctica de Laboratorio
Realizar un programa que permita calcular el área de un triángulo conociendo tres lados utilizando la fórmula de herón. Realizar el plan de pruebas que garantice que el programa está libre de errores

138 Arquitectura

139 Casos de Pruebas ¿Con cuantos casos de prueba valido que el software está correcto? Para cada caso de prueba sólo indicar las posibles entradas. Por ejemplo: Caso de Prueba 1: A=3 B=4 C=5, el resultado esperado debe de ser 6. ¿Es diferente el caso A=4 B=3 C=5?

140 Casos de Prueba Tipos de Triángulo en Base a sus lados:
Se deben tener al menos un caso de cada uno de ellos y al menos un caso no válido: A=0 B=-1 C=“Hola”.

141 Caso de Prueba ¿Cuál es el resultado esperado para el caso de prueba A=1 B=2 C=3? Area=0 ¿Qué pasó? !Exento este parcial quien pueda dibujar un triangulo de dimensiones 1, 2 y 3 cm para cada lado!

142 Referencias Pressman, R. (2004). Ingeniería del Software un Enfoque Práctico. Sexta Edición. McGraw Hill. Guido, J. y Clements, J., “Administración Exitosa de Proyectos”, Segunda Edición, Thomson, México, 2003, ISBN: X.

143 Referencias Pintor, A. (2009), Material del curso Calidad del Software II, Instituto Tecnológico de Morelia. Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN:

144 Referencias Piattini M.G. y F.O, Calidad en el desarrollo y mantenimiento del software. Ed. RAMA.

145 ¿Preguntas?