Vous êtes sur la page 1sur 6

MODELO DE PRODUCTIVIDAD BASADO EN COMPONENTES PARA LA

FBRICA DE SOFTWARE
Pedro S. Castaeda Vargas
1
, Luis A. Guevara Sandoval
2


Sinopsis: Todo proyecto de desarrollo de software consume tiempo y esfuerzo en cada una de las etapas que
lo conforman. Es clara entonces, la necesidad de contar con buenos estimadores para estas variables, lo cual
implica establecer cules son los factores que influyen directa e indirectamente en ellas. En muchas
organizaciones orientadas a objetivos y de ellas las que estn especializadas en la construccin de software bajo
diferentes plataformas, la gestin se preocupa por ser eficaz y no necesariamente eficiente, lo cual conlleva a
que no se preocupen por la productividad de los recursos asignados y por su homologacin, de manera que se
pueda comparar distintas lneas de produccin de tecnologas y plataformas distintas. Es a partir del ingreso a
un mundo globalizado que las organizaciones ven que para poder desarrollarse y competir no slo necesitan
ser eficaces sino tambin eficientes, empiezan a cuestionar su actual forma de trabajo, con preguntas como
Estamos utilizando adecuadamente la capacidad del equipo de trabajo? Estamos utilizando las habilidades y
capacidades de todos nuestros colaboradores? Nos estamos midiendo con el mercado o slo de manera
interna? Cunto es el potencial que nuestros recursos podran generar en valor a la organizacin? Y todo ello
confluye en un slo trmino que llamamos PRODUCTIVIDAD, factor que permitir medir cunta es la brecha
entre el potencial de valor que pueden generar nuestros recursos y lo que actualmente estn generando de
manera que el personal est pensando en la innovacin constante y por ende que la organizacin sea
trascendental en el tiempo. Este trabajo busca encontrar un modelo que permita establecer los lineamientos
para la medicin de la productividad y que posteriormente sirva como un factor de estimacin de tiempos.
Palabras Clave: Productividad, Mtricas, Eficiencia, Fbrica de Software, Componentes


Introduccin
Todo proyecto de desarrollo de software consume
tiempo y esfuerzo en cada una de las etapas que lo
conforman. Es clara entonces, la necesidad de
contar con buenos estimadores para estas variables,
lo cual implica establecer cules son los factores
que influyen directa e indirectamente en ellas.
GMD brinda servicios de fbrica de software
3
en
organizaciones pblicas y privadas, generando
productos de software personalizados de acuerdo a
las necesidades del cliente. Este mercado ha sido
durante aos el factor de xito de la organizacin,

1
Ingeniero de Sistemas
Universidad Tecnolgica del Per
pcastanedav@gmd.com.pe

2
Bachiller en Ingeniera de Sistemas
Universidad Nacional de Ingeniera
lguevarasa@gmd.com.pe

3
Fbrica de Software: Denominacin dada al conjunto de actividades que se ejecutan en el proceso de desarrollo de software
sin embargo ante la internacionalizacin y el
ingreso de nuevos competidores al mercado
peruano, es necesario plantearnos una serie de
preguntas como: Estamos aprovechando las
capacidades y habilidades de nuestros
colaboradores para desarrollar un producto de
calidad? Tenemos indicadores que permitan
comparar la productividad de los diferentes
proyectos? Cunto valor generan nuestros
recursos y cunta es la brecha del potencial que
podran generar?
Ante esta pregunta, nos encontramos en un dilema
que an no se ha podido resolver en la industria del
software, como es el uso de una tcnica o
metodologa que permita medir la productividad de
las personas y por ende de la organizacin en
casusticas tan diversas y bajo diversos enfoques
tecnolgicos y metodolgicos. Hasta la fecha, en
la industria del software se han utilizado diversos
mtodos que permiten medir la cantidad de
software producido, siendo los ms conocidos los
mtodos basados en casos de uso [1] y puntos de
funcin [2], pero en muchos casos que se han
aplicado estos mtodos, han devenido en mostrar
resultados que no son coherentes con la realidad, lo
cual genera algunos problemas, tales como:
No se puede conocer la capacidad de
produccin de los colaboradores de una
organizacin.
No se tiene una unidad de medida del software
que permita establecer la eficiencia de un
proyecto ni la comparacin entre proyectos
que involucren diferentes plataformas
tecnolgicas.
No existen indicadores de productividad.
No existe una base para la estimacin de
tiempos para un nuevo desarrollo.
En el siguiente trabajo de investigacin se busca
encontrar una metodologa que permita establecer
un estndar de medicin entre los diferentes
proyectos que interactan en la fbrica de software
de GMD, que por la diversidad de plataformas
tecnolgicas que abarca cada uno, permitir tener
un amplio espectro de informacin que nos
conlleve a la obtencin de un modelo inicialmente
destinado al uso en GMD y posteriormente
escalable a cualquier tipo de organizacin dedicada
al desarrollo de productos de software.
Es por ello que analizando la informacin existente,
se ha realizado un esfuerzo para determinar una
metodologa que permita medir la productividad y
facilite la estimacin de tiempos, establecindose
como unidad mnima de medida el Componente
4

