proyectos de software 2.1. introducciÓnrossainz/ingsw... · ingeniería de sw primavera 2020-cap2...

Ingeniería de SW Primavera 2020-Cap2 Dr. Mario Rossainz López

18

2. Planificación de Proyectos de Software

2.1. INTRODUCCIÓN La gestión efectiva de un proyecto de software depende de planear completamente el progreso del proyecto. El gestor o líder del proyecto debe anticiparse a los problemas que podrían surgir, así como preparar soluciones tentativas a esos problemas.

La Planificación de un Proyecto de Software es el conjunto de actividades necesarias que deben llevarse a cabo para desarrollar el proyecto.

La Planificación es probablemente la actividad que más consume tiempo

Existe una actividad continua desde el concepto inicial del proyecto hasta que este es liberado. Los planes deben ser revisados regularmente a medida que esta disponible nueva información.

La estructura sugerida por Sommerville para generar un plan de Proyecto o de Desarrollo de software es la siguiente: 1. Introducción: Describe brevemente los objetivos del proyecto y expone las restricciones del

mismo (por ejemplo, presupuesto, tiempo, etc.) que afectan su gestión. 2. Organización del Proyecto: Describe la forma en que el equipo de desarrollo está organizado,

la gente involucrada y sus tareas 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 la ayuda del

software requerida para llevar a cabo el desarrollo. Si es necesario comprar hardware, se deben incluir los estimados 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 a cada actividad.

6. Programa del Proyecto: Describe las dependencias entre las actividades, el tiempo estimado requerido para alcanzar cada hito y la asignación de la gente a las actividades.

7. Mecanismos de supervisión e informe: Describe la gestión de informes y cuando deben producirse, así como los mecanismos de supervisión del proyecto a utilizar.

Además de un plan de proyecto, los líderes suelen preparar otros tipos de planes, tales como los que se describen en la tabla que aparece en la página siguiente. El pseudocódigo que se muestra a continuación descreibe el proceso que se sigue en la planeación de un proyecto para el desarrollo de software. Establecer las restricciones del proyecto

hacer las suposiciones iniciales de los parámetros del proyecto

Definir hitos del proyecto y productos a entregar

while el proyecto no se haya completado o cancelado loop

Describe la planificación de tiempos del proyecto

Inicia las actividades de acuerdo a la planificación

Espera (a que se lleve a cabo el desarrollo)

Revisa el progreso del proyecto

Revisa los parámetros estimados del proyecto

Actualizar la planificación del proyecto

Renegociar las restricciones del proyecto y los productos a

entregar

if (aparecen problemas) then

inicia una revisión técnica y sus posibles soluciones

end if

end loop


19

El pseudocódigo anterior muestra que la planeación es un proceso iterativo que solamente se completa cuando el proyecto mismo se termina.

2.1.1. HITOS Y PRODUCTOS A ENTREGAR Los líderes necesitan información para gestionar el proyecto. Como el software es intangible, esta información sólo se puede proveer como documentos que describan el estado del software que se está desarrollando. Sin esta información es imposible saber del progreso del proyecto y no se pueden actualizar costos o calendarios. Cuando se planea un proyecto se deben establecer hitos. Un hito es un punto final de una actividad del proceso del software. En cada uno debe existir una salida formal, como un informe, que se debe presentar al gestor. Los hitos deben representar el fin de una etapa lógica en el proyecto. Un producto entregable es el resultado del proyecto que se entrega al cliente. De forma general, se entrega al final de una fase principal del proyecto como la especificación, el diseño, etc. Un producto a entregar es un hito, pero no todos los hitos son productos entregables, es decir, existen hitos internos del proyecto que son utilizados por el gestor del mismo para verificar el progreso de dicho proyecto pero que no se entregan al cliente. Para poder definir un hito, el proceso del software debe descomponerse en actividades básicas con sus salidas asociadas. La siguiente figura muestra por ejemplo las actividades involucradas en la especificación de requerimientos basada en la construcción de prototipos y las salidas o hitos principales de cada actividad.

Plan Descripción

Plan de Desarrollo

Plan de Calidad

Plan de Validación

Plan de Mantenimiento

Describe la metodología a utilizar en el desarrollo

del proyecto.

Describe los procedimientos de calidad, y los

estándares a utilizar en el proyecto.

Describe el enfoque, los recursos y la programación

utilizados para la validación del sistema.

Predice los requerimientos de mantenimiento del

sistema, los costos del mantenimiento y el esfuerzo.

Describe como se adquirirán y desarrollarán los

conocimientos y habilidades del personal. Plan de Desarrollo

Personal


20

2.2. CALENDARIZACION DEL PROYECTO La Calendarización del Proyecto es una representación gráfica de todas las actividades del proyecto necesarias para producir el resultado final que permite al gestor del proyecto coordinar de una forma efectiva al equipo de desarrollo durante el transcurso del mismo. El calendario es dinámico, es decir, puede variar a medida que avanza el proyecto por cambios no previstos en su extensión, plazos, etc. El proceso de la calendarización tiene las siguientes características u objetivos:

Distribuye el proyecto en tareas y estima el tiempo y los recursos requeridos para completar cada tarea

Organiza las tareas de forma concurrente para hacer mejor uso de la fuerza laboral

Minimiza la dependencia entre tareas para evitar retrasos debidos a que una tarea espere a la terminación de otra

Depende de la intuición y experiencia de los gestores Sin embargo la calendarización provoca problemas tales como los siguientes:

Es difícil estimar la longitud y dificultad de las tareas, por lo que la estimación del costo es más difícil.

