Unidad III

1. Unidad III Revisiones del Software

2. Revisiones del software • Son un filtro de software • Las revisiones se aplican en varios puntos durante la ing. del software y sirven para describir errores y defectos que luego pueden eliminarse. • Las revisiones “purifican” las actividades de la ing. del software. • Algunos expertos abordan de la siguiente manera la necesidad de revisiones:

3. Revisiones del software • “Errar es humano. Algunas razones por las que se necesitan las revisiones tecnicas es que, aunque la gente sea buena al captar algunos de sus propios errores, las grandes clases de errores escapan de su creador con mas facilidad de lo que escapan para alguien mas”

4. Revisiones de software • Una presentación formal del diseño de software a un auditorio de clientes, gestores y personal técnico es una forma de revisión. • Una Revisión Técnica Formal (RTF) es el filtro mas efectivo desde el punto de vista de aseguramiento de la calidad. • RTF es un medio efectivo para descubrir errores y mejorar la calidad del software, dirigida por los ing. de software. (Se vera mas adelante).

5. Situación de la calidad de SI • Desde hace varios años se viene insistiendo en la “crisis” de la Ing. del Software y en los desastres que los fallos de software pueden llegar a causar en las organizaciones. • Existe un grupo dedicado a actualizar y a “fotografiar” o reflejar la situacion actual del sector de SI (CHAOS). • CHAOS, dentro de su ultimo informe (2001), se señala que solo el 28% de los proyectos informáticos finalizan a tiempo, con los recursos planificados y con una calidad aceptable, mientras que casi una cuarta parte de los proyectos no llegan a finalizar nunca.

6. Situación de la calidad de SI • Hay un avance, ya que se ha pasado del 16% en 1994 al 28% en el 2000, respecto a los proyectos que se terminan con éxito.

7. Detectando errores a tiempo • Supóngase que la corrección de un error descubierto durante el diseño costara 1.0 unidad monetaria. • El mismo error descubierto justo antes de que comience el periodo de pruebas costará 6.5 • Durante las pruebas 15 y después de la liberación, entre 60 y 100 unidades. Por que se da este incremento??

8. Impacto de los defectos de software • El objetivo principal de las revisiones es descubrir errores lo mas pronto posible, antes de liberar el producto. • Hay que evitar que los errores se propaguen, he ahí la importancia de su detección oportuna. • Las actividades de diseño introducen entre el 50 y 65% de los errores. • Las técnicas de revisión formal han mostrado hasta 75% de efectividad al descubrir fallos en el diseño. • Al descubrir los errores el proceso de revisión reduce sustancialmente el costo de las actividades subsecuentes en el proceso de software.

9. Errores pasados por alto Porcentaje de eficiencia para detección de errores Errores amplificados 1: x Nuevos errores generados Amplificación y eliminación del defecto Detección Defectos Errores provenientes de pasos previos Errores que pasan al paso siguiente

10. Análisis de costo

11. Llevando a cabo inspecciones • De acuerdo a la siguiente tabla, se puede ver que el costo total para el desarrollo y el mantenimiento cuando se realizan inspecciones es de 783 unidades. Cuando no hay inspecciones, el costo total es de 2.177 unidades; casi 3 veces mas caro.

12. Llevando a cabo inspecciones Sin llevar a cabo Inspecciones

13. Evaluación de un producto de software • La norma ISO 14598 da una visión general del proceso de evaluación de un producto software, explicando en sus diferentes partes como aplicar el proceso en diferentes circunstancias. • Esta norma se apoya en la ISO 9126 ya que los aspectos ya que los aspectos cuantificables pueden medirse cuantitativamente usando métricas de calidad, cuyo valor medido se sitúa en una escala. Hacer dibujo Proceso de evaluación de un producto de software

14. Escala de evaluación • La escala se divide en rangos que corresponden a diferentes niveles de satisfacción de los requisitos: • Primero: se divide la escala en dos categorías: satisfactorio e insatisfactorio. • Segundo: la división de la escala en cuatro categorías: • Nivel actual de un producto existente o alternativo • El peor caso • El nivel proyectado • El nivel actual se declara con el fin de controlar que el nuevo sistema no suponga un deterioro en relación a la situación actual. Este nivel es lo que se puede alcanzar con los recursos disponibles. Hacer figura: Rangos de una escala de medida

