UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE

EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

Planificación de una revisión literaria

Mecanismos de estimación ágil del esfuerzo requerido para el desarrollo de un sistema

informático

Necesidades de la revisión sistemática

Esta investigación es necesaria ya que la estimación del esfuerzo requerido para el desarrollo de
un sistema informático es fundamental para que este pueda desarrollarse adecuadamente, una
estimación errónea o el no hacer una estimación de esfuerzo previa a la inicialización del proyecto
puede provocar que el mismo finalice mucho tiempo después de lo estimado o que nunca se
termine, además de que los recursos que se estimaron para el proyecto no serían los suficientes,
de manera que el proyecto colapsaría trayendo problemas muy graves a la empresa.

Fortalezas y debilidades

Fortalezas:

- Las fuentes utilizadas durante la investigación no son muy antiguas por lo que su
información aun es válida.
- Se encontró información experimental que nos permite evaluar cada uno de los métodos
o mecanismos.

Debilidades:

- Existen pocos métodos desarrollados específicamente para estimar esfuerzos

- Se encontraron métodos que datan de mucho tiempo y que ya no son tan utilies a
comparación de otros métodos nuevos.

Relevancia practica de lo que vamos a investigar:

Los resultados de nuestra investigación permitirán que otros investigadores puedan identificar la
utilidad entre los diferentes métodos de estimación de esfuerzos para desarrollar un proyecto de
software, de la misma forma team managers o estudiantes podrán valerse del documento para
realizar sus proyectos y determinar cómo desarrollar el mismo.
 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

Formación de preguntas de investigación

Tabla 1. Preguntas de investigación

N° Preguntas Motivación
1 ¿Qué variables además del esfuerzo estiman cada uno de los métodos Determinar la información que
hallados? podemos obtener de cada uno de los
métodos que puede ser útil para
desarrollar un proyecto de ing de
software
2 ¿Se especifica si en el método se realiza documentación? Determinar si la documentación se
realiza en cada método para
determinar su utilidad
3 ¿Qué tan preciso es el método para estimar el esfuerzo? Identificar la precisión de cada
método y destacar el mejor de ellos
4 ¿Qué aplicaciones ha tenido cada uno de estos métodos? Determinar en qué casos se puede
utilizar cada uno de los métodos
5 ¿Qué factores influyen en la estimación del esfuerzo en cada uno de los Identificar las variables que pueden
métodos? aumentar o disminuir el esfuerzo
dentro de nuestro proyecto

Mecanismos de estimación ágil explorados y parámetros que definen su exactitud

FUENTE 1

TITULO: Software Development Effort Estimation based-on multiple classifier system and Lines
of Code

Autores: Hector Velarde ; Cosme Santiesteban ; Ana Garcia ; Jorge Casillas

DOI: 10.1109/TLA.2016.7786379

Se analizan los métodos que se pueden estimar para la estimación de costos de un proyecto
orgánico, semi libre y empotrado.

FUENTE 2

TITULO: An experimental comparison of software effort estimation methods of ORM based

4GL software applications

Autore: Mohd. Owais ; R. Ramakishore

 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

DOI: 10.1109/UBMK.2017.8093382

Métodos de estimación empleados:

COCOMO II: uno de los más conocidos y mejor documentados modelos de algoritmos, con él se
puede estimar: el esfuerzo, el costo y la programación cuando se está planeando un software
nuevo.

COSYSMO: modelo abierto desarrollado en consenso de la corporación de afiliados para las

propuestas de estimación de costos en ingeniería de sistemas. Cuenta con cuatro controladores
de tamaño y catorce multiplicadores de esfuerzo. Los controladores de tamaño representan el
tamaño funcional de la ingeniería de sistemas. Los multiplicadores de esfuerzo representan los
parámetros de contexto que captura la complejidad del entorno del proyecto debajo de cada
equipo de ingeniería de sistemas que esta operando.

FUENTE 3

TITULO: Effort, Duration and Cost Estimation in Agile Software Development

Autor: R. Ramakishore, Mohd. Owais

Date of Conference: 11-13 Aug. 2016

DOI: 10.1109/IC3.2016.7880216

Este Proyecto se propuso un método de estimación algorítmica simple con enfoques heurísticos
(Planning Póker y estimación por analogía) para estimar el esfuerzo, duración y costo de los
proyectos agiles.

Documentación Precisión Variables Otras Factores que Limitaciones

estimables en el características determinan
método la estimación

COCOMO Uno de los Muy alta Costo Permite el Atributos del Factores
mejores 82% Esfuerzo ajuste según el producto. cualitativos son
documentados Programación tipo de Atributos del difíciles de
(software aplicación: ordenador. modelar.
nuevo) orgánica, semi- Atributos del Calibración
separada o personal. utilizando
incrustada Atributos del proyectos
proyecto. exitosos.
 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

Es fácil manipular
el modelo para
obtener los
resultados
deseados
COSYSMO No se especifica No se Costos Modelo abierto
especifica Esfuerzo Está
conformado por
4 controladores
de tamaño y 14
multiplicadores
de esfuerzo
COSTMO- Se realiza con No se Esfuerzo Consiste alguna
4GL reportes y especifica o todos los tres
graficas tipos de
componentes
de interfaces de
usuario.

