20061106 ante tesis - tesis.ipn.mx · esta tesis. me refiero a josé alberto gonzález garcía y a...
TRANSCRIPT
INSTITUTO POLITECNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA
DE INGENIERÍA Y CIENCIAS SOCIALES Y
ADMINISTRATIVAS
SECCION DE ESTUDIOS DE POSGRADO E
INVESTIGACIÓN
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 ADMINISTRACIÓN
P R E S E N T A :
FERNANDO SÁNCHEZ ALVARADO
Para Blanca
I.P.N. – U.P.I.I.C.S.A.
AGRADECIMIENTOS
________________________________________________________________________________
El Trabajo de Investigación siempre es un reto, y para hacerle frente, se requiere tener una
sólida preparación mental que permita concentrarse en forma sostenida por días, semanas; a veces
meses e incluso años. De la misma forma, es importante tener la convicción de que se cumple una
meta al plasmar un ideal. Este juego de conocimiento y valores hace posible la terminación de un
trabajo de investigación.
El camino que se sigue para recopilar y luego conjuntar ideas y escribirlas implica realizar, en
más de una ocasión una especie de práctica de prueba y error; otras veces, es indispensable el manejo
preciso e inmediato de conceptos, y todo ello lleva a conseguir una sensación de que las cosas toman
un cauce lógico y consistente. Es entonces cuando se toma plena conciencia de que esta labor es más
consecuente si se tiene el soporte de las personas idóneas, 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 Instituto
Politécnico Nacional, porque todo lo que soy es gracias a ellos.
La confianza en mi forma de redactar, pero sobre todo el inquisitivo rigor metodológico,
necesario en este tipo de empresas, me motiva a agradecer la labor de Guillermo Pérez Vázquez al
asesorarme en muchas situaciones académicas y de mi vida personal, pero sobre todo por su dirección
en la presente tesis.
El sincero cariño y la credibilidad de Blanca Margarita Díaz Téllez en mi persona y en mi trabajo
enriquece mi vida y fue mi principal motivación para retomar y concluir el presente trabajo. Agradezco
también 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 Ivonne Castañeda Patiño, Maricela Amador Ríos, Karina Cabrera Castro, Ana Laura
Rivera Espinosa, Jessica Yolanda Duran Olgin, Fides Niño Vega, Norma Magallanes Arriaga, Xavier
Murguía Morales, Arturo Montaño Pérez, Juan Manuel Román Huerta, Raúl Díaz Ramírez, Víctor Manuel
Carapia Sadurni, Erick Jair Wiechmann Villatoro (qepd), René Meneses Sánchez, Ludwig Guevara
I.P.N. – U.P.I.I.C.S.A.
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 investigación fue
desarrollada bajo mi supervisión, pero fue realizada directamente por mis alumnos de la Escuela
Bancaria y Comercial por ello, agradezco a Silvia Cervantes Serna, Zabdi Lizbeth Chabolla González,
Claudia Luna Lozada, Thania Moreno Villavicencio, Francisco Mohabbet Cervantes Moreno, Fernando
Vilchis Rivero y José Luis Wals Jara.
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 José Alberto González García y a Jorge Daniel Bautista Cárdenas a quienes
agradezco por enseñarme 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 años, a Octavio Mancilla González por esa mesurada y correcta forma de
expresar claramente las ideas, y a Everardo Rodríguez Caro por tantas frases, tan jocosas, y al mismo
tiempo tan ciertas y que son mencionadas en el momento más adecuado. A ambos les agradezco por
todas y cada una de las ocasiones que me auxiliaron y permitieron poder cumplir con mis actividades
académicas y por todas las enseñanzas 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.
I.P.N. – U.P.I.I.C.S.A.
CONTENIDO
________________________________________________________________________________
RELACION DE CUADROS , GRÁFICAS E ILUSTRACIONES.............................................. 1
SUMARIO …….....................................................................................................…………….. 2
SUMMARY ….....................................................................................................……………… 3
INTRODUCCIÓN................................................................................................................ 4
CAPÍTULO I. LA ADMINISTRACIÓN DE PROYECTOS …………………………........................... 6
I.1 El proyecto y sus características ……………………………………………………………………….. 6
I.1.1 Situación del problema a resolver mediante el proyecto …………………………………... 6
I.1.2 Identificación del propósito y objetivos del proyecto …………………………….. 7
I.1.3 Diferencias entre la producción en serie y la producción por proyecto….... 7
I.2. La Administración de Proyectos …………………........................................................ 8
I.2.2 Determinación preliminar de Recursos .………………………………………………. 8
I.3. El proceso administrativo aplicado al desarrollo de sistemas de software ............... 9
I.3.1. Planeación ………………......................................................................... 10
I.3.2. Organización …................................................................................... 12
I.3.3. Dirección …………………......................................................................... 15
I.3.4. Control ……..…..................................................................................... 16
I.3.4.1 Supervisión de actividades concluidas ……………………………………………… 17
I.3.4.2 Supervisión semanal de actividades………………………………………………….. 17
I.3.4.3 Análisis del avance económico del proyecto………………………………………. 17
I.3.4.4 Revisión del avance del proyecto con el área directiva ………………………. 18
I.4 Proceso General de Solución de Problemas ……………………………………………………….. 18
CAPÍTULO II. LA ESTRUCTURA ORGANIZACIONAL....................................................... 20
II.1 Organización y estructura organizacional ………………………………………………………... 20
II.1.1. Definición de estructura organizacional…………………………………………….. 20
II.2. Vertientes alternas de estructura……………………………………………………………………. 23
II.3 Conformación 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 validación.……………………………………………………………………….. 32
I.P.N. – U.P.I.I.C.S.A.
CAPÍTULO III. EL ENTORNO DE LOS PROYECTOS DE SOFTWARE EN MÉXICO ………….. 33
III.1. Las transformaciones Económicas y sus Repercusiones laborales .....................…. 34
III.2. Problemas comunes en la Adm. de Proyectos de Software ................................. 39
III.2.1 Definición de requerimientos inadecuada. …………………………………………. 40
III.2.2 Planeación Inadecuada ……………………………………………………………………. 40
III.2.3 Habilidades técnicas deficientes. ………………………………………………………. 40
III.2.4 Falta de trabajo en equipo ………………………………………………………………. 41
III.2.5 Insuficiente supervisión del avance ………………………………………………….. 41
III.3. La Crisis del Software: Panorama del Origen del Problema .................................. 41
III.3.1 Factores que influyen ……………………………………………………………………... 43
CAPÍTULO 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.- Características 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 Asociación Mexicana de Calidad en
Ingeniería de Software ................................................................................................ 57
CAPÍTULO 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: Expansión ………………………………………………………………………………. 65
V.1.2 Caso: Contracción ……………………………………………………………………………. 66
V.2. Desarrollo de sistemas con orientación funcional o estructurada…………………………. 68
V.3. Desarrollo de sistemas con orientación a objetos………………………………………………. 70
V.4. Intenciones competitivas en la compensación…………………………………………………… 75
CONCLUSIONES............................................................................................................. 77
BIBLIOGRAFÍA.................................................................................................................. 79
ANEXOS
A: Investigación acerca de la demanda de software en la Ciudad de México en el 2006 81
B: El modelo de asignación de tareas de Investigación de Operaciones……………………… 97
I.P.N. – U.P.I.I.C.S.A.
1
RELACION DE CUADROS, GRÁFICAS E ILUSTRACIONES
________________________________________________________________________________
Fig. I.1 Proceso Global de la Administración de Proyectos ………………………………………………………………………………. 9
Fig. I.2 Proceso General de Solución 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 mecánico versus modelo orgánico …………………………………………………………………………………………. 28
Fig. II.7 Condiciones propicias para aplicar el modelo mecanicista y el orgánico ………………………………………………… 29
Fig. II.8 Estructura Organizacional Híbrida ……………………………………………………………………………………………………… 30
Fig. III.1 Fuerza de trabajo de Estados Unidos en las economías agraria, industrial y de la información…………………. 34
Fig. III.2 Monto del presupuesto que se destina al pago del personal por sector (Elaboración propia) …………………… 35
Fig. III.3 Proyectos de desarrollo de software por sector en la ciudad de México (Elaboración propia Abril 2006) …… 36
Fig. III.4 Distribución de proyectos de desarrollo de software en el sector Servicios en la ciudad de México ………….. 37
Fig. III.5 Enfocándose en las Causas Raíz los síntomas se eliminan ……………………………………………………………………. 43
Fig. III.6 Flujo de la Investigación (Elaboración propia) …………………………………………………………………………………… 45
Fig. IV.1 Ciclo de Desarrollo en Cascada …………………………………………………………………………………………………………. 48
Fig. IV.2 Ventajas y Desventajas del modelo en cascada (Elaboración propia) ……………………………………………………. 49
Fig. IV.3 Ciclo de Desarrollo de Espiral ……………………………………………………………………………………………………………. 52
Fig. IV.4 Ventajas y desventajas del modelo de Espiral ……………………………………………………………………………………. 53
Fig. IV.5 Cuadro comparativo de modelos de desarrollo (Elaboración propia)………………………………………… 55
Fig. IV.6 Evolución del Modelo Normativo ………………………………………………………………………………………………… 57
Fig. IV.7 Historia de MoProSoft (proporcionado por la AMCIS) ………………………………………………………………. 58
Fig. IV.8 Niveles de capacidad por proceso ……………………………………………………………………………………………………… 59
Fig. IV.9 Modelo MoProSoft (Proporcionado por la AMCIS) ……………………………………………………………………………….. 62
Fig. V.1 Célula laboral (Diseño Propio) …………………………………………………………………………………………………………… 64
Fig. V.2 Célula laboral en Expansión ……………………………………………………………………………………………………………… 65
Fig. V.3 Célula laboral en Contracción …………………………………………………………………………………………………………… 66
Fig. V.4 Estructura del Equipo de Desarrollo …………………………………………………………………………………………………… 67
Fig. V.5 Diagrama de flujo de información del proceso de análisis estructurado …………………………………………………. 69
Fig. V.6 Flujo del análisis orientado a objetos …………………………………………………………………………………………………. 71
Fig. V.7 Flujo del diseño orientado a objetos…………………………………………………………………………………………………… 73
Fig. V.8 Flujo de infraestructura ……………………………………………………………………………………………………………………. 74
Fig. V.9 Intenciones competitivas de compensación ………………………………………………………………………………………… 76
I.P.N. – U.P.I.I.C.S.A.
2
SUMARIO ________________________________________________________________________________
El propósito 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
intrínseca 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 contemporáneo posea un conocimiento práctico de las estructuras organizacionales
mixtas y orgánicas, porque con este conocimiento puede colocar las bases de la adaptación 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 organización, y con
ello la habilidad de una organización para lograr sus metas.
Ciertamente, la estructura minimiza la improvisación, ya que no cambia frecuentemente,
además, mediante la estructura se logra la impersonalización de la organización, 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 operación de cualquier empresa.
I.P.N. – U.P.I.I.C.S.A.
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 doesn’t 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.
I.P.N. – U.P.I.I.C.S.A.
4
INTRODUCCIÓN ____________________________________________________________________________________
La incertidumbre de la economía y las constantes modificaciones que sufre el país y el mundo
debido a la globalización, acompañada 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 situación,
e incluso podemos afirmar que también 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 tamaño, 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 comúnmente
excedidos, ya que no están basados en estimaciones reales; además 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
capítulos. El capítulo uno trata de la administración de proyectos y de cómo se aplica el proceso
administrativo al desarrollo de software, así mismo se hace mención de los problemas más comunes
que se presentan en la Administración de Proyectos de software, los cuales se describen mas a detalle
en el tercer capítulo. Por otra parte, en el segundo capítulo, se recopilaron algunos conceptos de
organización y estructura organizacional, y se describen varias estructuras organizacionales, con
cuadros que muestran las ventajas y desventajas de cada uno.
En el capítulo tres se proporciona un panorama general del entorno nacional de las empresas
desarrolladoras de sistemas de información, se detallan algunas de las situaciones en las que operan
este tipo de organizaciones, enfocándose en los problemas más comunes que se presentan.
La razón de ser del capítulo cuatro es que la tecnología 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 tecnológicas, es decir la forma en que las personas se
organizan para crear tecnología, por ello en este capítulo se presenta una síntesis de los modelos o
enfoques que guían el proceso de desarrollo de software, considerándose 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 reutilización de software. En este capítulo, también se describe el modelo
de proceso de desarrollo de software, conocido como MOPROSOFT, modelo mexicano.
I.P.N. – U.P.I.I.C.S.A.
5
Finalmente, en el capítulo cinco se propondrá una alternativa para organizar a los recursos
humanos, con la cual se espera reducir gran parte la problemática 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 elaboración de la propuesta se eligió un marco teórico, 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 más influyó
en el presente trabajo es, Organizaciones: Estructura y proceso de Richard Hall, obra en la cual en su
cuarto capítulo se describen los factores contextuales que afectan la estructura organizacional; es por
ello que es pertinente enfatizar que cada capítulo del presente trabajo trata de explicar tres de los
cuatro factores contextuales: Entorno, tecnología y tamaño.
Por lo que respecta al factor cultura (o estilo cultural de la organización) 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, formación académica,
expectativas, creencias, etc; por ello cabe mencionar que, ciertamente las organizaciones son afectadas
por la cultura y el ambiente en donde están localizadas, en la misma forma que se ven afectadas por
los factores de tamaño y tecnología, sin embargo el tratamiento de este tema queda fuera de los
límites 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 investigación, como dirían los
economistas “Ceteris Paribus” (Término en latín usado en el análisis económico 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.
I.P.N. – U.P.I.I.C.S.A.
6
CAPITULO UNO
________________________________________________________________________
LA ADMINISTRACIÓN DE PROYECTOS
“La administración es, más que un concepto, una forma de vida. Internarse en ella es descubrir
que podemos cambiar la forma en que se nos ha enseñado a pensar y aprender a crear
conscientemente a través del tiempo.”1
Henry Mintzberg.
La administración puede ser vista como un instrumento para llegar a un objetivo: Ser más
eficientes. Se busca generar, incrementar y mantener el valor para la empresa, la administración busca
mejores rendimientos, incrementar la productividad, mejorar la relación costo-beneficio. Para poder
lograr esto, dentro del entorno de las empresas de servicios que trabajan por proyecto, se considera
muy importante establecer la definición de proyecto y sus diferencias con la producción en serie.
I.1 El proyecto y sus características
DEFINICIÓN DEL PROYECTO
Un proyecto puede definirse como una serie de actividades relacionadas entre sí, que por lo
común y cuyo desempeño requiere un periodo significativo. Un proyecto debe estar orientado a un
objetivo, debe tener una fecha de inicio y terminación, así como una secuencia de actividades. Dicho
proyecto es tá limitado en cuanto al uso de recursos y presupuesto para su aceptación, ya que involucra
mucha gente y/o áreas funcionales de la organización y el resultado final debe ser un producto y/o un
servicio. Aunque existe un riesgo durante su ejecución2.
I.1.1 Situación del problema a resolver mediante el proyecto
La situación 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 líder 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 Educación en Tecnología, México, Pág. 3 y Praxis, “Manual Administración de Proyectos de Software”, Ed. Praxis, versión 1.0 Año 1999 Pág. 2
I.P.N. – U.P.I.I.C.S.A.
7
I.1.2 Identificación del propósito y objetivos del proyecto
Al iniciar un proyecto se debe definir una meta clara, que permita saber cuál es el resultado
final deseado y su alcance. La definición de la meta debe ser un enunciado por escrito, que permita
asegurar que todos están entendiendo lo mismo. La meta deber ser específica, medible, realista y
definida en términos de tiempo y costo, debe estar de acuerdo con los objetivos de la alta dirección y
con la misión de la Institución.
Una vez identificado cuál es la meta del proyecto, es posible definir cuáles son los objetivos del
mismo. Los objetivos son enunciados más precisos que aclaran la meta y orientan la acción.
Representan grandes componentes del proyecto que tendrán que ser completados a través de una serie
de actividades.
Mediante la especificación de objetivos se comienza a ver el proyecto en términos de sus
grandes componentes, lo que ayuda a la toma de decisiones y a la comprensión por parte de los otros
integrantes del equipo.
I.1.3 Diferencias entre la producción en serie y la producción por proyecto.
La producción en serie se caracteriza por producir un número determina do de piezas iguales,
bajo un mismo procedimiento, y por su parte en la producción por proyecto se producen piezas muy
específicas 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
desempeñan debe estar acorde a las características intrínsecas de las actividades a realizar.
Configuración por Proyecto. Producción generalmente de productos únicos de cierta
complejidad que requieren gran cantidad de insumos. Estos deben fabricarse en un lugar definido
debido a que es difícil 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 operación, ya que aquí no existe flujo del objeto de trabajo, sino que son los recursos técnicos y
humanos quienes acuden al lugar de trabajo. Las actividades y recursos se gestionan como un todo. Su
coordinación adquiere carácter crítico. Existe un gran interés por el control de los costos y las fechas de
terminación.
3 Chase Aquilano, “Administración de la Producción y de Operaciones” Mc Graw Hill 10ª. Ed. Méx. 2005 Pág. 74
I.P.N. – U.P.I.I.C.S.A.
8
I.2 La Administración de Proyectos
“La Administración de proyectos puede definirse como planeación, dirección y control de
recursos (personas equipo, material) para cumplir las restricciones técnicas de costos y de tiempo de un
proyecto”.4
“La Administración de proyectos es el proceso cuya función principal es la de dar el seguimiento
adecuado a las actividades que se establecen, organizando éstas de acuerdo a una secuencia lógica y
asignándoles los recursos y costos necesarios para su ejecución que permitan el logro de los objetivos
planteados en el proyecto.” 5
La administración de proyectos trata de proporcionar una serie de métodos y/o técnicas
basadas en los principios de la administración, que sirvan como base para la planeación, estimación y
control de los proyectos, involucrando el establecimiento de objetivos claros y precisos, la secuencia de
actividades que tendrán que completarse, la organización e integración 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 planeación estratégica.
La primera etapa que se vislumbra para poder realizar la administración del proyecto es la
investigación 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 información
general y valiosa sobre éste, a fin de que sirva para describir la situación del problema, la dirección u
orientación del proyecto y la identificación de suposiciones y riesg os asociados con el mismo.
En la mayoría 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 capítulo cuatro se
describen varias formas de llevar a cabo un proyecto, usando gráficas.
I.2.1 Determinación preliminar de recursos
Aunque es una etapa aún temprana para estimar adecuadamente los recursos que deberán
usarse, deberá considerarse realizar una lista, aunque posteriormente en la elaboración del plan tenga
que ajustarse.
Los recursos no solamente se refieren a dinero sino también deben considerar los recursos
humanos, materiales y el capital financiero que requiera el proyecto. La lista deberá de responder a las
interrogantes ¿quién?, ¿cuándo?, ¿cuántos? ¿por cuánto tiempo?, ¿En dónde?
4 Chase, Aquilano, “Administración de Operaciones”, Mc Graw Hill. 10a edición. México. 2001, Págs. 165-168
I.P.N. – U.P.I.I.C.S.A.
9
I.3 El proceso administrativo aplicado al desarrollo de sistemas de software
La figura I.1 proporciona una visión global de la administración de proyectos. En la parte
superior izquierda de la figura, se muestra el inicio del proceso a través de la solicitud de propuesta
elaborada por el cliente, también se muestran las principales fases de la administración de proyectos:
Planeación, Organización, Dirección y Control. También en la parte superior se representa al equipo que
lleva a cabo la administración 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 Organización como en la dirección
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 también los criterios que
se utilizarán para evaluar la propuesta que se entregue.
Visión Global de la Administración de Proyectos
Fig. I.1 Proceso Global de la Administración de Proyectos (Diseño Propio)
Es común que el cliente no genere una solicitud de propuesta por escrito y que además éste
sea extremadamente superficial. En este caso se deberá escribir y detallar la solicitud de propuesta
antes de comenzar la fase de planeación debido a que la eficiencia de esta fase dependerá en gran
parte de los datos de entrada que recibe.
5 Praxis, “Manual Administración de Proyectos de Software”, Ed. Praxis, versión 1.0 Año 1999 Pág. 8
I.P.N. – U.P.I.I.C.S.A.
10
I.3.1 PLANEACION
La fase de planeación comienza con la determinación de requerimientos, los que servirán de
guía para elaborar el plan de proyecto que a su vez servirá de base para elaborar la propuesta. La
planeación recibe retroalimentación de la fase de supervisión, ya que es ahí donde verificamos que el
proyecto avance de acuerdo a lo establecido en la planeación.6
Requerimientos
“Un requerimiento es una condición 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 planificación 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 número 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 fácilmente medidas y su cumplimiento fácilmente verificable.
El plan del proyecto tiene cuatro elementos esenciales. Estos elementos son: La descripción del
proyecto, la descripción de las actividades, el presupuesto del proyecto y el análisis 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
características esenciales del proyecto.
• Proveer a la administración de la empresa un entendimiento del proyecto
• Transmitir al cliente las características 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 Educación en Tecnología, México, Pág. 29
I.P.N. – U.P.I.I.C.S.A.
11
• Formar la base de la propuesta para el cliente
La planeación del proyecto de software puede ser dividida en fases para su mejor control, las
fases son determinadas por la metodología de desarrollo que se esté ocupando, pero genéricamente
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 planeación 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
versión vigente en determinada fecha debe ser identificable.
d) La planeación debe ser revisada constantemente sin embargo es obligatorio revisarla y detallarla
al finalizar una fase de la metodología de desarrollo y antes de comenzar la siguiente.
Las actividades de la fase de planeación del proyecto son8:
1.- Obtener datos históricos de planeación de proyectos
Estos datos pueden surgir de muy diversas fuentes: manuales de políticas y procedimientos,
observación, entrevistas, cuestionarios etc. pero la más importante es la experiencia adquirida por parte
del equipo en proyectos similares
2.- Elaborar la descripción del proyecto.
La descripción del proyecto es una síntesis 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 versión del plan de actividades antes de iniciar cada fase de la metodología de
desarrollo, esta se realiza utilizando el paquete estándar de administración de proyectos que se defina
en la empresa.
4.- Elaborar el desglose de actividades
El desglose de actividades es un diseño gráfico o lista identada (con márgenes o sangrías
conformados por espacios en blanco que facilitan la lectura al mostrar relaciones de jeraquía) del
trabajo que debe ser realizado para completar el proyecto, proporciona una representación detallada
7 Quality And Productivity, Ob cit, Pág. 35 y Praxis Ob cit, Pág. 10
I.P.N. – U.P.I.I.C.S.A.
12
del proyecto como una colección de actividades que deben ser realizadas para que el proyecto sea
terminado.
Estimación 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 ningún 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 máquinas.
• Disponibilidad de material.
• Eventos inesperados (enfermedades, desastres naturales o sociales, huelgas, accidentes etc.)
Para la estimación en lo que respecta al costo existen típicamente 4 grandes categorías y que
pueden definirse para cualquier actividad, tales como :
1. Recursos Humanos
2. Recursos Materiales
3. Otros costos directos (viáticos, teléfonos, servicios contratados, etc.)
4. Indirectos (Administración)
Una práctica que se aplica por lo general, es que los costos no localizables (indirectos) tales
como administración, utilidades, depreciación 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 más bajo dependiendo del tamaño del proyecto, para recalcular los costos indirectos.
I.3.2 ORGANIZACIÓN
Por lo general al hablar de organización, se entiende que hablamos de una unidad social creada
para un fin. Dentro de la organización deberán ser definidas estructuras, para que se tenga la
seguridad de que las personas hagan aportaciones en una forma específica 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, Págs. 83 -90 y Praxis, Ob cit Pág. 8
I.P.N. – U.P.I.I.C.S.A.
13
asignarse todas las tareas necesarias a las personas más idóneas para hacerlas, siguiendo el principio
de Orden de Henri Fayol.9 Para ello, en el Anexo B se muestra una forma de asignación 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 organización.
Pero por estructura organizacional significamos “la distribución a lo largo de varias líneas, de personas
entre posiciones sociales que influyen en las relaciones de los papeles entre esta gente”. 10 Las
organizaciones varían en su grado de complejidad. Las organizaciones también varían en el grado en el
que se les da autonomía a la gente y a las unidades. Las estructuras organizacionales están cambiando
según 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 definición es la división 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 jerarquía; las posiciones que ocupa la gente tienen reglas y reglamentos que especifican,
en diferentes grados, cómo deben de comportarse los que ocupan esas posiciones.
Otras definiciones enfatizan la importancia de las interacciones humanas en la formación de
estructuras, puesto que las ‘estructuras configuran las prácticas de la gente, pero también es cierto
que las prácticas 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 interacción, y sin embargo da
forma a esa configuración: las estructuras se constituyen y son constituyentes’.
“Estos enfoques enfatizan que la estructura de una organización no queda fija; más bien,
configura lo que sucede en una organización. Las estructuras organizacionales son una consecuencia
del impacto simultáneo de múltiples factores”11
Las estructuras organizacionales cumplen con ciertas funciones, entre las cuales están las
siguientes: Las estructuras tienen la intención de elaborar productos organizacionales y alcanzar
objetivos organizacionales, las estructuras se diseñan para minimizar, o por lo menos regular, la
influencia de las variaciones individuales sobre la organización. 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, “Administración en las Org”. Ed. Mc Graw Hill, México 1985 Pág. 67 10 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Se transcribe la nota al pie original, Blau, 1974; página 12. 11 Ibidem. Página 92
I.P.N. – U.P.I.I.C.S.A.
14
Además es el ambiente donde se ejercita el poder (también 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 organización 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 deberán 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 fábrica”13 y ésta es muy diferente de
una escuela o un laboratorio. Los edificios también reflejan los valores e ideología de las personas que
tienen el control.
Construir equipos efectivos es tanto arte como ciencia. En la construcción de un equipo efectivo
lo que se ha de considerar es que debe estar dado no sólo por la destreza técnica del administrador y
los miembros del equipo, sino también por los papeles críticos que desempeñan y la química que les
mezcle.
Las actividades que deben realizarse durante la etapa de organización son:
- Tener definida y difundida la organización 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 encargarán del proyecto, es muy importante tomar en
cuenta el perfil de cada una, la información con la que cuenta el área de recursos humanos ayuda a la
formación de equipos de trabajo fáciles de integrar.
Una de las principales tareas dentro de la organización 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 representación de la organización 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 descripción de cada uno de los roles y funciones definidos. El
organigrama nos ayudará a la asignación de actividades del equipo.
12 Hall, Richard, Ob Cit Pág. 92 13 Kast, Fremont E, Rosenzweig, James E, “Administración en las Org”. Ed. Mc Graw Hill, México 1985 Pág. 68
I.P.N. – U.P.I.I.C.S.A.
15
I.3.3 DIRECCIÓN
La fase de organización es normalmente seguida por la fase de dirección. Los elementos
esenciales de esta fase son establecer un equipo de trabajo coherente y efectivo, para lograr esto es
necesario:
a) Realizar juntas periódicas de trabajo, agendadas con anterioridad y las personas involucradas
deberán de ser notificadas con anticipación.
b) Asignación de actividades.
c) Realizar periódicamente sesiones de retroalimentación, 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 motivación, enfoques de liderazgo y comunicación.
Para este caso de estudio, el liderazgo será mencionado como un elemento que se encuentra
implícito en algunos factores de comportamiento organizacional que se describen a continuación.
El líder del equipo debe ser objetivo e imparcial en las decisiones al momento de solucionar los
problemas. El líder 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. Además, el líder 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 demás miembros del equipo a que establezcan la relación
de confianza. Un equipo liderado por una persona que no inspira confianza seguramente será un equipo
donde la misma no va a prosperar.
La comunicación debe ser abierta. La comunicación dentro de un equipo puede referirse a dos
tópicos: Conversaciones sobre los temas en los que está operando el equipo, o conversaciones sobre la
interacción misma del equipo.
“La comunicación eficaz puede ser la llave para lograr la excelencia organizacional ya que
dentro de la empresa se lleva a cabo un sistema de comunicación humano y tecnológico 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 tecnología para
I.P.N. – U.P.I.I.C.S.A.
16
resolver creativamente los problemas altamente complejos.” 14
Comunicación 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.
Número óptimo de miembros. Los equipos eficaces contienen miembros suficientes para
asegurarse de que existe una buena interacción, pero no tantos como para que la discusión se sofoque,
por otro lado, se dice que un número impar de miembros es mejor para evitar empates en las
votaciones al tomar decisiones consensadas. 15
Consenso. Si una decisión no es producto de la reflexión e interacción del grupo, las ventajas
de la toma de decisiones grupales se pierden. Además, los miembros del equipo con frecuencia se
sienten más satisfechos acerca del proceso y más comprometidos con las decisiones que resultan del
mismo cuando éstas se alcanzan de una manera democrática, por medio de la interacción del grupo.
Liderazgo en la comunicación. Para que el liderazgo ocurra en los equipos de trabajo, unas de
las habilidades necesarias del líder 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 dirección de un líder, es probable que algunas personas hablen más tiempo del que
les corresponde.
I.3.4 CONTROL
Independientemente de qué tan completa y precisa sea la planeación, generalmente hay un
número 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 supervisión es obtener de forma permanente el estado del proyecto, con
el fin de dar retroalimentación a cada una de las fases de la administración anteriores.
14 Hernández Santuario, Eloisa Itzé, “Modelo de comportamiento organizacional para elevar el desempeño de los grupos de trabajo interfuncionales dentro de la empresa” Tesis, México, 2002, MCSC ITESM H531.M2002 Pág. 29 15 Ibidem Pág. 38
I.P.N. – U.P.I.I.C.S.A.
17
Existen distintos tipos de supervisión cada uno persiguiendo el control de las actividades que
llevarán a conseguir el objetivo final. Algunos tipos de supervisión dentro del desarrollo de sistemas de
información se describen a continuación:
I.3.4.1 Supervisión de actividades concluidas.
Al término de cada actividad, el producto generado deberá ser revisado por el responsable del
mismo. En caso de existir diferencias, entre la definición y el funcionamiento conseguido, se deberán
realizar las correcciones necesarias hasta lograr obtener el producto deseado.
La duración real de la actividad deberá ser documentada, la información generada en esta
supervisión debe ser entregada al líder del proyecto para que proceda a actualizar el avance del plan de
actividades. Este tipo de supervisión tiene como fin el determinar el estado del proyecto o de alguna de
sus actividades.
I.3.4.2 Supervisión semanal de actividades.
Los reportes de actividades semanales elaborados por los integrantes del equipo de trabajo
servirán para detectar:
• Actividades no planeadas.
• Actividades planeadas no realizadas.
• Poca inversión de tiempo en el proyecto.
• Avance de actividades.
Con las detecciones realizadas se tendrán las bases suficientes para llevar a cabo una
retroalimentación con la cual se obtendrán los ajustes necesarios que eviten un posible fracaso del
proyecto.
I.3.4.3 Análisis del avance económico del proyecto.
Uno de los principales indicadores del desempeño 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 pérdidas económicas.
I.P.N. – U.P.I.I.C.S.A.
18
I.3.4.4 Revisión del avance del proyecto con el área directiva.
Es necesario llevar a cabo una revisión formal con el área directiva de la calendarización del
proyecto, el costo y la calidad, es un elemento esencial de la administración efectiva de proyectos. Las
revisiones se deben llevar en forma mensual como mínimo.
I.4 Proceso General de Solución de Problemas
Con el objetivo de encontrar las causas raíz, 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 diagnóstico 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
diagnóstico mencionado.
Fig. I.2 Proceso General de Solución de Problemas.16
El proceso de solución de problemas mostrado en la anterior figura tiene como primer paso
(caja 1) el obtener o reiterar, los hechos que son conocidos en la situación dada. Estos hechos
normalmente se obtienen de la calendarización del proyecto, el análisis económico y la calidad de los
productos, sin embargo pueden existir otros factores que no son tan obvios. Algunos de estos ejemplos
podrían 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)
I.P.N. – U.P.I.I.C.S.A.
19
• La falta de disponibilidad de los usuarios.
• El bajo nivel de experiencia de los recursos asignados.
• Las dificultades en la autorización del análisis.
Después 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 categoría de problemas potenciales, están aquellos eventos que podrían hacer un daño
serio al proyecto. Ejemplos de estos son los conflictos en el personal, que la compañía pase por una
etapa de reorganización, la rotación del personal, es decir, la pérdida de gente clave, no en el proyecto,
sino en la organización. O bien, cambios en los proveedores/subcontratistas de la compañía.
Esta separación 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 más pequeños o con poca importancia y evadir los problemas críticos.
Después 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 más datos. Los planes para resolver problemas deberán
ser evaluados en términos de beneficio, riesgo y costo (caja 6). Los planes que no son satisfactorios
(caja 7) tienen que volver atrás para ser mejorados y considerar otras alternativas. Una vez que el plan
es aprobado la implementación comienza (caja 8).
Una vez que hemos abordado todas y cada una de las fases de la administración 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 teoría con la práctica los modelos se han ido
adaptando, y de lo cual se habla en el siguiente capítulo.
I.P.N. – U.P.I.I.C.S.A.
20
CAPITULO DOS
________________________________________________________________________
LA ESTRUCTURA ORGANIZACIONAL
“"Las estructuras se constituyen y son constituyentes"17
En la contundente mayoría de las obras consultadas para la elaboración del presente trabajo de
investigación, se puede observar que, un gran número enfatizan las llamadas “eses blandas o
cualitativas”, es decir, la tipificación del personal o descripción demográfica (Staff), las aptitudes que
distinguen al personal clave de la empresa considerada ésta en su conjunto (Skills), las ideas más
significativas que una organización permea en sus miembros (Superordinate goals) y, el
comportamiento característico de los directivos clave para la consecución de los objetivos de la empresa
(Style), e incluso, un buen número de obras tratan extensamente las llamadas “eses duras o
cuantitativas”, es decir, tratan el plan o acción para asignar los limitados recursos de la empresa
(Strategy), tratan la forma de hacer circular la información (Systems), pero en realidad son pocos los
autores que hacen referencia a la distribución del trabajo, a cómo se organiza la empresa, si está
descentralizada o centralizada, etc., es decir a la estructura (Structure) 18.
II.1 Organización y estructura organizacional
La palabra organización tiene tres acepciones, una etimológica que proviene del griego organón
que significa instrumento; otra que se refiere a la organización como una entidad o grupo social; y otra
más que se refiere a la organización como un proceso.
II.1.1. Definición de estructura organizacional
“Organización (Para Agustín Reyes Ponce) es la estructuración técnica 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 máxima eficiencia dentro de los planes y objetivos señalados.
Para Petersen y Plowman, la organización es un método de distribución de la autoridad y
responsabilidad, y sirve para establecer canales de comunicación entre grupos. Según Terry
17 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Pág. 53
I.P.N. – U.P.I.I.C.S.A.
21
Organización es un arreglo de las funciones que se estiman necesarias para lograr un objetivo, y una
indicación de la autoridad y responsabilidad asignadas a las personas que tienen a su cargo la ejecución
de las funciones respectivas. Finalmen te, podemos concluir que, la organización puede definirse como
dos o más personas que colaboran dentro de ciertos límites para alcanzar una meta común, o bien
como un conjunto de personas que están en constante interacción dentro de una estructura de poder y
autoridad para el logro de un objetivo común valiéndose para ello de conocimientos y tecnología.” 19
La Organización al ser vista como función administrativa, significa que es necesario estructurar
e integrar los recursos y órganos responsabilizados de su administración y establecer relaciones entre
ellos y atribuciones de cada uno de ellos. En este punto es necesario recordar que la teoría de la
organización se encuentra basada en los siguientes principios establecidos por Henri Fayol20 en su
Teoría Clásica de la Administración: División del trabajo, Autoridad y responsabilidad, Unidad de mando,
Unidad de Dirección, Centralización y Jerarquía o cadena escalar.
De acuerdo con Richard Hall, “se considera la estructura organizacional como el arreglo de las
partes de la organización”; la estructura Organizacional es la “Distribución a lo largo de varias líneas, de
personas entre posiciones sociales que influyen en las relaciones de los papeles entre esa gente”. “Una
consecuencia de esta definición es la división 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
jerarquía; las posiciones que ocupa la gente tienen reglas y reglamentos que especifican, en diferentes
grados, cómo deben comportarse los que ocupan estas posiciones”.
Otras definiciones enfatizan la importancia de las interacciones humanas en la formación de
estructuras, puesto que las ‘estructuras configuran prácticas de la gente, pero también es cierto que las
prácticas 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 interacción, y sin embargo da forma
a esa configuración: las estructuras se constituyen y son constituyentes”21.
Este enfoque enfatiza que la estructura de una organización no queda fija para siempre. Más
bien, configura lo que sucede en una organización, y a su vez es configurada por lo que sucede en
dicha organización. 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 Técnica Empresarial Japonesa” Grijalbo, Méx. 1984, Pág. 111 19 Münch Galindo, Lourdes, “Fundamentos de administración” 5ª. Ed. Trillas, México 1990, Pág. 107 20 Kast, Fremont E, Rosenzweig. James E, “Administración en las Org”. Ed. Mc Graw Hill, México 1985 Cap. 3 21 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Pág. 53
I.P.N. – U.P.I.I.C.S.A.
22
“Las estructuras organizacionales son una consecuencia del impacto simultáneo de múltiples
factores.” 22, De hecho, no existe una explicación única para las formas de las organizaciones. Más bien,
se necesitan múltiples 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 fábrica.
La naturaleza de la materia prima afecta la forma como se estructura y opera la organización.
Ya que puede que sea un ser viviente, humano o de otro tipo, un símbolo o un objeto inanimado. La
gente es materia prima en organizaciones que cambian o procesan a la gente; los símbolos son
materiales en los bancos, agencias de publicidad y algunas organizaciones de investigación; las
interacciones de la gente son materia prima a manipular por los administradores en las organizaciones;
por lo general, los consejos de administración, comités y comisiones están involucrados con el cambio o
procesamiento de símbolos e interacciones humanas
De acuerdo con Richard Hall, las estructuras organizacionales cumplen tres funciones, en primer
lugar las estructuras tienen la intención de elaborar productos y alcanzar objetivos organizacionales, en
segundo término, las estructuras se diseñan para minimizar, o por lo menos regular, influencia de las
variaciones individuales sobre la organización. 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 (también las estr ucturas fijan o determinan qué
puestos tienen poder en primer lugar), y dónde se toman decisiones.24
Actualmente, con la jerarquía tradicional desvaneciéndose “las estructuras organizacionales
están cambiando continuamente según se ven influenciadas por las olas sucesivas de sus miembros, las
interacciones críticas entre personas, productos e información 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 coordinación y control. Una
22 Hall, Richard, Ob cit Pág. 92 23 Ibidem. Pág. 93 24 Hall, Richard, Ob cit Pág. 53
I.P.N. – U.P.I.I.C.S.A.
23
forma en que se logra dicha coordinación es por medio de la comunicación efectiva entre las unidades.” 25
II.2. Vertientes alternas de estructura.
La estructura de una organización puede representarse a partir de diversas vertientes y tomar
varios formatos. Estas variantes, producto de la conversión de funciones o procesos en componentes,
fomentan el trabajo en equipo, la creación 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 tecnología de la información 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 través de redes semipermanentes de pequeños equipos
orientados al proyecto, cada uno de los cuales constituirá por si mismo un centro autónomo de
oportunidades empresariales, en el que las nuevas necesidades de rapidez y flexibilidad traerán consigo
un cambio radical en las estructuras administrativas tradicionales. Por consiguiente, Peters se inclina
más por el proyecto puro, en donde el equipo autónomo 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 líneas de comunicación se acortan. Las decisiones se
toman con rapidez.
Hay un elevado nivel de motivación y compromiso del equipo.
Duplicación de recursos. El equipo y las personas no se
comparten entre proyectos.
Se ignoran las metas y políticas organizacionales, debido a que
los miembros del equipo a menudo están, física y
psicológicamente alejados de la oficina central.
La organización se queda atrás en su conocimiento de la nueva
tecnología debido a las debilitadas divisiones funcionales.
Fig. II.1 Ventajas y Desventajas del proyecto puro
Fuente: Chase, Jacobs, Aquilano, “Administración de la producción y operaciones”, McGrawHill,
10ª. Edición, México 2005 Pág. 76
Estructuras de líneas y/o proyectos de negocio. La agrupación de actividades a lo largo de las
líneas de negocio es un modelo que ofrece una forma de aprovechar los beneficios de la curva de
aprendizaje/experiencia de la división del trabajo y del empleo inteligente de la tecnología y equipos
especializados. Desarrollar experiencia en una función o proceso de negocio mejora la eficiencia de la
25 Citado en Richard Hall .Ob cit Pág. 51
I.P.N. – U.P.I.I.C.S.A.
24
operación y fortalece una competencia valiosa, lo que en algún momento se convierte en la base para
lograr una ventaja competitiva.
Proyecto funcional. En el otro extremo del espectro de la organización del proyecto está el
proyecto funcional, que alberga al proyecto dentro de una división funcional.
Ventajas Desventajas
Un miembro del equipo puede trabajar en varios proyectos.
La experiencia técnica se mantiene dentro del área funcional
incluso si los individuos dejan el proyecto o la organización.
Los especialistas funcionales pueden ascender verticalmente.
Una masa crítica de expertos especializados en el área
funcional crea soluciones sinérgicas para los problemas
técnicos de un proyecto.
Los aspectos del proyecto que no se vinculan directamente con
el área funcional pueden resultar perjudicados.
La motivación de los miembros del equipo a menudo es débil.
Las necesidades del cliente son secundarias y se responde a
ellas con lentitud.
Fig. II.2 Ventajas y Desventajas del proyecto funcional
Fuente: Chase, Jacobs, Aquilano, “Administración de la producción y operaciones”, McGrawHill,
10ª. Edición, México 2005 Pág. 76
Estructura matricial. Una organización de matriz es una estructura con dos o más canales de
mando cuya característica clave es que la autoridad en un neg ocio/producto/proyecto/empresa y la
autoridad de una función 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 estratégicas y de operación en beneficio de la organización
en su conjunto26.
La estructura matricial también es conocida como Proyecto de matriz. El proyecto de matriz,
que es la clásica 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).
Después los administradores senior deben decidir si se va a utilizar una forma de matriz débil,
equilibrada o fuerte. Esto establece si los administradores del proyecto tienen poca, igual o más
autoridad que los administradores funcionales con quienes negocian la asignación de recursos.
26 Franklin F., Enrique Benjamín, Organización de Empresas, Ed. McGraw-Hill Interamericana; Segunda Edición México 2004 Pág. 106
I.P.N. – U.P.I.I.C.S.A.
25
Fig. II.3 Estructura Matricial
I.P.N. – U.P.I.I.C.S.A.
26
Ventajas Desventajas
• Mejora la comunicación entre las divisiones
funcionales.
• Un administrador del proyecto se responsabiliza por
la terminación exitosa del mismo.
• Se minimiza la duplicación de recursos.
• Los miembros del equipo tienen su propia área
funcional, después de la terminación del proyecto, de
manera que se preocupan menos por lo que ocurrirá
después de la terminación del proyecto.
• Al seguir las políticas de la organización 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
negociación.
• La suboptimización es un peligro, pues los
administradores del proyecto acumulan recursos
para su propio proyecto, con lo que perjudica a los
demás.
Fig. II.4 Ventajas y Desventajas del la estructura matricial
Fuente: Chase, Jacobs, Aquilano, “Administración de la producción y operaciones”, McGrawHill,
10ª. Edición, México 2005, Pág. 77
Estructura de Unidad/equipo. Durante algún tiempo las estructuras con estas características
también se denominaron híbridas, ya que en su diseño se emplean unidades representadas por los
rectángulos clásicos y por equipos de trabajo como enlace las áreas funcionales y el nivel de
producción. Si bien esta concepción abre las opciones del gráfico en función de su sola configuración,
también rompe con las líneas de mando por área para dar paso a un modelo que interrelaciona áreas y
niveles por medio de equipos. El esquema de operación tácticamente se apega más a unidades de
negocio o de carácter matricial que a una lineal.
Fig. II.5 Estructura unidad/equipo27
27 Franklin F., Enrique Benjamín, ob cit Pág. 107
I.P.N. – U.P.I.I.C.S.A.
27
“Las prácticas administrativas se relacionan con el tamaño de la unidad que se supervisa. La
flexibilidad en la asignación de personal, el grado de la delegación de autoridad y el énfasis sobre los
resultados en lugar de los procedimientos se relacionan con el tamaño de las unidades mayores.”28
El trabajo se subdivide en forma minuciosa en tareas pequeñas y rutinarias29 y “la rutinización
está relacionada con la alta formalización y centralización.” Todo ello no corresponde a las actividades
relacionadas con el desarrollo de sistemas.
“Diferenciación Horizontal La diferenciación horizontal se refiere a la forma en que están
subdivididas las tareas desarrolladas por la organización. Existen dos formas básicas 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 dándole 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 terminación. La segunda forma de diferenciación horizontal se ve con mayor claridad
en la línea de ensamble, donde cada obrero desempeña sólo 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 más adecuada para el segundo tipo de diferenciación; las tareas no rutinarias y muy variadas se
subdividen por lo común de acuerdo con el primer tipo”30.
Está comprobado que la especialización acelera el proceso productivo, pero esto sólo aplica a
las tareas altamente rutinarias, en donde se tiene la certidumbre de cómo hacer cada una de las
actividades; sin embargo en actividades no repetitivas, que requieren de la creatividad del trabajador,
tal como un mercadólogo, 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 intrínseca 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. Pág. 95 29 Ibidem. Pág. 99 30 Ibidem Pág. 100
I.P.N. – U.P.I.I.C.S.A.
28
La idea es que el potencial para el ejercicio del poder esté ahí, pero rara vez sea invocado, esto
dependerá de una correcta selección y reclutamiento de personal, de colocar a la persona más apta en
cada puesto, y de motivarlos y capacitarlos constantemente. El poder pues se emplearía para disuadir
polémicas 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 definición de una estructura orgánica con el objetivo y las necesidades de funcionamiento de
una organización es un requisito indispensable para que ésta opere dentro de un rango de actuación
que le permita generar productos, servicios o ambos acordes con los requerimientos de sus clientes.32
Burns y Stalker (1961)33 identificaron la forma ‘mecánica’, que es muy cercana al tipo ideal de
burocracia de Max Weber, y la forma ‘orgánica’, que es casi su opuesto lógico. De esta manera, en
lugar de tener autoridad jerárquica, las organizaciones orgánicas tienen una estructura de control en
forma de red; en lugar de una especialización sobre una tarea, un ajuste continuo y redefinición de
tareas; en lugar de una supervisión jerárquica, un contexto de comunicaciones que involucran
información y asesoría; ellos conciben las formas organizacionales como estrechamente vinculadas al
ambiente donde las organizaciones están insertadas, en especial en términos de tecnología que utiliza
la organización.
• Alta especialización
• Departamentalización rígida
• Cadena de mando clara
• Tramos de control estrechos
• Centralización
• Alta formalización
• Equipos Interfuncionales
• Equipos transjerárquicos
• Flujo libre de información
• Tramos de control amplios
• Descentralización
• Baja formalización
Fig II.6 Modelo mecánico versus modelo orgánico34
31 Hall, Richard, ob cit. Pág. 52 32 Franklin F., Enrique Benjamín, “Organización de empresas”, Mc-Graw Hill 2ª. Edición. México 2004, Pag. 118 33 Citado en Richard Hall .ob cit Pág. 54.
I.P.N. – U.P.I.I.C.S.A.
29
La figura II.7 conceptualiza los elementos anteriores al presentar dos modelos extremos de
diseño organizacional. A un extremo le llamamos el modelo mecánico. Generalmente es sinónimo de la
burocracia ya que tiene una gran departamentalización, mucha formalización, una red de información
limitada (en su mayor parte comunicación descendente) y poca participación de los miembros de bajo
nivel en la toma de decisiones. En el otro extremo está el modelo orgánico, el cual es plano, utiliza los
equipos transjerárquicos y funcionales, tiene baja formalización, posee una amplia red de información
(utiliza la comunicación lateral y ascendente así como descendente) e involucra una alta participación
en la toma de decisiones.
La forma de organización estable-mecánica es más adecuada
cuando se aplica lo siguiente:
La forma de organización adaptable-orgánica es más adecuada
cuando se aplica lo siguiente:
1. El medio ambiente es relativamente estable y seguro.
2. Los objetivos están bien definidos y se mantienen
3. La tecnología 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
coordinación y control tienden a permitir un sistema
jerárquico estructurado de manera estricta.
1. El medio ambiente es relativamente incierto e
inestable.
2. Los objetivos son diversos y cambiantes.
3. La tecnología es compleja y dinámica.
4. Hay muchas actividades no rutinarias en las que son
importantes la creatividad y la innovación.
5. Se utilizan procesos heurísticos de toma de
decisiones, el control y la coordinación se producen mediante
ajustes recíprocos. El sistema es menos jerárquico y más
flexible.
Fig. II.7 Condiciones propicias para aplicar el modelo mecanicista y el orgánico
Como regla general, mientras mayor es la calidad de la organización, menor es el nivel de
centralización35. Esto lo podemos apreciar en la selección de personal de Microsoft, ya que se dice que
Bill Gates contrata a gente con más habilidad que la que él posee, ya que, según él, es la forma más
eficiente de enfrentarse a la competencia. En general el modelo orgánico fue creado pensando en las
tareas no rutinarias, en donde se requiere de la creatividad de cada uno de sus miembros.
Estructuras múltiples
Existen variaciones intraorganizacionales, tanto dentro y entre las unidades organizacionales,
como hacia arriba y hacia abajo en la jerarquía, de hecho la complejidad, la formalización y la
centralización varían dentro de una misma organización. En ocasiones existe una cantidad mínima 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, México 1999, Pág. 497 35 Hall, Richard, Ob cit, Pág. 52
I.P.N. – U.P.I.I.C.S.A.
30
centralización ocurre cuando se retiene el poder para la toma de decisiones en la cima o cerca de la
parte superior de la organización. 36
Las variaciones intraorganizacionales en complejidad se pueden observar en los departamentos
de investigación y desarrollo, en los cuales existen varios niveles jerárquicos 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 fabricación, es más corto el tramo de control para cada supervisor,
y la unidad se verá más como una pirámide.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 evaluación de desempeño de los
investigadores). En cuanto a la parte inferior está
conformada por las personas que realizan las
actividades de investigación y desarrollo.
Fig. II.8 Estructura Organizacional Híbrida
II.3 Conformación del equipo de trabajo
La organización de un proyecto está basada en la existencia de líderes de proyecto o
administradores de proyecto, los cuales dirigen grupos de desarrollo que abordan uno o más sistemas o
módulos de la solución los cuales han sido agrupados considerando los conceptos que en ellos se
manejan y la sincronización de desarrollo.
II.3.1 El administrador del proyecto
La selección del administrador no siempre es perfecta, por lo general hay un riesgo con
cualquier decisión personal. Por tanto hay que crear conciencia de las características importantes que
deberán formar parte de un efectivo administrador y su equipo de trabajo.
36 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Pág. 99 37 Ibidem Página 56
I.P.N. – U.P.I.I.C.S.A.
31
Para hacer la selección del personal que formará el proyecto, primeramente deberá
seleccionarse al administrador o líder del proyecto, dicha persona tiene el rol principal en la planeación
y ejecución del mismo. Para determinar el candidato idóneo 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, analítica y práctica;
liderazgo, conocimientos técnicos, manejo de personal, además 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 líder
que ayuda a diseñar, coordinar e implantar el plan del proyecto. El líder del proyecto es el apoyo
durante toda la duración del proyecto hasta su liberación.
En cuanto a conocimientos técnicos, 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 técnica basada en conocimiento y
entrenamiento, ambos en el contexto del área que el proyecto demande y en herramientas de
administración de proyectos. Deberá tener la capacidad de entender al mercado, a los clientes, y de
poder involucrarse tecnológicamente en el proyecto, de igual manera deberá tener conocimiento básico
de organizaciones, por ejemplo, cómo organizar, determinar necesidades de personal, articular las
necesidades del proyecto, los niveles administrativos, ligar la meta del proyecto a la misión de la
empresa así como recompensar y disciplinar a los empleados.
II.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 tomarán 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 líder 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,
deberán de asignarse las actividades y responsabilidades de cada uno de los equipos de trabajo.
I.P.N. – U.P.I.I.C.S.A.
32
Se deben de formar equipos de trabajo que se encarguen de actividades que estén relacionadas
en forma modular, de las cuales se puede asignar un responsable o administrador, para determinar y
dirigir las actividades de ese módulo con el fin de que se lleven a cabo de acuerdo al plan general del
proyecto, para el manejo de estos módulos, existen formatos sencillos que permiten definir que es lo
que se debe de hacer, el plan de trabajo por módulo y los recursos asignados, además se deberá de
realizar un monitoreo para detectar y corregir posibles desviaciones.
Estos módulos de trabajo deberán definirse claramente, es decir tendrán fechas de inicio y de
terminación de manera que se pueda ir midiendo el desempeño del equipo. Las actividades de cada
módulo deberán de estar documentadas de manera estandarizada con la finalidad de que a cada
miembro del módulo se le deberá de informar las actividades, los productos y las fechas de entrega de
los mismos. Es muy importante registrar la evolución del proyecto. También es necesario describir cada
una de las actividades realizadas por cada módulo, la relación entre ellos y la relación con el proyecto y
darlos a conocer a todos los involucrados en el proyecto. Finalmente, se debe presentar de manera
periódica, a todo el equipo de trabajo el avance del proyecto. Se contempla también la participación de
algunas entidades de Staff destinadas a apoyar las actividades de desarrollo.
II.3.3 Comité de validación
Estructura funcional. Está conformado por el líder de proyecto el cual posee una visión general
del proyecto y un conocimiento aplicativo integral. Por su parte la gerencia de planeación y logística
proporciona la visión administrativa general e informa acerca del dimensionamiento e impactos. En la
parte de desarrollo se encuentran los analistas, los cuales dan un enfoque tecnológico y su
conocimiento aplicativo modular
El estrato de soporte está representado por: Infraestructura quien proporciona las bases y
estándares y realiza la identificación de código reutilizable y del adaptable además del supervisor quien
realiza la revisión de estándares de análisis, diseño y programación.
I.P.N. – U.P.I.I.C.S.A.
33
CAPITULO TRES ________________________________________________________________________
EL ENTORNO DE LOS PROYECTOS DE SOFTWARE EN MÉXICO
“Yo soy yo y mis circunstancias” 38.
José Ortega y Gasset
El hombre está en constante evolución, 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 económico, el social, el cultural, el político, etc. Es por ello que el presente trabajo comienza
con las últimas transiciones que ha tenido la economía, de la Economía Agrícola a la Manufacturera y
finalmente a la Economía de la Información, con sus correspondientes repercusiones (tanto
cuantitativas como cualitativas) en el aspecto laboral.
Es en el contexto de la Economía de la Información en donde aparecen las empresas
desarrolladoras de software, con una problemática muy específica que deriva de su intrínseca
naturaleza, con ello nos referimos a una labor creativa muy similar a la creación de obras de arte, lo
cual hace a la actividad de desarrollo de software muy distinta a otros tipos de trabajo como la
actividad agrícola o manufacturera y que incluso la hace distinta de otras empresas del ramo de
servicios. Es por ello que este capítulo aborda la problemática de la administración de proyectos de
software, sus síntomas y sus causas raíz, 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)
I.P.N. – U.P.I.I.C.S.A.
34
III.1 LAS TRANSFORMACIONES ECONÓMICAS Y SUS REPERCUSIONES LABORALES.
La transición de una economía industrial a lo que se denomina economía de la información no
es la primera –y tampoco será la última- que producirá cambios radicales en las reglas de la actividad
económica y empresarial. Hace más de un siglo Estados Unidos dejó de ser una economía agrícola para
convertirse en una economía industrial, transición propiciada por la invención y el perfeccionamiento de
la máquina de vapor. En la siguiente figura se muestra otra transformación: La fuerza laboral que
trabajaba directamente en la manufactura en la economía industrial disminuyó de 40% a menos de 5%
en la economía de la información:
Fig. III.1 Fuerza de trabajo de Estados Unidos en las economías agraria, industrial y de la información.39
En la transformación económica anterior, los incrementos de la productividad favorecieron la
unión de una nueva organización y una nueva tecnología, con ello la mayoría de los trabajadores del
campo fueron desplazados o reubicados en actividades industriales como la siderurgia, la industria
automotriz y la fabricación de aparatos electrodomésticos. La actividad industrial requería nuevas
estructuras para organizar los recursos, y también nuevos principios para administrarlos (Estas
situaciones generaron las condiciones adecuadas para la aplicación de las ideas de Frederick W. Taylor
y Henri Fayol).
39 Nolan, Richard, “Destrucción creativa”, Mc Graw Hill, México, 1996 Pág. 3
I.P.N. – U.P.I.I.C.S.A.
35
“De manera similar, la actividad relacionada con la información requiere nuevas estructuras
para organizar los recursos y además, nuevos principios para administrarlos. Estamos a punto de ser
una economía totalmente orientada a la información”40 debido a que la tecnología 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 economía de la información vivimos una revolución informática y los
paradigmas con los cuales veíamos la economía hace 20 o 30 años no son los mismos hoy en día.
Actualmente, la empresa más rentable del mundo produce software y la persona más rica del mundo es
un empresario de software, situación impensable hace 40 años, cuando las empresas que integraban
esas listas eran petroleras o siderúrgicas. Por otra parte la creación de empleos durante los últimos 30
años se ha dado en empresas más recientes que tienen menos de 100 empleados, y no en las grandes
empresas.
Esta situación podría parecer ajena a nuestro entorno, sin embargo según una investigación41
realizada por un diario de la ciudad de México 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 (Elaboración propia)
40 Nolan, Richard, “Destrucción creativa”, Mc Graw Hill, Méxic o, 1996, Págs. 3-4 . Sanders, Donald H. “Informática Presente y Futuro” Traducción de la 1ª. Ed. En Inglés de Computers Today. 1988 Págs . 5-7 41 Juárez Hernández, Othón, “Administración de la compensación Sueldos, incentivos y prestaciones”, Oxford University Press, Primer edición; México, 2000; Pág. 3. Se transcribe la nota al pie original: “Excélsior, sábado 29 de octubre de 1994, Sección financiera, primera plana.”
I.P.N. – U.P.I.I.C.S.A.
36
La anterior situación pudo ser corroborada mediante un estudio hecho como parte del presente
trabajo de investigación entre seis de las principales empresas consultoras de software con oficinas en
la ciudad de México42. de acuerdo con el Comité Nacional de Productividad e Innovación Tecnológica
A.C., y la Asociación Mexicana de Calidad en Ingeniería de Software quienes destacan a Hildebrando,
IDS, Praxis y Softtek entre los 11 desarrolladores más grandes de México.43 Los cuales abarcan la
mayor parte de los proyectos en la Ciudad de México, esto último es corroborado por Enrique Quintana
analista económico, quien comenta que “Las empresas desarrolladoras de software en México apenas
llegan a 206 y de ellas 180 son pequeñas o micro” 44,
Al término de este estudio se obtuvo como resultado que el sector con mayor número de
proyectos de desarrollo de sistemas en el país 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 sistematización en comparación con el sector primario en nuestro país en realidad
son muy pocas las empresas de este sector que adquieren los servicios de una empresa consultora para
desarrollar sistemas de información ‘a la medida’.
En este orden de ideas podemos decir que el sector servicios es el que más invierte en
desarrollo de sistemas con el afán de mantenerse a la vanguardia en tecnología, ser competitivo al
ofrecer más 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 remuneración
del personal.
0
10
20
30
40
50
60
70
SECTORPRIMARIO
SECTORSECUNDARIO
SECTORTERCIARIO
Fig. III.3 Proyectos de desarrollo de software por sector en la ciudad de México (Elaboración propia Abril 2006)
42 Consultar Anexo A 43 http://www.compite.org.mx/cenec/cenec100305.htm Fecha de consulta: 10 de Septiembre de 2006
I.P.N. – U.P.I.I.C.S.A.
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, razón por la cual presentamos en la Figura III.4, la participación de cada uno de los tipos
de servicios y su porcentaje de participación en la muestra levantada:
EDUCATIVO 4%
GOBIERNO9%
COMERCIO17%
SALUD4%
SEGUROS7%
FINANCIERO49%
TELECOMUNICACIONES10%
Fig. III.4 Distribución de proyectos de desarrollo de software en el sector Servicios en la ciudad de México (Elaboración propia
Abril 2006)
En ese sentido, el desarrollo de software constituye un sector estratégico, 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 evolución de las mismas y la administración 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 Industria del Software
pueden variar, dependiendo del papel específico 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 Administración de proyectos y la atención 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
I.P.N. – U.P.I.I.C.S.A.
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: compensación, desarrollo de competencias.
El software difiere de otras empresas porque en realidad no es como tal un producto, sino que
se convierte en una función o aplicación de un proceso de negocio. Esto significa que el rango de
aplicaciones generalmente es muy amplio. El software puede apoyar en la producción de reportes, la
construcción de un puente, la navegación de un yate, la marcación de un número telefónico o la
compra-venta de acciones en los mercados bursátiles. Por ello existen muchísimas categorías 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 solución, 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 situación de la industria en particular.
En cuanto al mercado objetivo, una empresa puede proveer servicios o productos de software
para diversos clientes:
• Por tamaño: Corporativo, empresa mediana o pequeña, consumidor directo.
• Por tipo de solución: Horizontal, vertical
• Por tipo de industria: financiera, gobierno, manufactura, etc.
Las empresas que venden a corporativos tienen más probabilidades de subsistir, porque pueden
jugar ampliamente con las características del producto para responder a las necesidades del cliente. En
cuanto al tipo de aplicación que se desea crear, las soluciones horizontales parecen ser más 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 más exitosas que se conocen (Microsoft, SAP) crean aplicaciones horizontales con
módulos verticales (MS Proyect, el mismo SAP) específicos que sirven para abrir el camino. A su vez, es
necesario determinar en cuántos y cuáles mercados verticales habrá que iniciar.
I.P.N. – U.P.I.I.C.S.A.
39
Otra consideración 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 económica mediante
contratos ya sea de largo plazo, de garantía o por evento.
Las empresas que inician operaciones generalmente tienen el fuerte debate entre ser una
empresa de producto, de servicios o híbrida. Los negocios son muy distintos:
• El negocio de productos de software es un negocio de volumen. Es clave la capacidad de
mercadotecnia y distribución para posicionarse como plataforma líder.
• El negocio de servicios de software, el cual es sobretodo un negocio muy especializado y
basado en satisfacer necesidades específicas del cl iente, basado en capital humano, relaciones
y proyectos. Incluso, la construcción de software así como el análisis y la captura de
requerimientos pueden ser de lo más críticos para la competitividad de la empresa.
Una vez que se ha planteado una somera clasificación 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 economía de la información, es
por ello que se enfatiza que la actividad relacionada con la información requiere nuevas estructuras
para organizar los recursos y además, adaptar e incluso replantear algunos principios para
administrarlos. Este tipo de empresa se enfrenta a una problemática muy específica, la cual se detalla
en la siguiente sección.
III.2 Problemas comunes en la administración de proyectos de software.
Los problemas típicos que aparecen en un proyecto de software están relacionados con los tres
principales aspectos a controlar: tiempo, costo y calidad45. A pesar de que hay numerosas razones para
que un proyecto no satisfaga estos aspectos de desarrollo de sistemas, las razones más comunes son:
• La definición de requerimientos es inadecuada.
• La Planeación del proyecto es inadecuada.
• Existen Habilidades técnicas deficientes en los miembros del equipo.
• Falta de trabajo en equipo.
• Insuficiente supervisión del avance del proyecto.
• Insuficiente apoyo por parte de la empresa.
45 Sommerville, Ian “Ingeniería de Software”, 6ª. Edición, Pearson Educación, México 2002, Pág. 9-13
I.P.N. – U.P.I.I.C.S.A.
40
Como podemos ver estos problemas también están íntimamente relacionados con el factor
humano. Los puntos del III.2.1 al III.2.5 fueron extraídos del material del módulo de Ingeniería de
software del Diplomado en Administración y Desarrollo de sistemas impartido por el Centro de
Desarrollo Empresarial y Ejecutivo en el Tecnológico de Monterrey Campus Cd. De México en Abril de
2000. Veamos a detalle cada uno de ellos.
III.2.1 Definición 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 términos 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 diseños deficientes. Esta situación genera un
problema si los requerimientos no pueden ser negociados y modificados por diversas razones
contractuales.
III.2.2 Planeación Inadecuada.
Todo proyecto sigue un plan escrito desde el comienzo del mismo. Debido a que los desarrollos
de sistemas son muy dinámicos es necesario actualizar los planes de manera que reflejen la
comprensión y estado actual del sistema para evitar que en el futuro se lleven a cabo acciones que
traigan consigo una gran cantidad de problemas.
S i desde un principio los objetivos originales del proyecto no están bien planteados o no
corresponden con los objetivos particulares de la empresa, el producto que se genere no será óptimo.
También puede suceder que el proyecto no siga el plan original, debido a que no se le da el correcto y
oportuno seguimiento, mediante reuniones periódicas, con los responsables. El plan no cuenta con el
detalle suficiente como para poder desglosar las actividades adecuadamente.
III.2.3 Habilidades técnicas deficientes.
El personal encargado de llevar a cabo las actividades de tipo técnico deberá ser altamente
capacitado de manera que se reduzca al mínimo posible el tiempo para la solución de problemas. Es
importante, por ello, que la Administración del Proyecto mantenga un personal técnico 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
I.P.N. – U.P.I.I.C.S.A.
41
la rotación es bastante frecuente, es necesario contar con una estructura organizacional que soporte
estos cambios.
III.2.4 Falta de trabajo en equipo.
En ocasiones el equipo de desarrollo no tiene buena comunicación, ni hay un esfuerzo
coordinado, lo cual va en contra de uno de los principios básicos de la administración. En la actualidad
los sistemas de información son muy complejos y requieren de la interacción continua de los miembros
que participan en su construcción. En ocasiones en un proyecto existen personas que no poseen la
habilidad de trabajar en equipo trayendo consigo la pérdida de esfuerzos conjuntos.
III.2.5 Insuficiente supervisión del avance.
Las revisiones sobre el estado de un proyecto en ocasiones no son llevadas a cabo
periódicamente sino hasta que se programa una revisión formal. Una de las tareas de la administración
de proyectos es realizar supervisiones informales que permitan determinar el avance, posibles
problemas y necesidades que eviten la pérdida 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 económicos, recursos materiales y recursos humanos).
III.3 La Crisis del Software: Panorama del Origen del Problema
La Ingeniería de Software es una disciplina relativamente joven, surge formalmente en 1968
cuando por primera vez se hace mención a la “crisis del software”. Este término se refiere a que el
proceso de desarrollo de software no posee las características que se presentan en el desarrollo del
hardware46 (Equipo físico, tal como los dispositivos electrónicos, magnéticos y mecánicos) y esto debido
a que en el desarrollo de hardware a diferencia de su contraparte de software intervienen muy
contadas personas, además de que el hardware es el primero que avanza. Las computadoras
evolucionan vertiginosamente, en cuanto a capacidad, velocidad y disminución de costos, ocasionando
su popularización, 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 operación y el
mantenimiento que sobrepasaba la capacidad de los desarrolladores, además las perspectivas de
mejorar este proceso con respecto a la complejidad creciente de los sistemas eran desalentadores. Aún
cuando se han desarrollado desde entonces modelos y métodos para manipular la complejidad del
software, aún se tienen problemas con los sistemas desarrollados, de ahí que se considere que la
46 Sanders, Donald H., “Informática Presente y Futuro” Trad. De la 1ª. Ed. En Inglés de Computer Today 1988 Págs. 5-7
I.P.N. – U.P.I.I.C.S.A.
42
Ingeniería de Software padece de una aflicción crónica47 , ya que crisis se define como el momento,
etapa o evento decisivo en el curso de algo.
En las últimas dos décadas se ha dado un aumento sin precedentes de la aplicación y uso de la
tecnología 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 Ian Sommerville y Roger Pressman,
autores de libros en Ingeniería de Software (incluidos en la biliografía del presente trabajo) tiene ciertos
síntomas:
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 módulos no encajan entre
sí, por lo que el software resulta difícil de mantener o extender. Por otro lado, se descubren en forma
tardía fallas críticas del proyecto, además de que el desempeño del software es inaceptable48.
En ocasiones el proyecto es una solución en busca de un problema, lo cual suena descabellado
y sin embargo es un problema común en nuestro entorno nacional. En muchos casos, basados en la
experiencia obtenida en el medio, se diseñan herramientas de software, para después 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 Médica y Hospitalaria (ASIMEDH), el cual fue el
resultado de una línea de investigación de la empresa Softtek, en el cual se creo primero el sistema y
después 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 situación
se origina cuando no se le da la suficiente importancia a los proyectos de software, o bien no se tiene la
suficiente difusión de los beneficios para la empresa y para los empleados que reportaría el proyecto
una vez que se haya terminado.
47 Pressman, Roger S., ”Ingeniería del Software. Un enfoque práctico”, 4ª. Edición México 1998. Mc Graw Hill, Pág.12 48 Booch, Grady, Rumbaugh, James, Jacobson, Ivar, “Rational Unified Proccess Fundamentals”, Ed. Itera; Edición (Versión) 5.5, año de publicación 2001. Módulo 1, Págs. 5 y 6.
I.P.N. – U.P.I.I.C.S.A.
43
III.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 homogéneo, ya que en muchas
ocasiones "es una persona quien lo requiere y es otra la que lo usa", además requiere de mucho
personal para su desarrollo y mantenimiento (número de desarrolladores, detalles técnicos y control
administrativo), en este rubro podemos profundizar mencionando que es muy común que quienes
desarrollan un sistema son distintos de quienes le dan mantenimiento. Finalmente, podemos comentar
que los cambios, tanto tecnológicos 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 Raíz de los diversos problemas descritos en la sección anterior tenemos, que la
comunicación entre los usuarios y los desarrolladores es ambigua e imprecisa, la complejidad de los
requerimientos es considerable, además de que hay una insuficiente administración de requerimientos,
existen inconsistencias no detectadas en los requerimientos, el diseño y las implementaciones; los
productos terminados no son probados suficientemente y hay una pobre administración en el control de
cambios
Fig. III.5 Enfocándose en las Causas Raíz los síntomas se eliminan
Fuente: Booch, Grady, Rumbaugh, James, Jacobson, Ivar, “Rational Unified Proccess Fundamentals”, Ed. Itera; Edición
(Versión) 5.5, año de publicación 2001. Módulo 1, Pág. 7.
Todo lo anterior nos lleva a formularnos varias preguntas: ¿Cómo desarrollar eficientemente
software?, ¿Cómo dar mantenimiento al cada vez mayor volumen de software?, ¿Cómo 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 difícil evaluar el avance?
I.P.N. – U.P.I.I.C.S.A.
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. Según
Donald H. Sanders (1988) “Preparar programas computacionales ha sido y es un arte que requiere
cuidado especial” 49 La materia prima es la información, por lo tanto es intangible, por ello es difícil ser
objetivos en la evaluación del progreso.
Otra situación común es caer en el error de suponer que al desarrollar software usando nuevas
tecnologías 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
rotación del personal, programas de selección de personal adecuados, entre otros.
DELIMITACIÓN DEL PROBLEMA
Una investigación del grupo Standish demuestra que 31.1% de proyectos serán cancelados
antes de ser terminados. Otros resultados indican que 52.7% de proyectos costarán 189% de sus
estimaciones originales. El costo de estas faltas y los sobrantes son sólo la punta del iceberg proverbial.
Los costes de oportunidad perdidos no son mensurables, pero podrían fácilmente estar en el orden de
los billones de dólares.50
Esta situación puede ser abordada desde muchos puntos de vista, tales como el punto de vista
técnico especializado, metodológico, o bien como en el presente trabajo con un enfoque administrativo,
y más específicamente desde el punto de vista de la Administración de proyectos. Por ello uno de los
objetivos del presente trabajo es enfatizar el trabajo en equipo y mejorar la comunicación interna.
El presente trabajo se centra en mejorar el desempeño en el desarrollo de sistemas, hacer más
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
través de la aplicación de la Administración
Una vez que se ha planteado la problemática 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 desempeño, evitar la
pérdida de conocimiento, mitigar los riesgos derivados de las curvas de aprendizaje, lo cual redunde en
un aumento en la productividad de la organización.
49 Sanders, Donald H., Ob cit Págs. 5-7
I.P.N. – U.P.I.I.C.S.A.
45
Los cambios en la estructura de la organización, en las funciones por puesto, en la motivación
de los empleados, redundarán en una mejora en el desempeño 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 organización al que va enfocado el presente trabajo se
ubica en el sector servicios de desarrollo de aplicaciones de software hechas “a la medida”, esta
expresión se deriva de que se dice de los sistemas de software que son hechos exactamente como lo
pide el cliente, el término 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 análisis y diseño 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 función sustantiva, redefiniendo las funciones de cada puesto, creando con ello
una organización con células de conocimiento, mediante la flexibilidad de la organización para
adaptarse al intercambio de roles, la centralización y descentralización de la toma de decisiones, la
formalización y la comunicación.
La productividad se puede obtener al lograr mayor eficiencia en el trabajo que desempeñe cada
empleado, evitando al máximo 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 comunicación.
A continuación se presenta el flujo de la investigación, la cual tiene dos vertientes: La investigación bibliográfica, por un lado y, la experiencia y las aportaciones personales por otro.
Fig. III.6 Flujo de la Investigación Fuente: (Elaboración propia)
50 www.standishgroup.com/sample_research/chaos_1994_1.php (Fecha de Acceso: 17/Abril/2006)
I.P.N. – U.P.I.I.C.S.A.
46
CAPITULO CUATRO ____________________________________________________________________________________________
HISTORIA DE LOS CICLOS DE DESARROLLO
DE SOFTWARE Una organización bien diseñada no es una solución 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 organización es la tecnología52, en esta
época llamada “Era de la información”, la Tecnología de la Información (en otras palabras el Software)
resulta un buen punto de partida para entender la división del trabajo dentro de una organización
desarrolladora de software, por ello el presente capítulo hace una breve semblanza histórica de cómo
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 organización que se
encarga de crear tecnología de información para otras organizaciones, se describen modelos de
procesos y someramente se menciona un método de evaluación para el desarrollo y mantenimiento de
software, por otra parte, en el siguiente capítulo se hace la propuesta de una estructura organizacional
basada en células de conocimiento, la cual resulta más acorde a estos tiempos en donde se pretende
evitar la pérdida de conocimiento.
IV.1 Modelo de desarrollo de software
El proceso de desarrollo de software es, una secuencia de actividades que producen dicho
software53. Se ha visto que las fases principales son: requerimientos, análisis, diseño, codificación o
construcción y pruebas, todas estas actividades en ocasiones son divididas en actividades de más 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
años, el objetivo de describir los siguientes modelos es para observar la evolución en la forma de
51 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Pág. 109 52 Hall, Richard, Ob cit Págs. 97 – 103. 53 Softtek, “Proceso de Desarrollo de Software de Softtek”, Sosfftek Educación en Tecnología, Méx. 1997, Pág.17
I.P.N. – U.P.I.I.C.S.A.
47
organizar tanto al personal que desarrolla el software, como a las actividades intrínsecas 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 específicas. Finalmente, se describe el Modelo de
Proceso de Software, un modelo diseñado 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
organización de empresas dedicadas a la actividad de desarrollo de software. Dicha evolución ha sido
de la siguiente manera:
a) El Desarrollo del Modelo de Procesos
En este modelo no hay planificación sino que las cosas son simplemente hechas como y cuando
son requeridas, por ejemplo cuando el código ha sido escrito entonces la documentación es considerada
y normalmente al final del proyecto se escribe la especificación, por supuesto de esta manera el
software esta sincronizado con las especificaciones.
b) La Codificación y el arreglo del modelo
Es un proceso iterativo donde el código es desarrollado en fases, cada fase contribuye a la
siguiente modificación, liberación y fase de prueba y entonces regresa al mismo punto para modificarlo
nuevamente. Aunque trabaja bien en sistemas pequeños una persona puede acomodar y cambiar los
requisitos en proyectos grandes lo que lo hace difícil de administrar, desarrollar, probar y modificar
porque se desarrolla la codificación 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 guían el proceso de
desarrollo. Aún 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 operación sea exitosa y el mantenimiento fácil de
realizar.
Los modelos del proceso de desarrollo de software se pueden considerar como abstracciones.
En la práctica y dependiendo de la complejidad del sistema, es posible que se puedan utilizar varios
modelos a la vez, combinando sus características. A continuación se presentará una breve descripción
de las características básicas de los modelos siguientes: El ciclo de vida del software o modelo de
cascada, El Desarrollo evolutivo y Desarrollo basado en componentes o reutilización.
I.P.N. – U.P.I.I.C.S.A.
48
IV.1.1 Modelo del ciclo de desarrollo en cascada
El modelo o ciclo en cascada es uno de los más utilizados, proporciona un estricto control en cada paso de la construcción del software pues pone mucho énfasis desde el inicio en los requerimientos.
Se compone por 5 fases (aunque en algunos casos se realiza una división más detallada y se pueden ver 6 o hasta 7 fases en este modelo), las cuales son:
1. Análisis 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 algún punto de riesgo.
2. Diseño Va dirigido a definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura externa y evitar realizar modelos que reflejen la proyección 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. Implementación 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 integración 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
Después de que cada una de las fases es terminada y el sistema ha entrado a producción se requiere
una línea de atención que observe y valide el buen funcionamiento de software entregado54.
Fig. IV.1 Ciclo de Desarrollo en Cascada
-54 Sommerville, Ian, “Ingeniería del Software”, Addison Wesley Iberoamericana, S.A., Segunda edición, México, 1988, Pág. 4
I.P.N. – U.P.I.I.C.S.A.
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 están educadas con una mentalidad de disciplina, lo que deriva en que cualquiera de estas fases se pueda repetir varias veces pues comúnmente 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 tardías y generación de reprocesos para identificar la fase donde se originó el error.
Además de lo mencionado, a continuación se presentan, en la Figura IV.2, algunas ventajas y desventajas muy visibles en este modelo cascada:
Ventajas Desventajas Si se completa una fase es más fácil manejar la siguiente Implementa el manejo de una disciplina al entender la filosofía del modelo Promueve la generación de documentación en cada fase
Los requerimientos usualmente no se definen en su totalidad al inicio del proyecto pues la información disponible es limitada Si existe algún cambio es muy difícil de adaptarlo pues además no se anticipa hacia lo que puede estarse presentando en el entorno La identificación de errores comúnmente no se logran ver hasta que se tiene una parte muy avanzada del proyecto Es muy costoso por la reinversión de tiempo y recursos para corregir los errores o implementar algo nuevo lo que lo lleva a ser poco confiable. Hay asignación 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 aplicación que le es entregada (software)
Fig. IV.2 Ventajas y Desventajas del modelo en cascada (Elaboración propia)
I.P.N. – U.P.I.I.C.S.A.
50
IV.1.2. Desarrollo evolutivo
El desarrollo evolutivo surge al reconocer que el software evoluciona con el tiempo. La
característica principal de este modelo es que es iterativo y en cada iteración se desarrollan versiones
ejecutables cada vez más completas del sistema. Usa prototipos para los requerimientos de las
versiones. Aunque inicialmente proporciona una visibilidad muy buena del producto al usuario y una
rápida capacidad operacional, la desventaja es que se puede desarrollar una mala codificación, 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 versión inicial de un sistema que se utiliza para demostrar
conceptos, opciones de diseño y en general propuestas de solución al problema. El modelo de
desarrollo evolutivo es un modelo iterativo que busca que las operaciones de especificación, desarrollo
y prueba se lleven a cabo concurrentemente, elaborando un prototipo inicial y refinándolo de acuerdo
con los comentarios del usuario, logrando ambos una mejor comprensión del sistema. El modelo de
prototipos tiene el inconveniente de que, por la rapidez de desarrollo, no es posible considerar
funciones críticas como puede ser la seguridad o el desempeño56.
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 iteración se le agregan nuevos
requerimientos. En el caso de los prototipos desechables, la función del prototipo sólo es clarificar los
requerimientos, después de la evaluación, el prototipo es desechado, no se utiliza como base para el
desarrollo posterior. En ocasiones se utiliza esta técnica 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 más importante la entrega y el funcionamiento del software que la
documentación, implementación 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. Pág. 39
I.P.N. – U.P.I.I.C.S.A.
51
incremento un producto ejecutable de ahí que los procesos de especificación, diseño e implementación
se entrelazan. Por la naturaleza del modelo, se utilizan herramientas de desarrollo rápido de
aplicaciones, lenguajes de 4ª generación y lenguajes para desarrollo de interfaces gráficas.
IV.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
fácilmente en niveles detallados. Se basa en cuatro actividades:
Planificación. Equivale a la recolección de requisitos en el modelo tradicional (cascada). Además se
planean las actividades a realizar en cada iteración, posteriormente se determinan objetivos y
restricciones. En el análisis de riesgo se Identifican y gestionan los riesgos, se estiman la probabilidad, y
se evalúan las consecuencias, en la actividad de ingeniería se desarrolla un prototipo y código y se
realiza la implementación y realización de pruebas, manual del usuario. Finalmente la evaluación del
cliente y valoración de los resultados equivale a la liberación en el modelo tradicional. El modelo de
espiral, es altamente teórico, contiene una pequeña guía de como adaptar, planear o ejecutar un
proyecto y se enfoca en la continua necesidad de refinar los requerimientos y estimaciones.5 7
57 Pressman, Roger S. “Ingeniería del Software. Un enfoque práctico”. 6ª. Edición 2002. Mc Graw Hill, Pág.54
I.P.N. – U.P.I.I.C.S.A.
52
Fig. IV.3 Ciclo de Desarrollo de Espiral
Fuente: Microsoft “Student Workbook – Solutions Development Discipline”. Microsoft 1997. Pág. 65
I.P.N. – U.P.I.I.C.S.A.
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 retroalimentación al proyecto.
Ventajas Desventajas -Interactivo. Si es necesario repetir algún proceso, sólo se pierde el esfuerzo de una iteración y no el valor del producto completo. -Activa participación del cliente ya que es involucrado en todas las etapas, produciendo retroalimentación. -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 más 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 código sin tener un análisis bien sólido. -No se descompone el proceso fácilmente en niveles detallados Este modelo es altamente teórico, y requiere no sólo mucha disciplina de cada uno de los integrantes, sino de una gran sincronización 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 investigación.
Fig. IV.4 Ventajas y desventajas del modelo de Espiral
IV.2.- Características del proceso unificado de desarrollo de software
Este proceso tiene las siguientes características fundamentales: está dirigido por casos de uso,
está centrado en la arquitectura, es iterativo e incremental, está basado en componentes
interconectados a través de interfaces y utiliza el lenguaje unificado de modelado (UML por sus siglas
en inglés) para su representación, además 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 representación 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 interactúa
con el sistema da origen a un caso de uso. Los actores no necesariamente son personas, también
pueden ser componentes software o hardware.58
Un caso de uso59 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.
I.P.N. – U.P.I.I.C.S.A.
54
El conjun to de actores y casos de uso del sistema forman el Modelo de Casos de Uso, que
constituye una especificación completa de todas las posibles formas en que se puede utilizar el sistema,
delimita sus alcances y guía el proceso completo siguiente que incluye las etapas del análisis, el diseño,
la implementación y la prueba del sistema, donde se obtienen los Modelos de Análisis, Diseño y
Despliegue, Implementación y Prueba, respectivamente.
Centrado en la Arquitectura: La arquitectura de software60 define el sistema en términos de sus
componentes computacionales y la interacción entre ellos. La arquitectura de capas61, trata de
representar cada capa como una colección 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 iteración se analice, diseñe, implemente y pruebe un conjunto de casos de uso y que el
sistema progrese incrementalmente a medida de que se consideren más y más casos de uso. El análisis
del sistema se lleva a cabo mediante la identificación de la estructura de clasificadores(diagrama de
clases), la realización de los casos de uso y diagramas de colaboración. Un clasificador es un
mecanismo que describe características estructurales y de comportamiento e incluye interfases, clases,
tipos de datos, componentes y nodos.
El modelo de diseño toma al Modelo de Análisis como entrada, pero toma en cuenta el entorno
de implementación a utilizar, por lo que este modelo es más físico que conceptual. En este modelo
también se utiliza el diagrama de clases, pero se incluyen más detalles que en el Modelo de Análisis
para reflejar la adaptación del modelo al entorno de la implementación. También 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 también se agrupan las clases en subsistemas, definiendo la interfaz de cada
subsistema. El modelo de despliegue, permite representar gráficamente la distribución del software en
los diferentes nodos de red y su comunicación entre ellos.
59 Ibidem. Apéndice A. Pág. 413 60 Cromwell, Jeff, “The Art and Science of Software Architecture”. Dr. Dobb s Journal Software Tools for the Proffessional Programmer. Vol.25, Issue 6, Jun. 2000. Pág.143. 61 Página 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
I.P.N. – U.P.I.I.C.S.A.
55
Fig. IV.5 Cuadro comparativo de modelos de desarrollo (Elaboración propia)
CARACTERISTICA CASCADA ESPIRAL
ITERATIVO
DIAGRAMA
Implantación en la realidad.
Es el más comúnmente implantado, aunque en muchos casos no es lo mejor.
Es un modelo un tanto Teórico y no es comúnmente implantado,
Es una de las mejores prácticas de Desarrollo de Sistemas
Hace mayor énfasis en:
Los requerimientos y el diseño proporcionando un estricto control en cada paso de la construcción del software.
Los riesgos y costos del desarrollo de software. (Añade el elemento de análisis 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 código sin tener un análisis bien sólido.
Cada iteración termina con la liberación de un ejecutable.
Interacción con el usuario
No fomenta la interacción con el usuario.
Comparado con el modelo de cascada, es más interactivo porque activa la participación del cliente.
Debido a las refinaciones sucesivas permite una retroalimentación continua con el usuario.
Administración de los requerimientos
Trabaja con los requerimientos congelados, aunque se dificulta definir todos los requerimientos desde el inicio del proyecto
Alcance sinérgico. Los cambios a los requerimientos son identificados más fácilmente por la interacción con el usuario.
Facilita la inclusión de cambios tácticos a los requerimientos o a las características.
Puntos de evaluación 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 construcción.
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.
Administración del Cambio
Es muy difícil de adaptar si se quiere realizar algún cambio.
Comparado con el modelo de cascada, no se dificultan mucho los cambios.
En este modelo es más fácil hacer cambios.
I.P.N. – U.P.I.I.C.S.A.
56
CARACTERISTICA CASCADA ESPIRAL ITERATIVO
Fechas de Liberación
Es monolítico en el sentido de que toda la planeación es orientada en una sola fecha de liberación. Es muy rígido con respecto a la fecha de liberación
No hay lineamientos de fechas de entrega
Facilita la inclusión de cambios al calendario, aunque con las revisiones periódicas 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 aproximación a la realidad
Realiza un prototipo y análisis de riesgo en cada vuelta de la espiral.
Permite un entendimiento incremental del problema a través 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 más fácil 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 realización de pruebas después de cada etapa del proceso Crea una solución efectiva mediante múltiples iteraciones.
Forma de trabajo
Diseñado para realizar una serie de pasos bien definidos. Los planes son basados en la suposición 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 administración del proyecto
Puede ser tardado por tantas pruebas que se llevan a cabo
Puntos Importantes
Es flexible para adaptarse a las necesidades de la organización y permite la especialización.
Introduce la programación y prueba modular así como la integración y prueba del sistema
Nos ayuda a evitar problemas futuros en el sistema con lo cual evita la pérdida de tiempo y dinero
I.P.N. – U.P.I.I.C.S.A.
57
IV.3 El Modelo de Proceso de Software de la Asociación Mexicana de Calidad en Ingeniería
de Software
Una vez que se han abordado los ciclos clásicos de desarrollo de sistemas, es pertinente
mencionar que, en nuestro entorno nacional, se han hecho esfuerzos encaminados a entregar
productos de calidad, productos que estén dentro de un periodo de tiempo y de un presupuesto
acordados antes del comienzo de los ciclos de desarrollo. La información que se presenta a
continuación, se obtuvo del material del seminario impartido en la Ciudad de México por la empresa
Itera SA en combinación con la Asociación Mexicana de Calidad en Ingeniería de Software (AMCIS A.C.)
el 8 de junio de 2006 en el D.F.
En la figura IV.6, se pueden apreciar los esfuerzos independientes, y prácticamente
simultáneos, de la Organización Internacional de Estándares (International Stardard Organization ISO),
el Software Engineering Institute (SEI) de la universidad de Carnegie Mellon y de la Asociación
Mexicana de Calidad en Ingeniería de Software (AMCIS) durante los últimos tres lustros.
Fig. IV.6 Evolución del Modelo Normativo
Es quizá la certificación ISO 9001:2000, la más conocida en general, sin embargo fue el Modelo
de Capacidad y Madurez o CMM, por sus siglas en inglés, el primero en retomar las ideas de los círculos
de calidad de Edward Deming, además cabe mencionar que, este último es un modelo de calidad
I.P.N. – U.P.I.I.C.S.A.
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 afán de certificarse para cumplir con estándares internacionales y así ser más
competitivas en el ámbito mundial, es que comienzan a certificarse bajo los parámetros de ISO
9001:2000, a pesar de que este método está enfocado a las empresas manufactureras, empresas de
sector secundario.
El CMM por su parte, aunque enfocado muy específicamente en las empresas de desarrollo de
software, está completamente dirigido al entorno norteamericano, un entorno muy distinto al entorno
nacional. Dados estos antecedentes la Secretaría de Economía solicita que se desarrrolle una Norma
mexicana verificable, esta norma es un sistema de gestión de la calidad de los procesos de desarrollo y
mantenimiento de software para las PYMES, la cual es desarrollada por la Asociación Mexicana de
Calidad en la Ingeniería de Software (AMCIS) y emitida como norma por el NYCE (Normalización y
Certificación Electrónica A. C.), la cual es una asociación civil sin fines de lucro creada en noviembre
de 1994 por un grupo de empresas líderes de los sectores de Electrónica, Telecomunicaciones y
Tecnologías de Información de México, convencidas de la necesidad de contar con un organismo de
jurisdicción nacional que tomara en cuenta sus necesidades, en la certificación 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)
I.P.N. – U.P.I.I.C.S.A.
59
En 1996, académicos de universidades públicas y privadas y personas dedicadas al desarrollo
de software en México, se reúnen y crean el Círculo de Calidad Mexicano, que sentó las bases para que
un año más tarde se creara la AMCIS, la cual con la colaboración de sus miembros dan vida
conceptualmente al Proceso de desarrollo de Software, el cual se dio a conocer en el año 2002 como
ProSoft, en ese mismo año la Secretaría de Economía 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 guía de implantación de procesos totalmente pensado para el
entorno mexicano.
Un año más tarde se da a conocer la pieza restante, el método de Evaluación (EvalProSoft). El
propósito del método de evaluación de procesos, EvalProSoft para la industria de software es, otorgar a
la organización solicitante un perfil del nivel de capacidad de los procesos implantados en la
organización y un nivel de madurez de capacidades, en la siguiente figura es posible observar los
distintos niveles que se pueden obtener mediante la aplicación 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
I.P.N. – U.P.I.I.C.S.A.
60
El nivel de madurez de capacidades de una organización corresponde al máximo 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 ejecución 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, además de contar con una adecuada
distribución de sus recursos durante el desarrollo del proceso. Las organizaciones que logran un nivel
cuatro son organizaciones maduras, que tienen estadísticas históricas 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 más 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 sólo 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 ISO 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 adaptación 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 administración, esto es, hay procesos para el equipo directivo, para los
mandos medios o equipo de coordinación y, finalmente, procesos relacionados a quienes se encargan
de ejecutar las funciones sustantivas de la organización, esto puede corresponder tanto a una
organización tradicional con una estructura de tipo pirámide, como con una organización híbrida, como
la que se propondrá en el siguiente capítulo.
Los procesos del MoProSoft son relacionados, con los procesos operativos de la organización,
esta relación entre procesos se establece mediante la identificación de los productos de trabajo de
entrada y salida y la definición de las responsabilidades de los roles que participan en más de un
proceso, simplificando con ello la relación entre el modelo de procesos y la organización.
I.P.N. – U.P.I.I.C.S.A.
61
Alineación con objetivos de negocio
El proceso de Gestión de Negocio enfatiza la importancia de alinear todas las actividades de la
organización a los objetivos del negocio a través de la elaboración, difusión, valoración y mejora del
Plan Estratégico.
El Plan Estratégico sirve de guía a los demás procesos de la organización logrando de este
modo una alineación explícita con los objetivos de negocio.
Se enfoca en el producto y su capitalización
Se identifican los productos y las actividades de verificación y validación a las que deben estar
sometidos dichos productos, además el proceso de Conocimiento de la Organización administra una
base de conocimiento que controla y asegura la disponibilidad de los productos de trabajo a través de
un mecanismo común.
Capacidad organizacional de gestión de procesos
El proceso referente a la Gestión de Procesos, establece la capacidad organizacional para la
planeación, definición, implantación, evaluación y valoración de procesos; este proceso está regido por
las directrices de Gestión de Negocio, lo que asegura la alineación con los objetivos.
Capacidad organizacional de gestión de proyectos
Se distingue entre la administración a nivel proyecto (Administración de Proyecto Específico) y
la gestión del porta folio de proyectos de la organización (Gestión de Proyectos).
La Gestión de Proyectos facilita la Identificación de iniciativas y proyectos; la provisión,
asignación y reasignación de recursos a programas y proyectos; y el mantenimiento del balance del
portafolio.
La Gestión 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
I.P.N. – U.P.I.I.C.S.A.
62
En la figura IV.9 se muestran las interacciones entre todos los procesos antes descritos:
Fig. IV.9 Modelo MoProSoft (Proporcionado por la AMCIS)
I.P.N. – U.P.I.I.C.S.A.
63
CAPITULO CINCO ________________________________________________________________________
PROPUESTA DE LA ESTRUCTURA ORGANIZACIONAL PARA UNA EMPRESA DE SERVICIOS DE DESARROLLO DE SISTEMAS
“La célula de una sociedad del conocimiento es un trabajador con conocimientos, es decir, un empleado que aporta valor a la empresa al suministrar o interpretar información”62
Richard Nolan.
La base de conocimiento de las organizaciones está rompiendo inercias y paradigmas. En un
contexto en el que el cambio es intrínseco a las acciones, el quehacer administrativo no puede
sustraerse. Esto ha generado la imperiosa necesidad de focalizar la administración con otra perspectiva,
de replantear su contenido para amalgamar la técnica con el movimiento y emigrar a nuevas formas de
expresión 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 institución mediante el
aprovechamiento al máximo 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 más o menos el mismo nivel jerárquico, que lleven a cabo
proyectos que requieran de la mezcla de distintas especialidades para diseñar, fabricar o comercializar
un nuevo producto, proceso o tarea específica, independientemente de su origen organizacional.
Todo proceso de desarrollo de software intenta implementar un cierto grado de disciplina
(formalización), lograr una eficiente comunicación, y un mejor aprovechamiento de los recursos
(personas, tiempo, dinero). La presente propuesta involucra la forma de organizar a las personas y que
la división del trabajo en las empresas prestadoras de servicios de desarrollo de software, sea hecha
62 Nolan, Richard, “Destrucción creativa”, Mc Graw Hill, México, 1996. Pág. 23 63 Franklin F., Enrique Benjamín, “Organización de empresas”, Mc-Graw Hill 2ª. Edición. México 2004, Pág. 110
I.P.N. – U.P.I.I.C.S.A.
64
sobre la base de contar con trabajadores interdisciplinarios, es decir, que posean conocimiento en
varias áreas, la aplicación de ello será lo que genere la plusvalía, y el valor para la empresa.
En este orden de ideas, este capítulo expone una propuesta de Estructura Organizacional, la
cual se desglosa en los siguientes puntos:
·Propuesta de organización o Descripción de la estructura organizacional mixta o híbrida.
·Descripción de los casos de la expansión y de contracción de la estructura.
·Propuesta de flujos de trabajo en los casos que se desarrolle tanto con el paradigma de
programación estructurada y la orientación a objetos
La propuesta. Consiste en una organización orgánica que desde su diseño se pensó en que
estuviese preparada para la expansión y para la contracción con la menor pérdida de conocimiento.
Cada elemento de la estructura de célula laboral tiene el mismo nivel jerárquico, sin embargo, cuando
haya que tomar una decisión 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 Híbrida), 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 coordinación… localizándolos y
haciéndolos condicionalmente autónomos
primero…después recíprocamente independientes,
después… unos interdependientes en forma
secuencial, y por último… agrupando los puestos
de manera homogénea para facilitar su
estandarización.” 64
Fig. V.1 Célula laboral (Diseño Propio)
“El contexto político del proceso de toma de decisiones tiene una relación 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; aquéllos que realizan tareas rutinarias no tienen esa fuente de poder. Las
personas con habilidades reclaman y reciben más poder discrecional, o una más amplia
64 Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Pág.7 98 y 99
I.P.N. – U.P.I.I.C.S.A.
65
descentralización, como algo que se ganó desde una posición de poder, en lugar de algo que se delegó
desde arriba.”65
V.1.1 Caso:Expansión
En épocas de bonanza cada uno de los tres elementos se convierte en un líder de proyecto que
coordina a dos nuevos elementos de un nuevo equipo, los cuales pueden ser nuevos empleados de
nómina, o bien consultores, personal temporal e incluso personal en entrenamiento. La persona que
funge como líder cumple una importante función: 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 también ayuda a permear el conocimiento.
65 Ibidem. Pág. 111
I.P.N. – U.P.I.I.C.S.A.
66
V.1.2 Caso:Contracción
En las empresas, una de las metas es mantener el tamaño de la organización al mínimo para
reducir los costos. “…el incremento de tamaño se relaciona con el incremento en la estructuración de
las actividades organizacionales y una menor concentración de autoridad”66.
En épocas de recesión este modelo se puede contraer sin perder conocimiento ya que son los
líderes de cada equipo, quienes regresan a conformar el equipo original, además coadyuva a mantener
el tamaño de la organización al mínimo para reducir costos.
Fig V.3 En Épocas de recesión es posible que el personal se reduzca al máximo sin perder conocimiento.
(Diseño propio)
66 Hall, Richard, ob cit. Pág. 95
I.P.N. – U.P.I.I.C.S.A.
67
La Estructura del Equipo de Desarrollo está organizada de tal manera que pueda soportar
múltiples proyectos simultáneamente sobre una misma plataforma tecnológica 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 interacción con los diferentes recursos de la organización
del cliente. Cada uno de esos roles puede ser un equipo conformado por más 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 Híbrida (Después)
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 específicas, ya que
mientras que el modelo tradicional está enfocado a organizaciones que desempeñan actividades
altamente rutinarias, por su parte, el modelo propuesto (híbrido: lineal militar y de células de
conocimiento) está enfocado en propiciar una baja centralización, es decir, propicia la participación de
las personas que forman la base de la organización 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
I.P.N. – U.P.I.I.C.S.A.
68
que las personas que se encuentran en la base de la organización puedan tomar ciertas decisiones ya
que se encontrarán respaldados por sus colegas de equipo, sin embargo en el momento que haya
alguna polémica ésta se dará por concluida invocando la autoridad del jefe inmediato superior, quien
tomará la decisión final.
Una empresa puede controlar a su personal en varias formas, mediante las reglas
(Formalización), centralizando las decisiones (Centralización), 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
formalización, ya que la documentación 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 formalización propia de la empresa.
Sin embargo, el tema de la formalización deberá revisarse en forma constante, porque seguramente
habrá circunstancias que necesiten un estándar a aplicar, en tanto que otras situaciones se deberá
privilegiar la plena libertad, para que la creatividad, aspecto prácticamente imprescindible en este tipo
de empresas, pueda florecer.
Para una correcta implementación, 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 solución y así adquirir experiencia
y conocimiento que más tarde se podrá aplicar en el resto de los proyectos. Por supuesto que toda
situación y problema (con su correspondiente solución –o alternativa por lo menos) deberá ser
documentado en bitácoras 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 situación no deseada. A continuación se
describe la propuesta del flujo de información para los dos paradigmas de desarrollo utilizados.
V.2. Desarrollo de sistemas con orientación funcional o estructurada
Secuencia de procesos de análisis estructurado
La secuencia comienza con la recopilación de información de todo lo referente al módulo que se
va a construir, el siguiente paso es la generación de los diagramas que contienen las entidades lógicas y
sus relaciones, posteriormente se generan los documentos de análisis cuya función es formalizar dicho
análisis para su posterior revisión, todas estas actividades son realizadas por el analista y con la
I.P.N. – U.P.I.I.C.S.A.
69
asesoría directa del usuario. Una vez que se obtiene lo anterior, el analista genera los procesos
involucrados en el módulo, así como las operaciones básicas que componen a dichos procesos, ambos
productos (procesos y operaciones básicas) son validadas por el analista en conjunción con el líder de
proyecto.
En la Fig. V.5 se presenta un diagrama que muestra el flujo que se sigue para la realización del
análisis de acuerdo al paradigma estructurado.
Da Doc. De Análisis alLíder de Proyecto
A
BA
Entrega Diseño paraCorreccións
B
I
Analista
Retroalimenta alAnalista
Da CorreccionesLíder Proyecto Analista
Realiza correccionesY las entrega
Líder Proyecto
Da Visto bueno alanalista si el análisis es Correcto.
Analista
Realiza elDiseño delmódulo
Líder Proyecto
Revisa diseño y daVisto Bueno C
Analista
RedactaEspecificaciones
Realiza Check List, Casos de prueba
C
Líder Proyecto
Revisa Check List yCasos de prueba y da
Visto Bueno
D
Analista
Analista
Archiva expediente
ylibera análisis
D EGenera expediente
de análisis y entregaAl líder Proy.
Fig. V.5 Diagrama de flujo de información del proceso de análisis estructurado (elaboración propia)
Una vez que el líder de proyecto revisa los documentos de análisis, procede a retroalimentar al
analista en cuanto a las correcciones (si es que las hay) que se le tuviesen que hacer al módulo, paso
siguiente, el analista realiza las correcciones hasta que el líder de proyecto da su voto aprobatorio, en
ese momento el analista da comienzo a la realización del diseño, producto para el cual se sigue el
mismo procedimiento que para el análisis, una vez que se cuenta con el análisis y el diseño aprobados
el analista procede a toda la documentación de cada uno de los programas que conforman al módulo,
estos últimos pasan a ser validados por el líder de proyecto, finalmente se elabora el expediente del
análisis para su posterior liberación.
I.P.N. – U.P.I.I.C.S.A.
70
V.3. Desarrollo de sistemas con orientación a objetos
El concepto de programación orientada a objetos se utilizó inicialmente para aquellos sistemas
desarrollados con lenguajes orientados a objetos, sin embargo, su evolución ha logrado conformar toda
una metodología de Ingeniería de Software que comprende, desde el análisis 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,
adaptación y escalabilidad.
Secuencia de procesos de análisis orientado a objetos
La secuencia comienza con la delimitación del alcance a cubrir, esta actividad la realizan el
analista conjuntamente con el líder de proyecto, el siguiente paso es la recopilación de información de
todo lo referente al módulo que se va a construir, posteriormente se generan los documentos de casos
de uso cuya función es formalizar el análisis para su posterior revisión, todas estas actividades son
realizadas por el analista y con la asesoría 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 módulo, ambos
productos (diagramas de secuencia y de clase) son validados conjuntamente por el analista, el líder de
proyecto y el comité de revisión.
Una vez que el líder 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 módulo, paso siguiente, el analista realiza las correcciones hasta que el líder de proyecto da su voto
aprobatorio, en ese momento el analista da comienzo a la realización del diseño correspondiente al caso
de uso aprobado, producto para el cual se sigue el mismo procedimiento que para el análisis, una vez
que se cuenta con el análisis y el diseño 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 módulo, estos últimos pasan a la correspondiente validación por parte del líder de
proyecto, finalmente se elabora el expediente del análisis para su posterior liberación. Este
procedimiento deberá de seguirse para todos y cada uno de los casos de uso que se generen.
I.P.N. – U.P.I.I.C.S.A.
71
En la Fig. V.6 se presenta un diagrama que muestra el flujo seguido para la realización del
análisis de acuerdo al paradigma orientado a objetos.
Generaciónde
Documentaciónal 100%
Reuniónde
Comité
Presentacióny
Revisión
Selección declases comunes
APROBACIÓNy
FORMALIZACIÓN
Transformación declases a modelode entidades relacionales
Entrega al Líderde Proyecto y
solicitud de fechapara utilización
Incorporación a BD por parte del Líder de P.
Entrega aInfraestructurapara construir
clases comunes
Públicaclases comunes
liberadas aAnalistas
INICIARDISEÑO
SINO
*
* Entregar a logística
la documentación de los subproductos generados completa y en limpio.
Entregaa integrantes
del comité
Fig. V.6 Flujo del análisis orientado a objetos (Elaboración propia)
I.P.N. – U.P.I.I.C.S.A.
72
POLITICAS Y PROCEDIMIENTOS DE LA FASE DE ANÁLISIS
El líder de proyecto deberá entregar el documento de alcance funcional al analista, el cual por
su parte debe entregar a cada integrante del comité de revisión una copia de su análisis, previo a su
revisión (Es deseable que el tiempo de anticipación para esta entrega no sea mayor a un día hábil). El
análisis deberá estar concluido al 100% antes de su revisión.
El analista deberá hacerse responsable de calendarizar la presentación y revisión de su análisis
con el comité de validación, cuidando no rebasar el tiempo estimado para la actividad.
El comité de validación aprobará la liberación del análisis una vez que éste ha sido revisado a detalle.
Dicha aprobación será formalizada en un documento conocido como “Formalización del Análisis”,
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 logística el original junto con el
documento de aprobación.
Los casos de uso al ser aprobados serán “congelados” por el área de logística y cualquier
cambio al mismo será controlado por el área de control de cambios.
I.P.N. – U.P.I.I.C.S.A.
73
Secuencia de procesos de diseño orientado a objetos
El analista se encarga de la generación de diagramas de estado, el diseño de interfaces, la
validación de entidades, así como de la generación de especificaciones, la validación del diseño lo
realiza el analista conjuntamente con el comité de validación.
Los Subproductos generados durante el diseño orientado a objetos son las Especificaciones, el
diagrama de entidad relación, el diagrama de estados y las interfaces
Paqueteanálisis
APROBADO
Generacióndiagramas
deestado
Generaciónde
especificaciones
Generacióninterfases(pantallas)
APROBACIÓNy
FORMALIZACIÓN
Reuniónde
Comité
Presentacióny
Revisión
Asignacióna
PROGRAMACIÓN
*
* Entregar a logística
la documentación de los subproductos generados completa y en limpio.
SI
Validaciónde
entidades
Fig. V.7 Flujo del diseño orientado a objetos (Elaboración propia)
I.P.N. – U.P.I.I.C.S.A.
74
Políticas y Procedimientos de infraestructura
El líder de infraestructura recibe la solicitud del analista previamente avalada por el comité,
analiza y determina la complejidad de la solicitud reflejando su duración en el formato de programación.
Posteriormente, realiza la asignación de tareas a los recursos de su área. Los subproductos generados
serán, el plan de trabajo, las funciones, Clases, Casos, etc. que se generen y el Documento de
Publicación.
Es responsabilidad del líder de infraestructura validar su plan de trabajo con el líder 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
logística el original junto con el documento de aprobación. La infraestructura desarrollada deberá ser
“congelada” y publicada por el área de logística y cualquier cambio será controlado por el área de
control de cambios.
Secuencia de procesos de infraestructura
El líder de infraestructura y el analista solicitante, validan la solicitud y realizan el análisis del
requerimiento. El líder de infraestructura asigna a un programador para que se realice la construcción
de la infraestructura solicitada, y son ellos mismos quienes realizan pruebas unitarias. Por su parte, el
comité realiza la validación correspondiente y procede a su publicación y liberación
ConstrucciónPaqueteanálisis
APROBADO
Analisisdel
Requerimiento
Asignación de
Tareas
Generaciónde
CasoPráctico
PUBLICACIÓN
*
* Entregar a logística
la documentación de los subproductos generados completa y en limpio.
Pruebade
Liberación
APROBACIÓNy
FORMALIZACIÓN
Presentacióny Revisióncon Comité
SI
NO
Fig. V.8 Flujo de infraestructura (Elaboración propia)
I.P.N. – U.P.I.I.C.S.A.
75
V.4 Intenciones competitivas en la compensación.
Mediante el diseño y la administración de la compensación, es factible atraer, retener y obtener
recursos humanos con cierto grado de calidad, acorde con la política planteada e idóneo para la
operación de la empresa. En otras palabras la factibilidad económica incide fuertemente en la
factibilidad operativa, sin embargo esta última dependerá de la correcta selección y reclutamiento del
capital humano, el cual es sumamente importante en las empresas de desarrollo de software, por lo
cual, a continuación 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 recién 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 inflación crece y el poder adquisitivo
paralelamente disminuye, hasta que en el siguiente punto de revisión 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 inflación, 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 inflación (un superávit). 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, prácticamente por lo general estará por
encima de la intención competitiva del mercado.6 7
El nivel de compensación depende, en buena medida de las características del sector económico
en que compite y de la disponibilidad del tipo de personal para estar en condiciones de competir
eficazmente con ventajas en dicho sector.
67 Juárez Hernández, Othón, “Administración de la compensación Sueldos, incentivos y prestaciones”; Oxford University Press; Primer edición; México 2000; Pág.84
I.P.N. – U.P.I.I.C.S.A.
76
Fig. V.9 Intenciones competitivas de compensación
I.P.N. – U.P.I.I.C.S.A.
77
CONCLUSIONES ________________________________________________________________________
Al comienzo de la elaboración de este trabajo surgió una pregunta ¿cómo refutar la frase “es un
mal con el que tenemos que vivir”?, y al término 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
interacción 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 dinámica’. 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 imposición de la autoridad, sin e mbargo tenemos que pensar en términos 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 investigación y a la vez
a la creación de obras artísticas (pinturas, esculturas u obras literarias), sin embargo, cuando el
desarrollador interactúa con sus clientes hace estimaciones de tiempos de entrega y se compromete a
terminar "obras" en tiempos y con recursos específicos y limitados, además, hoy en día la competencia
a escala mundial plantea desafíos a los que no se puede hacer frente sólo con la técnica 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 decía que “Las personas constituyen el activo más valioso de toda empresa”,
sin embargo, es cierto sólo en parte, concluimos que se requiere acotar esta aseveración: “Las personas
que generan valor constituyen el activo más 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 solución no genérica, pues como sabemos no podemos hacer
generalizaciones, y menos aún tratándose de personas, sin embargo pensando a futuro se plantea la
viabilidad de crear una organización de aprendizaje, la cual tenga una estructura flexible que se pueda
I.P.N. – U.P.I.I.C.S.A.
78
adecuar tanto a la expansión como a la contracción de la organización, permeando y evitando la
pérdida de conocimiento respectivamente.
Las empresas desarrolladoras de software encontrarán útil la presente propuesta ya que es
factible de ser implantada, sin tener gastos adicionales, sino simplemente implementado las células de
conocimiento en la base de la organización, logrando con ello mayor apertura y motivación 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 solución propuesta se basa en aspectos fundamentales de toda organización: orden,
disciplina, comunicación eficaz y eficiente, capacitación y el establecimiento de una relación 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 más bien se convierta en un empleado interdisciplinario y con un perfil versátil, 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 comunicación eficaz y eficiente. Además el
presente trabajo sostiene que es posible adquirir un enfoque dirigido hacia la gente y ver a las personas
como una ventaja competitiva, aún en tiempos de recesión.
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 relación ganar-ganar entre la empresa y los
empleados, ya que en el esquema de célula laboral cada integrante cuenta con un doble backup o
doble respaldo. Se basa en una comunicación que constituye la base para compartir el conocimiento, y
con ello, las personas no crean dependencias, con lo cual se genera un círculo virtuoso, porque se
reducen costos operativos ya que se aprovechan los tiempos de remanso o tiempos muertos, las
entregas de puestos son más fáciles y rápidas, además las personas pueden hacer uso de sus periodos
vacacionales, todo ello hace más consecuentes muchas labores cotidianas y contribuye a que el
trabajador logre una buena calidad de vida, motivándolo a recrear y reforzar constantemente este
modelo.
I.P.N. – U.P.I.I.C.S.A.
79
BIBLIOGRAFÍA ________________________________________________________________________ Bachmann, Felix L., L. Bass, J.Carriere, P. Clements, D. Garlan, J. Ivers, 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, James, Jacobson, Ivar, “Rational Unified Proccess Fundamentals”, Ed. Itera; Edición (Versión) 5.5, año de publicación 2001. Módulo 1 Chase, Aquilano, “Administración de operaciones”, McGrawHill. 10a edición. México. 2004 Chase, Jacobs, Aquilano, “Administración de la producción y operaciones”, McGrawHill, 10ª. Edición,
México 2005
ISBN 970-10-4468-1 Chiavenato, Idalberto “Introducción a la teoría general de la administración”, Mc Graw Hill, México Cromwell, Jeff, “The Art and Science of Software Architecture”. Dr. Dobb´s Journal Software Tools for the Proffessional Programmer, Vol.25, Issue 6, Jun. 2000. Franklin F, Enrique Benjamín, “Organización de Empresas”, Ed. McGraw-Hill, Interamericana; Segunda Edición México 2004 ISBN: 970-103-944-0
Hall, Richard, “Organizaciones: estructura y proceso” México, Prentice Hall. Hernández Santuario, Eloisa Itzé, “Modelo de comportamiento organizacional para elevar el
desempeño de los grupos de trabajo interfuncionales dentro de la empresa” Tesis, México, 2002, MCSC
ITESM H531.M2002
Jacobson, Ivar, Booch, Grady, Rumbaugh, Ja mes, “El Proceso Unificado de Desarrollo de Software”, Addison Wesley,.México, 2000 Juárez Hernández, Othón, “Administración de la compensación Sueldos, incentivos y prestaciones”, Oxford University Press, Primer edición; México, 2000 Kast, Fremont E, Rosenzweig, James E, “Administración en las Organizaciones”. Mc Graw Hill, México 1985 Microsoft , “Student Workbook – Solutions Development Discipline”, EUA,1997 Münch Galindo, Lourdes, “Fundamentos de administración”, 5ª Ed. Trillas, México 1990, ISBN 968-24-3941-8 Nolan, Richard, “Destrucción creativa”, Mc Graw Hill, México, 1996
I.P.N. – U.P.I.I.C.S.A.
80
Pascale, Richard T., Athos, Anthony G, “El secreto de la Técnica Empresarial Japonesa”, Grijalbo, México, 1984 ISBN 968-419-422-6 Praxis, “Manual Administración de Proyectos de Software”, Praxis versión 1.0 Año 1999 Pressman, Roger S., ”Ingeniería del Software”. Un enfoque práctico. 4ª. Edición México 1998. Mc Graw Hill Quality And Productivity Staff, “PDSS Proceso de desarrollo de software de Softtek”, Guía de Referencia 1, México 1999 Rational University, “Requirements Management with Use Cases”, Student Manual Version 2002.05.00 USA 2001 Reyes Ponce, Agustín, “Administración de empresas: Teoría y práctica”, Ed. Limusa 1999 Robbins, Stephen, “Comportamiento Organizacional”, 8ª. Ed., Prentice Hall, México, 1999 ISBN 970-17-0236-0 Senn, James A., “Análisis y diseño de Sistemas”, Ed. McGraw-Hill ISBN:968-422-991-7 Sommerville, Ian, “Ingeniería del Software”, Addison Wesley Iberoamericana, S.A., Segunda edición, México, 1988 ISBN: 0-201-64055-4 Sommerville, Ian, “Ingeniería de Software”, Pearson Educación, 6ª. Edición, México 2002, ISBN: 970-26-0206-8 Taha, Hamdy A., “Investigación de Operaciones, una introducción”, Prentice Hall, México, 1998 ISBN: 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
I.P.N. – U.P.I.I.C.S.A.
81
ANEXO ‘A’
________________________________________________________________________________
Investigación acerca de la demanda de software en la Ciudad de México en el 2006
El estudio que a continuación 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 México,
para ello se realizaron encuestas entre seis de las empresas desarrolladoras mas grandes de software
con oficinas en la Ciudad de México, esto de acuerdo con el Comité Nacional de Productividad e
Innovación Tecnológica A.C., y la Asociación Mexicana de Calidad en Ingeniería de Software quienes
destacan a Hildebrando, IDS, Praxis y Softtek entre los 11 de los 26 desarrolladores más grandes de
México :
Ø Grupo UNIKA
Ø Hildebrando
Ø IDS Comercial
Ø Integrated Technology
Ø Praxis
Ø Softtek
I.P.N. – U.P.I.I.C.S.A.
82
Grupo Unika ha tenido la oportunidad de participar en diversos proyectos para desarrollar aplicaciones
sobre Internet. Después de casi 5 años en el mercado, Grupo Unika se ha convertido en una excelente
solución para responder a desarrollos de alta tecnología sobre Internet.
Lo más interesante de nuestra capacidad es que sabemos convertir el gasto de TI de nuestros clientes
en una inversión con un retorno tangible.
Misión : Ser líder como proveedor de soluciones integrales con tecnología de punta, compromiso y
capacidad de respuesta.
Fuente:
www.grupounika.com.mx/
MATRIZ SECTOR SUBSECTOR EMPRESA/GIRO
SECUNDARIO MANUFACTURA MAQUILADORA
PEMEX IMP
TERCIARIO FINANCIEROS SERVICIOS
MAPFRE TEPEYAC GRUPO SCANDA AMERICAN EXPRESS AMIB GRUPO EDITORIAL SANTILLANA COMPAQ COMPUTER DE MÉXICO GRUPO NACIONAL PROVINCIAL SECODAM INFOTEC TRIFE COMISIÓN NACIONAL DE SEGUROS Y FIANZAS INVEX GRUPO FINANCIERO
I.P.N. – U.P.I.I.C.S.A.
83
GRAFICA
Sect
or
Pri
mari
o
Sect
or
Terc
iari
o
*02468
1012
I.P.N. – U.P.I.I.C.S.A.
84
Fundada en el año de 1986, Hildebrando es una empresa mexicana de consultoría tecnológica con
presencia internacional, especialista en desarrollo e integración de sistemas y soluciones de negocio
aplicando tecnología de vanguardia.
Hemos sido reconocidos por la revista "Expansión" como una de las 600 empresas más importantes de
México. Más de 1000 consultores prestan servicios a bancos, instituciones financieras, empresas de
comunicaciones, e industrias de servicios, en múltiples plataformas.
Filosofía. Pasión por la satisfacción y el éxito del cliente, confianza y respeto, trabajo en equipo, rapidez
y agilidad, innovación y trabajo bien hecho, son los valores de nuestra empresa que han sido la clave
para que a lo largo de más de 15 años, Hildebrando sea una Empresa de éxito.
Nuestro objetivo con los Clientes: Ser un Socio tecnológico, no sólo un proveedor.
Nuestra misión en México: Ser el Líder en el mercado de consultoría y desarrollo de sistemas.
Fuente:
http://www.hildebrando.com.mx
MATRIZ SECTOR SUBSECTOR EMPRESA/GIRO
PRIMARIO AGRICULTORA PESCA GANADERIA
AGRICULTURA CAZA PESCA
SECUNDARIO MANUFACTURA MAQUILADORA
COMISION NACIONAL DEL AGUA
TERCIARIO FINANCIEROS SERVICIOS
EDUACION COMERCIO FINANZAS GOBIERNO SERVICIOS DE TELECOMUNICACIONES
I.P.N. – U.P.I.I.C.S.A.
85
GRAFICA
0
2
4
6
1 2 3
Sector
Hildebrando
I.P.N. – U.P.I.I.C.S.A.
86
Misión
Ser una empresa en tecnologías de información rentable y en constante crecimiento. Que busca ser
reconocida y respetada en el medio por su calidad, eficiencia, espíritu 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 superación, el reconocimiento y donde se ofrezcan excelentes oportunidades de desarrollo
personal, técnico, profesional y económico.
Visión
Ser socios, proveedores y aliados tecnológicos de nuestros clientes ofreciendo servicios de soluciones
integrales en tecnologías de información a través de intervenciones proactivas y con un rol estratégico.
Fuente:
http://www.ids.com.mx/
I.P.N. – U.P.I.I.C.S.A.
87
MATRIZ SECTOR SUBSECTOR EMPRESA/GIRO
SECUNDARIO MANUFACTURA MAQUILADORA
TERCIARIO FINANCIEROS SERVICIOS
GRAFICA
0
5
10
15
20
25
30
#Empresas
Primario Secundario Terciario
Sector
Alianzas Estratégicas de IDS
I.P.N. – U.P.I.I.C.S.A.
88
IT ofrece soluciones eficaces dentro del ámbito de servicios de consultoría especializada. Proporciona los servicios necesarios para consolidar una arquitectura abierta, sólida y práctica, que fortalezca y de flexibilidad a sus áreas de sistemas de información para soportar adecuadamente los procesos de negocios y toma de decisiones de la organización. La experiencia adquirida en la Administración y liderazgo de proyectos de gran magnitud en importantes empresas en México, Centro y Sudamérica nos permiten llevar a cabo una de las tareas más complejas, "La administración de proyectos" en diferentes sectores como son: Retail, Telco, Sector Financiero, Administración de Riesgos, Distribución y Manufactura. Integrated Technology arranca el año 1994 orientado a Arquitectura de Sistemas. Posteriormente toma especialidades en Middleware, desarrollo en plataforma Microsoft. Desde 1998 inicia el área de Business In telligence, con especialidades tanto en ETL, como en OLAP y diseño de cubos. En 1999 nuestra área de desarrollo se orientó hacia el lenguaje Java, recibiendo el año 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 Minería de Datos. . En los últimos dos años se han incorporado las especialidades de Ingeniería de Software, proponiendo en nuestra metodología la automatización de pruebas, así como Seguridad, que es un tema fundamental en la actualidad. Misión: Brindar a nuestros clientes servicios de asesoría integral en sistemas, ayudándoles a consolidar una arquitectura sólida y abierta, que fortalezca y dé flexibilidad a sus áreas de Sistemas de Información 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 países de latinoamérica, así como un equipo de excelentes profesionales en diversas especialidades informáticas. Visión: El desarrollo, implementación y distribución de software es una de las industrias con mayores oportunidades de crecimiento en nuestro país. Sin embargo, el reto en esta oportunidad consiste en manejar el constante cambio tecnológico. Integrated Technology cuenta con varias especialidades (DataManagement, BusinessIntelligence, eCommerce, Ingeniería de Software y Seguridad), pero cuenta con una característica más importante: la habilidad de incorporar nuevas especialidades conforme avanza el desarrollo tecnológico. Otras características distintivas de la visión 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 formación continua de consultores del más alto nivel. Fuente: www.itweb.com.mx
I.P.N. – U.P.I.I.C.S.A.
89
MATRIZ SECTOR SUBSECTOR EMPRESA/GIRO
SECUNDARIO MANUFACTURA MAQUILADORA
TERCIARIO FINANCIEROS SERVICIOS
GRAFICA
0246
81012141618
SECUNDARIO TERCIARIOS
I.P.N. – U.P.I.I.C.S.A.
90
Praxis es una empresa de consultoría, desarrollo e integración de sistemas de información con una
misión clara: fortalecer el desarrollo de las empresas a través del uso adecuado de las tecnologías de
información.
Su principal interés es ofrecer a sus clientes un valor agregado para garantizar que su inversión en
tecnología de información los haga más competitivos.
Fuente:
http://www.praxis.com.mx/
MATRIZ
SECTOR SUBSECTOR EMPRESA/GIRO PRIMARIO AGRICULTURA
PESCA GANADERÍA
SECUNDARIO MANUFACTURA MAQUILADORA
Fuller,
TERCIARIO FINANCIEROS SERVICIOS
Ericsson, seguros serfin,
I.P.N. – U.P.I.I.C.S.A.
91
GRAFICA
0
2
4
6
8
10
12
14
16
SECTORSECUNDARIO
SECTORTERCEARIO
I.P.N. – U.P.I.I.C.S.A.
92
Softtek® es una empresa multinacional. Nace en México en 1982 como proveedora de servicios de
software enfocados a solucionar necesidades de desarrollo, implantación y soporte en empresas de
diversas magnitudes. Hoy somos en México una de las organizaciones líderes e integradoras en
tecnologías de información. Es una empresa con presencia en diez países, y es la empresa privada de
Tecnología de la información más grnade con presencia regional en Latinoamérica 68
Misión
Incrementar la competitividad de nuestros clientes a través del uso apropiado de tecnologías de
información, cómputo y telecomunicaciones.
Visión
Somos una empresa sólida y global . Apuntamos a trascender como líderes , 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 Revista“Software Guru”, Aó 1 No. 2 México Marzo-Abril 2005, Pág 18
I.P.N. – U.P.I.I.C.S.A.
93
MATRIZ
GRAFICA
SECTOR SUBSECTOR EMPRESA/GIRO
PRIMARIO AGRICULTORA PESCA GANADERIA
ASERCA (PROCAMPO): ASESOR ESTRATÉGICO, CICLO DE VIDA DE LOS PRODUCTOS
SECUNDARIO MANUFACTURA MAQUILADORA
BIMBO PEMEX GAMESA
TERCIARIO FINANCIEROS SERVICIOS
GOBIERNO DEL EDO DE GUANAJUATO BANAMEX BANCOMER IMSS ADUANAS HP
Sect
or
Pri
mari
o
Sect
or
Terc
iari
o
01234
5
6
I.P.N. – U.P.I.I.C.S.A.
94
MATRIZ GENERAL SECTOR SUBSECTOR EMPRESA/GIRO
PRIMARIO AGRICULTORA PESCA GANADERIA
AGRICULTURA, CAZA y PESCA ASERCA (PROCAMPO): ASESOR ESTRATÉGICO, CICLO DE VIDA DE LOS PRODUCTOS COMISION NACIONAL DEL AGUA
SECUNDARIO MANUFACTURA MAQUILADORA
PEMEX, GAMESA, IMP, FULLER
I.P.N. – U.P.I.I.C.S.A.
95
TERCIARIO FINANCIEROS SERVICIOS
EDUACION COMERCIO FINANZAS GOBIERNO SERVICIOS DE TELECOMUNICACIONES GOBIERNO DEL EDO DE GUANAJUATO IMSS ADUANAS HP MAPFRE TEPEYAC GRUPO SCANDA GRUPO EDITORIAL SANTILLANA COMPAQ COMPUTER DE MÉXICO GRUPO NACIONAL PROVINCIAL SECODAM INFOTEC TRIFE COMISIÓN NACIONAL DE SEGUROS Y FIANZAS INVEX GRUPO FINANCIERO
I.P.N. – U.P.I.I.C.S.A.
96
GRAFICA GENERAL
0
10
20
30
40
50
60
70
SECTORPRIMARIO
SECTORTERCEARIO
GRAFICA DEL SECTOR TERCIARIO
10%
49%4%
9%
17%
4%7%
TELECOMUNICACIONES
FINANCIERO
EDUCATIVO
GOBIERNO
COMERCIO
SALUD
SEGUROS
I.P.N. – U.P.I.I.C.S.A.
97
ANEXO ‘B’
________________________________________________________________________________
El modelo de asignación de tareas de Investigación de Operaciones 6 9
“La mejor persona para el trabajo” es una descripción apropiada de lo que trata de lograr el
modelo de asignación. La situación se ejemplifica con la asignación de trabajadores a ciertas tareas,
donde cualquier empleado puede desempeñar 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 hábil. El objetivo del modelo es determinar la asignación ó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 desempeñar 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 idóneo para cada una de las
tareas.
Procedimiento
Paso 1 Para la matriz del costo original, identificamos el mínimo de cada renglón y lo restamos de todas
las entradas en el renglón.
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 mínimo de cada columna y
lo restamos de todas las entradas de la columna.
Paso 3. Identificamos la asignación óptima como la asociada con los cero elementos de la
matriz obtenida en el paso dos.
69 69 Taha ,Hamdy A., “Investigación de operaciones, Una introducción”, Prentice Hall, México, 1998, Pág. 194
I.P.N. – U.P.I.I.C.S.A.
98
Digamos que pi y qj son los costos mínimos del renglón i y la columna j, como se definen en los
pasos 1 y 2, respectivamente. Los mínimos del renglón del paso 1 se calculan de la matriz del costo
original, como se muestra en la siguiente tabla:
Analizar Administrar Gestionar Renglón
mínimo
Empleado 1 15 10 9 P1 = 9
Empleado 2 9 15 10 P1 = 9
Empleado 3 10 12 8 P1 = 8
Enseguida, restamos el renglón mínimo de cada renglón respectivo, para obtener la matriz
reducida que se muestra en la siguiente tabla:
Analizar Administrar Gestionar
Empleado 1 6 1 0
Empleado 2 0 6 1
Empleado 3 2 4 0
Columna mínima q1 =0 q2 =1 q3 =0
La aplicación del paso 2 nos da los mínimos de la columna en la tabla anterior. Al restar estos
valores en las columnas respectivas, obtenemos la matriz reducida en la siguiente tabla:
Analizar Administrar Gestionar
Empleado 1 6 0 0
Empleado 2 0 6 1
Empleado 3 2 4 0
Los cuadros con las entradas cero subrayadas proporcionan la solución ó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
I.P.N. – U.P.I.I.C.S.A.
99
Los pasos dados del método húngaro funcionan bien para el ejemplo anterior porque sucede
que las entradas cero en la matriz final producen una asignación 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 solución factible. En este caso, se necesitan algunos pasos
adicionales para encontrar la asignación óptima (factible).