La productividad no es proporcional al número de personas trabajando en una tarea.

Incluir personal en un proyecto en avance, retrasa el proyecto por “overheads” en la comunicación.

Lo inesperado siempre sucede. Es necesario considerar siempre contingencias.

Estudio de

Factibilidad Análisis de

Requerimientos

Informe de

Factibilidad

Desarrollo

de

Prototipos

Estudio del

Diseño

Diseño de la

Arquitectura Informe de

Evaluación Definición de

Requerimientos

Especificación

de

Requerimientos

Requerimientos

Del sistema

ACTIVIDADES

HITOS


21

El modelo gráfico del proceso de calendarización del proyecto es el siguiente:

Normalmente, las actividades del proyecto deben durar por lo menos una semana y también es útil asignar una cantidad de tiempo máxima para realizar cualquier actividad, es decir, se deben considerar el tiempo más temprano (early) y el tiempo más tardío (last) para iniciar y terminar una actividad de acuerdo al tiempo máximo que se le dedique a dicha actividad. El recurso principal que los gestores deben estimar para completar las tareas es el esfuerzo humano que se requiere. Por lo general, el calendario del proyecto se representa como un conjunto de gráficos que muestran la división del trabajo, las dependencias de las actividades y la asignación del personal. Existen herramientas de administración y gestión de software que se utilizan para automatizar la producción de diagramas tales como Microsoft Proyect o Visio 2003 también de Microsoft. El calendario es por tanto un programa de tiempos que, para que sea efectivo, debe tener las siguientes características:

Comprensible por todas aquellas personas que van a utilizarlo

Detallado para que con él se puedan medir y controlar el progreso del proyecto

Capaz de señalar actividades críticas

Flexible y fácilmente modificable

Basados en estimaciones de tiempos fidedignas

Ajustable a los recursos disponibles

Compatible con los planes de otros proyectos que compartan los mismos recursos. Cori señala que, para desarrollar un calendario es necesario realizar siete pasos en el orden que se expone a continuación:

Identificar

Actividades

Identificar

Dependencias

de

Actividades

Requerimientos

de Software

Estimar

recursos

para las

actividades

Asignar

personas

A las actividades

Crear

Gráficos

de proyectos

Redes de actividades

Gráficos de barras


22

Definición de los Objetivos del proyecto: La primera tarea de un gestor de proyecto es la de clarificar los objetivos del proyecto en términos cuantificables para así asegurar que el producto final cumpla con los requisitos del cliente. Un Objetivo de Proyecto es un enunciado que

especifica los resultados que se deben conseguir. Para que un objetivo de proyecto quede bien definido, éste tiene que ser accesible en el sentido de que la meta identificada por dicho objetivo pueda conseguirse en unos tiempos y restricciones dadas, definitivo para especificar concretamente qué es lo que se debe lograr y en qué grado de detalle, cuantificable en el sentido de especificar un criterio de finalización y de duración específica para definir la duración de las actividades y así evaluar el progreso del proyecto.

Descomposición de las actividades: El gestor, una vez determinado los objetivos puede descomposición el proyecto en una serie de actividades que hay que realizar a distinto nivel de detalle. Puede hacer uso de un diagrama jerárquico para representar la actividad más general del proyecto y a partir de allí subdividirla en actividades más sencillas. Además de mostrar las actividades, se indican las personas responsables de su finalización.

Relación entre las actividades: Las actividades tienen que estar relacionadas por lo que hay que determinar sus secuencias y dependencias. Para programas sencillos los llamados diagramas de Gantt son suficientes para estimar la relación entre el tiempo y la carga de trabajo aunque no muestran las interrelaciones entre las distintas actividades. Para planificar proyectos grandes, se utilizan técnicas basadas en redes de precedencia tales como los diagramas PERT y CPM. Las redes de precedencia relacionan las actividades de forma que podemos identificar aquellas que sean críticas. Además se pueden reflejar en una escala de tiempos para facilitar la distribución de recursos y presupuestos.

Estimación de tiempos y costos de las actividades: Una vez definida la secuencias de las actividades, se debe realizar una estimación del tiempo que debe transcurrir entre el comienzo y final de una actividad. Estas estimaciones se basan en el tiempo requerido para finalizar una actividad.

Reajuste del programa de tiempos a las restricciones del proyecto: El objetivo de esta parte es determinar la duración total del proyecto, identificar las actividades que contribuyen a la duración total del proyecto (actividades críticas) y calcular las holguras de las actividades que no son críticas.

Asignación de los recursos/definición de la organización del equipo: Una vez ajustado el calendario a las restricciones de tiempo, hay que ajustarlo respecto a los recursos disponibles. Para suavizar la carga de trabajo, el gestor debe fijarse en aquellas actividades que tengan holguras y ajustar las fechas de comienzo de algunas actividades no críticas que de otra manera podrían darse en periodos de gran carga de trabajo. Si esto no se puede hacer, se debe aumentar la duración de las actividades críticas, aumentando así la duración total del proyecto.

Revisión del calendario: Una vez hecho el calendario, es necesario realizar una revisión del mismo para determinar si es o no realista. Se deben considerar los efectos de las revisiones técnicas y de gestión, los periodos vacacionales, los conflictos o las restricciones de recursos. Así mismo, se debe asegurar que el calendario sea lo suficientemente flexible como para acomodarse a los retrasos no previstos.


23

