Unidad III

Unidad III

Revisiones del Software

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:

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”

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).

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.

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.

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??

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.

Amplificación y eliminación del defecto

Errores pasados por alto

Errores amplificados 1: x

Nuevos errores generados

Porcentaje deeficiencia para

detecciónde errores

Erroresprovenientesde pasos previos

Defectos Detección

Erroresque pasanal pasosiguiente

Análisis de costo

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.

Errores encontrados Número Costo unitario Total

Antes de la prueba 22 6.5 143

Durante la prueba 82 15.0 1230

Después de la entrega

12 67.0 804

Total 2177

Errores encontrados Número Costo unitario Total

Durante el diseño 22 1.5 33

Antes de la prueba 36 6.5 234

Durante la prueba 15 15.0 315

Después de la entrega

3 67.0 201

Total 783

Llevando a cabo inspecciones

Sin llevar a cabo Inspecciones

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

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

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

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.

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.

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.

Objetivos de las Revisiones Técnicas Formales

1. Descubrir errores en la función, lógica o implementación en cualquier representación del software.

2. Verificar que el software en revisión satisface sus requisitos.

3. Garantizar que el software se ha representado de acuerdo con los estándares predefinidos

4. Lograr software desarrollado en una manera uniforme.

5. Hacer proyectos mas manejables.

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.

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.

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.

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.

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.

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.

Unidad IV

Garantía de la calidad estadística del software

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:

1. La información acerca de los defectos de software se recopila y clasifica.

Pasos..2. 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.

3. 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)

4. 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

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)

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 gravedadgravedad de sus consecuencias, de su frecuenciafrecuencia de aparición y de la facilidad de facilidad de detectardetectar los fallos.

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:

Sistema Componentes Funciones

Nomina

Alta a Empleados Capturar datos de los empleadosAlmacenar la información, Verificar que la información sea capturada correctamente

Nomina Generar Cheques Obtener el consecutivo del chequeImprimir el importe y conceptoGenerar firma electrónica


Paso 1. ¿Qué componentes y funciones se

pueden identificar en cada proyecto que se les asigno?

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


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:

Modo del Fallo Efecto

Error al Capturar el nombre del empleado

Que nombre tenga caracteres inválidos

No se genera correctamente el consecutivo de los cheques

Que los números de cheques se dupliquen o sean rechazados por el banco


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.


Modo del Fallo Efecto Causa

Error al Capturar el nombre del empleado

Que nombre tenga caracteres inválidos

No se valido correctamente los caracteres validos.

No se genera correctamente el consecutivo de los cheques

Que los números de cheques se dupliquen o sean rechazados por el banco

Se implemento de forma errónea la función que realiza el calculo

Ejemplo Paso 4. Identificando las causas en el sistema de nómina


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.


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:

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:


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.


Paso 10. Indicar las acciones correctoras, responsables y plazos.

Acciones Correctoras

Responsables Plazos

Poner una validación en la captura.

Equipo de Desarrollo De inmediato, en 2 horas

Agregar un campo en una tabla y generar un procedimiento almacenado en la B.D. para obtener el consecutivo

Equipo de Desarrollo, Gestor de Base de Datos

Prioritario, 4 horas

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)

SigmaSigma 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.

SigmaSigma 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 SigmaSeis 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.

Seis SigmaSeis 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.

Six Sigma Software (Introducción)

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

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

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.

Practical Software Measurement (PSM)

ISO/IEC 15939, Proceso de Medición de Software

CMMIMedición y Análisis

Estándares ISO/IEC SC7

12207 (revisión – procesos de soporte)

15288 (conceptos de medición)

9126 (terminología coordinada)

14598 (terminología coordinada)

ISO 90003 (objetivos)

Coordinación existente entre PSM, CMMI y los estándares ISO en el área de medición de Software

Unidad III

Documents

Transcript of Unidad III