Modelo Para la Realización de Proyectos de Desarrollo de Software Bajo Un Esquema de Trabajo Con Grupos Autodirigidos-1era edición

Modelo Para la Realización de Proyectos de Desarrollo de

Software Bajo Un Esquema de Trabajo Con Grupos

Autodirigidos-1era edición

Title Modelo Para la Realización de Proyectos de Desarrollo de Software Bajo Un Esquema de Trabajo Con Grupos Autodirigidos-1era edición

Authors Ramón David Sarmiento Cervantes

Affiliation itesm

Issue Date 2003-06-01

Abstract Tesis de posgrado presentada para obtener el grado de Maestro en Administración de Tecnologías de Información

Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 00:04:18

5. Investigación de campo

5.1. Introducción

Hoy en día no sólo los gerentes de sistemas o administradores de desarrollo de sistemas de software, sino los altos directivos de las empresas, reconocen los beneficios de un sistema computacional, tanto para agilizar los procesos de fábrica, como para disminuir los costos de un departamento contable o para eficientar la toma de decisiones de cualquier organización.

En muchas ocasiones los sistemas han venido a revolucionar la manera de organizar las empresas, los sistemas de información son cada vez más importantes no sólo en el nivel operativo sino táctico y estratégico; en un mundo en el que los cambios son constantes y el medio ambiente tan volátil, la información se ha convertido en un recurso indispensable que bien administrado puede hacer la diferencia entre la competitividad y la ruina.

Sin embargo, a pesar de la importancia que han tomado los sistemas en estos días, aún se siguen empleando técnicas de desarrollo que datan de los 70's, de los cuales no se lleva seguimiento para detectar su aplicación.

5.2. Definición del problema

Por lo anterior, es muy importante contar con los elementos necesarios para poder desarrollar los sistemas que cada empresa requiere, pero esto no es todo, también es necesario administrar el proceso de ésos desarrollos, porque así como los sistemas pueden contribuir grandemente a la eficiencia y competitividad de una empresa, un desarrollo erróneo o un proyecto cancelado puede, además, dejar una mala impresión a los desarrolladores y a los clientes/usuarios, repercutir gravemente en los procesos de la empresa, e incluso ocasionarle pérdida.

Aunque en teoría existen diversas técnicas o metodologías para la administración del desarrollo de sistemas, en la práctica existen pocos datos de los resultados obtenidos en su aplicación, específicamente de que si éstas contribuyen al éxito de un proyecto.

5.3. Metodología de la investigación

El estudio es dirigido a empresas de la localidad que se dedican a desarrollar sistemas computacionales. La metodología a utilizar para la investigación de campo se realiza a través de entrevistas en las que se aplica un cuestionario que nos permite alcanzar el objetivo y comprobar la hipótesis de la presente tesis.

Como primer paso se buscó una fuente de información donde estuvieran registrados dichos tipos de empresas, al no encontrar ningún organismo oficial en donde estuvieran registradas, se recurrió al directorio telefónico como fuente de información de las empresas que anuncian dichos servicios. De esta fuente se obtuvo una lista de posibles empresas a entrevistar, que representan la población sobre la que se efectuará la investigación.

Una vez que se conoce la población, se solicita la participación de las empresas para la aplicación del instrumento de investigación (el cual se describe más adelante). En este paso, se eliminarán algunas empresas. Finalmente, se obtiene una lista de empresas que constituirán la muestra de estudio, esto se fundamenta con métodos estadísticos en un apartado posterior.

5.4. Lista de posibles empresas a encuestar

1. AASA 2. ABASIS 3. ADAPTA 4. ANTAR 5. Aspel 6. ASSA 7. CDM 8. CEDSA 9. Cemtec

10. CU

11. CITI

15. Data General 16.Expertec 17.lnfosel

18. KIT Consultores 19. Limón Informática 20.Microsys

21.MIGESA 22.MPH

23. Navarro y Asoc. 24.Najera y Asoc. 25.Píxel 26.Progress Software 27.Qualtec 28. Quantum 29.SCAN 30.SECSA 31.SELYCO 32.Servidata 33.Share­tronics 34.Sist. Delnf. MEGA

35.Softek

36.TCA

37.Tec. Y comercialización y serv. 38. UNISYS

39. UNO Systems

40.VIAAS Comunicación 41. Vital 42.Woldspan 43.ZYS Sistemas 44. Kernel 45.Tarik

5.5. Determinación estadística de la muestra

La fórmula utilizada para calcular el mínimo número de empresas que necesitan contestar la encuesta (de un universo finito) para que la presente investigación tenga validez se extrajo del libro de Howell (1982), utilizando una técnica de aproximación basada en el poder real de una investigación. Poder es igual a 1­p (probabilidad de no encontrar las diferencias presentes).

Delta (8) es la relación entre el tamaño del efecto y la muestra, calculada con la relación del poder y alfa (probabilidad de encontrar diferencias que no están presentes). Se utiliza una tabla de poder que se describe en el libro de Howell (1982), donde para un alfa (a) de 0.5, comúnmente usado para protegerse de resultados inesperados y un poder de 0.70, delta(5) es igual a 2.25. Estas cifras son tomadas como referencias de nivel medio en los estudios estadísticos.

Para la variable gama (y), existe una tabla calculada por Cohén (1969), donde definió tres niveles de valores. Los efectos esperados dentro de los resultados en esta investigación se esperan que sean medianos, dando como valor para la variable 0.50.

Finalmente, despejando N, que es el número de empresas necesarias en la muestra, se tiene que es igual a la siguiente fórmula:

N = (8/y)2 = (2.25/0.50)2 = (5.0)2 = 20.25

Redondeando el valor de N, resultó que el mínimo número de encuestas necesarias para aprobar estadísticamente la investigación es 20.

Debido al desconocimiento del universo de empresas locales grandes y medianas, dedicadas al desarrollo de sistemas computacionales; se considera como punto de partida, primero el número de empresas listadas en el directorio telefónico que describieran este tipo de servicios, obteniendo una lista de 45 empresas que componen el Universo y con base en éste, se determinará el tamaño de la muestra.

Para identificar el tamaño del universo se tomó en consideración el 95% de nivel de confianza y un 15% de error permitido, el error permitido es alto debido a la incertidumbre del universo obtenido, así mismo, se asignó una probabilidad de éxito del 70% y por consecuencia una probabilidad de fracaso del 30%. Esto debido también a la consideración de la incertidumbre en el universo y a las restricciones de tiempo para la realización de una investigación más exhaustiva sobre fuentes de información de las empresas dedicadas al desarrollo de sistemas en Monterrey y su área metropolitana.

Se parte de los conceptos teóricos expuestos por George Sndecor en su libro "Statistical Methods", (Sndecor, 1980). A continuación se describe la fórmula utilizada: d) Donde: N n n' Z2 P (1­P)

n = Z2_aP(1­P)

L2

Universo

Tamaño de la muestra Tamaño de la muestra (con ajuste)'

Nivel de confianza Probabilidad de éxito Probabilidad de fracaso

Debido a que la muestra seleccionada se considera mayor al 10% del total del universo, se utilizó la siguiente fórmula de ajuste:

(2)

n' = n 1 +n/N

Despejando N (universo), se obtuvo: (3)

N= n'n n ­ n '

Sustituyendo (1) en (3), y conociendo el valor de n' = 20, se tiene como resultado la siguiente fórmula:

(4)

N= 20Z2_aP(1­P)

Z2_{aP(1­P)­20L}2

Incorporando los datos en la fórmula se tiene: N= 20(1.96)2(70)(30)