2.2.1. TECNICAS DE CALENDARIZACION Existen varias técnicas que se pueden utilizar en la realización de un calendario. Algunas son muy simples como la tabla de hitos, los diagramas de Gantt o la técnica Full-Wall las cuales no contemplan la interrelación entre las actividades. Pero existen otras técnicas más complicadas que muestran la interrelación de las actividades donde se requiere del análisis de las redes de precedencia tales como los diagramas de PERT o la técnica CPM.

2.2.1.1. Tabla de Hitos: Es el método más simple para determinar el calendario. Es un cuadro o tabla formada por dos columnas; en la primera se señalan las actividades y en la segunda se indican o bien las fechas de finalización o los días que duran las actividades junto con los hitos que habrán de concretar las actividades. Una ventaja de esta técnica es la facilidad de uso y el bajo costo en su preparación. Las desventajas son la incertidumbre sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.

Tareas o Actividades Duración (días)

T1 8

T2 15

T3 15 (M1)

T4 10

T5 10 (M2)

T6 5 (M3)

T7 20 (M1)

T8 25 (M5)

T9 15 (M4)

T10 15 (M7)

T11 7 (M6)

T12 10 (M8) Tabla de Hitos

2.2.1.2. Diagramas de Gantt El diagrama de Gantt suele utilizarse en proyectos de máximo 25 actividades y es el más utilizado pues aunque con estos diagramas no es posible representar las dependencias entre las actividades, es más fácil representar sus posibles solapamientos (actividades concurrentes) que en una red PERT o CPM. Estas dos últimas técnicas suelen trasladarse a un diagrama de Gantt. El diagrama de Gantt se puede utilizar para estimar los recursos y el presupuesto en función del tiempo identificando el total de recursos para una actividad y calculando el total para todas las actividades que ocurran durante un periodo de tiempo específico. El diagrama de Gantt por tanto es un histograma donde se hace una referencia cruzada entre las tareas y los tiempos de duración de las mismas. Opcionalmente se pueden incluir los hitos que habrán de generarse al terminar alguna actividad mediante un rombo completamente relleno. Además se pueden definir con colores diversos los retrasos máximos que pueden tener las actividades.


24

Tareas o Actividades Duración (días) Dependencias)

T1 8 8

T2 15 15

T3 15 T1 (M1)

T4 10 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8) Tabla de Hitos Ampliada a relaciones de precedencia

Diagrama de Gantt o Histograma de Actividades Este mismo diagrama de Gantt se puede utilizar para representar las asignaciones de las actividades a cada uno de los miembros que conforman el equipo de trabajo, por parte del gestor, en los mismos tiempos de duración de dichas actividades.


25

Diagrama de Gantt o Histograma de Asignación de Actividades

2.2.1.3. Técnica FULL-WALL o Programa de Tiempos En esta técnica se determina el calendario en una reunión en la que intervienen todas las personas que trabajarán en el proyecto. En una sala de reunión se forma un cuadro en una pared en el que las líneas verticales representan semanas de trabajo y las horizontales representan las actividades que debe hacer el equipo del proyecto. El gestor tiene que haber desarrollado un diagrama de Hitos y una lista de actividades, donde se indica quienes son los responsables de cada una. Cada actividad se escribe en dos tarjetas. La primera tarjeta se etiqueta como <<inicio>> y la segunda como <<final>>. A cada miembro del equipo se le dan las tarjetas apropiadas. Cada persona clava la tarjeta en la pared en la semana de su elección. La disposición de las tarjetas se modificará reiteradamente hasta que se hayan tratado todas las interrelaciones y restricciones de las actividades y el calendario sea accesible. Entonces el gestor hace una copia del calendario escrito en la pared y lo distribuye a cada uno de los miembros del equipo del proyecto.

2.2.1.4. Redes de Precedencia Existen dos técnicas principales basadas en grafos para la planificación de proyectos, que son PERT (Program Evaluation and Review Tecnique) y CPM (Critical Path Method). Estas técnicas son muy parecidas entre sí aunque provienen de estudios muy diferentes. La primera, es decir, PERT se inicia en 1957 por problemas surgidos en la planificación y control del proyecto Polaris; la segunda o CPM parte de la necesidad de programar y controlar los proyectos de mantenimiento de las plantas de fabricación de la empresa E. I. Du Pont. Posteriormente estas técnicas se amplían tratando la relación existente entre el costo y la duración de las actividades. De esta manera surge la planificación de proyectos con costo mínimo.


26

Es conveniente utilizar estas técnicas cuando un proyecto:

Tiene todas sus actividades bien definidas

Las actividades se pueden comenzar, interrumpir y realizar de forma separada dentro de una secuencia dada

Las actividades se pueden relacionar con otras

Las actividades están ordenadas de forma que se pueda seguir una secuencia

Una vez comenzada una actividad, debe continuar sin interrupción hasta su finalización. La red es un grafo que señala las relaciones secuenciales entre los sucesos claves en un proyecto. PERT y CPM pueden mostrar el camino crítico, que es la secuencia más larga de actividades conectadas a través de la red y que determina la duración total del proyecto. Esta técnica también permite visualizar las tareas que no son críticas. Las principales diferencias entre PERT y CPM son:

La técnica CPM se enfoca en las actividades, mientras que PERT se enfoca en los eventos o sucesos. Esto da la ventaja a los diagramas de PERT a considerar los eventos como hitos del proyecto, lo cual facilita el control de la gestión.

PERT permite el tratamiento de la probabilidad para su estimación de tiempo, mientras que CPM no.

Ejemplo de una Red de Actividades CPM


27

1 2 A

J H G

I

C

B

AD

P L

K

F

E

M

0 4 5 6

