“INSTITUTO TECNOLOGICO DE APIZACO”

METAL-MECÁNICA
INGENIERÍA MECATRÓNICA

PROGRAMACIÓN AVANZADA

RESÚMENES DE 3 ARTÍCULOS PARA LA DETECCIÓN DE ERRORES EN

SOFTWARES

ALUMNO:
JOSE NOE SANCHEZ LOPEZ

NO. CONTROL:
15370149

DOCENTE:
MAESTRO: ROBERTO ACOLTZI NAVA

APIZACO, TLAX.; 10 DE MAYO DE 2018

CALIDAD EN LA INSPECCIÓN DE REQUERIMIENTOS DE SOFTWARE: UNA
PROPUESTA DE MEDICIÓN
Alex F. Armijos, Carlos Monsalve, Rubén H. Ullon, Ricardo D. Maya, and José A. Romero

Para construir un software libre de defectos se ha venido ambicionando desde ya hace muchos años
atrás, Una técnica ampliamente usada y estudiada es la inspección de software que tuvo su origen
en 1976 cuando Fagan realizó su primera propuesta enfocada en la inspección de códigos. Desde
ese entonces la técnica de inspección de software ha tenido variantes con experimentos diversos
que han mostrado su aplicabilidad en la industria.

La importancia de la mencionada técnica radica en que mientras más defectos significativos se

encuentren en una etapa temprana de la construcción del software, más posibilidades existen que
el producto final responda a las necesidades funcionales.

Existiendo actualmente la norma IEEE 1028-2008; establece una serie de pasos y recomendaciones
que se deben cumplir para que una inspección (revisión sistemática de un artefacto) cumpla su
cometido de encontrar defectos en los DERS (Documentos de Especificación de Requerimientos de
Software)

2. Inspección y Calidad de Inspección

2.1. La Inspección

El proceso de inspección fue inicialmente propuesto por Fagan para detectar defectos en el código
construido pero este no fue suficiente así que fue extendido para la ayuda con la norma a IEEE-1028-
2008 que detalla los documentos que pueden ser inspeccionados por este proceso.

En esta norma también se detallan los roles involucrados:

1) Moderador

2) Registrador

3) Lector

4) Autor

5) Inspector

Así como sus etapas:

1) Preparar el proceso

2) Planificar el trabajo

3) Revisar anticipadamente los procedimientos

4) Revisar anticipadamente el producto a inspeccionar

5) Preparar la inspección (inspección individual)

6) Inspeccionar (inspección conjunta),

7) Remodelar

8) Culminar.

2.2. Métricas de calidad de inspección

El aporte que realiza presente trabajo sobre lo revisado en la literatura (sobre métricas de calidad
de inspección) consiste en que las métricas actualmente propuestas no consideran el nivel de
impacto de los defectos al momento de definir las métricas de calidad de inspección; y por tanto
estas métricas de calidad no penalizan las mediciones de acuerdo al grado del acierto que tuvieron
los inspectores al encontrar defectos.

Existiendo otros diferentes métodos donde expone que ninguna de las métricas propuestas integran
en una sola métrica los conceptos de eficacia y eficiencia, sino que miden por separado acierto y
eficiencia haciendo de todas estas un poco confusa la investigación y el acierto en el encuentro de
errores dl programa

2.3. Inspecciones y experiencia de los inspectores

Existen estudios relacionados con el mejoramiento de la efectividad del proceso de inspección que
proponen cambios al proceso: McCarthy et al. Realizaron un análisis costo beneficio (de las
reuniones colaborativas de inspección), sugiriendo que se omitan dichas reuniones ya que no son
necesarias para el éxito del proceso. Por otro lado, Eickelmannet al. Crearon un simulador con datos
de inspección recolectados (sobre inspecciones) por Motorola para identificar los factores que
intervienen en la efectividad de la inspección, y concluyeron que si las horas de inspección son
incrementadas, su efectividad tiende a disminuir. Esto también lo confirma Raz y Yaung con la
variante que el tamaño del producto inspeccionado también influye en la efectividad. Otros estudios
explican cómo influye la experiencia del inspector en la inspección de requerimientos. Estos
estudios realizan comparaciones entre inspectores profesionales y estudiantes universitarios

3. MÉTODO DE CALIDAD PROPUESTO

