• Author / Uploaded
• sidane rc

Citation preview

Instituto

Instituto Tecnológico Superior De San Andrés Tuxtla Carrera

Ingeniería En Sistemas Computacionales Profesor@

MTI Montserrat Masdefiol Suárez Grupo

604 – A Alumnos

Angélica Rubí Baxin Ruiz Brenda Denis Vásquez Cortez Angélica Isabel Cagal Malaga Carolina Temich Fermán Elfega Denis Román Cortes Izbeth Berenice Pucheta Fiscal José Alberto Hernández Sánchez Juan Francisco Temich Ponciano Mónica Daisy Velasco Hernández Omar Chigo Acua Petra Yadira Hernández Texna Santiago Jesús Notario Gasca Asignatura

Gestión de Proyectos de Software Trabajo

U1 – Introducción a la Gestion De Proyectos. **1.2 Fases de la gestión de proyectos**

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

ÍNDICE INTRODUCCIÓN ....................................................................................................................... 3 1.2 FASES DE LA GESTIÓN DE PROYECTOS DE SOFTWARE ............................................ 3 EL PERSONAL. .................................................................................................................... 4 LOS PARTICIPANTES .................................................................................................... 4 EL PRODUCTO .................................................................................................................... 5 EL PROCESO ...................................................................................................................... 5 EL PROYECTO .................................................................................................................... 6 1.2.1 PLANIFICACIÓN .............................................................................................................. 6 OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES ............................... 7 Organización jerárquica ................................................................................................... 7 Organización horizontal ................................................................................................... 7 Organización de colegas .................................................................................................. 8 Fuentes de personal para un proyecto............................................................................. 8 1.2.2 PROPUESTA ................................................................................................................... 9 1.2.3 SELECCIÓN Y EVALUACIÓN DE PERSONAL ............................................................... 9 ADMINISTRACIÓN DE LA COMUNICACIÓN ................................................................. 9 OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES ............................. 10 FUENTES DE PERSONAL PARA UN PROYECTO. ..................................................... 13 1.2.4 SUPERVISIÓN Y REVISIÓN DEL PROYECTO ............................................................. 14 SUPERVISIÓN DE LOS RESULTADOS ....................................................................... 15 SEGUIMIENTO DE COSTES Y CALENDARIO ............................................................. 16 SEGUIMIENTO DE ASPECTOS TÉCNICOS ................................................................ 16 GENERACIÓN DE DATOS HISTÓRICOS .................................................................... 16 1.2.5 INFORMES ..................................................................................................................... 17 CONCLUSIÓN ......................................................................................................................... 18 BIBLIOGRAFÍA ........................................................................................................................ 18

2

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

INTRODUCCIÓN En el presente trabajo se explicarán los conceptos básicos del tema de fases de la gestión de proyectos, esta disciplina está encaminada a la aplicación de metodologías, técnicas, y herramientas para lo que son las fases de planeación, propuesta, selección y supervisión del personal que estará a cargo del proyecto, así como la supervisión y la revisión del mismo. La gestión de proyectos de software es una parte esencial de la ingeniería del software. La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente lleva al fracaso del proyecto. El software es entregado tarde, los costes son mayores que los estimados y los requerimientos no se cumplen. La gestión de proyectos es la rama de la ciencia de la administración que trata de planificar y llevar el control de proyectos, “la planificación consiste en determinar qué se debe hacer cómo debe hacerse, quién es el responsable de que se haga y por qué”, por lo tanto, para poder aplicar los métodos de la gestión de proyectos las actividades se deben dividir en tareas que no sean cíclicas, que se caractericen con precisión y que las relaciones entre cada una de ellas sean conocidas. Los gestores de software son responsables de la planificación y temporalización del desarrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estándares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto. La administración de proyectos de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones organizaciones de tiempo y presupuesto. El trabajo del gestor de proyectos de software es asegurar que éstos cumplan con dichas restricciones y entregar software que contribuya a las metas de la compañía de desarrollo de software. Sommerville, I. (2005). Ingenieria del software. España: Pearson.

1.2 FASES DE LA GESTIÓN DE PROYECTOS DE SOFTWARE La administración efectiva de un proyecto de software se enfoca en las cuatro P: personal, producto, proceso y proyecto. El orden no es arbitrario. El gerente que olvida que el trabajo de la ingeniería del software es una empresa intensamente humana nunca triunfará en la administración del proyecto. Un gerente que fracase en alentar una comunicación comprensiva con los participantes durante las primeras etapas de la evolución de un producto se arriesga a construir una solución elegante para el problema equivocado. El gerente que ponga poca atención al proceso corre el riesgo de insertar métodos y herramientas técnicos competentes, pero en el vacío. Aquel que se embarque sin un plan sólido pone en peligro el éxito del proyecto.