4

2 3

83

3 7 4

1 2 3 5

4

6 7

8

9

0 0 0 0 4

7

10 11

18 18

22 22

15 154 9

4

7

6

9

Ejemplo de una Red de sucesos y actividades PERT

Existen varias reglas a considerar en el desarrollo de una red PERT o CPM:

1. La red debería tener un mínimo de veinte eventos. Para proyectos más pequeños es más apropiado un diagrama de Gantt.

2. Las redes que se realicen manualmente deben estar limitadas a un máximo de 300 sucesos. Si son más, se hace necesario el utilizar alguna herramienta que gestione la técnica de forma automática.

3. Los proyectos que justifican el uso de un gran número de actividades o eventos son: a. Muy críticos b. De alto riesgo o incertidumbre c. Que involucran a muchas personas u organizaciones d. Técnicamente complejos e. Con actividad en diversas localidades geográficas

2.2.1.4.1. La Técnica PERT Parte de la descomposición de un proyecto en actividades. Las actividades ocurren entre dos sucesos (un suceso inicial y un suceso final). Un suceso es un acontecimiento o punto temporal (una fecha) que no consume recursos. La representación se realiza por medio de un grafo en donde las actividades se reflejan mediante arcos y los sucesos mediante vértices, como lo muestra la figura siguiente: El vértice 1 representa el suceso inicial de la actividad A y el vértice 2 el suceso final de la actividad. La longitud del arco no tiene relación alguna con la duración de la actividad. El siguiente paso es la determinación de las relaciones entre las actividades. Habrá que estudiar entonces para cada actividad las relaciones de precedencia, esto es, las actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada. Existen varios tipos de relaciones de precedencia:


28

1 2 A 3 B

2 4 B 5 D

1

3

A

C

4 2 A 1 C

3

5 D

B

Las Relaciones de precedencia lineales: Donde por ejemplo, para iniciar una actividad B es necesario haber finalizado una actividad A anterior. En la figura de abajo, el suceso 2 es un suceso final de la actividad A y a su vez un suceso inicial de la actividad B. Las Relaciones de Precedencia Convergentes: Donde para iniciar una actividad digamos D es necesario haber finalizado antes más de una actividad, digamos A, B y C, tal como se muestra en la figura de abajo: Las Relaciones de Precedencia Divergentes: Donde para poder iniciar cuales quiera de más de una actividad, digamos las actividades B, C o D, es necesario que haya finalizado una actividad precedente, digamos A; tal como se ve en la figura siguiente:


29

B

A

C

E

D

B

A

C

E

D

F

Es obvio que se pueden dar combinaciones de cada tipo de relaciones, sin embargo existen casos en los que, para determinadas combinaciones existen conflictos, por ejemplo, supongamos que tenemos las siguientes relaciones:

Las actividades A y B preceden a la actividad D

Las actividades A, B y C preceden a la actividad E Según estas relaciones el grafo que las representaría sería el siguiente: Observamos que en el grafo se cumple la segunda regla pero no la primera, ya que es necesario que finalice la actividad C para comenzar la actividad D. Para resolver este problema, se añade una actividad ficticia F, de duración cero, tal como se muestra en el siguiente grafo:

2.2.1.4.2. Creación del grafo de PERT mediante un ejemplo Supongamos que tenemos que llevar a cabo un proyecto cuya descomposición en actividades nos arroja 8: A, B, C, D, E, F, G y H. Las relaciones entre estas actividades son las siguientes:

A precede a B, C y D

B precede a E

C precede a F

D precede a G y

E, F preceden a H


30

Existen dos formas de recoger este conjunto de relaciones: la llamada matriz de encadenamientos y el cuadro de relaciones de precedencia: La matriz de encadenamientos es una matriz cuadrada cuya dimensión coincide con el número de actividades en las que se ha descompuesto un proyecto. Sea Mij un elemento de la matriz, si Mij=X

entonces, para poder iniciar la actividad i, es necesario que haya finalizado la actividad j. En el caso del ejemplo la matriz de encadenamientos sería la siguiente:

A B C D E F G H

A

B X

C X

D X

E X

F X

G X

H X X El cuadro de relaciones de precedencia es una tabla de dos columnas. En la primera columna se representan las actividades en las que se descompone el proyecto y en la segunda las actividades precedentes que deben contemplarse:

ACTIVIDADES ACTIVIDADES PRECEDENTES

A -

B A

C A

D A

E B

F C

G D

H E,F

Una vez creada la matriz de encadenamientos o el cuadro de relaciones de precedencias se procede a construir el grafo:

Actividades Precedentes Ac t. S i gu i e n t e

s


31

La representación del grafo es sencilla sin embargo, cuando tenemos un número mayor de actividades, se hace necesario ordenar el grafo por niveles utilizando el llamado algoritmo de Demoucron. Éste algoritmo parte de la matriz de adyacencia M de un grafo G de n-vértices. Para aplicar el algoritmo al grafo anterior, construimos inicialmente la matriz de adyacencia de dicho grafo:

Matriz de Adyacencia del Grafo de la figura anterior

1 2 3 4 5 6 7

1 0 1 0 0 0 0 0

2 0 0 1 1 1 0 0

3 0 0 0 0 0 1 0 4 0 0 0 0 0 1 0

5 0 0 0 0 0 0 1

6 0 0 0 0 0 0 1

7 0 0 0 0 0 0 0 Una vez que tenemos esta matriz, incluimos una columna V1 (con un número de elementos igual al número de vértices del grafo). El contenido de los valores de la columna V1 es:

j=n

V1(i) = aij j=1

es decir, la suma de las filas de la matriz de adyacencia: V1(1) = 1 v1(2) = 3 v1(3) = 1 v1(4) = 1

V1(5) = 1 v1(6) = 1 v1(7) = 0

1 2

3

4

5

6

7

A

B

C

D

E

F

G

H


32

1 2 3 4 5 6 7 V1

1 0 1 0 0 0 0 0 1

2 0 0 1 1 1 0 0 3

3 0 0 0 0 0 1 0 1

4 0 0 0 0 0 1 0 1

5 0 0 0 0 0 0 1 1

6 0 0 0 0 0 0 1 1

7 0 0 0 0 0 0 0 0

7

En la parte inferior de la columna V1 se incluyen aquellos sucesos en los que V1(i) = 0, que en este caso es el vértice 7, es decir V1(7)=0. Este vértice formará parte del último nivel en el que se ordenará el grafo:

1 2 3 4 5 6 7 V1 V2 V3 V4 V5

1 0 1 0 0 0 0 0 1 1 1 1 0

2 0 0 1 1 1 0 0 3 3 2 0 X

3 0 0 0 0 0 1 0 1 1 0 X X

4 0 0 0 0 0 1 0 1 1 0 X X

5 0 0 0 0 0 0 1 1 0 X X X

6 0 0 0 0 0 0 1 1 0 X X X

7 0 0 0 0 0 0 0 0 X X X X

7 5 3 2 1

6 4

NIVELES DEL GRAFO V IV III II I A continuación se añade otra columna V2. Para calcular los valores V2(i) de esta columna, se buscan primero los valores de la columna anterior donde v1(i)=0. Los valores de V2(i) se hallan restando a los valores de V1(i) los valores de las columnas en los que los vértices i tienen un valor v1(i)=0. En el caso del ejemplo, se elige la columna ai7 y en la fila i (en este caso filas 5 y 6) en donde ai7 = 1, se resta el valor de V1(i). V2(1)= v1(1) – a1,7 = 1-0 =1 V2(2)= v1(2) – a2,7 = 3-0 =3 V2(3)= v1(3) – a3,7 = 1-0 =1 V2(4)= v1(4) – a4,7 = 1-0 =1 V2(5)= v1(5) – a5,7 = 1-1 =0 V2(6)= v1(6) – a6,7 = 1-1 =0 Los valores que en la columna de V1(i) = 0, en la siguiente columna se reemplazan por X. Se realiza el mismo procedimiento hasta llegar al suceso inicial, que estará en el nivel I.


33

1 2

4

3

6

5

7 A

B

C

D

E

F

H

G

I II III IV V

V3(1)= v2(1) – (a1,5 + a1,6) = 1-(0+0) =1 V3(2)= v2(2) – (a2,5 + a2,6) = 3-(1+0) =2 V3(3)= v2(3) – (a3,5 + a3,6) = 1-(0+1) =0 V3(4)= v2(4) – (a4,5 + a4,6) = 1-(0+1) =0 V4(1)= v3(1) – (a1,3 + a1,4) = 1-(0+0) =1 V4(2)= v3(2) – (a2,3 + a2,3) = 2-(1+1) =0 V5(1)= v4(1) – a1,2 = 1- 1 =0 El grafo resultante entonces, queda ordenado en 5 niveles; en el Nivel I debe estar el vértice 1, en el Nivel II el vértice 2, en el Nivel III los vértices 3 y 4, en el Nivel IV los vértices 5 y 6, finalmente en el Nivel V el vértice 7:

Grafo Ordenado por Niveles usando el algoritmo de Demoucron En seguida se calculan las asignaciones de los tiempos de cada actividad. PERT considera que la duración de las actividades es una variable aleatoria de la que se conoce su distribución de probabilidades. Se consideran entonces 3 tiempos para cada actividad: La estimación de tiempo pesimista (TP): Que representa el tiempo máximo en el que podría finalizar la actividad si se dan todas las circunstancias negativas que pueden surgir durante su realización. La estimación de tiempo más probable (TN): que representa el tiempo normal de duración de la actividad considerando que hay problemas durante las actividades, pero no aparecen en su totalidad.


34

La estimación de tiempo optimista (TO): que representa el tiempo mínimo si no aparece ningún problema durante la realización de la actividad.

En base a estas estimaciones, se calcula el tiempo PERT T como:

T = (TP + 4TN + TO) / 6

Cuya varianza es: = [ SQRT ( (TP-TO)/6 ) ] 2 Una vez calculados los tiempos que tardan en realizarse cada actividad, se calculan los tiempos early (tiempo más temprano posible en que puede ser iniciada/finalizada una actividad) y last (tiempo más tardío posible en que puede ser iniciada/finalizada una actividad) de cada suceso descrito en el grafo PERT. Para ello nos basaremos en la figura siguiente:

Representación de los tiempos early y last de una actividad

2.2.1.4.3. Cálculo de los tiempos más tempranos posibles (EARLY) El tiempo early del suceso j, que representaremos por TEj será igual a:

TEj = máximo [TEi + Tij]

Donde TEi es el tiempo early del suceso i y Tij es la duración de la actividad que comienza en el suceso i y finaliza en el suceso j. Es decir, se calcula sumando los tiempos early de los sucesos en los que nace una actividad que finaliza en el suceso j, la duración de la actividad y eligiendo el mayor. En el ejemplo que hemos estado llevando en este tema, supongamos que se tienen calculados los tiempos PERT de cada una de las actividades y que son los siguientes:

Suceso i

