16-Unidad 4: Manejo de archivos y seguimiento del proyecto

1. Unidad 4: Manejo de
archivos y seguimiento del
proyecto
Autor(es):
Ciencias de la Ingeniería
Carrera de Sistemas
Programación Orientada a Objetos
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Aguaszoft@Outlook.es

2. “Ser grande en las cosas pequeñas, ser
noble y heroica en los detalles insípidos
de la vida cotidiana, es una virtud tan
rara como ser digna de canonización.”
(Anónimo)
Ciencias de la Ingeniería
Carrera de Sistemas de Información
Programación Orientada a Objetos

3. Resultado de Aprendizaje
• Analizar metodologías y herramientas tecnológicas, que
mejor se ajusten a las necesidades de las organizaciones.

4. Contenidos
• Introducción
• Objetivos
• Desarrollo de Contenidos
• Conclusiones
• Bibliografía

5. Objetivos
• Adquirir los conceptos básicos relacionados con el manejo de
archivos
• Reconocer las características del manejo de archivos

6. 4.2 Lineamientos de Proyecto de aplicación
de contenidos
4.3 Seguimiento Proyecto de aplicación de
contenidos
Contenidos

7. 7
Replanificar o Corregir
• La replanificación debe de realizarse para
que el calendario se ajuste a la realidad
o Los desarrolladores se sentirán menos frustrados si
ven que los objetivos son alcanzables.
o Los clientes tendrán más claro que es lo que pueden
esperar.

8. 8
Replanificar o Corregir
• Corrección de las desviaciones.
o En lugar de modificar el plan, lo que haremos es
forzar al equipo de desarrollo para que la situación
real se aproxime a la planificada.
o Llamamos crisis de un proyecto al periodo que va
desde el que se ha producido una situación seria de
desajuste hasta que ésta es reencauzada.

9. 9
Crisis en Proyectos Informáticos.
• Detección del desfase
• Gestión de la crisis
• Recuperación tras la
crisis

10. 10
Gestión de la crisis
• Anuncio y publicidad general del problema en el
equipo.
• Reasignación de responsabilidades y autoridad.
• Actualización de la información de situación.
• Relajación de las restricciones sobre los
recursos.
• Poner al personal del proyecto a trabajar a tope.
• Establecer la fecha de finalización de la crisis.

11. 11
Recuperación tras la crisis
• Eliminar al personal innecesario.
• Realizar un estudio postmorten de la crisis.
• Replanificar el proyecto tras la crisis (coste
pendiente y total).

12. 12
Anuncio y publicidad general del
problema en el equipo.
• Cuando se declara la crisis vamos retrasados y
hemos intentado corregir el problema.
• Si la gente se entera de manera informal,
pensara que el problema esta controlado.
o Si no piden ayuda será que no es necesario.
o Se puede ofender alguien, así que mejor callar.

13. 13
Anuncio y publicidad general del
problema en el equipo.
• Lo primero que hay
que hacer es
comunicar a todos los
que están implicados
en el proyecto el
problema para que
ayuden sin reservas y
que interioricen la
situación.

14. 14
Reasignación de responsabilidades y
autoridad.
• Deberá reasignarse recursos,
o algunas tareas se paralizarán,
 las personas y recursos que tenían asignados
pasen a responsabilizarse de las nuevas tareas,
creadas para solucionar el problema.
• La reestructuración debe ser cuidadosa:
o aclarando las nuevas responsabilidades, y
o quién puede tomar decisiones y sobre que.

15. 15
Actualización de la información de
situación.
• Planificar reuniones para que los implicados
alineen los trabajos hacia la solución.
o En estos casos es cuando es mas importante la
comunicación.
• Dejar constancia de lo realizado e intentados
para no cometer varias veces el mismo error.
• El trabajo en grupo suele dar soluciones más
creativas.

16. 16
Relajación de las restricciones
sobre los recursos.
• Es posible que hubieran recursos limitados
para el proyecto.
• Habrá que hacer excepciones:
o Permitir la utilización de equipos más rápidos de
otros proyectos.
o Aumentar el soporte administrativo para que los
desarrolladores se concentren más en lo suyo.
o Hacer catering...

17. 17
Poner al personal del proyecto a
trabajar a tope.
• Hacer que la gente trabaje tantas horas
como sea posible en el proyecto (h. extras)
• Ponerles teléfonos móviles 24 horas al día
por si a alguien le hace falta comunicarse
con algún compañero.
• Suprimir reuniones de departamento o
empresa, aplazar cursillos, etc.

18. .18
Establecer la fecha de finalización
de la crisis.
• Hay que marcar un plazo razonable para que
finalice la crisis, 30 días máximo.
• Si se sobrepasa este limite debería
replantearse la viabilidad del proyecto.
• La gente no puede vivir con un nivel de
estrés excesivo, puede ser contraproducente.

19. 19
Eliminar al personal innecesario.
• Una vez finalizada la crisis habrá que
devolver los recursos tomados de otros
proyectos.
• El proyecto tiene una planificación que
deberá seguir.
• Los desarrolladores dejaran de tener
prioridad en la utilización de los
administrativos.

20. 20
Realizar un estudio postmorten de la crisis.
• Examinar que es lo que fue mal.
• Identificar problemas sistemáticos que
podrían evitarse.
• Documentar lo aprendido.

21. 21
Gasto acumulado
0
5
10
15
20
25
0 1 2 3 4 5 6 7 8 9
Revisión
Real
Planificado
Replanificar el proyecto tras la crisis
(coste pendiente y total).
• Como ha afectado la crisis al presupuesto del
proyecto.

22. 22
Tipos de seguimiento
• Proceso
o Hitos (Momentos clave del proyecto)
o Tareas: Comienzo, Fin, Recursos.
• Productos
o Entregables
o Calidad (Conformidad del cliente)
• Estas dos visiones no son independientes.
• (se suele planificar con ambos en mente)

23. 23
Estudio postmorten de los
proyectos.
• Todos los proyectos tienen problemas.
• La idea es documentar, analizar y aprender
de las cosas que han ido mal.
• Documenta aquellas cosas que podrás hacer
de forma diferente en el futuro.

24. 24
Estudio postmorten.
• Hay que reservar tiempo para que todos los
miembros del equipo puedan reflexionar
sobre:
o las desviaciones,
o los problemas, y
o las soluciones tomadas.

25. 25
Estudio postmorten: ejemplos.
o “Cuando llevábamos 10 días de retraso en las
pruebas deberíamos haberselo comunicado al
cliente”
o “Empezamos el diseño demasiado pronto, antes de
tener claras las especificaciones”
o “Se desmotivo al personal al decir que no habrían
subidas, justo en aquel momento.”

26. 26
Bibliografía
o Davis, A.M., 201 Principles of software development.
McGraw-Hill 1995
o Fairley, R., Risk Management for software projects,
IEEE Software Mayo 1994.
o Cotterell, M y Hughes, B. Software Project
Management. International Thomson, 1995.
o Thayer, R.H., Tutorial: Software Engineering Project
Mangement. IEEE Computer Press. 1988

27. Gracias
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Aguaszoft@Outlook.es