(1.96)2(70)(30)­20(15)2

N = 45

Por lo tanto, se puede decir que la muestra seleccionada de 20 empresas corresponde a un universo de 45 empresas en total.

5.6. Métodos estadísticos a utilizar

El método principal que se utilizará para el análisis de los datos de la investigación es la estadística descriptiva por medio de distribución por frecuencias, que es la agrupación de datos en categorías, mostrando el número de observaciones en cada categoría mutuamente exclusiva. Esta herramienta es útil para organizar una cantidad grande de datos de manera significativa (Lind y Masón, 1997).

Para la representación gráfica se utilizarán histogramas (describe una distribución de frecuencias utilizando una serie de rectángulos adyacentes, donde el alto de cada cuadrilátero es proporcional a la frecuencia que representa su

clase), las gráficas de barra simples (cada barra corresponde a la frecuencia de ocurrencia del grupo).

5.7. Descripción del Instrumento

Para llevar a cabo este estudio se eligió la encuesta como instrumento de investigación para la recolección de datos, ya que se consideró la forma más adecuada, tomando en cuenta la naturaleza de la investigación, que desea validar las prácticas administrativas del desarrollo de proyectos.

Se aplicará un cuestionario que consta de 18 preguntas cerradas, en algunas de las cuales se pide al entrevistado seleccionar una o más de las opciones que apliquen a la situación particular de la empresa. En otras se debe clasificar en orden de importancia algunos factores referentes al desarrollo de sistemas y la administración del proceso.

Las preguntas se enfocarán principalmente en los siguientes temas: la aplicación de metodologías, estándares y métricas para el desarrollo de sistemas computacionales, la estimación de recursos (tiempo, dinero, herramientas y personal), la selección y organización del equipo de trabajo; la participación del cliente/usuario en el proceso y los resultados obtenidos en sus proyectos de desarrollo de sistemas.

5.8. Resultados Obtenidos

En este apartado se describen los resultados obtenidos de la investigación de campo. Se describen cada una de las preguntas del cuestionario con la gráfica correspondiente a las respuestas obtenidas de las empresas, así como una descripción de los hallazgos más importantes obtenidos de cada una de las preguntas.

Cabe hacer la aclaración que en alguna de las preguntas los entrevistados opinaron que más de una respuesta coincidía con sus actividades, por lo cual se obtuvieron más de 20 respuestas, o en algunos casos al manejar diversos tipos de proyectos, algunas respuestas eran correctas para cierto tipo de proyectos, mientras que en otros las respuestas variaban. Por lo anterior se podrá observar que al presentar los resultados en las tablas o gráficas siguientes, algunas frecuencias suman más de 20 respuestas.

Por lo tanto para no discriminar los resultados obtenidos de acuerdo a las respuestas, se optó por expresar los resultados con relación al porcentaje de los

entrevistados que coinciden en sus afirmaciones, tomando como 100% las 20 empresas encuestadas.

A continuación se presentan las 18 preguntas del cuestionario aplicado a los entrevistados, junto con su gráfica y tabla de resultados obtenidos.

Pregunta 1: El desarrollo de un sistema se inicia por...

Primeramente se cuestionó acerca de quién o quiénes son los iniciadores del requerimiento de cada nuevo sistema a desarrollar.

Las respuestas y la frecuencia de los resultados se muestran en la Tabla 5.1 y en la Figura 5.1.

Opciones A B C D E Frecuencia 8 18 5 6 3

­:,;• ; • ­ Respuesta ­>*.• Requerimientos de un cliente interno Requerimientos de un cliente externo

Iniciativa del departamento de Sistemas/Informática Ordenes de la Dirección General

Otro

Tabla 5.1. El desarrollo de sistemas se inicia por... (De mayor a menor frecuencia).

Pregunta 1

O 2 4 6 8 10 12 14 16 18

Frecuencia

Figura 5.1. El desarrollo de sistemas se inicia por.

El 90% de las empresas entrevistadas respondieron que inician el desarrollo de sistemas por requerimientos de un cliente externo, esto se debe a que el tipo de empresas contactadas para este estudio son empresas de consultoría que se dedican a vender servicios de integración de soluciones de sistemas de información a otras empresas.

Sin embargo, se puede apreciar que el 40% de ellas aseguran que también recibe requerimientos de clientes internos para desarrollar sistemas.

Pregunta 2: ¿ Cómo se mide que un proyecto de desarrollo de sistemas ha sido exitoso ?

Aquí se cuestionó sobre las métricas para determinar si un proyecto de desarrollo de sistemas fue exitoso, pidiéndose que se ordenaran del 1 al 5 las actividades de acuerdo a su importancia. (1 de mayor importancia, 5 menor importancia).

Las respuestas y la importancia asignada por los entrevistados se muestran en la Tabla 5.2 y en la Figura 5.2.

Opciones A B C D E Importancia 3.60 4.25 1.50 1.85 3.80

• • Res puesta ­ '; • > . • :.. /r< \ ­1;, Finaliza a tiempo

No se excede del presupuesto

Cumple con los objetivos planeados (funcionalidad) Lo aprueba el cliente

Se implementa totalmente

Tabla 5.2. Éxito de un proyecto de desarrollo de sistemas (De mayor a menor importancia).

El 50% de los encuestados dan mayor importancia a que un proyecto de desarrollo cumpla con los objetivos planeados para determinar que éste ha sido exitoso, es decir que sea funcional.

Pero muy cercano a este porcentaje, en un 45% dan importancia a que lo apruebe el cliente, en este caso estos dos aspectos están muy relacionados, ya que si cumple con los objetivos, es muy probable que lo apruebe el cliente.

Pregunta 2

0 1 2 3 4

Menor Importancia Mayor Importancia

Figura 5.2. Éxito de un proyecto de desarrollo de sistemas.

Cabe mencionar que la aprobación del cliente en este tipo de empresas es primordial, ya que ellos son su razón de ser, y si éstos quedan satisfechos garantizan su permanencia como clientes para futuros trabajos o para incrementar su mercado si los clientes satisfechos los recomiendan con otras empresas.

Otro punto interesante de estos resultados es que la mayoría coinciden en que el punto con menor importancia es que los proyectos no se excedan del presupuesto, esto se debe mayormente a que en última instancia el excedente del presupuesto puede ser traspasado al cliente directa o indirectamente.

Pregunta 3: ¿ Cuáles de las siguientes actividades forman parte de la administración de un proyecto de desarrollo de sistemas ?

En esta pregunta se trata de indagar a qué actividades de las que conforman a la administración de un proyecto de desarrollo de sistemas se les asignan mayor importancia, por lo que se pidió que se ordenaran del 1 al 6 las actividades de acuerdo a su importancia. (1 mayor importancia, 6 menor importancia).

Las respuestas y la importancia asignada por los entrevistados se muestran en la Tabla 5.3 y en la Figura 5.3.

Opciones

^í^ \ " , '%'•$*

A B C D E F

Importancia

%*" y­ i­v>" ,*?*

4.30 4.30 2.50 2.75 4.70 2.45

­ • „ ­ ­ ­ Respuesta .<,­ ^*AÁ^' ­­

^.­,­ % ­ s « ­ ­ • ­ r ,.­,­ * • >vs¿ f<pf*V5?; *;; v­

Comprobación de la aplicación de la metodología

Medición del desempeño del equipo den trabajo

Nivel de satisfacción del cliente/usuario

Administración de los recursos asignados al proyecto

Nivel de satisfacción del equipo de trabajo Cumplimiento de los procedimientos y estándares de la empresa