de Software.
Segn Szyperski [3] un componente es una unidad
de composicin de aplicaciones software, que
posee un conjunto de interfaces y un conjunto de
requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con

4
Componente: Lista de objetos medibles y cuantificables que
facilitan la labor de asignacin de tareas al equipo de
programadores
otros componentes de forma independiente, en
tiempo y espacio
Para la elaboracin de la presente investigacin se
ha tomado en consideracin informacin de
proyectos de software del rea de Soluciones de
Negocio (Outsourcing de Aplicaciones) de GMD
como son:
Sistema Integrado de la Administracin
Financiera del Sector Pblico (SIAF SP II)
Ministerio de Economa y Finanzas.
Fbrica de Software SUNAT
Desarrollo y Mantenimiento de Software
(DYM) Oficina de Normalizacin
Previsional
Desarrollo y Mantenimiento de Software
AFP INTEGRA
Desarrollo y Mantenimiento de Software La
Positiva
Meta4
Es por ello, que en el inicio del trabajo se ha
destinado esfuerzo horas hombre en recuperar
informacin de los proyectos pasados, como son el
tamao (en puntos de funcin) y el esfuerzo
(horas).
Actualmente se viene trabajando con alumnos y
docentes del MBA del McDonough School of
Business de Georgetown University a fin de
recopilar informacin de fbricas de software de
EEUU y Europa que permitan extrapolar el alcance
de la metodologa desarrollada en GMD.
Marco Terico
La metodologa Rational Unified Process (RUP)
[4], considera que el porcentaje de duracin de las
fases del desarrollo del software de un proyecto
estn distribuidos de acuerdo a lo mostrado en la
Figura N 01.

Figura N 1: Esfuerzo por fases del Rational Unified Process
Tal como se muestra en la Figura N 1, el mayor
esfuerzo en el desarrollo de software se produce en
la disciplina de programacin, siendo justificable
por ello el hecho de dar inicio a este trabajo en el
hecho de capturar la informacin en un primer
momento sobre este componente, para luego poder
ir extrapolando a las dems disciplinas
(Modelamiento de Negocio, Anlisis, etc.).
Proceso General
El proceso de medicin de la productividad cumple
dos objetivos especficos:
Determinar el nivel de productividad de la
persona, proyecto y rea.
Calibrar los tiempos de programacin reales, a
fin de mejorar la estimacin de tiempos de la
fbrica.
Es por ello que se ha establecido un proceso que
facilite la interaccin de actividades necesarias para
la obtencin de los objetivos indicados
anteriormente. El proceso considera lo siguiente:

Figura N 2: Proceso propuesto
A continuacin, describiremos el modelo
operativo:

5
Orden de Trabajo (OT): Conjunto de requisitos de sistema

