CALENDARIZACION DE PROYECTOS DE SOFTWARE Armando Cabrera 1 ,Diego Sarmiento 2 , Wilson Villa 3 Universidad Técnica Particular de Loja, Es cuela de Ciencias en Computación 1 Armando Cabrera, UTPL, Loja,[email protected]2 Diego Sarmiento, UTPL, Loja, [email protected]3 Wilson Villa, UTPL, Loja,[email protected]Resumen El presente articulo tiene como finalidad de ayudar a todos las personas que realizan proyectos de s oftware, en el cual mos tramos el tema de CALENDARIZACION DE PROYECTOS DE SOFTWARE, como una herramienta importante para el de sarrollo 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 de software ha crecido de forma exponencial. Esto implica que son necesarias técnicas y tecnología eficien tes de Ingeniería de Software para resolve r los múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas de software de gran tamaño No es pos ible presentar una s olución glob al o precisa a todos los problemas de la Ingeniería de software o presentar una s olución únic a para res olver los problem as de la Ingenie ría de Software . Cada proyecto de software p resenta dis tintos 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 el problem a de la producción de l software teniendo e n cuenta las distintas metodologías y técnicas de desarrollo como también la distribución de tiempo para el proyecto, pe ro sin descuidar el aspecto humano, del usuari o del software y del ambiente para el cual se prende desarrollar e l software . Tareas para el proyecto de software La mayoría de l os proyectos de software fracasan porfalta 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 pobremente monitoreado. 4.- Cuando un resbalón en la Calendarizacion es reconocido, la respuesta tradicional es añadir mano de 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 la mayorí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 tal forma 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 medirel 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
5/16/2018 Calendarizacion de Proyecto de Sw - slidepdf.com
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.
5/16/2018 Calendarizacion de Proyecto de Sw - slidepdf.com
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