UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob

Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 1

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

DESARROLLO ACTIVIDAD (1) ORGANIZACIN DEL EQUIPO DE TRABAJO.

1. Como organizar el mejor Equipo Humano de trabajo para equipos de Software? La mejor estructura de equipo depende del estilo de gestin de una organizacin, el nmero de personas que compondr el equipo, sus niveles de preparacin y la dificultad general del problema. Mantei sugiere tres organigramas de equipo genricos: Descentralizado democrtico (DD). Este equipo de ingeniera del software no tiene un jefe permanente. Ms bien, se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas. Las decisiones sobre problemas y los enfoques se hacen por consenso del grupo. La comunicacin entre los miembros del equipo es horizontal. Descentralizado controlado (DC). Este equipo de ingeniera del software tiene un jefe definido que coordina tareas especficas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolucin de problemas sigue siendo una actividad del grupo, pero la implementacin de soluciones se reparte entre subgrupos por el jefe de equipo. La comunicacin entre subgrupos e individuos es horizontal. Tambin hay comunicacin vertical a lo largo de la jerarqua de control. Centralizado controlado (CC). El jefe del equipo se encarga de la resolucin de problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre el jefe y los miembros del equipo es vertical. 2. Una vez identificado el mejor equipo de trabajo determine: a) el objetivo general del equipo de trabajo. La primera consideracin al organizar un equipo es determinar el objetivo general del mismo. Segn Larson y La Fasto [1989] estos son los objetivos generales:

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 2

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Resolucin de problemas. Creatividad. Ejecucin tctica.

Una vez identificado el objetivo ms general del equipo, se prepara una estructura de equipo que haga hincapi en la caracterstica ms importante para este tipo de equipo. Equipo para la resolucin de problemas: El equipo para resolucin de problemas se centra en resolver un problema complejo, poco definido. Los miembros de un equipo de resolucin de problemas tienen que ser de confianza, inteligentes y pragmticos. Los equipos de resolucin de problemas estn ocupados principalmente en una o ms cuestiones especficas y su estructura de equipo debe soportar este modo de trabajo. Equipo para creatividad: El objetivo de un equipo para creatividad consiste en explorar posibilidades y alternativas. Los miembros de un equipo para creatividad necesitan estar motivados, ser independientes, creativos y persistentes. La estructura del equipo necesita soportar la autonoma individual y colectiva de los miembros del equipo. Equipo para ejecucin tctica: Se centran en ejecutar un plan bien definido. Este tipo de equipo se caracteriza por tener tareas muy centradas y funciones muy definidas. Los criterios del xito tienden a ser todo o nada, as que a menudo resulta fcil decir si el equipo triunfa o fracasa. Los miembros de un equipo de ejecucin tctica necesitan tener un sentido de la urgencia de su misin, estar ms interesados en la accin que en la intelectualizacin esotrica y ser leales al equipo. .

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 3

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

b) caractersticas a tener en cuenta para que estos equipos de trabajo funcionen con efectividad. Aparte de los tres tipos bsicos de equipos, hay cuatro caractersticas de la estructura de los equipos que parecen caracterizar todos los tipos de equipos que funcionan con efectividad. Papeles y responsabilidades claros: En un equipo de alto rendimiento, todo el mundo cuenta, y cada uno sabe lo que tiene que hacer. Monitorizacin del rendimiento individual y realimentacin: La otra cara de las responsabilidades consiste en que los miembros del equipo necesitan saber si estn trabajando de acuerdo con las expectativas del equipo. El equipo necesita disponer de mecanismos para que sus miembros sepan en qu aspectos tienen un rendimiento aceptable y cules son los que necesitan mejorar. Comunicacin efectiva: La informacin debe ser fcil de consultar. Reservar la informacin y darla a conocer cuando haga falta es malo para la moral en un proyecto. Se debe poner toda la informacin relevante a disposicin de todos. La informacin tiene que venir de fuentes fidedignas. La confianza del equipo en la toma de decisiones depende de lo fiable que sea la informacin sobre la que basa sus decisiones. Los miembros del equipo necesitan tener oportunidades para plantear cuestiones que no se encuentren en la agenda formal, esto forma parte del xito de mtodos de gestin informales tales como walking around (gestin mediante visitas). El sistema de comunicacin tiene que reflejar las cuestiones planteadas y las decisiones tomadas. Mantener un registro minucioso evita que el equipo retroceda para plantearse decisiones pasadas. Toma de decisiones basada en hechos: Los juicios subjetivos pueden minar la moral del equipo. Los miembros de un equipo de alto rendimiento necesitan comprender las bases de todas las decisiones que les afectan. Si encuentran que las decisiones estn tomadas por

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 4

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