3.1. Calidad integral de inspección

La medición de calidad de inspección propuesta incluye en un mismo puntaje tanto un componente

de esfuerzo como otro de eficacia de la detección de defectos; es decir, este trabajo propone una
medición de la calidad integral. El primer componente está basado en el esfuerzo requerido para
detectar los defectos (según el nivel de impacto de los defectos), mientras que el segundo está
basado en el nivel de acierto en la detección de defectos (según el tipo de defecto y su nivel de
impacto).
Pudiendo crear una tabla para el mayor acierto en la inspección de los errores del programa
desarrollado

Por cada desacierto ocurrido en la inspección se aplica una penalidad al puntaje cuyo valor podemos
observar en el Cuadro

4. Metodología

Artefactos inspeccionados

Las inspecciones realizadas por los profesionales fueron llevadas a cabo en un caso de estudio donde
fueron inspeccionados 209 documentos de especificaciones de casos de uso pertenecientes a una
institución del gobierno ecuatoriano para un proyecto de un sistema financiero nacional.

Las inspecciones realizadas por los estudiantes fueron llevadas a cabo en un experimento en una
escuela politécnica ecuatoriana durante una sesión de clases de la asignatura de Ingeniería de
Software con máximo 2 horas de duración (el mismo tiempo máximo que tuvieron las sesiones de
inspección realizadas en el caso de estudio).

5. Resultados

la calidad fue calculada para cada documento tanto para el caso de estudio como para el
experimento. En esta sección se presentan los resultados para su posterior análisis y discusión. Un
ejemplo de estos cálculos realizados son mostrados en el Cuadro

Conclusión

En este trabajo se desarrolló un caso de estudio donde participaron profesionales en ciencias de la

computación realizando inspecciones de documentos de especificaciones de casos de uso de un
sistema financiero nacional perteneciente a un ministerio del gobierno ecuatoriano. Luego,
tomando estos mismos documentos se desarrolló un experimento en el que estudiantes
universitarios (de una universidad politécnica ecuatoriana) hicieron trabajos de inspección sobre
una muestra de estos documentos. La calidad de inspección de ambos grupos de inspecciones
fueron comparadas. Para realizar las inspecciones, se siguió un proceso de inspección basado en la
norma IEEE 1028-2008.

PUNTO DE VISTA PERSONAL

En el presente estudio se pudo observar que tiene un doble objetivo:

1) analizar los perfiles de los inspectores que influyen en la calidad de la inspección

2) proponer un nuevo método de cálculo de la calidad de inspección que incluye tanto la eficacia de
acierto al detectar defectos como la afectación del esfuerzo que toma detectar dichos defectos. El
método propuesto en este documento es un modelo estadístico y muy bien elaborado, y su
aplicación en un caso de estudio y un experimento de inspección de DERS contribuyendo a
responder la pregunta de que si la experiencia de los inspectores influye en la calidad de detección
de defectos. Así mismo el caso del estudio realizado como experimento incluyeron dos tipos de
perfiles de los inspectores participantes: estudiantes y profesionales del área de computación.

Por último es recomendable la realización de un buen análisis e inspección acerca de los

requerimientos para el desarrollo de un software ya que así podemos obtener un resultado óptimo
tanto para el cliente como para la aplicación que se le va a dar lo desarrollado
LA PRUEBA DEL SOFTWARE COMO CIENCIA
Ingrid Gallesdic, George Killiospy

La opinión más ampliamente difundida entre las personas que tienen alguna relación con la prueba
del software es que esta actividad es un arte. De hecho, se han publicado libros de amplia difusión
cuyos títulos se refieren a ella como arte, oficio o proceso. Pero debido a que la complejidad del
software se incrementa cada año, en este artículo se propone un enfoque nuevo, concebir a las
pruebas como una ciencia. Esto se debe a que los procesos mediante los cuales se aplican siguen los
pasos del método científico: entradas, procesos, salidas. En el contenido del presente trabajo se
analizan las semejanzas y características de la prueba como ciencia.

En las comunidades de software comercial, las pruebas del software fueron vistas alguna vez como
una idea de último momento. Los gerentes de producto novatos e incluso los desarrolladores las
consideraban como una disciplina fuera de foco, que casi cualquier persona podía realizar. Incluso,
algunos libros de divulgación sobre el tema incluyen en sus títulos palabras como arte y oficio, lo
que puede haber llevado a algunas personas en la industria a la conclusión de que las pruebas para
la calidad no eran una verdadera disciplina de la Ingeniería de Software