3

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

EL PERSONAL. Desde la década de 1960 se estudia la formación de personal de software motivado y enormemente calificado. De hecho, el “factor humano” es tan importante que el Software Engineering Institute desarrolló un Modelo de madurez de capacidades del personal (PeopleCMM, por sus siglas en inglés), en reconocimiento al hecho de que “toda organización requiere mejorar continuamente su habilidad para atraer, desarrollar, motivar, organizar y conservar la fuerza de trabajo necesaria a fin de lograr sus objetivos empresariales estratégicos”. El People-CMM define las siguientes áreas prácticas clave para el personal de software: plantilla, comunicación y coordinación, ambiente de trabajo, desempeño administrativo, capacitación, compensación, análisis y desarrollo de competencias, desarrollo profesional, desarrollo de grupo de trabajo y desarrollo de equipo/cultura, entre otros. Las organizaciones que conforme a este modelo logran altos niveles de madurez de capacidades de personal tienen una probabilidad muy elevada de alcanzar la implementación de prácticas administrativas efectivas en los proyectos de software. LOS PARTICIPANTES El proceso de software (y todo proyecto de software) está poblado de participantes, quienes pueden organizarse en alguna de las siguientes áreas: 1. Gerentes ejecutivos, quienes definen los temas empresariales que con frecuencia tienen una influencia significativa sobre el proyecto. 2. Gerentes de proyecto (técnicos), quienes deben planificar, motivar, organizar y controlar a los profesionales que hacen el trabajo de software. 3. Profesionales que aportan las habilidades técnicas que se necesitan para someter a ingeniería un producto o aplicación. 4. Clientes que especifican los requerimientos para el software que se va a fabricar, así como otros participantes que tienen un interés periférico en el resultado. 5. Usuarios finales, quienes interactúan con el software una vez que se libera para su uso productivo. Para lograr un equipo de alto rendimiento: • Los miembros del equipo deben tenerse confianza entre sí. • La distribución de habilidades debe ser adecuada para el problema. • Es posible que tenga que excluirse del equipo a los inconformes si debe mantenerse la cohesión del equipo. Sin importar el tipo de organización del equipo, el objetivo para todo gerente de proyecto es ayudar a crear un equipo que muestre cohesión.

4

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

EL PRODUCTO Antes de poder planear un proyecto, deben establecerse los objetivos y el ámbito del producto, considerarse soluciones alternativas e identificar las restricciones técnicas y administrativas. Sin esta información, es imposible definir estimaciones razonables (y precisas) del costo, una valoración efectiva del riesgo, una descomposición realista de las tareas del proyecto y un calendario de proyecto manejable que proporcione en cada momento un indicio significativo del progreso. Como desarrolladores de software, todos los participantes deben reunirse para definir los objetivos y el ámbito del producto. Los objetivos identifican las metas globales para el producto (desde el punto de vista de los participantes) sin considerar cómo se lograrán estas metas. El ámbito identifica los datos, funciones y comportamientos principales que caracterizan al producto y, más importante, intenta ligar dichas características en forma cuantitativa. Una vez comprendidos los objetivos y el ámbito del producto, se consideran soluciones alternativas. Aunque se analizan muy pocos detalles, las alternativas permiten a los gerentes y profesionales seleccionar un “mejor” enfoque, dadas las restricciones impuestas por fechas de entrega, restricciones presupuestales, disponibilidad de personal, interfaces técnicas y muchos otros factores.

EL PROCESO Un proceso de software proporciona el marco conceptual desde el cual puede establecerse un plan completo para el desarrollo de software. Un pequeño número de actividades de marco conceptual se aplica a todos los proyectos de software, sin importar su tamaño o complejidad. Algunos conjuntos de diferentes tareas (tareas, hitos, productos operativos y puntos de aseguramiento de calidad) permiten que las actividades del marco conceptual se adapten a las características del proyecto de software y a los requerimientos del equipo del proyecto. Finalmente, las actividades sombrilla (como el aseguramiento de la calidad del software, la administración de configuración del software y las mediciones) recubren el modelo de proceso. Las actividades sombrilla son independientes de cualquier actividad del marco conceptual y ocurren a lo largo del proceso. El equipo debe decidir qué modelo de proceso es más adecuado: 1) para los clientes que solicitaron el producto y el personal que hará el trabajo, 2) para las características del producto en sí y 3) para el entorno de proyecto donde trabaja el equipo de software. Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar con base en el conjunto de actividades del marco conceptual del proceso. Una vez establecido el plan preliminar, comienza la descomposición del proceso, es decir, debe crearse un plan completo que refleje las tareas laborales requeridas para poblar las actividades del marco conceptual.

