CALENDARIZACION DE PROYECTOS DE SOFTWARE

Armando Cabrera1,Diego Sarmiento2, Wilson Villa3 Universidad Tcnica Particular de Loja, Escuela de Ciencias en Computacin
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 DE SOFTWARE, como una herramienta importante para el desarrollo de proyectos. Con este tema ayudamos a conocer mas fondo las diferentes ventajas de aplicar una calendarizacion, adems nos muestra las diferentes tcnicas que podemos aplicar para tener un ptimo resultado. Palabras Claves Calendarizacion, cronogramas, distribucin, esfuerzo, red, tareas, refinamiento, seguimiento, valor ganado. INTRODUCCIN 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 de software ha crecido de forma exponencial. Esto implica que son necesarias tcnicas y tecnologa eficientes de Ingeniera de Software para resolver los mltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas de software de gran tamao No es posible presentar una solucin global o precisa a todos los problemas de la Ingeniera de software o presentar una solucin nica para resolver los problemas de la Ingeniera de Software. Cada proyecto de software presenta distintos problemas en su desarrollo, los cuales involucran personas, equipo, usuarios del software y ambiente de la aplicacin. Por estas razones, cada proyecto debe resolver el problema de la produccin del software teniendo en cuenta las distintas metodologas y tcnicas de desarrollo como tambin la distribucin 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 mayora 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 comn? 1.- Las tcnicas de estimacin son pobremente desarrolladas. Reflejan suposiciones falsas, por ejemplo, que todo ir bien. 2.- Se confunde esfuerzo con progreso, suponiendo que hombres y meses son intercambiables. 3.- El progreso de la Calendarizacion es pobremente monitoreado. 4.- Cuando un resbaln en la Calendarizacion es reconocido, la respuesta tradicional es aadir mano de obra. Esto es similar a apagar un fuego con gasolina. Otros aspectos que se considerarn son: Optimismo. Los programadores son optimistas, tal vez por que la mayora son jvenes o por la juventud de la programacin. Se supone en principio, que todo ir bien. El medio de la programacin, cosas mentales, a diferencia de otras disciplinas, es muy tratable, de tal forma que se esperan pocas dificultades en la implementacin. En una sola tarea la suposicin de que todo ir bien tiene una distribucin de probabilidad para su atraso, y como los grandes programas tienen muchas tareas, algunas de ellas encadenadas, de tal modo que la suposicin de que todo ir bien llega a ser muy pequea. El Hombre-Mes El costo vara como el producto del nmero de hombres y el nmero de meses. El progreso no. De aqu que el hombre-mes como una unidad para medir el tamao de un trabajo es un mito peligroso y engaoso. Esto implica que hombres y meses no son intercambiables. Hombres y meses son activos intercambiables slo cuando una tarea puede partirse entre muchos trabajadores sin ninguna comunicacin entre ellos.

1 2

Armando Cabrera, UTPL, Loja, aacabrera@utpl.edu.ec Diego Sarmiento, UTPL, Loja, dsarmiento@utpl.edu.ec 3 Wilson Villa, UTPL, Loja, wvvilla@utpl.edu.ec

La grfica de hombres contra meses es una funcin decreciente como se indica en la siguiente figura.

Prueba del Sistema (Test) Ninguna parte de la calendarizacin es tan ampliamente afectada por las restricciones secuenciales como el componente de depuracin y prueba. Debido al optimismo se esperara que el nmero de bugs sea ms pequeo de lo que es. De acuerdo a la experiencia del autor, emplea la siguiente regla para calendarizar una tarea de software: 1/3 planeacin 1/6 codificacin 1/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 en este aspecto. Si se falla para calendarizar tiempo en este aspecto, se originar un atraso en la parte final del proyecto con consecuencias desastrosas, tanto econmicas como psicolgicas. Estimacin Cobarde Para el programador, la urgencia del patrn puede gobernar la conclusin calendarizada de la tarea, pero no gobernar la conclusin real. Cuando una comida no est lista en un cierto tiempo, el cliente tiene dos caminos, o espera o la come cruda. El cliente del software tiene opciones equivalentes. Una calendarizacin falsa para satisfacer los deseos del patrn es ms comn en esta disciplina que en alguna otra parte de la ingeniera. Es difcil hacer una defensa fuerte de la estimacin de tiempos que es derivada de mtodos no cuantitativos, soportada por pocos datos, y certificada principalmente por las corazonadas de los directivos. Es necesario desarrollar y publicar cifras de productividad, cifras de incidencias de bugs, reglas de estimacin y as sucesivamente. Y publicarlas en beneficio de la profesin.