15. Beneficios: • A partir de lo expuesto , podríamos resumir los beneficios comprobados al aplicar Inspecciones en : • Reducción de los defectos en el uso del software • Reducción de los recursos de desarrollo, sobre todo en las etapas de codificación y prueba • Reducción en los costos de mantenimiento correctivo

16. Revisiones • Hay dos motivos básicos para hacer una revisión: • El trabajo técnico necesita ser revisado. • Hay errores que son percibidos mas fácilmente. por otras personas que por los creadores. • Por definición es un grupo de personas que permiten: • Señalar la necesidad de mejoras. • Señalar que NO hay que mejorar. • Conseguir un trabajo técnico mas homogéneo.

17. Revisiones • En las revisiones un ingeniero de software debe utilizar tiempo y esfuerzo, y la organización desarrolladora, dinero. • El dinero o los costos de dan en el momento o después, obviamente el después siempre es mas caro, no solo por el dinero. • Por esto se proponen establecer actividades que acompañen al proceso de desarrollo (en lugar de puntos de control) para maximizar los defectos encontrados en cada etapa y minimizar la cantidad e impacto de los defectos que se encuentran en las etapas finales.

18. Revisiones técnicas • Revisiones Formales VS Informales: las informales se llevan a cabo constantemente, sin tales revisiones la programación y comprensión de un proyecto serian imposibles. Las revisiones formales tienen tres elementos: • Informe escrito del estado del producto revisado. • La participación activa y abierta de todos los del grupo de revisión. • Total responsabilidad de todos los participantes en la calidad de la revisión.

19. Objetivos de las Revisiones Técnicas Formales • Descubrir errores en la función, lógica o implementación en cualquier representación del software. • Verificar que el software en revisión satisface sus requisitos. • Garantizar que el software se ha representado de acuerdo con los estándares predefinidos • Lograr software desarrollado en una manera uniforme. • Hacer proyectos mas manejables.

20. La junta de revisión • En la revisión se deben involucrar entre 3 y 5 personas. • Se debe de preparar con anticipación, pero sin que requiera mas de dos horas de trabajo de cada persona. • La duración de la junta de revisión debe ser menor a 2 horas. RTF se enfoca en una parte especifica (y pequeña) del software total. Se llevan a cabo recorridos para cada componente o grupo pequeño de componentes.

21. Trabajando con RTF • RTF se dirige a una porción de requisitos, un diseño detallado de componente, etc. • Cuando el producto esta completo, se le informa al jefe del proyecto y se solicita la revisión. • El jefe del proyecto se pone en contacto con el jefe de revisión, quien evalúa la disponibilidad del producto, genera copias y las distribuye. • Al distribuirlas los revisores hacen las observaciones antes de la junta. • Se espera que cada revisor emplee entre una y dos horas en revisar el producto, tomar notas y familiarizarse con el trabajo. • El jefe de revisión revisa el producto y establece una agenda para la junta de revisión, usualmente se programa para el día siguiente.

22. Realizando la junta de revisión • Asisten el jefe de revisión, todos los revisores y el productor(es). • Uno de los revisores asume el papel de registrador (registra por escrito los temas importantes). • El productor procede a recorrer el producto de trabajo y explica el material. • Los revisores exponen los problemas encontrados. • Cuando se descubren problemas o errores (validos) el registrador los anota.

23. Finalizando la junta de revisión • Todos los asistentes deben decidir si: • Aceptan el producto sin modificaciones posteriores • Rechazan el producto debido a errores severos (una vez corregidos se tiene que realizar otra revisión). • Aceptan el producto provisionalmente (se encontraron errores menores que es necesario corregir, pero no se requerirá de una revisión adicional). • Al final se llena un documento de finalización en el que indican su participación en la revisión y conformidad con los hallazgos del equipo revisor.

24. Informe de la revisión • Un informe de la revisión responde a tres preguntas: • ¿Qué se revisó? • ¿Quién lo revisó? • ¿Cuáles fueron los hallazgos y conclusiones? • El informe resumen de la revisión es un formato de una sola pagina (con posibles anexos). Se vuelve parte del registro histórico del proyecto y es posible distribuirlo entre el jefe del proyecto y otras partes interesadas.

