Upload
others
View
12
Download
0
Embed Size (px)
Citation preview
SUBSISTEMA DE REQUERIMIENTOS DE HARDWARE
,,,,,
, ", RAT~CRE_HARO , ,
" , "
,, ,, ,, ,, ,, ,
EaUUNST
Figura 9. : Diagrama de Forrester : Requerimientos de Harct.Nare
Subsistema de Recursos Humanos
Misi6n: Asegurar la optimizacion de la cantidad de ingenieros asignados a
los diferenles proyectos. versus el numero de horas asignadas a cada uno
de los mismos (rendimiento del personal).
145
Proceso biisico operacional: Esta orientado hacia, planeacion de
contrataciones, entrenamientos, terminaci6n de contratos y politicas
salariales.
Resultados Buscados: Informaci6n del personal y mimero de empleados.
Estrategia: Plan ear diferentes altemativas de reclutamiento, selecci6n,
entrenamiento y motivaci6n que Ilenen las expectativas de calidad y que
equilibren los factores inversion salarial y beneficia laboral "
UQUI'lllMIENTOS DE ING(.N1D.Os
Tl\T:f'l IEROS k lJ.c\S!t "''1Al>L1:i
,
Il llhl"HA
~ NiE.-.JIF.MOS An tAt ES EN a. Akl'.A
Figura 10. : Diagrama Causal : Recursos Humanos
146
SUBSISTEMA DE RECURSOS HUMANOS (lNGENIEROS)
", ,
,
PROD R SOFT r- -:-1
Figura 11. : Diagrama de Forrester: Recursos Humanos
Subsistema de Producci6n Efectiva de Software
Misi6n: Asegurar la producci6n optima de software para los diferentes
proyectos (productividad en el desarroll'o del area).
Proceso bAsico operacional: Ejecuci6n de proyectos informaticos del
departamento de sistemas de Tejicondor S.A.
Resultados Buscados: Producci6n efectiva de software.
Estrategia: Generar la menor cantidad de perdidas por proceso de
desarrollo y optimizando las horas asignadas para cada proyecto.
r- PROOUmONEFEC11VA ~
PERDlDA REAL PRODUCCIONI REAL DE PRODUCCION
+~ P8mO"OAS ~ PORPROCESO
DETECCION DE ERRORES
( ~.¢w"!'.tDH"~~
HORAS DE CADA PROYECTO HARDWARE
DISPO 'IDLE
Figura 12 : Diagrama Causal: Producci6n Efectiva de Software
SUBSISTEMA DE PRODUCCION EFECTIVA DE SOFTWARE
Figura 13 : Diagrama de Forrester: Producci6n Efectiva de Software
148
Subsistema de Desarrollo de Nuevos Proyectos
Misi6n: Garantizar la asignaci6n optima de horas para la ejecuci6n de cada
proyecto, balianceando las perdidas de tiempo por problemas de analisis
como tambien las ventajas de desarrollo por calidad del mismo analisis.
Proceso basico operacional: Horas reales consumidas en cada proyecto
informatico.
Resultados Buscados: Cantidad real de horas asignadas y consumidas en
cada proyecto.
Estrategia: Generar la menor cantidad de compresi6n negativa en cada
proyecto y perdidas por comunicaci6n y anal isis.
RDl: D ON EN EL AREA
\ HORAS REALES PARA HORAS SlGNADAS+\ CADAPROYECTO +" NOCON:U,DAS~ __.....
~ HORASASIG ASA ~ I ( + LOS PROYECTOS + \ PEROIDAS POR COMPRl!S10N
~~\ J~"" ~ HORASREALES PARA
A PROOOCCl N REAL DEf )c.:o PROYECID + ~ SOFtWARE \
soucrruo DE I'ROYEcros
PBRDIDAS DE TMMNODEPRODUceo LOS PROYECrOS
Figura 14: Diagrama Causal: Desarrollo de Nuevos Proyectos
149
SUBSISTEMA DE DESARROLLO DE NUEVOS PROYECTOS
r :l ----
Figura 15 Diagrama de Forrester : Desarrollo de Nuevos Proyectos
5.1.3. Presentacion y Analisis de Resultados
A partir del modelo organizacional aqui construido serfan multiples los
escenarios que podrfan construirse, no obstante, se han planteado tres a
modo de ejemplo. En los tres escenarios, que se simularon, se estableci6 un
horizonte 0 cicio de treinta y seis meses (tres arios).
150
Escenario 1 : Se obtiene en condiciones normales del modelo, es decir,
lNG_AREA =11, EQUI_INST =8, PROD_R_SOFT =2. Cuando se corre la
simulaci6n se puede representar diversas posibilidades, en el modelo
creado aqur, los niveles actuales de personal tienden a oscilar hacia nuestro
objetivo, siguiendo las pautas tfpicas de un cicio compensador con demora
(un mes de contrataci6n) : al principio demasiados ingenieros (veintiuno al
cabo de dos meses), luego logra lIegar al objetivo de numero de ingenieros
(diez y siete al cabo del mes diez), momenta en el cual tambien se estabiliza
la requisici6n de equipos necesarios (Once) para lograr una entrega de
productos efectivamente desarrollados por el area de informatica de trece
m6dulos de aplicaciones por mes,(Figura 16), con una asignaci6n de horas
para los proyectos, que oscila entre ,[1.040 - 1540] horas/mes, es decir, un
tiempo de trabajo de 5.4 hora - dra - ingeniero (Figura 17), en esta
simulaci6n ademas, podemos observar que existe una mayor productividad
de los equipos, dandose una relaci6n de 1.5 ingenieros por equipo, hay una
mayor optimizaci6n de la capacidad instalada, y el rendimiento del desarrollo
es punto ocho (0.8) m6dulos por ingeniero mes.
Escenario 2: Se genera a partir del concepto de racionalizaci6n de la
planta de cargos adscrita al departamento de informatica, el modelo asume
los siguientes parametros lNG_AREA = 14, EQUI_INST = 20,
PROD_R_SOFT =3. En la grafica, el modelo muestra una carda inmediata
151
del numero de ingenieros requeridos, como tambien la necesidad de equipos
instalados para operar, no obstante se ve que la racionalizaci6n de
computadores no decrece de la misma forma que del personal, dado que en
la practica (realidad empresarial) la salida de equipos de computo se da por
obsolescencia, danos 0 reinversiones (reconversi6n industrial), entre otros,
pero esto es mucho mas lento, en cambio para personal en algunas
ocasiones un despido puede ser mas simple.(Figura 18)
En este escenario, se puede analizar que al estabilizarse el cicio
compensador del modelo habra 1.2 equipos por ingeniero, es decir, hay mas
equipos de computo que ingenieros. Como tambien el nivel de productividad
baja a cuatro m6dulos de aplicaci6n por mes, con una asignaci6n horaria
para los proyectos, en un rango de [650, 840 ] horas mes (Figura 19), a
menos ingenieros menos horas para los proyectos 10 que da un promedio de
6.2 horas - dfa - ingeniero para poder cumplir las metas de desarrollo, se
trabaja mas pero se entregan menos aplicaciones terminadas.
Escenario 3: Se produce este a partir del concepto de crecimiento de la
planta de cargos y maximizaci6n del numero de m6dulos de aplicaciones
informaticas, el modelo asume los siguientes parametms lNG_AREA = 15,
EQUI_INST = 15, PROD_R_SOFT = 3. En la grafica, el modelo aumento de
inmediato en el numero de ingenieros estabilizandose en el cuarto mes, en
152
cambio el numero de equipos solo se estabiliza en el mes quince, donde se
empieza a dar una productividad por equipo de computo de 1.3 ingenieros
por equipo, generando una entrega ascendente de modulos de cada
aplicacion a una rata de 1.025 presentandose una asfntota alrededor de 19
ingenieros, es decir un modulo por ingeniero mes (relacion uno a uno)
(Figura 20).
La asignacion horaria para los proyectos, oscila en un range de [1400, 1600]
horas mes (Figura 20), a mas ingenieros mas horas para los proyectos 10
que da un promedio de 6.3 horas - dfa - ingeniero para poder cumplir las
metas de desarrollo, se trabaja mas pero se entregan mas aplicaciones
terminadas, en una relacion 0.93 aplicaciones par meso
Como se puede observar, evaluar la simulacion en sus tres escenarios
resulta gratificante, puesto que ocurrirfa si nos extralimitamos en un proceso
de contratacion 0 despido, 10 que puede lIegar a significar que se elimine
personal sin necesidad 0 se contrate mayor numero del necesario,
incurriendo en pagos e indemnizaciones innecesarias y costosas, e
igualmente adquiriendo equipo de computo que no se requiere y que
rapidamente se vuelve obsoleto.
MESES
Figura 16. Escenario 1. Comportamiento comparativo del: Total de ingenieros en el area vs. EI total de quipos de computo instalados vs.
Producci6n real de software en el area.
o 1 2 3 • 5 8 7 8 9 10 tI 12 13 t .. 15 18 17 '8 19 20 2' Z2 23 24 25 28 'Z7 28 29 30 31 32 13 34 35 38
MESES
Figura 17. Escenario 1. Total Horas asignadas a los proyectos