TEi TLi

Suceso j

TEj TLj

Tiempo más temprano para comenzar la

actividad A (tiempo early de comienzo de A)

Tiempo más tardío para

comenzar la actividad A

Tiempo más temprano para

finalizar la actividad A

Tiempo más tardío para

finalizar la actividad A


35

A

B

C

D

E

F

H

G

1

0

2

8

3

13

4

14

5

13

6

21

8

5

6

5

6

7

3

9

7

24

ACTIVIDAD A B C D E F G H

DURACION 8 3 6 5 6 7 9 3 TE1=0 (El suceso inicial siempre tiene un tiempo early de 0) TE2=máximo [TE1+T1,2] = máximo[0+8 ] = 8 TE3=máximo [TE2+T2,3] = máximo[8+5 ] = 13 TE4=máximo [TE2+T2,4] = máximo[8+6 ] = 14 TE5=máximo [TE2+T2,5] = máximo[8+5 ] = 13 TE6=máximo [TE3+T3,6 , TE4+T4,6] = máximo[13+6 , 14+7 ] = máximo[19,21] = 21 TE7=máximo [TE6+T6,7 , TE5+T5,7] = máximo[21+3 , 13+9 ] = máximo[24,22] = 24

Cálculo de los tiempos EARLY

2.2.1.4.4. Cálculo de los tiempos más tardíos posibles (LAST) El resto de los tiempos LAST se calculan usando la siguiente fórmula:

TLi = mínimo [TLj - Tij], j Donde TLj es el tiempo last del suceso j y Tij la duración de la actividad que comienza en el suceso i y finaliza en el suceso j. Es decir, se calcula restando a los tiempos last de los sucesos en los que finalizan actividades que nacen en el suceso i, la duración de las actividades y eligiendo el menor.


36

A

B

C

D

E

F

H

G

1

0 0

2

8 8

3

13 15

4

14 14

5

13 15

6

21 21

8

5

6

5

6

7

3

9

7

24 24

TL7= TE7= 24 (El tiempo last del último suceso coincide con su tiempo early.) TL6=mínimo [TL7 – T6,7] = mínimo[24 -3 ] = 21 TL5=mínimo [TL7 – T5,7] = mínimo[24 -9] = 15 TL4=mínimo [TL6 – T4,6] = mínimo[21 -7] = 14 TL3=mínimo [TL6 – T3,6] = mínimo[21 -6] = 15 TL2=mínimo [TL3 – T2,3 , TL4 – T2,4 ] = mínimo[15 -5 , 14-6] = mínimo [10,8] = 8 TL1=mínimo [TL2 – T1,2] = mínimo[8 -8] = 0

Cálculo de tiempos early y LAST

2.2.1.4.5. Holgura total de una actividad y camino crítico Para definir la holgura total de una actividad es necesario definir previamente el concepto de holgura de un suceso i como:

Hi = TLi - TEi La holgura de un suceso indica el número de unidades de tiempo en las que se puede retrasar su realización de forma que no aumente la duración total del proyecto. Se dice que un suceso es crítico si Hi = 0. Los sucesos críticos del ejemplo que hemos venido utilizando son: Holgura de los sucesos del ejemplo: H1 = TL1 – TE1 = 0 – 0 = 0 (Suceso 1 crítico) H2 = TL2 – TE2 = 8 – 8 = 0 (Suceso 2 crítico) H3 = TL3 – TE3 = 15 – 13 = 2 H4 = TL4 – TE4 = 14 – 14 = 0 (Suceso 4 crítico) H5 = TL5 – TE5 = 15 – 13 = 2 H6 = TL6 – TE6 = 21 – 21 = 0 (Suceso 6 crítico) H7 = TL7 – TE7 = 24 – 24 = 0 (Suceso 7 crítico)


37

A

B

C

D

E

F

H

G

1

0 0

2

8 8

3

13 15

4

14 14

5

13 15

8

6

21 21

5

6

5

6

7

3

9

7

24 24

La Holgura total de una actividad que une el suceso i con el suceso j se define como:

HTij = TLj – TEi - Tij

y representa el número de unidades de tiempo que puede retrasarse la realización de la actividad con respecto al tiempo PERT previsto sin que aumente la duración del proyecto. Si la actividad H del ejemplo aumenta dos unidades de tiempo, el tiempo final del proyecto se verá afectado de igual modo: TEi=TEj =26. Sin embargo la actividad E tiene una holgura total de:

HT3,6 = TL6 – TE3 – T36 = 21 – 13 – 6 = 2 (Holgura total de la actividad E del ejemplo) Luego entonces, podemos retrasar esta actividad como máximo 2 unidades de tiempo más sin que se retrase la finalización del proyecto. Las actividades que tienen una holgura total igual a cero se denominan actividades críticas. Uniendo todas las actividades críticas se forma un camino desde el suceso inicial hasta el suceso final del proyecto, que recibe el nombre de camino crítico que en el grafo del ejemplo es representado por una línea gruesa (de color rojo). Cualquier retraso que sufra alguna de las actividades del camino crítico implicará un retraso del proyecto.