25. Trabajo • Por equipos se trabajara en la revisión de un mini proyecto de software que ya esta desarrollado. • Se realizara una RTF del mismo, por partes. • Se realizaran juntas de revisión y se elaborará un informe de las revisiones. • Cada equipo debe de crear su propio formato de informe de revisión.

26. Unidad IV Garantía de la calidad estadística del software

27. Introducción • La garantía de la calidad estadística refleja una tendencia, creciente en la industria, por adoptar un enfoque mas cuantitativo acerca de la calidad. • Para el software, la garantía de la calidad estadística implica los pasos siguientes: • La información acerca de los defectos de software se recopila y clasifica.

28. Pasos.. • Se intenta identificar la causa o motivo de cada defecto: • Falta de concordancia con las especificaciones • Errores de diseño • Violación de estándares, etc. • Mediante el principio de Pareto (80% de los defectos se encuentra en 20% de todas las causas posibles) se aísla un 20% (los mas importantes) • Una vez que las causas vitales han sido identificadas, se corrigen los problemas que han provocado los defectos. “ 20% del codigo tiene el 80% de los errores. ¡Encuéntrenlos, corríjanlos!” Lowell Arthur

29. Ejemplo de defectos • Una organización de ingeniería de software recopila información acerca de defectos durante un año. • Algunos defectos se descubren cuando el software esta en desarrollo; otros, después de que se ha liberado entre sus usuarios finales. • Los defectos encontrados son los siguientes: • Especificaciones incompletas o erróneas (EIE) • Mala interpretación de la comunicación del cliente (MCC) • Desviación intencional de las especificaciones (DIE) • Violación de los estándares de programación (VEP)

30. Tabla AMFE (Análisis Modal de Fallos y Efectos) • Es un proceso sistemático, planificado y participativo que se aplica cuando se diseñan nuevos productos o procesos. • También se utiliza cuando se realizan modificaciones importantes para evaluar o detectar fallos y causas que se originan antes de que lleguen al cliente. • Los fallos se priorizan de acuerdo a la gravedad de sus consecuencias, de su frecuencia de aparición y de la facilidad de detectar los fallos.

31. Metodología para crear Tabla AMFE • Paso 1. Identificar la función, proceso o parte a revisar. • Supongamos que se desea revisar un sistema de nomina:

32. Metodología para crear Tabla AMFE • Paso 1. • ¿Qué componentes y funciones se pueden identificar en cada proyecto que se les asigno?

33. Metodología para crear Tabla AMFE • Paso 2. Identificación del modo del fallo: • Dado que el estudio es sobre modos potenciales de fallo, se deben indicar todos los fallos susceptibles de producirse. • Fallos en el sistema de nomina: • Error al Capturar el nombre del empleado • No se genera correctamente el consecutivo de los cheques • La firma electrónica no se imprime correctamente

34. Metodología para crear Tabla AMFE • Paso 3. Determinación del efecto de fallo. • En este paso se deben de identificar todos los datos correspondientes a las diferencias en el funcionamiento observadas. • Los efectos que el fallo produce en los usuarios del sistema. • Ejemplo:

35. Metodología para crear Tabla AMFE • Paso 4. Identificación de las causas del fallo. • Se determina para cada Modo de Fallo analizado, las posibles causas que lo pueden ocasionar. • Este es uno de los elementos críticos del AMFE, ya que su conocimiento permite el establecimiento de Acciones Correctoras para evitar la aparición de los fallos, eliminando las causas que los provocan.

36. Metodología para crear Tabla AMFE Ejemplo Paso 4. Identificando las causas en el sistema de nómina

37. Metodología para crear Tabla AMFE • Paso 5. Determinación de la probabilidad de ocurrencia. • La probabilidad de ocurrencia es un valor entre 1 (mínima probabilidad) y 10 (máxima probabilidad) que indica la probabilidad de que el fallo ocurra. • Si bien no existen unas reglas normalizadas para la valoración de la probabilidad de ocurrencia, en la tabla se indican criterios de valoración que pueden servir de referencia.

