T4 Anexo1 Analisis de Esfuerzo

Anexo 1. Análisis de
Esfuerzo
Ciclo 3
2010
Especialización en construcción de software
Universidad de los andes
Bogotá 2010
Andrés González. 201018063
Julián Morales. 200213074
Carlos Criales. 200925612
José Daniel García. 200818257
Robinson De La Hoz. 201018033
Haiver Páez. 201018119
TABLA DE CONTENIDO
1.
Introducción ...................................................................................................................................... 3
2.
Calculo del Esfuerzo por Modulo ...................................................................................................... 4
2.1
Selección de factores de Escala ............................................................................................ 5
2.1.1
Factor PREC (Precedencia) ............................................................................................ 5
2.1.2
Factor FLEX (Flexibilidad en el desarrollo) .................................................................... 6
2.1.3
Factor RESL (Arquitectura y Determinación del Riesgo) ............................................... 7
2.1.4
Factor TEAM (Cohesión del Equipo) ............................................................................. 7
2.1.5
Factor PMAT (Cohesión del Equipo) ............................................................................. 8
2.2
Factores Multiplicadores de Esfuerzo ................................................................................. 10
2.2.1
Factores del Producto ................................................................................................. 10
2.2.1.1 RELY (Confiabilidad Requerida)................................................................................ 10
2.2.1.2 DATA (Tamaño de la base de datos) ........................................................................ 10
2.2.1.3 CPLX (Complejidad del producto) ............................................................................ 11
2.2.1.4 RUSE (Requerimientos de reusabilidad) .................................................................. 12
2.2.1.5 DOCU: Documentación acorde a las diferentes etapas del ciclo de vida ................ 12
2.2.2
Factores de la plataforma ........................................................................................... 13
2.2.2.1 PVOL (Volatilidad de la plataforma)......................................................................... 13
2.2.2.2 STOR (Restricción del almacenamiento principal) ................................................... 14
2.2.2.3 TIME (Restricción del tiempo de ejecución) ............................................................ 14
2.2.3
Factores del personal .................................................................................................. 15
2.2.3.1 ACAP (Capacidad del analista) ................................................................................. 15
2.2.3.2 PCAP (Capacidad del programador)......................................................................... 16
2.2.3.3 PCON (Continuidad del personal) ............................................................................ 16
2.2.3.4 AEXP (Experiencia en la aplicación) ......................................................................... 17
2.2.3.5 PEXP (Experiencia en la plataforma) ........................................................................ 17
2.2.3.6 LTEX (Experiencia en el lenguaje y las herramientas) .............................................. 18
2.2.4
Factores del proyecto ................................................................................................. 19
2.2.4.1 TOOL (Uso de herramientas de software) ............................................................... 19
2.2.4.2 SITE (Desarrollo multisitio)....................................................................................... 20
2.2.4.3 SCED (Cronograma requerido para el desarrollo) ................................................... 20
2.3
Calculo del esfuerzo para el modulo ................................................................................... 21
1. Introducción
Es muy importante estimar dentro de la planificación de los proyectos con cierto grado de certeza los
recursos necesarios para cumplir con las tareas de desarrollo de los componentes de un sistema. A pesar
de que la estimación no es una ciencia exacta, no podemos prescindir de esta pues un error en la
estimación puede conducir a resultados adversos.
Con el fin de aplicar un modelo de estimación hemos optado por adoptar el esquema de COCOMO II que
soporta su modelo en aspectos tales como:
-
Tamaño del software
Factores de costo. Relacionados con la naturaleza del producto, hardware, capacidades de
personal y características del proyecto
Factores de escala. Explica las economías y deseconomías que se producen a medida que el
software aumenta su tamaño
La estimación de costos tiene varios usos en la administración de proyectos
-
Determinar la cantidad de personas necesarias para desarrollar un proyecto y así establecer un
cronograma adecuado
Controlar el progreso del proyecto teniendo como punto de validación un cronograma
correctamente definido
Métricas para medir los niveles de cumplimiento
El modelo seleccionado tiene como características las siguientes
-
Construir una base de datos de proyectos de software que permita la consulta y calibración de
futuros proyectos, con el fin de incrementar la precisión en la estimación
Implementar una herramienta que permitiera automatizar y soportar la configuración del
modelo
Provee un marco analítico y cualitativo que mediante un conjunto de herramientas y técnicas
evaluara el impacto de las mejoras tecnológicas en un sistema teniendo en cuenta costos y
tiempos en las etapas del ciclo de vida de un proyecto
Para nuestro caso en particular utilizamos la herramienta COSTAR 7.0 que nos permite en forma sencilla
y automatizada proveer la información base y las características del proyecto y los recursos para en
última instancia realizar un cálculo de esfuerzo en número de recursos por mes.
2. Calculo del Esfuerzo por Modulo
Para nuestro proyecto particular del Banco de los Alpes, partimos de la premisa de la estimación
basados en las líneas de código proyectadas por nuestros expertos en desarrollo. Como parte de nuestra
estrategia de desarrollo se estimaron para cada uno de los módulos de la solución la estimación de LOCs
por componente (clase, paquete). De tal forma que a continuación se describe el esfuerzo estimado en
recurso por mes. Para este informe en particular se toma como ejemplo el cálculo del esfuerzo para el
modulo de cargue de archivos que es el más dispendioso porque dentro de las aplicaciones del Banco de
los Alpes no se encuentra ninguna que cumpla con su funcionalidad, lo que significa que debe
desarrollarse desde cero.
El modulo de cargue permite el cargue de la información de prospectos que son la materia prima que
utiliza el proceso de originación de crédito del banco para el análisis de personas como potenciales
clientes del banco para ofrecerle productos de crédito.
El cargue de la información de prospectos se realiza a través del cargue de archivos planos que son
entregados por entidades tales como: Supermercados, Inmobiliarias y Concesionarios de automóviles.
Componente
LOCs Estimadas
ArchivoAbstracto.java
ArchivoConsecionarios.java
ArchivoConstructora.java
ProspectosEntityFacade.java
ProspectosEntityFacadeLocal.java
PersistirInformación.java
ProspectosEntity.java
ProspectosEntiyPK.java
cliente.java
CargaArchivos.java
TOTAL LOCs
10
300
300
200
15
100
120
50
120
100
1315
Ahora a través de la herramienta comenzamos el proceso del cálculo del esfuerzo:
Primero la herramienta puede ser utilizada para proveer tanto puntos de función como líneas de código.
Para nuestro caso hemos estimado 1315 líneas de código
2.1 Selección de factores de Escala
Los modelos de estimación de costos analizan dos aspectos antagónicos que influyen notablemente en
los procesos de estimación, la economía y deseconomía de escala. La economía de escala abarca
factores que hacen más eficiente la producción de software en gran escala. Es frecuente lograr
economía en proyectos de gran envergadura, gracias a la inversión en software de propósitos
específicos que mejoran la productividad, tales como herramientas de testeo, librerías de programas,
preprocesadores, pos procesadores. Ahora bien, estamos frente a una deseconomía de escala cuando al
incrementarse el tamaño del producto se produce una considerable disminución de la productividad. El
aumento de la cantidad de personas que conforman el equipo de desarrollo generalmente provoca
problemas de integración, que sumados a los conflictos personales, las diferencias en la filosofía y
hábitos de trabajos producen deseconomía de escala.
2.1.1
Factor PREC (Precedencia)
Este factor evalúa la experiencia del equipo de trabajo en proyectos similares, tanto a nivel del
hardware, software y tipo de negocio.
Para este caso seleccionamos “Algún precedente” debido a que a pesar de que se tiene experiencia en
el sector bancario y en el desarrollo de aplicaciones web bajo la tecnología JAVA, no se tiene experiencia
en la parte de la implementación de un motor de procesos.
2.1.2
Factor FLEX (Flexibilidad en el desarrollo)
Este considera el nivel de exigencia en el cumplimiento de los requerimientos, los tiempos y
especificaciones de interfaz predefinidos.
Para este caso seleccionamos “Relajación ocasional” debido a que los requerimientos a pesar de que son
claros concretos, ofrecen alguna flexibilidad respecto de la forma en que pueden ser analizados,
modelados e implementados.
2.1.3
Factor RESL (Arquitectura y Determinación del Riesgo)
Este involucra aspectos relacionados al conocimiento de los ítems de riesgo y al modo de abordarlos
dentro del proyecto. Así mismo tiene en cuenta aspectos tales como la definición de la arquitectura,
arquitecturas de software disponibles y factores claves de arquitectura como interfaces de usuario,
hardware, tecnología y desempeño.
Para este ítem seleccionamos “Alto” porque consideramos que la solución tiene una base de análisis de
arquitectura de componentes importante, así como también tiene un componente de planeación de
riesgos ciclo a ciclo que permite prever y mitigar el riesgo.
2.1.4
Factor TEAM (Cohesión del Equipo)
Este tiene en cuenta las dificultades de sincronización entre los participantes del proyecto: usuarios,
desarrolladores, líderes, etc. Estas dificultades pueden surgir por diferencias culturales, dificultad en la
conciliación de objetivos, falta de experiencia y familiaridad con el trabajo en equipo.
Para este caso seleccionamos “Nominal” puesto que si bien existe compatibilidad cultural, han existido
también algunas fallas en la conciliación y definición de objetivos y no existe una alta experiencia en el
trabajo en equipo.
2.1.5
Factor PMAT (Cohesión del Equipo)
El procedimiento para determinar el factor PMAT se basa en el Modelo de CMM propuesto por el
Software Engineering Institute. Existen dos formas de calcularlo:
La primera captura el nivel de madurez de la organización, resultado de la evaluación según CMM y
asignándole el valor correspondiente según el nivel de maduración. Para nuestro caso seleccionamos un
nivel “Nominal” porque tenemos un proceso de desarrollo de software definido y estructurado, con
entregables específicos que se están refinando en cada fase del proceso.
Sin embargo para este factor y teniendo en cuenta una segunda alternativa para el cálculo del PMAT,
también utilizamos un análisis de 18 áreas de proceso y la siguiente fórmula:
PMAT = 5 − [∑18
𝑖=1(𝐾𝑃𝐴%𝑖/100) ∗ 5/18]
Areas Clave
Administración de
Requerimientos
Planificación del Proyecto de
Software
Seguimiento y supervisión del
Proyecto de Software
Administración de
Subcontratos
Aseguramiento de la Calidad
Casi
siempre
(90%)
A menudo
(60%)
La mitad de las veces
(40-60%)
Ocasionalmente
(10 - 40%)
Casi nunca
(<10%)
No se
aplica
No se
conoce
40
40
60
60
60
60
0
40
Administración de la
Configuración
Objetivo del Proceso de
Organización
Definición del Proceso de
Organización
Programa de Entrenamiento
Sumatoria
0
40
50
50
60
60
60
60
40
40
Administración Integrada de
Software
0
0
Ingeniería del Producto
0
0
Coordinación entre Grupos
60
60
Rev isión por Pares
Administración Cuantitativa
60
60
40
40
40
40
Administración de la Calidad
Prevención de Defectos
Administración de las
Tecnologías de Cambio
Administración de los Procesos
de Cambio
10
10
0
0
0
620
PMAT
3.277777778
2.2 Factores Multiplicadores de Esfuerzo
El esfuerzo nominal de desarrollo de un proyecto de software se ajusta para una mejor estimación
mediante factores que se clasifican en cuatro áreas: Producto, Plataforma, Personal y Proyecto
Estos son los principales factores que afectan el esfuerzo requerido para completar un proyecto basado
en las cuatro áreas antes mencionadas. Estos factores se fijan para describir como su proyecto se
diferencia de cualquier otro ejecutado con anterioridad.
Cada factor tiene un impacto multiplicador sobre el esfuerzo
2.2.1
Factores del Producto
Estos están asociados a las restricciones y requerimientos del producto a desarrollar
2.2.1.1 RELY (Confiabilidad Requerida)
Este relacionado con los requerimientos que exigen que el producto cumpla con la funcionalidad para la
que se desarrollo y cumpla con el tiempo de ejecución que se le fijo.
Para nuestro caso se selecciono “Nominal” pues la presencia de una falla es fácilmente recuperable por
el usuario
2.2.1.2 DATA (Tamaño de la base de datos)
El esfuerzo requerido para desarrollar un producto de software está relacionado con el tamaño de la
base de datos asociada. Un ejemplo que marca la importancia de esta influencia es el esfuerzo que
consume la preparación de los lotes de prueba que se usan en el testeo del producto.
D/P = 250000 bytes / 1315 LOCs = 190.11
Este resultado nos ubica en “Alto”, teniendo en cuenta que un archivo de cargue tiene 2500 registros en
donde cada registro tiene en promedio 100 bytes de información y el total de líneas estimadas de
código del modulo son 1315.
2.2.1.3 CPLX (Complejidad del producto)
Analiza la complejidad de las operaciones empleadas en el producto, clasificadas en operaciones: de
control, computacionales, dependientes de los dispositivos, de administración de datos y de
administración de interfaz de usuario.
Para nuestro caso seleccionamos “Alto” debido a la complejidad del código sobretodo a nivel del bus de
servicios en donde ninguno de nosotros tiene experiencia y adicionalmente las interfaces en Portal que
hasta el momento son también desconocidas.
2.2.1.4 RUSE (Requerimientos de reusabilidad)
Este factor considera el esfuerzo adicional necesario para construir componentes que puedan ser
reusados dentro de un mismo proyecto o en futuros desarrollos. El incremento del esfuerzo se debe a
que se incorporan tareas inherentes al reuso, tales como: creación de diseños genéricos de software,
elaboración de mayor cantidad de documentación, testeo intensivo para asegurar que las componentes
estén debidamente depuradas, etc.
Para nuestro caso se selecciono un nivel de complejidad “Nominal” debido a que el reuso se da
únicamente a nivel del modulo y no se extiende más allá.
2.2.1.5 DOCU: Documentación acorde a las diferentes etapas del ciclo de vida
Varios modelos de costo de software tienen un factor de costo para representar el nivel de
documentación requerida. En COCOMO II este factor se evalúa en función de la adecuación de la
documentación del proyecto a las necesidades particulares en cada etapa del ciclo de vida.
Para nuestro caso seleccionamos “Nominal” porque en cada fase del proceso de desarrollo se ha
generado la documentación necesaria en aspectos tales como análisis, diseño, planeación
(configuración, pruebas, calidad, riesgos, cronogramas, wbs, etc.)
2.2.2
Factores de la plataforma
Estos factores analizan la complejidad de la plataforma subyacente. La plataforma es la infraestructura
base de hardware y software, lo que también recibe el nombre de máquina virtual. Si el software a
desarrollar es un sistema operativo la plataforma es el hardware, si en cambio se trata del desarrollo de
un administrador de base de datos se considerará como plataforma el hardware y el sistema operativo.
Por ejemplo, la plataforma puede incluir cualquier compilador o ensamblador empleado en el desarrollo
del software.
2.2.2.1 PVOL (Volatilidad de la plataforma)
Este factor se usa para representar la frecuencia de los cambios en la plataforma subyacente.
Para nuestro caso es una plataforma que no tendrá un cambio significativo al menos en 1 año, por lo
tanto la selección es “Baja”
2.2.2.2 STOR (Restricción del almacenamiento principal)
Este factor es una función que representa el grado de restricción del almacenamiento principal
impuesto sobre un sistema de software. Cuando se habla de almacenamiento principal se hace una
referencia al almacenamiento de acceso directo, tales como circuitos integrados, memoria de núcleos
magnéticos, excluyendo discos, cintas, etc.
En este caso seleccionamos una opción promedio pues de acuerdo a la carga y software utilizado sobre
las maquinas en las que esta desplegada la solución no se prevé un uso importante de la memoria de
almacenamiento. En vista de que no es muy claro el uso de este recurso y partiendo de las premisas
dadas por el modelo hemos optado por seleccionar “Nominal”.
2.2.2.3 TIME (Restricción del tiempo de ejecución)
Este factor representa el grado de restricción de tiempo de ejecución impuesta sobre el sistema de
software.
En este caso seleccionamos una opción promedio pues de acuerdo a la carga y software utilizado sobre
las maquinas en las que está desplegada la solución no se prevé un uso importante del tiempo de
ejecución. En vista de que no es muy claro el uso de este recurso y partiendo de las premisas dadas por
el modelo hemos optado por seleccionar “Nominal”.
2.2.3
Factores del personal
Estos factores están referidos al nivel de habilidad y conocimientos técnicos que poseen los integrantes
del equipo de desarrollo.
2.2.3.1 ACAP (Capacidad del analista)
Se entiende por analista a la persona que trabaja con los requerimientos, en el diseño global y en el
diseño detallado. Los principales atributos que deberían considerarse en un analista son la habilidad
para el diseño, el análisis, la correcta comunicación y cooperación entre sus pares. En este análisis no se
tiene en cuenta el nivel de experiencia.
En este caso hemos seleccionado “Nominal” en razón al conocimiento adquirido por los integrantes del
equipo en la especialización y en razón a la habilidad previa que cada quien tiene gracias a la labor
desempeñada en sus empresas.
2.2.3.2 PCAP (Capacidad del programador)
Las tendencias actuales siguen enfatizando la importancia de la capacidad de los analistas. Sin embargo,
debido a que la productividad se ve afectada notablemente por la habilidad del programador en el uso
de las herramientas actuales, existe una tendencia a darle mayor importancia a la capacidad del
programador. También se evalúa la capacidad de los programadores para el trabajo en equipo más que
para el trabajo individual, resaltando las aptitudes para comunicarse y cooperar mutuamente.
Para nuestro caso hemos seleccionado “Baja” pues la productividad no se ve tan afectada por la
habilidad del programador sino más bien por la carga de trabajo de tipo analítico y de diseño que
requiere la solución.
2.2.3.3 PCON (Continuidad del personal)
Este factor mide el grado de permanencia anual del personal afectado a un proyecto de software.
Para nuestro caso en el que el proyecto es de un año y en el que el personal sabemos que permanece
hasta el final, el porcentaje de permanencia es “Muy Alto”.
2.2.3.4 AEXP (Experiencia en la aplicación)
Este factor mide el nivel de experiencia del equipo de desarrollo en aplicaciones similares.
Teniendo en cuenta de que al menos 2 de los integrantes ya tienen experiencia con el sector financiero,
el nivel de experiencia para este ítem es “Alto”.
2.2.3.5 PEXP (Experiencia en la plataforma)
COCOMO afirma que existe gran influencia de este factor en la productividad. Reconociendo así la
importancia del conocimiento de nuevas y potentes plataformas, interfaces gráficas, base de datos,
redes, etc.
Para nuestro caso no se tiene experiencia particularmente en PORTAL ni en el motor de procesos WID
que conforman un gran porcentaje de la solución. Por lo anterior este ítem lo calificamos como “Bajo”
puesto que la única experiencia que se ha adquirido es en la especialización.
2.2.3.6 LTEX (Experiencia en el lenguaje y las herramientas)
Este factor mide el nivel de experiencia del equipo en el uso del lenguaje y herramientas a emplear. El
desarrollo de software, hoy en día, incluye el uso de herramientas que soportan tareas tales como
representación de análisis y diseño, administración de la configuración, extracción de documentación,
administración de librerías, y chequeos de consistencia. Es por ello que, no sólo es importante la
experiencia en el manejo del lenguaje de programación sino también en el uso de estas herramientas,
ya que influye notablemente en el tiempo de desarrollo.
Para nuestro caso no se tiene experiencia particularmente en PORTAL ni en el motor de procesos WID
que conforman un gran porcentaje de la solución. Por lo anterior este ítem lo calificamos como “Bajo”
puesto que la única experiencia que se ha adquirido es en la especialización.
2.2.4
Factores del proyecto
Estos factores se refieren a las condiciones y restricciones bajos las cuales se lleva a cabo el
proyecto.
2.2.4.1 TOOL (Uso de herramientas de software)
Las herramientas de software se han incrementado significativamente desde la década del 70. El tipo de
herramientas abarca desde las que permiten editar y codificar hasta las que posibilitan una
administración integral del desarrollo en todas sus etapas.
Para nuestro caso hemos utilizado herramientas que se acomodan al ciclo básico de desarrollo de
software tanto en la parte de planificación como de desarrollo y pruebas. Como son herramientas
promedio hemos seleccionado “Nominal”
2.2.4.2 SITE (Desarrollo multisitio)
La determinación de este factor de costo involucra la evaluación y promedio de dos factores, ubicación
espacial (disposición del equipo de trabajo) y comunicación (soporte de comunicación).
En este caso hemos seleccionado “Alta” debido a que el equipo de desarrollo se encuentra en la misma
área (ciudad) y contamos con medios electrónicos para la comunicación (email, skype, teléfonos
celulares)
2.2.4.3 SCED (Cronograma requerido para el desarrollo)
Este factor mide la restricción en los plazos de tiempo impuesta al equipo de trabajo. Los valores se
definen como un porcentaje de extensión o aceleración de plazos con respecto al valor nominal.
Acelerar los plazos produce más esfuerzo en las últimas etapas del desarrollo, en las que se acumulan
más temas a determinar por la escasez de tiempo para resolverlos tempranamente. Por el contrario una
relajación de los plazos produce mayor esfuerzo en las etapas tempranas donde se destina más tiempo
para las tareas de planificación, especificación, validación cuidadosa y profunda.
Para este caso hemos seleccionado “Alta” debido a que con respecto al valor nominal del 100% los
plazos para la entrega de desarrollo se han extendido para poder concluir los productos.
2.3 Calculo del esfuerzo para el modulo
Como conclusión del análisis con el modelo COCOMO y gracias al análisis detallado por factores, la
construcción del modulo para el cargue de archivos demanda un esfuerzo de 4.5 personas por mes,
como se puede ver en el reporte que automáticamente genera la herramienta COSTAR.
3. Bibliografía
-
http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/teo/8/cocomo2-apuntes.pdf
http://www.softstarsystems.com/main.htm