5

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

EL PROYECTO Los proyectos de software se planean y controlan debido a una razón principal: es la única forma conocida para manejar la complejidad. E incluso así, los equipos de software todavía batallan. Actualmente la tasa de éxito para los proyectos de software puede haber mejorado un poco, la tasa de falla de proyecto sigue siendo mucho más alta de lo que debiera. Para evitar el fracaso del proyecto, un gerente de proyecto de software y los ingenieros de software que construyan el producto deben evitar un conjunto de señales de advertencia comunes, entender los factores de éxito cruciales que conducen a una buena administración del proyecto y desarrollar un enfoque de sentido común para planificar, monitorear y controlar el proyecto. Para cada proyecto de desarrollo de software se puede decir que existen dos puntos de partida: uno a nivel de empresa y otro a nivel del propio proyecto. El primero es un precedente necesario del segundo, ya que este último sólo tiene lugar cuando anteriormente la empresa ha tomado ya la decisión de emprender el proyecto. Pressman, R. s. (2010). Ingenieria del Software un enfoque Práctico. México: McGraw-Hill.

1.2.1 PLANIFICACIÓN La planificación del proyecto se refiere a la identificación de las actividades, hitos y entregas de un proyecto. Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto. Muchos planes incluyen las siguientes secciones: 1. Introducción. Describe brevemente los objetivos del proyecto y expone las restricciones (por ejemplo, presupuesto, tiempo, entre otros) que afectan a la gestión del proyecto. 2. Organización del proyecto. Describe la forma en que el equipo de desarrollo está organizado, la gente involucrada y sus roles en el equipo. 3. Análisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que surjan estos riesgos y las estrategias de reducción de riesgos propuestas 4. Requerimientos de recursos de hardware y software. Describe el hardware y el software de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario comprar hardware, se deben incluir las estimaciones de los precios y las fechas de entrega. 5. División del trabajo. Describe la división del proyecto en actividades e identifica los hitos y productos a entregar asociados con cada actividad. 6. Programa del proyecto. Describe las dependencias entre actividades, el tiempo estimado requerido para alcanzar cada hito y la asignación de la gente a las actividades.

6

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

7. Mecanismos de supervisión e informe. Describe la gestión de informes y cuándo deben producirse, así como los mecanismos de supervisión del proyecto a utilizar. El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como el calendario del proyecto, cambiarán frecuentemente; otras serán más estables. Para simplificarlas revisiones, se debe organizar el documento en secciones separadas que permitan su reemplazo de forma individual conforme evoluciona el plan. Sommerville, I. (2005). Ingenieria del software. España: Pearson. OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES Organización jerárquica En esta organización existe una gerente global, con tres personas que le reportan. El responsable de los aspectos de mercadotecnia del proyecto, es el que interactúa con los clientes para asegurar que el producto es lo que desean. Todos deben entender las líneas de autoridad y decisión, y el número de personas con quienes cada uno debe interactuar con regularidad es aceptable. La desventaja es que los miembros del equipo tienden a participar menos en las decisiones porque es probable que las tareas se asignen desde arriba. Si todo lo demás es igual, ésta es una manera segura de organizar un proyecto. Los proyectos más grandes organizados con este estilo jerárquico requieren organigramas más amplios. La ventaja de esta organización es el potencial para la motivación que viene con la participación por igual en el proyecto. Esto funciona bien en especial si el grupo es pequeño, muy competente y está acostumbrado a trabajar en equipo. Las desventajas incluyen la dificultad para resolver las diferencias y el hecho de que “nadie está a cargo”. Sólo establecer que todas las decisiones son participativas y por consenso (unanimidad) no hace que el proceso funcione de manera automática. El TSP de Humphrey es un conjunto específico de guías para este tipo de equipos. En última instancia, debe establecerse una mezcla de participación de colegas y responsabilidad de liderazgo adecuada para el tamaño del proyecto, su naturaleza, su madurez y las personas involucradas. Organización horizontal La idea es que los miembros del equipo son iguales, excepto por el líder designado. En la situación ideal, él debe estimular la participación de los miembros del equipo, pero debe tomar decisiones cuando se requiere. Los papeles pueden intercambiarse una vez durante un periodo de tres meses para proporcionar a los miembros del equipo una experiencia más amplia. Como cada papel es crítico, es buena idea designar un tipo de “sistema de amigos” para cada líder. El amigo del ingeniero puede hacerse cargo si el líder está incapacitado. Él o ella deben inspeccionar el resto de los trabajos de los ingenieros.

