calendarizacion de proyecto de sw

5/16/2018 Calendarizacion de Proyecto de Sw - slidepdf.com

http://slidepdf.com/reader/full/calendarizacion-de-proyecto-de-sw 1/8

CALENDARIZACION DE PROYECTOS DE SOFTWARE

Armando Cabrera1 ,Diego Sarmiento

2 , Wilson Villa

3

Universidad Técnica Particular de Loja, Escuela de Ciencias en Computación

1Armando Cabrera, UTPL, Loja, [email protected]

2Diego Sarmiento, UTPL, Loja, [email protected]

Wilson Villa, UTPL, Loja, [email protected]

Resumen El presente articulo tiene como

finalidad de ayudar a todos las personas que realizan

proyectos de software, en el cual mostramos el tema

de CALENDARIZACION DE PROYECTOS DESOFTWARE, como una herramienta importante

para el desarrollo de proyectos.Con este tema ayudamos a conocer mas

fondo las diferentes ventajas de aplicar una

calendarizacion, además nos muestra las diferentes

técnicas que podemos aplicar para tener un óptimo

resultado.

Palabras Claves Calendarizacion, cronogramas,

distribución, esfuerzo, red, tareas, refinamiento,seguimiento, valor ganado.

INTRODUCCIÓN

El reciente aumento de aplicaciones en donde se

utiliza la computadora ha sido posible debido a un

hardware de bajo costo, por lo cual la demanda desoftware ha crecido de forma exponencial. Esto

implica que son necesarias técnicas y tecnología

eficientes de Ingeniería de Software para resolver losmúltiples problemas que se derivan de las

aplicaciones en donde se desarrollan sistemas de

software de gran tamaño

No es posible presentar una solución global o precisa

a todos los problemas de la Ingeniería de software o

presentar una solución única para resolver los

problemas de la Ingeniería de Software. Cada

proyecto de software presenta distintos problemas en

su desarrollo, los cuales involucran personas, equipo,

usuarios del software y ambiente de la aplicación.

Por estas razones, cada proyecto debe resolver elproblema de la producción del software teniendo en

cuenta las distintas metodologías y técnicas de

desarrollo como también la distribución de tiempo

para el proyecto, pero sin descuidar el aspecto

humano, del usuario del software y del ambiente

para el cual se prende desarrollar el software.

Tareas para el proyecto de software

La mayoría de los proyectos de software fracasan por

falta de tiempo de calendario que por otras causas

combinadas ¿Por qué esta causa de desastre es tan

común?

1.- Las técnicas de estimación son pobremente

desarrolladas. Reflejan suposiciones falsas, porejemplo, que todo irá bien.

2.- Se confunde esfuerzo con progreso, suponiendo

que hombres y meses son intercambiables.

3.- El progreso de la Calendarizacion es pobrementemonitoreado.

4.- Cuando un resbalón en la Calendarizacion esreconocido, la respuesta tradicional es añadir manode obra. Esto es similar a apagar un fuego con

gasolina.

Otros aspectos que se considerarán son:Optimismo.Los programadores son optimistas, tal vez por que lamayoría son jóvenes o por la juventud de la

programación. Se supone en principio, que todo irá

bien.El medio de la programación, cosas mentales, a

diferencia de otras disciplinas, es muy tratable, de talforma que se esperan pocas dificultades en la

implementación.En una sola tarea la suposición de que todo irá bien

tiene una distribución de probabilidad para su atraso,

y como los grandes programas tienen muchas tareas,

algunas de ellas encadenadas, de tal modo que la

suposición de que todo irá bien llega a ser muy

pequeña.

El Hombre-Mes

El costo varía como el producto del número de

hombres y el número de meses. El progreso no. De

aquí que el hombre-mes como una unidad para medir

el tamaño de un trabajo es un mito peligroso y

engañoso. Esto implica que hombres y meses no son

intercambiables.

Hombres y meses son activos intercambiables sólo

cuando una tarea puede partirse entre muchos

trabajadores sin ninguna comunicación entre ellos.

mailto:[email protected]








La gráfica de hombres contra meses es una función