razones arbitrarias, subjetivas o egostas su rendimiento se ver penalizado. 3. Cules son los modelos de equipo? Para tres de ellos, identifique su estructura jerrquica, filosofa de trabajo, el objetivo, debilidades y fortalezas. Equipo de negocios Equipo con programador jefe o quirrgico Equipo en la sombra Equipo de prestaciones Equipo de emercencias o de bsqueda y rescate. Equipo de especialistas (G.E.O.) Equipo deportivo Equipo de teatro

EQUIPO DE NEGOCIOS La estructura de equipo ms comn es la de un grupo de iguales encabezado por un jefe tcnico. Aparte del jefe tcnico, todos los miembros del equipo tienen el mismo estatus, diferencindose en su mbito de experiencia. El jefe tcnico contribuye de forma activa. El jefe es responsable de tomar las decisiones finales sobre cuestiones tcnicas. Desde el exterior, la estructura del equipo de negocios parece una estructura jerrquica tpica. Concentra la comunicacin con la directiva, identificando una persona como responsable principal del trabajo tcnico del proyecto. Permite a cada miembro del equipo trabajar en su rea de experiencia, y permite que el propio equipo decida en que va a trabajar cada uno de sus miembros. Funciona bien con grupos pequeos y con grupos que llevan juntos mucho tiempo, y pueden estructurar sus relaciones con el tiempo. Es bastante adaptable para trabajar en todos los tipos de proyectos. Pero generalmente sta es su debilidad, y en muchos casos hay otra estructura que puede funcionar mejor.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 5

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

EQUIPO CON PROGRAMADOR JEFE O QUIRRGICO Esta idea de equipo fue concebida por IBM a finales de los sesenta y popularizada por Fred Brooks [1975, 1995], l se refiere al equipo como quirrgico, ambos trminos son intercambiables. El equipo con programador jefe saca partido del hecho de que algunos desarrolladores son 10 veces ms productivos que otros. En el concepto de equipo quirrgico, la persona ms cualificada se identifica con el cirujano, o programador jefe. Esta persona realiza la especificacin completa, hace todo el diseo, escribe la mayora del cdigo de produccin, y es el responsable final de prcticamente todas las decisiones del proyecto. El resto de los miembros del equipo son libres para especializarse. Los miembros del equipo se distribuyen alrededor del cirujano con funciones de apoyo, y el equipo con programador jefe saca partido del hecho de que los especialistas tienden a rendir ms que los generalistas [Jones, 1991]. Hay un programador de reserva que apoya al cirujano como crtico, ayudante de investigacin, contacto tcnico con grupos externos y cirujano de reserva. Otra persona gestiona cuestiones administrativas. Aunque el cirujano tiene la ltima palabra en estas cuestiones, el administrador libera al cirujano de tener que tratarlas de forma diaria. Alguien ser el responsable de crear herramientas personalizadas solicitadas por el programador jefe. El equipo est arropado por un especialista del lenguaje, que apoya al cirujano respondiendo a preguntas especficas y peculiares sobre el lenguaje de programacin que est usando el programador jefe. Varios de los papeles de apoyo sugeridos en la propuesta original de equipo con programador jefe son desempeados actualmente por personas que no son programadores. Esta estructura sigue siendo adecuada cuando se usa de forma oportunista. Este equipo resulta adecuado para proyectos creativos, en los que tener un cerebro al frente ayudar a proteger la integridad conceptual del sistema. Tambin resulta adecuado para proyectos de ejecucin tctica, en los que el

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 6

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