2. EL MÉTODO CIENTÍFICO

El método científico tradicional ha sido el método predominante para las personas observar y
comprender el funcionamiento del mundo y el universo. En los últimos años, algunos científicos han
desarrollado métodos que son menos rigurosos [5], pero el tradicional [6] es el que se utiliza como
base para este artículo. El algoritmo de este método es:

1. Observar algún aspecto del universo

2. Inventar una teoría que sea consistente con lo que se ha observado

3. Utilizar la teoría para hacer predicciones

4. Probar esas predicciones con experimentos o nuevas observaciones

5. Modificar la teoría de acuerdo con los resultados 6. Volver al paso 3.

Existen diferentes puntos de vista entre los científicos de hoy en cuanto a lo que constituye una
teoría, una hipótesis y un hecho, y de cómo se definen estos términos depende su visión de la
ciencia. Exponer plenamente los diferentes puntos de vista acerca del método científico y cómo se
definen los términos es una cuestión que está más allá del alcance de este trabajo. Sin embargo, es
importante entender que a menudo hay un nivel de sesgo, porque las personas aceptan las
definiciones, acerca de cómo funciona el mundo, siempre que sean coherentes con sus creencias.
Este es un razonamiento circular, porque si se trata de explicar cómo y por qué sucede algo, esto
está basado en cierto grado en un marco en el que ya se cree [7], por lo que uno de los grandes
retos de la ciencia es mantener la objetividad.

 Observación. Es el acto de reconocer y notar algún hecho u ocurrencia en la naturaleza, como una
aurora, una corona, o la estructura de un animal. Específicamente, es el acto de medir, con
instrumentos adecuados, cierta magnitud, como el tiempo de una ocultación con un reloj, la
ascensión recta de una estrella con un instrumento de tránsito y un reloj, la altura del sol o la
distancia a la luna desde una estrella con un sextante; la temperatura con un termómetro, etc.. Es
la información así adquirida.

 Experimento. Es un ensayo u observación especial, hecha para confirmar o refutar algo dudoso;
es un acto u operación realizada con el fin de descubrir algún principio o efecto desconocido, o para
probar, establecer, o ilustrar alguna sugerencia o verdad conocida; es un examen práctico; es una
prueba.

 Hipótesis. Es una suposición, una proposición o principio que se supone o se da por sentado, con
el fin de llegar a una conclusión o inferencia para probar el punto en cuestión; algo que no se ha
probado, pero que se asume para el propósito del argumento, o para contar un hecho o un
acontecimiento, como la hipótesis de que los vientos de proa detienen un barco. En Ciencias
Naturales, es una teoría tentativa o suposición adoptada provisionalmente para explicar

 Presunción. Lo que supone; un postulado o proposición asumida; una suposición.  Teoría. Es

una doctrina o esquema de cosas, que termina en especulación o contemplación, sin una visión
práctica; es una hipótesis; es una especulación. Es una exposición de los principios generales o
abstractos de cualquier ciencia. Es ciencia a diferencia del arte. Es una explicación filosófica de los
fenómenos, ya sea física o moral.  Hecho. Es un efecto producido o logrado; cualquier cosa
sucedida o que va a pasar; es un acto; es un evento; es una circunstancia. Es una realidad; una
actualidad; una verdad. La afirmación o declaración de un acto realizado o existente

3.1 Pre-definición de los resultados esperados Pre-definir los resultados esperados en la prueba es
similar al científico que predice el resultado de un experimento, antes que se lleve a cabo, mediante
la propuesta de una hipótesis.

3.2 Observación Sin la observación es imposible determinar el resultado de una prueba o

experimento. Aunque esto tiene sentido, es tentador diseñar pruebas y experimentos que sean
difíciles, si no imposibles, de observar.

3.3 Repetitividad En ciencia, un experimento se puede realizar miles de veces antes de poder
establecer una tendencia.

3.4 Construir el Experimento En la investigación científica, los experimentos son cuidadosamente