7

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

Organización de colegas Promueve que los artefactos cambien de manos sin problemas de una etapa a la siguiente, pues cada ingeniero se familiariza con el producto de la etapa anterior a la que él o ella será el responsable. Conforme el número de participantes crece en un proyecto, la organización pura de los colegas se convierte en algo imposible debido a que el número de vínculos de comunicación, crece con el cuadrado del número de participantes. Una alternativa para proyectos grandes es realizar los grupos de colegas pequeños y se designa un miembro de cada grupo como comunicador con los otros grupos. Este tipo de organización intenta preservar los beneficios de los equipos pequeños, pero cuenta con muchas personas para construir una aplicación extensa. Es de conocimiento general que es raro el ingeniero con aptitudes para labores tanto de ingeniería como de administración. Fuentes de personal para un proyecto En las organizaciones orientadas a proyectos, el personal del proyecto reporta al gerente del proyecto en el sentido organizacional. Él o ella es su jefe. Un ingeniero de software está ligado de todas las maneras a un proyecto específico, y no tiene afiliación organizacional con los otros ingenieros de software en otros proyectos de la compañía. Esto tiene la ventaja de simplificar las líneas de autoridad, pero la desventaja de aislar a los ingenieros en el sentido profesional. Por ejemplo, las compañías pequeñas casi siempre están organizadas con una orientación a los proyectos, pero incluso en las grandes se ve esta organización, en especial cuando intentan resaltar el enfoque en el cliente. En términos generales, las estructuras según el reporte de actividades son más complejas que en las organizaciones orientadas a proyectos, debido al uso de la organización matricial. En estas organizaciones, los empleados pertenecen a unidades funcionales (como ingeniería, ventas, etcétera) y se prestan a los proyectos. Así, el supervisor de un ingeniero de software “la persona responsable de evaluarlo” sería miembro de la unidad funcional de ingeniería de software. Sin embargo, dentro de cada proyecto en el que trabaje estará supervisado por el líder del proyecto. Por lo común, los ingenieros están incluidos en un proyecto, a veces dos, pero muy pocas veces más. Las organizaciones matriciales tienen la ventaja de mejorar las aptitudes y el profesionalismo, y la desventaja de debilitar las líneas de autoridad. Las compañías con frecuencia intentan encontrar un punto medio entre las organizaciones matriciales y las orientadas a proyectos. Braude. Ingeniería de software Una perspectiva orientada a objetos. Alfaomega

8

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

1.2.2 PROPUESTA La propuesta describe los objetivos del proyecto y cómo se llevaría a cabo. Por lo general, incluye estimaciones de coste y tiempo y justifica por qué el contrato del proyecto se le debe dar a una organización o a un equipo en particular. La redacción de la propuesta es una tarea crítica, ya que la existencia de muchas organizaciones de software depende de las propuestas aceptadas y los contratos asignados. No existen guías para esta tarea; la redacción de propuestas es una habilidad que se adquiere con la práctica y la experiencia.

1.2.3 SELECCIÓN Y EVALUACIÓN DE PERSONAL Por lo general, los gestores de proyectos tienden a seleccionar a las personas para trabajar en su proyecto. De forma ideal, habrá personal disponible con habilidades y experiencia apropiada para trabajar en el proyecto. Sin embargo, en muchos casos, los gestores tienen que establecer un equipo ideal mínimo para el proyecto. Las razones que explican esto son:  

 

El presupuesto del proyecto no cubre la contratación de personal con sueldos altos. Se tiene que contratar personal con menos experiencia y menor sueldo. El personal con experiencia apropiada no está disponible dentro o fuera de la organización. Es imposible reclutar nuevo personal para el proyecto. Dentro de la organización, los mejores trabajadores ya se han asignado a otros proyectos. La organización desea desarrollar las habilidades de sus empleados. El personal inexperto puede ser asignado al proyecto para aprender y adquirir experiencia. El gestor de software tiene que trabajar con estas restricciones al seleccionar el personal del proyecto, Sin embargo, todos estos problemas son probables a menos que exista un miembro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. Sin esta experiencia, probablemente se cometerán muchos errores pequeños.