programador jefe puede ser una especie de dictador que disee los medios ms expeditivos para lograr la culminacin del proyecto. EQUIPO EN LA SOMBRA Un equipo en la sombra (skunworks) es una parte integral de la herencia del mundo de la ingeniera. Un equipo en la sombra aglutina un grupo de desarrolladores de productos creativos y con talento, les pone en una situacin en la que son liberados de las restricciones burocrticas habituales de la organizacin, y les da libertad para desarrollar e innovar. Los equipos en la sombra son tratados generalmente como cajas negras por sus directivos. La directiva no quiere conocer los detalles sobre como realizan el trabajo, sino que slo quieren saber lo que estn haciendo. As, el equipo es libre de organizarse como mejor le parezca. Con el paso del tiempo, puede aparecer un lder natural, o el equipo podra designar uno desde el principio. Los proyectos en la sombra tienen la ventaja de crear una sensacin de intensa propiedad y compromiso por parte de los desarrolladores implicados. El efecto motivacional puede ser impresionante. Tienen la desventaja de no ofrecer mucha visibilidad del progreso del equipo. Parte de esto puede ser un efecto inevitable de la impredecibilidad inherente en un trabajo altamente creativo. Tambin se debe a un equilibrio explcito: prdida de visibilidad a costa de incrementar la motivacin. Los equipos en la sombra resultan ms adecuados para proyectos exploratorios en los que la creatividad es absolutamente importante. Los equipos en la sombra son raramente la estructura ms rpida cuando se necesita resolver un problema claramente definido o cuando se necesita ejecutar un plan bien entendido. EQUIPO DE PRESTACIONES En un equipo de prestaciones, el desarrollo, el control de calidad, la documentacin, la gestin del programa y el marketing estn organizados con las estructuras jerrquicas tradicionales de responsabilidad.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 7

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Con esta organizacin tradicional se encuentran los equipos que toman uno o ms miembros de cada uno de los grupos implicados y les asignan la responsabilidad de una parte de la funcionalidad del producto [Mc Carthy, 1995]. Los equipos de prestaciones presentan las ventajas de potenciacin, facilidad de seguimiento y equilibrio. El equipo puede potenciarse sensiblemente porque incluye representantes de desarrollo, control de calidad, documentacin, gestin del programa y marketing; es decir, de todas las partes implicadas. El equipo considerar todos los puntos de vista necesarios en sus decisiones, y por ello en raras ocasiones dar pie a que estas sean cuestionadas. Por la misma razn, resulta fcil llevar el seguimiento del equipo. Tienen acceso a todas las personas que necesitan para tomar buenas decisiones. Si no toman buenas decisiones, slo pueden echarse la culpa a ellos mismos. El equipo est equilibrado. Los equipos de prestaciones resultan adecuados para proyectos de resolucin de problemas, ya que ofrecen el refuerzo y la facilidad de seguimiento necesarios para resolver las cuestiones planteadas de forma expeditiva. Tambin son adecuados para proyectos de creatividad, ya que la composicin interdisciplinar del equipo puede estimular las ideas. La gestin adicional generada por los equipos de prestaciones se desperdicia en los proyectos de ejecucin tctica: si todas las tareas estn claramente identificadas, los equipos de prestaciones tienen poco que aportar. 4. independiente de los puntos anteriores. A) Qu es un equipo de alto rendimiento? Los equipos productivos a veces se caracterizan por ser equipos que se han ido formando o equipos con una gran unin. Un equipo con una gran cohesin, un alto rendimiento y que se ha ido moldeando a s mismo, tiene una serie de caractersticas comunes: Una alta visin u objetivo compartidos. Un sentido de identidad de equipo.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012 Una estructura dirigida a los resultados. Miembros del equipo competentes. Un compromiso con el equipo. Confianza mutua. Interdependencia entre miembros del equipo. Comunicacin efectiva. Un sentido de autonoma. Un sentido de enriquecimiento. Tamao del equipo pequeo. Un alto nivel de disfrute.

