Diapositiva 1

ObjetivosComprender los conceptos generales sobre la Gestin de Proyectos de software.Comprender la importancia que tiene la gestin de proyectos de software.Resolver algunos problemas de aplicacin relacionados a la Gestin de Proyectos.

Quin lo hace?Todos gestionan en cierta medida, pero el mbito de las aplicaciones de las actividades de gestin vara entre las personas involucradas en un proyecto de software.Un Ingeniero de Software gestiona sus actividades diarias.Los gestores de proyectos planifican, supervisan y controlan el trabajo de un equipo de ingenieros de software.Porqu es importante?La construccin de software de computadora es una empresa compleja, en particular si involucra a muchas personas durante un tiempo relativamente largo, por ello es necesario la gestin.

EL ESPECTRO DE LA GESTION DE PROYECTOS La gestin eficaz de un Proyecto de Software se centra en 4 P

PersonalProductoProcesoProyecto

Todas estas etapas son importantes, el orden no es arbitrario.Gestores Superiores: Definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.Gestores del Proyecto: Son los que planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo.Profesionales: Son los que proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. Clientes: Son los que especifican los requisitos del proyecto.

Usuarios finales: Son los que interactan con el producto entregado.

1. PERSONALLos participantes que colaboran en el Proceso de Software se pueden clasificar en:

Debe existir un nivel de madurez alto en la gestin de personal ya que el personal es fundamental para el xito de los proyectos, debe haber personal motivado.El modelo de madurez de gestin de personal define las siguientes reas claves prcticaspara el personal de software:ReclutamientoSeleccinGestin de desempeoEntrenamientoRetribucinDesarrollo de la carreraDiseo de la organizacinTrabajoDesarrollo de la cultura de tiempoSe debe poder reclutar adecuadamente al personal, luego de ello elegimos a los candidatos que formaran parte de nuestro grupo de ingenieros de software, debe haber una excelente gestin del desempeo de los miembros, se debe entrenar al personal, se debe pagar adecuadamente segn las funciones que realice una persona y la capacidad intelectual por su trabajo o un servicio.El desarrollo de la carrera es responsabilidad de cada persona, no de la empresa. Las personas que no desarrollan su propia carrera terminan siendo menos competitivas y suelen ser las que pierden sus empleos. Debe crearse una adecuada estructura de la empresa, respetar las jerarquas.El trabajo debe realizarse de forma eficiente.Hay que desarrollar una cultura de tiempo, aprovechar el tiempo al mximo.Personal,caractersticas y participantes

El equipo de softwareNo todo grupo es un equipo, y no todo equipo es eficiente.

Para planificar la estructura de los equipos de ingeniera de software se debe tomar en cuenta:

La dificultad del problema que se resolver.El tamao del programa resultante.Dependiendo de la complejidad, as se puede elegir si tener personal sumamente capacitado, o con experiencia media. Tambin se puede decidir la cantidad de personas, lo mismo se considera dependiendo de las lneas de cdigo resultantes.El tiempo que el equipo estar junto.El grado en que el problema pueda separarse en mdulos.La calidad y la confiabilidad requerida.La rigidez de la fecha de entrega.El grado de sociabilidad (comunicacin) que requiere el proyecto.

La vida del equipo prcticamente es el tiempo en el cual estarn trabajando juntos.Si se va a separar en mdulos generalmente se necesitan varios equipos trabajando en paralelo.Si por ejemplo se arriesgan vidas humanas o se puede perder mucho dinero por un software de mala calidad es mejor tener equipos con experiencia y bien capacitados.Si se desea terminar rpido, y es imposible mover las fechas de entrega, es mejor no arriesgarse y contar con ms personal.Paradigmas organizacionales para los equipos de ingeniera de software:

Paradigma cerrado:Estructura un equipo a lo largo de una jerarqua tradicional de autoridad. Pueden trabajar mejor cuando producen software muy similar a los proyectos anteriores, pero ser menos probable que sean innovadores cuando trabajan con este paradigma.

Paradigma aleatorio:Estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo. Cuando se requiere innovacin o adelantos tecnolgicos, los equipos que siguen el paradigma aleatorio sern excelentes. Pero estos equipos pueden luchar cuando se requiere desempeo ordenado

Paradigma abierto:Intenta estructurar un equipo de una forma que logre algunos de los controles asociados con el paradigma cerrado, pero tambin mucha de la innovacin que ocurre cuando se aplica el paradigma aleatorio. El trabajo se desarrolla en colaboracin. Las decisiones son en consenso. Se adecuan bien a la solucin de problemas complejos, pero no pueden desempearse de manera tan eficiente como otros equipos.

Paradigma sincrnico:Se apoya en la compartimentalizacin natural de un problema y organiza a los miembros del equipo para trabajar en partes del problema con poca comunicacin activa entre ellos.

Hay que tener cuidado con la toxicidad de los equiposTienen una atmsfera de trabajo frentica.Alta frustracin que provoca friccin entre los miembrosUn equipo pobremente coordinadoUna definicin poco clara de los papeles del equipo de softwareContinuas exposiciones al fracaso.

