Orga

I NSTI TUTO POLI TECNI CO NACI ONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA

DE INGENIERA Y CIENCIAS SOCIALES Y
ADMINISTRATIVAS

SECCION DE ESTUDIOS DE POSGRADO E
INVESTIGACIN

PROPUESTA DE ESTRUCTURA ORGANIZACIONAL
PARA UNA EMPRESA DE SERVICIOS DE
DESARROLLO DE SISTEMAS.

T E S I S
QUE PARA OBTENER EL GRADO DE
M A E S T R O E N C I E N C I A S
CON ESPECIALIDAD EN ADMINISTRACIN
P R E S E N T A :
FERNANDO SNCHEZ ALVARADO

Para Blanca

I.P.N. U.P.I.I.C.S.A.

AGRADECI MI ENTOS
________________________________________________________________________________

El Trabajo de Investigacin siempre es un reto, y para hacerle frente, se requiere tener una
slida preparacin mental que permita concentrarse en forma sostenida por das, semanas; a veces
meses e incluso aos. De la misma forma, es importante tener la conviccin de que se cumple una
meta al plasmar un ideal. Este juego de conocimiento y valores hace posible la terminacin de un
trabajo de investigacin.

El camino que se sigue para recopilar y luego conjuntar ideas y escribirlas implica realizar, en
ms de una ocasin una especie de prctica de prueba y error; otras veces, es indispensable el manejo
preciso e inmediato de conceptos, y todo ello lleva a conseguir una sensacin de que las cosas toman
un cauce lgico y consistente. Es entonces cuando se toma plena conciencia de que esta labor es ms
consecuente si se tiene el soporte de las personas idneas, en los momentos y en los lugares que se
necesitan.

Es por ello que agradezco a Dios, a mi padre Luis, a mi madre Guadalupe, y al I nstituto
Politcnico Nacional, porque todo lo que soy es gracias a ellos.

La confianza en mi forma de redactar, pero sobre todo el inquisitivo rigor metodolgico,
necesario en este tipo de empresas, me motiva a agradecer la labor de Guillermo Prez Vzquez al
asesorarme en muchas situaciones acadmicas y de mi vida personal, pero sobre todo por su direccin
en la presente tesis.

El sincero cario y la credibilidad de Blanca Margarita Daz Tllez en mi persona y en mi trabajo
enriquece mi vida y fue mi principal motivacin para retomar y concluir el presente trabajo. Agradezco
tambin el nimo de todos mis amigos que me hicieron sentir en todo momento que compartimos con
la frescura y actitud positiva que los distingue:

Por ello agradezco a I vonne Castaeda Patio, Maricela Amador Ros, Karina Cabrera Castro, Ana Laura
Rivera Espinosa, J essica Yolanda Duran Olgin, Fides Nio Vega, Norma Magallanes Arriaga, Xavier
Murgua Morales, Arturo Montao Prez, J uan Manuel Romn Huerta, Ral Daz Ramrez, Vctor Manuel
Carapia Sadurni, Erick J air Wiechmann Villatoro (qepd), Ren Meneses Snchez, Ludwig Guevara

Morales, quienes sin saberlo aportaron muchos detalles importantes a este trabajo, los cuales se
derivaron de muchas y amenas charlas. De igual forma agradezco a quienes conforman un soporte muy
importante en mi vida, mi familia: Guadalupe, Bertha, Patricia, Felipe, Sergio, Alejandra, Paola, Luis
Sergio y Edgar.

Considero muy importante mencionar que, una parte de la presente investigacin fue
desarrollada bajo mi supervisin, pero fue realizada directamente por mis alumnos de la Escuela
Bancaria y Comercial por ello, agradezco a Silvia Cervantes Serna, Zabdi Lizbeth Chabolla Gonzlez,
Claudia Luna Lozada, Thania Moreno Villavicencio, Francisco Mohabbet Cervantes Moreno, Fernando
Vilchis Rivero y J os Luis Wals J ara.

No puedo dejar de mencionar que, en un momento del tiempo, en una cierta etapa, un par de personas
influyeron decisivamente en mi vida, y fueron, aunque de una manera muy indirecta, piedra angular de
esta tesis. Me refiero a J os Alberto Gonzlez Garca y a J orge Daniel Bautista Crdenas a quienes
agradezco por ensearme y por hacerme vivir en carne propia muchas situaciones que me impulsaron a
estudiar, documentar y buscar opciones para administrar los recursos con los que se cuenta.

Antes de finalizar quiero agradecer a dos personas muy trascendentes en mi diario y cotidiano vivir
durante los ltimos tres aos, a Octavio Mancilla Gonzlez por esa mesurada y correcta forma de
expresar claramente las ideas, y a Everardo Rodrguez Caro por tantas frases, tan jocosas, y al mismo
tiempo tan ciertas y que son mencionadas en el momento ms adecuado. A ambos les agradezco por
todas y cada una de las ocasiones que me auxiliaron y permitieron poder cumplir con mis actividades
acadmicas y por todas las enseanzas en el plano profesional.

Para concluir reitero mi sincera gratitud a Dios porque a cada paso dado ha cuidado todos los detalles
para poder llevar a cabo una obra seria y bien estructurada.


CONTENIDO
________________________________________________________________________________

RELACION DE CUADROS , GRFICAS E ILUSTRACIONES.............................................. 1
SUMARIO ....................................................................................................... 2
SUMMARY ..................................................................................................... 3
I NTRODUCCI N................................................................................................................ 4
CAPTULO I. LA ADMINISTRACIN DE PROYECTOS ........................... 6
I.1 El proyecto y sus caractersticas .. 6
I.1.1 Situacin del problema a resolver mediante el proyecto ... 6
I.1.2 Identificacin del propsito y objetivos del proyecto .. 7
I.1.3 Diferencias entre la produccin en serie y la produccin por proyecto.... 7
I.2. La Administracin de Proyectos ........................................................ 8
I.2.2 Determinacin preliminar de Recursos .. 8
I.3. El proceso administrativo aplicado al desarrollo de sistemas de software ............... 9
I.3.1. Planeacin ......................................................................... 10
I.3.2. Organizacin ................................................................................... 12
I.3.3. Direccin ......................................................................... 15
I.3.4. Control ....................................................................................... 16
I.3.4.1 Supervisin de actividades concluidas 17
I.3.4.2 Supervisin semanal de actividades.. 17
I.3.4.3 Anlisis del avance econmico del proyecto. 17
I.3.4.4 Revisin del avance del proyecto con el rea directiva . 18
I.4 Proceso General de Solucin de Problemas .. 18
CAPTULO II. LA ESTRUCTURA ORGANIZACIONAL....................................................... 20
II.1 Organizacin y estructura organizacional ... 20
II.1.1. Definicin de estructura organizacional.. 20
II.2. Vertientes alternas de estructura. 23
II.3 Conformacin del equipo de trabajo .. 30
II.3.1 El administrador del proyecto ... 30
II.3.2 El Equipo de trabajo ... 31
II.3.3 Comit de validacin... 32

CAPTULO III. EL ENTORNO DE LOS PROYECTOS DE SOFTWARE EN MXICO .. 33
III.1. Las transformaciones Econmicas y sus Repercusiones laborales ...................... 34
III.2. Problemas comunes en la Adm. de Proyectos de Software ................................. 39
III.2.1 Definicin de requerimientos inadecuada. . 40
III.2.2 Planeacin Inadecuada . 40
III.2.3 Habilidades tcnicas deficientes. . 40
III.2.4 Falta de trabajo en equipo . 41
III.2.5 Insuficiente supervisin del avance .. 41
III.3. La Crisis del Software: Panorama del Origen del Problema .................................. 41
III.3.1 Factores que influyen ... 43
CAPTULO IV. HISTORIA DE LOS CICLOS DE DESARROLLO DE SOFTWARE. 46
IV.1. Modelos de desarrollo de software ..................................................................... 46
IV.1.1. Modelo del ciclo de desarrollo en cascada ............................................ 48
IV.1.2.Desarrollo evolutivo .............................................. 50
IV.1.3. Modelo del ciclo de desarrollo en espiral ........................................ 51
IV.2.- Caractersticas del proceso unificado de desarrollo de software........................ 53
Cuadro comparativo de modelos de desarrollo. ............................................... 55
IV.3 El Modelo de Proceso de Software de la Asociacin Mexicana de Calidad en
Ingeniera de Software ................................................................................................ 57
CAPTULO V. PROPUESTA DE LA ESTRUCTURA ORGANIZACIONAL PARA UNA EMPRESA
DE SERVICIOS DE DESARROLLO DE SISTEMAS. ..... 63
V.1. La propuesta ... 64
V.1.1 Caso: Expansin . 65
V.1.2 Caso: Contraccin . 66
V.2. Desarrollo de sistemas con orientacin funcional o estructurada. 68
V.3. Desarrollo de sistemas con orientacin a objetos. 70
V.4. Intenciones competitivas en la compensacin 75

CONCLUSIONES............................................................................................................. 77
BIBLI OGRAF A.................................................................................................................. 79

ANEXOS
A: Investigacin acerca de la demanda de software en la Ciudad de Mxico en el 2006 81
B: El modelo de asignacin de tareas de Investigacin de Operaciones 97


1

RELACI ON DE CUADROS, GRFI CAS E I LUSTRACI ONES
________________________________________________________________________________

Fig. I .1 Proceso Global de la Administracin de Proyectos . 9
Fig. I .2 Proceso General de Solucin de Problemas. 18
Fig. II.1 Ventajas y Desventajas del proyecto puro . 23
Fig. II.2 Ventajas y Desventajas del proyecto funcional ... 24
Fig. II.3 Estructura Matricial .. 25
Fig. II.4 Ventajas y Desventajas del la estructura matricial . 26
Fig. II.5 Estructura unidad/equipo . 26
Fig. II.6 Modelo mecnico versus modelo orgnico . 28
Fig. II.7 Condiciones propicias para aplicar el modelo mecanicista y el orgnico 29
Fig. II.8 Estructura Organizacional Hbrida 30
Fig. III.1 Fuerza de trabajo de Estados Unidos en las economas agraria, industrial y de la informacin. 34
Fig. III.2 Monto del presupuesto que se destina al pago del personal por sector (Elaboracin propia) 35
Fig. III.3 Proyectos de desarrollo de software por sector en la ciudad de Mxico (Elaboracin propia Abril 2006) 36
Fig. III.4 Distribucin de proyectos de desarrollo de software en el sector Servicios en la ciudad de Mxico .. 37
Fig. III.5 Enfocndose en las Causas Raz los sntomas se eliminan . 43
Fig. III.6 Flujo de la Investigacin (Elaboracin propia) 45
Fig. I V.1 Ciclo de Desarrollo en Cascada . 48
Fig. I V.2 Ventajas y Desventajas del modelo en cascada (Elaboracin propia) . 49
Fig. I V.3 Ciclo de Desarrollo de Espiral . 52
Fig. I V.4 Ventajas y desventajas del modelo de Espiral . 53
Fig. I V.5 Cuadro comparativo de modelos de desarrollo (Elaboracin propia) 55
Fig. I V.6 Evolucin del Modelo Normativo 57
Fig. I V.7 Historia de MoProSoft (proporcionado por la AMCIS) . 58
Fig. I V.8 Niveles de capacidad por proceso 59
Fig. I V.9 Modelo MoProSoft (Proporcionado por la AMCIS) .. 62
Fig. V.1 Clula laboral (Diseo Propio) 64
Fig. V.2 Clula laboral en Expansin 65
Fig. V.3 Clula laboral en Contraccin 66
Fig. V.4 Estructura del Equipo de Desarrollo 67
Fig. V.5 Diagrama de flujo de informacin del proceso de anlisis estructurado . 69
Fig. V.6 Flujo del anlisis orientado a objetos . 71
Fig. V.7 Flujo del diseo orientado a objetos 73
Fig. V.8 Flujo de infraestructura . 74
Fig. V.9 Intenciones competitivas de compensacin 76


2

SUMARI O
________________________________________________________________________________

El propsito de este trabajo es mostrar a los administradores que las empresas desarrolladoras
de software requieren una estructura organizacional distinta a las tradicionales, debido a la naturaleza
intrnseca de este tipo de empresas, esto puede ayudarlo a administrar mejor las complejidades y retos
asociados con el trabajo en las organizaciones de nuestro tiempo; por ello se considera importante que
el administrador contemporneo posea un conocimiento prctico de las estructuras organizacionales
mixtas y orgnicas, porque con este conocimiento puede colocar las bases de la adaptacin de la
empresa que administra a los constantes cambios que sufre el ambiente en el que la empresa misma se
encuentra. De hecho una parte significativa del trabajo de los administradores es emplear las continuas
mejoras que se derivan de las investigaciones acerca de las estructuras organizacionales, dichas
mejoras constituyen herramientas que ayudan a incrementar la productividad de la organizacin, y con
ello la habilidad de una organizacin para lograr sus metas.

Ciertamente, la estructura minimiza la improvisacin, ya que no cambia frecuentemente,
adems, mediante la estructura se logra la impersonalizacin de la organizacin, sin embargo es
pertinente enfatizar que los trabajadores no deben ser considerados como parte de la maquinaria, las
personas no son tuercas, ni tornillos, y est demostrado que el factor humano es muy trascendente
para la correcta operacin de cualquier empresa.


3

SUMMARY
________________________________________________________________________________

The purpose of this work is to show managers that software companies require an
organizational structure distinct from traditional ones. Due to organizations' nature, this starting point
can support better management of complexity and challenges associated with the activities in
companies through these modern times. That is why I consider important for managers to develop field
and practical knowledge of mixed and organic organizational structures, since this can form solid bases
for a good adaptation to the constant changes that common companies suffer due to the prevailing
environment. In fact, a big percentage of manager's job is to apply the ever changing improvements
born from investigations. Such improvements constitute the tools that increase organization effectivity
and go with the hability to achieve the organization's goals.

Actually structures make improvisation difficult since they doesn't change frequently, they
achieve that the organization doesnt depend on workers, just in its structures. Nevertheless it is
pertinent to emphazise the fact that workers must not be considered as parts in the machinery, people
are neither nuts nor screws, and it has been demonstrated that human factor is quite trascendental for
the correct operation of any company.


4

I NTRODUCCI N
____________________________________________________________________________________

La incertidumbre de la economa y las constantes modificaciones que sufre el pas y el mundo
debido a la globalizacin, acompaada de la constante amenaza de crisis, afecta a nuestra sociedad en
muchos aspectos. Es claro que el desarrollo de sistemas de software, es un fiel reflejo de esta situacin,
e incluso podemos afirmar que tambin pasa por su propia crisis. De hecho, gran parte de las
organizaciones, empresas, y reas de sistemas que se dedican a desarrollar aplicaciones de software de
mediano y gran tamao, se encuentran inmersas dentro de una Crisis del software, la cual se
caracteriza porque los tiempos de entrega y los presupuestos (tiempo y dinero) son comnmente
excedidos, ya que no estn basados en estimaciones reales; adems la calidad del producto no es la
que se espera si los tiempos de entrega son muy comprometidos.

La presente Tesis tiene el objetivo de proponer una estructura organizacional para el tipo de
empresa dedicada al desarrollo de proyectos de software, para ello, este trabajo se estructura en cinco
captulos. El captulo uno trata de la administracin de proyectos y de cmo se aplica el proceso
administrativo al desarrollo de software, as mismo se hace mencin de los problemas ms comunes
que se presentan en la Administracin de Proyectos de software, los cuales se describen mas a detalle
en el tercer captulo. Por otra parte, en el segundo captulo, se recopilaron algunos conceptos de
organizacin y estructura organizacional, y se describen varias estructuras organizacionales, con
cuadros que muestran las ventajas y desventajas de cada uno.

En el captulo tres se proporciona un panorama general del entorno nacional de las empresas
desarrolladoras de sistemas de informacin, se detallan algunas de las situaciones en las que operan
este tipo de organizaciones, enfocndose en los problemas ms comunes que se presentan.

La razn de ser del captulo cuatro es que la tecnologa es otro de los factores contextuales que
explica la estructura organizacional, y se pretende describir las diferentes formas en las que la gente se
ha organizado para generar aplicaciones tecnolgicas, es decir la forma en que las personas se
organizan para crear tecnologa, por ello en este captulo se presenta una sntesis de los modelos o
enfoques que guan el proceso de desarrollo de software, considerndose el tradicional ciclo de vida o
modelo en cascada, el proceso de desarrollo evolutivo, y el modelo basado en componentes el cual,
dicho sea de paso, fomenta la reutilizacin de software. En este captulo, tambin se describe el modelo
de proceso de desarrollo de software, conocido como MOPROSOFT, modelo mexicano.

5

Finalmente, en el captulo cinco se propondr una alternativa para organizar a los recursos
humanos, con la cual se espera reducir gran parte la problemtica actual, buscando lograr la sinergia
del equipo desde la estructura misma, al conjuntar, bajo ciertas circunstancias, los intereses de los
directivos y trabajadores.

Para la elaboracin de la propuesta se eligi un marco terico, de tal manera que, a medida
que el lector avance en la lectura de esta tesis se podr percatar que, una de las obras que ms influy
en el presente trabajo es, Organizaciones: Estructura y proceso de Richard Hall, obra en la cual en su
cuarto captulo se describen los factores contextuales que afectan la estructura organizacional; es por
ello que es pertinente enfatizar que cada captulo del presente trabajo trata de explicar tres de los
cuatro factores contextuales: Entorno, tecnologa y tamao.

Por lo que respecta al factor cultura (o estilo cultural de la organizacin) podemos mencionar
que, en estos tiempos en donde la competencia global ha impulsado la tendencia en las organizaciones
a contar con una fuerza de trabajo notablemente diversificada en cuanto a nacionalidades, culturas e
incluso subculturas, muy frecuentemente ha dado por resultado que los integrantes de los grupos de
trabajo lleguen a diferir profundamente en cuanto a sus antecedentes, formacin acadmica,
expectativas, creencias, etc; por ello cabe mencionar que, ciertamente las organizaciones son afectadas
por la cultura y el ambiente en donde estn localizadas, en la misma forma que se ven afectadas por
los factores de tamao y tecnologa, sin embargo el tratamiento de este tema queda fuera de los
lmites del presente trabajo, ya que esto constituye por s mismo otro tema de tesis y lo que se
pretende es fijar ciertas variables para poder generar el ambiente de investigacin, como diran los
economistas Ceteris Paribus (Trmino en latn usado en el anlisis econmico para variar un factor
mientras que el resto de factores se mantienen constantes). Sin embargo, muy someramente podemos
comentar al respecto que, la flexibilidad ser un factor esencial en estos casos. El respeto a las
diferencias nacionales y culturales tiende a rendir dividendos.


6

CAPITULO UNO
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
LA ADMINISTRACIN DE PROYECTOS

La administracin es, ms que un concepto, una forma de vida. Internarse en ella es descubrir
que podemos cambiar la forma en que se nos ha enseado a pensar y aprender a crear
conscientemente a travs del tiempo.
1

Henry Mintzberg.

La administracin puede ser vista como un instrumento para llegar a un objetivo: Ser ms
eficientes. Se busca generar, incrementar y mantener el valor para la empresa, la administracin busca
mejores rendimientos, incrementar la productividad, mejorar la relacin costo- beneficio. Para poder
lograr esto, dentro del entorno de las empresas de servicios que trabajan por proyecto, se considera
muy importante establecer la definicin de proyecto y sus diferencias con la produccin en serie.

I .1 El proyecto y sus caractersticas
DEFI NI CI N DEL PROYECTO
Un proyecto puede definirse como una serie de actividades relacionadas entre s, que por lo
comn y cuyo desempeo requiere un periodo significativo. Un proyecto debe estar orientado a un
objetivo, debe tener una fecha de inicio y terminacin, as como una secuencia de actividades. Dicho
proyecto est limitado en cuanto al uso de recursos y presupuesto para su aceptacin, ya que involucra
mucha gente y/o reas funcionales de la organizacin y el resultado final debe ser un producto y/o un
servicio. Aunque existe un riesgo durante su ejecucin
2
.

I.1.1 Situacin del problema a resolver mediante el proyecto

La situacin puede ser descrita a partir de un enunciado corto, claro y preciso que pueda ser
interpretado por las personas involucradas, que informe sobre todo lo que se debe hacer as como la
fecha de cuando el proyecto deber ser completado o finalizado y mencione en todo caso al
responsable o lder del proyecto.

1
http://es.wikipedia.org/wiki/Henry_Mintzberg Fecha de Acceso 17-Abril-2006
2
Quality And Productivity, Proceso de Desarrollo de Software de Sofftek, Softtek Educacin en Tecnologa,
Mxico, Pg. 3 y Praxis, Manual Administracin de Proyectos de Software, Ed. Praxis, versin 1.0 Ao 1999
Pg. 2

7
I.1.2 I dentificacin del propsito y objetivos del proyecto

Al iniciar un proyecto se debe definir una meta clara, que permita saber cul es el resultado
final deseado y su alcance. La definicin de la meta debe ser un enunciado por escrito, que permita
asegurar que todos estn entendiendo lo mismo. La meta deber ser especfica, medible, realista y
definida en trminos de tiempo y costo, debe estar de acuerdo con los objetivos de la alta direccin y
con la misin de la Institucin.

Una vez identificado cul es la meta del proyecto, es posible definir cules son los objetivos del
mismo. Los objetivos son enunciados ms precisos que aclaran la meta y orientan la accin.
Representan grandes componentes del proyecto que tendrn que ser completados a travs de una serie
de actividades.

Mediante la especificacin de objetivos se comienza a ver el proyecto en trminos de sus
grandes componentes, lo que ayuda a la toma de decisiones y a la comprensin por parte de los otros
integrantes del equipo.

I .1.3 Diferencias entre la produccin en serie y la produccin por proyecto.
La produccin en serie se caracteriza por producir un nmero determinado de piezas iguales,
bajo un mismo procedimiento, y por su parte en la produccin por proyecto se producen piezas muy
especficas tales como supercomputadoras, locomotoras, barcos, aviones, edificios y sistemas de
software.
3
, por ello la forma en la que se organizan tanto las tareas como a las personas que las
desempean debe estar acorde a las caractersticas intrnsecas de las actividades a realizar.