Cdigo 0152717 0152775 Pgina 8

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

B) En equipos de alto rendimiento segn Larson y La Fasto TODO EL MUNDO SABE LO QUE TIENE QUE HACER EN CADA MOMENTO. y teniendo en cuenta los modelos de ciclo de vida diligencie el siguiente cuadro (haga un anlisis de acuerdo a ellos tomado tres modelos de ciclo de vida) Caractersticas Resolucin Problemas Confianza de Creatividad Ejecucin tctica Claridad

Caracterstica dominante

Autonoma

Ejemplo tpico en Mantenimiento Desarrollo de un Desarrollo de la software corrector en nuevo producto actualizacin de sistemas en un producto marcha nfasis proceso en el Centrado cuestiones en Explorar posibilidades Tareas y centradas muy con

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012 alternativas

Cdigo 0152717 0152775 Pgina 9

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

funciones claras, marcadas con un claro xito o fracaso Cascada, cascadas modificadas, entrega por etapas, espiral, diseo para planificacin, diseo para herramientas Leales, comprometidos, dispuestos a la accin, con sentido de la urgencia, responsables Equipo de negocios, equipo con programador jefe, equipo de prestaciones, equipo SWAT, equipo profesional de atletismo

Modelos apropiados ciclo de vida

Codificar y Prototipado de corregir, espiral evolutivo, entrega evolutiva, espiral, diseo para planificacin, diseo para herramientas

Criterios seleccin equipo

de Inteligentes, del desenvueltos, sensibles, alta integridad

Cerebrales, independientes, pensadores, con iniciativa, tenaces

Modelos apropiados equipo software

Equipo de de negocios, equipo de de bsqueda y rescate, equipo SWAT

Equipo de negocios, equipo con programador jefe, equipo en la sombra, equipo de prestaciones, equipo de teatro

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 10

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

5. Usted es el Gestor y Director de un Proyecto de Software, identifique para los equipos de Pruebas de Software, Gestin de configuracin del Software, Gestin de Proyectos, de Mantenimiento de Software:

Definicin de puestos y funciones.

El anlisis y descripcin del puesto de trabajo permite saber: Como se denomina cada puesto. Dnde se ubica dentro de la estructura organizativa general. Qu se hace en l y para qu. Dnde, cmo y cundo acta. Toda esta informacin sistematizada se recoge en fichas descriptivas que, como norma general, incluyen datos referentes a los siguientes aspectos:
Ficha descriptiva del puesto Nombre del puesto. rea, Departamento o Seccin a la que pertenece. Dependencia jerrquica y puestos que dependen de l. Funcin bsica o principal del puesto. Funciones o actividades especificas de las que debe ocuparse. Responsabilidades: Alcance y nivel de las decisiones que debe tomar. Implicaciones que tiene sobre aspectos econmicos. Grado, momento y carcter de la supervisin que la empresa ejerce sobre el puesto. Relaciones internas y externas que se mantienen en el puesto, as como su frecuencia, nivel y repercusiones. Medios de apoyo tcnico que utiliza (informacin, equipos, etc.). Condiciones especiales (viajes, traslados, dedicacin, etc.). Condiciones ambientales (riesgo, entorno fsico, etc.).

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 11

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Los datos de la ficha anterior permiten valorar objetivamente el puesto y sirven de base para definirlos requisitos de la persona que lo desempee y los niveles retributivos de dicho puesto.

Organigrama y personigramas.

Perfil del puesto: De acuerdo a las caractersticas del puesto podemos determinar las condiciones que deben reunir los aspirantes. El conjunto de dichas condiciones se denomina perfil.
Perfil o Profesiograma del puesto

