8. Planificacion Temporal y Plan Del Proyecto Del Software

Índice • Conc Concep epto toss bási básico coss

8. Planificación temporal y plan del proyecto del software

– Introdu Introducci cción ón – Planificació Planificaciónn temporal temporal

• Relaci Relación ón entre entre pers persona onass y esfuer esfuerzo zo • Distri Distribuc bución ión del esfuer esfuerzo zo

Ingeniería del Software Antonio Navarro

1


Índice

Índice

• Definición Definición de un un conjunt conjuntoo de tareas tareas para para el proyecto de software

• Sel Selecc ección ión de las tareas tareas de IS IS – Descom Descompos posici ición ón de referencia. – Ejem Ejempl plo. o.

– Introd Introducci ucción ón – Grado Grado de de rigor rigor.. – Criterios Criterios de adaptaci adaptación. ón. – Cálculo Cálculo del valor selector selector del del conjunto conjunto de tareas. – Interpretaci Interpretación ón del SCT y selección selección del cjto. cjto. tareas. Ingeniería del Software Antonio Navarro

2

• Refinamien Refinamiento to de las tareas tareas princi principales pales • Pla Planif nifica icació ciónn tempor temporal al

3

– Gráfico Gráficoss Gant Gantt.t. – Redes Redes de tareas tareas.. – Seguimiento Seguimiento de la planifica planificación ción temporal. temporal. – Análisis Análisis del del valor valor ganado. Ingeniería del Software Antonio Navarro

4

Conceptos básicos Introducción

Índice • El plan plan del del proyec proyecto to del del softw software are

• La planif planificaci icación ón tempo temporal ral y el seguim seguimiento iento del proyecto tienen como objetivo primordial evitar los retrasos en las entregas del software • Caus Causas as de de los los retr retras asos os::

– Introd Introducci ucción. ón. – Pres Pressm sman an.. – IEEE IEEE Std. 10581058-1998 1998..

• Conc Concllusi usiones ones

- Fechas límite límite de entrega entrega poco realistas. realistas. - Cambio de los requisit requisitos os que no se reflejan en la planificación temporal. Ingeniería del Software Antonio Navarro

5


6



- Sub Subest estima imació ciónn honesta del esfuerzo y/o recursos. - Riesgos Riesgos predecibles predecibles e impredecible impredecibless no considerados. - Falta de comunicaci comunicación ón entre la plantill plantilla. a. - Falta de reconocim reconocimiento iento del del retraso retraso en un proyecto. - Falta de medidas medidas para para corregir corregir el problema. problema.

• Las fechas fechas lími límite te poco poco realist realistas as son son bastante bastante frecuente en el desarrollo de software • Jamás Jamás debem debemos os empez empezar ar un proy proyect ectoo sabiendo que la fecha impuesta es imposible de alcanzar • Tampoco Tampoco es es factibl factiblee cambiar cambiar la fecha, fecha, pues por lo general, está impuesta por la ley del mercado


7


8


Conceptos básicos Planificación temporal

• Solución: - Realizar una estimación detallada (productividad>25%). - Utilizar un modelo incremental que implemente la funcionalidad crítica mínima para la fecha límite impuesta. - Reunirse con los clientes y explicar la situación. Ingeniería del Software Antonio Navarro

9


• ¿Cómo se retrasan las planificaciones temporales en los proyectos? diariamente [Fred Brooks] • ¿Cómo se cumplen las planificaciones temporales en los proyectos? diariamente [Antonio Navarro] Ingeniería del Software Antonio Navarro

10


• En los proyectos hay tareas más importantes que otras, e.g.: diseñar biblioteca vs. comprar billetes y reservar hotel... ... y en planificación temporal también, e.g.: comprar billetes y reservar hotel vs. diseñar biblioteca • Las tareas críticas son aquellas que de retrasarse, retrasan el proyecto

• El objetivo del gestor es:



11

- Definir las tareas de trabajo del proyecto. - Identificar aquellas que son críticas. - Hacer seguimiento de las tareas, con especial atención a las críticas.

• Con este fin, el gestor realiza la planificación temporal 12



• La planificación temporal de un proyecto software es una actividad que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las tareas de trabajo concretas • La planificación temporal no es estática, evoluciona con el tiempo

• Podemos distinguir entre una planificación temporal macroscópica y otra detallada • Además, la planificación temporal puede hacerse desde dos supuestos:



13


14


• La planificación temporal se guía por una serie de principios básicos :