En este apartado se analizan los aspectos organizacionales de los equipos de proyecto desde dos perspectivas. Primero, ¿Cuál es la estructura de responsabilidades del proyecto? Segundo, ¿de dónde viene la gente y a quién reportan? De cualquier modo, poco se puede lograr a menos que los participantes se comuniquen de manera adecuada. ADMINISTRACIÓN DE LA COMUNICACIÓN La experiencia del autor y de otra muestra que el número de desarrolladores con quienes cada desarrollador debe interactuar con regularidad debe ser entre tres y siete. Los estudios formales acerca del efecto del tamaño del equipo sobre el desempeño son raros, en la figura 1 ilustra los extremos que llevan a las recomendaciones del tamaño del equipo. En un extremo, el desarrollador trabaja de manera individual sin interacciones del tamaño del equipo. En un extremo, el desarrollador trabaja de manera individual sin interacción habitual con otros. Aunque no gaste tiempo en comunicación, ese aislamiento suele repercutir en malos entendidos

9

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

respecto a lo que se espera del desarrollador, y conducir a un nivel relativamente bajo de efectividad. En el otro extremo, el desarrollador tiene que interactuar por rutina con tantos individuos que no queda tiempo para realizar el desarrollo en sí, y de nuevo el resultado es inefectividad. En particular, “comunicación habitual” implica hablar con alguien para algo, alrededor de dos horas a la semana. Si un ingeniero tiene una comunicación, lo que le deja sólo media semana para su contribución individual. Los organizadores del proyecto deben tener esto en cuenta cuando planeen proyectos, ya sea de diez o de cien personas.

Fig1. Tamaño óptimo aproximado para la interacción OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES La estructura jerárquica de la administración, figura 2, es un extremo organizacional. Las ventajas de este esquema organizacional son que todos entienden las líneas de autoridad y decisión, y el número de personas con quienes cada uno debe de interactuar con regularidad es aceptable. Las desventajas es que los miembros del equipo tienden a participar menos en las decisiones porque es probable que las tareas se asignen desde arriba. Si todo lo demás es igual, ésta es una manera segura de organizar un proyecto. Los proyectos más grandes organizados con este estilo jerárquico requieren organismos más amplios.

10

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

Fig. 2 Organización jerárquica para la administración de proyectos El otro extremo organizacional hay un equipo que consiste en una comunidad que colegas con las mismas autoridades. La ventaja de esta organización es el potencial para la motivación que viene con la participación por igual en el proyecto. Esto funciona bien en especial si el grupo es pequeño, muy competente y está acostumbrado a trabajar en equipo. Las desventajas incluyen la dificultad para resolver las diferencias y el hecho de que “nadie está a cargo”. En última instancia, debe establecerse una mezcla de participación de colegas y responsabilidad de liderazgo adecuado para el tamaño del proyecto, su naturaleza, su madurez y las personas involucradas. Un punto medio es la estructura de organización horizontal, como ilustra la figura 3. La idea es que los miembros del equipo son iguales, excepto el líder designado.

Fig. 3

Organización horizontal para la administración de proyectos

En las situaciones ideales, él debe estimular la participación de los miembros del equipo, pero debe tomar decisiones cuando se requiere. En la figura 4 muestra una forma más detallada para la organización de los equipos. Si hay cinco integrantes, entonces uno de ellos tal vez

11

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

quiera ser el líder de requerimientos al igual que líder de implementación, ya que sólo una de estas actividades tiene tareas en un tiempo dado. Se puede prescindir del líder de requerimientos, aunque alguien debe ser responsable de mantener el ERS (especificación de requerimientos de software, documento que establece lo que una aplicación debe lograr). Los papeles pueden intercambiarse una vez durante un periodo de tres meses para proporcionar a los miembros del equipo una experiencia más amplia. Como cada papel es crítico, es buena idea designar un tipo de “Sistema de amigos” para cada líder. El líder amigo del ingeniero puede hacerse cargo si está incapacitado.