decreciente como se indica en la siguiente figura.

Cuando una tarea no puede partirse por restricciones

secuenciales, la aplicación de mas esfuerzo no tiene

efectos en la calendarización. El nacimiento de un

niño toma nueve meses, no importa cuantas mujeres

se asignen. Muchas tareas de software se comportan

así por la naturaleza secuencial de la depuración.

Aquí el comportamiento es una línea recta paralela al

eje de Hombres.En tareas que pueden partirse pero que requieren

comunicación entre la subtareas, el esfuerzo de

comunicación debe añadirse a la cantidad de trabajo

que debe hacerse. Por tanto lo mejor que puede

hacerse es algo más pobre que un canje simple de

hombres por meses. La gráfica de comportamiento essimilar al del primer caso, pero desplazada una

determinada cantidad hacia arriba de meses.

La sobrecarga de comunicación se debe al

entrenamiento (de la tecnología, las metas, la

estrategia global y el plan de trabajo) y a la

intercomunicación. El entrenamiento no puedepartirse, de tal forma que el esfuerzo añadido varía

linealmente con el número de trabajadores.

La intercomunicación es peor. Como cada parte de la

tarea debe comunicarse con otra parte el esfuerzo se

incrementa por n(n -1) / 2. Esta situación puede

visualizarse mediante un grafo cuyos

nodos tienen arcos a los demás nodos. Para 3 nodos

se requieren 3 arcos, y para 4 nodos se requieren 6.

El esfuerzo de la comunicación se comporta de

acuerdo a la siguiente gráfica.

_________________________________1

SOMMERVILLE IAM(2005) Ingenieria de Software. (VII edición)

Madrid:Ed.Pearson

Prueba del Sistema (Test)

Ninguna parte de la calendarización es tan

ampliamente afectada por las restricciones

secuenciales como el componente de depuración y

prueba. Debido al optimismo se esperaría que el

número de bugs sea más pequeño de lo que es.

De acuerdo a la experiencia del autor, emplea la

siguiente regla para calendarizar una tarea de

software:

1/3 planeación

1/6 codificación1/4 prueba de componentes y prueba preliminar del

sistema

1/4 prueba del sistema, de todos los componentes en

conjunto

Puede observarse que la mitad del esfuerzo recae eneste aspecto. Si se falla para calendarizar tiempo eneste aspecto, se originará un atraso en la parte final

del proyecto con consecuencias desastrosas, tanto

económicas como psicológicas.

Estimación Cobarde

Para el programador, la urgencia del patrón puedegobernar la conclusión calendarizada de la tarea, pero

no gobernar la conclusión real. Cuando una comida

no está lista en un cierto tiempo, el cliente tiene dos

caminos, o espera o la come cruda. El cliente delsoftware tiene opciones equivalentes.

Una calendarización falsa para satisfacer los deseosdel patrón es más común en esta disciplina que en

alguna otra parte de la ingeniería. Es difícil hacer una

defensa fuerte de la estimación de tiempos que es

derivada de métodos no cuantitativos, soportada por

pocos datos, y certificada principalmente por las

corazonadas de los directivos. Es necesariodesarrollar y publicar cifras de productividad, cifras

de incidencias de bugs, reglas de estimación y así

sucesivamente. Y publicarlas en beneficio de la

profesión.

Desastre en la calendarización regenerativa

Se analiza una tarea que se estima en 12 hombres-

mes. Y se asigna a 3 hombres durante 4 meses. Y que

tiene cuatro puntos medibles A, B, C, D que son

calendarizados para concluirse al final de cada mes.

Como se indica en la Fig. 1.



Suponga que el primer punto se alcanza hasta que

han transcurrido dos meses. ¿Que alternativas tiene el

director del proyecto?

1) Suponga que sólo la primera parte de la tareafue mal estimada. La Fig. 2 establece esta situación.

Suponga que la tarea debe terminarse a tiempo.Como la subtarea que terminó en A consumió 2

meses, hay que terminar el resto en 2 meses. Esto es,

9 hombre-mes de trabajo deben hacerse en 2 meses.