Configuracin por Proyecto. Produccin generalmente de productos nicos de cierta
complejidad que requieren gran cantidad de insumos. Estos deben fabricarse en un lugar definido
debido a que es difcil o casi imposible transportarlos una vez terminados. Como resultado, y a
diferencia de cualquier otro proceso productivo, los recursos que comprende deben trasladarse al lugar
de operacin, ya que aqu no existe flujo del objeto de trabajo, sino que son los recursos tcnicos y
humanos quienes acuden al lugar de trabajo. Las actividades y recursos se gestionan como un todo. Su
coordinacin adquiere carcter crtico. Existe un gran inters por el control de los costos y las fechas de
terminacin.

3 Chase Aquilano, Administracin de la Produccin y de Operaciones Mc Graw Hill 10. Ed. Mx. 2005 Pg. 74

8
I .2 La Administracin de Proyectos

La Administracin de proyectos puede definirse como planeacin, direccin y control de
recursos (personas equipo, material) para cumplir las restricciones tcnicas de costos y de tiempo de un
proyecto.
4

La Administracin de proyectos es el proceso cuya funcin principal es la de dar el seguimiento
adecuado a las actividades que se establecen, organizando stas de acuerdo a una secuencia lgica y
asignndoles los recursos y costos necesarios para su ejecucin que permitan el logro de los objetivos
planteados en el proyecto.
5

La administracin de proyectos trata de proporcionar una serie de mtodos y/o tcnicas
basadas en los principios de la administracin, que sirvan como base para la planeacin, estimacin y
control de los proyectos, involucrando el establecimiento de objetivos claros y precisos, la secuencia de
actividades que tendrn que completarse, la organizacin e integracin de los recursos materiales,
humanos y financieros al plan del proyecto y seguimiento del mismo para realizar los ajustes conforme
se vayan detectando las desviaciones, lo cual constituye el principio de la planeacin estratgica.

La primera etapa que se vislumbra para poder realizar la administracin del proyecto es la
investigacin preliminar, en donde se busca identificar riesgos potenciales y tratar de mitigarlos. Al ser
una etapa temprana en el ciclo de vida del proyecto tendr que enfocarse a obtener informacin
general y valiosa sobre ste, a fin de que sirva para describir la situacin del problema, la direccin u
orientacin del proyecto y la identificacin de suposiciones y riesgos asociados con el mismo.
En la mayora de las situaciones esta etapa es subestimada debido a la dificultad que implica
tanto definir la meta y los objetivos del proyecto como identificar los problemas. En el captulo cuatro se
describen varias formas de llevar a cabo un proyecto, usando grficas.

I .2.1 Determinacin preliminar de recursos
Aunque es una etapa an temprana para estimar adecuadamente los recursos que debern
usarse, deber considerarse realizar una lista, aunque posteriormente en la elaboracin del plan tenga
que ajustarse.

Los recursos no solamente se refieren a dinero sino tambin deben considerar los recursos
humanos, materiales y el capital financiero que requiera el proyecto. La lista deber de responder a las
interrogantes quin?, cundo?, cuntos? por cunto tiempo?, En dnde?

4
Chase, Aquilano, Administracin de Operaciones, Mc Graw Hill. 10a edicin. Mxico. 2001, Pgs. 165-168

9
I .3 El proceso administrativo aplicado al desarrollo de sistemas de software

La figura I .1 proporciona una visin global de la administracin de proyectos. En la parte
superior izquierda de la figura, se muestra el inicio del proceso a travs de la solicitud de propuesta
elaborada por el cliente, tambin se muestran las principales fases de la administracin de proyectos:
Planeacin, Organizacin, Direccin y Control. Tambin en la parte superior se representa al equipo que
lleva a cabo la administracin de proyectos, y en la parte inferior al soporte corporativo como el entorno
en el cual se desarrolla el proyecto. El equipo se presenta tanto en la Organizacin como en la direccin
ya que se pretende que sea un equipo autodirigido.

El cliente es a quien se considera como la fuente de la solicitud de propuesta, esta solicitud
marca el inicio del proyecto y usualmente especifica lo que el cliente necesita y tambin los criterios que
se utilizarn para evaluar la propuesta que se entregue.

Visin Global de la Administracin de Proyectos

Fig. I .1 Proceso Global de la Administracin de Proyectos (Diseo Propio)

Es comn que el cliente no genere una solicitud de propuesta por escrito y que adems ste
sea extremadamente superficial. En este caso se deber escribir y detallar la solicitud de propuesta
antes de comenzar la fase de planeacin debido a que la eficiencia de esta fase depender en gran
parte de los datos de entrada que recibe.

5
Praxis, Manual Administracin de Proyectos de Software, Ed. Praxis, versin 1.0 Ao 1999 Pg. 8

10
I .3.1 PLANEACI ON
La fase de planeacin comienza con la determinacin de requerimientos, los que servirn de
gua para elaborar el plan de proyecto que a su vez servir de base para elaborar la propuesta. La
planeacin recibe retroalimentacin de la fase de supervisin, ya que es ah donde verificamos que el
proyecto avance de acuerdo a lo establecido en la planeacin.
6

Requerimientos

Un requerimiento es una condicin o capacidad que debe cumplir el software solicitado por el
usuario para resolver un problema o alcanzar un objetivo. Las definiciones de los requerimientos son
generadas por el cliente, el desarrollador de sistemas es por lo tanto un receptor en lugar de la fuente
original de estas definiciones (sin embargo, puede definir y proponer estos con base en las necesidades
del cliente y su experiencia). Los requerimientos asignados al software son la principal entrada para
desarrollar el plan del proyecto.

Los requerimientos pueden estar relacionados con sistemas completamente nuevos o con
actualizaciones de sistemas existentes. El cliente a menudo tiene dificultades para expresar estos
requerimientos en forma completa y consistente, especialmente cuando los sistemas son nuevos
7
.
Plan del Proyecto

Para poder realizar una planificacin efectiva y ejecutar un proyecto complejo puede ser de
ayuda el visualizar el proyecto como un conjunto de metas con una serie de objetivos bien definidos.
Cada objetivo debe tener un nmero discreto de actividades, las cuales definen el trabajo o las tareas
que deben realizarse y en que orden, para alcanzar los objetivos. Estas deben ser formuladas y
especificadas de tal forma que puedan ser fcilmente medidas y su cumplimiento fcilmente verificable.

El plan del proyecto tiene cuatro elementos esenciales. Estos elementos son: La descripcin del
proyecto, la descripcin de las actividades, el presupuesto del proyecto y el anlisis de riesgo.

Entre los objetivos del plan de proyecto se encuentran los siguientes:
Permitir que los miembros del equipo, incluyendo al nuevo personal asignado, comprendan las
caractersticas esenciales del proyecto.
Proveer a la administracin de la empresa un entendimiento del proyecto
Transmitir al cliente las caractersticas esenciales del proyecto, como fueron percibidas e
implementadas por el equipo de trabajo.

6
Quality And Productivity, Proceso de Desarrollo de Software de Sofftek, Softtek Educacin en Tecnologa, Mxico, Pg. 29

11
Formar la base de la propuesta para el cliente

La planeacin del proyecto de software puede ser dividida en fases para su mejor control, las
fases son determinadas por la metodologa de desarrollo que se est ocupando, pero genricamente
podemos hablar de las siguientes fases:

a) Antes de comenzar el proyecto se elabora un plan inicial de proyecto utilizando los
requerimientos base, este plan es muy general y debe ser detallado durante el desarrollo de este.
b) Durante el proyecto, el plan base se modifica por varias razones: porque la planeacin base no
es implementable o porque los requerimientos base sufren modificaciones.
c) Los componentes del plan del proyecto deben ser documentos controlados, es decir que la
versin vigente en determinada fecha debe ser identificable.
d) La planeacin debe ser revisada constantemente sin embargo es obligatorio revisarla y detallarla
al finalizar una fase de la metodologa de desarrollo y antes de comenzar la siguiente.

Las actividades de la fase de planeacin del proyecto son
8
:

1.- Obtener datos histricos de planeacin de proyectos
Estos datos pueden surgir de muy diversas fuentes: manuales de polticas y procedimientos,
observacin, entrevistas, cuestionarios etc. pero la ms importante es la experiencia adquirida por parte
del equipo en proyectos similares

2.- Elaborar la descripcin del proyecto.
La descripcin del proyecto es una sntesis de todo el trabajo requerido para complementar el
proyecto, y se elabora a partir de los requerimientos base.

3.- Elaborar el plan de actividades.
Se crea una versin del plan de actividades antes de iniciar cada fase de la metodologa de
desarrollo, esta se realiza utilizando el paquete estndar de administracin de proyectos que se defina
en la empresa.

4.- Elaborar el desglose de actividades
El desglose de actividades es un diseo grfico o lista identada (con mrgenes o sangras
conformados por espacios en blanco que facilitan la lectura al mostrar relaciones de jeraqua) del
trabajo que debe ser realizado para completar el proyecto, proporciona una representacin detallada

7
Quality And Productivity, Ob cit, Pg. 35 y Praxis Ob cit, Pg. 10

12
del proyecto como una coleccin de actividades que deben ser realizadas para que el proyecto sea
terminado.

Estimacin de Tiempos y Costos

Para estimar el tiempo y el costo da cada una de las actividades del proyecto, si las actividades
son lo suficientemente familiares o rutinarias como para estimarles los recursos necesarios, entonces no
debe existir ningn problema. Sin embargo, para actividades no bien conocidas, o en las cuales se
carece de la suficiente experiencia como para estimarles los recursos de manera directa, entonces se
tienen que tener en cuenta los siguientes factores:
Nivel de pericia y experiencia de las personas que realizan la actividad.
Variaciones en los equipos o mquinas.
Disponibilidad de material.
Eventos inesperados (enfermedades, desastres naturales o sociales, huelgas, accidentes etc.)

Para la estimacin en lo que respecta al costo existen tpicamente 4 grandes categoras y que
pueden definirse para cualquier actividad, tales como :
1. Recursos Humanos
2. Recursos Materiales
3. Otros costos directos (viticos, telfonos, servicios contratados, etc.)
4. Indirectos (Administracin)

Una prctica que se aplica por lo general, es que los costos no localizables (indirectos) tales
como administracin, utilidades, depreciacin de edificios, entre otros, son calculados mediante un
porcentaje fijo del total de los costos directos del proyecto en su conjunto. Esto permite que los
cambios ocurridos en las actividades individuales puedan ser considerados a nivel proyecto, o a un nivel
un poco ms bajo dependiendo del tamao del proyecto, para recalcular los costos indirectos.

I .3.2 ORGANI ZACI N

Por lo general al hablar de organizacin, se entiende que hablamos de una unidad social creada
para un fin. Dentro de la organizacin debern ser definidas estructuras, para que se tenga la
seguridad de que las personas hagan aportaciones en una forma especfica al esfuerzo del grupo.

La estructura tiene que definir las tareas a organizar, este proceso es intencional ya que deben

8
Quality And Productivity Staff, Ob cit, Pgs. 83-90 y Praxis, Ob cit Pg. 8

13
asignarse todas las tareas necesarias a las personas ms idneas para hacerlas, siguiendo el principio
de Orden de Henri Fayol.
9
Para ello, en el Anexo B se muestra una forma de asignacin de tareas cuyo
objetivo es precisamente encontrar La mejor persona para el trabajo

Se considera a la estructura organizacional como el arreglo de las partes de la organizacin.
Pero por estructura organizacional significamos la distribucin a lo largo de varias lneas, de personas
entre posiciones sociales que influyen en las relaciones de los papeles entre esta gente.
10
Las
organizaciones varan en su grado de complejidad. Las organizaciones tambin varan en el grado en el
que se les da autonoma a la gente y a las unidades. Las estructuras organizacionales estn cambiando
segn se ven influenciadas por sus miembros, las interacciones entre dichos miembros y las presiones
ambientales incesantes. Al mismo tiempo la naturaleza de las estructuras organizacionales tienen fuerte
tendencia hacia la inercia.

Una consecuencia de la definicin es la divisin del trabajo; a la gente se le dan diferentes
tareas o puestos dentro de las organizaciones. Otra consecuencia es que las organizaciones tienen
rangos o una jerarqua; las posiciones que ocupa la gente tienen reglas y reglamentos que especifican,
en diferentes grados, cmo deben de comportarse los que ocupan esas posiciones.

Otras definiciones enfatizan la importancia de las interacciones humanas en la formacin de
estructuras, puesto que las estructuras configuran las prcticas de la gente, pero tambin es cierto
que las prcticas de la gente constituyen, y reproducen, la estructura, se ve a la estructura como un
medio complejo de control que se produce y recrea continuamente en la interaccin, y sin embargo da
forma a esa configuracin: las estructuras se constituyen y son constituyentes.

Estos enfoques enfatizan que la estructura de una organizacin no queda fija; ms bien,
configura lo que sucede en una organizacin. Las estructuras organizacionales son una consecuencia
del impacto simultneo de mltiples factores
11

Las estructuras organizacionales cumplen con ciertas funciones, entre las cuales estn las
siguientes: Las estructuras tienen la intencin de elaborar productos organizacionales y alcanzar
objetivos organizacionales, las estructuras se disean para minimizar, o por lo menos regular, la
influencia de las variaciones individuales sobre la organizacin. Las estructuras se imponen para
asegurarse de que los individuos se ajusten a los requisitos de las organizaciones, y no viceversa.

9
Kast, Fremont E, Rosenzweig, James E, Administracin en las Org. Ed. Mc Graw Hill, Mxico 1985 Pg. 67
10
Hall, Richard, Organizaciones: estructura y proceso Mxico, Prentice Hall. Se transcribe la nota al pie
original, Blau, 1974; pgina 12.
11
Ibidem. Pgina 92

14
Adems es el ambiente donde se ejercita el poder (tambin las estructuras fijan o determinan qu
puestos tienen poder en primer lugar), donde se toman decisiones y donde se desarrollan las
actividades organizacionales
12
.

Al hablar de organizacin como proceso, nos referimos a la etapa del proceso administrativo en
la cual se debe de establecer la estructura del equipo de trabajo y se debern definir los roles de cada
persona.
Se supone que los edificios tienen estructuras que se ajustan a las actividades que se
desarrollan en su interior. Un edificio de oficinas es diferente a una fbrica
13
y sta es muy diferente de
una escuela o un laboratorio. Los edificios tambin reflejan los valores e ideologa de las personas que
tienen el control.

Construir equipos efectivos es tanto arte como ciencia. En la construccin de un equipo efectivo
lo que se ha de considerar es que debe estar dado no slo por la destreza tcnica del administrador y
los miembros del equipo, sino tambin por los papeles crticos que desempean y la qumica que les
mezcle.
Las actividades que deben realizarse durante la etapa de organizacin son:
- Tener definida y difundida la organizacin del equipo de trabajo en cada etapa, con la
responsabilidad de cada rol entre todas las personas que forman el equipo.
- Adecuar los diferentes roles a las habilidades individuales de los integrantes del equipo.

Para seleccionar a las personas que se encargarn del proyecto, es muy importante tomar en
cuenta el perfil de cada una, la informacin con la que cuenta el rea de recursos humanos ayuda a la
formacin de equipos de trabajo fciles de integrar.

Una de las principales tareas dentro de la organizacin es definir el organigrama del proyecto,
as como los roles y funciones de cada uno de los miembros del equipo de trabajo.

Un organigrama es la representacin de la organizacin del proyecto, puede variar de acuerdo a
cada una de las fases del ciclo de vida del proyecto. Este organigrama deber estar debidamente
definido y documentado, junto con la descripcin de cada uno de los roles y funciones definidos. El
organigrama nos ayudar a la asignacin de actividades del equipo.

12
Hall, Richard, Ob Cit Pg. 92
13
Kast, Fremont E, Rosenzweig, James E, Administracin en las Org. Ed. Mc Graw Hill, Mxico 1985 Pg. 68

15

I .3.3 DI RECCI N

La fase de organizacin es normalmente seguida por la fase de direccin. Los elementos
esenciales de esta fase son establecer un equipo de trabajo coherente y efectivo, para lograr esto es
necesario:
a) Realizar juntas peridicas de trabajo, agendadas con anterioridad y las personas involucradas
debern de ser notificadas con anticipacin.
b) Asignacin de actividades.
c) Realizar peridicamente sesiones de retroalimentacin, para informar al equipo de los
avances, los problemas, acuerdos, etc. Deber involucrarse a todos los miembros del equipo
de trabajo.
d) Influir en las personas para que contribuyan a obtener las metas del proyecto; incluyendo
estilos de motivacin, enfoques de liderazgo y comunicacin.

Para este caso de estudio, el liderazgo ser mencionado como un elemento que se encuentra
implcito en algunos factores de comportamiento organizacional que se describen a continuacin.

El lder del equipo debe ser objetivo e imparcial en las decisiones al momento de solucionar los
problemas. El lder tiene que estar constantemente revisando los factores que motivan a los miembros
del mismo para asegurarse de que dichos factores sean atendidos y as generar compromiso, ya que las
personas se comprometen en la medida que se sienten parte de algo. Adems, el lder del equipo, debe
ser el principal encargado de construir un ambiente propicio para el surgimiento de la confianza,
mediante su propio ejemplo, y guiando a los dems miembros del equipo a que establezcan la relacin
de confianza. Un equipo liderado por una persona que no inspira confianza seguramente ser un equipo
donde la misma no va a prosperar.

La comunicacin debe ser abierta. La comunicacin dentro de un equipo puede referirse a dos
tpicos: Conversaciones sobre los temas en los que est operando el equipo, o conversaciones sobre la
interaccin misma del equipo.

La comunicacin eficaz puede ser la llave para lograr la excelencia organizacional ya que
dentro de la empresa se lleva a cabo un sistema de comunicacin humano y tecnolgico que es
responsable de resolver los problemas altamente complejos de una manera creativa, entendiendo por
excelencia organizacional a la habilidad de las personas de trabajar juntos y utilizar la tecnologa para

16
resolver creativamente los problemas altamente complejos.
14

Comunicacin efectiva entre los miembros del equipo

Un factor muy importante para tener eficiencia en los equipos es sin duda la efectividad en la
forma que se comunican sus integrantes.

Nmero ptimo de miembros. Los equipos eficaces contienen miembros suficientes para
asegurarse de que existe una buena interaccin, pero no tantos como para que la discusin se sofoque,
por otro lado, se dice que un nmero impar de miembros es mejor para evitar empates en las
votaciones al tomar decisiones consensadas.
15

Consenso. Si una decisin no es producto de la reflexin e interaccin del grupo, las ventajas
de la toma de decisiones grupales se pierden. Adems, los miembros del equipo con frecuencia se
sienten ms satisfechos acerca del proceso y ms comprometidos con las decisiones que resultan del
mismo cuando stas se alcanzan de una manera democrtica, por medio de la interaccin del grupo.

Liderazgo en la comunicacin. Para que el liderazgo ocurra en los equipos de trabajo, unas de
las habilidades necesarias del lder son planear la agenda, ofrecerles a todos una oportunidad igual para
participar, formular preguntas apropiadas, lidiar con la diversidad cultural, resumir el debate y cristalizar
el consenso. Sin la direccin de un lder, es probable que algunas personas hablen ms tiempo del que
les corresponde.

I.3.4 CONTROL

Independientemente de qu tan completa y precisa sea la planeacin, generalmente hay un
nmero de eventos cuyo resultado no puede ser previsto o controlado. El administrador de proyectos
deber tener la capacidad de detectar esos problemas y tomar las acciones correctivas para mantener
el proyecto sobre el calendario, dentro del presupuesto y completarlo de acuerdo con las
especificaciones.

El fin que persigue la supervisin es obtener de forma permanente el estado del proyecto, con
el fin de dar retroalimentacin a cada una de las fases de la administracin anteriores.

14
Hernndez Santuario, Eloisa Itz, Modelo de comportamiento organizacional para elevar el desempeo de los
grupos de trabajo interfuncionales dentro de la empresa Tesis, Mxico, 2002, MCSC ITESM H531.M2002 Pg. 29
15
Ibidem Pg. 38

17
Existen distintos tipos de supervisin cada uno persiguiendo el control de las actividades que
llevarn a conseguir el objetivo final. Algunos tipos de supervisin dentro del desarrollo de sistemas de
informacin se describen a continuacin:

I .3.4.1 Supervisin de actividades concluidas.

Al trmino de cada actividad, el producto generado deber ser revisado por el responsable del
mismo. En caso de existir diferencias, entre la definicin y el funcionamiento conseguido, se debern
realizar las correcciones necesarias hasta lograr obtener el producto deseado.

La duracin real de la actividad deber ser documentada, la informacin generada en esta
supervisin debe ser entregada al lder del proyecto para que proceda a actualizar el avance del plan de
actividades. Este tipo de supervisin tiene como fin el determinar el estado del proyecto o de alguna de
sus actividades.

I.3.4.2 Supervisin semanal de actividades.

Los reportes de actividades semanales elaborados por los integrantes del equipo de trabajo
servirn para detectar:
Actividades no planeadas.
Actividades planeadas no realizadas.
Poca inversin de tiempo en el proyecto.
Avance de actividades.

Con las detecciones realizadas se tendrn las bases suficientes para llevar a cabo una
retroalimentacin con la cual se obtendrn los ajustes necesarios que eviten un posible fracaso del
proyecto.

I .3.4.3 Anlisis del avance econmico del proyecto.

Uno de los principales indicadores del desempeo del proyecto es el avance del costo. El costo
actual del proyecto debe ser comparado contra el planeado, considerando a su vez las posibles
diferencias entre las actividades planeadas y las realizadas hasta el momento, todo ello con el fin de
evitar prdidas econmicas.

18

I .3.4.4 Revisin del avance del proyecto con el rea directiva.
Es necesario llevar a cabo una revisin formal con el rea directiva de la calendarizacin del
proyecto, el costo y la calidad, es un elemento esencial de la administracin efectiva de proyectos. Las
revisiones se deben llevar en forma mensual como mnimo.

I .4 Proceso General de Solucin de Problemas