Fig. 4. Una manera de organizar un equipo (PAPS: Plan de administración del proyecto de software, PACS: Plan de administración de la configuración del software, PAQS: Plan de aseguramiento de la calidad de software, PPS: Plan de prueba de software, ERS: Especificación de requerimientos de software, DDS: Documento de diseño de software.) Él o ella deben inspeccionar el resto de los trabajos de los ingenieros. El esquema de respaldo de la figura 4 promueve que los artefactos cambien de manos sin problemas de una etapa anterior a la que él o ella será el responsable. Conforme al número de participantes crece en un proyecto, la organización pura de los colegas se convierte en algo imposible debido a que el número de vínculos de comunicación (entre todos los pares) crece con el cuadro del número de participantes. Una alternativa para proyectos grandes es la organización que se muestra en la figura 5 donde los grupos de colegas son pequeños y se designan un miembro de cada grupo como comunicador con los otros grupos. Este tipo de organización intenta preservar los beneficios de los equipos pequeños, pero cuenta con muchas personas para construir una aplicación extensa.

12

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

Fig. 5. Organización de colegas para proyectos grandes. Es de conocimientos general que es raro el ingeniero con aptitudes para labores tanto de ingeniería y de administración. Sin embargo, el autor ha observado que muchos ingenieros se han desempañado bien dirigiendo grupos, incluso cuando muy pocos esperaban que pudieran.

FUENTES DE PERSONAL PARA UN PROYECTO. En las organizaciones orientadas a proyectos, el personal del proyecto reporta el gerente del proyecto en el sentido organizacional. Él o ella es su jefe. Un ingeniero de software está ligado de las maneras a un proyecto en específico, y no tiene afiliación organizacional con los otros ingenieros de software en otros proyectos en la compañía. Esto tiene la ventaja de simplificar las líneas de autoridad, pero la desventaja de aislar a los ingenieros en el sentido profesional. Por ejemplo, las compañías pequeñas casi siempre están organizadas con una orientación a los proyectos, pero incluso en las grandes se ve esta organización, en especial cuando intentan resaltar el enfoque en el cliente. En términos generales la estructura según el reporte de actividades es más complejas que en las organizaciones orientadas a proyectos, debido al uso de la organización matricial. En estas organizaciones, los empleados pertenecen a unidades funcionales (ingeniería, ventas, entre otros) y se presenta los proyectos figura 6.

13

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

Así el supervisor de unos ingenieros de software- la persona responsable de evaluarlo- sería miembro de la unidad funcional de ingeniería de software. Sin embargo, dentro de cada proyecto en el que trabaje estará supervisado por el líder del proyecto. Braude, E. J. (s.f.). Ingeniería de Software. Una perspectiva Orientada a Objetos.

1.2.4 SUPERVISIÓN Y REVISIÓN DEL PROYECTO La supervisión del proyecto es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Aunque muchas organizaciones tienen mecanismos formales para supervisar, un gestor hábil podría formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con el personal del proyecto. La supervisión informal predice problemas importantes del proyecto, y revela dificultades que pueden aparecer, Por ejemplo, las entrevistas diarias con el personal del proyecto pueden exteriorizar un problema en un fallo del software. Más que esperar un informe de atraso del proyecto, el gestor de software podría asignar algún experto para resolver el problema o podría decidir si se vuelve a programar. Durante el proyecto, es normal tener varias revisiones formales de su gestión. Se hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se tiene en cuenta el estado del proyecto junto con los propósitos de la organización que ha encargado el software. El resultado de una revisión puede dar lugar a la cancelación del proyecto, El tiempo de desarrollo para un proyecto grande de software puede ser de varios años. Durante ese tiempo los objetivos organizaciones tienden obviamente a cambiar. Estos cambios pueden significar que el software ya no se necesita o que los requerimientos originales del proyecto son inapropiados. La gestión puede decidir parar el desarrollo del software o cambiar el proyecto para adecuarlo a los cambios de los objetivos de la organización.

14

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

SUPERVISIÓN DE LOS RESULTADOS Para conseguir el primer objetivo, se han de desarrollar las siguientes actividades: 