Planning Se realiza con No se Se definen las Las razones en Complejidad El estimador debe
Póker factores especifica razones que han caso de de la introducir los
heurísticos determinado la diferenciarse se tecnología puntos de la
asignación de discuten con Integración historia
los puntos otros expertos Equipo La velocidad
específicos de la Ubicación de especificado por
historia los miembros los sprints no es
Esfuerzo del equipo exacta
Duración Riesgos El estimador debe
Costo Tasas de inferir los
Estimación Se realiza con No se Esfuerzo Los expertos facturación factores que
por factores especifica Duración hacen afecten el
analogía heurísticos Costo estimaciones proyecto según la
sobre la base de opinión del
la experiencia experto.
previa de
proyectos
anteriores y se
comparan.

EEpred Si tiene Orgánico: Se estima el Se divide en dos Se basa en el Todas las listas
78% esfuerzo niveles, el cual conteo de deben tener una
Semi libre: específicamente el primero se líneas de dimensión igual.
63% basó en una código La frecuencia de
estimación no fuente y la ocurrencia para
tan profunda, puntos de cada punto de
generado asi un fusión. datos X y Y
problema para Está correspondientes.
poder orientado a El valor
solucionarlo en su empleo en predeterminado
el segundo nivel metodologías es 1.
desglosando el ágiles Todos los
mismo elementos deben
ser enteros.
 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

Tipo de amenaza Descripción de la Mitigación de amenazas Estudios que

amenaza encuentran
estas amenazas
Falta de experto Un experto debe Un experto para entender
evaluación evaluar la clasificación su verdadero significado
generada. o concepto.
Reglas para entender su Se deben evaluar las
verdadero significado o reglas de clasificación
significado. generadas.
Capacidad de prueba El investigador debe
estadística baja Uso de nivel de elegir un nivel de
significación significación adecuado
inapropiado al realizar para las pruebas
pruebas estadísticas. La estadísticas, como 0.01 o
elección de un nivel de 0.05 para concluir
significación resultados significativos
inadecuado conducirá a
conclusiones
incorrectas.
Sesgo de validación Los modelos predichos
pueden usar los mismos Uso de validación cruzada
datos para el y múltiples iteraciones
entrenamiento, así para evitar sesgos de
como la validación, lo muestreo. Además, para
que conduce a la obtener resultados
posibilidad de imparciales, los datos de
resultados sesgados. capacitación deben ser
Puede denominarse diferentes de los datos de
sesgo de muestreo prueba

Supuestos de pruebas Un investigador debe

estadísticas no Los datos sobre los que asegurarse de que se
satisfechos se aplica una prueba o cumplan las condiciones
medida estadística de una prueba estadística
particular pueden no paramétrica o debe usar
ser apropiados para una prueba no
cumplir las condiciones paramétrica donde no se
de la prueba. Por cumplen las condiciones
ejemplo, la aplicación necesarias para usar las
de la prueba de análisis pruebas paramétricas.
de varianza (ANOVA)
requiere el supuesto de
la normalidad de los
 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

datos y la
homogeneidad de la
varianza, que puede no
ser cumplida por los
datos subyacentes que
conducen a
conclusiones erróneas.
Efectos de confusión El estudio debe tener en
de las variables No tiene en cuenta el cuenta el efecto de
efecto de confusión del confusión del tamaño de
tamaño de clase en la la clase en la relación
asociación entre entre las métricas y la
métricas y propensión a propensión a la falla al
fallos controlar el tamaño de la
clase y su efecto en la
relación.

Influencia de los No tiene en cuenta la
factores humanos. capacidad o la
capacitación del
programador y otros
factores humanos en la
relación explorada de
las métricas y la
propensión a fallos
Si es posible, el estudio
debe evaluar el efecto de
capacidad o
capacitación del
programador y otros
factores humanos en la
relación causa-efecto de
las métricas y la
propensión a fallas. Sin
embargo, los datos para
evaluar dicha relación son
difíciles de recopilar en la
práctica

Mala interpretación
de conceptos y Las diferentes métricas Las medidas que capturan
medidas. de OO utilizadas como los diversos atributos
variables deben ser bien
independientes pueden entendidas.
no ser bien
comprendidas o
representadas.
Para comparar
Incapacidad de diferentes algoritmos, Para realizar una
generalización en no se tienen en cuenta comparación justa entre
construcciones las diferentes los algoritmos, se debe
relacionadas. configuraciones y los establecer una línea de
detalles internos, como base para evaluar el
 UNIVERSIDAD DE LAS FUERZAS ARMADAS – ESPE
EXTENSIÓN LATACUNGA
DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA
CARRERA DE SOFTWARE

el número de reglas y número de reglas, elegir

las diferentes medidas una medida de calidad
de calidad. Esto adecuada, etc. El uso
conduce a una exclusivo de parámetros
comparación injusta predeterminados no
entre diferentes tiene en cuenta mejores
algoritmos. conjuntos de reglas

Métodos inadecuados El proceso o los Los investigadores deben

de recolección de métodos de verificar específicamente
datos recopilación de datos el proceso de recolección
para la recolección de la de la variable
variable dependiente dependiente. Por
pueden no verificarse ejemplo, las actividades
completamente, lo que de prueba de aceptación
lleva a una recopilación para la colección de
de datos incorrecta fallas.

Uso de una herramienta Verificación manual de la

Fiabilidad de las automatizada para la métrica / variable
herramientas de extracción de métricas dependiente generada
medición. (variables por la herramienta.
independientes) o
variable dependiente

Ajustes Los datos pueden ser Es importante eliminar

experimentales inconsistentes en la módulos incoherentes de
inapropiados. naturaleza. Por un conjunto de datos
ejemplo, en el conjunto para obtener resultados
de datos JM1 de la apropiados.
NASA, ciertos módulos
tienen valores idénticos
para todas las métricas
pero se les asignan
diferentes etiquetas.
Este tipo de datos
puede influir
significativamente en
los resultados