Con el objetivo de encontrar las causas raz, se deben realizar durante las revisiones algunas
verificaciones, Por ejemplo, si el proyecto est en tiempo de acuerdo al calendario establecido, si el
presupuesto ha sido sobrepasado, o bien que los productos obtenidos hasta el momento cumplan con
lo que se esperaba. En caso de que alguna de estas situaciones est sucediendo se deber llevar a cabo
un proceso de diagnstico de forma estructurada que ayude a determinar las posibles causas de las
desviaciones existentes. En la figura I.2 se muestran las fases a seguir dentro del proceso de
diagnstico mencionado.

Fig. I.2 Proceso General de Solucin de Problemas.
16

El proceso de solucin de problemas mostrado en la anterior figura tiene como primer paso
(caja 1) el obtener o reiterar, los hechos que son conocidos en la situacin dada. Estos hechos
normalmente se obtienen de la calendarizacin del proyecto, el anlisis econmico y la calidad de los
productos, sin embargo pueden existir otros factores que no son tan obvios. Algunos de estos ejemplos
podran ser:

Un incumplimiento de un proveedor o subcontratista.
Un conflicto serio entre miembros del equipo.
La salida de un miembro clave del equipo.

16
http://contexto-educativo.com.ar/2003/3/nota-04.htm (Fecha de Acceso: 16/Septiembre/2006)


19
La falta de disponibilidad de los usuarios.
El bajo nivel de experiencia de los recursos asignados.
Las dificultades en la autorizacin del anlisis.

Despus de que estos hechos han sido identificados, se pueden seguir dos caminos. Uno
dirigido a identificar un conjunto de problemas evidentes (caja 2) y el otro dirigido a identificar a
problemas potenciales (caja 3).

El primero representa los problemas claros e irrefutables, normalmente de alta prioridad.
Ejemplos de este tipo de problemas pueden ser un atraso en el plan de actividades, que los gastos sean
mayores que las cantidades presupuestadas, que las entregas no sean realizadas en fechas
establecidas, o bien que se detecten fallas en las pruebas del sistema.

En la categora de problemas potenciales, estn aquellos eventos que podran hacer un dao
serio al proyecto. Ejemplos de estos son los conflictos en el personal, que la compaa pase por una
etapa de reorganizacin, la rotacin del personal, es decir, la prdida de gente clave, no en el proyecto,
sino en la organizacin. O bien, cambios en los proveedores/subcontratistas de la compaa.

Esta separacin ayudar al siguiente paso, que es ordenar estos problemas por prioridades
(caja 4). Una lista de prioridades busca forzar una disciplina que asegure que los problemas clave no
puedan ser ignorados. Sin esta disciplina, un administrador de proyectos puede estar inclinado a
abordar los problemas ms pequeos o con poca importancia y evadir los problemas crticos.

Despus de asignar prioridades, el siguiente paso es desarrollar planes para solucionarlos (caja
5). Los planes para los problemas del principio de la lista deben ser elaborados, en tanto que los
ltimos pueden ser postergados hasta obtener ms datos. Los planes para resolver problemas debern
ser evaluados en trminos de beneficio, riesgo y costo (caja 6). Los planes que no son satisfactorios
(caja 7) tienen que volver atrs para ser mejorados y considerar otras alternativas. Una vez que el plan
es aprobado la implementacin comienza (caja 8).

Una vez que hemos abordado todas y cada una de las fases de la administracin de proyectos,
es conveniente comentar que estas fases han sido modificadas en el tiempo, ya que se han hecho
propuestas, se han aplicado a la realidad y al confrontar la teora con la prctica los modelos se han ido
adaptando, y de lo cual se habla en el siguiente captulo.


20

CAPITULO DOS
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
LA ESTRUCTURA ORGANIZACIONAL

"Las estructuras se constituyen y son constituyentes"
17

En la contundente mayora de las obras consultadas para la elaboracin del presente trabajo de
investigacin, se puede observar que, un gran nmero enfatizan las llamadas eses blandas o
cualitativas, es decir, la tipificacin del personal o descripcin demogrfica (Staff), las aptitudes que
distinguen al personal clave de la empresa considerada sta en su conjunto (Skills), las ideas ms
significativas que una organizacin permea en sus miembros (Superordinate goals) y, el
comportamiento caracterstico de los directivos clave para la consecucin de los objetivos de la empresa
(Style), e incluso, un buen nmero de obras tratan extensamente las llamadas eses duras o
cuantitativas, es decir, tratan el plan o accin para asignar los limitados recursos de la empresa
(Strategy), tratan la forma de hacer circular la informacin (Systems), pero en realidad son pocos los
autores que hacen referencia a la distribucin del trabajo, a cmo se organiza la empresa, si est
descentralizada o centralizada, etc., es decir a la estructura (Structure)
18
.

I I .1 Organizacin y estructura organizacional

La palabra organizacin tiene tres acepciones, una etimolgica que proviene del griego organn
que significa instrumento; otra que se refiere a la organizacin como una entidad o grupo social; y otra
ms que se refiere a la organizacin como un proceso.

II.1.1. Definicin de estructura organizacional
Organizacin (Para Agustn Reyes Ponce) es la estructuracin tcnica de las relaciones que
deben existir entre las funciones, niveles y actividades de los elementos materiales y humanos de un
organismo social, con el fin de lograr su mxima eficiencia dentro de los planes y objetivos sealados.

Para Petersen y Plowman, la organizacin es un mtodo de distribucin de la autoridad y
responsabilidad, y sirve para establecer canales de comunicacin entre grupos. Segn Terry

17 Hall, Richard, Organizaciones: estructura y proceso Mxico, Prentice Hall. Pg. 53

21
Organizacin es un arreglo de las funciones que se estiman necesarias para lograr un objetivo, y una
indicacin de la autoridad y responsabilidad asignadas a las personas que tienen a su cargo la ejecucin
de las funciones respectivas. Finalmente, podemos concluir que, la organizacin puede definirse como
dos o ms personas que colaboran dentro de ciertos lmites para alcanzar una meta comn, o bien
como un conjunto de personas que estn en constante interaccin dentro de una estructura de poder y
autoridad para el logro de un objetivo comn valindose para ello de conocimientos y tecnologa.
19

La Organizacin al ser vista como funcin administrativa, significa que es necesario estructurar
e integrar los recursos y rganos responsabilizados de su administracin y establecer relaciones entre
ellos y atribuciones de cada uno de ellos. En este punto es necesario recordar que la teora de la
organizacin se encuentra basada en los siguientes principios establecidos por Henri Fayol
20
en su
Teora Clsica de la Administracin: Divisin del trabajo, Autoridad y responsabilidad, Unidad de mando,
Unidad de Direccin, Centralizacin y J erarqua o cadena escalar.

De acuerdo con Richard Hall, se considera la estructura organizacional como el arreglo de las
partes de la organizacin; la estructura Organizacional es la Distribucin a lo largo de varias lneas, de
personas entre posiciones sociales que influyen en las relaciones de los papeles entre esa gente. Una
consecuencia de esta definicin es la divisin del trabajo; a la gente se le dan diferentes tareas o
puestos dentro de las organizaciones. Otra consecuencia es que las organizaciones tienen rangos o una
jerarqua; las posiciones que ocupa la gente tienen reglas y reglamentos que especifican, en diferentes
grados, cmo deben comportarse los que ocupan estas posiciones.

Otras definiciones enfatizan la importancia de las interacciones humanas en la formacin de
estructuras, puesto que las estructuras configuran prcticas de la gente, pero tambin es cierto que las
prcticas de la gente constituyen (y reproducen) la estructura se ve la estructura como un medio
complejo de control que se produce y recrea continuamente en la interaccin, y sin embargo da forma
a esa configuracin: las estructuras se constituyen y son constituyentes
21
.

Este enfoque enfatiza que la estructura de una organizacin no queda fija para siempre. Ms
bien, configura lo que sucede en una organizacin, y a su vez es configurada por lo que sucede en
dicha organizacin. Resalta que las organizaciones son conservadoras por naturaleza. Su estructura
contituye las interacciones que tienen lugar dentro de ellas.

18
Pascale, Richard T., Athos, Anthony G, El secreto de la Tcnica Empresarial Japonesa Grijalbo, Mx. 1984, Pg. 111
19
Mnch Galindo, Lourdes, Fundamentos de administracin 5. Ed. Trillas, Mxico 1990, Pg. 107
20
Kast, Fremont E, Rosenzweig. James E, Administracin en las Org. Ed. Mc Graw Hill, Mxico 1985 Cap. 3
21
Hall, Richard, Organizaciones: estructura y proceso Mxico, Prentice Hall. Pg. 53

22
Las estructuras organizacionales son una consecuencia del impacto simultneo de mltiples
factores.
22,
De hecho, no existe una explicacin nica para las formas de las organizaciones. Ms bien,
se necesitan mltiples explicaciones para entender la estructura organizacional
. 23

La estructura es un determinante principal de los movimientos y actividades de la gente en el
interior de las organizaciones. Partimos del supuesto que las organizaciones tienen estructuras que se
ajustan a las actividades que se desarrollan en su interior. As por ejemplo, la naturaleza de las
actividades que se realizan en una agencia de publicidad es muy distinta de las que se desarrollan en
una fbrica.

La naturaleza de la materia prima afecta la forma como se estructura y opera la organizacin.
Ya que puede que sea un ser viviente, humano o de otro tipo, un smbolo o un objeto inanimado. La
gente es materia prima en organizaciones que cambian o procesan a la gente; los smbolos son
materiales en los bancos, agencias de publicidad y algunas organizaciones de investigacin; las
interacciones de la gente son materia prima a manipular por los administradores en las organizaciones;
por lo general, los consejos de administracin, comits y comisiones estn involucrados con el cambio o
procesamiento de smbolos e interacciones humanas

De acuerdo con Richard Hall, las estructuras organizacionales cumplen tres funciones, en primer
lugar las estructuras tienen la intencin de elaborar productos y alcanzar objetivos organizacionales, en
segundo trmino, las estructuras se disean para minimizar, o por lo menos regular, influencia de las
variaciones individuales sobre la organizacin. Las estructuras se imponen para asegurarse de que los
individuos se ajusten a los requisitos organizacionales, y no viceversa, y finalmente, las estructuras
constituyen el ambiente donde se ejercita el poder (tambin las estructuras fijan o determinan qu
puestos tienen poder en primer lugar), y dnde se toman decisiones.
24

Actualmente, con la jerarqua tradicional desvanecindose las estructuras organizacionales
estn cambiando continuamente segn se ven influenciadas por las olas sucesivas de sus miembros, las
interacciones crticas entre personas, productos e informacin y las presiones ambientales incesantes. Al
mismo tiempo la naturaleza de surgimiento constante de la estructura no debe cegarnos ante el hecho
de que las estructuras organizacionales tienen fuerte tendencia hacia la inercia. Las organizaciones
altamente complejas se enfrentan a muchos problemas complicados de coordinacin y control. Una

22
Hall, Richard, Ob cit Pg. 92
23
Ibidem. Pg. 93
24
Hall, Richard, Ob cit Pg. 53

23
forma en que se logra dicha coordinacin es por medio de la comunicacinefectiva entre las unidades.
25

I I .2. Vertientes alternas de estructura.

La estructura de una organizacin puede representarse a partir de diversas vertientes y tomar
varios formatos. Estas variantes, producto de la conversin de funciones o procesos en componentes,
fomentan el trabajo en equipo, la creacin de ventajas competitivas para dar un valor agregado a
productos y servicios, el desarrollo de capacidades distintivas basadas en el conocimiento y el empleo
inteligente de la tecnologa de la informacin para emigrar a un contexto capaz de adaptarse a un
entorno de negocios soportado por el aprendizaje continuo.

Proyecto Puro. Tom Peters predice que en el futuro la mayor parte del trabajo en el mundo ser
un trabajo cerebral, es decir, ser realizado a travs de redes semipermanentes de pequeos equipos
orientados al proyecto, cada uno de los cuales constituir por si mismo un centro autnomo de
oportunidades empresariales, en el que las nuevas necesidades de rapidez y flexibilidad traern consigo
un cambio radical en las estructuras administrativas tradicionales. Por consiguiente, Peters se inclina
ms por el proyecto puro, en donde el equipo autnomo trabaja tiempo completo en el proyecto.

Ventajas Desventajas
El administrador del proyector tiene plena autoridad sobre l.

Los miembros del equipo se reportan con un jefe. No tienen
que preocuparse por dividir su lealtad con un administrador
funcional del rea.

Las lneas de comunicacin se acortan. Las decisiones se
toman con rapidez.

Hay un elevado nivel de motivacin y compromiso del equipo.
Duplicacin de recursos. El equipo y las personas no se
comparten entre proyectos.

Se ignoran las metas y polticas organizacionales, debido a que
los miembros del equipo a menudo estn, fsica y
psicolgicamente alejados de la oficina central.

La organizacin se queda atrs en su conocimiento de la nueva
tecnologa debido a las debilitadas divisiones funcionales.

Fig. II.1 Ventajas y Desventajas del proyecto puro
Fuente: Chase, J acobs, Aquilano, Administracin de la produccin y operaciones, McGrawHill,
10. Edicin, Mxico 2005 Pg. 76

Estructuras de lneas y/o proyectos de negocio. La agrupacin de actividades a lo largo de las
lneas de negocio es un modelo que ofrece una forma de aprovechar los beneficios de la curva de
aprendizaje/experiencia de la divisin del trabajo y del empleo inteligente de la tecnologa y equipos
especializados. Desarrollar experiencia en una funcin o proceso de negocio mejora la eficiencia de la

25
Citado en Richard Hall .Ob cit Pg. 51

24
operacin y fortalece una competencia valiosa, lo que en algn momento se convierte en la base para
lograr una ventaja competitiva.

Proyecto funcional. En el otro extremo del espectro de la organizacin del proyecto est el
proyecto funcional, que alberga al proyecto dentro de una divisin funcional.

Un miembro del equipo puede trabajar en varios proyectos.

La experiencia tcnica se mantiene dentro del rea funcional
incluso si los individuos dejan el proyecto o la organizacin.

Los especialistas funcionales pueden ascender verticalmente.

Una masa crtica de expertos especializados en el rea
funcional crea soluciones sinrgicas para los problemas
tcnicos de un proyecto.
Los aspectos del proyecto que no se vinculan directamente con
el rea funcional pueden resultar perjudicados.

La motivacin de los miembros del equipo a menudo es dbil.

Las necesidades del cliente son secundarias y se responde a
ellas con lentitud.

Fig. II.2 Ventajas y Desventajas del proyecto funcional
10. Edicin, Mxico 2005 Pg. 76

Estructura matricial. Una organizacin de matriz es una estructura con dos o ms canales de
mando cuya caracterstica clave es que la autoridad en un negocio/producto/proyecto/empresa y la
autoridad de una funcin o de un proceso de negocios se sobreponen para formar una red o rejilla, con
el fin de compartir la responsabilidad de la toma de decisiones. En esencia, la matriz es un sistema de
trabajo que permite negociar las prioridades estratgicas y de operacin en beneficio de la organizacin
en su conjunto
26
.

La estructura matricial tambin es conocida como Proyecto de matriz. El proyecto de matriz,
que es la clsica forma organizacional especializada, trata de combinar las propiedades de las
estructuras del proyecto funcional y del proyecto puro. Si se elige la forma de matriz, los diferentes
proyectos (renglones de la matriz) toman prestados recursos de otras reas funcionales (columnas).
Despus los administradores senior deben decidir si se va a utilizar una forma de matriz dbil,
equilibrada o fuerte. Esto establece si los administradores del proyecto tienen poca, igual o ms
autoridad que los administradores funcionales con quienes negocian la asignacin de recursos.

26
Franklin F., Enrique Benjamn, Organizacin de Empresas, Ed. McGraw-Hill Interamericana; Segunda Edicin
Mxico 2004 Pg. 106

25

Fig. II.3 Estructura Matricial


26

Mejora la comunicacin entre las divisiones
funcionales.
Un administrador del proyecto se responsabiliza por
la terminacin exitosa del mismo.
Se minimiza la duplicacin de recursos.
Los miembros del equipo tienen su propia rea
funcional, despus de la terminacin del proyecto, de
manera que se preocupan menos por lo que ocurrir
despus de la terminacin del proyecto.
Al seguir las polticas de la organizacin matriz se
incrementa el apoyo para el proyecto.
Hay dos jefes. A menudo se escuchar al
administrador funcional antes que al administrador
del proyecto.
Est condenado al fracaso a menos que el
administrador del proyecto tenga gran capacidad de
negociacin.
La suboptimizacin es un peligro, pues los
administradores del proyecto acumulan recursos
para su propio proyecto, con lo que perjudica a los
dems.

Fig. I I .4 Ventajas y Desventajas del la estructura matricial
10. Edicin, Mxico 2005, Pg. 77

Estructura de Unidad/equipo. Durante algn tiempo las estructuras con estas caractersticas
tambin se denominaron hbridas, ya que en su diseo se emplean unidades representadas por los
rectngulos clsicos y por equipos de trabajo como enlace las reas funcionales y el nivel de
produccin. Si bien esta concepcin abre las opciones del grfico en funcin de su sola configuracin,
tambin rompe con las lneas de mando por rea para dar paso a un modelo que interrelaciona reas y
niveles por medio de equipos. El esquema de operacin tcticamente se apega ms a unidades de
negocio o de carcter matricial que a una lineal.

Fig. II.5 Estructura unidad/equipo
27

27
Franklin F., Enrique Benjamn, ob cit Pg. 107

27

Las prcticas administrativas se relacionan con el tamao de la unidad que se supervisa. La
flexibilidad en la asignacin de personal, el grado de la delegacin de autoridad y el nfasis sobre los
resultados en lugar de los procedimientos se relacionan con el tamao de las unidades mayores.
28

El trabajo se subdivide en forma minuciosa en tareas pequeas y rutinarias
29
y la rutinizacin
est relacionada con la alta formalizacin y centralizacin. Todo ello no corresponde a las actividades
relacionadas con el desarrollo de sistemas.

Diferenciacin Horizontal La diferenciacin horizontal se refiere a la forma en que estn
subdivididas las tareas desarrolladas por la organizacin. Existen dos formas bsicas en las que pueden
subdividirse dichas tareas y dos formas en las que se mide la complejidad. La primera forma en que las
tareas se pueden subdividir es dndole a especialistas altamente calificados una gama amplia de
actividades que deben desarrollar, mientras que la segunda consiste en subdividir las tareas de manera
que las puedan realizar no especialistas. El primer enfoque se ejemplifica por profesionales o
trabajadores muy especializados dentro del ambiente organizacional, que son los nicos responsables
de las operaciones completas. A tal persona se le da la responsabilidad y la autoridad para llevar a cabo
la tarea hasta su terminacin. La segunda forma de diferenciacin horizontal se ve con mayor claridad
en la lnea de ensamble, donde cada obrero desempea slo una o unas cuantas tareas repetitivas.
Aqu, la naturaleza de la tarea misma es importante, puesto que es la tarea rutinaria y uniforme la que
es ms adecuada para el segundo tipo de diferenciacin; las tareas no rutinarias y muy variadas se
subdividen por lo comn de acuerdo con el primer tipo
30
.

Est comprobado que la especializacin acelera el proceso productivo, pero esto slo aplica a
las tareas altamente rutinarias, en donde se tiene la certidumbre de cmo hacer cada una de las
actividades; sin embargo en actividades no repetitivas, que requieren de la creatividad del trabajador,
tal como un mercadlogo, un desarrollador de software, un analista de mercado, etc. Se requiere otro
perfil, en el cual el trabajador sea multidisciplinario

La naturaleza del trabajo del investigador, desarrollador, publicista es muy similar al de un
artista como un pintor, escritor o escultor, ya que en ambos casos el trabajo no es repetitivo, por el
contrario se trata de un trabajo creativo e indagador y es precisamente por la intrnseca naturaleza de
su actividad que no es correcto dar el mismo tratamiento administrativo a las labores no repetitivas que
a las tareas rutinarias.

28
Hall, Richard, Ob cit. Pg. 95
29
Ibidem. Pg. 99
30
Ibidem Pg. 100

28
La idea es que el potencial para el ejercicio del poder est ah, pero rara vez sea invocado, esto
depender de una correcta seleccin y reclutamiento de personal, de colocar a la persona ms apta en
cada puesto, y de motivarlos y capacitarlos constantemente. El poder pues se empleara para disuadir
polmicas y conflictos o para tomar decisiones bajo los criterios institucionales. (el tema de toma de
decisiones propensas o adversas al riesgo est fuera del alcance del presente trabajo)
31

La definicin de una estructura orgnica con el objetivo y las necesidades de funcionamiento de
una organizacin es un requisito indispensable para que sta opere dentro de un rango de actuacin
que le permita generar productos, servicios o ambos acordes con los requerimientos de sus clientes.
32

Burns y Stalker (1961)
33
identificaron la forma mecnica, que es muy cercana al tipo ideal de
burocracia de Max Weber, y la forma orgnica, que es casi su opuesto lgico. De esta manera, en
lugar de tener autoridad jerrquica, las organizaciones orgnicas tienen una estructura de control en
forma de red; en lugar de una especializacin sobre una tarea, un ajuste continuo y redefinicin de
tareas; en lugar de una supervisin jerrquica, un contexto de comunicaciones que involucran
informacin y asesora; ellos conciben las formas organizacionales como estrechamente vinculadas al
ambiente donde las organizaciones estn insertadas, en especial en trminos de tecnologa que utiliza
la organizacin.

Alta especializacin
Departamentalizacin rgida
Cadena de mando clara
Tramos de control estrechos
Centralizacin
Alta formalizacin
Equipos Interfuncionales
Equipos transjerrquicos
Flujo libre de informacin
Tramos de control amplios
Descentralizacin
Baja formalizacin

Fig II.6 Modelo mecnico versus modelo orgnico
34

31
Hall, Richard, ob cit. Pg. 52
32
Franklin F., Enrique Benjamn, Organizacin de empresas, Mc-Graw Hill 2. Edicin. Mxico 2004, Pag. 118
33
Citado en Richard Hall .ob cit Pg. 54.