- Validación de esfuerzo . No se deben sobreasignar recursos. - Responsabilidades definidas . Cada tarea debe tener asignados miembros específicos. - Resultados definidos . Cada tarea debe tener un resultado definido. - Hitos definidos . Las tareas deberían asociarse a hitos del proyecto. Se consigue un hito cuando se acepta uno o más productos tras revisar su calidad

- Compartimentalización. Número de tareas manejables, obtenidas mediante WBS. - Interdependencia. Dependencias entre las tareas identificadas. - Asignación de esfuerzo . A cada tarea se le debe asignar un cierto número de unidades de trabajo, así como fecha de inicio y de fin. Ingeniería del Software Antonio Navarro

- Fecha de entrega ya establecida. - Límites cronológicos aproximados.

15


16

Relación entre personas...


• Desde el punto de vista del esfuerzo da igual tener tres personas trabajando dos meses que dos personas trabajando tres meses • Lo que no da igual es añadir personas de manera incontrolada • Personas  canales de comunicación  descenso en la productividad Ingeniería del Software Antonio Navarro

• Supongamos cuatro desarrolladores con una productividad individual de 600(LDC/pm) - Cuando trabajan juntos, se abren seis posibles vías de comunicación D1 D4

D2

D3

17



18


- Cada vía de comunicación requiere un tiempo que podría emplearse en desarrollo - Si suponemos una reducción en 20 (LDC/víames) debido al gasto en comunicación, la productividad real es:

- Si añadimos dos personas más, las vías de comunicación pasan a ser 15. - En este caso, la productividad es:

600(LDC/pm)*4(p) – 20 (LDC/vm)*6(v) = 2280 (LDC/m) 2280(LDC/m)/4(p) = 570(LDC/pm)

es decir, una merma del 8,3% en la productividad

600(LDC/pm)*6(p)–20(LDC/vm)*15(v) = 3300(LDC/m) 3300(LDC/m)/6(p) = 550 (LDC/pm)

es decir, una merma del 5% en la productividad Ingeniería del Software Antonio Navarro

19


20



• Es decir, cuanta más gente haya en un equipo, menor será su productividad • Esto puede tener consecuencias nefastas si se añada gente al final de un proyecto - Supongamos que durante diez meses tenemos un equipo de cuatro programadores, y a tres meses de acabar el proyecto incorporamos a dos nuevos programadores. Ingeniería del Software Antonio Navarro

21


600(LDC/pm)*6(p)–20 (LDC/vm)*6(v)–40(LDC/vm)*9(v) = 3120(LDC/m) Ingeniería del Software Antonio Navarro

22


3120(LDC/m) / 6(p) = 520(LDC/pm)

• El razonamiento anterior está muy simplificado • Pero si es cierto que cuanto mayor sea el equipo, más baja va a ser su productividad (por lo general) • La ecuación del software también sustenta esta hipótesis

- Por lo tanto en los últimos tres meses cuatro personas producen: 570(LDC/pm)*4(p)*3(m) = 6840(LDC)

- Seis personas en el mismo periodo producen: 520(LDC/pm)*6(p)*3(m) = 9360(LDC)

- Es decir, dos personas más solo aportan 2520(LDC) cuando en teoría deberían aportar 3600(LDC), un 30% menos de lo esperado. Ingeniería del Software Antonio Navarro

- Las 6 vías de comunicación ya establecidas no suponen ningún cambio, pero las nueve nuevas establecidas entre los dos miembros nuevos y los cuatro existentes van a ser más conflictivas y supondrán una disminución en la productividad de 40(LDC/vm). - La productividad del equipo es:

23


24


Relación entre personas... E = 35/t4

• Ecuación del software: E = B(LDC/P) 3*(1/t4)

- Si t=12 meses

E = (B(LDC/P)3*)/t4

- Si t=13 meses

E = 35 (pm) equipo = 3 (p)

• Es decir: • Supongamos un proyecto con 50000(LDC), B=0,28 y P=10000 Ingeniería del Software Antonio Navarro

25

Distribución del esfuerzo


26

Distribución del esfuerzo

• Regla del 40-20-40

• Una distribución del esfuerzo puede ser:

– 40% esfuerzo en análisis y diseño. – 20% esfuerzo en codificación. – 40% esfuerzo en pruebas.

- Planificación: 2-3% - Análisis de requisitos: 10-25% - Diseño: 20-25% - Codificación: 15-20% - Pruebas: 30-40%

• Es una directriz genérica • Cada proyecto es un mundo Ingeniería del Software Antonio Navarro