Tabla 5.3. Actividades que forman parte de la Administración de Proyectos de Desarrollo de Sistemas (De mayor a menor importancia).

Podemos observar que el cumplimiento de los procedimientos y estándares de la empresa se encuentra en primer sitio de importancia entre las actividades que forman parte de la administración de los proyectos de desarrollo de sistemas, pero muy cercanamente seguido por el nivel de satisfacción del cliente/usuario.

Esto se puede apoyar en el hecho de que para cualquier empresa formalmente establecida es importante contar con procedimientos y estándares que guíen sus acciones y le den credibilidad ante la sociedad. Esto encaminado a tener una mejor imagen.

Pregunta 3

o 1

3 4

Mayor Importancia

Figura 5.3. Actividades que forman parte de la Administración de Proyectos de Desarrollo de Sistemas.

Sin embargo, dichos estándares y procedimientos no servirían de nada si su objetivo último no fuera un alto nivel de satisfacción de ios clientes, de quien depende su negocio.

La siguiente actividad en la escala de importancia es la administración de los recursos asignados al proyecto; es lógico pensar que como todo negocio, el desarrollo de sistemas debe ser rentable, por lo cual es importante una buena estimación de los recursos para con base en ellos realizar un presupuesto que el cliente aprobará, en la mayoría de los casos se pacta un precio por el sistema y un tiempo de entrega, si éstos no se cumplen, la empresa corre el riesgo de tener que absorber los costos extras o de perder el cliente si el sistema no es entregado a tiempo.

Pregunta 4: La realización de la metodología de desarrollo de sistemas:

En esta pregunta se cuestiona sobre el origen de la metodología de desarrollo de sistemas que se utiliza en la empresa, si fue desarrollada completamente en la empresa o por otra empresa, en conjunto o se adaptó de otra metodología ya existente o si se carece de una metodología formal.

Las respuestas y la frecuencia de los resultados se muestran en la Tabla 5.4 y en la Figura 5.4.

Opciones A B C D E Frecuencia 6 3 2 8 1

¿ • t ,. Pregunta ,

• > .. |if ¿¿jgOSplkjrs ­M.

Se desarrolló completamente de forma interna Se desarrolló completamente de forma externa Se desarrolló completamente con un tercero Se adaptó de otra ya existente

No se tiene

Tabla 5.4. Origen de la metodología de desarrollo de sistemas (De mayor a menor frecuencia).

Pregunta 4

0 1 2 3 4 5 6 7 8

Frecuencia

Figura 5.4. Origen de la metodología de desarrollo de sistemas.

Con base en los resultados de esta pregunta, se puede notar una tendencia por el adopción y adaptación de metodologías que han demostrado que funcionan en otras empresas, hay empresas que deciden tomar lo que ya está probado y realizarle cambios para adaptarse a sus necesidades.

En segundo término se tiene a las empresas que prefieren desarrollar desde inicio su propia metodología, para que se alinie totalmente con los objetivos de la empresa.

Por otro lado, están las empresas que prefieren utilizar el outsourcing en el desarrollo de la metodología y dejar que otra empresa con experiencia en el área les proporcionen la metodología de desarrollo.

En menor grado las empresas prefieren compartir el desarrollo de la metodología con alguna otra empresa, a menos que sean socios muy directos, pues implica un bajo grado de confidencialidad.

Por último observamos que las empresas que no tienen una metodología o al menos no formalmente, están en una posición nada ventajosa, pues es un aspecto sustantivo por el giro del negocio, pero esto puede ser por ser empresa en gestación o muy pequeña.

Pregunta 5: Utilización de la metodología de desarrollo de sistemas:

Con está pregunta se pretende conocer la forma en que se aplica la metodología en los diferentes proyectos de desarrollo que se tienen, saber si está uniformemente estandarizada y es homogénea para cualquier proyecto, si tiene variaciones según el proyecto o el área de la empresa de que se trate, o si no se aplica la metodología existente.

Las respuestas y la frecuencia de los resultados se muestran en la Tabla 5.5 y en la Figura 5.5.

Opciones

frecuencia

••:•

,

­í :.v, • .A

9

í

Es una estandarizada en general

Varía entre los diferentes equipos o departamentos Varía según los diferentes proyectos

No se aplica No se tiene

Tabla 5.5. Utilización de la metodología de desarrollo de sistemas (De mayor a menor frecuencia).

Pregunta 5

0 1 2 3 4 5 6 7

Frecuencia

Figura 5.5. Utilización de la metodología de desarrollo de sistemas.

Según los resultados de la pregunta, se observa una variedad en la forma de implementar la metodología de desarrollo de sistemas.

En primera instancia se tiene a las empresas que realizan variaciones a la metodología según el tipo de proyecto que se trate.

Después se están las empresas que realizan modificaciones a la metodología dependiendo del departamento o área en que se ubique el proyecto.

A continuación se encuentran las empresas que tienen uniformemente estandarizada la metodología sin diferenciar entre los proyectos que se traten.

Por último la minoría son las empresas que no aplican o no tienen metodología de desarrollo de sistemas.

Pregunta 6: Ciclo de vida del desarrollo de sistemas:

Con esta pregunta se pretende identificar el tipo de metodología de desarrollo de sistemas según los modelos de ciclo de vida del proyecto que aplican, presentándoles los modelos más usuales o representativos en el área de desarrollo de proyectos de software.

Las respuestas y la frecuencia de los resultados se muestran en la Tabla 5.6 y en la Figura 5.6.

Opciones A B C D E Frecuencia 5 6 7 2 0 Pregunta Secuencial Bloques traslapados Espiral Piramidal Otro

Tabla 5.6. Ciclo de vida del desarrollo de sistemas. (De mayor a menor frecuencia).

Pregunta 6

2 3 4 5

Frecuencia

Figura 5.6. Ciclo de vida del desarrollo de sistemas.

En esta pregunta se observa en primera instancia que las empresas siguen el modelo más clásico de espiral en el que el ciclo de vida de desarrollo de sistemas se reinicia después de cada ciclo de versión.

En segunda instancia se tiene la preferencia por el modelo de bloques traslapados, que es en forma de gráfica de Gantt donde entre cada fase del ciclo de vida puede existir un traslape en el tiempo, es decir que puede haber una coexistencia en ciertos puntos de las etapas del desarrollo del sistema.

A continuación observamos uno de los modelos más tradicionales, que es el secuencial, donde las fases del ciclo de vida siguen un orden determinado y

lineal y cada etapa comienza donde termina su predecesora en el orden que marca el modelo.

Posteriormente se encuentra un modelo más reciente que es el piramidal, por capas o estratos, que es similar al secuencial, pero involucra conceptos de abstracción de objetos, y los estratos se pueden empalmar entre sí, ya que el flujo no es necesariamente lineal.

Por último, no se presentó el caso de algún otro modelo, o los modelos que tienen las empresas son a grandes rasgos adaptables a los modelos planteados en la pregunta.

Pregunta 7: ¿ En cual de las siguientes categorías clasificaría el proceso de desarrollo de sistemas de los proyectos exitosos que se han llevado a cabo en la empresa ?

Con base en la clasificación hecha por el Instituto de Ingeniería de Software

(Software Engineering Institute) de la Universidad de Carnegie Mellon, paramedir el nivel de madurez de la metodología de desarrollo, se pretende conocer en qué categoría se encuentran las empresas entrevistadas.

Las respuestas y la frecuencia asignada por los entrevistados se muestran en la Tabla 5.7 y en la Figura 5.7.

Opciones :

A B C D E Frecuencia 1 8 9 6 0 Respuesta AdHoc Repetible Definido Administrado Optimizado