Requisitos personales: Edad, sexo, etc. Conocimientos: Tipo y nivel acadmico o de formacin profesional. Requisitos profesionales: Grado y clase de experiencia necesaria. Requisitos mentales o aptitudes: Relativa a las habilidades en el desempeo del puesto (verbales, numricas, espaciales, atencin, inteligencia general, etc.). Requisitos fsicos: Aspecto, salud, etc. Requisitos de personalidad y motivacin: Carcter, expectativas, capacidad de trabajo, etc.

Una vez definido el perfil, hay que reflexionar sobre las posibilidades de encontrar personas adecuadas al mismo. Si despus de ello se determina que la previsin de respuesta es suficiente hay que establecer la forma en la que se va a llevar a cabo el proceso de adquisicin, esto es: Dnde se encuentran las personas que se adecuan al perfil? Cmo hacerles llegar la informacin y que se interesen por la oferta? Dnde. Las fuentes de adquisicin pueden ser tanto internas como externas. Las fuentes internas pueden ser: Planes de rotacin-traslado o planes de promocin. En cuanto a las externas son muy numerosas, las principales son:

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 12

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Solicitudes y ofrecimientos, Oficinas de empleo, Centros de formacin, Asociaciones, Empresas de la competencia, Empresas especializadas y consultoras de recursos humanos. Cmo. La oferta puede darse a conocer de forma directa o a travs de medios de comunicacin.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 13

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Habilidades necesarias para cada puesto. Habilidad para comprender conceptos abstractos, reorganizarlos en divisiones lgicas y sintetizar soluciones basadas en cada divisin; Habilidad para entresacar hechos importantes de fuentes conflictivas o confusas; Habilidad para comprender entornos de usuario/cliente; Un gran bagaje tcnico; Conocimientos bsicos en otras disciplinas: administracin, economa, organizacin.

6. Investigue sobre: a) Motivacin al Personal de Trabajo. La motivacin es indudablemente la mayor influencia individual sobre como trabajan las personas. La mayora de los estudios de productividad han encontrado que tiene mayor influencia en la productividad que cualquier otro factor [Boehm, 1981]. La motivacin juega un papel crtico en el desarrollo, pero es un factor intangible: es difcil de cuantificar, y suele considerarse despus de otros factores menos importantes, pero ms fciles de medir. Cualquiera sabe que la motivacin es importante, pero pocos hacen algo al respecto. Los cinco factores de motivacin son: REALIZACIN A los desarrolladores de software les gusta trabajar, la mejor forma de motivar a los desarrolladores es proporcionarles un entorno que les facilite centrarse. Propiedad. La propiedad es una clave para la motivacin por realizacin. Las personas trabajarn ms duro para alcanzar sus propios objetivos que los de las dems personas. Definicin de objetivos. La definicin de objetivos es otra clave para la motivacin por realizacin. Establecer los objetivos explcitamente es un

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 14

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

paso obvio y simple para un buen y rpido desarrollo, y es fcil de supervisar. Los desarrolladores no pueden responder a los objetivos que cambian diariamente o que son imposibles de cumplir en conjunto. Los desarrolladores hacen lo que se les pida que hagan. Tienen una gran motivacin por realizacin, trabajan en los objetivos que se les especifican, pero hay que especificar esos objetivos y ser conciso. Si a un equipo se le dan varios objetivos a la vez, no es probable que los hagan todos bien. Un estudio de ITT demostr que la productividad disminua claramente cuando haba muchos objetivos [Vosburgh et al., 1984]. Definir demasiados objetivos al mismo tiempo es un problema comn. Para obtener mejores resultados, hay que seleccionar un objetivo y dejar claro que es el ms importante. POSIBILIDAD DE SUPERACIN Uno de los aspectos ms excitantes de ser un desarrollador de software es trabajar en un campo que est cambiando constantemente. Hay que considerar la naturaleza de la industria elegida por los desarrolladores para trabajar en ella, y no sorprenderse de la motivacin por posibilidad de superacin. Una organizacin puede influir en esta motivacin dando a los desarrolladores las oportunidades de crecer en sus proyectos. Esto requiere alinear los objetivos de crecimiento de la organizacin con los objetivos de superacin individuales. Barry Boehm [1981] lo indica de esta forma: El principio de la progresin en la carrera indica que est en una organizacin cuyo principal inters es ayudar a las personas a determinar cmo desean prosperar profesionalmente, y proporcionarles oportunidades para desarrollarse en esas direcciones. Esto puede parecer un principio obvio pero en la practica hay muchas organizaciones de software que siguen principios fuertemente opuestos. Si se elimina la posibilidad de superacin al equipo, se elimina al mismo tiempo la motivacin del equipo. Una empresa puede mostrar inters en el progreso profesional de sus programadores de varias (no estn todas) formas:

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 15

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

