Transcript Paso 1 - Informática y Sistemas de Computación

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
Defectos
Errores
provenientes
de pasos previos
Detección
Errores pasados por alto
Errores amplificados 1: x
Nuevos errores generados
Porcentaje de
eficiencia para
detección
de errores
Errores
que
pasan
al paso
siguiente
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.
Llevando a cabo inspecciones
Errores encontrados
Número
Costo unitario
Durante el diseño
22
1.5
Antes de la prueba
36
6.5
234
Durante la prueba
15
15.0
315
3
67.0
201
Después
entrega
de
la
Total
Total
33
783
Sin llevar a cabo Inspecciones
Errores encontrados
Número
Costo unitario
Total
Antes de la prueba
22
6.5
143
Durante la prueba
82
15.0
1230
12
67.0
804
Después
entrega
Total
de
la
2177
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.
2.
3.
4.
5.
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.
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


1.
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.
Pasos..
2.
Se intenta identificar la causa o motivo de cada
defecto:



3.
4.
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
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
gravedad de sus consecuencias, de su
frecuencia de aparición y de la facilidad de
detectar 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
Alta
Capturar
a Empleados
Nomina
Nomina
Generar
Cheques
datos de los
empleados
Almacenar la información,
 Verificar que la información
sea capturada correctamente
Obtener
el consecutivo del
cheque
Imprimir el importe y concepto
Generar firma electrónica
Metodología para crear Tabla
AMFE

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
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:
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
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.
Metodología para crear Tabla
AMFE
Ejemplo Paso 4. Identificando las causas en el sistema de nómina
Modo del Fallo
Efecto
Causa
Error al Capturar el
nombre del empleado
Que nombre tenga caracteres No se valido
inválidos
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
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.

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:
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:
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.
Metodología para crear Tabla
AMFE

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)
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.
Six Sigma Software (Introducción)

2 Sigma



4 Sigma



69.146% de productos/servicios reúnen los
requerimientos de los clientes.
308,538 defectos por millones de oportunidades (DPMO)
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
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)