Cuando una tarea no puede partirse por restricciones secuenciales, la aplicacin de mas esfuerzo no tiene efectos en la calendarizacin. El nacimiento de un nio toma nueve meses, no importa cuantas mujeres se asignen. Muchas tareas de software se comportan as por la naturaleza secuencial de la depuracin. Aqu el comportamiento es una lnea recta paralela al eje de Hombres. En tareas que pueden partirse pero que requieren comunicacin entre la subtareas, el esfuerzo de comunicacin debe aadirse a la cantidad de trabajo que debe hacerse. Por tanto lo mejor que puede hacerse es algo ms pobre que un canje simple de hombres por meses. La grfica de comportamiento es similar al del primer caso, pero desplazada una determinada cantidad hacia arriba de meses. La sobrecarga de comunicacin se debe al entrenamiento (de la tecnologa, las metas, la estrategia global y el plan de trabajo) y a la intercomunicacin. El entrenamiento no puede partirse, de tal forma que el esfuerzo aadido vara linealmente con el nmero de trabajadores. La intercomunicacin es peor. Como cada parte de la tarea debe comunicarse con otra parte el esfuerzo se incrementa por n(n -1) / 2. Esta situacin puede visualizarse mediante un grafo cuyos nodos tienen arcos a los dems nodos. Para 3 nodos se requieren 3 arcos, y para 4 nodos se requieren 6. El esfuerzo de la comunicacin se comporta de acuerdo a la siguiente grfica.

Desastre en la calendarizacin regenerativa Se analiza una tarea que se estima en 12 hombresmes. 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. _________________________________
1

SOMMERVILLE IAM(2005) Ingenieria de Software. (VII edicin) Madrid:Ed.Pearson

terminan en B, C y D se realizan en 6 meses) de trabajo deben hacerse en 2 meses. Para lo cual se requieren 9 hombres. Hay que aadir 6 hombres a los 3 asignados inicialmente. 3) Recalendarizar. Hay que tomar suficiente tiempo en la nueva calendarizacin para asegurar que el trabajo 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 accin posible. Se debe recortar cuidadosamente para recalendarizar, o ver como la tarea es calladamente recortada por un diseo 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 rpidamente reclutados, requerirn entrenamiento en la tarea por uno de los hombres experimentados. Si sto toma un mes, 3 hombres-mes se habrn dedicado a un trabajo no considerado en la estimacin original. Y ms aun, la tarea originalmente particionada en 3 partes, debe ahora ser reparticionada en 5 partes; de aqu algn trabajo ya hecho se perdera y la prueba del sistema se alargara. Entonces, al final del tercer mes, sustancialmente ms de 7 hombres-mes de esfuerzo permanecen, y se tienen disponibles 5 personas entrenadas y un mes.

Suponga que el primer punto se alcanza hasta que han transcurrido dos meses. Que alternativas tiene el director del proyecto? 1) Suponga que slo la primera parte de la tarea fue mal estimada. La Fig. 2 establece esta situacin. 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 hay que aadir 2 hombres a los 3 asignados inicialmente. 2) Suponga que la estimacin total fue uniformemente baja. La Fig. 3 establece esta situacin. 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 ___________________________________________
1

Segn lo anterior el desastre regenerativo dara un producto ms pobre, posteriormente, que el que podra recalendarizarse con los tres hombres originales. Simplificando todo lo anterior, se enuncia la Ley de Brooke: Aadir mano de obra a un proyecto de software atrasado lo hace peor. Esto desmitifica el hombre-mes. El nmero de meses de un proyecto depende sus restricciones secuenciales. El mximo nmero de hombres depende del nmero de subtareas independientes. de esas dos cantidades se pueden derivar calendarios usando menos hombres y ms meses. No se puede calendarios efectivos usando ms hombres y menos meses. La mayor parte de proyectos de software han fracasado por falta de tiempo de calendario que por otras causas combinadas.

Desastres, Disponibles en http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/adproysisinf.htm

Conjunto de tareas para el proyecto de Software Actividades en un proyecto deberan ser organizadas para producir resultados tangibles que permitan a la administracin 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