HT1,2 = TL2 – TE1 – T1,2 = 8 – 0 – 8 = 0 (Holgura total de la actividad A del ejemplo) HT2,3 = TL3 – TE2 – T2,3 = 15 – 8 – 5 = 2 (Holgura total de la actividad B del ejemplo) HT2,4 = TL4 – TE2 – T2,4 = 14 – 8 – 6 = 0 (Holgura total de la actividad C del ejemplo) HT2,5 = TL5 – TE2 – T2,5 = 15 – 8 – 5 = 2 (Holgura total de la actividad D del ejemplo) HT3,6 = TL6 – TE3 – T3,6 = 21 – 13 – 6 = 2 (Holgura total de la actividad E del ejemplo) HT4,6 = TL6 – TE4 – T4,6 = 21 – 14 – 7 = 0 (Holgura total de la actividad F del ejemplo) HT5,7 = TL7 – TE5 – T5,7 = 24 – 13 – 9 = 2 (Holgura total de la actividad G del ejemplo) HT6,7 = TL7 – TE6 – T6,7 = 24 – 21 – 3 = 0 (Holgura total de la actividad H del ejemplo)


38

2.3. ADMINISTRACION DE RIESGOS Una actividad importante del gestor de un proyecto software es la de anticiparse a los riesgos que podrían afectar la calendarización del proyecto o la calidad del software que se desarrolla y emprender acciones para evitar esos riesgos. Un riesgo se define como la probabilidad de que una circunstancia adversa ocurra en el desarrollo de un proyecto software. La administración de riesgos es el proceso que se realiza para identificar los riesgos que podrían afectar la programación del proyecto, la calidad del software y la creación de planes, y así una vez identioficados, minimizar sus efectos en el proyecto. Por tanto, los riesgos son una amenaza para el proyecto, para su organización y para el software que se esta desarrollando. Los riesgos se categorizar en: 1. Riesgos del Proyecto: Afectan la calendarización o los recursos del proyecto. 2. Riesgos del Producto: Afectan la calidad o desempeño del software que se esta desarrollando. 3. Riesgos del Negocio: Afectan a la organización que desarrolla el software. La administración de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes que afectan muchos proyectos. El gestor de proyectos debe anticiparse a los riesgos; comprender el impacto de éstos en el proyecto, en el producto y en el negocio; y considerar pasos o metodologías para evitarlos. En el caso de que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación. Los tipos de riesgos que pueden afectar un proyecto dependen de éste y del entorno organizacional en el que se esté desarrollando el mismo. No obstante muchos riesgos son universales. En la tabla siguiente se muestran algunos de ellos:

RIESGO TIPO DE RIESGO

DESCRIPCION

Rotación de Personal Proyecto Personal con experiencia, abandona el proyecto

Cambio de Admon. Proyecto Cambio de Admon. Organizacional.

No disponibilidad del HW

Proyecto El HW esencial para el proyecto no será entregado

a tiempo.

Cambio de requerimientos

Proyecto y Producto

Habrá más cambios en los requerimientos

Retrasos en la especificación

Proyecto y Producto

Las especificaciones de las interfaces no estarán a tiempo

Subestimación del tamaño

Proyecto y Producto

El tamaño del sistema se ha subestimado

Bajo desempeño de la herramienta CASE

Proyecto y Producto

Las herramientas CASE utilizadas no tienen el rendimiento anticipado

Cambio de tecnología Negocio La tecnología sobre la que se construye el

producto es sustituida por la nueva tecnología

Competencia del Producto

Negocio Un producto competitivo se pone en venta antes

de que el sistema se complete.


39

Un proceso de administración de riesgos comprende varias etapas: 1. Identificación de riesgos: Identificar los posibles riesgos para el proyecto, el producto y los

negocios. 2. Análisis de Riesgos: Valorar las probabilidades y consecuencias de estos riesgos. 3. Planeación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar

sus efectos en el proyecto 4. Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la

mitigación de riesgos tan pronto como la información de los riesgos esté disponible.

2.3.1. IDENTIFICACION DE RIESGOS Comprende el descubrimiento de los posibles riesgos del proyecto. Esta identificación se puede llevar a cabo a través de un trabajo de equipo utilizando la técnica de lluvia de ideas, o simplemente puede estar basada en la experiencia del gestor del proyecto. Para ayudar en el proceso de esta identificación se utiliza una lista de los posibles tipos de riesgos que puede haber entre los que se incluyen: 1. Riesgos de Tecnología: Se derivan de las tecnologías de SW o de HW utilizadas en el sistema

que se esta desarrollando. 2. Riesgos de Personas: Riesgos asociados con las personas en el equipo de desarrollo. 3. Riesgos Organizacionales: Se derivan del entorno organizacional donde el software se esta

desarrollando 4. Riesgos de Herramientas: Se derivan de las herramientas CASE y otro software de apoyo

utilizado para desarrollar el sistema 5. Riesgos de Requerimientos: Se derivan de los cambios de los requerimientos del cliente y el

proceso de administrar dicho cambio. 6. Riesgos de Estimación: Se derivan de los estimados administrativos de las características del

sistema y los recursos para construirlo. La siguiente tabla da algunos ejemplos de posibles riesgos en cada una de las categorías de la lista anterior. El resultado de este proceso debe ser una listas de riesgos que podrían ocurrir y afectar el producto, el proceso o el negocio.


40

Tipo de Riesgo Riesgos Posibles

Tecnología

La BD que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba.

Los componentes de SW a reutilizarse contienen defectos que limitan su funcionalidad.

Personas

Es imposible reclutar personal con las habilidades requeridas para el proyecto

El personal clave esta enfermo y no disponible en momentos críticos

La capacitación solicitada para el personal no esta disponible

Organizacional

La organización se reestructura de tal forma que una admon. diferente se responsabiliza del proyecto.

Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto.

Herramientas Es ineficiente el código generado por las herramientas CASE

Las herramientas CASE no se pueden integrar

Requerimientos