Tabla 5.7. Nivel de madurez de la metodología de desarrollo (De mayor a menor frecuencia).

Pregunta 7

0 1 2 3 4 5 6 7

Frecuencia

8 9

Figura 5.7. Nivel de madurez de la metodología de desarrollo.

El 45% de las empresas afirman que su metodología de desarrollo de sistemas se encuentran en la categoría de definido, esto es el desarrollo está perfectamente entendido e implementado y se llevan a cabo mediciones del proceso, el cual en su mayoría es predecible. Esto quiere decir que un porcentaje significativo de las empresas tienen su metodología bien definida, la siguen y miden los resultados obtenidos de la misma.

Una observación interesante es que muchas de las empresas tienen sistemas estándares ya desarrollados que se dedican a comercializar y sus desarrollos son adiciones o modificaciones a dichos sistemas.

Por otro lado las empresas que sí realizan nuevos desarrollos dicen llevar un control muy estricto al apego de la metodología, no sólo para el desarrollo, sino desde el inicio del requerimiento por parte del cliente/usuario, análisis del problema, la propuesta al cliente, etc. Por lo que los pasos a seguir son muy estructurados y repetibles, esto concuerda con los resultados apreciados en la gráfica, ya que en segundo lugar se observa que las empresas se encuentran en la categoría de repetible en cuanto a la madurez de su metodología de desarrollo.

Por último, cabe mencionar que ninguna de las empresas entrevistadas dijo estar en la categoría Ad­hoc, ya que en ella no existe una metodología definida y existen pocos o nulos controles. El comentario general al respecto de esta categoría fue que si una empresa se dedica al desarrollo de sistemas y estuviera en esta categoría, estaría condenada a la ruina.

en:

Pregunta 8: El riesgo de cada proyecto a desarrollar se mide con base

Esta pregunta tiene como objetivo indagar cuáles son los factores que se toman en cuenta para medir el riego de los proyectos de desarrollo de sistemas y cuál es su importancia, por lo que se pidió que se ordenaran del 1 al 5 estos factores de acuerdo a su importancia. (1 mayor importancia, 5 menor importancia). Las respuestas y la importancia asignada por los encuestados se muestran en la Tabla 5.8 y en la Figura 5.8.

Opciones; r

". V ­

A B C D E

importancia

•4 , , " * * • * ^ T ­

2.90 3.10 3.85 2.50 2.65

• :­ > ,

Tamaño del proyecto

Conocimiento de la tecnología Inversión económica

Impacto en la empresa

Grado de definición (estructura) del proyecto

Tabla 5.8. Medición del riesgo de los proyectos (De mayor a menor importancia).

Pregunta 8

O 0.5 1

Menor Importancia

1.5 2 2.5

Mayor Importancia

Figura 5.8. Medición del riesgo de los proyectos.

El 50% de las empresas encuestadas aseguran que toman en cuenta en primer lugar el impacto que el desarrollo tendrá en la empresa para medir el riesgo

del proyecto, esto lo atribuyeron mayormente a que entre mayor sea el impacto que el sistema a desarrollar tenga en la empresa, mayor es su riesgo, así pues, es necesario determinar todos los factores que puedan arriesgar el éxito en estos proyectos, ya que su función como proveedores de un servicio es ayudar a las empresas a solucionar sus problemas a través de los sistemas que ellos crean, y no el de generar mayores problemas con un sistema que no funcione adecuadamente y que dejen una mala impresión en los clientes.

Gran parte de los entrevistados asignó segundo término en importancia al grado de definición o estructura que tenga el proyecto para medir el riesgo de cada proyecto, esto se refiere al grado de definición que se tenga desde el inicio del proyecto, si se conocen todas las variables que van a intervenir, si se tiene claro cuál será el producto final. Este aspecto es muy importante ya que esta definición o estructura del proyecto es en lo que se basan estas empresas para hacer sus estimaciones y comprometerse con el cliente a entregarle lo que al inicio de él se defina.

Es importante mencionar que en último lugar de importancia se definió a la inversión económica, la mayoría de las empresas coinciden en que la inversión es poco influyente en su riesgo ya que los costos se trasladan de una u otra forma al cliente, y que es mejor medir el riesgo en base a otros factores como los descritos anteriormente.

Pregunta 9: Las estimaciones de los recursos que se destinarán al proyecto se realizan en base a:

Esta pregunta tiene como objetivo indagar sobre los métodos utilizados para llevar a cabo la estimación de los recursos destinados a los proyectos y su importancia dentro de la estimación, por lo que se pidió que se ordenaran del 1 al 4 estos factores de acuerdo a su importancia. (1 mayor importancia, 4 menor

importancia).

Las respuestas y la importancia asignada por los encuestados se muestran en la Tabla 5.9 y en la Figura 5.9.

Opciones A B C D importancia 2.90 2.30 2.05 2.75

­ . ,

. . • ­ ­ Respuesta \­ • ;^ ,4^%^ %••

Métodos estadísticos

Experiencia del líder de proyecto

Estándares prestablecidos en la empresa Necesidades del cliente/usuario

Tabla 5.9. Factores para determinar las estimaciones de recursos del proyecto (De mayor a menor importancia).

Pregunta 9

Figura 5.9. Factores para determinar las estimaciones de recursos del proyecto.

Primordialmente las empresas se basan en estándares preestablecidos para determinar sus estimaciones de tiempo, dinero, personal, pero muy cercano a este factor encontramos que también se basan en la experiencia del líder del proyecto para hacerlo. En la práctica la mayoría de las veces es una combinación de estos dos factores los que se utilizan para realizar las estimaciones, es decir, con base en una serie de estándares ya conocidos, los líderes utilizan su experiencia y situaciones vividas en proyectos anteriores para estimar los recursos necesarios para cada desarrollo.

Otro punto interesante a mencionar, es que los métodos estadísticos son los menos utilizados para la estimación, esto se debe a que la mayoría de las empresas no lleva un registro minucioso de los proyectos y de sus estimaciones, y si los registran, únicamente lo hacen por historial y no los analizan posteriormente

para determinar la exactitud de las estimaciones realizadas en proyectos pasados y con base en ellos aplicar estos conocimientos en los proyectos futuros.

Pregunta 10: ¿ Quién realiza la selección del líder del proyecto ?

Dentro de los aspectos primordiales que se desean analizar en el presente estudio se encuentra la conformación del equipo de trabajo, por lo tanto se cuestionó acerca de la selección del líder de proyecto, ¿quién se encarga de seleccionarlo?.

Las respuestas y la frecuencia asignada por los encuestados se muestran en la Tabla 5.10 y en la Figura 5.10.

Opciones A B C D E F Frecuencia 0 2 12 6 6 0

. , • ;. Respuesta « • « ­^^i ­

\V­ ' '­ x_{í ,}

El equipo de trabajo El cliente/usuario

Director de Sistemas/Informática

Existen líderes por área de especialidad Director General

Se aceptan voluntarios

Tabla 5.10. Quién realiza la selección del líder de proyecto (De mayor a menor frecuencia).

El 60% de los encuestados afirman en sus respuestas que la decisión de elegir a la persona que se encargará de liderar el proyecto lo realiza la Dirección de Sistemas/Informática, quien es normalmente la autoridad inmediata superior, no sólo del líder, sino del resto del equipo de trabajo y quien en última instancia es también responsable de los resultados que dicho líder produzca.

Pregunta 10

o

Frecuencia

10 12

Figura 5.10. Quién realiza la selección del líder de proyecto.

