GESTION DE PROYECTOS Que es?

Implica la planificacin,supervision y control del personal , del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase preliminar ala iplementacion operacional. Espectro de la gestin La gestin eficaz de un proyecto de software se centra en las 4ps. 1. Personal:el personal debe estar organizado para desarrollar el trabajo de software con efectividad.el factor humano es tn importante tanto asi q se ah desarrollado un modelo de madurez de la capacidad de gestin de personal(mmcgp) para aumentar la capacidad de las organizaciones. El modelo de madurez de gestin de personal define las siguientes reas clave prcticas para el personal que desarrolla software: reclutamiento, seleccin, gestin de rendimiento, entrenamiento, retribucin, desarrollo de la carrera, diseo de la organizacin y del trabajo y desarrollo cultural y de espritu de equipo. 2. Producto : Antes de poder planificar un proyecto, se deberan establecer los objetivos y el mbito del producto, se deberan considerar soluciones alternativas e identificar las dificultades tcnicas y de gestin;por ello el desarrollador de software y el cliente deben establecer los objetivos y su mbito. Una vez que se han entendido los objetivos y el mbito del producto, se consideran soluciones alternativas. 3. Proceso : Un proceso de software (Captulo 2) proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. 4. Proyecto: dirigimos los proyectos planificados y controlados con la nica funcin conocida de gestionar la complejidad. PERSONAL Los participantes El proceso del software lo componen participantes que pueden clasificarse en una de estas cinco categoras: 1. Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. 2. Gestores (tcnicos) del proyecto, que deben planificar,motivar, organizar y controlar a los profesionales que realizan el trabajo de software. 3. Profesionales, que proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. 4. Clientes, que especifican los requisitos para la ingeniera del software y otros elementos que tienen menor influencia en el resultado.

5. Usuarios finales, que interaccionan con el software una vez que se ha entregado para la produccin. Los jefes de equipo La gestin de un proyecto es una actividad intensamente humana, y por esta razn, los profesionales competentes del software a menudo no son buenos jefes de equipo.
En un excelente libro sobre gestin tcnica, Jerry Weinberg [WEI86] sugiere el modelo de gestin MOI: Motivacin. La habilidad para motivar (con un tira y afloja ) al personal tcnico para que produzca conforme a sus mejores capacidades. Organizacin. La habilidad para amoldar procesos existentes (o inventar unos nuevos) que permita al concepto inicial transformarse en un producto final. Ideas o innovacin. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los lmites establecidos para un producto o aplicacin de software particular.

Otro punto de vista [EDG95] de las caractersticas que definen a un gestor de proyectos eficiente resalta cuatro apartados clave:

Resolucin del problema. Un gestor eficiente de un proyecto de software puede diagnosticar los aspectos tcnicos y de organizacin ms relevantes, estructurar una solucin sistemticamente o motivar apropiadamente a otros profesionales para que desarrollen la solucin, aplicar las lecciones aprendidas de anteriores proyectos a las nuevas situaciones, mantenerse lo suficientemente flexible para cambiar la gestin si los intentos iniciales de resolver el problema no dan resultado. Dotes de gestin. Un buen gestor de proyectos debe tomar las riendas. Debe tener confianza para asumir el control cuando sea necesario y la garanta para permitir que los buenos tcnicos sigan sus instintos. Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la iniciativa y los logros, y demostrar a travs de sus propias acciones que no se penalizar si se corren riesgos controlados. Influencia y construccin de espritu de equipo. Un gestor de proyecto eficiente debe ser capaz de leer a la gente; debe ser capaz de entender seales verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas seales. El gestor debe mantener el control en situaciones de gran estrs. El equipo de software .Existen casi tantas estructuras de organizacin de personal

