Modelo de Administración de Proyectos Para Desarrollo de
Software con Equipos Autodirigidos-Edición Única
Title Modelo de Administración de Proyectos Para Desarrollo de Software con Equipos Autodirigidos-Edición Única
Authors Paúl Méndez Maldonado Affiliation ITESM
Issue Date 2003-04-01 Item type Tesis
Rights Open Access
Downloaded 19-Jan-2017 08:53:35
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS MONTERREY
DIVISIÓN DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMÁTICA
Y COMUNICACIONES
MODELO DE ADMINISTRACIÓN DE PROYECTOS PARA DESARROLLO DE SOFTWARE CON EQUIPOS
AUTODIRIGIDOS
TESIS
PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE:
MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN
POR
PAUL MÉNDEZ MALDONADO
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
MAESTRÍA EN ADMINISTRACIÓN DE TECNOLOGÍAS
DE INFORMACIÓN
TESIS
MODELO DE ADMINISTRACIÓN DE PROYECTOS PARA
DESARROLLO DE SOFTWARE CON EQUIPOS
AUTODIRIGIDOS
POR
Paul Méndez Maldonado
DEDICATORIA
A mis padres, por todo su apoyo durante este proceso de formación, a mi madre por haberme enseñado a ver siempre las cosas positivas, de contagiarme con ese entusiasmo y emoción por la vida que sólo ella sabe transmitir, a mi padre por enseñarme a ser un hombre con valores bien definidos y a dar siempre lo mejor de mi en cada empresa que vaya a emprender.
A la mujer de mi vida, por su cariño y comprensión durante todos estos años en que la distancia hizo más fuerte nuestra relación, por todo lo bueno que trajo a mi vida, pero sobre todo, por su amor, que me impulsaba en los momentos más difíciles a seguir adelante ... te amo Monserrat.
A mis asesores, a Leticia por haberme guiado en esta labor tan ardua pero a la vez tan gratificante, por todos sus consejos y su tiempo, a Cuauhtémoc, del que he aprendido tantas cosas, por haber creído en mi y darme la oportunidad de demostrar lo que puedo ofrecer como profesionista, y a Víctor que entro de "bateador" emergente en esta comité, un excelente profesionista, un gran compañero y amigo.
A ti "Lorenz", mi querida hermana, por haber ampliado mis límites de paciencia y tolerancia durante todo el tiempo que convivimos juntos, por lo buenos momentos que pasamos y los que faltan.
A mi familia, porque todos y cada uno de ellos estuvieron siempre al pendiente de mí, gracias por su apoyo y su ayuda para lograr este objetivo que al final se llevó a cabo con gran éxito.
A L.O.M., mis grandes amigos, que nos conocemos desde hace años y con los cuales he crecido y convivido durante tanto tiempo, a pesar que ahora algunos hemos tomado rumbos distintos, seguimos siendo los mejores amigos, por tantos recuerdos y anécdotas ... gracias por su amistad.
RESUMEN
La administración de proyectos ha surgido como una disciplina relativamente nueva en los últimos años, debido a la importancia que ha cobrado para las organizaciones la forma de llevar el control desde el inicio hasta el fin de un proyecto, con prácticas de planeación y seguimiento perfectamente bien definidas, involucrando a todas las áreas y recursos necesarios para llevar a cabo el objetivo propuesto.
De la misma forma en que la administración de proyectos ha crecido en las últimas dos décadas, las ciencias computacionales se han desarrollado exponencialmente, principalmente en los últimos años, esto nos lleva al área de desarrollo de software, que engloba prácticamente todas las áreas que componen las disciplina anteriormente mencionada, y que requiere de un grado de exactitud considerable, ya que es durante un desarrollo de productos de software donde se presentan'diversas problemáticas que se deben resolver para el logro del producto final y durante todo el ciclo de vida de dicho producto.
A lo largo de los años han surgido diversos modelos para el trabajo en equipo, de los cuales el más común ha sido el jerárquico, donde todos los integrantes de un equipo son dirigidos directamente por un individuo, en el cual recae toda la responsabilidad de controlar las actividades de los elementos a su cargo y el poder de decisión le pertenece en su totalidad, aunque el uso de este modelo ha disminuido considerablemente, debido a las múltiples deficiencias que presenta en algunos casos que se necesita otorgar a la persona cierto poder de decisión y así aprovechar al máximo las capacidades de los miembros del equipo de trabajo.
De los múltiples modelos que se han creado a lo largo del tiempo, se analizará el uso de los equipos autodirigidos, que prácticamente rompen los esquemas tradicionales, ya que todos los miembros del equipo cuentan con autonomía propia, lo que les permite estar involucrados directamente en cada una de las decisiones concernientes al proyecto, y son responsables de los procesos y actividades del mismo. Este esquema de trabajo permite aprovechar al máximo las capacidades de cada individuo, y la interacción humana resultante de un equipo autodirigido, permite una alta integración de los miembros, debido a las características inherentes del mismo.
La presente investigación tiene como objetivo proponer un modelo de administración de proyectos para el desarrollo de productos de software, utilizando como esquema de trabajo los equipos autodirigidos, para aprovechar las ventajas que esto ofrece, principalmente porque el desarrollo de software, es una de las principales áreas de aplicación de este tipo de equipos.
Para esta investigación se requiere recopilar cierta información con respecto al manejo de equipos de trabajo y a las prácticas utilizadas en el desarrollo de software y administración de proyectos de empresas dedicadas a este giro y que utilicen equipos autodirigidos. Esto se llevará a cabo mediante el uso de herramientas de apoyo, las cuales se describirán con detalle en el Capítulo IV, de donde se obtendrá la información necesaria para sustentar el modelo.
Los resultados obtenidos muestran una clara preferencia de los individuos hacia un liderazgo participativo, esto muestra que tiene el perfil idóneo para trabajar en equipos autodirigidos, de la misma forma se analizan diversas variables que muestran el comportamiento de los individuos que forman el equipo.
ÍNDICE
DEDICATORIA ¡v RESUMEN v ÍNDICE viü ÍNDICE DE TABLAS xi ÍNDICE DE FIGURAS xii ÍNDICE DE GRÁFICAS xiii
4.3.2 Tipo de liderazgo 54 4.3.3 Formación de equipos de trabajo 55 4.3.4 Prácticas de administración y desarrollo de software 61 4.4 Caso de estudio 61 4.4.1 Descripción del equipo de trabajo 62 4.4.2 Liderazgo en el equipo 64 4.4.3 Formación de equipos de trabajo 65 4.4.4 Procesos de administración y desarrollo de software 65 4.4.5 Resultados del CAT 68 4.5 Conclusiones 68
CAPITULO 5: Análisis de resultados 70
5.1 Tipo de Liderazgo preferido 70 5.2 Grado de confianza 71 5.3 Grado de apertura 73 5.4 Grado de compromiso 75 5.5 Grado de colaboración 77 5.6 Organización de equipos de trabajo 79 5.6.1 Liderazgo y gobierno de equipos 79 5.6.2 Monitoreo del desempeño y retroalimentación 80 5.6.3 Selección de los miembros de los equipos 81 5.6.4 Autonomía y toma de decisiones 82 5.7 Prácticas en administración de proyectos de software 835.7.1 Pregunta 1: Responsable del inicio de un desarrollo de
sistema 84 5.7.2 Pregunta 2: ¿Cómo se mide que un proyecto de desarrollo de sistemas ha sido exitoso? 85 5.7.3 Pregunta 3: ¿Cuáles de las siguientes actividades forman parte de la administración de un proyecto de desarrollo de sistemas?....86 5.7.4 Pregunta 4: La metodología de desarrollo de sistemas 87 5.7.5 Pregunta 5: La utilización de la metodología 88 5.7.6 Pregunta 6: El papel que desempeña el cliente / usuario en el desarrollo 89 5.7.7 Pregunta 7: Categorías para clasificar el proceso de desarrollo de software 90 5.7.8 Pregunta 8: Como se mide el riesgo de un proyecto de
desarrollo de software 91 5.7.9 Pregunta 9: Responsable de la estimación de recursos
asignados al proyecto 93 5.7.10 Pregunta 10: Estimación de recursos asignados al proyecto.
CAPITULO VI: Propuesta del modelo de administración de
proyectos de desarrollo de software con equipos autodirigidos
105
6.1 Introducción 105 6.2 Propuesta del diseño 105 6.3 Descripción del modelo 107 6.3.1 Iniciación 107 6.3.2 Planeación 108 6.3.3 Ejecución 111 6.3.4 Control 112 6.3.5 Cierre 113 6.4 Equipo autodirigido 114 6.5 Comentarios adicionales sobre el diseño propuesto 118CAPITULO 7: Conclusiones 119
Trabajos Futuros 121
Anexo 1 123
Determinación estadística de la muestra 123
Anexo 2 125
Sección I 125
Sección II 127
Sección III 128
Sección IV 130
Bibliografía 135
ÍNDICE DE TABLAS
Tabla 4.1 Lista de posibles empresas a encuestan 50 Tabla 4.2 Muestra representativa de la población 51 Tabla 4.3 Escala de calificación sección 1 53 Tabla 4.4 Agrupación de respuestas sección 2 55 Tabla 5.1 Grado de confianza en el equipo autodirigido 73 Tabla 5.2 Grado de apertura en equipos autodirigidos 75 Tabla 5.3 Grado de compromiso en equipos autodirigidos 77 Tabla 5.4 Grado de colaboración en equipos autodirigidos 79 Tabla 5.5 Resultados sección 4 pregunta 1 84 Tabla 5.6 Resultados sección 4 pregunta 2 85 Tabla 5.7 Resultados sección 4 pregunta 3 86 Tabla 5.8 Resultados sección 4 pregunta 4 '. 87
ÍNDICE DE FIGURAS
Figura 1.1 Las fuerzas que influyen en un proyecto 2 Figura 1.2 Áreas de conocimiento y procesos
ÍNDICE DE GRÁFICAS
Gráfica 5.1 Tipo de liderazgo deseado para equipos 71 Gráfica 5.2 Confianza de los equipos de trabajo 72 Gráfica 5.3 Grado de Confianza en el proceso 73 Gráfica 5.4 Grado de apertura a sentimientos 74 Gráfica 5.5 Grado de apertura al descubrimiento 74 Gráfica 5.6 Grado de compromiso con la misión individual 76 Gráfica 5.7 Grado de compromiso con la misión del equipo 76 Gráfica 5.8 Grado de colaboración en los equipos de trabajo 78 Gráfica 5.9 Grado de colaboración en el sistema de trabajo 78 Gráfica 5.10 Porcentaje de liderazgo utilizado
en los equipos de trabajo 80 Gráfica 5.11 Porcentaje de monitoreo y
retroalimentación utilizado 81 Gráfica 5.12 Porcentaje de formas de organización
de equipos de trabajo utilizadas 82 Gráfica 5.13 Porcentaje de autonomía y
CAPITULO 1: La administración de proyectos
1.1 Introducción.
El proceso que implica el seguimiento y control de tareas interrelacionadas para llegar a un objetivo previamente definido, conocido en la administración moderna como administración de proyectos, es uno de los principales temas a tratar en esta investigación, por esta razón, definiremos esta área de estudio, para comprender el entorno de esta disciplina.
1.2 Evolución de la disciplina.
La mayoría de los grandes logros de la humanidad, como las pirámides egipcias, la muralla China, o la bomba atómica, pueden ser designados como proyectos exitosamente terminados, y que fueron logrados, en cierta forma, por la administración de proyectos. Esto nos da una idea clara que, la administración de proyectos ha estado presente desde hace tiempo, ya que siempre ha existido una necesidad imperante de dirigir de alguna manera las actividades necesarias para obtener un producto o servicio. Al respecto Kimmons y Loweree (1989) dicen: "Desde hace tiempo la administración de proyectos ha servido de apoyo para llevar a cabo tareas que producen un resultado tangible".
1.3 Qué es un proyecto.
Para comprender lo que la administración de proyectos implica y tener una visión amplia de las labores que se desempeñan durante un proyecto, se muestran algunas definiciones que aclaran el concepto.
Gaddis (1991) define un proyecto como "una unidad organizacional dedicada a la culminación de una meta generalmente la terminación exitosa de un producto desarrollado en el tiempo, dentro del presupuesto, y en cumplimiento con unas especificaciones predeterminadas." A este respecto el Instituto de Administración de Proyectos (PMI por sus siglas en inglés) (1996), tiene un concepto más simplificado, "una labor temporal que se lleva a cabo para crear un producto o servicio único". Es temporal porque debe tener un inicio y un fin claramente definidos.
[image:18.612.197.400.453.653.2]Según Kerzner (2000), cualquier proyecto esta influenciado por tres factores cuyo efecto o impacto es directo, y el resultado exitoso depende de la habilidad del administrador para compensar la carencia de alguno, en la figura 1.1 se muestran dichos factores.
Como se puede ver hay un cuarto factor que generalmente se encuentra implícito dentro de todo proyecto, este factor es la calidad, generalmente el tiempo, el costo y los recursos pueden ser sacrificados hasta cierto punto donde se pueda lograr un equilibrio, pero la calidad no puede ser sacrificada, ya que es indispensable su existencia para la culminación satisfactoria de un proyecto.
Otra definición, muy similar a las anteriores, es la de Meredith y Mantel (1985), quienes explican el concepto de proyecto como una actividad única con un conjunto de resultados finales esperados muy bien definidos. Puede ser dividido en subtareas que deben ser completadas para lograr las metas del proyecto.
Como resultado del análisis de estas definiciones, es claro que cada proyecto tiene un tiempo establecido para su realización, durante el cual se pueden definir etapas que se llevan a cabo desde la concepción hasta la culminación del mismo. Kimmons (1990) define 4 etapas (pueden existir etapas intermedias dentro de cada una de éstas):
1. Etapa conceptual: Se concibe el proyecto, se identifican las necesidades y se desarrollan las posibles soluciones.
2. Etapa de implementación: Es donde se llevan a cabo las actividades de la administración del proyecto.
3. Etapa operacional: El producto ha iniciado su fase operacional y la capacitación para el cliente.
4. Etapa de abandono: Culmina la vida del proyecto.
Los beneficios obtenidos de estas revisiones son diversos, tanto para los administradores, como para los miembros del equipo de trabajo y la organización. Específicamente permite hacer lo siguiente:
1. Identificar qué salió bien y qué salió mal: Una revisión no se trata únicamente de identificar e investigar los errores. Si un enfoque en particular ha funcionado bien, o si alguno de los elementos involucrados han logrado buenos resultados o un alto desempeño, conformen la base para llevar a cabo la etapa de retroalimentación.
2. Prevenir de que los errores no sean repetidos: En cualquier proyecto, algunas cosas saldrán mal y la mayoría de las veces no son percibidas la primera vez que ocurren. Al tomarse el tiempo en la fase de revisión para entender qué ha sucedido y porqué, se comprenden situaciones que de otra forma no se tomarían en cuenta o pasarían desapercibidos. La próxima vez, los errores serán más predecibles y consecuentemente se evitarán con mayor facilidad.
3. Motivar a los miembros del equipo: A las personas les gusta conocer su desempeño, especialmente cuando ponen mucho esfuerzo en un proyecto. La fase de revisión debe incluir un resumen del rendimiento de cada persona. Es importante aclarar a los miembros del equipo con anticipación que serán evaluados y el criterio que será aplicado para dicha evaluación.
4. Estimular ideas para futuros proyectos: La fase de revisión debe evaluar tanto el proceso como los resultados del proyecto. Durante el trabajo del proyecto, los miembros del equipo pueden haberse dado cuenta de puntos que no fueron totalmente cubiertos, o áreas donde se requiera trabajo similar.
1.4 La disciplina de la administración de proyectos.
La administración de proyectos de acuerdo con Meredith y Mantel (1985), tiene un propósito básico que es el de iniciar un proyecto para completar ciertas metas. La razón para organizar las tareas como un proyecto es enfocar la responsabilidad o autoridad para llevarlas a cabo por un individuo o un pequeño grupo.
Al respecto, Kimmons y Loweree (1989) opinan que la administración de proyectos moderna es la aplicación del enfoque sistémico a la administración de tareas y proyectos tecnológicamente complejos cuyos objetivos son explícitamente establecidos en términos de tiempo, costo y parámetros de rendimiento.
Kerzner (1982) nos dice que es la planeación, organización, dirección y control dé los recursos de la compañía para objetivos de, relativamente, corto término que han sido establecidos para completar objetivos y metas específicas. Utiliza un enfoque sistémico a la administración teniendo personal funcional (la jerarquía vertical) asignados a un proyecto específico (la jerarquía horizontal).
Pero la administración de proyectos no se refiere propiamente a un solo proyecto, Dobson (1999) dice que un proyecto puede formar parte de un conjunto de proyectos (portafolio de proyectos) donde cada proyecto se considera como una tarea (de la misma forma que un proyecto esta conformado por tareas) y todos estos proyectos son diferentes en tiempo o tamaño.
Un enfoque diferente de la administración de proyectos propuesto por Barkley y Saylor (1994), involucra el concepto de calidad total y esta dirigido hacia el cliente, se le denomina CDPM (Administración de proyectos dirigida al cliente por sus siglas en inglés), el cual permite actuar y reaccionar frente a las fuerzas económicas del mundo actual, es decir, la organización se enfoca en determinar y actuar con las fuerzas internas o externas que influyen en el cliente, tomando como base la calidad total, para lograr su total satisfacción. Demarco y Lister (1999) difieren de este enfoque argumentando que, durante la ejecución de un proyecto la calidad implica dos cosas: tiempo y dinero, el cliente espera ver resultados casi inmediatos y concluyen en base a la experiencia que, en la mayoría de los casos, la calidad es sacrificada debido a que el cliente desea su producto lo más pronto posible.
Como se puede observar, esta disciplina es muy amplia ya que esta conformada de diversas áreas, cada una de las cuales ocupa un lugar importante dentro del proceso de administración, y funcionan como un complemento de una con la otra.
1.5 Áreas y procesos que conforman la disciplina.
Para tener una visión amplia y bien definida de las diversas áreas que implica la administración de proyectos, las englobaremos de acuerdo a la clasificación del estándar internacional del Project Management Institute. Las áreas de conocimiento de la administración
Administración de Proyectos
Administración de la integración del proyecto.
Desarrollo del plan del proyecto.
Ejecución del plan del proyecto.
Control general de cambios.
Administración del costo del proyecto.
Planeación de recursos. Estimación de costos. Presupuesto de costos. Control de costos.
Administración de la comunicación del proyecto
Planeación de las comunicaciones. Distribución de la información.
Reporte del rendimiento. Acercamiento
administrativo.
Administración del alcance del proyecto.
Iniciación.
Planeación del alcance. Definición del alcance. Verificación del alcance. Control de cambios del alcance.
Administración de la calidad del proyecto.
Planeación de la calidad. Aseguramiento de la calidad.
Control de la calidad.
Administración del riesgo del proyecto.
Identificación del riesgo. Cuantificación del riesgo. Desarrollo de respuesta al riesgo.
Control de respuesta al riesgo.
Administración del tiempo del proyecto.
Definición de actividades. Secuencia de actividades. Estimación de la duración de actividades.
Desarrollo de la agenda. Control de la agenda.
Administración de los recursos humanos del proyecto.
Planeación organizacional. Adquisición del personal. Desarrollo del equipo.
Administración de adquisiciones del proyecto. Planeación de adquisiciones.
Planeación de solicitudes. Solicitudes.
Selección del origen. Administración de contratos. Clausura del contrato
Figura 1.2 Áreas de conocimiento y procesos de la administración de proyectos (PMI,
[image:23.612.84.521.64.664.2]• Administración de la integración: Describe los procesos requeridos para asegurar que los diversos elementos del proyecto estén propiamente coordinados:
• Administración del alcance: Describe el proceso necesario para asegurar que el proyecto incluye todo el trabajo, y solo el trabajo requerido, para completar el proyecto exitosamente.
• Administración del tiempo: Describe el proceso requerido para asegurar la terminación del proyecto a tiempo.
• Administración del costo: Describe el proceso requerido para asegurar que el proyecto sea completado dentro del presupuesto aprobado.
• Administración de la calidad: Describe el proceso requerido para asegurar que el proyecto satisfaga las necesidades para las que fue llevado a cabo.
• Administración de los recursos humanos: Describe el proceso requerido para hacer el uso efectivo de la gente involucrada en el proyecto.
• Administración de la comunicación: Describe el proceso requerido para asegurar a tiempo y apropiadamente la generación, recolección, diseminación, almacenamiento y disposición de la información del proyecto.
• Administración del riesgo: Describe el proceso concerniente con la identificación, análisis y respuesta a los riesgos del proyecto.
• Administración de adquisiciones: Describe el proceso requerido para adquirir bienes y servicios del exterior de la organización.
Cada una de estas áreas recibe igual importancia durante todo el ciclo de vida del proyecto y cualquier error impacta directamente en el desarrollo del mismo.
• Procesos de administración de proyectos: Se refieren a la descripción y organización del trabajo del proyecto. Estos procesos son aplicables a la mayoría de los proyectos.
• Procesos orientados a productos: Se refieren a la especificación y creación del producto del proyecto. Estos procesos están definidos en el ciclo de vida del proyecto y varia de acuerdo al área de aplicación.
Ambas clasificaciones de procesos se traslapan e interactúan durante el proyecto. Los procesos de la primera clasificación pueden ser organizados en cinco grupos de uno o más procesos cada uno, la figura
1.3 muestra los procesos y la relación existente entre ellos.
Proceso de
Inicialización Procesos deplaneación
Figura 1.3 Relación existente entre los procesos.
El propósito de cada uno de estos procesos se describe a continuación:
• Procesos de iniciación: Reconocer que un proyecto o fase debe iniciar y comprometerse a llevarlo a cabo.
• Proceso de planeación: Diseñar y mantener un esquema de trabajo para cumplir con las necesidades del negocio que el proyecto pretende alcanzar.
[image:25.612.108.474.290.457.2]• Proceso de control: Asegurar que los objetivos del proyecto se cumplan, monitoreando y midiendo el progreso y tomando acciones correctivas cuando sea necesario.
• Proceso de cierre: Formalizar la aceptación del proyecto o fase para llevarlo a su conclusión.
Los procesos están presentes en toda organización, e influyen directamente en su operación, la administración de proyectos es uno de los procesos más importantes ya que juega un papel importante en su desempeño. Así, el proceso de administración de proyectos adquiere gran relevancia al ser un indicador de cómo se esta realizando el trabajo en la organización.
1.6 Situación actual y su importancia dentro de la organización.
El éxito de un proyecto esta influenciado fuertemente por el ambiente organizacional que lo rodea. Algunos factores organizacionales mejoran las oportunidades de éxito de un proyecto, mientras que otros lo amenazan. Un administrador experimentado tomará ventaja de los factores positivos que puedan existir, y tratará de compensar cualquier factor negativo que sea inevitable.
Kimmons y Loweree (1989) definen seis factores organizacionales que afectan el éxito de un proyecto: Estructura, equipos laborales, relaciones con los clientes, actitud hacia el riesgo, comunicación y expectativas.
La oportunidad de que un administrador de proyectos tenga éxito se incrementa considerablemente si comprende cómo la organización influye en los proyectos. Necesita identificar las características que le serán útiles y aquéllas que actuarán en su contra, definir claramente las diferentes amenazas al proyecto de acuerdo a su importancia, para establecer acciones que contrarresten esas amenazas.
Los administradores generales pueden mejorar el éxito de todos los proyectos, reconociendo las diferentes formas en que la organización afecta a los proyectos y a los administradores de proyectos. Necesitan dar la atención adecuada a cada nuevo proyecto desde sus inicios y su interacción con otros proyectos, de forma que los problemas por más insignificantes, deben ser atendidos antes de que se conviertan en un problema mayor.
Los proyectos operan en ambientes que pueden afectar seriamente el rendimiento, el costo y la agenda. De hecho, la forma en que el administrador de proyectos trabaje con el ambiente puede ser la diferencia entre cumplir con el objetivo definido o no.
1.7 El papel del administrador de proyectos.
Como se ha mencionado, en el proceso de administración de proyectos, existe un individuo encargado de dirigir y dar seguimiento a las actividades que se realizan durante su ejecución, cuya responsabilidad es la de llevar el proyecto a una culminación exitosa.
La tarea del administrador de proyectos es una labor interesante pero a la vez con un alto grado de responsabilidad, Freeherry y Ciprian (1997) opinan que administrar un proyecto puede ser una experiencia retadora y satisfactoria. Pero puede ser frustrante y destructiva si no se esta preparado para la incertidumbre y los cambios no anticipados que son inevitables en la vida de la mayoría de los proyectos hoy en día.
Por lo anterior, es evidente que este rol debe ser desempeñado por una persona que reúna ciertas características, Kimmons y Loweree (1989) definen una lista de cualidades que debe tener un administrador de proyectos:
• Reconocido líder con habilidades organizacionales. • Amplia experiencia en proyectos relacionados. • Habilidad para trabajar y comunicarse con otros.
• Habilidad para coordinar tanto funciones simples como complejas. • Habilidad para obtener el máximo de su equipo de trabajo.
• Sensitivo a la relaciones humanas, incluyendo el intercambio de personal.
• Total conocimiento de los recursos, sistemas y procedimientos de su compañía.
• Habilidad para desarrollar y mantener relaciones favorables con el cliente.
Y hacen especial mención las 4 características que consideran más importantes, líder de equipo, relación con los clientes, planes de contingencia, organización para el proyecto. Por otra parte, en un administrador de proyectos recaen muchas responsabilidades, Lester (1982) define las siguientes tres:
1. Debe estructurar el trabajo de acuerdo a las especificaciones para satisfacer los requerimientos operacionales.
2. Debe completar el proyecto a tiempo.
Es obvio que las dos últimas están estrechamente interconectadas, ya que es más sencillo obtener un incremento extra en el presupuesto por parte del cliente, si los avances que se han presentado están dentro de los tiempos establecidos y el presupuesto no se ha excedido de lo que originalmente se estableció. También es necesario mencionar que estas responsabilidades definidas anteriormente, pueden diferir en gran escala de una industria a otra o de una estructura organizacional a otra, debido al amplio alcance que cubre dicha posición.
Es evidente que el administrador de proyectos es el elemento clave del equipo de trabajo. No sólo debe administrar el proyecto, sino también delegar y coordinar las actividades, manteniéndolas de acuerdo al programa establecido. A través de la comunicación, oral y escrita, junto con visitas y juntas, se encuentra totalmente al tanto de las operaciones. Evalúa el trabajo actual y lo efectuado para evaluar y hacer proyecciones a futuro. Además, es el encargado de iniciar y dar seguimiento a cualquier medida correctiva para asegurarse de su efectividad.
Como se puede observar la efectividad del administrador de proyecto puede resumirse en tres elementos clave, que cumplan con la agenda, dentro del presupuesto y con un buen rendimiento. Lo contrastante de esta situación es que en su mayoría los proyectos se terminan tarde, sobre el presupuesto y debajo del rendimiento esperado.
Dentro de las habilidades del administrador de proyectos, una de las principales, es la del liderazgo, ya que estará a cargo de varios elementos de un equipo de trabajo, donde el enfoque humano es el principal factor para una culminación exitosa del mismo.
Kimmons y Loweree (1989) "el administrador de proyectos debe, proveer un tipo diferente de administración ejecutando su autoridad y comunicación con su equipo de trabajo de tal forma que ellos reciban el mensaje apropiado en el momento justo", para ello definen 4 áreas de particular interés:
• Rango de Autoridad: La cual es definida por el administrador general y el cual debe definir los niveles de autoridad que serán delegados al administrador de proyecto y a los administradores funcionales. Y dependiendo de la estructura organizacional (funcional o matricial) será el tipo de autoridad ejercida por el administrador de proyectos.
• Habilidades de comunicación: El administrador de proyectos y sus subordinados clave necesitan comunicación constante y habilidades para relacionarse para así desarrollar grupos de trabajo con una alta cohesión.
• Uso del poder percibido: Una cualidad importante de un administrador de proyectos, se define como la habilidad que tiene de producir una percepción de autoridad en su equipo de trabajo, haciendo que éstos "perciban" más autoridad de la que tiene.
Este poder o autoridad, debe ser utilizado con cautela, ya que se puede caer en extremos que resultarán perjudiciales para el equipo de trabajo. Al respecto Demarco y Lister (1999) opinan que el administrador de proyectos puede estar presionando arduamente a su gente, esto produce una ilusión de incremento en la productividad (y de hecho si se incrementa) en el corto plazo, pero puede ser ineficiente a largo plazo: "No hay nada más desalentador para cualquier trabajador que el sentir que su propia motivación es inadecuada y tiene que ser "sustituida" por parte de su superior".
El administrador de proyecto es un rol que requiere una gran experiencia así como características muy específicas en el individuo que lo desempeña, debe realizar varias actividades para dirigir el curso del proyecto, por otra parte debe fungir como moderador y líder entre los diversos elementos del equipo de trabajo, esta última función puede ser un factor determinante en el éxito o fracaso del proyecto.
1.8 Conclusiones
Las diversas áreas y procesos que conforman la disciplina, juegan un papel importante en el desarrollo del proyecto, por lo que el control constante de cada una de ellas debe ser una de las prioridades para el equipo del proyecto, para corregir desviaciones que puedan afectar el presupuesto o el tiempo destinados para realizar el proyecto, los cuales son los factores principales que conllevan a una terminación no exitosa.
CAPITULO 2: Desarrollo de software
2.1 Introducción.
Los proyectos sobre los que esta enfocada esta investigación son del área de desarrollo de software, esta área se conforma de métodos y modelos a seguir para crear un producto de software, utilizando diversas técnicas de análisis y diseño, así como técnicas de programación.
Con el fin de establecer las bases para el desarrollo del marco teórico es pertinente primeramente definir algunos términos básicos en cuanto al desarrollo de sistemas, dichos conceptos se describen a continuación (Diccionario de la Lengua Española):
• Sistema: "Conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a determinado objeto".
• Programa: Una definición podría ser "serie ordenada de actividades necesarias para llevar a cabo un proyecto", esta definición es muy general por lo que es necesaria una enfocada a programas computacionales, la cual sería "el conjunto de instrucciones que permiten a una computadora realizar determinadas operaciones".
• Sistema Computacional: Programa(s) que controlan y soportan las operaciones de una computadora. Regularmente compuesto de uno o más de los siguientes elementos: sistema operativo, base de datos, programas de control de comunicaciones, programas de servicio y utilerías, compilador o traductor de lenguaje máquina. • Software: Se refiere a la colección de programas, datos, diseño
de programas, especificaciones y toda otra información relevante de un sistema. Esta definición coincide con la de sistema computacional, para efectos de esta investigación serán utilizados como sinónimos.
Para el desarrollo de un sistema existen tres áreas básicas:
1. La representación del sistema: Incluye programas, diseños detallados, la estructura del sistema representada en diagramas de flujo de datos, diccionarios, diagramas y toda información que de alguna manera representa un conjunto de programas y los datos asociados a éste se deben incluir en esta representación.
2. Conocimiento de ingeniería de software: Toda la información referente al desarrollo de un sistema, cómo utilizar un método específico de diseño, técnicas de desarrollo, herramientas, etc. Es la disciplina que involucra una serie de procedimientos, métodos y herramientas para llevar a cabo el desarrollo de software.
3. Conocimiento específico del área de enfoque del desarrollo:
Un conocimiento más que superficial de los conceptos relacionados al área específica en la que se va a utilizar el desarrollo es esencial para la adecuada aplicación de un sistema. Es decir, si se desarrolla un sistema contable, es muy deseable contar con dichos conocimientos.
Este capítulo esta enfocado en describir la segunda área, ya que es esta la que define formalmente los procedimientos, métodos, herramientas y modelos a utilizar durante un desarrollo, por lo que se describirán los más utilizados para la creación de productos de software.
2.2 Enfoques en ingeniería de software.
Históricamente han surgido varios enfoques que buscan abordar la planificación, análisis, diseño e implementación de los proyectos de desarrollo de software, sean estos de gran escala o pequeñas aplicaciones, software a la medida o comerciales.
Un aspecto central en el análisis, es la relación del enfoque con el área del problema a resolver, ya que es dicha relación (en muchos casos deficiente) la que determina el desarrollo adecuado del producto. Esta visión está dada, principalmente, para aquella clase de problemas que se solucionan mediante una aplicación a la medida, donde hay un usuario (el experto en el problema) y como contraparte un desarrollador quien es el encargado de modelar el problema como un software.
Así, para hacer esta revisión, el análisis se centrará en los métodos y se extraerán de ellos las conclusiones que permitan obtener una visión sobre las limitaciones que éstos presentan. Básicamente se expondrá el enfoque de manera general, como una guía al desarrollo.
2.3 El modelo de codificar y fijar.
El primer modelo que realmente no representa ningún uso de métodos y modelos de la ingeniería de software, ni algún tipo de planeación para el desarrollo de software. Este modelo básico, utilizado en los primeros días del desarrollo de software, tiene dos pasos: Escribir algún código y posteriormente fijar los problemas en el código.
Este método resume las características de los métodos más formales desarrollados posteriormente, primero, la desvinculación con el problema: hay, de inicio, dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa.
Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos.
Farley (1988) dice al respecto: "En el sentido real, el ingeniero de programación crea modelos de situaciones físicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solución computacional del problema. Un principio fundamental de la ingeniería de programación es diseñar productos que minimicen la distancia intelectual entre el problema y la solución".
Y pese a que hay claridad en el problema (minimizar la distancia intelectual entre el problema y la solución) no existiría aún un método que permita asegurar esto, por ejemplo, Farley continúa: "...empero, la variedad de enfoques en el desarrollo de programas está limitado únicamente por la creatividad e ingenio del programador; no siempre se encuentra con claridad el enfoque que minimice esta distancia, e incluso diferentes enfoques minimizan distintas dimensiones de la distancia."
Pero, por otro lado, la primera evolución en relación a los métodos es el resultado de las deficiencias del método de codificar y fijar. Es
2.4 El modelo de etapas.
El enfrentarse a un gran sistema de desarrollo de software hizo que se reconocieran los problemas Inherentes a la codificación y esto llevó al desarrollo del modelo de etapas. El modelo estipula que el desarrollo se realizará en etapas sucesivas:
• Plan operativo. Se define el problema a resolver, las metas del proyecto y se identifica cualquier restricción aplicable al proyecto.
• Especificación de requerimientos. Permite entregar una visión de alto nivel sobre el proyecto, poniendo énfasis en la descripción del problema desde el punto de vista de los clientes y desarrolladores. También se considera la posibilidad de una planificación de los recursos sobre una escala de tiempos.'
• Especificación funcional. Especifica la información sobre la cual el software a desarrollar trabajará.
• Diseño. Describe como el sistema va a satisfacer los requerimientos. A menudo tiene diferentes niveles de detalle, los niveles más altos generalmente describen los componentes o módulos que conformarán el software y los más bajos describen, con mucho detalle, cada módulo del sistema.
• Implementación. Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño del proyecto, la programación puede ser distribuida, donde cada parte se concentrará en la construcción y prueba de una parte del software (subsistema). Las pruebas tienen por objetivo asegurar que todas las funciones están correctamente implementadas dentro del sistema.
Validación y verificación. Inicia una vez que el sistema ha sido integrado. Es donde es probado para verificar que es consistente con la definición de requerimientos y la especificación funcional. La verificación consiste en una serie de actividades que aseguran que el software implementa correctamente una función específica. Al finalizar esta etapa, el sistema ya puede ser instalado.
Mantenimiento. Ocurre cuando hay algún problema dentro de un sistema existente, e involucraría la corrección de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementación del sistema y cambios para que responda a los nuevos requerimientos. El mantenimiento se puede clasificar en: correctivo, adaptativo, perfectivo y preventivo.
Especificación de Requerimientos
Especificación Funcional
Verificación y Validación
Definición del problema y establecimiento de proyecto de desarrollo.
Visión profunda del problema desde el punto de vista de desarrolladores y usuarios.
Específica la información sobre la cual el software a desarrollar trabajará.
Permite describir como el software va a satisfacer los requerimientos.
Aquí es donde el software a ser desarrollador se codifica.
Es la parte donde todos los módulos codificados independientemente se integran.
Etapa en donde el software es probado para verificar si es consistente con las definiciones.
Modificaciones del software que sean producto de errores, adecuaciones, etc.
[image:38.614.115.512.277.667.2]El modelo de etapas consideraba que deberían ser consecutivas, poniendo énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificación y de control. Todo para conformar una cadena de producción de software como se muestra en al figura 2.1.
Pero ello no logra que las causas que hicieron que se replanteara el modelo de codificar y fijar desapareciera. Todavía existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia está dada por dominios de acción distintos, (válido también para el método de cascada que se explica más adelante). La iteración de aproximación es ahora más factible, pero también resulta compleja, ya que es necesario instalar todo el software nuevamente en la cadena de montaje para su revisión y reconstrucción.
2.5 El modelo de cascada o ciclo de vida clásico.
Es un refinamiento altamente influenciado del modelo de etapas. Para este modelo, existe un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del trabajo repetido involucrado en retroalimentaciones a través de muchas etapas, el modelo se muestra en la figura 2.2.
Especificación de Requerimientos
Especificación Funcional
Verificación y Validación
Mantenimiento
Figura 2.2 Modelo Cascada (Pressman, 2000).
Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la especificación de los problemas. Ambos métodos asumen que el diseñador puede distinguir entre lo que el sistema debe hacer y como lo hará; pero algunos problemas no pueden ser divididos tan fácilmente para ser atacados desde este prisma.
[image:40.613.105.508.66.378.2]Otro factor importante es que estos métodos asumen que una vez que los requerimientos han sido definidos entonces ellos no cambiarán más. Pero, dependiendo de la complejidad del proyecto, la implementación final puede ocurrir meses o, eventualmente, años después de que los requerimientos han sido especificados; así, en las últimas etapas del proyecto, los requerimientos pueden haber cambiado.
Existiría un énfasis en la elaboración de documentos. El sistema completo es descrito y registrado en papel, cada etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las especificaciones de requerimientos pueden ser de cientos de páginas, explicando todos o cada uno de los detalles del sistema. Y es difícil poder visualizar, desde éste nivel, las características del sistema.
Por último, se ha detectado que el enfoque lineal de estos métodos no sería el adecuado para reflejar el proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clásico los lleva a seguir las etapas en orden incorrecto. Más aún, es posible que todas las etapas del proyecto, estén comprimidas dentro de cada una.
2.6 El desarrollo orientado a prototipos.
Si bien algunos autores consideran que esto es parte del ciclo de vida clásico como Boehm (1990), es también posible verlo como un método independiente. Una definición de un prototipo en software podría ser: "...es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas".
Las fases que comprende este método de desarrollo serían:
• Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización e identificar una idea general de la solución para realizar un estudio de factibilidad, para determinar qué tan factible es una solución de software.
• Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo, esta etapa será revisada posteriormente con más detalle.
• Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar que son correctos y que cumplen con los requerimientos definidos anteriormente.
• Operación y mantenimiento. La instalación del sistema en ambiente de producción, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos, por lo tanto el sistema ya ha sido utilizado y sólo requiere de la actualización a la última versión.
El mantenimiento debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriere un mantenimiento, entonces el proceso de prototipo es repetido y se definirá un nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar los requerimientos del usuario al desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
• Análisis profundo y especificación. El propósito de esta sub fase es desarrollar un diseño básico para el prototipo inicial.
• Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interfase del usuario.
El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.
• Modificación. Esto ocurre cuando la definición de requerimientos del sistema es alterada en la subfase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
• Término. Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación con aspectos de calidad y de representación del sistema.
En la figura 2.3 se puede ver el esquema en que estas etapas se realizan, la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión de la solución final en etapas tempranas del desarrollo, previniendo costos producidos por especificaciones erróneas.
Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por: reducción de la incertidumbre y del riesgo, reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema, mejoras en la administración de proyectos, mejoras en la comunicación entre desarrolladores y clientes, etc.
Investigación
Preliminar • •i Definición del problema, sus^ organizacionales. Estudio de factibilidad.
efectos
Análisis y Especificación ?; Diseño Básico del Prototipo.
Construcción del Prototipo Inicial.
Diseño y Construcción
Evaluación
Modificación
Verificación y Requerimientos.
Modificación del Prototipo.
Especificación de Requerimientos y Prototipado
Diseño Técnico
Programación y Prueba
Operación y Mantenimiento
Diseño Detallado. Rediseño del Prototipo y documentación para Programación v Mantenimiento.
Las especificaciones del Diseño Técnico son implementadas y probadas.
Instalación del sistema y modificaciones posteriores.
Figura 2.3 Modelo de desarrollo orientado a prototipos (Pressman, 2000).
También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.
[image:45.613.80.519.65.471.2]Por último, el proceso de iteración para que sea efectivo debería ser infinito, lo que lo hace poco efectivo. Es decir, mediante este método acercamos la problemática de los usuarios a los dominios de los desarrolladores y viceversa, pero no sería posible unir ambos dominios, lo que sería el ideal.
2.7 El modelo de desarrollo evolutivo.
El desarrollo evolutivo es una metodología de desarrollo de software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El énfasis esta puesto sobre la importancia de obtener un sistema de producción flexible y expandible. Así, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mínimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendría la propiedad de satisfacer los nuevos requerimientos lo más rápido posible. En contraste, el modelo de prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto, el tiempo tomado entre cada iteración es más importante para el desarrollo evolutivo. En la figura 2.4 se puede ver gráficamente esta diferencia.
La ¡dea entonces de la metodología de desarrollo evolutivo es estar liberando constantemente una nueva versión del sistema que sea completamente funcional; cada sistema producto de las iteraciones sucesivas tendría incorporado los nuevos requerimientos que han sido posible identificar y que no estarían considerados en la versión anterior.
Investigación Preliminar
Desarrollo del Producto
Implementación, Uso y Evaluación
Definición del problema y especificación inicial en base a los requerimientos definidos.
Desarrollo del software en base a un proceso con énfasis en la rapidez de la fabricación.
Implantación y uso del software en ambiente de explotación, monitoreo de los nuevos reauerimientos.
Versiones del Software
Volver a realizar
[image:47.614.86.517.167.451.2]especificaciones Redefinición del problema en base a los nuevosrequerimientos.
Figura 2.4 Modelo de Desarrollo Evolutivo (Pressman, 2000).
Así, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de un producto de software operacional, en las direcciones determinadas por la evolución de la experiencia operacional.
Pero existen algunas dificultades técnicas que no pueden dejar de ser mencionadas, por ejemplo:
• No facilita la integración de aplicaciones que han sido desarrolladas como sistemas independientes.
• Facilita la posibilidad de que existan casos de "esclerosis de información", en el sentido que trabajos temporales alrededor de algunas deficiencias del software se solidifican como poderes inmodificables a la evolución. Es decir, en la medida que se evoluciona, esta misma facilidad a la evolución llevaría a que no sea posible seguir evolucionando.
• Puede ocurrir que el software nuevo es un reemplazo incremental de un subsistema dentro de un gran sistema existente. Si el sistema existente está pobremente modularizado, es obvia la dificultad en hacer que la nueva versión se acople al resto.
El método evolutivo tiene la gran ventaja de reconocer la existencia de constantes cambios en los requerimientos, a partir de esto, proponer una solución, la cual es válida para la solución de ese problema pero que no resolvería la inquietud original, esto es que el método no facilita elementos que permitan reducir la distancia conceptual entre el desarrollador y el usuario.
Lehman también propone que la evolución de un sistema de software esta sujeta a 5 leyes, las cuales ha determinado a partir de observaciones experimentales de varios sistemas, como los grandes sistemas operativos:
1. Cambio Continuo. Un programa utilizado en un ambiente del mundo real debe cambiar o cada vez será menos útil en ese ambiente.
2. Complejidad creciente. A medida que un programa en evolución cambia, su estructura se hace más compleja, a menos que se lleven a cabo esfuerzos activos para evitar este fenómeno.
3. Evolución del programa. La evolución del programa es un proceso autorregulador, y una medición de atributos del sistema, como el tamaño, el tiempo entre versiones, el número de errores advertidos, etc., revela las tendencias estadísticas significativas y las características invariantes.
4. Conservación de la estabilidad organizativa. Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi constante e independiente de los recursos dedicados al desarrollo del sistema.
5. Conservación de la familiaridad. Durante el tiempo de vida de un sistema, la evolución del cambio del sistema en cada versión es, aproximadamente, constante.
2.8 Modelo Espiral.
El modelo espiral de Boehm para Ingeniería de Software agrupa las mejores características del modelo del ciclo de vida clásico y de prototipos. Pero también agrega nuevas funciones que no están incluidas en los otros modelos, como el análisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida.
• Análisis de Riesgo. El análisis de alternativas y la identificación y solución de riesgos.
• Ingeniería. Desarrollo del producto.
• Evaluación del cliente. El asentimiento de los resultados.
El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteración comienza en el centro del círculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones más completas del software que está siendo construido. Al principio de cada iteración del ciclo de vida se hace un análisis de riesgo, mientras, por el otro extremo, la revisión del proyecto se realiza al final de la iteración. Así, se puede contrarrestar cualquier riesgo observado en el tiempo preciso.
El modelo espiral es visto como un enfoque más realista para el desarrollo de grandes sistemas de software. Usa un método evolutivo para desarrollo y prototipos como una técnica de reducción de riesgo (pese a que los prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). También utiliza el enfoque de sistematización y el "desarrollo en etapas" del ciclo de vida clásico, pero, con la diferencia que todos están incorporados dentro del esquema iterativo planteado por el modelo espiral.
2.9 Modelo Orientado a Objetos.
• Clases. • Herencia. • Polimorfismo.
• Sobrecarga de métodos y operadores, etc.
Y como consecuencia, un aumento de la integridad del sistema. El costo de contar con un equipo experimentado en dicha técnica de programación es considerablemente mayor que en las anteriores.
Figura 2.5 Modelo orientado a objetos (Somerville, 2000).
Las características del modelo orientado a objetos son:
• No se preescribe una secuencia lineal de pasos.
• El desarrollo es iterativo e incremental combinando diagramas formales con técnicas informales según el problema.
• Existen micro y macro fases.
• Combinación del modelo de cascada y el modelo de espiral. • Macroproceso.
• Es similar al modelo de cascada y sirve como marco de control para el microproceso.
• Establecer requerimientos esenciales (conceptualización).
• Desarrollar un modelo del comportamiento esperado (análisis). • Crear una arquitectura (diseño).
[image:51.612.103.505.211.398.2]El modelo orientado a objetos es el más novedoso, revolucionario y utilizado en los últimos años, su auge ha crecido exponencialmente, debido a las características tan particulares que posee, lo cual lo ha convertido en la base para prácticamente todos los lenguajes de programación.
2.10 Conclusiones.
Los diversos modelos existentes para el desarrollo de software son aplicables en la mayoría de los proyectos cuya finalidad es la creación de un producto de software. Debido a que cada uno cuenta con características propias, dependerá de las necesidades del cliente para utilizar el modelo adecuado.
Ciertamente los modelos son presentados en su estado más básico, por lo que cada organización puede adaptarlos o modificarlos de acuerdo a los requerimientos específicos del producto a desarrollar, es importante que estás modificaciones no alteren la base del modelo, debido a que esto puede ocasionar problemas en el desarrollo ya que la solución utilizada puede ya no ser la requerida en el proyecto para el cual fue elegida inicialmente.
CAPITULO 3: Los equipos autodirigidos
3.1 Introducción.
En cualquier organización, para llevar a cabo una tarea, generalmente se trabajan en agrupaciones de personas que persiguen un objetivo común, que se conoce como equipo. Esta forma de trabajar, ha sido adoptada desde hace ya muchos años, cuando el hombre descubre que un trabajo puede realizarse de manera más rápida y efectiva si se lleva a cabo en conjunto con otros individuos.
El concepto de equipo difiere, dependiendo de los diversos puntos de vista, por la forma en que se realizan las tareas, así como de la organización interna de cada equipo de trabajo y el grado de integración que muestran lo integrantes del mismo. Todos estos enfoques, nos definen los ámbitos en los que se desenvuelven los diversos equipos de trabajo y como esta conformada su estructura interna.
3.2 Trabajo en equipo.
La conformación de un equipo de trabajo puede variar considerablemente de acuerdo a la naturaleza y contexto del proyecto. De acuerdo con Hobbs (2000) generalmente cae en tres subgrupos:
• Especialistas técnicos: Los miembros del equipo con especialización de conocimientos técnicos son usualmente empleados como consultores. Tienden a ser muy caros y sólo pueden ofrecer tiempo limitado al proyecto. Por lo tanto, se les debe asignar tareas muy específicas o ser utilizados para supervisar o aconsejar en otros aspectos más generales.
• Equipos externos: Se puede realizar un "outsource" de ciertas partes del proyecto a otras organizaciones. Probablemente se necesite llegar a un acuerdo formal acerca de las escalas de tiempo, alcance y costo del trabajo. Si estos acuerdos se realizaron correctamente, no será necesario hacer una administración cotidiana de lo delegado a terceros. De otra forma, corregirlo puede consumir mucho tiempo y ser muy costoso.
• Equipos internos: Los miembros generalmente surgen de la propia organización o departamento, de manera que se adoptará un estilo menos formal cuando se les deleguen tareas. Se debe tener cuidado, de equilibrar este estilo poco formal con una definición poco estrecha de lo que se requiere y para cuándo. Esto es crucial cuando se delega a miembros de mayor categoría.
Frecuentemente el equipo interno es el grupo más difícil de administrar debido a que los miembros posiblemente realizan otras tareas prioritarias. Las ventajas son que rara vez se salen del presupuesto asociado al utilizarlos, sus fuerzas y debilidades son generalmente conocidas por el administrador de proyectos.
A pesar que esta paradoja es obviamente cierta, la forma en que se traduce a un comportamiento es muy sutil. Mantener un balance entre tratar a todos igual (o administrar a todos consistentemente) y en ser sensible a diferencias individuales no es fácil. Cada persona tiene intereses, metas y una personalidad, que son únicos.
Una vez comprendida la diversificación de los miembros es un buen inicio para formar un equipo. Sin embargo, el grupo de personas que trabajan en conjunto en un proyecto no se convierte automáticamente en un equipo al inicio del mismo. Existen varias etapas de evolución que el grupo de individuos debe pasar para convertirse en un equipo.
3.3 Tipos de equipo.
Dentro de la evolución de los equipos, diversos autores presentan una clasificación de éstos en base al compromiso de los equipos, mientras que otros autores proponen una clasificación en base a la autonomía. Katzenbach y Smith (1995) hacen una comparación que muestra las etapas de las personas trabajando en equipo.
1. Trabajando en grupo. Los miembros de este grupo no ven razón para convertirse en equipo. Ellos pueden compartir información, pero las responsabilidades, metas y productos pertenecen a individualidades.
2. Pseudo equipo. Este grupo de personas define el trabajo a realizar, pero no se enfoca en el desempeño colectivo, la individualidad de los miembros va en contra del desempeño colectivo de la organización.
4. Equipo real. Consiste en un grupo de personas con habilidades complementarias, quienes están comprometidos con metas y objetivos comunes. Han aprendido a confiar los unos de los otros. 5. Equipo de alto desempeño o autodirigido. Este equipo cumple
con todos los criterios de un equipo real, pero sus miembros también están comprometidos con sus compañeros de trabajo. El desempeño de estos equipos es mayor al de todos los mencionados anteriormente.
Con esta clasificación de personas trabajando juntas podemos identificar a los equipos en las organizaciones. Es necesario que los equipos vayan evolucionando en el grado de confianza y autonomía hasta que sean capaces de autodirigirse.
Una de la variables críticas que se identifican en los equipos autodirigidos, es la autonomía, que es el grado de poder o de toma de decisiones que estos equipos tienen Shonk (1992), clasifica a los equipos basado en su grado de autonomía.
1. Equipos de sugerencia. Estos equipos son temporales y trabajan en problemas específicos. El equipo tiene poca autoridad en implantar sus sugerencias, la jerarquía tradicional aún sobrevive. Estos equipos son útiles para recopilar ideas en tópicos, como reducción de costos o incremento de la productividad.
2. Equipos de solución de problemas. Estos equipos identifican y analizan problemas, desarrollando modos de solución, generalmente están compuestos por un supervisor y de 5 a 8 elementos. Estos equipos se conocen también como círculos de calidad o Task Forces.
3. Equipo semiautónomo. Cuentan con un supervisor, desarrollan sus planes y organizan su trabajo diario.
4. Equipos autodirigidos. Estos equipos administran su trabajo en base diaria, usualmente:
• Definen y solucionan problemas en su área.
• Toman decisiones diarias dentro de sus límites de autoridad. • Calendarizan el trabajo.
• Contratan nuevos miembros
La evolución hacia los grupos autodirigidos implica que los individuos aporten no sólo sus manos (bajo el esquema de "mano de obra" tradicional), sino también sus mentes. Es necesario que el individuo piense y aprenda para que la organización también evolucione.
3.4 Esquema de trabajo en equipos autodirigidos.
Los equipos autodirigidos nacen en Inglaterra y Suecia alrededor de 1950, donde unos mineros se agrupan en equipo y comienzan a trabajar de una manera distinta a lo que se hacia entonces. Al realizar sus actividades se ayudaban entre sí y se distribuían las tareas según sus capacidades, de tal manera, que lograban producir más y mejor. Como resultado de esta forma de trabajo bajo el ausentismo, así como los accidentes y la productividad fue más alta (Moreno 1991).
Los equipos autodirigidos surgen como una manera natural de trabajar del hombre. Al pertenecer este a una sociedad, tiende a desempeñar tareas en conjunto con otros hombres que compartan sus mismos objetivos y puedan realizar la tarea, proporcionando al equipo una serie de habilidades que en conjunto satisfagan las necesidades del trabajo.
De las anteriores definiciones podemos tomar tres aspectos relevantes:
• El tamaño del grupo autodirigido es pequeño. • Los objetivos están claramente identificados.
• La autonomía, cada uno es responsable de su parte del proceso.
En base a lo anterior, se puede decir, que un equipo autodirigido es: Un pequeño grupo de personas, completamente responsables de un segmento del proceso, en el cual, ellos administran sus actividades cotidianas y toman sus propias decisiones.
Parker (1993) menciona doce características de los equipos efectivos que según él se debieran considerar a la hora de evaluar a algún equipo. Es importante mencionar que estas variables hacen sentido con lo observado en los equipos reportados como exitosos por Wellins, Byham y Dixon (1994).
1. Claro sentido de propósito. Se refiere a que el equipo autodirigido tenga entendido, cuál es el objetivo de estar juntos y cuál es la misión a desarrollar. Es la razón de ser del equipo. El equipo autodirigido debe saber para que fue creado, y entre más específico sea su propósito, más probable será que lo cumpla. Además, algo que también es importante para el éxito del equipo autodirigido, es saber qué se espera exactamente de él.
2. Clima informal. Es el ambiente de trabajo que permite, el estar en confianza y armonía con los demás compañeros. Se crea un ambiente de camaradería, es más importante no fallarle al compañero, que no fallarle a la empresa; la gente se divierte en su trabajo, se organizan celebraciones para festejar los pequeños triunfos, se crea un clima de confianza y compañerismo.
4. Habilidad para escuchar. Los miembros del equipo deben poner atención a lo que sus compañeros están aportando. La cualidad de escuchar es muy importante. Deben ser capaces de recibir retroalimentación, tanto para las personas que conforman el equipo, como éste en su totalidad. Deben escuchar lo que sus compañeros opinan y aportan.
5. Desacuerdos civilizados. Es la capacidad de opinar diferente, y no por ello llevar al equipo a discusiones y pleitos. Al contrario, se busca alcanzar una riqueza de puntos de vista complementarios y valiosos a la práctica. Es el saber disentir en armonía, obteniendo un aprendizaje tanto individual como colectivo.
6. Consenso. El entender las diferentes opiniones y el poder trabajar confortablemente con ellas. Es importante, al momento de trabajar en equipo, la capacidad de los miembros para escuchar las diferentes propuestas, y una vez tomada la decisión el apoyar y trabajar en equipo en conjunto para realizarla.
7. Comunicación abierta. Se refiere a lograr la confianza con los demás miembros para intercambiar ideas y opiniones sin temor al rechazo. El equipo, como la empresa, debe crear cultura de comunicación abierta, el saber que todo el mundo tiene algo que decir y sentir, que la empresa y sus compañeros están ahí para escucharlo.
8. Roles y asignaciones claramente repartidos. El saber quién hace qué y cuál es la manera de repartir el trabajo, debe ser claro para los miembros del equipo. De lo anterior, depende la realización de las tareas, donde el éxito es lo mismo que saber claramente que se espera de ellos, y definir exactamente lo que deben hacer, y cómo se reparten las asignaciones para que cada individuo aporte según sus habilidades.