Para lo cual se requieren 4.5 hombres. Entonces hayque añadir 2 hombres a los 3 asignados inicialmente.

2) Suponga que la estimación total fueuniformemente baja. La Fig. 3 establece esta

situación. Suponga que la tarea debe terminarse a

tiempo. Como la subtarea que terminó en A

consumió dos meses, hay que terminar el resto en 2

meses. Esto es, 18 hombre-mes (las etapas que

___________________________________________1Desastres, Disponibles en

http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/adproysisinf.htm

terminan en B, C y D se realizan en 6 meses) detrabajo deben hacerse en 2 meses. Para lo cual se

requieren 9 hombres. Hay que añadir 6 hombres a los

3 asignados inicialmente.

3) Recalendarizar. Hay que tomar suficiente tiempoen la nueva calendarización para asegurar que eltrabajo se haga cuidadosamente, y que no sea

necesario recalendarizar nuevamente.

4) Recortar la tarea. Cuando los costos secundarios

del atraso son muy altos, es la única acción posible.

Se debe recortar cuidadosamente para recalendarizar,

o ver como la tarea es calladamente recortada por undiseño precipitado e incompleta prueba.

Pero en los dos primeros casos, insistir que la tarea

inalterada sea completada en 4 meses es desastroso.

Los dos nuevos hombres aunque competentes y

rápidamente reclutados, requerirán entrenamiento en

la tarea por uno de los hombres experimentados. Siésto toma un mes, 3 hombres-mes se habrán

dedicado a un trabajo no considerado en la

estimación original. Y más aun, la tarea

originalmente particionada en 3 partes, debe ahora

ser reparticionada en 5 partes; de aquí algún trabajo

ya hecho se perdería y la prueba del sistema se

alargaría. Entonces, al final del tercer mes,

sustancialmente más de 7 hombres-mes de esfuerzopermanecen, y se tienen disponibles 5 personas

entrenadas y un mes.

Según lo anterior el desastre regenerativo daría un

producto más pobre, posteriormente, que el que

podría recalendarizarse con los tres hombres

originales.

Simplificando todo lo anterior, se enuncia la Ley de

Brooke:

Añadir mano de obra a un proyecto de software

atrasado lo hace peor.

Esto desmitifica el hombre-mes. El número de meses

de un proyecto depende sus restricciones

secuenciales. El máximo número de hombres

depende del número de subtareas independientes. de

esas dos cantidades se pueden derivar calendarios

usando menos hombres y más meses. No se puede

calendarios efectivos usando más hombres y menosmeses. La mayor parte de proyectos de software han

fracasado por falta de tiempo de calendario que porotras causas combinadas.





Conjunto de tareas para el proyecto de Softwareü Actividades en un proyecto deberían ser

organizadas para producir resultados

tangibles que permitan a la administración

evaluar el progreso

ü Hitos marcan el final de una actividad del

proceso

ü Entregables son resultados del proyecto que

se entregan al cliente

ü El proceso de cascada permite establecer los

hitos de progreso en forma directa

Hitos del proceso de requerimientos

La figura la encontramos en anexo (1)

Calendarización del proyecto

ü Segmentar el proyecto en tareas y estimar

tiempo y recursos requeridos para completar

cada tarea

ü Organizar tareas concurrentemente para

hacer uso óptimo de la fuerza de trabajo

ü Minimizar la dependencia de tareas para

evitar atrasos causados por una tarea queespera el fin de otra

ü Depende de la intuición y experiencia de

administradores de proyectos

El proceso de Calendarizacion del proyectoLa figura la encontramos en anexo (2)

Problemas de Calendarizacion

ü Es difícil estimar la dificultad de problemas

y por lo tanto el costo de desarrollar una

solución

ü Productividad no es proporcional al númerode personas trabajando en una tarea

ü Agregar personas a un proyecto atrasado lo

atrasa aún más debido a sobrecarga de

comunicaciones

ü Lo inesperado siempre ocurre. Siempre

contar con una holgura al planear

Gráficos de barras y redes de actividades

ü Se usan notaciones gráficas para ilustrar el

calendario del proyecto

ü Mostrar el proyecto descompuesto en tareas.

