See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/266137857

DISEÑO EXPERIMENTAL PARA COMPARAR MÉTODOS DE ESTIMACIÓN DEL

TAMAÑO FUNCIONAL DEL SOFTWARE

Conference Paper · May 2008

CITATIONS READS

0 631

6 authors, including:

Sergio Gustavo Zapata Myriam Herrera

National University of San Juan National University of San Juan
27 PUBLICATIONS   49 CITATIONS    13 PUBLICATIONS   72 CITATIONS   

SEE PROFILE SEE PROFILE

Susana Ruiz María Inés Lund

Universidad Nacional de San Juan, Argentina, San Juan. National University of San Juan
9 PUBLICATIONS   0 CITATIONS    24 PUBLICATIONS   11 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Global Software Development View project

Empirical software engineering View project

All content following this page was uploaded by Sergio Gustavo Zapata on 26 September 2014.

The user has requested enhancement of the downloaded file.

 DISEÑO EXPERIMENTAL PARA
COMPARAR MÉTODOS DE
ESTIMACIÓN DEL TAMAÑO
FUNCIONAL DEL SOFTWARE
INTERTECH’2008
Sergio G. Zapata1, Claudia P. Gomez 2, Myriam
Herrera 3, Susana Ruiz4, Estela Torres5,
M. Inés Lund6
Abstract  Uno de los síntomas de la denominada crisis del
software es la carencia de estimaciones certeras respecto
del esfuerzo de construcción de software, cuestión de suma
importancia a la hora de tomar decisiones sobre la
factibilidad de un proyecto de software. Los métodos
existentes de estimación de tamaño de software no son
ampliamente utilizados, entre otros motivos, porque no
cuentan con un alto grado de confianza de parte de los
ingenieros de software. Se presenta en este trabajo el diseño
de un experimento para la comparación de dos métodos de
estimación de tamaño de software. Para esta experiencia se
contará con la participación de alumnos avanzados de la
carrera de grado de Licenciatura en Informática de la
Universidad Nacional de San Juan (Argentina).
Adicionalmente se evaluará la experiencia como mecanismo
de aprendizaje para los alumnos participantes.
Palabras Claves Ingeniería de Software Empírica,
tamaño funcional del software, Puntos de Función, Método
FPA, método MKII.
INTRODUCCIÓN
El software, un bien en el que se invierten grandes
sumas de dinero, es cada vez más importante en las acciones
cotidianas de las sociedades modernas. Por lo tanto es
importante controlar su desempeño, y para poder controlarlo
es imprescindible medirlo [1].
El uso de métricas, y en este caso de un método de
estimación del tamaño de software, nos puede ayudar a tener
mejor el control de la ejecución de un proyecto de software,
como también una mejor evaluación previa de la inversión
necesaria para encarar tal proyecto.
1 los más utilizados en la actualidad en diversos proyectos de
Investigadores del Instituto de Informática dependiente de
la Universidad Nacional de San Juan, Meglioli 1150 (sur) CP
5400, Rivadavia – San Juan- Argentina, Telefono: +54 (0264)
4265101 - 4234180 (FAX), San Juan Argentina, {szapata –
cpgomez – sruiz - mherrera – etorre - mlund}@iinfo.unsj.edu.ar
Algunas de las falencias importantes que se han
detectado en el proceso de desarrollo de software son las
escasas pruebas (testing) sistemáticas de software, poco
involucramiento de los usuarios y la falta o incorrecta
estimación del tamaño de los sistemas, que resulta ser otro
factor que lleva al fracaso de proyectos de software. [2].
La Ingeniería de Software Empírica trata de probar
métodos, técnicas y herramientas de software utilizando la
validación empírica, con el fin de aportar información sobre
la probable adopción en la práctica de tales elementos.
La experimentación es la técnica más eficaz para probar
una hipótesis. En este trabajo se propone llevar a la práctica
un proceso de Ingeniería de Software Empírica a través de
un experimento convenientemente diseñado que permita
obtener datos apropiados, que puedan ser analizados
mediante métodos estadísticos, con el objeto de realizar
comparaciones, para producir conclusiones válidas y
objetivas.
Este trabajo está organizado de la siguiente manera: en la
sección 2 se definen las hipótesis de trabajo que se
intentaran corroborar a lo largo del experimento. En la
sección 3 se presenta un diseño de experimento denotando
qué aspectos son necesarios tener en cuenta para llevarlo a
cabo. Se termina el trabajo con la sección 4 en la cual se
expresan las conclusiones y trabajos a futuro.
PLANTEAMIENTO DEL PROBLEMA
Existen distintos métodos de estimación de tamaño
de software. Cada uno de ellos aplicados al mismo software
debería arrojar valores que no difieran significativamente.
¿Esto es efectivamente así? De ser así, estos métodos
ganarían en confianza por parte de los ingenieros de
software, lo cual estimularía su beneficiosa utilización.
También se podría determinar las bondades de un método
respecto al otro, por ejemplo estableciendo cuál es más
sencillo de aplicar, cuál más fácil de aprender, cuál más
rápido de emplear, etc.
Con el fin de obtener respuestas a las preguntas del
párrafo anterior, se propone en este trabajo un diseño
experimental que permitirá comparar dos métodos de
estimación de tamaño funcional de software, Análisis de
Puntos de Función (FPA) propuesto por Alan Albrecht en
1979 y Análisis de Puntos de Función MarkII (MK-II)
desarrollado por Symons en 1980 que presenta la misma
funcionalidad y estructura que el de Albrecht.
La elección de los métodos en cuestión estuvo dada
por el hecho que FPA es uno de los más antiguos y uno de
software, y MK-II porque toma en cuenta, a diferencia de
FPA, las transacciones lógicas del sistema. Esto quiere decir
que tiene en cuenta la complejidad de procesamiento interno
del sistema, la cual se puede capturar o identificar
claramente a través de los casos de uso y escenarios que
muestran la funcionalidad del sistema desde el punto de vista
del usuario. Esta diferencia entre los métodos se plantea
principalmente porque Symons considera que el método de
Albrecht presentaba anomalías e ineficiencias para lo cual
pretendió dar una solución con su método denominado
Análisis de Puntos de Función MarkII o simplemente MKII,
un nuevo enfoque basándose en el mismo concepto.
El objetivo que se pretende con esta experiencia, dado
que se sospecha que ambos métodos no estiman el tamaño
funcional del software en igual términos medios, es
contrastar las siguientes hipótesis:
a) Hipótesis respecto a tamaños funcionales
Ha0: Son iguales los tamaños funcionales medios del
software estimados por ambos métodos, MK II y FPA.
Ha1: Ambos métodos no estiman el mismo tamaño funcional
medio del software.
En el caso de no encontrar evidencias suficientes como para
rechazar la hipótesis nula anterior, resultaría interesante
analizar si el método MKII es más ventajoso que el método
FPA en cuanto al tiempo promedio en la aplicación sobre un
mismo software de entrada. Esto podría ser útil, por ejemplo,
en el momento de realizar un presupuesto de un proyecto de
software donde el cliente demande una respuesta rápida,
para lo cual se podría optar por aquel método cuyo tiempo
de aplicación sea menor.
b) Hipótesis respecto al tiempo de estimación:
Hb0: En promedio, los métodos MKII y FPA tardan el mismo
tiempo en estimar el tamaño funcional del software.
Hb1: El tiempo medio que tarda en estimar el tamaño
funcional el método MKII es mayor que el obtenido con el
método FPA, para un mismo software.
SELECCIÓN DE VARIABLES
Las variables independientes describen los tratamientos
y son las variables para las cuales se evalúan los efectos. Las
variables independientes de interés en nuestro estudio es el
método que estima el tamaño funcional del software. Esta es
nominal y toma dos niveles MKII y FPA.
Las variables dependientes son las variables respuestas
descriptas por los efectos de los tratamientos antes
mencionados como variables independientes. Ellas son el
tamaño funcional del software y el tiempo en estimar el
tamaño funcional del software.
SELECCIÓN DE SUJETOS
Los sujetos (alumnos) serán elegidos por conveniencia,
no aleatoriamente, serán estudiantes avanzados de la carrera
de grado Licenciatura en Sistemas de Información, de la
Universidad Nacional de San Juan. La elección de los
alumnos tiene como motivos principales el relativo bajo
costo de su participación y la alta disponibilidad de los
mismos. Adicionalmente, los alumnos se verán beneficiados
en su formación profesional al adquirir experiencia práctica
sobre métodos de estimación de tamaño de software.
En la siguiente sección se presenta el diseño
experimental que proponemos para contrastar las hipótesis
planteadas.
DISEÑO DEL EXPERIMENTO
Durante la ejecución del experimento es fundamental seguir
un procedimiento fiable para que los resultados que de él se
obtengan puedan ser considerados válidos [3].
Es importante poder identificar en el diseño del experimento,
las posibles causas (también llamadas factores) que lleven a
modificar la respuesta de salida del experimento, a lo que se
dará el nombre de error experimental.
La metodología estadística es el único enfoque objetivo para
analizar un problema que involucre datos que contengan
errores experimentales. El diseño del experimento y el
análisis estadístico de los datos, en un problema
experimental, están estrechamente vinculados, ya que el
método de análisis depende directamente del diseño
empleado [4].
Tres principios básicos para el diseño de un experimento
son: la repetición, la aleatorización, y el análisis por
bloques. Por lo que al definir un diseño experimental se
deberá:
 Considerar el tamaño muestral (número de
repeticiones),
 Seleccionar un orden adecuado para los ensayos