planificados y controlados. El ambiente del laboratorio surgió de la necesidad de probar las
condiciones durante un experimento y poderlo repetir nuevamente. En esta analogía de las pruebas
como ciencia, muchas personas parecen realizar los experimentos en la cocina, no en un entorno
de laboratorio controlado.

3.5 Realizar el experimento La realización del experimento es un ejercicio en el que se sigue

cuidadosamente el diseño previo. El científico investigador no improvisa a menos que esté
trabajando por fuera del plan.

3.6 El grupo de control En los experimentos científicos, los grupos de control se utilizan como una
línea base para comparar los resultados. Por ejemplo, un investigador podría probar un fármaco de
prueba en un grupo de personas, mientras que administra un placebo a otro grupo.

3.7 Modificar la hipótesis A menudo la hipótesis principal en las pruebas es que el sistema debe
funcionar en determinadas condiciones. Sin embargo, existe otra hipótesis opuesta según la cual,
aunque el sistema funciona, necesariamente no que quiere decir que no tiene defectos. La segunda
hipótesis es la más segura.

3.8 Visión a largo plazo La razón por la que se realiza investigación científica es para explicar la
forma en que se comporta la naturaleza observable. Se ha dicho que lo que distinguía a Thomas
Edison de otros inventores era que siempre tenía un agudo sentido de cómo la ciencia podía
ayudarles a las personas a mejorar sus vidas. También tenía un buen sentido de los negocios, y sabía
cuándo dejar de investigar para construir el proyecto.

3.9 Creatividad Aunque algunos pueden considerar a las pruebas de software como un arte, la única
similitud es que implica una gran dosis de creatividad. Se podría argumentar que la prueba de un
programa computacional a gran escala requiere más creatividad que su diseño.

3.10 Visión filosófica Desde el principio de los tiempos, los seres humanos han participado de las
pruebas en diversas formas, ya fuera al cuestionar los diseños de herramientas o al criticar los
procesos. Esta constante re-evaluación dio lugar a una mejor calidad y a ganancias significativas en
eficacia y eficiencia.

3.11 Establecer confianza La mejor forma para establecer la confianza en la fiabilidad del software
no es sólo demostrar que funciona dentro de los límites de la especificación del producto, sino
también al exponer los defectos potenciales en el diseño o la funcionalidad del mismo. Sin embargo,
cualquier conjetura puede consumir muchas horas de exhaustivas pruebas y todavía contener
errores.

CONCLUSIONES

Existen muchos puntos en común entre las pruebas del software y la ciencia tradicional. De hecho,
las primeras pueden estar más cerca de la ciencia que cualquier otra cosa que podamos relacionar.
Estas similitudes pueden ser útiles para su comprensión y para explicarlas a otros. Las similitudes
también proporcionan un punto de referencia de la rigurosidad del proceso que se utilizan en la
definición y realización de los procesos de prueba. Aunque no es necesario que cada prueba se
realice con el rigor de la investigación científica, algunas sí requieren ese nivel, especialmente las de
productos de alto riesgo. Al igual que en la ciencia, en las pruebas de software se buscan respuestas
correctas. O bien el producto cumple con los requisitos o no lo hace. A través de pequeños pasos
incrementales las pruebas se aproximan a la verdad sobre el software. El objetivo es entregar el
software con el menor número de errores posible, para que el usuario reciba un producto fiable y
de calidad.

OPINION PERSONAL

En este documento se pudo observar que la prueba de software ha sido descrita como un arte, un
oficio o un proceso pero no como una ciencia así que se describe las co-relaciones que tiene e
influyen en el ámbito científico y que además es una ciencia el desarrollo de un software, nos
planteó desde las cualidades que debemos de tener para la correcta implementación hasta los
puntos más importantes que engloban la ciencia tradicional

Para mejorar nuestro sistema científico actual, necesitamos buenas herramientas de Software,
necesitamos hacer a la ciencia más accesible.

Pero también necesitamos un cambio de cultura. Para el mejor entendimiento en vez de basarse en
información de segunda mano, aplicar un poco más de ciencia a lo cotidiano ya que cualquier
persona puede buscar conocimiento por sí mismo.
APROVECHANDO LOS DEFECTOS PARA PREVENIR SU REPETICIÓN.
EXPERIENCIA EN UNA ORGANIZACIÓN PEQUEÑA.
ISC, LSCA Clara Min Poblete Universidad Veracruzana, Xalapa, Ver. México. claraminp@yahoo.com
Dr. Juan Manuel Fernández Peña Universidad Veracruzana, Xalapa, Ver. México. jfernandez@uv.mx
Dra. María de los Ángeles Sumano López Universidad Veracruzana, Xalapa, Ver. México.