Cursos de desarrollo profesional. Tiempo extra para asistir a clases o estudiar. Dinero para la compra de libros profesionales. Asignando a los desarrolladores a proyectos que aumentarn su experiencia. Asignando un tutor a cada desarrollador. Evitando presiones excesivas en la planificacin. Las compaas que estn en el grupo de cabeza de sus sectores en calidad y productividad, normalmente dedican 2 semanas al ao para la preparacin de los desarrolladores del software y tres semanas para los responsables del software [Jones, 1994]. Centrarse en la superacin personal puede tener consecuencias a corto y largo plazo sobre la productividad de la organizacin. A corto plazo, aumentar la motivacin del equipo, haciendo que trabajen ms duro. A largo plazo, aumentar la posibilidad de que la organizacin atraiga y mantenga a personas con grandes aptitudes. EL TRABAJO EN S Richard Hackman y Greg Oldham mantienen que, generalmente, la motivacin interna de las personas parte de tres fuentes: su trabajo debe tener sentido; debe tener responsabilidad por el resultado del trabajo; y debe conocer los resultados reales de las actividades de su trabajo [Hackman y Oldham,1980]. Hackman y Oldham identificaron cinco dimensiones del trabajo en s que contribuyen a esas fuentes de motivacin. Las tres primeras caractersticas de este trabajo contribuyen a ver el significado que las personas encuentran en su trabajo: La diversidad de tcnicas es el grado en el que el trabajo requiere que se ejerciten una serie de tcnicas, de forma que se pueda evitar el aburrimiento y la fatiga. An en trabajos no muy significativos ni importantes, la variedad encuentra un significado al trabajo. La identidad de la tarea es el grado en el que el trabajo requiere que se cubra una parte completa. Las personas ponen ms inters cuando tienen que hacer un trabajo completo y sienten que su colaboracin es importante.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 16

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

La importancia de las tareas es el grado en el que el trabajo afecta a otras personas y contribuye al bienestar social. Las personas necesitan sentir que el producto final tiene un valor. La cuarta caracterstica contribuye al sentimiento de responsabilidad de la persona sobre el resultado del trabajo: Autonoma es el grado en el que se tiene el control sobre los medios y mtodos que se utilizan para realizar el trabajo. Cuanto mayor sea la autonoma, mayor ser el sentimiento de responsabilidad personal por el resultado del trabajo. La quinta caracterstica contribuye al conocimiento de las personas sobre los resultados reales de las actividades de su trabajo: Realimentacin del trabajo es el grado en que la realizacin del trabajo en s proporciona informacin clara y directa sobre cmo es de efectivo. Una clave para la motivacin es controlar estas cinco dimensiones para crear un trabajo significativo, y posteriormente asignar este trabajo a personas con un gran deseo de realizarlo. El 60 por 100 de la motivacin de un desarrollador proviene de la correspondencia entre el trabajo y el desarrollador [Zawacki, 1993]. Oportunidad para centrarse en el trabajo en s. Otro aspecto motivacional del trabajo en s es el grado en el que el entorno permite a un desarrollador centrarse en el trabajo en s, comparado con la cantidad de tiempo que necesita el desarrollador para centrarse en otros temas relacionados. Conseguir algo inusual ha tardado desde semanas a meses. Para un desarrollador de software que no desea otra cosa que desarrollar software, puede ser increblemente frustrante y desmotivador tener que perder el tiempo con tareas burocrticas o pelendose para conseguir material normal de oficina. VIDA PERSONAL El impacto motivacional de la vida personal de un desarrollador es probablemente el factor motivacional ms duro de comprender por un

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 17

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