Se proponen cambios en los requerimientos que requieren rehacer el diseño

Los clientes no comprenden el impacto de los cambios en los requerimientos

Estimación El tiempo requerido para desarrollar el SW esta subestimado

La tasa de reparación de defectos esta subestimada

El tamaño del SW esta subestimado

2.3.2. ANALISIS DE RIESGOS Durante éste proceso se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y seriedad del mismo. Esto no es fácil, se requiere de la opinión y experiencia del gestor del proyecto de tal forma que no se hace una valoración precisa de la probabilidad de ocurrencia del riesgo, sino más bien se propone un intervalo:

La probabilidad de que el riesgo se valore como muy bajo (<10%), bajo (10%-25%), moderado (25%-50%), alto (50%-75%), o muy alto (>75%).

Los efectos del riesgo pueden ser valorados como: catastróficos, serios, tolerables o insignificantes.

El resultado de este proceso de análisis se coloca en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo. La tabla siguiente muestra esto con los riesgos identificados de la tabla anterior:


41

RIESGO PROBABILIDAD EFECTOS

Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto

Baja Catastrófico

Es imposible reclutar personal con las habilidades requeridas para el proyecto

Alta Catastrófico

El personal clave esta enfermo y no disponible en momentos críticos

Moderada Serio

Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad

Moderada Serio

Se proponen cambios en los requerimientos que requieren rehacer el diseño

Moderada Serio

La organización se reestructura de tal forma que una admon. diferente se responsabiliza del proy.

Alta Serio

La BD que se utiliza en el sistema no puede procesar muchas transacciones por seg.

Moderada Serio

El tiempo requerido para desarrollar el software esta subestimado

Alta Serio

Las herramientas CASE no se pueden integrar Alta Tolerable

Los clientes no comprenden el impacto de los cambios en los requerimientos

Moderada Tolerable

La capacitación solicitada para el personal no esta disponible

Moderada Tolerable

La tasa de reparación de defectos esta subestimada Moderada Tolerable

El tamaño del SW esta subestimado Alta Tolerable

Es ineficiente el código generado por las herramientas CASE

Moderada Insignificante

Una vez que se han clasificado y analizado los riesgos, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto. Esto depende de una combinación de la probabilidad del riesgo en cuestión y los efectos del mismo.

2.3.3. PLANEACION DE RIESGOS Este proceso considera cada uno de los riesgos claves identificados y las estrategias para administrarlos. Nuevamente, en esta parte tampoco existe un proceso simple a seguir para definir un plan de administración de riesgos. Esto recae en el juicio y experiencia del gestor del proyecto. Existen varias estrategias identificadas para los riesgos clave, las cuales se muestran en la tabla siguiente:


42

RIESGO ESTRATEGIA

Problemas Financieros de la Organización

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones importantes a las metas del negocio

Problemas de Reclutamiento

Alertar al cliente de las dificultades potenciales y las posibilidades de retraso, investigar los componentes comprados

Enfermendad del Personal

Reorganizar el equipo de tal forma que haya traslapes en el trabajo y las personas comprendan el trabajo de los demás

Componentes Defectuosos

Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida

Cambios en los requerimientos

Rastrear la información para valorar el impacto de los requerimientos, maximizxar la información oculta en ellos

Reestructuración Organizacional

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.

Desempeño de la Base de Datos

Investigar la posibilidad de comprar una base de datos con alto desempeño

Tiempo de Desarrollo Subestimado

Investigar los componentes comprados y la utilización de un generador de programas

Estas estrategias caen en tres categorías: 1. Estrategias de anulación: Significa reducir la probabilidad de que el riesgo surja. Un ejemplo

es la estrategia para abordar los componentes defectuosos que se muestra en la tabla anterior. 2. Estrategias de disminución: Significa reducir el impacto del riesgo. Un ejemplo es la estrategia

para abordar las enfermedades del personal que se muestra en la tabla anterior. 3. Planes de Contingencia: Significa que, si sucede lo peor, se esta preparado para ello y se cuenta

con una estrategia para abordarlo. Un ejemplo es la estrategia para los problemas de organización financiera, también mostrada en la tabla anterior.

2.3.4. SUPERVISION DE RIESGOS Esta fase valora cada uno de los riesgos identificados para decidir si un riesgo es más o menos probable y cuando los efectos del mismo han cambiado. Esto no se puede observar de forma directa. Habrá que buscar otros factores que den indicios de la probabilidad del riesgo y sus efectos. La tabla siguiente da algunos ejemplos de los factores que ayudan en la valoración de estos tipos de riesgos.


43

TIPO DE RIESGO INDICADORES POTENCIALES

TECNOLOGÍA Entrega retrasada del HW o de la ayuda al SW, muchos problemas tecnológicos reportados

PERSONAS Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de empleo.

ORGANIZACIONAL Chismorreo organizacional, falta de acciones por el administrador principal

HERRAMIENTAS Rechazo de los miembros del equipo para utilizar herramientas, quejas acerca de las herramientas CASE, peticiones de estaciones de trabajo más potentes.

REQUERIMIENTOS Peticiones de muchos cambios en los requerimientos, quejas del cliente

ESTIMACIÓN Fracaso en el cumplimiento de los tiempos acordados y en la eliminación de defectos reportados.

La supervisión de riesgos debe ser un proceso continuo y, en cada revisión del progreso de la administración, cada uno de los riesgos clave debe ser considerado por separado y discutido por la audiencia.

proyectos de software 2.1. introducciÓnrossainz/ingsw... · ingeniería de sw primavera 2020-cap2...

Documents