experimentales (aleatorización), y
 Determinar si hay bloqueos implicados u otras
restricciones (para controlar sistemáticamente la
variabilidad producida por diversas fuentes
extrañas) que perturben los resultados.
Nuestro problema planteado consiste en determinar si hay
diferencias significativas en las estimaciones medias de los
tamaños funcionales que proporcionan los citados métodos
MKII y FPA, sobre un mismo software.
Por lo que nuestra variable aleatoria de interés es la Cantidad
de Puntos de Función (o tamaño funcional del software).
Podemos reconocer, hasta ahora, que hay un único factor
que puede producir cambios en la variable respuesta, y esta
es: la clase de método empleado para estimar el tamaño
funcional del software, bajo sus respectivos dos niveles de
interés: método MKII y método FPA.
Para que ambos métodos sean aplicados se requiere la
participación de sujetos expertos, esto es de personas con
conocimiento del método para su aplicación. En este aspecto
se ha decidido trabajar con estudiantes avanzados de la
carrera de grado Licenciatura en Sistemas de Información,
de la Universidad Nacional de San Juan. Se entiende que la
participación de alumnos en este tipo de experimento puede
ser una instancia adicional de aprendizaje no tradicional y
positiva para ellos [5]. Inicialmente se llevará a cabo un
entrenamiento, en las aulas del Instituto de Informática de la
Universidad Nacional de San Juan, para que los sujetos
involucrados tengan un nivel de conocimiento y experiencia
en la aplicación de los métodos de tal forma que puedan el FPA. Al final del período se miden las respuestas. A
considerarse expertos en los mismos. Para ello se continuación, se les da el método FPA a los sujetos que
confeccionará un documento que se denominará Guía habían utilizado el MKII, y a quienes aplicaron el MKII se
Técnica, el cual resumirá los métodos, su aplicación y les da el FPA. Este diseño se muestra en la Tabla 2.
ejemplos.
Con el fin de trabajar con alumnos motivados en la temática
de estimación del tamaño funcional de software y evitar
influencias no deseadas en los resultados que se quieren Tipo de método
obtener de esta experiencia, no se dará a conocer a los
estudiantes, que se tratará de un experimento, sino de un Alumnos Método Método
taller práctico de aprendizaje de métodos de estimación de expertos (j) MK II FPA (i=2)
tamaño funcional del software. B
Se requerirá de los estudiantes candidatos a participar en el L (i=1)
experimento las siguientes condiciones: O
1 Y11 Y12
 Acreditar conocimientos en Análisis y Diseño Q