directivo. El resultado es que los directivos premian en ocasiones a sus mejores desarrolladores asignndoles los proyectos ms complejos y de mayor presin. Para los directivos, la responsabilidad extra, puede ser un placer, y la disminucin de la vida personal no importara mucho. Para un desarrollador, la responsabilidad extra es ms un engao que un placer, y la disminucin de la vida personal es una fuerte prdida. El desarrollador interpreta el premio del directivo como un castigo. No se puede hacer mucho para utilizar las vidas personales como factores de motivacin, excepto planificar proyectos de manera realista, para que los desarrolladores tengan tiempo para su vida personal, respetando periodos vacacionales, y siendo susceptible a peticiones ocasionales de tiempo libre durante el trabajo. OPORTUNIDAD DE SUPERVISIN TCNICA Para un desarrollador una oportunidad de revisin tcnica representa una realizacin. Una oportunidad de supervisin tcnica implica que el desarrollador ha alcanzado un nivel de experiencia tcnica suficiente para dirigir a otros. Las oportunidades de supervisin tcnica no se limitan a asignar a una persona como responsable tcnico de un proyecto. Se puede usar este factor de motivacin en trminos ms generales: En un proyecto, asignar a cada persona como responsable tcnico de un rea del producto en particular. Asignar a cada persona la responsabilidad tcnica de un rea del proceso en particular. Hacer que casi todos los desarrolladores sean monitores. b) Mediante una lista identifique los Factores que motivan a los desarrolladores, directivos y personas en general (agregue todas las motivaciones que considere) Motivacin tpicas Directores 1.Responsabilidad Desarrolladores 1.Realizacion Personas en general 1.Realizacion

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012 2.Realizacin 2.Posibilidad superacin 3.El propio trabajo 4.Vida personal de 5.Oportunidad supervisin tcnica 6.Ascenso

Cdigo 0152717 0152775 Pgina 18

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

de 2.Reconocimiento

3.El propio trabajo 4.Reconocimiento 5.Posibilidad superacin 6.Relaciones interpersonales, subordinados 7.Relaciones interpersonales, nivel. 8. Ascenso

3.El propio trabajo 4.Responsabilidad de 5.Ascenso

6.Salario

7.Relaciones igual interpersonales, nivel 8. Reconocimiento

7.Posibilidad igual superacin

de

8.Relaciones interpersonales, subordinados 9. Posicin social 10.Relaciones interpersonales, superiores 11.Relaciones interpersonales, nivel

9.Salario 10.Relaciones interpersonales superiores 11.Politicas de compaa la administracin

9.Salario 10.Responsabilidad

la 11.Relaciones y interpersonales, superiores en

igual

12. Seguridad en el 12.Seguridad trabajo trabajo 13.Relaciones interpersonales, 13.Relaciones interpersonales,

el 12.Oportunidad supervisin tcnica 13.Politicas compaa de y

de

la de

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012 subordinados 14.Politicas de compaa y administracin 15.Condiciones trabajo 16.Posicion social subordinados la 14.Politicas de de compaa y de administracin de 15.Condiciones trabajo 16.Posicion social

Cdigo 0152717 0152775 Pgina 19

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

administracin la 14.Condiciones la trabajo de

de 15.Vida personal

16.Seguridad trabajo

en

el