29
La figura II.7 conceptualiza los elementos anteriores al presentar dos modelos extremos de
diseo organizacional. A un extremo le llamamos el modelo mecnico. Generalmente es sinnimo de la
burocracia ya que tiene una gran departamentalizacin, mucha formalizacin, una red de informacin
limitada (en su mayor parte comunicacin descendente) y poca participacin de los miembros de bajo
nivel en la toma de decisiones. En el otro extremo est el modelo orgnico, el cual es plano, utiliza los
equipos transjerrquicos y funcionales, tiene baja formalizacin, posee una amplia red de informacin
(utiliza la comunicacin lateral y ascendente as como descendente) e involucra una alta participacin
en la toma de decisiones.

La forma de organizacin estable-mecnica es ms adecuada
cuando se aplica lo siguiente:
La forma de organizacin adaptable-orgnica es ms adecuada
cuando se aplica lo siguiente:
1. El medio ambiente es relativamente estable y seguro.

2. Los objetivos estn bien definidos y se mantienen
3. La tecnologa es relativamente uniforme y estable.
4. Hay actividades rutinarias y la productividad es el objetivo
primordial.
5. La toma de decisiones es programable y los procesos de
coordinacin y control tienden a permitir un sistema
jerrquico estructurado de manera estricta.

1. El medio ambiente es relativamente incierto e
inestable.
2. Los objetivos son diversos y cambiantes.
3. La tecnologa es compleja y dinmica.
4. Hay muchas actividades no rutinarias en las que son
importantes la creatividad y la innovacin.
5. Se utilizan procesos heursticos de toma de
decisiones, el control y la coordinacin se producen mediante
ajustes recprocos. El sistema es menos jerrquico y ms
flexible.

Fig. II.7 Condiciones propicias para aplicar el modelo mecanicista y el orgnico

Como regla general, mientras mayor es la calidad de la organizacin, menor es el nivel de
centralizacin
35
. Esto lo podemos apreciar en la seleccin de personal de Microsoft, ya que se dice que
Bill Gates contrata a gente con ms habilidad que la que l posee, ya que, segn l, es la forma ms
eficiente de enfrentarse a la competencia. En general el modelo orgnico fue creado pensando en las
tareas no rutinarias, en donde se requiere de la creatividad de cada uno de sus miembros.

Estructuras mltiples
Existen variaciones intraorganizacionales, tanto dentro y entre las unidades organizacionales,
como hacia arriba y hacia abajo en la jerarqua, de hecho la complejidad, la formalizacin y la
centralizacin varan dentro de una misma organizacin. En ocasiones existe una cantidad mnima de
poder. El potencial para el ejercicio del poder est all, pero rara vez se invoca. En cambio una alta

34
Robbins, Stephen, Comportamiento Organizacional, 8. Ed. Prentice Hall, Mxico 1999, Pg. 497
35
Hall, Richard, Ob cit, Pg. 52

30
centralizacin ocurre cuando se retiene el poder para la toma de decisiones en la cima o cerca de la
parte superior de la organizacin.
36

Las variaciones intraorganizacionales en complejidad se pueden observar en los departamentos
de investigacin y desarrollo, en los cuales existen varios niveles jerrquicos por encima de los
trabajadores de dicha rea, los cuales prefieren estar supervisados con cierta laxitud, con amplio tramo
de control. En los departamentos de fabricacin, es ms corto el tramo de control para cada supervisor,
y la unidad se ver ms como una pirmide.
37

En la figura II.1 podemos observar una
estructura organizacional mixta, con un amplio
tramo de control en donde la parte superior es
lineal-militar y se trata de las personas que
realizan las actividades administrativas (quienes
realizan la evaluacin de desempeo de los
investigadores). En cuanto a la parte inferior est
conformada por las personas que realizan las
actividades de investigacin y desarrollo.

Fig. II.8 Estructura Organizacional Hbrida

I I .3 Conformacin del equipo de trabajo

La organizacin de un proyecto est basada en la existencia de lderes de proyecto o
administradores de proyecto, los cuales dirigen grupos de desarrollo que abordan uno o ms sistemas o
mdulos de la solucin los cuales han sido agrupados considerando los conceptos que en ellos se
manejan y la sincronizacin de desarrollo.

II.3.1 El administrador del proyecto

La seleccin del administrador no siempre es perfecta, por lo general hay un riesgo con
cualquier decisin personal. Por tanto hay que crear conciencia de las caractersticas importantes que
debern formar parte de un efectivo administrador y su equipo de trabajo.

36
37
Ibidem Pgina 56

31
Para hacer la seleccin del personal que formar el proyecto, primeramente deber
seleccionarse al administrador o lder del proyecto, dicha persona tiene el rol principal en la planeacin
y ejecucin del mismo. Para determinar el candidato idneo que administrar el proyecto, usualmente
se debe formar un comit para seleccionar uno de entre varios candidatos.

Se deber de seleccionar a alguien que tenga experiencia conceptual, analtica y prctica;
liderazgo, conocimientos tcnicos, manejo de personal, adems de habilidad y experiencia
administrativa comprobada. Esta persona deber ser experto, capaz y competente para conseguir
objetivos dentro de lo planeado en cuanto a tiempo y costo. El administrador del proyecto es el lder
que ayuda a disear, coordinar e implantar el plan del proyecto. El lder del proyecto es el apoyo
durante toda la duracin del proyecto hasta su liberacin.

En cuanto a conocimientos tcnicos, no podr contar con todos los necesarios dentro del
proyecto, pero ser una persona que pueda dirigir, evaluar y tomar decisiones sobre alternativas
relacionadas con el proyecto. Deber tener experiencia tcnica basada en conocimiento y
entrenamiento, ambos en el contexto del rea que el proyecto demande y en herramientas de
administracin de proyectos. Deber tener la capacidad de entender al mercado, a los clientes, y de
poder involucrarse tecnolgicamente en el proyecto, de igual manera deber tener conocimiento bsico
de organizaciones, por ejemplo, cmo organizar, determinar necesidades de personal, articular las
necesidades del proyecto, los niveles administrativos, ligar la meta del proyecto a la misin de la
empresa as como recompensar y disciplinar a los empleados.

I I .3.2 El Equipo de trabajo.
Una vez que el administrador del proyecto est a cargo, deber de seleccionar a los miembros
del equipo. Para seleccionar al equipo se tomarn en cuenta varios factores:

1. Las metas y objetivos del proyecto.
2. Las necesidades de personal en cada etapa del proyecto.
3. Los objetivos y metas del personal seleccionado.

Se puede determinar el mismo criterio que se utiliz para seleccionar el lder como para
seleccionar al equipo de trabajo, pero de acuerdo a cada rol o puesto, se deber de dar peso a cada
una de las habilidades del candidato.

Una vez que el equipo de trabajo se encuentra formado, y el plan de trabajo elaborado,
debern de asignarse las actividades y responsabilidades de cada uno de los equipos de trabajo.

32

Se deben de formar equipos de trabajo que se encarguen de actividades que estn relacionadas
en forma modular, de las cuales se puede asignar un responsable o administrador, para determinar y
dirigir las actividades de ese mdulo con el fin de que se lleven a cabo de acuerdo al plan general del
proyecto, para el manejo de estos mdulos, existen formatos sencillos que permiten definir que es lo
que se debe de hacer, el plan de trabajo por mdulo y los recursos asignados, adems se deber de
realizar un monitoreo para detectar y corregir posibles desviaciones.

Estos mdulos de trabajo debern definirse claramente, es decir tendrn fechas de inicio y de
terminacin de manera que se pueda ir midiendo el desempeo del equipo. Las actividades de cada
mdulo debern de estar documentadas de manera estandarizada con la finalidad de que a cada
miembro del mdulo se le deber de informar las actividades, los productos y las fechas de entrega de
los mismos. Es muy importante registrar la evolucin del proyecto. Tambin es necesario describir cada
una de las actividades realizadas por cada mdulo, la relacin entre ellos y la relacin con el proyecto y
darlos a conocer a todos los involucrados en el proyecto. Finalmente, se debe presentar de manera
peridica, a todo el equipo de trabajo el avance del proyecto. Se contempla tambin la participacin de
algunas entidades de Staff destinadas a apoyar las actividades de desarrollo.

I I .3.3 Comit de validacin

Estructura funcional. Est conformado por el lder de proyecto el cual posee una visin general
del proyecto y un conocimiento aplicativo integral. Por su parte la gerencia de planeacin y logstica
proporciona la visin administrativa general e informa acerca del dimensionamiento e impactos. En la
parte de desarrollo se encuentran los analistas, los cuales dan un enfoque tecnolgico y su
conocimiento aplicativo modular

El estrato de soporte est representado por: Infraestructura quien proporciona las bases y
estndares y realiza la identificacin de cdigo reutilizable y del adaptable adems del supervisor quien
realiza la revisin de estndares de anlisis, diseo y programacin.


33

CAPI TULO TRES
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

EL ENTORNO DE LOS PROYECTOS DE
SOFTWARE EN MXICO

Yo soy yo y mis circunstancias
38
.
J os Ortega y Gasset

El hombre est en constante evolucin, en ocasiones los cambios son marginales, pero otras
veces, dichos cambios dejan una gran y profunda huella en el quehacer humano. El administrador debe
estar consciente de ello y adaptarse al entorno, a todos y cada uno de los subsistemas del sistema
general, el econmico, el social, el cultural, el poltico, etc. Es por ello que el presente trabajo comienza
con las ltimas transiciones que ha tenido la economa, de la Economa Agrcola a la Manufacturera y
finalmente a la Economa de la Informacin, con sus correspondientes repercusiones (tanto
cuantitativas como cualitativas) en el aspecto laboral.

Es en el contexto de la Economa de la Informacin en donde aparecen las empresas
desarrolladoras de software, con una problemtica muy especfica que deriva de su intrnseca
naturaleza, con ello nos referimos a una labor creativa muy similar a la creacin de obras de arte, lo
cual hace a la actividad de desarrollo de software muy distinta a otros tipos de trabajo como la
actividad agrcola o manufacturera y que incluso la hace distinta de otras empresas del ramo de
servicios. Es por ello que este captulo aborda la problemtica de la administracin de proyectos de
software, sus sntomas y sus causas raz, pretendiendo con ello mitigar los factores que originan los
problemas de tiempo y presupuesto en el desarrollo de sistemas.

38
http://www.ensayistas.org/filosofos/spain/ortega/ortega1.htm (Fecha de Acceso: 17/Abril/2006)

34

I I I .1 LAS TRANSFORMACI ONES ECONMI CAS Y SUS REPERCUSI ONES LABORALES.

La transicin de una economa industrial a lo que se denomina economa de la informacin no
es la primera y tampoco ser la ltima- que producir cambios radicales en las reglas de la actividad
econmica y empresarial. Hace ms de un siglo Estados Unidos dej de ser una economa agrcola para
convertirse en una economa industrial, transicin propiciada por la invencin y el perfeccionamiento de
la mquina de vapor. En la siguiente figura se muestra otra transformacin: La fuerza laboral que
trabajaba directamente en la manufactura en la economa industrial disminuy de 40% a menos de 5%
en la economa de la informacin:

Fig. III.1 Fuerza de trabajo de Estados Unidos en las economas agraria, industrial y de la informacin.
39

En la transformacin econmica anterior, los incrementos de la productividad favorecieron la
unin de una nueva organizacin y una nueva tecnologa, con ello la mayora de los trabajadores del
campo fueron desplazados o reubicados en actividades industriales como la siderurgia, la industria
automotriz y la fabricacin de aparatos electrodomsticos. La actividad industrial requera nuevas
estructuras para organizar los recursos, y tambin nuevos principios para administrarlos (Estas
situaciones generaron las condiciones adecuadas para la aplicacin de las ideas de Frederick W. Taylor
y Henri Fayol).

39 Nolan, Richard, Destruccin creativa, Mc Graw Hill, Mxico, 1996 Pg. 3

35

De manera similar, la actividad relacionada con la informacin requiere nuevas estructuras
para organizar los recursos y adems, nuevos principios para administrarlos. Estamos a punto de ser
una economa totalmente orientada a la informacin
40
debido a que la tecnologa ha penetrado en
todos los aspectos de las organizaciones. En algunos casos ha reemplazado al hombre mismo, dando
lugar a cambios estructurales en las empresas y en la sociedad.
En el contexto de la economa de la informacin vivimos una revolucin informtica y los
paradigmas con los cuales veamos la economa hace 20 o 30 aos no son los mismos hoy en da.
Actualmente, la empresa ms rentable del mundo produce software y la persona ms rica del mundo es
un empresario de software, situacin impensable hace 40 aos, cuando las empresas que integraban
esas listas eran petroleras o siderrgicas. Por otra parte la creacin de empleos durante los ltimos 30
aos se ha dado en empresas ms recientes que tienen menos de 100 empleados, y no en las grandes
empresas.
Esta situacin podra parecer ajena a nuestro entorno, sin embargo segn una investigacin
41

realizada por un diario de la ciudad de Mxico en 1994, se concluy que son las empresas de servicios
las que destinan un mayor monto de sus presupuestos al pago del personal, lo cual no es nada
descabellado, si consideramos que una vez que las empresas del sector servicios cuentan con la
infraestructura necesaria para llevar a cabo sus operaciones, es el capital humano quien se encarga de
generar los servicios y con ello generar valor para las empresas.

Fig. III.2 Monto del presupuesto que se destina al pago del personal por sector (Elaboracin propia)

40
Nolan, Richard, Destruccin creativa, Mc Graw Hill, Mxic o, 1996, Pgs. 3-4 .
Sanders, Donald H. Informtica Presente y Futuro Traduccin de la 1. Ed. En Ingls de Computers Today. 1988 Pgs . 5-7
41
Jurez Hernndez, Othn, Administracin de la compensacin Sueldos, incentivos y prestaciones, Oxford
University Press, Primer edicin; Mxico, 2000; Pg. 3. Se transcribe la nota al pie original: Exclsior, sbado 29
de octubre de 1994, Seccin financiera, primera plana.

36

La anterior situacin pudo ser corroborada mediante un estudio hecho como parte del presente
trabajo de investigacin entre seis de las principales empresas consultoras de software con oficinas en
la ciudad de Mxico
42
. de acuerdo con el Comit Nacional de Productividad e Innovacin Tecnolgica
A.C., y la Asociacin Mexicana de Calidad en Ingeniera de Software quienes destacan a Hildebrando,
IDS, Praxis y Softtek entre los 11 desarrolladores ms grandes de Mxico.
43
Los cuales abarcan la
mayor parte de los proyectos en la Ciudad de Mxico, esto ltimo es corroborado por Enrique Quintana
analista econmico, quien comenta que Las empresas desarrolladoras de software en Mxico apenas
llegan a 206 y de ellas 180 son pequeas o micro
44
,
Al trmino de este estudio se obtuvo como resultado que el sector con mayor nmero de
proyectos de desarrollo de sistemas en el pas es precisamente el sector servicios que, a diferencia del
ramo extractivo y agropecuario est automatizado, en cuanto al sector manufacturero, si bien presenta
un mayor grado de sistematizacin en comparacin con el sector primario en nuestro pas en realidad
son muy pocas las empresas de este sector que adquieren los servicios de una empresa consultora para
desarrollar sistemas de informacin a la medida.
En este orden de ideas podemos decir que el sector servicios es el que ms invierte en
desarrollo de sistemas con el afn de mantenerse a la vanguardia en tecnologa, ser competitivo al
ofrecer ms y mejores servicios, reducir tiempos de respuesta al sistematizar y optimizar tareas y con
ello reducir su plantilla de personal con lo cual disminuye sus egresos por conceptos de remuneracin
del personal.
0
10
20
30
40
50
60
70
SECTOR
PRIMARIO
SECTOR
SECUNDARIO
SECTOR
TERCIARIO

Fig. III.3 Proyectos de desarrollo de software por sector en la ciudad de Mxico (Elaboracin propia Abril 2006)

42
Consultar Anexo A
43
http://www.compite.org.mx/cenec/cenec100305.htm Fecha de consulta: 10 de Septiembre de 2006

37
Finalmente, como se muestra en la Figura III.3 es el sector servicios el que demanda en mayor
medida los servicios especializados en desarrollo de software, sin embargo este sector est
segmentado, razn por la cual presentamos en la Figura III.4, la participacin de cada uno de los tipos
de servicios y su porcentaje de participacin en la muestra levantada:
EDUCATIVO
4%
GOBIERNO
9%
COMERCIO
17%
SALUD
4%
SEGUROS
7%
FINANCIERO
49%
TELECOMUNICACIO
NES
10%

Fig. III.4 Distribucin de proyectos de desarrollo de software en el sector Servicios en la ciudad de Mxico (Elaboracin propia
Abril 2006)
En ese sentido, el desarrollo de software constituye un sector estratgico, ya que se encuentra
en el centro de todas las grandes transformaciones; sobre todo si se considera que temas tales como la
operatividad de muchas empresas, la evolucin de las mismas y la administracin del conocimiento, es
decir de las reglas propias del negocio, se apoya necesariamente en el software.
Las principales aptitudes organizacionales de las empresas dentro de la I ndustria del Software
pueden variar, dependiendo del papel especfico que juegue una empresa dentro de este ramo:

El desarrollo de software es una aptitud clave para todas las empresas de software,
especialmente en ventas de software en donde se agrupa en forma de grupos de producto.
La Administracin de proyectos y la atencin a clientes son aptitudes clave en el desarrollo de
aplicaciones a la medida y entrega de servicios
La Mercadotecnia masiva es una aptitud clave para empresas de producto, con capacidad real
de generar demanda de prospectos

44
http://www.isocmex.org.mx/15-22jul.html Fecha de consulta: 16 de Septiembre de 2006

38
Un negocio de software debe ser capaz de administrar temas generales a cualquier empresa:
Liderazgo de la plana mayor (management team)
Existencia de un plan de negocios apropiado
Capacidad real de venta y mercadotecnia de un bien intangible
Modelo integral de recursos humanos: compensacin, desarrollo de competencias.

El software difiere de otras empresas porque en realidad no es como tal un producto, sino que
se convierte en una funcin o aplicacin de un proceso de negocio. Esto significa que el rango de
aplicaciones generalmente es muy amplio. El software puede apoyar en la produccin de reportes, la
construccin de un puente, la navegacin de un yate, la marcacin de un nmero telefnico o la
compra-venta de acciones en los mercados burstiles. Por ello existen muchsimas categoras en sus
aplicaciones.

Una empresa de software puede primordialmente estar dirigida a la venta de productos
terminados o bien en proporcionar servicios. Ambas estrategias son buenas. Las empresas
distribuidoras de productos terminados tienen muy alta productividad, pero generalmente el costo de la
licencia es solo el 30% del total de la solucin, lo que puede ser excelente oportunidad para las
empresas que prestan sus servicios de desarrollo. De hecho, el mejor modelo es el que permite
balancear el quehacer de la empresa, dependiendo de la situacin de la industria en particular.

En cuanto al mercado objetivo, una empresa puede proveer servicios o productos de software
para diversos clientes:
Por tamao: Corporativo, empresa mediana o pequea, consumidor directo.
Por tipo de solucin: Horizontal, vertical
Por tipo de industria: financiera, gobierno, manufactura, etc.

Las empresas que venden a corporativos tienen ms probabilidades de subsistir, porque pueden
jugar ampliamente con las caractersticas del producto para responder a las necesidades del cliente. En
cuanto al tipo de aplicacin que se desea crear, las soluciones horizontales parecen ser ms atractivas
pues el mercado es mayor. Pero hay muchas variantes en esos distintos mercados. Es decir, los
mercados horizontales requieren grandes inversiones para poder satisfacerlos.

Las empresas ms exitosas que se conocen (Microsoft, SAP) crean aplicaciones horizontales con
mdulos verticales (MS Proyect, el mismo SAP) especficos que sirven para abrir el camino. A su vez, es
necesario determinar en cuntos y cules mercados verticales habr que iniciar.


39
Otra consideracin a tomar en cuenta en el modelo de negocio de una empresa de software es
la de establecer ingresos recurrentes. Esto es, aumentar la predictibilidad econmica mediante
contratos ya sea de largo plazo, de garanta o por evento.

Las empresas que inician operaciones generalmente tienen el fuerte debate entre ser una
empresa de producto, de servicios o hbrida. Los negocios son muy distintos:
El negocio de productos de software es un negocio de volumen. Es clave la capacidad de
mercadotecnia y distribucin para posicionarse como plataforma lder.

El negocio de servicios de software, el cual es sobretodo un negocio muy especializado y
basado en satisfacer necesidades especficas del cliente, basado en capital humano, relaciones
y proyectos. I ncluso, la construccin de software as como el anlisis y la captura de
requerimientos pueden ser de lo ms crticos para la competitividad de la empresa.

Una vez que se ha planteado una somera clasificacin de las empresas relacionadas con el
software, podemos precisar que, el presente trabajo se centra precisamente en este ltimo punto, en
las empresas de desarrollo de software como pieza fundamental de la economa de la informacin, es
por ello que se enfatiza que la actividad relacionada con la informacin requiere nuevas estructuras
para organizar los recursos y adems, adaptar e incluso replantear algunos principios para
administrarlos. Este tipo de empresa se enfrenta a una problemtica muy especfica, la cual se detalla
en la siguiente seccin.

I I I .2 Problemas comunes en la administracin de proyectos de software.

Los problemas tpicos que aparecen en un proyecto de software estn relacionados con los tres
principales aspectos a controlar: tiempo, costo y calidad
45
. A pesar de que hay numerosas razones para
que un proyecto no satisfaga estos aspectos de desarrollo de sistemas, las razones ms comunes son:

La definicin de requerimientos es inadecuada.
La Planeacin del proyecto es inadecuada.
Existen Habilidades tcnicas deficientes en los miembros del equipo.
Falta de trabajo en equipo.
Insuficiente supervisin del avance del proyecto.
I nsuficiente apoyo por parte de la empresa.

45
Sommerville, Ian Ingeniera de Software, 6. Edicin, Pearson Educacin, Mxico 2002, Pg. 9-13

