Gestión de proyectos informáticos

TEMA 1

El primer tema de la asignatura introduce el reto al que se enfrenta un ingeniero de software y que ya se menciona en el prefacio del libro de texto: desarrollar software que triunfe.

Entre los puntos de mayor interés de este tema destacan los siguientes:

El software no es solo código ejecutable, y el desarrollo de software no consiste únicamente en tareas de codificación.

La calidad es el objetivo. En un producto o servicio, la calidad la definen los consumidores. No basta con confiársela a un departamento de la empresa, sino que debe de ser promovida desde la dirección y asumida por todos los miembros de una empresa de desarrollo.

La ingeniería del software proporciona una estructura de proceso de desarrollo con actividades genéricas y sombrilla para desarrollar software de calidad.

En el desarrollo de una aplicación software hay muchos participantes (stakeholders) involucrados, no solo informáticos: gerentes, desarrolladores, clientes, usuarios, revisores, auditores, etc.

El mantenimiento y la reutilización son dos aspectos muy importantes que hay que considerar en el desarrollo.

Hay que diferenciar claramente entre proceso, proyecto y producto.

Inicialmente se adoptaron procesos de desarrollo “prescriptivos”, frente a los procesos “ágiles” que demandan los desarrollos actuales. Cualquier metodología de proceso se debe adaptar al proyecto concreto y emplear con flexibilidad; esto no quiere decir que se pueda implementar de manera desordenada.

El apartado 1.5 da claves importantes, como:

- no dar una solución sin pensar antes (aunque parezca una perogrullada, es algo muy habitual).

- buscar la simplicidad: donde dice “mantenlo sencillo” debería decir “mantenlo simple” (tan simple como sea posible, pero no más). Una solución simple no es sencilla de lograr (me ha ocupado 30 líneas, pero si hubiera tenido más tiempo lo habría resuelto en 5), aunque sí es sencilla de entender (lo que facilita el mantenimiento y reutilización).

-  tratar de resolver el problema general, no sólo uno específico.

Esperamos que el estudio de este capítulo les resulte de interés. Les animamos a resolver las 11 cuestiones planteadas en el último apartado.

TEMA 2

El segundo tema resulta de enorme importancia para el resto de la asignatura. En el se entra de lleno en el principal asunto de estudio de la ingeniería del software: el proceso de desarrollo.

Se han propuesto infinidad de modelos de proceso que en el libro se clasifican en distintas categorías: prescriptivos, especializados, proceso unificado, y personal y de equipo, dejando los modelos ágiles para el capítulo 3. Las fronteras que separan unos de otros no son estrictas, habiendo muchas características comunes entre ellos o siendo unos el resultado de la evolución de otros. Se presentan de forma general, y hay que considerar que la mayoría de ellos tiene distintas versiones y su descripción completa ocupa extensos manuales. La clasificación muestra las principales características que los diferencian, las aportaciones de cada uno de ellos y su idoneidad para un tipo de proyecto u otro.

Todos los modelos de proceso contemplan la estructura general de proceso presentada en el capítulo 1, ya que esta estructura es aplicable en el proyecto de desarrollo de cualquier producto (desde una terminal de aeropuerto a un largometraje). La estructura general se debe adaptar a las necesidades de cada proyecto y los modelos de proceso deben emplearse de manera flexible. Esta es la principal  conclusión que debe extraerse del estudio de este tema.

Lo anterior se ilustra en el apartado 2.1.1 en el ejemplo de "un proyecto de software pequeño solicitado por una persona (en una ubicación remota) con requerimientos sencillos y directos".

El modelo de ciclo de vida clásico o de la "cascada" es la primera propuesta específica que se hizo para el desarrollo de proyectos informáticos. Lo dicho antes sobre la flexibilidad a la hora de aplicar un modelo de proceso no anula la enorme importancia que tiene este modelo "prescriptivo" (rígido o estricto, aunque sus variantes contemplan realimentación y concurrencia entre fases), que deben haber estudiado ya en la asignatura Introducción a la Ingeniería del Software de segundo curso. El conocimiento de sus fases (análisis, diseño, codificación, integración y mantenimiento) y de los productos generados en cada una de ellas es imprescindible para la comprensión de esta asignatura. Su variante (solo en la forma de representación) en V ilustra los conceptos de validación y verificación que también deben conocer y que se tratarán más adelante en el curso.