7. Identifique otros factores como los destructores. MANIPULACIN DE LA DIRECTIVA. Los desarrolladores son susceptibles a ser manipulados por los directivos. Tienden a enfrentarse a temas importantes, y desean que la directiva trate a los desarrolladores de forma sincera.

Cualquier directivo podra tener buenas razones para pedir una fecha lmite o una peticin similar, sin tener que dar explicaciones. Los directivos de un nivel inferior podran no entender las razones por las que se ha establecido la fecha lmite. Razones que podran parecer ser evasivas y manipuladoras (y los desarrolladores responden mal a esto). Salvo circunstancias extremas cualquier directivo que pida a los desarrolladores que realicen trabajo extra en un proyecto les debe dar una clara explicacin. Los directivos que se esfuerzan por no proporcionar detalles sobre porqu una fecha lmite es importante, deberan recordar que sus explicaciones probablemente resulten desalentadoras para los desarrolladores.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 20

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

PRESIN EXCESIVA DE LA PLANIFICACIN. Una de las formas ms rpidas de bajar la motivacin a cero es presentar a los desarrolladores una fecha lmite imposible. Pocas personas trabajarn duro para alcanzar una fecha lmite que saben que es imposible, especialmente si son del tipo T MBPI (aquellos que responden ms a la lgica que a las emociones).

FALTA DE APRECIACIN DE LOS ESFUERZOS DE DESARROLLO. En ocasiones los directivos no ven la cantidad de trabajo que los desarrolladores estn realizando, de forma que piensan que no estn haciendo mucho y, por tanto, deben obligarlos. En realidad, los desarrolladores estn extremadamente automotivados, trabajan duro y muchas horas, y encontrarse acusados de holgazanear es muy desalentador. Si se desea que los desarrolladores hagan ms de lo que realmente ponen de manifiesto en la oficina, nunca jams hay que decirles que no estn trabajando duro cuando si lo estn haciendo.

PARTICIPACIN DE DIRECTIVOS SIN PREPARACIN TCNICA. Los desarrolladores pueden ser motivados por directivos tcnicamente incapaces, siempre que esos directivos reconozcan que no tienen preparacin tcnica y limiten el control del proyecto a las decisiones de ndole no tcnica. Intentar meterse en decisiones tcnicas que no se comprende, significa convertirse en el blanco de las bromas del equipo de desarrollo, y la mayora de las personas no pueden ser motivadas por alguien a quien no respetan.

BARRERAS DE LA PRODUCTIVIDAD. Si el entorno se establece de forma que se frustra el esfuerzo del mejor desarrollador para ser productivo, se puede estar seguro de daar su motivacin. Hay que intentar eliminar las barreras de la productividad, de forma que el equipo pueda centrarse en el trabajo en vez de en salvar las distracciones.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012

Cdigo 0152717 0152775 Pgina 21

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

NO INVOLUCRAR A LOS DESARROLLADORES EN DECISIONES QUE LES AFECTAN. No involucrar a los desarrolladores en decisiones que les afectan da la impresin de que el responsable no presta atencin al equipo de desarrollo, o que ese directivo no lo respeta lo suficiente como para desear su participacin.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DEPARTAMENTO DE SISTEMAS E INFORMATICA INGENIERIA DE SOFTWARE Grupo A INGENIERIA DE SOFTWARE III Elabor Aprob Johana Andrea Pabuence Ing. Judith del Pilar Villamizar Rodrguez Tenjo Ana Yajaira Pallares Echavez Fecha: 17 de Octubre de Fecha: 2012 BIBLIOGRAFIA Libro Roger Pressman. Quinta Edicin.

Cdigo 0152717 0152775 Pgina 22

Revis Ing. Judith del Pilar Rodrguez Tenjo Fecha:

http://www.inf.utfsm.cl/~guerra/publicaciones/Gestion%20de%20Proyectos%20 de%20Software.pdf http://alarcos.inf-cr.uclm.es/doc/pgsi/doc/esp/T9900_MAMolina.pdf