40
Como podemos ver estos problemas tambin estn ntimamente relacionados con el factor
humano. Los puntos del I I I .2.1 al III.2.5 fueron extrados del material del mdulo de Ingeniera de
software del Diplomado en Administracin y Desarrollo de sistemas impartido por el Centro de
Desarrollo Empresarial y Ejecutivo en el Tecnolgico de Monterrey Campus Cd. De Mxico en Abril de
2000. Veamos a detalle cada uno de ellos.

I I I .2.1 Definicin de requerimientos inadecuada.

Los requerimientos de un sistema son normalmente definidos por el usuario de sistemas.
Cuando los requerimientos son nuevos, el cliente tiene a menudo dificultades para expresar estos
requerimientos en forma completa y consistente, y en trminos que puedan ser entendibles para el
desarrollador de sistemas. Cuando hay un entendimiento impreciso de las necesidades del usuario final,
los requerimientos deficientes generan invariablemente diseos deficientes. Esta situacin genera un
problema si los requerimientos no pueden ser negociados y modificados por diversas razones
contractuales.

I I I .2.2 Planeacin I nadecuada.

Todo proyecto sigue un plan escrito desde el comienzo del mismo. Debido a que los desarrollos
de sistemas son muy dinmicos es necesario actualizar los planes de manera que reflejen la
comprensin y estado actual del sistema para evitar que en el futuro se lleven a cabo acciones que
traigan consigo una gran cantidad de problemas.

Si desde un principio los objetivos originales del proyecto no estn bien planteados o no
corresponden con los objetivos particulares de la empresa, el producto que se genere no ser ptimo.
Tambin puede suceder que el proyecto no siga el plan original, debido a que no se le da el correcto y
oportuno seguimiento, mediante reuniones peridicas, con los responsables. El plan no cuenta con el
detalle suficiente como para poder desglosar las actividades adecuadamente.

I I I .2.3 Habilidades tcnicas deficientes.

El personal encargado de llevar a cabo las actividades de tipo tcnico deber ser altamente
capacitado de manera que se reduzca al mnimo posible el tiempo para la solucin de problemas. Es
importante, por ello, que la Administracin del Proyecto mantenga un personal tcnico excelente
evitando movimientos frecuentes del mismo reduciendo as la curva de aprendizaje general y la falta de
habilidad para mantener requerimientos cambiantes, sin embargo si no es posible retener al personal y

41
la rotacin es bastante frecuente, es necesario contar con una estructura organizacional que soporte
estos cambios.

I I I .2.4 Falta de trabaj o en equipo.

En ocasiones el equipo de desarrollo no tiene buena comunicacin, ni hay un esfuerzo
coordinado, lo cual va en contra de uno de los principios bsicos de la administracin. En la actualidad
los sistemas de informacin son muy complejos y requieren de la interaccin continua de los miembros
que participan en su construccin. En ocasiones en un proyecto existen personas que no poseen la
habilidad de trabajar en equipo trayendo consigo la prdida de esfuerzos conjuntos.

I I I .2.5 I nsuficiente supervisin del avance.

Las revisiones sobre el estado de un proyecto en ocasiones no son llevadas a cabo
peridicamente sino hasta que se programa una revisin formal. Una de las tareas de la administracin
de proyectos es realizar supervisiones informales que permitan determinar el avance, posibles
problemas y necesidades que eviten la prdida del control y con ello el fracaso; incluso en ocasiones no
existe un responsable del proyecto, que le d seguimiento y administre adecuadamente los recursos
(tiempo, recursos econmicos, recursos materiales y recursos humanos).

I I I .3 La Crisis del Software: Panorama del Origen del Problema

La Ingeniera de Software es una disciplina relativamente joven, surge formalmente en 1968
cuando por primera vez se hace mencin a la crisis del software. Este trmino se refiere a que el
proceso de desarrollo de software no posee las caractersticas que se presentan en el desarrollo del
hardware
46
(Equipo fsico, tal como los dispositivos electrnicos, magnticos y mecnicos) y esto debido
a que en el desarrollo de hardware a diferencia de su contraparte de software intervienen muy
contadas personas, adems de que el hardware es el primero que avanza. Las computadoras
evolucionan vertiginosamente, en cuanto a capacidad, velocidad y disminucin de costos, ocasionando
su popularizacin, en cambio, el proceso de desarrollo de software, en 1968 era un proceso informal,
caracterizado por retrasos en los tiempos de entrega, con fuertes problemas durante la operacin y el
mantenimiento que sobrepasaba la capacidad de los desarrolladores, adems las perspectivas de
mejorar este proceso con respecto a la complejidad creciente de los sistemas eran desalentadores. An
cuando se han desarrollado desde entonces modelos y mtodos para manipular la complejidad del
software, an se tienen problemas con los sistemas desarrollados, de ah que se considere que la

46
Sanders, Donald H., Informtica Presente y Futuro Trad. De la 1. Ed. En Ingls de Computer Today 1988 Pgs. 5-7

42
Ingeniera de Software padece de una afliccin crnica
47
, ya que crisis se define como el momento,
etapa o evento decisivo en el curso de algo.

En las ltimas dos dcadas se ha dado un aumento sin precedentes de la aplicacin y uso de la
tecnologa computacional. El incremento en el uso de la computadora ha causado lo que se ha
denominado como crisis del software, la cual de acuerdo con I an Sommerville y Roger Pressman,
autores de libros en I ngeniera de Software (incluidos en la biliografa del presente trabajo) tiene ciertos
sntomas:

La complejidad del software producido y demandado se incrementa constantemente, por su
parte la industria del software no ha podido satisfacer la demanda, esto ha provocado que el software
sea de baja calidad, por lo que la confiabilidad de los sistemas se ha cuestionado. Al hablar del
desarrollo de sistemas, el tiempo y presupuesto para los proyectos son excedidos o bien el proyecto no
cuenta con los recursos suficientes en tiempo o est bajo en presupuesto; los mdulos no encajan entre
s, por lo que el software resulta difcil de mantener o extender. Por otro lado, se descubren en forma
tarda fallas crticas del proyecto, adems de que el desempeo del software es inaceptable
48
.

En ocasiones el proyecto es una solucin en busca de un problema, lo cual suena descabellado
y sin embargo es un problema comn en nuestro entorno nacional. En muchos casos, basados en la
experiencia obtenida en el medio, se disean herramientas de software, para despus ser colocadas a
la venta, sin embargo, dichas herramientas no pasaron por el visto bueno de un usuario final, un
ejemplo de esto lo constituye el sistema de Asistencia Mdica y Hospitalaria (ASIMEDH), el cual fue el
resultado de una lnea de investigacin de la empresa Softtek, en el cual se creo primero el sistema y
despus se busc un cliente para su venta. En ocasiones estas situaciones se originan en la labor de
venta de los servicios de desarrollo de software, en donde el vendedor con tal de lograr consumar la
venta hace promesas al cliente, muchas de ellas carentes de un sustento real.

En otros casos el equipo del proyecto es el nico interesado en el resultado final, esta situacin
se origina cuando no se le da la suficiente importancia a los proyectos de software, o bien no se tiene la
suficiente difusin de los beneficios para la empresa y para los empleados que reportara el proyecto
una vez que se haya terminado.

47
Pressman, Roger S., Ingeniera del Software. Un enfoque prctico, 4. Edicin Mxico 1998. Mc Graw Hill, Pg.12
48
Booch, Grady, Rumbaugh, J ames, J acobson, Ivar, Rational Unified Proccess Fundamentals, Ed. Itera; Edicin (Versin) 5.5,
ao de publicacin 2001. Mdulo 1, Pgs. 5 y 6.

43
I I I .3.1 Factores que influyen:

Los sistemas de software tienen una gran cantidad de usuarios y aunque en ocasiones el
sistema se hace "a la medida del cliente", el tipo de usuario no es homogneo, ya que en muchas
ocasiones "es una persona quien lo requiere y es otra la que lo usa", adems requiere de mucho
personal para su desarrollo y mantenimiento (nmero de desarrolladores, detalles tcnicos y control
administrativo), en este rubro podemos profundizar mencionando que es muy comn que quienes
desarrollan un sistema son distintos de quienes le dan mantenimiento. Finalmente, podemos comentar
que los cambios, tanto tecnolgicos como en el entorno y de las necesidades del usuario impactan en el
proyecto de software, tanto en tiempo como en presupuesto.

Entre las Causas Raz de los diversos problemas descritos en la seccin anterior tenemos, que la
comunicacin entre los usuarios y los desarrolladores es ambigua e imprecisa, la complejidad de los
requerimientos es considerable, adems de que hay una insuficiente administracin de requerimientos,
existen inconsistencias no detectadas en los requerimientos, el diseo y las implementaciones; los
productos terminados no son probados suficientemente y hay una pobre administracin en el control de
cambios

Fig. III.5 Enfocndose en las Causas Raz los sntomas se eliminan
Fuente: Booch, Grady, Rumbaugh, J ames, J acobson, Ivar, Rational Unified Proccess Fundamentals, Ed. Itera; Edicin
(Versin) 5.5, ao de publicacin 2001. Mdulo 1, Pg. 7.

Todo lo anterior nos lleva a formularnos varias preguntas: Cmo desarrollar eficientemente
software?, Cmo dar mantenimiento al cada vez mayor volumen de software?, Cmo poder mantener
al corriente a la creciente demanda de software?, Por qu lleva tanto tiempo terminar los programas?,
Por qu desarrollar software es tan caro?, Por qu no podemos encontrar todos los errores?, Por qu
es tan difcil evaluar el avance?


44
Las primeras respuestas a las preguntas son muy intuitivas, ya que desarrollar un proyecto de
software es una labor muy creativa, todos los que participan deben aportar su creatividad. Segn
Donald H. Sanders (1988) Preparar programas computacionales ha sido y es un arte que requiere
cuidado especial
49
La materia prima es la informacin, por lo tanto es intangible, por ello es difcil ser
objetivos en la evaluacin del progreso.

Otra situacin comn es caer en el error de suponer que al desarrollar software usando nuevas
tecnologas los tiempos de desarrollo descienden de manera considerable, en realidad es que no
necesariamente es cierto, ya que est sujeto a muchas situaciones, tales como la experiencia, baja
rotacin del personal, programas de seleccin de personal adecuados, entre otros.

DELIMITACIN DEL PROBLEMA

Una investigacin del grupo Standish demuestra que 31.1% de proyectos sern cancelados
antes de ser terminados. Otros resultados indican que 52.7% de proyectos costarn 189% de sus
estimaciones originales. El costo de estas faltas y los sobrantes son slo la punta del iceberg proverbial.
Los costes de oportunidad perdidos no son mensurables, pero podran fcilmente estar en el orden de
los billones de dlares.
50

Esta situacin puede ser abordada desde muchos puntos de vista, tales como el punto de vista
tcnico especializado, metodolgico, o bien como en el presente trabajo con un enfoque administrativo,
y ms especficamente desde el punto de vista de la Administracin de proyectos. Por ello uno de los
objetivos del presente trabajo es enfatizar el trabajo en equipo y mejorar la comunicacin interna.

El presente trabajo se centra en mejorar el desempeo en el desarrollo de sistemas, hacer ms
predictivos los tiempos de entrega de los productos e incrementar la calidad de los productos de
software desarrollados, es decir, en general se centra en mejorar el proceso de desarrollo de sistemas a
travs de la aplicacin de la Administracin

Una vez que se ha planteado la problemtica actual, es importante remarcar el objetivo de la
presente tesis, el cual es generar una propuesta de estructura organizacional para instituciones
prestadoras de servicios de desarrollo de software, buscando con ello mejorar el desempeo, evitar la
prdida de conocimiento, mitigar los riesgos derivados de las curvas de aprendizaje, lo cual redunde en
un aumento en la productividad de la organizacin.

49
Sanders, Donald H., Ob cit Pgs. 5-7

45
Los cambios en la estructura de la organizacin, en las funciones por puesto, en la motivacin
de los empleados, redundarn en una mejora en el desempeo general de la empresa, debido a que el
proceso de desarrollo propuesto ser hecho a la medida de las necesidades de dicha empresa.

Es importante enfatizar que el tipo de organizacin al que va enfocado el presente trabajo se
ubica en el sector servicios de desarrollo de aplicaciones de software hechas a la medida, esta
expresin se deriva de que se dice de los sistemas de software que son hechos exactamente como lo
pide el cliente, el trmino es muy similar a los trajes de vestir a la medida.

El perfil de empresa al que est dirigido este trabajo, es la que tiene funciones tales como
recabar los requerimientos de los usuarios mediante entrevistas, realizar el anlisis y diseo de dichos
requerimientos, desarrollar (programar) aplicaciones de software hechas a la medida de las necesidades
del cliente, corroborar que no existan errores al usar los sistemas, dar mantenimiento a los sistemas ya
desarrollados, en pocas palabras, el ciclo completo de desarrollo de software.

Las variables independientes que se consideran en el presente trabajo son la forma de
organizar y realizar la funcin sustantiva, redefiniendo las funciones de cada puesto, creando con ello
una organizacin con clulas de conocimiento, mediante la flexibilidad de la organizacin para
adaptarse al intercambio de roles, la centralizacin y descentralizacin de la toma de decisiones, la
formalizacin y la comunicacin.

La productividad se puede obtener al lograr mayor eficiencia en el trabajo que desempee cada
empleado, evitando al mximo los tiempos muertos del personal, estandarizando la forma de trabajar
de los empleados, homologando los conocimientos en los integrantes de la empresa, compartiendo
ciertas funciones y teniendo una buena comunicacin.

A continuacin se presenta el flujo de la investigacin, la cual tiene dos vertientes: La
investigacin bibliogrfica, por un lado y, la experiencia y las aportaciones personales por otro.

Fig. III.6 Flujo de la Investigacin Fuente: (Elaboracin propia)

50
www.standishgroup.com/sample_research/chaos_1994_1.php (Fecha de Acceso: 17/Abril/2006)

46

CAPI TULO CUATRO

____________________________________________________________________________________________

HISTORIA DE LOS CICLOS DE DESARROLLO
DE SOFTWARE
Una organizacin bien diseada no es una solucin estable que se deba
alcanzar, sino un proceso de desarrollo que se mantiene activo.
51

Starbuck y Nysrom.

Uno de los factores que determinan la estructura de una organizacin es la tecnologa
52
, en esta
poca llamada Era de la informacin, la Tecnologa de la Informacin (en otras palabras el Software)
resulta un buen punto de partida para entender la divisin del trabajo dentro de una organizacin
desarrolladora de software, por ello el presente captulo hace una breve semblanza histrica de cmo
se ha ido modificando la forma de organizar y distribuir el trabajo en las empresas desarrolladoras de
sistemas, se pretende describir la forma en la cual se organiza al personal de una organizacin que se
encarga de crear tecnologa de informacin para otras organizaciones, se describen modelos de
procesos y someramente se menciona un mtodo de evaluacin para el desarrollo y mantenimiento de
software, por otra parte, en el siguiente captulo se hace la propuesta de una estructura organizacional
basada en clulas de conocimiento, la cual resulta ms acorde a estos tiempos en donde se pretende
evitar la prdida de conocimiento.

I V.1 Modelo de desarrollo de software
El proceso de desarrollo de software es, una secuencia de actividades que producen dicho
software
53
. Se ha visto que las fases principales son: requerimientos, anlisis, diseo, codificacin o
construccin y pruebas, todas estas actividades en ocasiones son divididas en actividades de ms bajo
nivel. Un modelo para el proceso de desarrollo de software especifica como estas actividades son
organizadas durante el desarrollo del software.

Varios modelos del proceso de desarrollo de software han sido desarrollados a lo largo de los
aos, el objetivo de describir los siguientes modelos es para observar la evolucin en la forma de

51
52
Hall, Richard, Ob cit Pgs. 97 103.
53
Softtek, Proceso de Desarrollo de Software de Softtek, Sosfftek Educacin en Tecnologa, Mx. 1997, Pg.17

47
organizar tanto al personal que desarrolla el software, como a las actividades intrnsecas en dicho
proceso, todos y cada uno de los modelos tienen ventajas y desventajas, posteriormente se muestra un
cuadro comparativo, para que el lector tenga los elementos suficientes para determinar la factibilidad
de implementar alguno de ellos bajo condiciones especficas. Finalmente, se describe el Modelo de
Proceso de Software, un modelo diseado para empresas mexicanas, todo ello para que el lector tenga
un panorama de los diversos esfuerzos que preceden a la presente propuesta en materia de
organizacin de empresas dedicadas a la actividad de desarrollo de software. Dicha evolucin ha sido
de la siguiente manera:

a) El Desarrollo del Modelo de Procesos
En este modelo no hay planificacin sino que las cosas son simplemente hechas como y cuando
son requeridas, por ejemplo cuando el cdigo ha sido escrito entonces la documentacin es considerada
y normalmente al final del proyecto se escribe la especificacin, por supuesto de esta manera el
software esta sincronizado con las especificaciones.

b) La Codificacin y el arreglo del modelo
Es un proceso iterativo donde el cdigo es desarrollado en fases, cada fase contribuye a la
siguiente modificacin, liberacin y fase de prueba y entonces regresa al mismo punto para modificarlo
nuevamente. Aunque trabaja bien en sistemas pequeos una persona puede acomodar y cambiar los
requisitos en proyectos grandes lo que lo hace difcil de administrar, desarrollar, probar y modificar
porque se desarrolla la codificacin en partes, en forma fragmentada y por consiguiente no est
estructurada.

c) El modelo Evolutivo
Los paradigmas o modelos de desarrollo de software son enfoques que guan el proceso de
desarrollo. An no existe un modelo que sea considerado como el definitivo, pero todos ellos buscan
que en el desarrollo de un sistema de software se maneje la complejidad, cumpla con los
requerimientos, se genere en tiempos razonables, su operacin sea exitosa y el mantenimiento fcil de
realizar.

Los modelos del proceso de desarrollo de software se pueden considerar como abstracciones.
En la prctica y dependiendo de la complejidad del sistema, es posible que se puedan utilizar varios
modelos a la vez, combinando sus caractersticas. A continuacin se presentar una breve descripcin
de las caractersticas bsicas de los modelos siguientes: El ciclo de vida del software o modelo de
cascada, El Desarrollo evolutivo y Desarrollo basado en componentes o reutilizacin.

48
IV.1.1 Modelo del ciclo de desarrollo en cascada
El modelo o ciclo en cascada es uno de los ms utilizados, proporciona un estricto control en
cada paso de la construccin del software pues pone mucho nfasis desde el inicio en los
requerimientos.

Se compone por 5 fases (aunque en algunos casos se realiza una divisin ms detallada y se
pueden ver 6 o hasta 7 fases en este modelo), las cuales son:

1. Anlisis del requerimiento
Que permite desmenuzar y entender lo que se busca con el fin de empezar a planear el proyecto
antes de involucrarse en l u omitir algn punto de riesgo.

2. Diseo
Va dirigido a definir el comportamiento externo deseado del sistema antes de disear su
arquitectura externa y evitar realizar modelos que reflejen la proyeccin de avances o incluso
posibles formas en que se pueden presentar los atrasos con respecto al tiempo y a los recursos que
finalmente pueden ser simples predicciones para completar el proyecto

3. I mplementacin
Es la puesta en marcha en un determinado equipo para documentar los resultados de cada
actividad para no encontrarse con el retraso en agregados de integracin o de utilidad que no se
haya considerado.

4. Pruebas
Busca no liberar un proyecto de manera temprana y que pueda repercutir con el resultado final
buscado en el proyecto, por ello se somete a un proceso de prueba para que se puedan identificar
cualquier tipo de errores

5. Mantenimiento
Despus de que cada una de las fases es terminada y el sistema ha entrado a produccin se requiere
una lnea de atencin que observe y valide el buen funcionamiento de software entregado
54
.

Fig. I V.1 Ciclo de Desarrollo en Cascada

-
54
Sommerville, Ian, Ingeniera del Software, Addison Wesley Iberoamericana, S.A., Segunda edicin, Mxico,
1988, Pg. 4

49
El modelo en cascada se asegura que no se inicie una fase si antes no es terminada la anterior
y que siga una secuencia como la que se marca en el diagrama, sin embargo rara vez ocurre esto pues
muy pocas personas estn educadas con una mentalidad de disciplina, lo que deriva en que cualquiera
de estas fases se pueda repetir varias veces pues comnmente se encuentran deficiencias las cuales se
erradican muchas veces hasta que el sistema es corregido totalmente.

Lo anterior sucede porque usualmente los errores no son detectados por las distintas revisiones
en las primeras fases sino hasta que el sistema es liberado, lo que lleva a tener retroalimentaciones
tardas y generacin de reprocesos para identificar la fase donde se origin el error.

Adems de lo mencionado, a continuacin se presentan, en la Figura IV.2, algunas ventajas y
desventajas muy visibles en este modelo cascada:

Si se completa una fase es ms fcil manejar la siguiente

Implementa el manejo de una disciplina al entender la filosofa
del modelo

Promueve la generacin de documentacin en cada fase
Los requerimientos usualmente no se definen en su totalidad al
inicio del proyecto pues la informacin disponible es limitada

Si existe algn cambio es muy difcil de adaptarlo pues adems
no se anticipa hacia lo que puede estarse presentando en el
entorno

La identificacin de errores comnmente no se logran ver
hasta que se tiene una parte muy avanzada del proyecto

Es muy costoso por la reinversin de tiempo y recursos para
corregir los errores o implementar algo nuevo lo que lo lleva a
ser poco confiable.

Hay asignacin de diferentes equipos en cada fase
Congela las decisiones tempranamente en el desarrollo del
documento

El usuario por lo general desconoce el alcance total de la
aplicacin que le es entregada (software)

Fig. I V.2 Ventajas y Desventajas del modelo en cascada (Elaboracin propia)


50

I V.1.2. Desarrollo evolutivo

El desarrollo evolutivo surge al reconocer que el software evoluciona con el tiempo. La
caracterstica principal de este modelo es que es iterativo y en cada iteracin se desarrollan versiones
ejecutables cada vez ms completas del sistema. Usa prototipos para los requerimientos de las
versiones. Aunque inicialmente proporciona una visibilidad muy buena del producto al usuario y una
rpida capacidad operacional, la desventaja es que se puede desarrollar una mala codificacin, esto
puede dificultar el reemplazo y el manejo del software existente
55
.