U
Orientado a Objetos y lenguaje de modelado UML E
2 Y21 Y22
(Unified Model Lenguage). S
 Acreditar ser alumno del último año de la carrera de   
Licenciatura en Sistemas de Información o egresado B Yb1 Yb2
de la misma carrera.
A los estudiantes seleccionados se les hará entrega de una
encuesta personal con el fin de obtener información del
perfil de cada uno de ellos.
Tabla 1: Diseño aleatorizado por bloques completos
Como las diferencias de capacidades entre los alumnos para el experimento
pueden contribuir en la variabilidad observada en los
cálculos del tamaño funcional del software por ellos
obtenida, el error experimental puede reflejar tanto el error I II …… N
aleatorio como la variabilidad de capacidades.
Sujeto 1 2 3 4 … 2n-1 2n
Se desea que el error experimental sea lo más pequeño
posible; en otras palabras, se desea sustraer del error Período 1 MK FPA FPA MK MK II FPA
experimental la variabilidad que pueden producir los II II
alumnos en la aplicación de los métodos. Para ello será Período 2 FPA MK MK FPA …… FPA MK II
necesario que cada alumno experto aplique los dos métodos, II II
en horarios diferentes, una por vez, donde el orden de la
aplicación de los métodos se realizará en forma aleatoria.
Este diseño, que se resumirá en una tabla final, (Tabla 1), se Tabla 2: Diseño Cruzado
denomina diseño aleatorizado por bloques completos [4],
donde los bloques son los propios alumnos que conforman
las unidades experimentales más homogéneas posibles, tal Notemos que si designamos con G1 al grupo de alumnos que
que se puedan comparar los métodos dentro de ellos. A este realizan el método MKII primero y el método FPA después
caso, donde el bloque es el alumno, también se lo denomina y con G2 al grupo de alumnos que realizan el método FPA
diseño completamente aleatorizado en bloque. El orden en primero y el método MKII después, tal asignación de
que los métodos deberán ser aplicados se determinará en acuerdo al anterior diseño será:
cada bloque, en cada alumno, en forma aleatoria. Esto sería
correcto si asumimos que un método no adiestra al alumno Sujetos
cuando aplica el otro. En caso de no poder asegurar que el
primer método utilizado sirve de adiestramiento para el G1 1 4 6 …. 2n-1
segundo (el primero aún refleja efectos que influyen en el G2 2 3 5 … 2n
segundo) se sugiere el diseño de cuadro latino cruzado
(primero se selecciona un método y luego el otro) para
experimentos con tratamientos que poseen efectos Tabla 3: Grupos de trabajo
residuales. Este tipo de diseño es adecuado cuando los
períodos de tiempo constituyen un factor en el experimento. Para determinar cuál método es mejor, se utilizará un
En nuestro caso, se cuenta con la cantidad total de alumnos análisis de la varianza (ANOVA) que en el caso de trabajar
del curso. En el primer período la mitad de los sujetos con dos tratamientos, como es nuestro caso, se trata de la
(escogidos al azar) aplican el método MKII, y la otra mitad prueba t para datos en pareja bajo condiciones de normalidad
o en caso de fallar esta condición se trabajará con el test de
Wilcoxon [4].
CONTEXTO DEL EXPERIMENTO
El experimento se realizará en las aulas del Instituto de
Informática de la Universidad Nacional de San Juan, las
cuales están acondicionadas (capacidad, mobiliario,
equipamiento didáctico, etc.) para los fines propuestos.
RECURSOS NECESARIOS
Para la realización del experimento será necesario contar con
los siguientes recursos:
 Materiales: proyector, documentos guías, pizarra,
