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.

...