En este modelo se detectan varios enfoques: El desarrollo de prototipos, el modelo en espiral,
el modelo incremental y el desarrollo basado en componentes.

El desarrollo de prototipos se utiliza cuando los usuarios no tienen claros sus requerimientos al
inicio del sistema. Un prototipo es una versin inicial de un sistema que se utiliza para demostrar
conceptos, opciones de diseo y en general propuestas de solucin al problema. El modelo de
desarrollo evolutivo es un modelo iterativo que busca que las operaciones de especificacin, desarrollo
y prueba se lleven a cabo concurrentemente, elaborando un prototipo inicial y refinndolo de acuerdo
con los comentarios del usuario, logrando ambos una mejor comprensin del sistema. El modelo de
prototipos tiene el inconveniente de que, por la rapidez de desarrollo, no es posible considerar
funciones crticas como puede ser la seguridad o el desempeo
56
.

Dentro de este modelo se detectan dos vertientes: el desarrollo exploratorio y los prototipos
desechables. El desarrollo exploratorio inicia el proceso de desarrollo de software con aquellos
requerimientos que el usuario tiene mejor definidos y en cada iteracin se le agregan nuevos
requerimientos. En el caso de los prototipos desechables, la funcin del prototipo slo es clarificar los
requerimientos, despus de la evaluacin, el prototipo es desechado, no se utiliza como base para el
desarrollo posterior. En ocasiones se utiliza esta tcnica para el desarrollo de interfaces de usuario, para
que el usuario pueda interactuar y aclarar de esta forma los requerimientos.

En el desarrollo exploratorio de prototipos se tienen dos ventajas principales: la entrega
acelerada del sistema, ya que es ms importante la entrega y el funcionamiento del software que la
documentacin, implementacin eficiente o el mantenimiento posterior; y el compromiso del usuario
con el sistema, dado que ste se involucra con el proceso de desarrollo. El proceso genera en cada

55
Rational University, Requirements Management with Use Cases, Student Manual Version 2002.05.00 Pag. 1-9
56
Sommerville, Ian, ob cit. Pg. 39

51
incremento un producto ejecutable de ah que los procesos de especificacin, diseo e implementacin
se entrelazan. Por la naturaleza del modelo, se utilizan herramientas de desarrollo rpido de
aplicaciones, lenguajes de 4 generacin y lenguajes para desarrollo de interfaces grficas.

I V.1.3. Modelo del ciclo de desarrollo en espiral

El modelo espiral hace nfasis en los riesgos y costos y no se descompone el proceso
fcilmente en niveles detallados. Se basa en cuatro actividades:
Planificacin. Equivale a la recoleccin de requisitos en el modelo tradicional (cascada). Adems se
planean las actividades a realizar en cada iteracin, posteriormente se determinan objetivos y
restricciones. En el anlisis de riesgo se I dentifican y gestionan los riesgos, se estiman la probabilidad, y
se evalan las consecuencias, en la actividad de ingeniera se desarrolla un prototipo y cdigo y se
realiza la implementacin y realizacin de pruebas, manual del usuario. Finalmente la evaluacin del
cliente y valoracin de los resultados equivale a la liberacin en el modelo tradicional. El modelo de
espiral, es altamente terico, contiene una pequea gua de como adaptar, planear o ejecutar un
proyecto y se enfoca en la continua necesidad de refinar los requerimientos y estimaciones.
57

57
Pressman, Roger S. Ingeniera del Software. Un enfoque prctico. 6. Edicin 2002. Mc Graw Hill, Pg.54

52

Fig. IV.3 Ciclo de Desarrollo de Espiral
Fuente: Microsoft Student Workbook Solutions Development Discipline. Microsoft 1997. Pg. 65

53

Todo lo anterior produce una sinergia entre el equipo de desarrollo y el cliente, ya que los
clientes son involucrados en todas las etapas, produciendo una retroalimentacin al proyecto.

-Interactivo. Si es necesario repetir algn proceso, slo se
pierde el esfuerzo de una iteracin y no el valor del producto
completo.

-Activa participacin del cliente ya que es involucrado en
todas las etapas, produciendo retroalimentacin.

-Reduce el riesgo sobre fechas de entrega pactada al
comienzo del proyecto.

-Incrementa actividad. Acelera el ritmo del desarrollo global
ya que los desarrolladores trabajan de forma ms eficiente
cuando ven objetivos a corto plazo.

-Acepta el hecho de que las necesidades de los usuarios y
por tanto los requisitos, no se pueden definir
completamente desde el principio, sino que son refinados en
iteraciones sucesivas.

-Salta a cdigo sin tener un anlisis bien slido.
-No se descompone el proceso fcilmente en niveles detallados

Este modelo es altamente terico, y requiere no slo mucha
disciplina de cada uno de los integrantes, sino de una gran
sincronizacin entre todos los colaboradores del equipo de
trabajo.

Es complejo caro y riesgoso. Involucra mucha gente y mucho
tiempo. Por ello es conveniente usarlo en proyectos de
investigacin.

Fig. I V.4 Ventajas y desventajas del modelo de Espiral

IV.2.- Caractersticas del proceso unificado de desarrollo de software

Este proceso tiene las siguientes caractersticas fundamentales: est dirigido por casos de uso,
est centrado en la arquitectura, es iterativo e incremental, est basado en componentes
interconectados a travs de interfaces y utiliza el lenguaje unificado de modelado (UML por sus siglas
en ingls) para su representacin, adems este lenguaje se usa para documentar, diagramar y modelar
un entorno determinado.

Dirigido por Casos de Uso. Los casos de uso son una herramienta que ha sido ampliamente
utilizada para la captura y representacin de requisitos, ya que permite identificar a los usuarios -
representados como actores-, la forma de interactuar de ellos con el sistema y representar los
requisitos en forma comprensible para los usuarios, clientes y desarrolladores. Un actor que interacta
con el sistema da origen a un caso de uso. Los actores no necesariamente son personas, tambin
pueden ser componentes software o hardware.
58

Un caso de uso
59
se define como: una secuencia de acciones, incluyendo variantes, que el
sistema puede llevar a cabo, y que producen un resultado observable de valor para un actor concreto.

58
Jacobson, Ivar., Booch,Grady, Rumbaugh, James, El Proceso Unificado de Desarrollo de Software. Addison
Wesley. 2000.

54
El conjunto de actores y casos de uso del sistema forman el Modelo de Casos de Uso, que
constituye una especificacin completa de todas las posibles formas en que se puede utilizar el sistema,
delimita sus alcances y gua el proceso completo siguiente que incluye las etapas del anlisis, el diseo,
la implementacin y la prueba del sistema, donde se obtienen los Modelos de Anlisis, Diseo y
Despliegue, Implementacin y Prueba, respectivamente.

Centrado en la Arquitectura: La arquitectura de software
60
define el sistema en trminos de sus
componentes computacionales y la interaccin entre ellos. La arquitectura de capas
61
, trata de
representar cada capa como una coleccin de software que proporciona un conjunto de servicios que
otro software puede utilizar sin saber como son implementados los servicios. El conjunto de servicios
debe ser cohesivo de forma de que al realizar cambios, estos cambios afecten solo una capa

Iterativo e Incremental: Ya que el proceso es iterativo e incremental, la estrategia del proceso
es que en cada iteracin se analice, disee, implemente y pruebe un conjunto de casos de uso y que el
sistema progrese incrementalmente a medida de que se consideren ms y ms casos de uso. El anlisis
del sistema se lleva a cabo mediante la identificacin de la estructura de clasificadores(diagrama de
clases), la realizacin de los casos de uso y diagramas de colaboracin. Un clasificador es un
mecanismo que describe caractersticas estructurales y de comportamiento e incluye interfases, clases,
tipos de datos, componentes y nodos.

El modelo de diseo toma al Modelo de Anlisis como entrada, pero toma en cuenta el entorno
de implementacin a utilizar, por lo que este modelo es ms fsico que conceptual. En este modelo
tambin se utiliza el diagrama de clases, pero se incluyen ms detalles que en el Modelo de Anlisis
para reflejar la adaptacin del modelo al entorno de la implementacin. Tambin se utilizan los
diagramas de secuencia que muestra como se trasmite el control de un objeto a otro para el caso de
uso. En este modelo tambin se agrupan las clases en subsistemas, definiendo la interfaz de cada
subsistema. El modelo de despliegue, permite representar grficamente la distribucin del software en
los diferentes nodos de red y su comunicacin entre ellos.

59 Ibidem. Apndice A. Pg. 413
60
Cromwell, Jeff, The Art and Science of Software Architecture. Dr. Dobbs Journal Software Tools for the
Proffessional Programmer. Vol.25, Issue 6, Jun. 2000. Pg.143.
61
Pgina web de Software Engineering Institute (SEI) de la Universidad de Carnegie Mellon
http://www.sei.cmu.edu/publications/documents/00.reports/00sr004.html Fecha de acceso Abril de 2006

55

Fig. IV.5 Cuadro comparativo de modelos de desarrollo (Elaboracin propia)

CARACTERISTICA CASCADA ESPIRAL

ITERATIVO

DIAGRAMA

Implantacin en la
realidad.

Es el ms comnmente
implantado, aunque en
muchos casos no es lo
mejor.

Es un modelo un
tanto Terico y no
es comnmente
implantado,

Es una de las mejores
prcticas de Desarrollo
de Sistemas

Hace mayor nfasis
en:

Los requerimientos y el
diseo proporcionando
un estricto control en
cada paso de la
construccin del
software.

Los riesgos y costos
del desarrollo de
software.

(Aade el elemento
de anlisis de riesgo)

Las refinaciones
sucesivas.

Avances visibles para
el usuario

No se puede ver con
claridad el sistema sino
hasta que ya se lleva
una parte avanzada.

Salta a cdigo sin
tener un anlisis bien
slido.

Cada iteracin termina
con la liberacin de un
ejecutable.

Interaccin con el
usuario

No fomenta la
interaccin con el
usuario.

Comparado con el
modelo de cascada,
es ms interactivo
porque activa la
participacin del
cliente.

Debido a las
refinaciones sucesivas
permite una
retroalimentacin
continua con el usuario.

Administracin de los
requerimientos

Trabaja con los
requerimientos
congelados, aunque se
dificulta definir todos
los requerimientos
desde el inicio del
proyecto

Alcance sinrgico.
Los cambios a los
requerimientos son
identificados ms
fcilmente por la
interaccin con el
usuario.

Facilita la inclusin de
cambios tcticos a los
requerimientos o a las
caractersticas.

Puntos de evaluacin
que determinan el
avance.

Los resultados de cada
fase se congelan antes
de seguir a la siguiente,
lo cual proporciona un
control en cada paso de
la construccin.

Sus requerimientos
son analizados con
cada giro, en un
Estudio de la
factibilidad.

Ayuda a identificar los
problemas antes de
cada fase del proceso de
desarrollo.

Administracin del
Cambio

Es muy difcil de
adaptar si se quiere
realizar algn cambio.

Comparado con el
modelo de cascada,
no se dificultan
mucho los cambios.

En este modelo es ms
fcil hacer cambios.

56

CARACTERISTICA CASCADA ESPIRAL ITERATIVO

Fechas de Liberacin

Es monoltico en el
sentido de que toda la
planeacin es orientada
en una sola fecha de
liberacin.

Es muy rgido con
respecto a la fecha de
liberacin

No hay lineamientos
de fechas de entrega

Facilita la inclusin de
cambios al calendario,
aunque con las
revisiones peridicas
del status se asegura
que se mantenga en el
calendario establecido.

Forma de atacar el
problema

Define todo el problema
antes de comenzar,
aunque puede ser solo
una aproximacin a la
realidad

Realiza un prototipo
y anlisis de riesgo
en cada vuelta de la
espiral.

Permite un
entendimiento
incremental del
problema a travs de
refinaciones sucesivas.

Manejo de la
Complejidad en
etapas

Cada una de las fases
no debe ser iniciada
hasta que la anterior
sea terminada, de
hecho el fin de cada
fase suele ser la
entrada a la siguiente y
una vez que cada fase
ha sido completada es
ms fcil manejar la
siguiente.

Estructura un
proceso en una serie
de fases donde la
salida de una fase
constituye la entrada
de otra.

Es un modelo que se
basa en la realizacin de
pruebas despus de
cada etapa del proceso

Crea una solucin
efectiva mediante
mltiples iteraciones.

Forma de trabajo

Diseado para realizar
una serie de pasos bien
definidos.

Los planes son basados
en la suposicin de
linealidad

Cada fase es
estructurada como
un conjunto de
actividades que
deben ser ejecutadas
por diferentes
equipos al mismo
tiempo.

Reduce riesgos
mediante liberaciones
frecuentes.

Desventajas

Puede presentar
inconsistencias.

Puede llegar a
requerir de mucha
administracin del
proyecto

Puede ser tardado por
tantas pruebas que se
llevan a cabo

Puntos Importantes

Es flexible para
adaptarse a las
necesidades de la
organizacin y permite
la especializacin.

Introduce la
programacin y
prueba modular as
como la integracin y
prueba del sistema

Nos ayuda a evitar
problemas futuros en el
sistema con lo cual evita
la prdida de tiempo y
dinero


57
IV.3 El Modelo de Proceso de Software de la Asociacin Mexicana de Calidad en I ngeniera
de Software

Una vez que se han abordado los ciclos clsicos de desarrollo de sistemas, es pertinente
mencionar que, en nuestro entorno nacional, se han hecho esfuerzos encaminados a entregar
productos de calidad, productos que estn dentro de un periodo de tiempo y de un presupuesto
acordados antes del comienzo de los ciclos de desarrollo. La informacin que se presenta a
continuacin, se obtuvo del material del seminario impartido en la Ciudad de Mxico por la empresa
Itera SA en combinacin con la Asociacin Mexicana de Calidad en I ngeniera de Software (AMCI S A.C.)
el 8 de junio de 2006 en el D.F.

En la figura IV.6, se pueden apreciar los esfuerzos independientes, y prcticamente
simultneos, de la Organizacin Internacional de Estndares (International Stardard Organization ISO),
el Software Engineering Institute (SEI) de la universidad de Carnegie Mellon y de la Asociacin
Mexicana de Calidad en Ingeniera de Software (AMCIS) durante los ltimos tres lustros.

Fig. IV.6 Evolucin del Modelo Normativo

Es quiz la certificacin I SO 9001:2000, la ms conocida en general, sin embargo fue el Modelo
de Capacidad y Madurez o CMM, por sus siglas en ingls, el primero en retomar las ideas de los crculos
de calidad de Edward Deming, adems cabe mencionar que, este ltimo es un modelo de calidad

58
enfocado al desarrollo de software, que describe un camino par evolucionar desde un proceso
inmaduro, a uno maduro y disciplinado. Pese a ello, las empresas mexicanas (incluso del sector
servicios), con el afn de certificarse para cumplir con estndares internacionales y as ser ms
competitivas en el mbito mundial, es que comienzan a certificarse bajo los parmetros de ISO
9001:2000, a pesar de que este mtodo est enfocado a las empresas manufactureras, empresas de
sector secundario.

El CMM por su parte, aunque enfocado muy especficamente en las empresas de desarrollo de
software, est completamente dirigido al entorno norteamericano, un entorno muy distinto al entorno
nacional. Dados estos antecedentes la Secretara de Economa solicita que se desarrrolle una Norma
mexicana verificable, esta norma es un sistema de gestin de la calidad de los procesos de desarrollo y
mantenimiento de software para las PYMES, la cual es desarrollada por la Asociacin Mexicana de
Calidad en la Ingeniera de Software (AMCIS) y emitida como norma por el NYCE (Normalizacin y
Certificacin Electrnica A. C.), la cual es una asociacin civil sin fines de lucro creada en noviembre
de 1994 por un grupo de empresas lderes de los sectores de Electrnica, Telecomunicaciones y
Tecnologas de Informacin de Mxico, convencidas de la necesidad de contar con un organismo de
jurisdiccin nacional que tomara en cuenta sus necesidades, en la certificacin del cumplimiento con las
Normas Oficiales Mexicanas aplicables a los productos de la rama.

En la figura IV.7 se puede observar el desarrollo del esfuerzo mexicano dentro del campo de la
calidad en los productos de software.

Fig. IV.7 Historia de MoProSoft (proporcionado por la AMCIS)

59

En 1996, acadmicos de universidades pblicas y privadas y personas dedicadas al desarrollo
de software en Mxico, se renen y crean el Crculo de Calidad Mexicano, que sent las bases para que
un ao ms tarde se creara la AMCIS, la cual con la colaboracin de sus miembros dan vida
conceptualmente al Proceso de desarrollo de Software, el cual se dio a conocer en el ao 2002 como
ProSoft, en ese mismo ao la Secretara de Economa patrocina este proyecto y es as que se conforma
el Modelo de Proceso de Software Mexicano o MoProSoft, el cual es implantado en muchas empresas, y
que a diferencia del CMM del SEI, es una gua de implantacin de procesos totalmente pensado para el
entorno mexicano.

Un ao ms tarde se da a conocer la pieza restante, el mtodo de Evaluacin (EvalProSoft). El
propsito del mtodo de evaluacin de procesos, EvalProSoft para la industria de software es, otorgar a
la organizacin solicitante un perfil del nivel de capacidad de los procesos implantados en la
organizacin y un nivel de madurez de capacidades, en la siguiente figura es posible observar los
distintos niveles que se pueden obtener mediante la aplicacin de MoProSoft y que, mediante las
evaluaciones que se realicen con el EvalProSoft, se puedan verificar.

Finalmente , podemos comentar al respecto que, la norma mexicana NMX-I- 059/NYCE fue
publicada en el diario oficial en Agosto del 2005, y sta ha sido implantada en 140 empresas.

Fig. IV.8 Niveles de capacidad por proceso

60

El nivel de madurez de capacidades de una organizacin corresponde al mximo nivel de
capacidad alcanzado por todos los procesos evaluados, de esta forma las organizaciones que se
califican con un nivel de madurez uno son las que realizan de alguna manera el desarrollo de software,
las que se ubican en el nivel dos tienen un mejor control de la ejecucin del proceso y del desarrollo de
productos, cuando las empresas alcanzan un nivel de madurez tres es porque ya tienen un proceso
definido que reproducen una y otra vez al desarrollar sistemas, adems de contar con una adecuada
distribucin de sus recursos durante el desarrollo del proceso. Las organizaciones que logran un nivel
cuatro son organizaciones maduras, que tienen estadsticas histricas referentes a los resultados de sus
propios desarrollos, los cuales les permite predecir o inferir tiempos y costos con un alto nivel de
certeza y llevar un control ms puntual sobre sus desarrollos. Finalmente, las organizaciones que
alcanzan un nivel de madurez cinco, constituyen modelos de organizaciones, lo que representa ser una
referencia para el resto de las organizaciones, el prestigio de estas organizaciones no slo se basa en la
certeza de sus estimaciones, sino en la mejora continua sobre sus procesos de desarrollo.

Es importante resaltar que el modelo MoProSoft cubre el 92% del modelo I SO 9001:2000, el 88%
del Nivel 2 de CMM y el 77% del nivel 2 del CMMI , esto puede dar la apariencia de una cobertura
parcial e incompleta, sin embargo, esto obedece a la adaptacin de los mencionados procesos a nuestro
entorno nacional.

Propiedades y ventajas del modelo MoProSoft

MoProSoft est conformado por varios procesos, cada uno de los procesos corresponde a un
cierto nivel organizacional de administracin, esto es, hay procesos para el equipo directivo, para los
mandos medios o equipo de coordinacin y, finalmente, procesos relacionados a quienes se encargan
de ejecutar las funciones sustantivas de la organizacin, esto puede corresponder tanto a una
organizacin tradicional con una estructura de tipo pirmide, como con una organizacin hbrida, como
la que se propondr en el siguiente captulo.

Los procesos del MoProSoft son relacionados, con los procesos operativos de la organizacin,
esta relacin entre procesos se establece mediante la identificacin de los productos de trabajo de
entrada y salida y la definicin de las responsabilidades de los roles que participan en ms de un
proceso, simplificando con ello la relacin entre el modelo de procesos y la organizacin.

61

Alineacin con objetivos de negocio

El proceso de Gestin de Negocio enfatiza la importancia de alinear todas las actividades de la
organizacin a los objetivos del negocio a travs de la elaboracin, difusin, valoracin y mejora del
Plan Estratgico.

El Plan Estratgico sirve de gua a los dems procesos de la organizacin logrando de este
modo una alineacin explcita con los objetivos de negocio.

Se enfoca en el producto y su capitalizacin

Se identifican los productos y las actividades de verificacin y validacin a las que deben estar
sometidos dichos productos, adems el proceso de Conocimiento de la Organizacin administra una
base de conocimiento que controla y asegura la disponibilidad de los productos de trabajo a travs de
un mecanismo comn.

Capacidad organizacional de gestin de procesos

El proceso referente a la Gestin de Procesos, establece la capacidad organizacional para la
planeacin, definicin, implantacin, evaluacin y valoracin de procesos; este proceso est regido por
las directrices de Gestin de Negocio, lo que asegura la alineacin con los objetivos.

Capacidad organizacional de gestin de proyectos

Se distingue entre la administracin a nivel proyecto (Administracin de Proyecto Especfico) y
la gestin del portafolio de proyectos de la organizacin (Gestin de Proyectos).

La Gestin de Proyectos facilita la Identificacin de iniciativas y proyectos; la provisin,
asignacin y reasignacin de recursos a programas y proyectos; y el mantenimiento del balance del
portafolio.

La Gestin de Recursos se encarga de establecer un ambiente de trabajo adecuado (bienes
muebles e inmuebles, servicios e infraestructura) para que los recursos humanos asignados a las tareas
de desarrollo y mantenimiento de software puedan llevar a cabo los ciclos de desarrollo de sistemas


62
En la figura IV.9 se muestran las interacciones entre todos los procesos antes descritos:

Fig. I V.9 Modelo MoProSoft (Proporcionado por la AMCI S)


63

CAPI TULO CI NCO
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

PROPUESTA DE LA ESTRUCTURA
ORGANIZACIONAL PARA UNA EMPRESA DE
SERVICIOS DE DESARROLLO DE SISTEMAS

La clula de una sociedad del conocimiento es un trabajador con
conocimientos, es decir, un empleado que aporta valor a la empresa al
suministrar o interpretar informacin
62

Richard Nolan.

La base de conocimiento de las organizaciones est rompiendo inercias y paradigmas. En un
contexto en el que el cambio es intrnseco a las acciones, el quehacer administrativo no puede
sustraerse. Esto ha generado la imperiosa necesidad de focalizar la administracin con otra perspectiva,
de replantear su contenido para amalgamar la tcnica con el movimiento y emigrar a nuevas formas de
expresin organizacional que pueden tomar vertientes que empezamos a explorar.
63

Se propone una forma de organizar al recurso humano que conforma a la empresa o al rea de
desarrollo de software, con el objetivo de elevar la productividad de la institucin mediante el
aprovechamiento al mximo de los recursos con los que cuenta, y de mejorar la calidad del software
construido y disminuir el tiempo de desarrollo.

Se pretende reorganizar al personal en equipos constituidos por integrantes de diferentes
especialidades o disciplinas, que tengan ms o menos el mismo nivel jerrquico, que lleven a cabo
proyectos que requieran de la mezcla de distintas especialidades para disear, fabricar o comercializar
un nuevo producto, proceso o tarea especfica, independientemente de su origen organizacional.

Todo proceso de desarrollo de software intenta implementar un cierto grado de disciplina
(formalizacin), lograr una eficiente comunicacin, y un mejor aprovechamiento de los recursos
(personas, tiempo, dinero). La presente propuesta involucra la forma de organizar a las personas y que
la divisin del trabajo en las empresas prestadoras de servicios de desarrollo de software, sea hecha

62
Nolan, Richard, Destruccin creativa, Mc Graw Hill, Mxico, 1996. Pg. 23
63
Franklin F., Enrique Benjamn, Organizacin de empresas, Mc-Graw Hill 2. Edicin. Mxico 2004, Pg. 110

64
sobre la base de contar con trabajadores interdisciplinarios, es decir, que posean conocimiento en
varias reas, la aplicacin de ello ser lo que genere la plusvala, y el valor para la empresa.

En este orden de ideas, este captulo expone una propuesta de Estructura Organizacional, la
cual se desglosa en los siguientes puntos:

Propuesta de organizacin o Descripcin de la estructura organizacional mixta o hbrida.
Descripcin de los casos de la expansin y de contraccin de la estructura.
Propuesta de flujos de trabajo en los casos que se desarrolle tanto con el paradigma de
programacin estructurada y la orientacin a objetos

La propuesta. Consiste en una organizacin orgnica que desde su diseo se pens en que
estuviese preparada para la expansin y para la contraccin con la menor prdida de conocimiento.
Cada elemento de la estructura de clula laboral tiene el mismo nivel jerrquico, sin embargo, cuando
haya que tomar una decisin o arreglar un conflicto se acudir a un nivel superior en el tramo de
control. La estructura propuesta es mixta ya que la plana mayor se mantiene con una estructura lineal
militar, (Ver Fig. V.1 Estructura Organizacional Hbrida), esto minimiza la resistencia al cambio por parte
de los estratos encargados de la toma de decisiones en la empresa.
Bajo normas de racionalidad, las
organizaciones agrupan puestos para minimizar
los costos de coordinacin localizndolos y
hacindolos condicionalmente autnomos
primerodespus recprocamente independientes,
despus unos interdependientes en forma
secuencial, y por ltimo agrupando los puestos
de manera homognea para facilitar su
estandarizacin.
64

Fig. V.1 Clula laboral (Diseo Propio)

El contexto poltico del proceso de toma de decisiones tiene una relacin importante con la
estructura. Por ejemplo, la gente que lleva a cabo tareas no rutinarias es probable que tenga poder a
causa de sus habilidades; aqullos que realizan tareas rutinarias no tienen esa fuente de poder. Las
personas con habilidades reclaman y reciben ms poder discrecional, o una ms amplia

64
Hall, Richard, Organizaciones: estructura y proceso Mxico, Prentice Hall. Pg.7 98 y 99

65
descentralizacin, como algo que se gan desde una posicin de poder, en lugar de algo que se deleg
desde arriba.
65

V.1.1 Caso:Expansin

En pocas de bonanza cada uno de los tres elementos se convierte en un lder de proyecto que
coordina a dos nuevos elementos de un nuevo equipo, los cuales pueden ser nuevos empleados de
nmina, o bien consultores, personal temporal e incluso personal en entrenamiento. La persona que
funge como lder cumple una importante funcin: comparte y conserva el conocimiento.

Fig. V.2 La Estructura es constituyente: en pocas de crecimiento es posible reproducir la estructura minimizando
la curva de aprendizaje, este modelo tambin ayuda a permear el conocimiento.

65
Ibidem. Pg. 111


66

V.1.2 Caso:Contraccin

En las empresas, una de las metas es mantener el tamao de la organizacin al mnimo para
reducir los costos. el incremento de tamao se relaciona con el incremento en la estructuracin de
las actividades organizacionales y una menor concentracin de autoridad
66
.

En pocas de recesin este modelo se puede contraer sin perder conocimiento ya que son los
lderes de cada equipo, quienes regresan a conformar el equipo original, adems coadyuva a mantener
el tamao de la organizacin al mnimo para reducir costos.

Fig V.3 En pocas de recesin es posible que el personal se reduzca al mximo sin perder conocimiento.
(Diseo propio)

66
Hall, Richard, ob cit. Pg. 95

67

La Estructura del Equipo de Desarrollo est organizada de tal manera que pueda soportar
mltiples proyectos simultneamente sobre una misma plataforma tecnolgica y productos diferentes.
Permitiendo al equipo poder enfocarse en diferentes actividades y habilidades requeridas para el
desarrollo de software.

Como se muestra en la Figura V.4, la estructura del equipo de desarrollo est dividida en
diferentes equipos de roles, permitiendo su interaccin con los diferentes recursos de la organizacin
del cliente. Cada uno de esos roles puede ser un equipo conformado por ms de una persona. De esta
forma es posible que los equipos puedan ser estructurados de tal manera que se tenga un mejor uso
del conocimiento de un simple individuo.

Estructura Tradicional (Antes) Estructura Hbrida (Despus)

Fig. V.4 Estructura del Equipo de Desarrollo (Esquema tradicional y propuesto)

En este punto, es pertinente enfatizar que mas que hablar de ventajas y desventajas, se debe
hacer incapi en que cada uno de estos modelos responde a ciertas necesidades especficas, ya que
mientras que el modelo tradicional est enfocado a organizaciones que desempean actividades
altamente rutinarias, por su parte, el modelo propuesto (hbrido: lineal militar y de clulas de
conocimiento) est enfocado en propiciar una baja centralizacin, es decir, propicia la participacin de
las personas que forman la base de la organizacin en la toma de decisiones, lo cual es necesario en el
tipo de empresas cuya materia prima son las ideas, el conocimiento y que las capacidades requeridas
en los empleados sean multldisciplinarias. la presente propuesta ofrece la suficiente flexibilidad para

68
que las personas que se encuentran en la base de la organizacin puedan tomar ciertas decisiones ya
que se encontrarn respaldados por sus colegas de equipo, sin embargo en el momento que haya
alguna polmica sta se dar por concluida invocando la autoridad del jefe inmediato superior, quien
tomar la decisin final.

Una empresa puede controlar a su personal en varias formas, mediante las reglas
(Formalizacin), centralizando las decisiones (Centralizacin), o bien, motivando al personal ya sea
positivamente (con premios) o negativamente (Castigos).

En estos tiempos de cambio constante, es indispensable contar con un cierto grado de
formalizacin, ya que la documentacin constituye la base del conocimiento, en torno al cual se
generan los productos y servicios de las empresas de desarrollo de software.

Es de suponer que se generen conflictos y que puedan surgir discusiones cuando choquen la
normatividad que cada profesional traiga de su alma mater, con la formalizacin propia de la empresa.
Sin embargo, el tema de la formalizacin deber revisarse en forma constante, porque seguramente
habr circunstancias que necesiten un estndar a aplicar, en tanto que otras situaciones se deber
privilegiar la plena libertad, para que la creatividad, aspecto prcticamente imprescindible en este tipo
de empresas, pueda florecer.

Para una correcta implementacin, se recomienda tomar un proyecto piloto cuya consigna ser
enfrentarse antes que nadie en la empresa a los nuevos problemas generados por las nuevas
situaciones que surjan al aplicar la forma de trabajo propuesta, darles solucin y as adquirir experiencia
y conocimiento que ms tarde se podr aplicar en el resto de los proyectos. Por supuesto que toda
situacin y problema (con su correspondiente solucin o alternativa por lo menos) deber ser
documentado en bitcoras de errores, de versiones, etc. Ser como un ente que ir a la punta con el
objetivo de minimizar las probabilidades de que se repita una situacin no deseada. A continuacin se
describe la propuesta del flujo de informacin para los dos paradigmas de desarrollo utilizados.

V.2. Desarrollo de sistemas con orientacin funcional o estructurada

Secuencia de procesos de anlisis estructurado

La secuencia comienza con la recopilacin de informacin de todo lo referente al mdulo que se
va a construir, el siguiente paso es la generacin de los diagramas que contienen las entidades lgicas y
sus relaciones, posteriormente se generan los documentos de anlisis cuya funcin es formalizar dicho
anlisis para su posterior revisin, todas estas actividades son realizadas por el analista y con la

69
asesora directa del usuario. Una vez que se obtiene lo anterior, el analista genera los procesos
involucrados en el mdulo, as como las operaciones bsicas que componen a dichos procesos, ambos
productos (procesos y operaciones bsicas) son validadas por el analista en conjuncin con el lder de
proyecto.

En la Fig. V.5 se presenta un diagrama que muestra el flujo que se sigue para la realizacin del
anlisis de acuerdo al paradigma estructurado.

Da Doc. De Anlisis al
Lder de Proyecto
A
B A
Entrega Diseo para
Correccin
s
B
I
Analista
Retroalimenta al
Analista
Da Correcciones
Lder Proyecto Analista
Realiza correcciones
Y las entrega
Lder Proyecto
Da Visto bueno al
analista si el anlisis es
Correcto.
Analista
Realiza el
Diseo del
mdulo
Lder Proyecto
Revisa diseo y da
Visto Bueno
C
Analista
Redacta
Especificaciones
Realiza Check List,
Casos de prueba
C
Lder Proyecto
Revisa Check List y
Casos de prueba y da
Visto Bueno
D
Analista
Analista
Archiva
expediente
y
libera anlisis
D E
Genera expediente
de anlisis y entrega
Al lder Proy.

Fig. V.5 Diagrama de flujo de informacin del proceso de anlisis estructurado (elaboracin propia)

Una vez que el lder de proyecto revisa los documentos de anlisis, procede a retroalimentar al
analista en cuanto a las correcciones (si es que las hay) que se le tuviesen que hacer al mdulo, paso
siguiente, el analista realiza las correcciones hasta que el lder de proyecto da su voto aprobatorio, en
ese momento el analista da comienzo a la realizacin del diseo, producto para el cual se sigue el
mismo procedimiento que para el anlisis, una vez que se cuenta con el anlisis y el diseo aprobados
el analista procede a toda la documentacin de cada uno de los programas que conforman al mdulo,
estos ltimos pasan a ser validados por el lder de proyecto, finalmente se elabora el expediente del
anlisis para su posterior liberacin.

70
V.3. Desarrollo de sistemas con orientacin a objetos

El concepto de programacin orientada a objetos se utiliz inicialmente para aquellos sistemas
desarrollados con lenguajes orientados a objetos, sin embargo, su evolucin ha logrado conformar toda
una metodologa de I ngeniera de Software que comprende, desde el anlisis de requisitos hasta el
desarrollo del sistema y su mantenimiento. Surge como una respuesta a la necesidad de realizar
software de calidad en corto tiempo, con menor costo y mayor facilidad en su mantenimiento,
adaptacin y escalabilidad.

Secuencia de procesos de anlisis orientado a objetos

La secuencia comienza con la delimitacin del alcance a cubrir, esta actividad la realizan el
analista conjuntamente con el lder de proyecto, el siguiente paso es la recopilacin de informacin de
todo lo referente al mdulo que se va a construir, posteriormente se generan los documentos de casos
de uso cuya funcin es formalizar el anlisis para su posterior revisin, todas estas actividades son
realizadas por el analista y con la asesora directa del usuario. Una vez que se obtiene lo anterior, el
analista genera los diagramas de secuencia y los diagramas de clases involucrados en el mdulo, ambos
productos (diagramas de secuencia y de clase) son validados conjuntamente por el analista, el lder de
proyecto y el comit de revisin.

Una vez que el lder de proyecto revisa los documentos de casos de uso, procede a
retroalimentar al analista en cuanto a las correcciones (si es que las hay) que se le tuviesen que hacer
al mdulo, paso siguiente, el analista realiza las correcciones hasta que el lder de proyecto da su voto
aprobatorio, en ese momento el analista da comienzo a la realizacin del diseo correspondiente al caso
de uso aprobado, producto para el cual se sigue el mismo procedimiento que para el anlisis, una vez
que se cuenta con el anlisis y el diseo de un caso de uso aprobado el analista procede a redactar las
especificaciones del programa, los check lists y los casos de prueba de cada uno de los programas que
conforman al mdulo, estos ltimos pasan a la correspondiente validacin por parte del lder de
proyecto, finalmente se elabora el expediente del anlisis para su posterior liberacin. Este
procedimiento deber de seguirse para todos y cada uno de los casos de uso que se generen.

71

En la Fig. V.6 se presenta un diagrama que muestra el flujo seguido para la realizacin del
anlisis de acuerdo al paradigma orientado a objetos.

Generacin
de
Documentacin
al 100%
Reunin
de
Comit
Presentacin
y
Revisin
Seleccin de
clases comunes
APROBACIN
y
FORMALIZACIN
Transformacin de
clases a modelo
de entidades
relacionales
Entrega al Lder
de Proyecto y
solicitud de fecha
para utilizacin
Incorporacin a
BD por parte
del Lder de P.
Entrega a
Infraestructura
para construir
clases comunes
Pblica
clases comunes
liberadas a
Analistas
INICIAR
DISEO
SI
NO
*
* Entregar a logstica
la documentacin de los
subproductos generados
completa y en limpio.
Entrega
a integrantes
del comit

Fig. V.6 Flujo del anlisis orientado a objetos (Elaboracin propia)

72

POLI TI CAS Y PROCEDI MI ENTOS DE LA FASE DE ANLI SI S

El lder de proyecto deber entregar el documento de alcance funcional al analista, el cual por
su parte debe entregar a cada integrante del comit de revisin una copia de su anlisis, previo a su
revisin (Es deseable que el tiempo de anticipacin para esta entrega no sea mayor a un da hbil). El
anlisis deber estar concluido al 100% antes de su revisin.

El analista deber hacerse responsable de calendarizar la presentacin y revisin de su anlisis
con el comit de validacin, cuidando no rebasar el tiempo estimado para la actividad.
El comit de validacin aprobar la liberacin del anlisis una vez que ste ha sido revisado a detalle.
Dicha aprobacin ser formalizada en un documento conocido como Formalizacin del Anlisis,
firmado por cada uno de los integrantes del comit. Es responsabilidad del analista documentar los
subproductos finales que sean requeridos y entregar al rea de logstica el original junto con el
documento de aprobacin.

Los casos de uso al ser aprobados sern congelados por el rea de logstica y cualquier
cambio al mismo ser controlado por el rea de control de cambios.


73

Secuencia de procesos de diseo orientado a objetos

El analista se encarga de la generacin de diagramas de estado, el diseo de interfaces, la
validacin de entidades, as como de la generacin de especificaciones, la validacin del diseo lo
realiza el analista conjuntamente con el comit de validacin.

Los Subproductos generados durante el diseo orientado a objetos son las Especificaciones, el
diagrama de entidad relacin, el diagrama de estados y las interfaces

Paquete
anlisis
APROBADO
Generacin
diagramas
de
estado
Generacin
de
especificaciones
Generacin
interfases
(pantallas)
APROBACIN
y
FORMALIZACIN
Reunin
de
Comit
Presentacin
y
Revisin
Asignacin
a
PROGRAMACIN
*
SI
Validacin
de
entidades

Fig. V.7 Flujo del diseo orientado a objetos (Elaboracin propia)

74
Polticas y Procedimientos de infraestructura
El lder de infraestructura recibe la solicitud del analista previamente avalada por el comit,
analiza y determina la complejidad de la solicitud reflejando su duracin en el formato de programacin.
Posteriormente, realiza la asignacin de tareas a los recursos de su rea. Los subproductos generados
sern, el plan de trabajo, las funciones, Clases, Casos, etc. que se generen y el Documento de
Publicacin.

Es responsabilidad del lder de infraestructura validar su plan de trabajo con el lder de proyecto
y posteriormente darlo a conocer a los analistas, as como asegurar que la infraestructura generada
cumpla al 100% con las especificaciones, documentar los subproductos finales y entregar al rea de
logstica el original junto con el documento de aprobacin. La infraestructura desarrollada deber ser
congelada y publicada por el rea de logstica y cualquier cambio ser controlado por el rea de
control de cambios.

Secuencia de procesos de infraestructura
El lder de infraestructura y el analista solicitante, validan la solicitud y realizan el anlisis del
requerimiento. El lder de infraestructura asigna a un programador para que se realice la construccin
de la infraestructura solicitada, y son ellos mismos quienes realizan pruebas unitarias. Por su parte, el
comit realiza la validacin correspondiente y procede a su publicacin y liberacin

Construccin
Paquete
anlisis
APROBADO
Analisis
del
Requerimiento
Asignacin
de
Tareas
Generacin
de
Caso
Prctico
PUBLICACIN
*
Prueba
de
Liberacin
APROBACIN
y
FORMALIZACIN
Presentacin
y Revisin
con Comit
SI
NO

Fig. V.8 Flujo de infraestructura (Elaboracin propia)

75
V.4 I ntenciones competitivas en la compensacin.

Mediante el diseo y la administracin de la compensacin, es factible atraer, retener y obtener
recursos humanos con cierto grado de calidad, acorde con la poltica planteada e idneo para la
operacin de la empresa. En otras palabras la factibilidad econmica incide fuertemente en la
factibilidad operativa, sin embargo esta ltima depender de la correcta seleccin y reclutamiento del
capital humano, el cual es sumamente importante en las empresas de desarrollo de software, por lo
cual, a continuacin se muestran tres formas distintas de compensar al personal:

La figura V.9, fue pensada para ejemplificar diferentes formas de pago en diferentes empresas,
aqu se retoma la idea, pero para aplicarla dentro de una misma empresa. Para los recin ingresados se
puede aplicar el lag match (ajuste con retraso), en donde el trabajador percibe un salario mediante el
cual tiene un cierto poder adquisitivo, con el tiempo la inflacin crece y el poder adquisitivo
paralelamente disminuye, hasta que en el siguiente punto de revisin salarial, la empresa ajusta los
salarios. Para los empleados que ya tienen mas tiempo en la empresa se puede usar el leadlag match
(ajuste con adelanto-retraso) en el cual se le otorga un incremento real al trabajador, dicho incremento
colocar el poder adquisitivo del empleado por encima de la inflacin, aunque sea por un corto tiempo,
hasta que dicho poder adquisitivo empiece a disminuir, cuando llegue el siguiente ajuste, el empleado
volver a contar con un poder adquisitivo por encima de la inflacin (un supervit). Finalmente, el lead
match (ajuste con adelanto) puede ser ocupado para motivar y retener al personal que genere valor
para la empresa, ya que con cada ajusta que se le otorgue, prcticamente por lo general estar por
encima de la intencin competitiva del mercado.
67

El nivel de compensacin depende, en buena medida de las caractersticas del sector econmico
en que compite y de la disponibilidad del tipo de personal para estar en condiciones de competir
eficazmente con ventajas en dicho sector.

67
Jurez Hernndez, Othn, Administracin de la compensacin Sueldos, incentivos y prestaciones; Oxford
University Press; Primer edicin; Mxico 2000; Pg.84

76

Fig. V.9 Intenciones competitivas de compensacin

77

CONCLUSI ONES
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Al comienzo de la elaboracin de este trabajo surgi una pregunta cmo refutar la frase es un
mal con el que tenemos que vivir?, y al trmino de esta tesis se concluye que son varias las formas y
distintos los ngulos mediante los cuales se puede intentar abordar y contestar esta pregunta: La
interaccin entre las personas genera conflicto, el cual es un mal necesario, ya que si el conflicto es
correctamente administrado puede traer consecuencias positivas para la empresa, debido a que
posiblemente es factible sacar provecho o aprender de las situaciones adversas y con ello lograr una
estabilidad dinmica. Es imprescindible determinar las causas y tratar de solucionarlas, muchas
ocasiones es necesario renovar ideas; finalmente, sabemos que en muchos casos, los conflictos se
resuelven con la imposicin de la autoridad, sin embargo tenemos que pensar en trminos de grupo, ya
que generar un buen clima laboral generalmente tiende a rendir buenos resultados.

La naturaleza del desarrollo de sistemas de software es similar a la de la investigacin y a la vez
a la creacin de obras artsticas (pinturas, esculturas u obras literarias), sin embargo, cuando el
desarrollador interacta con sus clientes hace estimaciones de tiempos de entrega y se compromete a
terminar "obras" en tiempos y con recursos especficos y limitados, adems, hoy en da la competencia
a escala mundial plantea desafos a los que no se puede hacer frente slo con la tcnica o los recursos
financieros. Por ello concluimos que la capacidad para competir se apoya en la capacidad para organizar
a los seres humanos, de manera que produzca oportunidades y resultados, y no puntos muertos,
estancamiento, burocracia ni fricciones.