Las tareas no deberían ser muy pequeñas.

Deberían tomar cerca de una semana o dos___________________________________________1 Hitos, disponible en http://delta.cs.cinvestav.mx/~pmejia/softeng/curso.html

ü Los gráficos de actividad muestran las

dependencias de tareas y la ruta crítica

ü Los gráficos de barras muestran el calendario

programado contra el tiempo real

transcurrido

Duración de tareas y dependencias

La figura la encuentra en anexo (3)

Red de actividadesLa figura la encontramos en anexo (4)

Línea de tiempo de actividades GanttLa figura la encontramos en anexo (5)

Asignaciones del personalLa figura la encontramos en anexo (6)

Puntos clave

ü Buena administración de proyecto es

esencial para el éxito del proyecto

ü La naturaleza intangible del software causaproblemas de administración

ü Administradores juegan roles diversos, pero

sus actividades más significativas son

planeamiento, estimación y Calendarizacionü Planeamiento y estimación son procesos

iterativos que continuan durante todo el

proyecto

ü Un hito de proyecto es un estado predecible

donde se presenta a la administración algún

reporte formal del progreso.

ü Riesgos pueden ser riesgos del proyecto,

riesgos del producto, o riesgos del negocio.

ü Administración de riesgo se preocupa deidentificar cuáles riesgos pueden afectar el

proyecto y planear a fin de evitar que estos

riesgos no se conviertan en amenazas

mayores.

Conclusiones:ü Todos los proyectos que tengan una

celendarizacion adecuada no va ha

tener ningún inconveniente.

ü Teniendo reuniones permanentes

dentro del equipo que estén

trabajando en proyecto y exponiendo

todos los puntos en su desarrollo el

producto final va ha tener éxito.

Ver Anexos

http://delta.cs.cinvestav.mx/~pmejia/softeng/curso.html

http://delta.cs.cinvestav.mx/~pmejia/softeng/curso.html



ü Aplicar correctamente los diferentes

alternativas que nos brinda la

ü calendarizacion, y teniendo en cuenta

una organización adecuada, los

objetivos se van a cumplir.

BIBLIOGRAFIA

[1]PRESSMAN ROGER, Ingenieria de

software, (VI edición)

[2]SOMMERVILLE IAM(2005) Ingenieriade Software. (VII edición)

Madrid:Ed.Pearson

[3]http://www.frsf.utn.edu.ar/estudios_y_acc

eso/posgrado/maestria-isi/cursos/2006/AdmProyectoSW.htm

[4]http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/adproysisinf.htm

[5]http://delta.cs.cinvestav.mx/~pmejia/softe

ng/curso.html

http://www.frsf.utn.edu.ar/estudios_y_acc

http://www.gestiopolis.com/recursos2/doc

http://delta.cs.cinvestav.mx/~pmejia/softe

http://delta.cs.cinvestav.mx/~pmejia/softe

http://www.gestiopolis.com/recursos2/doc

http://www.frsf.utn.edu.ar/estudios_y_acc



ANEXOS

ANEXO1

ANEXO2

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Create project

charts

Software

requirements

Activity charts

and bar charts

Evaluationreport

Prototypedevelopment

Requirementsdefinition

Requirementsanalysis

Feasibilityreport

Feasibilitystudy

Architecturaldesign

Designstudy

Requirementsspecification

Requirementsspecification

ACTIVITIES

MILESTONES



ANEXO3

ANEXO4

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4

Task Duration (days) Dependencies

T1 8T2 15

T3 15 T1 (M1)

T4 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)



ANEXO5

ANEXO64 /7 11 /7 1 8/7 2 5/ 1 /8 8 /8 1 5/ 8 22 /8 29 /8 5 /9 12/9 19/9

T4

T8 T1 1

T1 2

T1

T3

T9

T2

T6 T1 0

T7

T5

Fred

Jane

Anne

Mary

Jim

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1

T2

M1

T7T3

M5

T8

M3

M2

T6

T5

M4

T9M7

T10

M6

T1 1M8

T12

Start

Finish

calendarizacion de proyecto de sw

Documents