La filosofía del modelo incremental, también incluido en la clasificación como "prescriptivo", es uno de los principios de los modelos ágiles (generalmente presentados como contrapuestos a los prescriptivos), como se verá en el próximo tema.

En el segundo párrafo de la página 42, donde dice "… , no se detecta una inconsistencia…", debe decir "… , se detecta una inconsistencia…".

El principio del segundo párrafo de la página 45 es una mala traducción de "A distinct a-o process has not yet matured": ningún modelo de proceso o-a reseñable ha madurado.

Las 17 cuestiones planteadas al final del capítulo les servirán para reflexionar y comprender mejor los contenidos de este.

Lean el enunciado de la primera PEC del curso pasado (fichero GPI_PEC1_2020.pdf disponible en "Exámenes anteriores") y traten de responder a las siguientes preguntas:

- ¿Qué acciones o tareas se requieren en la actividad de comunicación para el proyecto planteado?

- ¿Qué acciones o tareas asociadas a actividades sombrilla podrían acompañar a la actividad de comunicación en este proyecto?

                                TEMA 3

Este tercer tema está dedicado a los modelos de proceso "ágiles", sobre los cuales ya se ha adelantado algún detalle en los dos temas anteriores.

No se debe considerar la agilidad como una ruptura con los modelos tradicionales (apartado 3.3.2), cuyos métodos y principios se pueden seguir aplicando en muchos proyectos y en muchos casos están incluidos en los modelos ágiles, como ya se indicó. Tampoco se pueden aplicar todos los principios de la agilidad a cualquier tipo de proyecto. La máxima de flexibilidad y adaptabilidad apuntada en el tema anterior no se debe de olvidar.

El paradigma ágil busca adaptarse al cambio, en las múltiples facetas que puede presentarse en un proyecto informático (requisitos, tecnología empleada, equipo humano, aspectos sociales, financieros, legales, políticos, etc.), y aligerar el proceso, reduciendo la documentación no imprescindible e incidiendo en la búsqueda de soluciones simples (principio general de la ingeniería visto en el primer tema). Para lograrlo propone equipos de desarrollo auto-gestionados (apartado 3.3.3) y entregas rápidas de forma incremental, implicando al cliente en el desarrollo y promoviendo la comunicación para obtener realimentación tras cada entrega.

Los apartados 3.4 y 3.5 ilustran esta metodología de desarrollo con los principales métodos que se han propuesto, y que se utilizan en mayor o menor medida, basados en los principios de la agilidad. Respecto al modelo XP, hay que aclarar que, cuando en la página 62 se emplea el término "disciplina" como una característica del desarrollador ágil, no se refiere a su entrenamiento para obedecer reglas estrictas (lo que choca con los principios de la agilidad), sino a su capacidad de autocontrol y dedicación. Scrum es el otro método ágil que goza de mayor implantación; la breve descripción que se hace de el en el apartado 3.5.2 sirve para ilustrar el hecho de que la agilidad no tiene nada que ver con la improvisación. También se puede observar que ningún método ágil suprime por completo las tareas del análisis y diseño.

Las 18 cuestiones planteadas al final del capítulo les ayudarán a asimilar los contenidos estudiados en el.

Lean el enunciado de la primera PEC del curso 2018-2019 (fichero GPI_PEC1_2019.pdf) y traten de responder a las siguientes cuestiones:

- ¿Qué aplicaría de la agilidad (aspectos generales de la metodología y particulares de métodos concretos estudiados) para el desarrollo de este proyecto?

- ¿Qué aspectos de esta metodología no tiene sentido aplicar en este proyecto?

TEMA 4

Los principios que presenta el cuarto tema de la asignatura deben ser conocidos por todo ingeniero del software, más allá de herramientas y lenguajes de programación específicos, puesto que perduran aunque las tecnologías concretas cambien o evolucionen.

Como se observa en el apartado 4.2.1, las actividades sombrilla aparecen en forma de principios que hay que aplicar a lo largo de todo el proceso de desarrollo del software: aseguramiento de la calidad, gestión del cambio, gestión del riesgo, etc.

El apartado 4.3 sirve para profundizar en el conocimiento de las actividades estructurales del proceso estudiadas brevemente en el tema 1. Los principios que guían cada actividad podemos tomarlos como una guía de acciones y buenas prácticas necesarias en cada una de ellas.

...