Figura N 3: Modelo operativo de fbrica
El cliente determina requisitos funcionales para
un producto de software, siendo ste luego
transformado a requisitos de sistema en la
fbrica de software.
La fbrica de software genera una Orden de
Trabajo
5
(OT), que contiene un conjunto de
requisitos de sistema.
La OT previamente priorizada ingresa al
Componente de Programacin, a fin de que
inicie la atencin.
El Coordinador de Fbrica en base al Catlogo
de Componentes de Software realizar la
descomposicin de los requisitos del sistema
en componentes de software y la asignacin de
los mismos en tareas a los diferentes
participantes de la OT.
El Coordinador de Fbrica al culminar todas las
tareas encomendadas en la OT, proceder a
verificar la integracin del producto (labor
tambin asignada como un componente ficticio
a un recurso integrador de los componentes) y
dar finalizada la atencin de la OT.
Los roles participantes en este proceso son:
Coordinador de Fbrica: Arquitecto de
Soluciones o experto en programacin que
tenga la capacidad de asignar requerimientos
de sistemas en componentes de software, en
base al diseo entregado en la OT, as como
habilidades de gestin de recursos.
Programador: Rol encargado de realizar las
tareas asignadas.
El proceso propuesto utiliza como herramienta de
trabajo para la asignacin de tareas un documento
denominado Catlogo de Componentes de
Software, para cuya elaboracin se ha realizado un
trabajo exhaustivo de bsqueda y recoleccin de
E
n
t
r
a
d
a
s
Orden de
Trabajo (OT)
H
e
r
r
a
m
i
e
n
t
a
s

y

T

c
n
i
c
a
s
Factores de impacto
en el tiempo de
desarrollo de
componentes
Catlogo de
Componentes de
Software
Lmites de Control
S
a
l
i
d
a
s
Orden de
Trabajo (OT)
Finalizada
Lista de
Incidencias
informacin que permita estandarizar los diferentes
componentes de software utilizados en los
diferentes proyectos que se ejecutan en la Fbrica
de Software de GMD
6
, la cual ha conllevado a que
se establezca un trabajo de calibracin de tres (03)
elementos principales:

Figura N 4: Elementos del modelo de productividad
1. Expertos. Se realiz una recoleccin de
informacin de ochenta (80) programadores y
diez (10) arquitectos de soluciones, a fin de
estandarizar tiempos de programacin basado
en las siguientes caractersticas:
Experiencia en desarrollo (meses)
Conocimiento del negocio (meses)
Lenguaje de programacin base
Dominio del lenguaje de programacin
(meses)
Herramienta base
Dominio de la herramienta (meses)
2. Distribucin de Trabajo. Esta distribucin se
realiza en base a una lista de componentes
estandarizada que ha sido recolectada de la
experiencia de los proyectos de software con
una antigedad mayor a dos (02) aos, a fin de
que la data a considerar en esta lista ya est
validada y permita tener una conocimiento ms
certero del desglose del software en
componentes. Para la elaboracin de la lista se
ha considerado lo siguiente:
Componentes
Unidad mnima de desglose del software,
cuya caracterstica principal es ser medible
y cuantificable. Ejemplos de componentes:
En lenguaje de programacin orientada a
objetos:
ID COMPONENTE DESCRIPCIN CATEGORA
01 Integracin
Componente artificial que
corresponde a la integracin
de los dems componentes
en un flujo de programacin.
Artificial
02 Servicio
Componente que contiene las
operaciones transaccionales
de una aplicacin.
Lenguaje de
Alto Nivel

6
Informacin recopilada de los proyectos del rea de Soluciones de
Negocio (AO)
03 Negocio
Componente que contiene las
operaciones de negocio de
una aplicacin
Lenguaje de
Alto Nivel
04 Pantalla con lgica
Este componente
corresponde a una pantalla
que tiene cdigo embebido o
tiene cdigo para manejo de
eventos (Code behind) a
travs de un controlador para
manejar los eventos de la
pantalla.
Lenguaje de
Alto Nivel