38. Metodología para crear Tabla AMFE • Paso 6. Determinación de la gravedad del fallo: • La gravedad del fallo es un valor entre 1 y 10, que indica la influencia del fallo en el grado de satisfacción del cliente o usuario del sistema. • Las criterios que se incluyen en la tabla pueden servir de referencia en la valoración de la gravedad:

39. Metodología para crear Tabla AMFE • Paso 7. Determinación de la probabilidad de no detección: • Indica la probabilidad de no detectar el fallo antes de entregar el producto al cliente • Al igual que en los casos anteriores toma valores comprendidos entre 1 y 10. • La tabla muestra un criterio de clasificación que puede servir de referencia en la valoración de la probabilidad de no detección:

40. Metodología para crear Tabla AMFE • Paso 8. Determinación del Índice de Prioridad de Riesgo (IPR). • Se calcula el I.P.R. de acuerdo a la fórmula: • IPR= P · G · D, para cada uno de los fallos. • P= probabilidad de ocurrencia, G= gravedad del fallo y • D= probabilidad de no detección. • El IPR permite evaluar los diferentes niveles de riesgo y ordenarlos según sus prioridades. Estas prioridades determinan sobre qué modos de fallo es necesario tomar acciones correctoras, con objeto de reducir el correspondiente IPR.

41. Metodología para crear Tabla AMFE • Paso 10. Indicar las acciones correctoras, responsables y plazos.

42. Defectos • Errores en la representación de los datos (ERD) • Interfaz de componentes inconsistente (ICI) • Error en la lógica del diseño (ELD) • Prueba incompleta o errónea (PIE) • Documentación imprecisa o incompleta (DII) • Error en la traducción del diseño al lenguaje de programación (TLP) • Interfaz hombre-computadora ambigua o inconsistente (IHC) • Misceláneo (MIS)

43. Six Sigma Software (Introducción) Sigma es una letra griega que representa una unidad estadística de medida para definir la desviación estándar de una población. Mide la variabilidad o la dispersión de los datos. Seis Sigma también es una medida de variabilidad. Se ha dado su nombre para indicar que información cae dentro de los requerimientos de los clientes. Entre más grande es la sigma del proceso, mayores son las salidas de proceso, los productos y los servicios que reúnen los requerimientos de los clientes.

44. Six Sigma Software (Introducción) • 2 Sigma • 69.146% de productos/servicios reúnen los requerimientos de los clientes. • 308,538 defectos por millones de oportunidades (DPMO) • 4 Sigma • 99,379% de los productos/servicios reúnen los requerimientos de los clientes. • 6,210 DPMO • 6 Sigma • 99.99966% de los productos/servicios reúnen los requerimientos de los clientes. • 3.4 DPMO

45. Estándares y metodologías de medición • Antes de poder aplicar planes de mejora en una organización es necesario partir de una base cuantitativa que permita determinar de una forma objetiva los puntos fuertes y débiles de los procesos. • Las métricas de software constituyen la base necesaria para poder llevar a cabo un proceso de evaluación y posteriormente, una mejora de procesos de software. Tarea: Buscar norma 15504, SPICE, CMMI

46. Estándares y metodologías de medición • La medición esta presente en: • ISO/IEC 15504. Se define un proceso de medición. • CMMI. Se incluye un área clave de proceso en el nivel II de madurez denominada “Medición y Analisis” . • IEEE std 1061-1998. • El objetivo de estos estándares y marcos de trabajo es proporcionar la referencia necesaria para poder llevar a cabo el proceso de medición de una forma efectiva y sistemática, partiendo de la base de que la medición es un proceso que debe ser llevado a cabo en base a una serie de objetivos.

47. Practical Software Measurement (PSM) ISO/IEC 15939, Proceso de Medición de Software Estándares ISO/IEC SC7 CMMI Medición y Análisis 12207 (revisión – procesos de soporte) 15288 (conceptos de medición) Coordinación existente entre PSM, CMMI y los estándares ISO en el área de medición de Software 9126 (terminología coordinada) 14598 (terminología coordinada) ISO 90003 (objetivos)