20061106 ANTE TESIS - tesis.ipn.mx · esta tesis. Me refiero a José Alberto González García y a Jorge Daniel Bautista Cárdenas a quienes ... Modelo del ciclo de desarrollo en

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


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.


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


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


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


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.


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.


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.


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.


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


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


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


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


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


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


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


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


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


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


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


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.


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)


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.


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


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


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


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


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.


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


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


25

Fig. II.3 Estructura Matricial


26


• 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


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


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


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.


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


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


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.


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.


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)


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


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.”


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


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


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.


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


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


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


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.


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?


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


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)


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


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.


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


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)


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


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


52

Fig. IV.3 Ciclo de Desarrollo de Espiral

Fuente: Microsoft “Student Workbook – Solutions Development Discipline”. Microsoft 1997. Pág. 65


53

Todo lo anterior produce una sinergia entre el equipo de desarrollo y el cliente, ya que los

clientes son involucrados en todas las etapas, produciendo una 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.


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


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.


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


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


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)


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


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.


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


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)


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


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


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


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


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


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


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.


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.


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)


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.


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

*



SI

Validaciónde

entidades

Fig. V.7 Flujo del diseño orientado a objetos (Elaboración propia)


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

*



Pruebade

Liberación

APROBACIÓNy

FORMALIZACIÓN

Presentacióny Revisióncon Comité

SI

NO

Fig. V.8 Flujo de infraestructura (Elaboración propia)


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


76

Fig. V.9 Intenciones competitivas de compensación


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


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.


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


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


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


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


83

GRAFICA

Sect

or

Pri

mari

o

Sect

or

Terc

iari

o

*02468

1012


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


PRIMARIO AGRICULTORA PESCA GANADERIA

AGRICULTURA CAZA PESCA


COMISION NACIONAL DEL AGUA


EDUACION COMERCIO FINANZAS GOBIERNO SERVICIOS DE TELECOMUNICACIONES


85

GRAFICA

0

2

4

6

1 2 3

Sector

Hildebrando


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/


87




GRAFICA

0

5

10

15

20

25

30

#Empresas

Primario Secundario Terciario

Sector

Alianzas Estratégicas de IDS


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


89




GRAFICA

0246

81012141618

SECUNDARIO TERCIARIOS


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


Fuller,


Ericsson, seguros serfin,


91

GRAFICA

0

2

4

6

8

10

12

14

16

SECTORSECUNDARIO

SECTORTERCEARIO


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


93

MATRIZ

GRAFICA

SECTOR SUBSECTOR EMPRESA/GIRO


ASERCA (PROCAMPO): ASESOR ESTRATÉGICO, CICLO DE VIDA DE LOS PRODUCTOS


BIMBO PEMEX GAMESA


GOBIERNO DEL EDO DE GUANAJUATO BANAMEX BANCOMER IMSS ADUANAS HP

Sect

or

Pri

mari

o

Sect

or

Terc

iari

o

01234

5

6


94

MATRIZ GENERAL SECTOR SUBSECTOR EMPRESA/GIRO


AGRICULTURA, CAZA y PESCA ASERCA (PROCAMPO): ASESOR ESTRATÉGICO, CICLO DE VIDA DE LOS PRODUCTOS COMISION NACIONAL DEL AGUA


PEMEX, GAMESA, IMP, FULLER


95


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


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


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


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:


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:


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


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).

Documents

20061106 ANTE TESIS - tesis.ipn.mx · esta tesis. Me refiero a José Alberto González García y a Jorge Daniel Bautista Cárdenas a quienes ... Modelo del ciclo de desarrollo en