En segundo término se puede apreciar una equidad entre dos opciones: que el líder lo seleccione el director general, como cabeza de la empresa y responsable máximo de la misma. Este caso se presenta primordialmente en empresas pequeñas en las que el director general tiene contacto directo con todo el personal y conoce las habilidades y limitaciones de los miembros del equipo.

En esta misma frecuencia observamos como resultado que no se lleva a cabo una asignación propiamente de líder de proyecto, sino que existen áreas de especialidad previamente definidas, y en cada una de ellas existen uno o varios líderes de proyecto, a los cuales se les asigna un desarrollo con base en su carga de trabajo y especialización.

Es de notar con respecto a este cuestionamiento, que en ninguna de las empresas encuestadas la responsabilidad de seleccionar al líder recae en las bases, es decir en el mismo equipo de trabajo, ni tampoco se aceptan voluntarios. Lo anterior denota una organización jerárquica en la que se realiza la asignación de carga de trabajo y selección de personal en las capas superiores hacia abajo (líder, equipo de trabajo).

Pregunta 11: ¿ Quién realiza la selección del equipo de trabajo ?

Con el mismo propósito de la pregunta anterior, pero ahora enfocada en el resto de los integrantes del equipo de trabajo se pidió que se seleccionara al responsable de elegir el equipo de trabajo que se asignará a cada proyecto.

Las respuestas y la frecuencia asignada por los encuestados se muestran en la Tabla 5.11 y en la Figura 5.11.

Opciones A B C D E F G Frecuencia . 3 10 2 9 1 0 3