para el desarrollo de software como organizaciones que se dedican a ello. Para bien o para mal, el organigrama no puede cambiarse fcilmente. Las consecuencias prcticas y polticas de un cambio de organizacin no estn dentro del alcance de las responsabilidades del gestor de un proyecto de software. Sin embargo, la organizacin del personal directamente involucrado en un nuevo proyecto de software est dentro del mbito del gestor del proyecto. Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k aos: 1. n individuos son asignados a m diferentes tareas funcionales. 2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen equipos informales; se puede nombrar un lder al efecto;la coordinacin entre los equipos es responsabilidad de un gestor del software. 3. n individuos se organizan en t equipos Mantei[MAN81] sugiere tres organigramas de equipo genricos: Descentralizado democrtico (DD). Este equipo 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 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. Mantei [MAN8 11 describe 7 factores 7 que deberan considerarse cuando se planifica el organigrama de equipos de I.S. la dificultad del problema que hay que resolver el tamao del programa resultante n lneas de cdigo o puntos de funcin el tiempo que el equipo estar junto (tiempo de vida del equipo) el grado en que el problema puede ser modularizado la calidad requerida y fiabilidad del sistema que se va a construir la rigidez de la fecha de entrega el grado de sociabilidad (comunicacin) requerido para el proyecto.

Los equipos descentralizados generan ms y mejores soluciones que los individuales.Por tanto, estos equipos tienen ms probabilidades de xito en la resolucin de problemas complejos. Puesto que el equipo DC es centralizado para la resolucin de problemas, tanto el organigrama de equipo DC como el de CC pueden aplicarse con xito para problemas sencillos. La estructura DD es la mejor para problemas difciles. los proyectos muy grandes son mejor dirigidos por equipos con estructura CC o DC, donde se pueden formar fcilmente subgrupos. Se ha descubierto que los organigramas de equipo tipo DD producen una moral ms alta y ms satisfaccin por el trabajo y son, por tanto, buenos para equipos que permanecern juntos durante mucho tiempo. El organigrama de equipo DD se aplica mejor a problemas con modularidad relativamente baja, debido a la gran cantidad de comunicacin que se necesita. Los organigramas CC o DC funcionan bien cuando es posible una modularidad alta (y la gente puede hacer cada uno lo suyo). Constantine [CON931 sugiere cuatro paradigmas de organizacin para equipos de ingeniera del software: 1. Un paradigma cerrado estructura a un equipo con una jerarqua tradicional de autoridad (similar al equipo CC). Estos equipos trabajan bien cuando producen software similar a otros anteriores, pero probablemente sean menos innovadores cuando trabajen dentro de un paradigma cerrado. 2. El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requiere innovacin o avances tecnolgicos, los equipos de paradigma aleatorio son excelentes. Pero estos equipos pueden chocar cuando se requiere un rendimiento ordenado. 3. El paradigma .El trabajo se desarrolla en colaboracin, con mucha comunicacin y toma de decisiones consensuadas y con el sello de los equipos de paradigma abierto. Los organigramas de equipo de paradigma abierto son adecuados para la resolucin de problemas complejos, pero pueden no tener un rendimiento tan eficiente como otros equipos. 4. El paradigma sincronizado se basa en la compartimentacin natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicacin activa entre ellos. denominando equipo a cualquier grupo de gente asignado para trabajar junta. Lo que falta es un fenmeno que denominamos cuajar. Un equipo cuajado es un grupo de gente tejido tan fuertemente que el todo es mayor que la suma de las partes. Una vez que el equipo empieza a cuajar, la probabilidad de xito empieza a subir. El equipo puede convertirse en imparable, un monstruo de xito .

DeMarco y Lister mantienen que los miembros de equipos cuajados son significativamente ms productivos y estn ms motivados ,comparten una meta comn, en muchos casos, un sentimiento elitista que les hace nicos. Pero no todos los equipos cuajan,de hecho, muchos equipos sufren lo que Jackman llama toxicidad de equipo . cinco factores que fomentan un entorno de equipo txico potencial: 1. Una atmsfera de trabajo frentica en la que los miembros del equipo gastan energa y se descentran de los objetivos del trabajo a desarrollar; 2. alta frustracin causada por factores tecnolgicos, del negocio, o personales que provocan friccin entre los miembros del equipo; 3. procedimientos coordinados pobremente o fragmentados o una definicin pobre o impropiamente elegida del modelo de procesos que se convierte en un obstculo a saltar; 4. definicin confusa de los papeles a desempear produciendo una falta de responsabilidad y la acusacin correspondiente. 5. continua y repetida exposicin al fallo que conduce a una prdida de confianza y a una cada de la moral. Kraul y Streeter [KRA95] examinan una coleccin de tcnicas de coordinacin de proyectos que se categorizan de la siguiente manera: Formal, enfoque impersonal. Incluyen documentos de ingeniera del software y entregas , memorandos tcnicos, hitos del proyecto, planificaciones del programa y herramientas de control del proyecto,peticiones de cambios y documentacin relativa. Formal, procedimientos interpersonales. Se centra en las actividades de garanta de calidad aplicada a productos de ingeniera del software. Estos incluyen reuniones de revisin de estado e inspecciones de diseo y de cdigo. Informal, procedimientos interpersonales. Incluyen reuniones de grupo para la divulgacin de informacin y resolucin de problemas as como definicin de requisitos y del personal de desarrollo. Comunicacin electrnica. Comprende correo electrnico,boletines de noticias electrnicos y, por extensin, sistemas de videoconferencia. Red interpersonal. Discusiones informales con los miembros del equipo y con personas que no estn en el proyecto pero que pueden tener experiencia o una profunda visin que puede ayudar a los miembros del equipo. PRODUCTO El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniera del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de informacin slida. Un anlisis detallado de los requisitos del software proporcionara la informacin necesaria para las estimaciones, pero el anlisis a menudo lleva semanas o meses.

An peor, los requisitos pueden ser fluidos, cambiando regularmente a medida que progresa el proyecto. 3.3.1. mbito del software La primera actividad de gestin de un proyecto de software es determinar el mbito del software. El mbito se define respondiendo a las siguientes cuestiones: Contexto. Cmo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qu limitaciones se imponen como resultado. Objetivos de informacin. Qu objetos de datos visibles al cliente se obtienen del software? Qu objetos de datos son requeridos de entrada? Funcin y rendimiento. Qu funcin realiza el software para transformar la informacin de entrada en una salida? Hay caractersticas de rendimiento especiales que abordar? Los enunciados del mbito del software deben estar delimitados. Es decir, los datos cuantitativos se establecen explcitamente; se anotan las limitaciones Y se describen los factores de reduccin de riesgos. 3.3.2. Descomposicin del problema La descomposicin del problema, denominado a veces particionado o elaboracin del problema, es una actividad que se asienta en el ncleo del anlisis de requisitos del software. la descomposicin se aplica en dos reas principales: (1) la funcionalidad que debe entregarse (2) el proceso que se emplear para entregarlo. PROCESO Las fases genricas que caracterizan el proceso de software definicin, desarrollo y soporte- son aplicables a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo del proyecto. gama de paradigmas de ingeniera del software: el modelo secuencia1 lineal el modelo de prototipo el modelo DRA . el modelo incremental el modelo en espiral el modelo en espiral WINWIN el modelo de desarrollo basado (ensamblaje) en componentes el modelo de desarrollo concurrente el modelo de mtodos formales el modelo de tcnicas de cuarta generacin Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en un conjunto de actividades estructurales. Una vez establecido el plan preliminar, empieza la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales.

Maduracin del producto y del proceso La planificacin de un proyecto empieza con la maduracin del producto y del proceso. Todas las funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de software deben pasar por el conjunto de actividades estructurales que se han definido para una organizacin de software. conjunto de actividades Comunicacin con el cliente- tareas requeridas para establecer la obtencin de requisitos eficiente entre el desarrollador y el cliente. Planificacin- tareas requeridas para definir los recursos, la planificacin temporal del proyecto y cualquier informacin relativa a l. Anlisis del riesgo- tareas requeridas para valorar los riesgos tcnicos y de gestin. Ingenieria- tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario Evaluacin del cliente- tareas requeridas para obtener informacin de la opinin del cliente basadas en la evaluacin de las representaciones de software creadas durante la fase de ingeniera e implementadas durante la fase de instalacin. Descomposicin del proceso Un equipo de software debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera del software que resulte mejor para el proyecto y de las tareas de ingeniera del software que conforman el modelo de proceso una vez elegido. Un proyecto relativamente pequeo similar a otros que se hayan hecho anteriormente se debera realizar con el enfoque secuencia1 lineal. Si hay lmites de tiempo muy severos y el problema se puede compartimentar mucho, el modelo apropiado es el DRA. Si la fecha lmite est tan prxima que no va a ser posible entregar toda la funcionalidad,una estrategia incremental puede ser lo mejor.

Por ejemplo, un pequeo proyecto, relativamente simple, requiere las siguientes tareas para la actividad de comunicacin con el cliente: 1. Desarrollar una lista de aspectos que se han de clarificar. 2. Reunirse con el cliente para resolver los aspectos que se han de clarificar. 3. Desarrollar conjuntamente una exposicin del mbito del proyecto. 4. Revisar el alcance del proyecto con todos los implicados.

5. Modificar el alcance del proyecto cuando se requiera. Ahora, consideremos un proyecto ms complejo que tenga un mbito ms amplio y un mayor impacto comercial. Un proyecto como se podra requerir las siguientes tareas para la actividad de comunicacin con el cliente: 1. Revisar la peticin del cliente. 2. Planificar y programar una reunin formal con el cliente. 3. Realizar una investigacin para definir soluciones propuestas y enfoques existentes. 4. Preparar un documento de trabajo y una agenda para la reunin formal. 5. Realizar la reunin. 6. Desarrollar conjuntamente mini-especificaciones que reflejen la informacin, funcin y caractersticas de comportamiento del software. 7. Revisar todas las mini-especificaciones para comprobar su correccin, su consistencia, la ausencia de ambigedades. 8. Ensamblar las mini-especificaciones en un documento de alcance del proyecto. 9. Revisar ese documento general con todo lo que pueda afectar. 10. Modificar el documento de alcance del proyecto cuando se requiera. Ambos proyectos realizan la actividad estructural que denominamos comunicacin con el cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de ingeniera del software que el segundo. PROYECTO John Reel [REE99] define diez seales que indican que un proyecto de sistemas de informacin est en peligro: La gente del software no comprende las necesi2. El mbito del producto est definido pobremente. 3. Los cambios estn mal realizados. 4. La tecnologa elegida cambia. 5. Las necesidades del negocio cambian [o estn mal

6. Las fechas de entrega no son realistas. 7. Los usuarios se resisten. 8. Se pierden los patrocinadores [o nunca se obtuvieron adecuadamente]. 9. El equipo del proyecto carece del personal con las habilidades apropiadas. 10. Los gestores [y los desarrolladores] evitan buenas prcticas y sabias lecciones.
Reel [REE99] sugiere una aproximacin de sentido comn a los proyectos de software dividida en cinco partes: Empezar con el pie derecho. Esto se realiza trabajando duro (muy duro) para comprender el problema a solucionar y estableciendo entonces objetivos y expectativas realistas para cualquiera que vaya a estar involucrado en el proyecto. Mantenerse. Muchos proyectos no realizan un buen comienzo y entonces se desintegran lentamente.Para mantenerse, el gestor del proyecto debe proporcionar Incentivos. Seguimiento del Progreso. Para un proyecto de software, el progreso se sigue mientras se realizan los productos del trabajo . Tomar Decisiones Inteligentes. En esencia, las decisiones del gestor del proyecto y del equipo de software deberan seguir siendo sencillas. Realizar un Anlisis Postmortem (despus definalizar el proyecto). Establecer un mecanismo consistente para extraer sabias lecciones de cada proyecto. Evaluar la planificacin real y la prevista, reunir y analizar mtricas del proyecto de software y realimentar con datos de los miembros del equipo y de los clientes, y guardar los datos obtenidos en formato escrito.

Solucion de exmenes 1. defina: a) gestin b) proyecto c) gestin de proyecto a) gestin: es la administracin b) proyecto: es un conjunto de actividades relacionadas para lograr un fin especifico, con un comienzo y un fin claro; con tres restaricciones principales:tiempo, presupuesto alcance. c) Gestin de proyecto: es a dministrar los proyectos o actividades para planificar, organizar, supervisar y controlar proyecto. 2. Porque aplicar la gestin de proyecto en el proceso de software. 3. Describa los pasos para la gestin de proyecto. pro