Los grficos de actividad muestran las dependencias de tareas y la ruta crtica Los grficos de barras muestran el calendario programado contra el tiempo real transcurrido Duracin de tareas y dependencias La figura la encuentra en anexo (3) Red de actividades La figura la encontramos en anexo (4)

Hitos del proceso de requerimientos La figura la encontramos en anexo (1) Calendarizacin 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 que espera el fin de otra Depende de la intuicin y experiencia de administradores de proyectos El proceso de Calendarizacion del proyecto La figura la encontramos en anexo (2) Problemas de Calendarizacion Es difcil estimar la dificultad de problemas y por lo tanto el costo de desarrollar una solucin Productividad no es proporcional al nmero de personas trabajando en una tarea Agregar personas a un proyecto atrasado lo atrasa an ms debido a sobrecarga de comunicaciones Lo inesperado siempre ocurre. Siempre contar con una holgura al planear Grficos de barras y redes de actividades Se usan notaciones grficas para ilustrar el calendario del proyecto Mostrar el proyecto descompuesto en tareas. Las tareas no deberan ser muy pequeas. Deberan tomar cerca de una semana o dos ___________________________________________
1

Lnea de tiempo de actividades Gantt La figura la encontramos en anexo (5) Asignaciones del personal La figura la encontramos en anexo (6) Puntos clave Buena administracin de proyecto es esencial para el xito del proyecto La naturaleza intangible del software causa problemas de administracin Administradores juegan roles diversos, pero sus actividades ms significativas son planeamiento, estimacin y Calendarizacion Planeamiento y estimacin son procesos iterativos que continuan durante todo el proyecto Un hito de proyecto es un estado predecible donde se presenta a la administracin algn reporte formal del progreso. Riesgos pueden ser riesgos del proyecto, riesgos del producto, o riesgos del negocio. Administracin de riesgo se preocupa de identificar cules 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 ningn inconveniente. Teniendo reuniones permanentes dentro del equipo que estn trabajando en proyecto y exponiendo todos los puntos en su desarrollo el producto final va ha tener xito.
Ver Anexos

Hitos, disponible en http://delta.cs.cinvestav.mx/~pmejia/softeng/curso.html

 Aplicar correctamente los diferentes alternativas que nos brinda la calendarizacion, y teniendo en cuenta una organizacin adecuada, los objetivos se van a cumplir.

BIBLIOGRAFIA [1]PRESSMAN ROGER, Ingenieria de software, (VI edicin) [2]SOMMERVILLE IAM(2005) Ingenieria de Software. (VII edicin) Madrid:Ed.Pearson [3]http://www.frsf.utn.edu.ar/estudios_y_acc eso/posgrado/maestriaisi/cursos/2006/AdmProyectoSW.htm [4]http://www.gestiopolis.com/recursos2/doc umentos/fulldocs/ger/adproysisinf.htm [5]http://delta.cs.cinvestav.mx/~pmejia/softe ng/curso.html

ANEXOS
ANEXO1
A TIV IE C IT S Feasibility stud y R equirem ts en an alysis P typ roto e de elop ent v m D esign stud y R uirem ts eq en sp ecification

Feasibility rep ort

R equirem ts en de itio fin n

E alua n v tio rep ort M E OE IL ST N S

A itectu rch ral de sign

R uirem ts eq en sp ecification

ANEXO2
Identify activities Identify activity dependencies Estimate resources for activities A llocate people toactivities Create project charts

Software requirements

A ctivity charts and bar charts

ANEXO3
Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duration (days) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencies T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

ANEXO4
14/7/99 8 days T1 4/7/99 start 15 days T2 10 days T4 18/7/99 M5 25 days T8 19/9/99 Finish 25/7/99 M2 T7 10 days T5 11/8/99 M7 15 days T10 M1 15 days T3 5 days T6 20 days 4/8/99 M4 15 days T9 25/7/99 M3 7 days T11 5/9/99 M8 10 days T12 25/8/99 M6

ANEXO5
4/7 Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T1 1 M8 T12 Finish 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

ANEXO6
4 /7 Fred T4 T8 Jane T1 T3 T9 Anne T2 T6 Jim Mary T7 T5 T1 0 T1 1 T1 2 11 /7 1 8/ 7 2 5/ 1 /8 8 /8 1 5/ 8 22 /8 29 /8 5 /9 1 2/ 9 19 /9