Desarrollar estándares que establezcan las condiciones o medidas que deben cumplir cuando se realizan correctamente las diferentes tareas del proyecto.  Establecer sistemas de supervisión y de informes, para lo cual hay que determinar: los datos necesarios. Quién los recibe y cuándo se reciben  Medir los resultados. Lo que permite determinar la consecución o la desviación de los objetivos y estándares. Los jefes de proyecto deben discutir la necesidad de controlar sus proyectos de acuerdo a los planes establecidos. El reto es utilizar las herramientas y las técnicas disponibles de forma efectiva, es decir, gestionar el esfuerzo de tal forma que el personal acepte los objetivos que debe cumplir dentro de unos tiempos y recursos dados. Sin embargo. Pueden existir problemas que llevan a salir del calendario y sobrepasar l presupuesto. Algunos de estos problemas son:  Dificultad para definir el trabajo con el detalle suficiente.  Poca implicación del equipo de proyecto durante la planificación.  Problemas con la organización y la constitución del equipo del proyecto.  Organización del equipo del proyecto insuficientemente definida.  El proyecto se considera poco importante o interesante.  No existen planes de contingencia.  Mala comunicación con la dirección y con el cliente.  Mala comprensión en las líneas de comunicación en la organización.  Dificultad al trabajar entre distintos departamentos de la organización.  Mala dirección del proyecto.  Poca asistencia y ayuda de la dirección.  El jefe de proyecto no se compromete con el equipo.  Dificultades la valorar los riesgos. Algunas de las razones que conducen a los problemas anteriores son;         

Planificación insuficiente. Plan del proyecto no relista. Cambios del cliente/dirección. Planificación de contingencia insuficiente. Incapacidad para controlar el progreso. Incapacidad de detectar los problemas tempranamente. Número de puntos de verificación insuficiente. Problemas de la plantilla. Complejidades técnicas.

15

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

SEGUIMIENTO DE COSTES Y CALENDARIO Muchas organizaciones muestran un gran interés en el seguimiento de cortes y calendario. Con frecuencia, se exige que las organizaciones mantengan sistemas de informes de costes y progresos muy formales. Sin embargo, es fundamental reconocer las limitaciones de tales sistemas. Muchas organizaciones asumen que el seguimiento de los costes frente a los presupuestos y el seguimiento de los sucesos frente al calendario, representan todo el control del progreso que necesitan. Si no existe un informe serio de las variaciones, se supone que todo va bien. Sin embargo, puede que los jefes de proyecto sufran un shock cuando surjan problemas serios, aparentemente fuera de contexto. Por lo tanto, además de los costes y del calendario, también es necesario tratar aspectos más técnicos del estado del proyecto del software. Específicamente, el seguimiento de los recursos críticos del proyecto y el seguimiento del tamaño de los productos software. SEGUIMIENTO DE ASPECTOS TÉCNICOS Para comprender la importancia de estos aspectos técnicos, pensaremos, por ejemplo, en un proyecto que trata de mejorar una función (por ejemplo, control de temperatura), similar a las de proyectos anteriores, dentro de un período limitado de tiempo. Al terminar el diseño preliminar, el prototipo construido muestra que el algoritmo probado más rápido no alcanza los requisitos de tiempo establecidos. Desde el punto de vista del sistema de informes de coste y de progreso, no existe ningún problema visible, ya que el diseño preliminar se finalizó a tiempo y los costes son concordantes con el presupuesto. Pero el personal técnico sabe, de antemano, que existe una dificultad. Si el jefe de proyecto les obliga, pueden ocultar el problema durante un largo tiempo (al menos hasta la fase de integración y pruebas). También pueden abordar el problema inmediatamente y así resolverlo mientras todavía hay tiempo. En cualquier caso, el control más riguroso de los informes del estado del coste y calendario no pueden detectar este problema. Solo un control directo suplementario de los aspectos técnicos críticos del proyecto traerá el problema a primer plano de atención de la dirección o el jefe del proyecto. A veces, puede que los problemas técnicos o de la plantilla sean la causa de una desviación respecto al plan. En este caso, hay que supervisar dichos problemas y no enmascararlos respecto al cambio en la planificación: “no trate de estar bien hoy a expensas de mañana”. En definitiva, el jefe de proyecto tiene que valorar cuidadosamente el motivo y el impacto de un cambio en la planificación. De esta forma, se tendrán presiones hoy, pero cuando se llegue a los hitos importantes, el proyecto cumplirá sus objetivos. GENERACIÓN DE DATOS HISTÓRICOS Otro aspecto importante del seguimiento y la supervisión de proyectos es la generación de datos históricos para utilizarlos como soporte de estimación de futuros desarrollados. De nuevo, los sistemas de seguimiento económicos pueden interferir en la tarea. Si el objetivo es saber en qué se gasta el dinero, entonces no hay necesidad de mantener un seguimiento de las horas extraordinarias no remuneradas. Como resultado, muchos sistemas de seguimiento económico