Una de las formas de mejorar la calidad de productos de software a partir de las pruebas es el
análisis de los defectos identificados, buscando sus causas, para luego proponer mejoras al proceso
de desarrollo y a las propias pruebas. El presente trabajo se desarrolla en una pequeña organización
de gobierno, donde existe un reducido equipo de desarrollo de software y adquiere software ad
hoc, con el propósito de mejorar la calidad del software desarrollado y verificar el que se adquiere
de manera más adecuada.

La realización de pruebas en una organización que desarrolla y adquiere software sir para varios
propósitos, inicialmente verificar sus productos y los que compra. A largo plazo resulta más
relevante la prevención de los defectos, con la cual se mejora la calidad de los productos. Para
prevenir los defectos debe conocerse el problema que se enfrenta, que depende del tipo de
organización, la capacidad de su personal y la naturaleza del software desarrollado. Todo ello se
puede resumir, de alguna manera, en que cada organización está más propensa a ciertos tipos de
defectos. Así estudiando el pasado puede conocerse cómo provenir defectos futuros, siempre y
cuando se tenga registro de los problemas encontrados.

A lo largo del tiempo la realización de pruebas ha ido acompañada de la clasificación de defectos,

generalmente de manera arbitraria y particular a cada empresa. Beizer propuso una manera de
clasificar defectos que permite cierto grado de estandarización, pero dejando margen a la
particularización de la misma (Beizer, 1990). Esta clasificación aún es muy empleada. Existen otras
como la Norma IEEE 1044-93 (IEEE,1994), la de Cem Kaner y sus colaboradores (Kaner et al, 1990) y
alguna especializada en seguridad (Landwehr et al, 1996). Sin embargo en la década de 1990 se hizo
evidente que las clasificaciones dejaban abiertos muchos problemas por ambigüedades y traslapes
en las categorías usadas. Autores como Chillarege (Chillarege, 1994) y Demillo y Mathur, citados en
(Ploski et al, 2007), propusieron formas de evitar las ambigüedades dadas. El método propuesto por
Chillarage, conocido como Clasificación Ortogonal de Defectos, (ODC por sus siglas en inglés),
continuó su desarrollo siendo muy empleado en IBM y otras empresas (Chillarege, 1999).

Muchos de los problemas para clasificar los defectos vienen de las diferentes concepciones acerca
de su naturaleza. En la definición de ODC se parte de considerar un defecto como un cambio que se
debe aplicar al software para corregir un funcionamiento inadecuado. De acuerdo al método ODC
se registra información en dos momentos: el primero (apertura) cuando ocurre una falla,
anotándose las circunstancias que la provocaron y el impacto en los usuarios. El segundo (cierre),
cuando un defecto ha sido reparado, encontrando su naturaleza exacta, anotándose el tipo de
cambio necesario para su solución. Los defectos se clasifican en varias categorías mutuamente
excluyentes pero complementarias, es decir ortogonales.

Este método de clasificación abre las puertas a una amplia variedad de técnicas de análisis causal
de defectos y de obtención de estadísticos acerca de ellos. Con el Análisis causal de defectos se
identifican causas posibles y se buscan maneras de eliminar o disminuir éstas y de iniciar acciones
orientadas a prevenir defectos en un futuro. El análisis es cualitativo y sólo está limitado por la
capacidad y habilidad de los que la realizan (Chillarege et al, 1992).

Para preparar el análisis causal se prepara un histograma con las frecuencias de los defectos,
ordenados descendentemente y luego se seleccionan los tipos más frecuentes, aplicando el llamado
Principio de Pareto. De este modo se atiende primero los defectos con mayor ocurrencia en la
empresa.

Análisis de datos registrados