marcadores de pizarra y demás material didáctico.
 Instalaciones: aula de capacitación del Instituto de
Informática de la UNSJ.
 Humanos: un coordinador general, dos instructores,
un asesor ingeniero de software y un asesor
estadístico.
PLANIFICACIÓN DEL TALLER PRÁCTICO
El taller práctico de aprendizaje de métodos de estimación
del tamaño funcional del software se desarrollará, para cada
uno de los grupos, G1 y G2, en 4 sesiones secuenciales, que
se detallan a continuación:
Sesión 1: Consistirá en la enseñanza teórica de uno
de métodos en cuestión para que el alumno sea capaz de
aplicarlo a un caso práctico. Luego se trabajará con una
práctica que permita afianzar los conceptos teóricos
expuestos con anterioridad. Esta sesión tendrá una duración
de 3 horas aproximadamente. A los sujetos se les proveerá
de guías técnicas instructivas necesarias para lograr la
comprensión de uno de los métodos. Además se contarán
con planillas útiles para el cálculo del método y documentos
que especifiquen los requisitos del sistema utilizado como
caso de estudio.
Sesión 2: En esta sesión se les impartirá a los
sujetos los conceptos teóricos pero del otro método, seguido
de una práctica que como la anterior sesión le permita llevar
aplicar los conceptos vistos pero con este nuevo método.
Para ello los sujetos también contarán con planillas útiles
para el cálculo de la métrica y documentos que especifiquen
los requisitos del sistema utilizado como caso de estudio. El
tiempo asignado a esta sesión será de 3 horas
aproximadamente. Al finalizar la sesión se realizará un test
evaluativo mediante el uso de cuestionarios, con el fin de
determinar el nivel de conocimiento adquirido por los
estudiantes y actuar en consecuencia.
Sesión 3: En esta etapa los sujetos del experimento
llevarán a cabo la medición del tamaño funcional de un
sistema propuesto con uno de los métodos propuestos. La
duración estimada es de 3 horas aproximadamente.
Sesión 4: Para este caso los sujetos del experimento
llevarán a cabo la medición del tamaño funcional del
software pero con el otro método con el cual se los ha
adiestrado. La duración estimada es de 3 horas
aproximadamente.
Se les proveerá del material necesario para poder llevar a
cabo los objetivos de cada sesión. Para el caso del método
FPA se proveerá la narrativa que especifique los
requerimientos del sistema propuesto, posibles pantallas del
sistema, planillas necesarias para el cálculo de la métrica y
archivos lógicos.
Para el método MKII se proporcionará a los alumnos de la
narrativa que especifique los requerimientos del sistema
propuesto, diagrama de casos de uso, documento con los
escenarios del sistema, archivos lógicos y las planillas
necesarias.
Al finalizar la sesión 3 y 4 se procederá a recolectar los
resultados, obtenidos por cada individuo, para su posterior
análisis.
Además a cada alumno se le entregará una encuesta final,
con el propósito de obtener información adicional que
complete los resultados del experimento.
CONCLUSIÓN
El diseño experimental presentado reconoce los avances
alcanzados en el campo de la Ingeniería de Software
Empírica y basa su fortaleza en un serio estudio estadístico,
lo cual aumenta las posibilidades de arribar a conclusiones
científicamente correctas sobre el tema abordado.
La participación de alumnos avanzados en el experimento,
en lugar de ingenieros de software provenientes de la
industria, puede observarse como una debilidad del
experimento. No obstante existen probanzas que los
resultados obtenidos en experimentos con estudiantes
avanzados, analizados correctamente [5] [6], son de gran
utilidad para obtener evidencias o indicios importantes que
luego pueden ser seriamente trasladados a la industria.
Adicionalmente, los estudiantes participantes se benefician
en su formación académica al obtener aprendizaje adicional
y fuera del marco formal de la carrera de grado.
El presente trabajo presenta una propuesta de diseño que
tiene la ventaja de poder ser replicado en otras universidades
como un paquete experimental en sí mismo. Estas
replicaciones incrementarán las posibilidades de arribar a
conclusiones más certeras sobre la temática propuesta. Estas
replicaciones son necesarias ya que contamos con un cuasi-
experimento, debido que se trabaja con sujetos (alumnos)
elegidos por conveniencia y no aleatoriamente [7].
Como trabajo futuro se planea realizar el experimento dando
divulgación a los resultados con el fin de motivar a otros
grupos de investigación a replicar esta experiencia.
 ACKNOWLEDGMENT