En lenguaje estructurado:
ID COMPONENTE DESCRIPCIN CATEGORA
01
Interactivo Data
Entry
Componente programado
para AS400
Cobol/CLP/RPG
02
Online
Actualizadores
Componente programado
para OS390
Cobol/Cics
03 Online Consultas
Componente que contiene
las operaciones de negocio
de una aplicacin
Cobol/Cics
Factores
Son elementos externos que afectan los
tiempos de desarrollo de los componentes,
habindose identificado los siguientes:
- Complejidad (simple, medio,
complejo).
- Lenguajes de Programacin.
- Framework/Tecnologa.
- Estndares de Programacin.
- Tipo de Proceso (mantenimiento,
desarrollo).
- Tipo de Tarea (creacin,
modificacin).
- Herramienta Base.
- Retrabajo.
Ejemplo de factores. En el siguiente cuadro
se considera que el lenguaje de
programacin es JAVA y los criterios para
definir la complejidad estn definidas en
base a los datos de entrada y las
validaciones en cada una de ellas.
COMPONENTE
FACTOR: COMPLEJIDAD
Simple (S) Medio (M) Complejo (C)
Pantalla con lgica
De 1-5
datos de
entrada.
Una tabla
para
mostrar
como
resultado
de hasta
10 campos
de salida.
De 6-10
datos de
entrada.
Validacion
es cruzadas
de campos
de
formulario
con
validacin
Java.
Paginacin
De 11 a ms datos
de entrada.
Validaciones
cruzadas de
campos de
formulario.
Paginacin.
Uso de taglibs.
Uso de Layers.
Uso de Frames,
iframes.
3. Mtricas. Indicadores que permiten medir la
productividad por persona, proyecto y rea. Se
han establecido las siguientes mtricas:
INDICADOR PERSONA FBRICA
Productividad






Eficiencia
(. )


(. )


El proceso de calibracin considera la
recoleccin de informacin de manera
permanente, de tal manera de permitir que este
modelo sea usado como una herramienta de
estimacin de tiempos.
Implementacin y Resultados del Modelo
Para la elaboracin del modelo se ha contemplado
dos etapas:
a. Etapa 1 Diseo del modelo. En esta etapa
se ha realizado la recoleccin de data histrica de
proyectos de software con una antigedad mayor a
dos (02) aos. El objetivo en esta etapa ha sido la
obtencin de un modelo estadstico inicial. La
tcnica utilizada ha sido regresin lineal mltiple.
Al utilizar la tcnica de regresin lineal mltiple, se
han determinado los factores que eran
estadsticamente significativos sobre una muestra
de 1799 observaciones y logrando determinar un
modelo predictivo apropiado que se muestra a
continuacin:
= (0,44 ) + (0,35 ) (0,39 ) (0,23
) (0,45 ) (0,043 )
+ (0,13 ) +5,83
Donde:
T: Tiempo de construccin de componente
(en horas)
C: Complejidad (1: Simple, 2: Media, 3:
Complejo)
EP: Estndares de Programacin (1:
Tiene, 0: No tiene)
ED: Experiencia en Desarrollo (en meses)
CN: Conocimiento del Negocio (en meses)
DLP: Dominio del lenguaje de
programacin (en meses)
DT: Dominio de la Tecnologa (en meses)
CH: Conocimiento de la herramienta de
desarrollo (en meses)

b. Etapa 2 Validacin y calibracin del
modelo. En esta etapa se ha considerado la
validacin del modelo en un proyecto en ejecucin,
y con los resultados reales, realizar un proceso de
calibracin, a fin de ir ajustando las variables del
modelo inicial. En esta etapa se ha tenido como
objetivo que el modelo pueda brindar una
estimacin de tiempos con un margen de error de
12%.
Para la validacin del modelo estadstico inicial se
eligi al Proyecto SIAF SP II MEF, por reunir
caractersticas comunes a todos los proyectos y por
tener una estructura organizacional que garantizaba
la fiabilidad de la data obtenida. Algunas de las
caractersticas del proyecto se mencionan a
continuacin:
Poco conocimiento del negocio, debido a que
la organizacin no haba gestionado proyectos
anteriores orientados a la formulacin del
presupuesto pblico.
Tecnologa nueva, ya que la implementacin
implicaba el desarrollo de un producto de
software basado en tecnologas SOA-BPM.
Herramientas de desarrollo nuevas, ya que las
herramientas a utilizar deberan estar basadas
en la suite de desarrollo IBM WebSphere.
La informacin obtenida de este proyecto ha sido
durante un perodo de 18 meses, lo cual ha
permitido realizar los ajustes en el modelo inicial,
aplicando la tcnica de regresin lineal mltiple en
diferentes momentos.
Los resultados obtenidos se muestran a
continuacin:
Para la estimacin de tiempos:
Mdulo
Casos de
Uso (das)
Puntos de
Funcin
(das)
Componentes
(das)
Real
(das)
Administracin
de Clasificadores
65 80 101 114
Marco Lgico 35 47 60 55
Formulacin
Anual
154 110 120 135
Formulacin
Plurianual
57 67 80 75
Seguridad 25 15 28 35
Del cuadro anterior, se ha podido obtener las
desviaciones que han tenido cada una de las
metodologas utilizadas en la evaluacin:
Mdulo
Casos de
Uso (%)
Puntos de
Funcin (%)
Componentes
(%)
Administracin
de Clasificadores
43% 30% 11%
Marco Lgico 36% 15% -9%
Formulacin
Anual
-14% 19% 11%
Formulacin
Plurianual
24% 11% -7%
Seguridad 29% 57% 20%