Anteriormente se deca que Las personas constituyen el activo ms valioso de toda empresa,
sin embargo, es cierto slo en parte, concluimos que se requiere acotar esta aseveracin: Las personas
que generan valor constituyen el activo ms valioso de toda empresa es por ello que quienes
conforman el desarrollo del proyecto deben ser motivados, mediante los mecanismos de carrera
profesional, lo cual genera un compromiso hacia los proyectos y hace que el trabajo sea de mayor
calidad.

Se ha buscado una solucin no genrica, pues como sabemos no podemos hacer
generalizaciones, y menos an tratndose de personas, sin embargo pensando a futuro se plantea la
viabilidad de crear una organizacin de aprendizaje, la cual tenga una estructura flexible que se pueda

78
adecuar tanto a la expansin como a la contraccin de la organizacin, permeando y evitando la
prdida de conocimiento respectivamente.

Las empresas desarrolladoras de software encontrarn til la presente propuesta ya que es
factible de ser implantada, sin tener gastos adicionales, sino simplemente implementado las clulas de
conocimiento en la base de la organizacin, logrando con ello mayor apertura y motivacin en los
empleados al momento de la toma de decisiones, privilegiando en todo momento la materia prima con
la que se trabaja en este tipo de empresas, el conocimiento tanto del negocio a modelar, como de las
herramientas de desarrollo.

La solucin propuesta se basa en aspectos fundamentales de toda organizacin: orden,
disciplina, comunicacin eficaz y eficiente, capacitacin y el establecimiento de una relacin ganar-
ganar. Apoya la idea de dividir el trabajo en subtareas, sin embargo el enfoque enfatiza que varias
subtareas sean realizadas por una sola persona, es decir, que cada trabajador no sea un especialista,
sino ms bien se convierta en un empleado interdisciplinario y con un perfil verstil, por ello
sostenemos que es viable que el problema de la crisis del software, puede ser resuelto mediante el
orden al trabajar, siguiendo un proceso y teniendo una comunicacin eficaz y eficiente. Adems el
presente trabajo sostiene que es posible adquirir un enfoque dirigido hacia la gente y ver a las personas
como una ventaja competitiva, an en tiempos de recesin.

Finalmente, podemos afirmar que la presente propuesta a pesar de estar enfocada a una de las
eses duras como lo es la estructura, busca establecer una relacin ganar-ganar entre la empresa y los
empleados, ya que en el esquema de clula laboral cada integrante cuenta con un doble backup o
doble respaldo. Se basa en una comunicacin que constituye la base para compartir el conocimiento, y
con ello, las personas no crean dependencias, con lo cual se genera un crculo virtuoso, porque se
reducen costos operativos ya que se aprovechan los tiempos de remanso o tiempos muertos, las
entregas de puestos son ms fciles y rpidas, adems las personas pueden hacer uso de sus periodos
vacacionales, todo ello hace ms consecuentes muchas labores cotidianas y contribuye a que el
trabajador logre una buena calidad de vida, motivndolo a recrear y reforzar constantemente este
modelo.

79

BIBLIOGRAFA
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Bachmann, Felix L., L. Bass, J .Carriere, P. Clements, D. Garlan, J . I vers, R. Nord, R. Little.,
Documentation in Practice: Documenting Architectural Layers. Software,
http://www.sei.cmu.edu/publications/documents/00.reports/00sr004.html

Booch, Grady, Rumbaugh, J ames, J acobson, I var, Rational Unified Proccess Fundamentals, Ed.
Itera; Edicin (Versin) 5.5, ao de publicacin 2001. Mdulo 1

Chase, Aquilano, Administracin de operaciones, McGrawHill. 10a edicin. Mxico. 2004

Chase, J acobs, Aquilano, Administracin de la produccin y operaciones, McGrawHill, 10. Edicin,
Mxico 2005
ISBN 970-10-4468-1

Chiavenato, I dalberto I ntroduccin a la teora general de la administracin, Mc Graw Hill, Mxico

Cromwell, J eff, The Art and Science of Software Architecture. Dr. Dobbs J ournal Software Tools for
the Proffessional Programmer, Vol.25, Issue 6, J un. 2000.

Franklin F, Enrique Benjamn, Organizacin de Empresas, Ed. McGraw- Hill, Interamericana;
Segunda Edicin Mxico 2004
ISBN: 970-103-944-0

Hall, Richard, Organizaciones: estructura y proceso Mxico, Prentice Hall.

Hernndez Santuario, Eloisa I tz, Modelo de comportamiento organizacional para elevar el
desempeo de los grupos de trabajo interfuncionales dentro de la empresa Tesis, Mxico, 2002, MCSC
ITESM H531.M2002

J acobson, Ivar, Booch, Grady, Rumbaugh, J ames, El Proceso Unificado de Desarrollo de
Software, Addison Wesley,.Mxico, 2000

J urez Hernndez, Othn, Administracin de la compensacin Sueldos, incentivos y prestaciones,
Oxford University Press, Primer edicin; Mxico, 2000

Kast, Fremont E, Rosenzweig, J ames E, Administracin en las Organizaciones. Mc Graw Hill,
Mxico 1985

Microsoft , Student Workbook Solutions Development Discipline, EUA,1997

Mnch Galindo, Lourdes, Fundamentos de administracin, 5 Ed. Trillas, Mxico 1990,
ISBN 968-24-3941-8

Nolan, Richard, Destruccin creativa, Mc Graw Hill, Mxico, 1996


80
Pascale, Richard T., Athos, Anthony G, El secreto de la Tcnica Empresarial J aponesa, Grijalbo,
Mxico, 1984
ISBN 968-419-422-6

Praxis, Manual Administracin de Proyectos de Software, Praxis versin 1.0 Ao 1999

Pressman, Roger S., Ingeniera del Software. Un enfoque prctico. 4. Edicin Mxico 1998. Mc
Graw Hill

Quality And Productivity Staff, PDSS Proceso de desarrollo de software de Softtek, Gua de
Referencia 1, Mxico 1999

Rational University, Requirements Management with Use Cases, Student Manual Version
2002.05.00 USA 2001

Reyes Ponce, Agustn, Administracin de empresas: Teora y prctica, Ed. Limusa 1999

Robbins, Stephen, Comportamiento Organizacional, 8. Ed., Prentice Hall, Mxico, 1999
ISBN 970-17-0236-0

Senn, J ames A., Anlisis y diseo de Sistemas, Ed. McGraw-Hill
I SBN:968-422- 991-7

Sommerville, I an, I ngeniera del Software, Addison Wesley I beroamericana, S.A., Segunda edicin,
Mxico, 1988
ISBN: 0-201-64055-4

Sommerville, I an, Ingeniera de Software, Pearson Educacin, 6. Edicin, Mxico 2002,
I SBN: 970-26-0206-8

Taha, Hamdy A., I nvestigacin de Operaciones, una introduccin, Prentice Hall, Mxico, 1998
I SBN: 970-17-0166-6

Van Genuchten, Michael, Towards a Software Factory, Kluwer Academic Publishers,
ISBN: 0-7923-1751-3

http://www.sei.cmu.edu

http://www.standishgroup.com

http://contexto-educativo.com.ar/2003/3/nota-04.htm

81

ANEXO A
________________________________________________________________________________

I nvestigacin acerca de la demanda de software en la Ciudad de Mxico en el 2006

El estudio que a continuacin se presenta tiene por objetivo levantar algunos datos para
conocer como est conformada la oferta y la demanda dentro del mercado de la Ciudad de Mxico,
para ello se realizaron encuestas entre seis de las empresas desarrolladoras mas grandes de software
con oficinas en la Ciudad de Mxico, esto de acuerdo con el Comit Nacional de Productividad e
Innovacin Tecnolgica A.C., y la Asociacin Mexicana de Calidad en Ingeniera de Software quienes
destacan a Hildebrando, IDS, Praxis y Softtek entre los 11 de los 26 desarrolladores ms grandes de
Mxico :

Grupo UNIKA
Hildebrando
IDS Comercial
I ntegrated Technology
Praxis
Softtek


82

Grupo Unika ha tenido la oportunidad de participar en diversos proyectos para desarrollar aplicaciones
sobre Internet. Despus de casi 5 aos en el mercado, Grupo Unika se ha convertido en una excelente
solucin para responder a desarrollos de alta tecnologa sobre I nternet.
Lo ms interesante de nuestra capacidad es que sabemos convertir el gasto de TI de nuestros clientes
en una inversin con un retorno tangible.
Misin : Ser lder como proveedor de soluciones integrales con tecnologa de punta, compromiso y
capacidad de respuesta.

Fuente:

www.grupounika.com.mx/

MATRI Z

SECTOR SUBSECTOR EMPRESA/GIRO
SECUNDARI O MANUFACTURA
MAQUILADORA
PEMEX
IMP
TERCI ARI O FI NANCI EROS
SERVICIOS
MAPFRE TEPEYAC
GRUPO SCANDA
AMERI CAN EXPRESS
AMI B
GRUPO EDITORIAL SANTILLANA
COMPAQ COMPUTER DE MXI CO
GRUPO NACIONAL PROVINCIAL
SECODAM
INFOTEC
TRIFE
COMISIN NACIONAL DE SEGUROS Y
FIANZAS
INVEX GRUPO FINANCIERO


83
GRAFICA

S
e
c
t
o
r
P
r
i
m
a
r
i
o
S
e
c
t
o
r
T
e
r
c
i
a
r
i
o
*
0
2
4
6
8
10
12

84

Fundada en el ao de 1986, Hildebrando es una empresa mexicana de consultora tecnolgica con
presencia internacional, especialista en desarrollo e integracin de sistemas y soluciones de negocio
aplicando tecnologa de vanguardia.
Hemos sido reconocidos por la revista "Expansin" como una de las 600 empresas ms importantes de
Mxico. Ms de 1000 consultores prestan servicios a bancos, instituciones financieras, empresas de
comunicaciones, e industrias de servicios, en mltiples plataformas.
Filosofa. Pasin por la satisfaccin y el xito del cliente, confianza y respeto, trabajo en equipo, rapidez
y agilidad, innovacin y trabajo bien hecho, son los valores de nuestra empresa que han sido la clave
para que a lo largo de ms de 15 aos, Hildebrando sea una Empresa de xito.
Nuestro objetivo con los Clientes: Ser un Socio tecnolgico, no slo un proveedor.
Nuestra misin en Mxico: Ser el Lder en el mercado de consultora y desarrollo de sistemas.
Fuente:

http://www.hildebrando.com.mx

MATRI Z

SECTOR SUBSECTOR EMPRESA/GI RO
PRI MARI O AGRICULTORA
PESCA
GANADERIA
AGRICULTURA
CAZA
PESCA
MAQUILADORA
COMISION NACIONAL DEL AGUA
SERVI CI OS
EDUACI ON
COMERCIO
FINANZAS
GOBI ERNO
SERVI CI OS DE TELECOMUNI CACI ONES


85
GRAFICA

0
2
4
6
1 2 3
Sector
Hildebrando

86

Misin

Ser una empresa en tecnologas de informacin rentable y en constante crecimiento. Que busca ser
reconocida y respetada en el medio por su calidad, eficiencia, espritu de servicio y sobre todo, por su
compromiso con sus clientes, al punto de dejarlos a todos ampliamente satisfechos y referenciables.

Ser un lugar de trabajo agradable, donde se respete al individuo y se trabaje en equipo; donde abunde
el reto, la superacin, el reconocimiento y donde se ofrezcan excelentes oportunidades de desarrollo
personal, tcnico, profesional y econmico.

Visin

Ser socios, proveedores y aliados tecnolgicos de nuestros clientes ofreciendo servicios de soluciones
integrales en tecnologas de informacin a travs de intervenciones proactivas y con un rol estratgico.

Fuente:

http://www.ids.com.mx/


87

MATRI Z

MAQUILADORA

SERVI CI OS

GRAFICA

0
5
10
15
20
25
30
#Empresas
Primario Secundario Terciario
Sector
Alianzas Estratgicas de IDS


88

I T ofrece soluciones eficaces dentro del mbito de servicios de consultora especializada. Proporciona
los servicios necesarios para consolidar una arquitectura abierta, slida y prctica, que fortalezca y de
flexibilidad a sus reas de sistemas de informacin para soportar adecuadamente los procesos de
negocios y toma de decisiones de la organizacin.

La experiencia adquirida en la Administracin y liderazgo de proyectos de gran magnitud en
importantes empresas en Mxico, Centro y Sudamrica nos permiten llevar a cabo una de las tareas
ms complejas, "La administracin de proyectos" en diferentes sectores como son: Retail, Telco, Sector
Financiero, Administracin de Riesgos, Distribucin y Manufactura.

Integrated Technology arranca el ao 1994 orientado a Arquitectura de Sistemas. Posteriormente toma
especialidades en Middleware, desarrollo en plataforma Microsoft.

Desde 1998 inicia el rea de Business I ntelligence, con especialidades tanto en ETL, como en OLAP y
diseo de cubos. En 1999 nuestra rea de desarrollo se orient hacia el lenguaje J ava, recibiendo el
ao 2000 el premio e- Best.

Contamos con un amplio bagaje de experiencias en el campo del manejo masivo de datos, en procesos
de DataCleansing o Minera de Datos. .

En los ltimos dos aos se han incorporado las especialidades de Ingeniera de Software, proponiendo
en nuestra metodologa la automatizacin de pruebas, as como Seguridad, que es un tema
fundamental en la actualidad.

Misin: Brindar a nuestros clientes servicios de asesora integral en sistemas, ayudndoles a consolidar
una arquitectura slida y abierta, que fortalezca y d flexibilidad a sus reas de Sistemas de
Informacin y favorezca la competitividad de su negocio.

Con este fin nos apoyamos en un selecto portafolio de productos y contamos con distribuidores y
clientes en varios pases de latinoamrica, as como un equipo de excelentes profesionales en diversas
especialidades informticas.
Visin: El desarrollo, implementacin y distribucin de software es una de las industrias con mayores
oportunidades de crecimiento en nuestro pas. Sin embargo, el reto en esta oportunidad consiste en
manejar el constante cambio tecnolgico.

I ntegrated Technology cuenta con varias especialidades (DataManagement, BusinessIntelligence,
eCommerce, Ingeniera de Software y Seguridad), pero cuenta con una caracterstica ms importante:
la habilidad de incorporar nuevas especialidades conforme avanza el desarrollo tecnolgico.

Otras caractersticas distintivas de la visin de nuestra empresa son el trabajo hombro con hombro con
nuestros clientes, que nos permite conocer de manera profunda sus necesidades para aportar
efectivamente a sus sistemas, y la formacin continua de consultores del ms alto nivel.

Fuente:

www.itweb.com.mx


89

MATRI Z

MAQUILADORA

SERVICIOS

GRAFICA

0
2
4
6
8
10
12
14
16
18
SECUNDARIO TERCIARIOS


90

Praxis es una empresa de consultora, desarrollo e integracin de sistemas de informacin con una
misin clara: fortalecer el desarrollo de las empresas a travs del uso adecuado de las tecnologas de
informacin.
Su principal inters es ofrecer a sus clientes un valor agregado para garantizar que su inversin en
tecnologa de informacin los haga ms competitivos.

Fuente:

http://www.praxis.com.mx/

MATRI Z

PRI MARI O AGRI CULTURA
PESCA
GANADERA

SECUNDARIO MANUFACTURA
MAQUILADORA
Fuller,
SERVICIOS
Ericsson, seguros serfin,


91

GRAFICA

0
2
4
6
8
10
12
14
16
SECTOR
SECUNDARIO
SECTOR
TERCEARIO


92

Softtek es una empresa multinacional. Nace en Mxico en 1982 como proveedora de servicios de
software enfocados a solucionar necesidades de desarrollo, implantacin y soporte en empresas de
diversas magnitudes. Hoy somos en Mxico una de las organizaciones lderes e integradoras en
tecnologas de informacin. Es una empresa con presencia en diez pases, y es la empresa privada de
Tecnologa de la informacin ms grnade con presencia regional en Latinoamrica
68

Misin
Incrementar la competitividad de nuestros clientes a travs del uso apropiado de tecnologas de
informacin, cmputo y telecomunicaciones.

Visin
Somos una empresa slida y global . Apuntamos a trascender como lderes , haciendo factible para
nuestros clientes servicios de TI eficientes , innovadores y de reconocida calidad, y conviviendo en una
cultura plenamente humana comprometida con el desarrollo de las comunidades en las que
interactuamos.
Fuente:

http://www.softtek.com.mx

68
RevistaSoftware Guru, A 1 No. 2 Mxico Marzo-Abril 2005, Pg 18

93

MATRI Z

GRAFICA

PRI MARI O AGRI CULTORA
PESCA
GANADERIA
ASERCA (PROCAMPO): ASESOR
ESTRATGI CO, CI CLO DE VI DA DE LOS
PRODUCTOS

MAQUI LADORA
BIMBO
PEMEX
GAMESA
SERVICIOS
GOBI ERNO DEL EDO DE GUANAJ UATO
BANAMEX
BANCOMER
IMSS
ADUANAS
HP
S
e
c
t
o
r
P
r
i
m
a
r
i
o
S
e
c
t
o
r
T
e
r
c
i
a
r
i
o
0
1
2
3
4
5
6

94

MATRI Z GENERAL

PRI MARI O AGRICULTORA
PESCA
GANADERIA
AGRICULTURA, CAZA y PESCA
ASERCA (PROCAMPO): ASESOR
ESTRATGICO, CICLO DE VIDA DE LOS PRODUCTOS
COMI SION NACIONAL DEL AGUA

MAQUI LADORA
PEMEX, GAMESA, IMP, FULLER


95
SERVI CI OS
EDUACI ON
COMERCIO
FI NANZAS
GOBI ERNO
SERVI CI OS DE TELECOMUNI CACI ONES
GOBIERNO DEL EDO DE GUANAJ UATO
IMSS
ADUANAS
HP
MAPFRE TEPEYAC
GRUPO SCANDA
GRUPO EDITORIAL SANTILLANA
COMPAQ COMPUTER DE MXICO
GRUPO NACI ONAL PROVI NCI AL
SECODAM
INFOTEC
TRI FE
COMI SI N NACI ONAL DE SEGUROS Y FI ANZAS
I NVEX GRUPO FI NANCI ERO


96
GRAFI CA GENERAL

0
10
20
30
40
50
60
70
SECTOR
PRIMARIO
SECTOR
TERCEARIO

GRAFI CA DEL SECTOR TERCI ARI O

10%
49%
4%
9%
17%
4%
7%
TELECOMUNICACIONES
FINANCIERO
EDUCATIVO
GOBIERNO
COMERCIO
SALUD
SEGUROS


97

ANEXO B
________________________________________________________________________________

El modelo de asignacin de tareas de I nvestigacin de Operaciones
69

La mejor persona para el trabajo es una descripcin apropiada de lo que trata de lograr el
modelo de asignacin. La situacin se ejemplifica con la asignacin de trabajadores a ciertas tareas,
donde cualquier empleado puede desempear cualquier tarea, aunque con diferentes grados de
habilidad. Un empleo que es igual a la habilidad de un trabajador cuesta menos que uno en el cual el
operador no es hbil. El objetivo del modelo es determinar la asignacin ptima (la menos costosa) de
trabajadores a ciertas labores.

Si consideramos que el modelo propuesto consta de equipos de alto rendimiento conformados
cada uno por tres trabajadores, los cuales pueden desempear tres tareas: Analizar el problema,
administrar las actividades y gestionar con el usuario final. Se solicita que cada trabajador presente en
forma individual una propuesta en la que presenten a su juicio el tiempo idneo para cada una de las
tareas.

Procedimiento
Paso 1 Para la matriz del costo original, identificamos el mnimo de cada rengln y lo restamos de todas
las entradas en el rengln.

Analizar Administrar Gestionar
Empleado 1 15 10 9
Empleado 2 9 15 10
Empleado 3 10 12 8

Paso 2. Para la matriz resultante del paso anterior, identificamos el mnimo de cada columna y
lo restamos de todas las entradas de la columna.

Paso 3. Identificamos la asignacin ptima como la asociada con los cero elementos de la
matriz obtenida en el paso dos.

69

69
Taha ,Hamdy A., Investigacin de operaciones, Una introduccin, Prentice Hall, Mxico, 1998, Pg. 194

98

Digamos que pi y qj son los costos mnimos del rengln i y la columna j, como se definen en los
pasos 1 y 2, respectivamente. Los mnimos del rengln del paso 1 se calculan de la matriz del costo
original, como se muestra en la siguiente tabla:

Analizar Administrar Gestionar Rengln
mnimo
Empleado 1 15 10 9 P1 = 9
Empleado 2 9 15 10 P1 = 9
Empleado 3 10 12 8 P1 = 8

Enseguida, restamos el rengln mnimo de cada rengln respectivo, para obtener la matriz
reducida que se muestra en la siguiente tabla:

Empleado 1 6 1 0
Empleado 2 0 6 1
Empleado 3 2 4 0

Columna mnima q1 =0 q2 =1 q3 =0

La aplicacin del paso 2 nos da los mnimos de la columna en la tabla anterior. Al restar estos
valores en las columnas respectivas, obtenemos la matriz reducida en la siguiente tabla:

Empleado 1 6 0 0
Empleado 2 0 6 1
Empleado 3 2 4 0

Los cuadros con las entradas cero subrayadas proporcionan la solucin ptima. Esto quiere
decir que el empleado 1 administrar el trabajo, el empleado 2 analizar el problema y el empleado tres
gestionar con el cliente.

El costo total es 9 + 10 + 8 = 27 horas


99
Los pasos dados del mtodo hngaro funcionan bien para el ejemplo anterior porque sucede
que las entradas cero en la matriz final producen una asignacin factible (en el sentido de que cada
empleado es asignado a exactamente a una tarea). En algunos casos, los ceros creados por los pasos 1
y 2 quiz no den directamente una solucin factible. En este caso, se necesitan algunos pasos
adicionales para encontrar la asignacin ptima (factible).

Orga

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Orga

Загружено:

Авторское право:

Доступные форматы

I NSTI TUTO POLI TECNI CO NACI ONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA

Вам также может понравиться