Este trabajo fue financiado por el proyecto
Adaptación de Modelos Internacionales de Procesos de
Software a Organizaciones Locales Productoras de Software
(AMIPROSOFT), ejecutado en el Instituto de Informática,
Facultad de Ciencias Exactas, Físicas y Naturales de la
Universidad Nacional de San Juan.
Agradecemos la colaboración de los profesores
Alicia Aballay, Laura Aballay y Carina Ramos, miembros
del proyecto que aportaron valiosas ideas al presente trabajo.

REFERENCES

[1] Sergio Eduardo Durán Rubio: “Puntos por Función: una métrica
estándar para establecer el tamaño del software. Boletín de Política
Informática, número 6
2003,www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/
Articulos/tecnologia/puntosxfuncion.pdf
[2] Martin Shepperd: “Empirically- based software Engineering”,
capítulo del Libro UPGRADE Vol. IV, issue no. 4, August 2003 -
Software Engineering - State of an Art. Available at:
http://www.upgrade-cepis.org
[3] Barbara A. Kitchenham, Shari Lawrence Pfleeger, David C.
Hoaglin, Jarrett Rosenberg: Preliminary Guidelines for Empirical
Research in Software Engineering. IEEE Transactions on Software
Engineering, vol. 8, NO 8 (2002).
[4] Douglas C. Montgomery: Diseño y Análisis de Experimentos. Ed.
Iberoamérica México 1991.
[5] Jeffrey Carver, Letizia Jaccheri, Sandro Morosca, Forrest Shull,
Carver J., Jaccheri L., Morasca S., and Shull F., "Issues in using
students in empirical studies in software engineering education", In
Proceedings of 2003 International Symposium on Software Metrics
(METRICS 2003), Sydney, Australia, September 2003, pp. 239-249.
Available at: http://fc-
md.umd.edu/fcmd/papers/EsEEducation_(final).pdf
[6] Walpole, Ronald E.: Probabilidad y estadística para ingenieros.
Editorial Prentice Hall, Hipanoamericana, S.A., 6° edición, México
1999.
[7] Campbell Donald T. Stanley Julian C.: Experimental and Quasi-
Experimental Designs for Research. Houghton Mifflin Company
Boston. 1999.

View publication stats