Figura N 5: Desviaciones por metodologa aplicada
Tal como se puede visualizar en la Figura N 5, las
estimaciones generadas por el modelo propuesto
han tenido menos desviacin, notndose que los
datos estimados se estn centrando en un rango de
11%, valor que cumple los objetivos trazados en
el proyecto.
En el caso de las estimaciones que han pasado el
objetivo de 12%, se ha realizado un anlisis de
esta informacin, a fin de conocer los factores que
han generado este tipo de valores, habindose
encontrado algunas consideraciones como:
Cambios que no han sido gestionados
adecuadamente, y por lo tanto no se realiz una
reestimacin.
Los tiempos reales han considerado no slo
tiempos de desarrollo, sino de anlisis u otra
actividad que no era parte del objetivo del
estudio.
Para la medicin de la productividad
En el siguiente cuadro se presenta una muestra de
la data obtenida (produccin real) por los diferentes
proyectos, que ha permitido establecer la cantidad
de componentes que puede desarrollar un
programador por hora (1.95 componentes de
software), pudindose extrapolar para diferentes
perodos de tiempo.
Productividad
Real
Proyectos de Software
Perodo DYM Horizonte MasterCard MEF Meta4 Total
Semana 1 0.20 0.87 0.39 1.65 7.37 1.93
Semana 2 0.03 2.50 4.10 2.61
Semana 3 0.58 0.50 2.27 1.98
Semana 4 4.18 0.67 1.06 2.21
2.18
Semana 5 2.94 0.63 1.54
Semana 6 0.41 0.57 0.53
Semana 7 0.33 0.50 0.42
Total general 2.01 0.61 0.62 2.17 6.76 1.95
Si extrapolamos esta informacin para un da, se
puede concluir que un programador estara en la
capacidad de producir aproximadamente 16
componentes de software.
Conclusiones
El modelo permite determinar la productividad
de manera objetiva en base a un modelo
estadstico autoregulable en el tiempo.
El modelo ha permitido establecer lmites de
control, que son los valores mnimos y
mximos sobre los cuales se debera medir la
productividad de la fbrica.
El modelo permitir realizar de manera fiable
la estimacin de tiempos de la fbrica.
Recomendaciones
Introducir en el modelo propuesto, la
informacin de otras fbricas de software, a fin
de hacer escalable el modelo haca otras
organizaciones.
Incorporar en el modelo, las actividades de las
dems disciplinas de desarrollo de software que
no han sido consideradas en esta fase inicial.
Automatizar el proceso establecido en el
modelo, a fin de facilitar la recoleccin de
datos.
Formar un equipo encargado de monitorear el
proceso, de tal manera que realice la
calibracin de la informacin generada en los
proyectos.
Utilizar otras tcnicas matemticas que
permitan incrementar el nivel de precisin en la
estimacin de tiempos, de tal manera que se
reduzca el margen de error plasmado en los
objetivos del proyecto ( 12%)
Bibliografa
[1] Roy K. Clemmons. (2006). Project estimation
with Use Case Points. EEUU, Crosstalk: The
Journal of Defense Software Engineering.
[2] Jones, C. 1987. A Short History of Function
Points and Feature Points. Software Productivity
Research Inc. USA.
[3] Karlsruhe, Germany, October 1417
Michael R.V. Chaudron, Clemens Szyperski, Ralf
Reussner, Component-Based Software
Engineering Proceedings, 11th International
Symposium (CBSE 2008), (Eds.)
Springer, LNCS 5282, ISBN 978-3-540-87890-2,
October 2008
[4] Philippe Kruchten (2003). The Rational Unified
Process: An Introduction, Third Edition.