E= 25 (pm) equipo = 2 (p) - Es decir, es más rentable menos personas más tiempo... ... o eso, o estamos forzando la ecuación del software

27


28

Definición de un conjunto... Introducción


• Los modelos de proceso son fijos • La estructura rígida de los modelos de proceso se puede adaptar a los proyectos variando el conjunto de tareas de IS en las que descomponemos sus AE. • En el modelo en cascada, las tareas de IS se corresponden con las tareas de trabajo

• En los iterativos, las tareas de trabajo son repeticiones de las tareas de IS • Luego, es equivalente decidir:



29

Definición de un conjunto... Introducción Comunicación Planificación Análisis de Cliente riesgos TUE S RS Estim. Planif. Valor. Plan.

CTIS

I nge ni er ía

• El conjunto de tareas de IS debe ser:

Con str uc ci ón y ad ap ta ci ón

E va lu aci ón Cliente Prueba Ensam. Instal. Eval.

Anal. Diseño Codif.

Módulo dibujo Módulo transformaciones

30


Tarea de Ingeniería del software AE

- En cuantas tareas de IS se van a descomponer las AE. - En cuantas tareas de trabajo se va descomponer el proyecto.

Ana, Luis, Paco 01.11.03 01.12.03 Código m. transf.

Módulo archivo

- Suficientemente elevado para garantizar una alta calidad del software. - Suficientemente bajo para no sobrecargar al equipo de desarrollo.

Módulo impresión

Ejemplo tabla EDT


Tarea de trabajo

31


32

Definición de un conjunto... Grado de rigor


• Los conjuntos de tareas se eligen en función del grado de rigor que deseemos aplicar en un proyecto • A su vez el grado de rigor depende fundamentalmente del tipo de proyecto: - Proyectos de desarrollo del concepto . Se inician para explorar algún nuevo concepto de negocios o aplicación de alguna nueva tecnología. Ingeniería del Software Antonio Navarro

33



34


- Proyectos de mantenimiento de aplicaciones . Corrigen, adaptan o amplían un software existente de manera que pueden no ser obvia para el usuario final. - Proyectos de reingeniería . Se llevan a cabo con la intención de reconstruir un sistema existente (heredado) en su totalidad o parte.


- Proyectos de desarrollo de una nueva aplicación. Se aceptan como consecuencia del encargo de un cliente específico. - Proyectos de mejoras de aplicaciones . Ocurren cuando un software existente sufre grandes modificaciones de su funcionamiento, rendimiento o interfaces que son observables externamente.

35

• El grado de rigor en la aplicación de un proceso del software puede ser: - Casual. - Estructurado. - Estricto. - Reacción rápida.


36



• Casual

• Estructurado

- Se aplican todas las AE, pero ser requiere un conjunto de tareas mínimo. - Se minimizan las tareas protectoras. - Se reducen los requisitos de documentación. - Son aplicables todos los principios básicos de IS


37



38

Definición de un conjunto... Criterios

• Estricto - Se aplican todas las actividades posibles de IS de tal forma que se garantice una altísima calidad.

• Reacción rápida - Se aplican las AE. - Tareas mínimas para garantizar calidad. - Se realiza back-filling . Ingeniería del Software Antonio Navarro

- Se aplican todas las AE. - Se aplican las actividades de protección necesarias para garantizar una alta calidad. - Se aplica SQA. - Se aplica GCS. - Se produce documentación. - Aparecen tareas de medición.

39

• Los criterios de adaptación se emplean para determinar el grado de rigor • Matizan la importancia del tipo de proyecto • Hay once criterios de adaptación • Se puntúan de uno (poca rigidez) a cinco (mucha rigidez) Ingeniería del Software Antonio Navarro

40

Definición de un conjunto... Cálculo del SCT

Definición de un conjunto... Cálculo del SCT

Tabla para el cálculo del SCT

Ejemplo de cálculo de SCT


41

Definición de un conjunto... Interpretación del SCT

42

Selección de las tareas de IS Descomposición de referencia • La selección es algo que debe decidir el gestor en base al grado de rigor • De todas formas por defecto podemos suponer un grado de rigor estructurado y fijar el conjunto de tareas de IS

Valor del SCT Grado de rigor SCT < 1,2 Casual 1,0 < SCT < 3,0 Estructurado SCT > 2,4 Estricto • Solapamiento  libertad



43


44

8. Planificacion Temporal y Plan Del Proyecto Del Software

Recommend Documents