Respuesta "..­•„ •¿­­"­|V(;>|­ .­­ Director General

Gerencia de Sistemas/Informática

Existen equipos por área de especialidad Líder del proyecto

El cliente/usuario Se aceptan voluntarios Otros

Tabla 5.11. Selección del equipo de trabajo (De mayor a menor frecuencia).

Pregunta 11

o 1

Frecuencia

8 10

Figura 5.11. Selección del equipo de trabajo.

El 50% de las empresas encuestadas afirman que esta responsabilidad al igual que la selección del líder recae principalmente en el Director de Sistemas/Informática, por las mismas razones expuestas anteriormente.

En segundo término el 45% de los encuestados asignó esta responsabilidad al líder de proyecto, quien de acuerdo a su experiencia y al conocimiento de sus compañeros de trabajo, realiza la asignación de tareas con base en las necesidades de cada proyecto y a la carga de trabajo de cada integrante del equipo.

En este sentido cabe mencionar que en sólo una de las empresas encuestadas el cliente es el responsable de asignar el personal dedicado al proyecto, resulta interesante mencionar este caso, ya que igual que se realiza una propuesta del sistema a desarrollar, se presentan los posibles candidatos para llevar a cabo dicho trabajo, y es el cliente quien con base en la revisión de esta propuesta analiza sus necesidades y elige el personal con el que desea laboral.

Pregunta 12: ¿ Qué mecanismos de supervisión se utilizan dentro del equipo de trabajo ?

Para poder analizar la interacción dentro del equipo de trabajo y el papel del líder y cada uno de los integrantes, se cuestionó acerca de los mecanismos de supervisión o control que se aplican dentro del equipo asignado a cada proyecto.

Las respuestas y la frecuencia asignada por los entrevistados se muestran en la Tabla 5.12 y en la Figura 5.12.

Opciones A B C D Frecuencia 4 18 5 1

Respuesta. ­_­_, :(«y|í~^.|f¿; '

Equipos Autodirigidos El líder los supervisa

Trabajan Independientemente Dependen del Director de Sistemas

Tabla 5.12. Mecanismos de supervisión utilizados dentro del equipo de trabajo (De mayor a menor frecuencia).

Pregunta 12

2 4 6 8 10 12 14 16 18

Frecuencia

Figura 5.12. Mecanismos de supervisión utilizados dentro del equipo de trabajo.

En un 90% los encuestados afirmaron que el mecanismo utilizado para la supervisión del equipo de trabajo es a través de un líder del cual depende el resto del personal que conforman el equipo de trabajo. Lo anterior confirma que este tipo de empresas se encuentran organizadas jerárquicamente y su administración está basada en los principios básicos del control por supervisión directa de un superior al que se reportan los avances y necesidades de cada actividad realizada.

Pregunta 13: ¿ Qué mecanismos de comunicación se utilizan en el equipo de trabajo ?

Para conocer acerca de las interacciones del equipo de trabajo en general y la manera en que se comunican y cómo se lleva el control de los avances del proyecto, se cuestionó sobre los mecanismos de comunicación existentes y la frecuencia de uso de los mismos.

En la tabla 5.13 y en la Figura 5.13 se muestran la matriz de los resultados obtenidos.

Medio/Períodiidad, Diario Semanal Mensual Fin Module»

Correo

19

1

1

12

O

15

14

Tabla 5.13. Mecanismos de comunicación dentro del equipo de trabajo.

En esta gráfica se distingue que para la comunicación diaria del equipo prevalece el uso del correo electrónico, así como las reuniones/juntas y las presentaciones de avances son los mecanismos de seguimiento y comunicación que se realizan por semana, seguidos de los reportes escritos.

Pregunta 13

8 10 12 14 16 18 20

Figura 5.13. Mecanismos de comunicación dentro del equipo de trabajo.

En algunos casos estos reportes y presentaciones se llevan a cabo también en la terminación de cada módulo, pero en la mayoría de las empresas como se

hacen con una periodicidad mayormente semanal, no se lleva a cabo un reporte por finalización de módulos.

Es de notar que todos los mecanismos de comunicación y seguimiento disminuyen considerablemente al final del proyecto. Tal vez porque las reuniones no son tan frecuentes o porque los reportes ya no son tan necesarios.

Pregunta 14: ¿ Qué factores son de mayor importancia para medir el desempeño del equipo de trabajo ?

Un aspecto muy importante dentro del análisis que se pretende hacer en este estudio con respecto al personal del proyecto, es conocer cómo se miden los resultados obtenidos, por lo cual se cuestionó sobre los factores que se utilizan para medir el desempeño del equipo de trabajo. Además se pidió que se ordenaran del 1 al 7 de acuerdo a su importancia. (1 mayor importancia, 7 menor importancia).

Las respuestas y la importancia asignada por los entrevistados se muestran en la Tabla 5.14 y en la Figura 5.14.

Opciones A B C D E F G ^Importancia 1.85 3.40 4.35 2.65 4.60 5.00 6.15 Respuesta Y

.­. .­ .'• ­\. ­­ • " ­;í • ¿T" '¡ _{''> "• ­..­•}

Cumplimiento de los objetivos iniciales Terminación a tiempo

Terminación dentro del presupuesto Retroalimentación de los clientes Evaluación del líder de proyecto

Evaluación de los integrantes del equipo Autoevaluación

Tabla 5.14. Factores para medir el desempeño del equipo de trabajo. (De mayor a menor importancia).

El 60% de las empresas coinciden en valorar el cumplimiento de los objetivos iniciales del proyecto como primero en importancia para medir el desempeño del equipo de trabajo, ya que éste es un valor más o menos cualitativo que puede ser fácilmente medido con base en la retroalimentación del cliente/usuario y a la revisión de lo planeado y pactado al inicio del desarrollo.

Pregunta 14

O 1 2

Menor Importancia

4 5 6

Mayor Importancia

Figura 5.14. Factores para medir el desempeño del equipo de trabajo.

En segundo término se considera la retroalimentación de los clientes, ya que son éstos quienes a fin de cuentas miden el desempeño del sistema entregado y quienes pueden determinar su funcionalidad con base en su uso. En este tipo de empresas como en todas las que prestan un servicio, la satisfacción del cliente es número uno en sus prioridades, por ello una métrica muy utilizada es la reacción de los clientes ante el sistema entregado.

Como aspectos complementarios a la medición del desempeño del equipo se encuentra que se cumplan con la estimación de tiempo y recursos casi en la misma proporción. Con menor importancia se consideran los aspectos internos de evaluación, es decir la opinión del líder y de los mismos integrantes del equipo. Aquí surge nuevamente a relucir el lugar preponderante hacia el exterior, dejando los aspectos internos en segundo plano.

Pregunta 15: Porcentaje de proyectos exitosos en un año

Esta parte de la encuesta se dedicó a validar los resultados obtenidos por las empresas en cuanto a la administración de los proyectos de desarrollo de sistemas.

Debido a que el tamaño de las empresas y el número de proyectos que cada una maneja puede variar grandemente, se decidió evaluar los éxitos en

relación a un porcentaje del total, lo cual evita el sesgo de las respuestas en cuanto a la variación en número y dimensión de los proyectos.

Por lo cual, se pidió que se clasificaran dentro de diferentes rangos de porcentajes los proyectos exitosos que se obtuvieron en el transcurso de un año, tomando en cuenta varios aspectos como la terminación a tiempo, en presupuesto, con los recursos estimados, y cumpliendo con los objetivos planeados.

En la Tabla 5.15 y en la Figura 5.15 se muestra la matriz de los resultados obtenidos.

Rango_{. ,%­;<^,«ív} : ; v

•vO^is&tof­

­"X&­:lQQíW>

Tabla 5.15. Clasificación de proyectos exitosos en un año.

Se puede observar que la gran mayoría de los entrevistados consideran que los proyectos de desarrollo realizados en su empresa y clasificados por ellos mismos como exitosos, con base en los cuatro criterios cuestionados (tiempo, presupuesto, recursos y objetivos) el 80% de las empresas consideraron que de sus proyectos exitosos cumplieron con sus objetivos dentro del rango del 76 al

100% (de los objetivos cumplidos).

Dentro de este mismo rango (76 al 100%), aproximadamente en un 45% finalizaron con los recursos estimados, la excepción es el tiempo, las respuestas señalan que en este rango sólo el 15% se terminó en el tiempo especificado. Esta clasificación muestra una idea de las prioridades con las que se clasifican cada uno de estos factores.

Por otra parte, se observa que en cuanto a las estimaciones de tiempo y presupuesto acertados, la mayoría clasificó en el rango de 51­75%, lo cual indica que poco más de la mitad de los proyectos terminan en el tiempo estimado y con el presupuesto inicialmente calculado.

Pregunta 15

76-100%

51 - 75 %

26 ­ 50 %

0­25 %

g Objetivas

rj Recursos

B Presupuesto

8 10 12 14 16

F/gwa 5.15. Clasificación de proyectos exitosos en un año.

La mayor variación dentro de los rangos se observa en cuanto al tiempo, ya que este aspecto aparece significativamente en los cuatro rangos establecidos, lo que da una idea que lo más difícil de estimar adecuadamente es el tiempo en que se concluirá un desarrollo.

Pregunta 16: Porcentaje de proyectos NO exitosos en un año

Así como preguntó sobre los éxitos obtenidos en los proyectos de desarrollo de sistemas, se determinó crucial indagar sobre los proyectos no exitosos en las empresas, para tener un punto de referencia y comparación entre los dos aspectos.

Por lo tanto, también se pidió que se clasificarán dentro de diferentes rangos de porcentajes los proyectos NO exitosos que se obtuvieron en el transcurso de un año, tomando en cuenta varios aspectos para su cancelación como falta de presupuesto, falta de tiempo, desconocimiento de la tecnología,

desviación de los objetivos establecidos al inicio, problemas con los clientes/usuarios y factores ajenos a la empresa de desarrollo.

En la Tabla 5.16 y en la Figura 5.16 se muestra la matriz de los resultados obtenidos.

Rangos 0­25 % 26­50%

1 s _\

5_ír"^Í? 7€^10Q|% Presupuesto 20 0 0 0 Tiempo 18 1 1 0 Tecnología 18 1 0 1 Objetivos 14 5 1 0 Clientes •í 17 1 0 2 Externos

'„ "­ ­^ , ­

14 2 2 2

7a£>/a 5.76. Clasificación de proyectos NO exitosos.

Pregunta 16

76-100%

51 -75 %

26 ­ 50 %

0 ­ 2 5 %

g Externos B Clientes rj Objetivos rj Tecnología B Tiempo @ Presupuesto

8 10 12 14 16 18 20

Figura 5.16. Clasificación de proyectos NO exitosos en un año.

desconocimiento de la tecnología, ya que tratándose de una empresa de servicios no se puede dar el lujo de desechar clientes por falta de tiempo o de presupuesto interno, lo más común en estos casos es que los proyectos se retrasen se pospongan cierto período pero se trata siempre de dar un servicio. O en su defecto de posponer su inicio hasta que se cuente con los recursos necesarios.

En un segundo término dentro del rango de 26 al 50 %, la mayoría de los proyectos se cancelan porque se desvían de los objetivos establecidos inicialmente, en estos casos los entrevistados indican que lo que ocurre es que se cancela dicho proyecto pero se inicia uno nuevo donde se definen claramente los objetivos deseados.

Otra observación es que en el rango superior 76 ­100 % la mayoría de los proyectos que se cancelan es por aspectos externos a la empresa o por problemas con el cliente/usuario, tal vez por los problemas de solvencia económica del cliente o por cambios en el entorno económico en general.

Pregunta 17: Factores que determinan el éxito de un proyecto de desarrollo de sistemas.

Para corroborar los factores de éxito en un proyecto de desarrollo de sistemas y la percepción que de ellos tienen las empresas se pidió que se clasificaran seis de ellos, mismos que se manejaron en distintas preguntas a lo largo del cuestionario.

Las respuestas y la importancia asignada por los entrevistados se muestran en la Tabla 5.17 y en la Figura 5.17.

Opciones • r"íf A B C D E F importancia

­'^r^ví*­ ;•> <*.

3.20 1.50 5.00 4.15 5.15 2.00

_,.t. .,t. . ­ Respuesta

Finaliza a tiempo

Cumple con los requisitos/objetivos Consume el mínimo de recursos Finaliza dentro del presupuesto El equipo está satisfecho

Lo aprueba el cliente/usuario

Tabla 5.17. Factores que determinan el éxito de un proyecto (De mayor a menor importancia).

Pregunta 17

O 1 2

Menor Importancia

4 5 6

Mayor Importancia

Figura 5.17. Factores que determinan el éxito de un proyecto.

Efectivamente se comprueba con estas respuestas lo que a lo largo de la encuesta se ha observado, prevaleciendo en importancia el cumplimiento de los objetivos y requerimientos del cliente en un 60% como principal factor de éxito en los proyectos, seguido por la aprobación del cliente.

Los aspectos de estimación de tiempo, dinero y recursos en general son de menor importancia y los aspectos internos como es la satisfacción del equipo de trabajo se evaluaron como de menor importancia entre los descritos.

Pregunta 18: ¿ Qué papel desempeña el cliente/usuario en el proceso de desarrollo de sistemas ?

Por último, se consideró importante indagar cuál es la participación del cliente en todo el proceso del desarrollo, desde el punto de vista de las empresas. Para lo cual se pidió que se seleccionara uno o más de los roles que asume el cliente/usuario en los diferentes proyectos que se realizan.

Las respuestas y la frecuencia asignada por los encuestados se muestran en la Tabla 5.18 y en la Figura 5.18.

Opciones A B C D E Frecuencia 4 11 11 9 6

Respuesta . »,. ^ .. ­ , • ^ Solo proporciona información

Aporta ideas y sugerencias Aprueba cada fase del proyecto

Interviene activamente en alguna

proyecto fase del

Forma parte del equipo de trabajo

Tabla 5.18. Participación del cliente/usuario en el proceso de desarrollo (De mayor a menor

frecuencia).

Pregunta 18

4 6 8

Frecuencia

10 12

Figura 5.18. Participación de cliente/usuario en el proceso de desarrollo.

En un 55% de los encuestados coincidieron que mayormente el papel del cliente/usuario es aprobar cada fase del proyecto, es decir, es una entidad activa en el proceso de desarrollo, también seleccionaron en igual proporción (55%) que el cliente aporta ideas y sugerencias sobre sus necesidades y los requerimientos del sistema deseado, es claro que el cliente debe participar en toma de decisiones de cada fase del proyecto, así mismo desea aportar sus conocimientos y experiencias para que el sistema resultante cumpla con sus expectativas.

Por otra parte, en un 45% de las respuestas de los entrevistados dicen que el cliente/usuario participa activamente en el desarrollo, en lo que todos coincidieron es que esta participación varía grandemente de un cliente a otro y de

un proyecto a otro, depende mucho de los responsables internos que cada empresa asigne para hacerse cargo del proyecto y de las características individuales de cada proyecto, puede ser con base en el riesgo que éste implica para la empresa o de los beneficios que esperan recibir del mismo.

6. Contribución y Trabajos Futuros

6.1. Introducción

Con base en la investigación documental realizada y el análisis de los resultados obtenidos en el capítulo de investigación de campo, se presentará una propuesta de los elementos clave para integrar un modelo para el desarrollo de proyectos de software con un esquema de grupos autodirigidos.

Además con los elementos presentados se propondrá un modelo para el desarrollo de proyectos de software con un esquema de grupos autodirigidos, el cual no se pretende que sea considerado como un modelo de solución, ni como una metodología, sino como una propuesta derivada de esta investigación que pueda servir como referencia cuando se desarrollen proyectos bajo el contexto mencionado en el título de la tesis.

Para finalizar el capítulo se presentarán las futuras líneas de investigación que se consideran interesantes para darle continuidad a este trabajo.

Al presentar un modelo no se pretende que se considere una metodología o receta de cocina que asegure el éxito de los proyectos sobre los que se aplique dicho modelo, sin embargo si se intenta que sea un marco de referencia sobre el cual desarrollar una guía de trabajo para el proyecto.

En esta investigación se plantea tres dimensiones bien definidas que son la administración de proyectos, los grupos autodirigidos y el desarrollo de software. Este último es el ámbito sobre el cual se enfoca el modelo propuesto.

Lo más importante para las empresas de desarrollo de sistemas de software es la satisfacción del cliente al cumplir con los requerimientos, especificaciones y tiempos acordados, desde luego intentando administrar los recursos, costos y tiempos que son las fuerzas que influyen en el proyecto.

Administración de Proyectos Desarrollo de Software Grupos Autodirigidos

Figura 6.1. Las 3 dimensiones del modelo

6.2. Contribución

Como contribución de esta investigación se presenta un modelo conceptual para la realización de proyectos de desarrollo de sistemas utilizando equipos a utodi rígidos.

Además se plantea un cuestionario para otorgarle una idea al administrador del proyecto del nivel de riesgo y el potencial de éxito que plantea el desarrollo de dicho proyecto al evaluar los factores clave que esta investigación determinó como esenciales para lograr un cierre de proyecto satisfactorio.

6.2.1. Modelo conceptual

Existe una gran variedad de modelos conceptuales sobre desarrollo de sistemas de software, sin embargo, para simplificar el entendimiento se optó por proponer un modelo sencillo que contemple de manera clara el aspecto importante de lo que implica el ciclo de vida de un desarrollo de software, que es el carácter cíclico, y la ¡dea qu debe tener un principio y un fin bien delimitados.

FASES

Workflow

Identificación

Planificado^ Elaboración (

Anal. Riesgo^ , Preparada

Construcción

Verificación . Transición

Iteración en Fase de Elaboración

Iterac¡ón­es Inicial­es

Iteraciones Figura 6.2. Modelo de desarrollo de proyectos de software.

Fuente: Gráfico adaptado de documentos www.rational.com

Las fases pueden variar dependiendo de la metodología de desarrollo de software o de administración de proyectos que se utilice. Sin embargo, el ciclo de la vida del proyecto de desarrollo debe iniciar y culminar, ya sea en versiones o en prototipos.

Controles iterativos:

0 Preparación. Objetivos, definir alcances del proyecto.

0 Elaboración. Plan del proyecto, especificar características, arquitectura. 0 Construcción. Desarrollo del producto.

0 Transición. Transición del producto a la comunidad de usuarios finales.

En la gráfica del modelo se presenta un ciclo de desarrollo de sistemas típico, donde se observa el workflow y las dimensiones del desarrollo de software

en relación con las fases del proyecto y las iteraciones necesarias para su realización.

Las dimensiones del desarrollo de software ya no se representan en forma secuencial como en modelos anteriores, sino que pueden estar traslapadas pero a la vez codependientes.

Producto suficientemente maduro para el cliente Comprometer recursos

para la construcción Comprometer recursos

para la fase de elaboración

Aceptación del cliente o fin del ciclo de vida

Preparación

Elaboración

Construcción

Transición

A A A

Objetivos Arquitectura Capacidad Producto

Operativa Liberado

Figura 6.3. Puntos clave en el ciclo de vida del proyecto.

Los puntos clave ayudan a evaluar el progreso del proyecto, el administrador puede usarlos para establecer criterios que decidan el curso del proyecto.

La duración de las iteraciones depende del tamaño de la organización, del tamaño del proyecto, la familiaridad con el proceso y la simplicidad técnica. Una vez que se conoce la duración, se puede decidir el número de iteraciones en cada fase.

Si la Preparación consiste solo de planeación y mercadotécnia, entonces puede no ser realmente una iteración. Si se necesita un prototipo se necesita evitar un riego técnico, se necesitará una iteración.

El número de iteraciones en la Elaboración puede depender de la complejidad de la arquitectura, de donde se está partiendo y de la experiencia del equipo.

Durante la Construcción, se pueden usar iteraciones para hacer un buen trabajo de pruebas e integración. Suficiente automatización puede hacer más fácil el manejo de más iteraciones. Así mismo, un proceso maduro puede acomodar más iteraciones.

La Transición requeriría al menos una iteración o más si las condiciones en el momento de la transición así lo requieren.

En la* gráfica también se pueden ver unas protuberancias que representan la intensidad del flujo de trabajo requerida en esa franja del ciclo de vida del proyecto. Es aquí donde aplica la otra dimensión del modelo que trata esta investigación que es los grupos de trabajo autodirigidos.

En uno de los capítulos de este trabajo se trato el tema de los grupos de trabajo autodirigidos, si se tiene un esquema de trabajo con este tipo de equipos, se pueden implementar "celdas" de trabajo, compuesta por grupos de trabajo que se encarguen de cubrir las funciones necesarias para realizar o ayudar a realizar las tareas necesarias, ya sean elementales, modulares, funcionales, etc.

Figura 6.4. Celdas de trabajo (equipos autodirigidos) asignados a tareas.

De esta forma, sí se tiene que cubrir una función compleja más de una celda de trabajo puede asistir en su realización. Haciendo las unidades de trabajo más complejas que un solo individuo, se da el valor agregado de la heterogeneidad en la función de respuesta a algún requerimiento, se logra una integración importante en los grupos de trabajo, se obtiene una solución más completa de los problemas y con un tiempo de respuesta menor.

En este punto es donde interviene un concepto clave, el rol. El rol define el comportamiento y reponsabílidades de unindividuo, o de un conjunto de individuos trabajando juntos como un equipo autodirigido o en este caso una celda de trabajo.

Los comportamientos son un conjunto de actividades cohesivas. Las responsabilidades usualmente se definen relativas a ciertos artefactos. De esta forma los miembros de equipos autodirigidos puden formar parte de diferentes celdas de trabajo.

Los roles se constituyen por un conjunto de actividades cohesivas que se desarrollan. Estas actividades están fuertemente relacionadas y funcionalmente acopladas. Las actividades son cohesivas en el sentido que son mejormente alcanzadas cuando son combinadas y desempeñadas por una celda de trabajo.

El estilo del esquema de trabajo con equipos autodirigidos depende de la estructuración que el administrador de proyectos le imprima, pueden ser equipos altamente especializados o equipos staff de soluciones. Lo importante es alcanzar el autodesempeño en estos grupos.

6.2.2. Factores Clave

Se consideró necesario valorar los factores clave según su importancia para el logro de los objetivos de las empresas de desarrollo de sistemas de software, los cuales se resumen fundamentalmente en lograr la máxima satisfacción del cliente. Analizando las respuestas obtenidas en la investigación de campo, y en base a la bibliografía analizada se presentan estos factores clave en orden de importancia para el logro de este objetivo (máxima satisfacción del cliente).

En la Tabla 6.1 se presentan dichos factores en orden de importancia, siendo el 1 el más importante y 10 el de menor importancia.

Factores clave

1. Determinación de los satisfactores del cliente (requerimientos). 2. Clara definición de los objetivos.

3. Involucramiento del cliente en cada una de las etapas del proyecto.

4. Establecimiento de estándares, procedimientos y metodologías de desarrollo. 5. Estimación de recursos con base en parámetros establecidos por la empresa y

experiencias anteriores. 6. Un buen líder de proyectos.

7. Selección del personal con base en sus habilidades y experiencia en el área de sistemas y en el conocimiento de las herramientas y plataformas de trabajo. 8. Supervisión y comunicación en el equipo de trabajo.

9. Establecimiento de metas intermedias alcanzables.

10. Medición del desempeño del equipo de trabajo basándose en el cumplimiento de objetivos y en la satisfacción del cliente.

Tabla 6.1. Factores clave para una exitosa administración de proyectos de desarrollo de sistemas en empresas de este giro.

Una vez determinados los factores clave, analizaremos su relación con cada una de las fases del proceso de administración de desarrollo de sistemas, es decir, su influencia en cada una de estas etapas.

En la Tabla 6.2 se presentan los factores clave propuestos y su influencia en cada una de las fases del desarrollo de sistemas, así como el proceso de administración de dicho desarrollo.

Las fases son: inicio del proyecto, análisis, diseño, codificación o programación, implementación y el proceso de administración del proyecto que se lleva acabo a lo largo de todas las fases. Consideramos la primera fase (inicio del proyecto) como todas las actividades que se deben realizar antes de iniciar la fase de análisis: establecimiento de la relación con el cliente, primeras entrevistas, fase

de pre­análisis, realización de la propuesta inicial, aceptación de una relación para el desarrollo del sistema, etc.

En la Tabla 6.2 se puede observar que las fases donde más intervienen los factores clave son las de inicio y en la administración, en la fase de inicio es de suma importancia determinar lo que el cliente desea, establecer objetivos claros, recursos necesarios, tanto técnicos como de personal (líder y equipo de trabajo), y establecer metas. Sin embargo, estas actividades no son únicamente importantes durante la fase de inicio, sino que se deben monitorear y ajustar a las necesidades conforme avance el proyecto, es por eso que se consideran cruciales dentro del proceso de administración del proyecto.

Otra fase en la que influyen varios de los factores claves es en el análisis, esto es porque una vez determinada la relación entre clientes y empresa de desarrollo de sistemas, se deben especificar exactamente tanto las metas, entregables, fechas de compromiso y recursos que se utilizarán en el proyecto y el líder debe organizar a su equipo de trabajo y establecer responsabilidades con base a las habilidades de cada uno de los integrantes.

Existen dos factores clave: el ¡nvolucramiento del cliente y la supervisión y comunicación que afectan a todas las fases y al proceso de administración del proyecto, ya que ambas se deben cuidar durante todo el desarrollo para dar seguimiento y tener control de los objetivos, compromisos y consumo de recursos: tanto por parte del cliente como parte integral del proyecto, como del líder al resto del equipo de trabajo.

Otros factores clave como el establecimiento de estándares, procedimientos y metodologías de desarrollo y la medición del desempeño del equipo de trabajo muestran influencia en una sola fase (codificación en el caso de establecimiento de estándares), sin embargo, ésta sola influencia es determinante para el buen funcionamiento de esta fase, ya que si no se contara con procedimientos y metodologías de desarrollo bien definidos esta etapa estaría propensa al fracaso.

Factoresr­V'"^.­ 1 . Determinación

de los

satisfactores del cliente 2. Clara definición

de los objetivos 3. Involucramiento

del cliente en cada etapa del proyecto 4. Establecimiento

de estándares, procedimientos y metodologías 5. Estimación de

recursos

Inicio Análisis Diseño

­

Codificación

­

Implementación _í^iWnistpWi

6. Un buen líder de proyectos 7. Selección del

personal 8. Supervisión y

comunicación 9. Establecimiento

de metas intermedias alcanzables 10. Medición del

desempeño

­ ­

Tabla 6.2. Factores clave y su importancia en las diferentes etapas del desarrollo

Por otro lado, el factor de medición de desempeño se identifica en el proceso de administración del desarrollo ya que con base en lo realizado en las diferentes etapas de éste puede ser medido, normalmente cada fase tendrá su grado de desempeño, sobre el cual el administrado debe ir haciendo sus ajustes para lograr cubrir los objetivos establecidos a lo largo de todo el proceso de administración del proyecto.

Una vez determinados los factores clave y su importancia en cada una de las fases del proyecto, es necesario contar con algún mecanismo para su medición, el cual nos permita establecer para cada proyecto, el grado de éxito o riesgo de fracaso con base en estos factores.

En el siguiente apartado se presenta un estudio realizado en empresas de desarrollo de sistemas norteamericanas donde se determinaron una serie de factores clave y un mecanismo para medirlos, con base en este modelo se propondrá un marco de referencia similar para la medición de los factores clave establecidos en esta investigación.

6.2.3. Criterios de Éxito

The Standish Group es una empresa norteamericana dedicada a hacer estudios de mercado y dar consultoría a empresas dedicadas al desarrollo de software y al comercio electrónico, sus áreas de estudio se centran principalmente en: tecnologías para el desarrollo de aplicaciones, para el manejo de datos, para la administración y control de sistemas computacionales.

En un estudio denominado CHAOS realizado por Standish Group en 1995, se determinaron 10 criterios de éxito para el desarrollo de sistemas computacionales, dicho estudio se realizó entre administradores y altos ejecutivos de sistemas de empresas líderes en diferentes segmentos de la industria como el bancario, seguridad, manufactura, industrias del detalle, hospitales, aseguradoras,