2. PRODUCTOAntes de Planificar un proyecto se deben establecer: Objetivos mbito del Producto Soluciones alternativas Dificultades Tcnicas Dificultades de GestinSin sta informacin es imposible definir Estimaciones de Costo Valorizacin del Riesgo Planificacin del Proyecto

El mbito es un espacio comprendido dentro de unos lmites determinados, es decir los lmites que tendr el producto de software.Antes de planificar cualquier proyecto se deben tener claros muchos elementos, se debe decidir de que forma se har el trabajo, se decide la alternativa ms adecuada y luego se comienza a planificar.Deben tenerse claros todos los riesgos que se pueden presentar, y si se presentan como los vamos a resolver, por ejemplo pueden haber dificultades tcnicas, de gestin y otras ms.Si un requerimiento va a elevar los costos del proyecto se debe pensar en eliminarlo si no es realmente necesario.

PRODUCTOEl desarrollador de software y el cliente se deben reunir para definir los objetivos y el mbitodel producto

PRODUCTO

Contexto son las circunstancias bajo las cuales un dispositivo est siendo utilizado, por ejemplo el uso actual del usuario. 3. PROCESOLo definiremos como un marco de trabajo de las tareasque se requieren para desarrollar Software de Alta Calidad.

Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software.Las actividades protectoras (como el control de calidad del software, la gestin de configuracin y la medicin) cubren el modelo del proceso.Todos los Proyectos de Software deben ser PLANIFICADOS Y CONTROLADOS

por una razn principal: Poder gestionar su complejidad

4. PROYECTO

PROYECTOLos proyectos de software se realizan de manera planificada y controlada por una razn principal: Es la nica forma conocida de gestionar la complejidad.Un proyecto es como un viaje por carretera. Algunos proyectos son simples y rutinarios, como conducir hacia la tienda a plena luz del da. Pero la mayora de los proyectos que vale la pena realizar son ms parecidos a conducir un camin en la carretera, en la montaa, de nochePROYECTO10 seales que indican que un proyecto de sistema de informacin est en peligro:El personal de software no entiende las necesidades de sus clientes.El mbito del producto est mal definido.Los cambios se gestionan mal.La tecnologa elegida cambia.Las necesidades comerciales cambian o estn mal definidas.Los plazos de entrega no son realistas.Los usuarios se resisten.Se pierde el patrocinio.El equipo de proyecto carece de personal con las habilidades apropiadas.Los gestores evitan las mejores prcticas y lecciones aprendidas.Retroalimentacin de repaso personalQu entiende por gestin de proyectos de software?Haga un pequeo resumen de las 4P?Cul es el elemento central de todos los proyectos, explquese?

El Principio W5HH Boehm sugiere un enfoque que aborde los objetivos del proyecto, los hitos y planificacin, responsabilidades, gestin y enfoques tcnicos y recursos requeridos. Boehm lo llama el principio W5HH, en honor a una serie de preguntas que conducen a una definicin de las caractersticas claves del proyecto y al plan de proyecto resultante:Por qu se desarrolla el sistema? La respuesta a esta pregunta permite a todas las partes evaluar la validez de las razones del negocio para el trabajo de software. Dicho de otra forma: el propsito del negocio justifica el gasto de personal, tiempo y dinero?

Qu se har? La respuesta a esta pregunta establece el conjunto de tareas que se requerir para el proyecto.

Quin es el responsable de una funcin? Prrafos atrs se anot que el papel y la responsabilidad de cada miembro del equipo de software deben estar definidos. La respuesta a esta pregunta ayuda a lograrlo.

Dnde estn ubicados en la organizacin? No todos los papeles y responsabilidades residen en el equipo de software. El cliente, los usuarios y otros participantes tambin tienen responsabilidadesCmo se har el trabajo desde los puntos de vista tcnico y de gestin? Una vez establecido el mbito del producto se debe definir una estrategia de gestin y tcnica para el proyecto.

Cunto de cada recurso se necesita? La respuesta a esta pregunta se deriva al desarrollar estimaciones con base en las respuestas a las preguntas anteriores.

Lecturas complementariasSi desean ampliar sus conocimientos sobre el tema, pueden consultar el captulo 21 del libro texto de Roger Pressman.Tarea (vendr en el parcial paginas 647-650 libro de texto de Pressman)Investigar que son los equipos programador jefe, equipo cuajado, equipo con anarqua innovadora.Investigar que son los conflictos de coordinacin y comunicacin.Muchas graciasPersonal

Participantes

Lideres de equipo

Gestores Ejecutivos

Gestores del proyecto

Profesio_nales

Clientes

Clientesdirectos

Con caractersticas como

Organizacin

Ideas o innovacin

Resolucin de problemas

Dotes de gestin

Incentivos

Influencia y fomento de la cultura de equipo

Motivacin

EL PRODUCTO

mbito del software

Contexto

Objetivos de informacin

Funcin y desempeo

Descomposicin del problema