16

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

no requieren registrar tales horas e, incluso, algunos lo tienen prohibido y archivan no más de cuarenta horas por semana y por empleado. Este enfoque causa problemas cuando los registros almacenados se utilizan como fuente de datos históricos para la estimación y planificación de un nuevo proyecto. En un proyecto donde el nivel de horas extraordinarias no remuneradas está limitado (por ejemplo, en un 10-20%), la distorsión de los datos históricos estará limitada en igual proporción. Sin embargo, en muchas organizaciones, el nivel de horas extras no remuneradas puede fácilmente alcanzar el 25%. El 50% o incluso el 100% de las horas pagadas, y estos niveles pueden mantenerse durante semanas, meses o, incluso, años. Cuando las horas no registradas alcanzan este nivel, datos como “números de horas para finalizar el diseño preliminar” o “productividad de la plantilla por día” están seriamente distorsionados. Las estimaciones basadas en tales datos históricos erróneos conducen inevitablemente a estimaciones inapropiadas de las horas necesarias para las tareas, dando como resultado una planificación muy ajustada y un presupuesto muy bajo. Pero, ¿Qué se hace en estos casos? La respuesta es obvia: incluir más horas extras no remuneradas. La organización esta así en un ciclo destructivo que algunos han denominado “la espiral de la muerte”. La frase “mantener dos juegos de libros de contabilidad” tiene una connotación negativa, porque la gente lo asocia con el uso de múltiplos registros económicos para realizar un fraude. Pero las organizaciones deben reconocer que, mientras existan las horas extraordinarias no remuneradas, el seguimiento del dinero y el seguimiento del esfuerzo real son cosas distintas. Si aquellos que están a cargo del sistema económico están dispuestos a asumir la tarea extra de seguimiento del esfuerzo real, esté pagado o no, entonces no hay problema. Sin embargo, si no están dispuestos a hacerlo, entonces el mantenimiento de un informe del esfuerzo real realizado debe convertirse en una tarea de alta prioridad en la organización independientemente del esfuerzo pagado. Con frecuencia, el mero hecho del seguimiento de esas horas y su informe a la dirección, abrirá sus ojos a la carga de trabajo que han estado poniendo en su plantilla y les sensibilizará con los impactos producidos por la planificación de los proyectos. Piattini, M. G. (2004). Análisis y diseño de Aplicaciones Informáticas de Gestión una perspectiva de Ingeniería del Software. México: Alfaomega.

1.2.5 INFORMES Los gestores del proyecto son responsables de informar a los clientes y contratistas sobre el proyecto. Tienen que redactar documentos concisos y coherentes que resuman la información crítica de los informes detallados del proyecto. Les debe ser posible presentar esta información durante las revisiones de progreso. En consecuencia, comunicarse efectivamente de forma oral y escrita es una habilidad esencial que un gestor de proyectos debe tener, Sommerville, I. (2005). Ingenieria del software. España: Pearson.

17

GESTIÓN DE PROYECTOS DE SOFTWARE “UNIDAD 1-FASES DE LA GESTIÓN DE PROYECTOS” 704-A

MTI. MONTSERRAT MASDEFIOL SUÁREZ

CONCLUSIÓN Como se mencionó anteriormente, la Gestión de Proyectos trata de planificar y llevar el control de proyectos, por lo que, aplicados al software, podemos decir que se convierte en la llamada Gestión de Proyectos de Software, integrada por la planificación, una propuesta, la selección y evaluación del personal y los informes. Cada uno de ellos a su vez cuenta con pasos indispensables a realizar para que la gestión pueda cumplir el objetivo. Con esto equipo de trabajo concluye que es importante conocer estos aspectos ya que estas bases son necesarias para lograr comprender la forma en que se debe elaborar una Gestión de Proyecto de Software exitosa.

BIBLIOGRAFÍA Braude, E. J. (s.f.). Ingeniería de Software. Una perspectiva Orientada a Objetos. Pressman, R. s. (2010). Ingenieria del Software un enfoque Práctico. México: McGraw-Hill. Sommerville, I. (2005). Ingenieria del software. España: Pearson Braude, E. J. (s.f.). Ingeniería de Software. Una perspectiva Orientada a Objetos.Alfaomega Piattini, M. G. (2004). Análisis y diseño de Aplicaciones Informáticas de Gestión una perspectiva de Ingeniería del Software. México: Alfaomega.

18