Con la intención de identificar cuáles defectos son los más frecuentes y así considerarlos en pruebas
de proyectos futuros, se decidió estudiar la información disponible en la organización donde se
aplica este estudio. Inicialmente se han registrado defectos, de manera informal, desde hace
tiempo, en varios formatos. Tomando como referencia la clasificación sugerida en el método ODC,
se procedió a clasificar los defectos y su solución para los datos registrados desde julio del 2009
hasta el mes de febrero del 2010. En ese período se encontraron y repararon 37 defectos, donde la
mayoría corresponden a los sistemas que ya se encuentran implementados en alguna área de
trabajo. El número quizá suene reducido, pero resultan importantes por los problemas que generan.

Para realizar la clasificación de defectos de esta institución se utilizó el siguiente proceso:

 Primero se registraron todos los defectos identificados en algún medio, para darle
tratamiento y saber por qué y en qué momento ocurre la falla.
 Después, se procede a investigar el defecto para eliminarlo desde su raíz.
 Por último se registró la solución para conocer la causa con la clasificación ortogonal de
defectos.

En cuanto a la clasificación de defectos, la Figura 1 muestra el impacto que provocan los defectos al
cliente cuando estos producen una falla.
En la Figura 2 los defectos fueron clasificados de acuerdo al artefacto que fue modificado,
separándolos por tipo. Los resultados obtenidos muestran que existe un alto grado de fallos
relacionados con comprobaciones. Otra de las observaciones el comportamiento de la Figura 2 es
que existe un alto nivel de fallos en los algoritmos de interpretación del diseño al código y también
en el propio código. Esto puede ayudar a ser más específicos cuando se realiza los diseños de
software para minimizar los fallos en las comprobaciones. También puede observarse que el
número de problemas que debieron corregirse en el diseño es igual al de aquellos que requirieron
cambios en el código.

De acuerdo a los resultados obtenidos de los defectos revisados en esta empresa puede identificarse
las causas donde se debe trabajar para evitar los defectos: La identificación de los requerimientos y
el medio ambiente en el que opera el software.
Conclusiones

Con la clasificación de defectos realizada se ha logrado lo siguiente:

 Fueron identificados los defectos más frecuentes en el software utilizado, logrando

cuantificar en qué parte del proceso fue cometido el error y cómo perjudica al cliente.
 Se identificaron las fallas más comunes en el proceso de desarrollo.
 Ya se lleva un control de los defectos del software utilizado, tanto desarrollado de forma
interna y de forma externa, en donde el personal que lleva el mantenimiento puede
resolver con mayor rapidez.

Cabe mencionar que los resultados de un trabajo como el presentado también ayudan a
terceras personas, como son proveedores y usuarios finales. Se refleja en la satisfacción que
logran proveedor y cliente como resultado de una buena negociación. Con la finalidad de
disminuir la frecuencia de las fallas más comunes, se recomienda utilizar la clasificación de
defectos en organizaciones donde exista personal que se encargue de dar soporte al software
y tenga cierto contacto con usuarios finales. Como continuación del presente trabajo se
trabajará en mejorar las guías propuestas y en analizar los resultados de su aplicación en la
prevención de defectos.

OPINION PERSONAL

En este documento se entiende que a partir de los análisis de los defectos identificados
previamente en algún tipo de software es posible mejorar la calidad y funcionamiento del
mismo, y gracias a la realización de pruebas ha sido posible clasificar los tipos de errores y por
medio de tablas que es lo que propone el documento, en el encabezado debería de ir planteado
el tipo de error y por lo consiguiente las anotaciones de cómo es posible corregirlo, esto debe
de hacerse en cada error que este de visto después del análisis. Después del registro se procede
al análisis de los datos en donde los autores proponen la siguiente metodología para el análisis:

 Primero registrar todos los defectos identificados en algún medio, para darle tratamiento
y saber por qué y en qué momento ocurre la falla.
 Después, se procede a investigar el defecto para eliminarlo desde su raíz.
 Por último se registra la solución para conocer la causa con la clasificación ortogonal de
defectos.

Y una vez clasificados los defectos y analizados es posible llegar a:

 Fueron identificados los defectos más frecuentes en el software utilizado, logrando

cuantificar en qué parte del proceso fue cometido el error y cómo perjudica al cliente.
 Se podrán identificar las fallas más comunes en el proceso de desarrollo.
 Llevar un control de los defectos del software utilizado, tanto desarrollado de forma
interna y de forma externa, en donde el personal que lleva el mantenimiento puede
resolver con mayor rapidez.