Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Recuperación de un Proyecto de Software

Grupo #4. Curso Seminario
by

Bryan García

on 17 September 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Recuperación de un Proyecto de Software

Recuperación de un Proyecto de Software Introducción 0900 05 0901 JUAN SEBASTIAN CARIAS RODRIGUEZ
0900 06 0689 KARLA JEANNETTE SEQUEN GONZALEZ
0900 05 0793 KARLA MELISSA LOPEZ ELVIRA
0900 04 3262 MELVIN EMMANUEL RUSTRIAN BARILLAS
0900 06 4583 OTTO RENE REYES SANTIZO
0900 06 0156 CARLOS BRYAN ALEXANDER GARCIA BARRIENTOS
0900 06 4313 JONATHAN ESTEBAN TREJO PEREZ
0900 98 1929 EDWIN RODOLFO BARRIOS MORALES
0900 06 0569 MONICA ADELAIDA LEMUS RODRIGUEZ Qué es la Recuperación de un
Proyecto de Software? Importancia de la Recuperación de un Proyecto de Software Características de un Proyecto con Problemas Reconocer que un proyecto esta en problemas no es una tarea fácil y aun si el Project manager no esta conciente del rumbo que esta tomando el proyecto, para este fin es importante reconocer las características de un proyecto con problemas: Alcance Personal no tiene claro el alcance del proyecto.
No se conocen los entregables del proyecto.
No hay un control de cambios de alcance efectivo Tiempo Cronograma desviado significativamente.
No se cumplen los entregables en las fechas programadas.
Recurso con sobrecarga de trabajo o esfuerzos mal distribuidos. Costos Calidad Los costos del proyecto están desviados significativamente. Alto numero de errores en los entregables Integridad Comunicación RRHH Riesgos El personal siente que el proyecto no tiene un objetivo claro.
Cambios en los proyectos sin control, o cambios a los costos, tiempo, calidad y alcance administrados independientemente Pocos canales de comunicación
No se maneja documentación escrita ni centralizada. Moral baja del personal
No sabe quien es el responsable de los entregables
Existe conflicto entre los recursos Procura Hay una sobre confianza de que todo saldrá bien por lo que no se identifica riesgos ni se establecen acciones específicas para minimizarlos. No sabe cuantos contratos están involucrados en el proyecto ni cuales son los compromisos de cada uno de ellos. Enfoques de Recuperación de un Proyecto de Software Enfoque Entre los escasos enfoques para la recuperación de proyectos difundidos a la fecha, es necesario hacer mención de un plan de recuperación, el cual está orientado a la recuperación de proyectos con serios problemas.

En dicho enfoque, la recuperación de un proyecto se basa en la combinación de tres estrategias fundamentales:

Reducción del tamaño del software,
Incremento de la productividad del proceso de desarrollo y
Ajuste de la planeación, considerando el tiempo realmente requerido para el Desarrollo del producto. Estrategias Estas estrategias están directamente relacionadas con tres elementos claves del Proyecto de software:
El producto,
Las personas y
El proceso, respectivamente. Para cada estrategia, el plan de recuperación evalúa y aplica un conjunto de directrices dirigidas al elemento clave en cuestión. Por ejemplo, si la estrategia a ejecutar va dirigida al producto, entonces el conjunto de directrices abarca acciones tales como: la estabilización de los requerimientos, la disminución del conjunto de prestaciones, la eliminación de las partes del producto caracterizadas por una baja calidad, la reducción del número de defectos, entre otras. La clave entre el éxito y el fracaso de un proyecto de software radica (en la gran mayoría de los casos), contar con un Departamento de Riesgos encargado de tomar las riendas de un proyecto de software. La administración efectiva de un proyecto de software depende totalmente de la forma en la que se planea la totalidad del proyecto. Dentro de las actividades que se deben tomar en cuenta al momento de querer retomar el rumbo correcto de un proyecto de software podemos mencionar: Cuanto personal se requiere para contemplar una actividad de recuperación
Cuanto tiempo tomara realizar esta actividad
Cual será el costo total de realizar este tipo de actividades Filosofía de Recuperación de Proyectos El fundamento teórico de la propuesta metodológica que aquí se presenta es aquel que caracteriza el proceso de diagnostico y tratamiento Filosofía para aplicar en la recuperación de Proyectos Identificación de signos y síntomas, interrogatorio, pruebas complementarias, tratamiento y seguimiento. En este sentido, vale la pena iniciar esta sección refiriéndonos a este estilo de solución de problemas y en particular a algunos de los términos que lo caracterizan. El diagnostico es el proceso encaminado a la identificación o reconocimiento de una problema del cual se toma como base los signos y síntomas que se manifiestan y con el apoyo de los estudios necesarios. El diagnostico medico indica todo el proceso de investigación ejecutado sobre el paciente, a partir de las observaciones y razonamientos del medico para determinar la enfermedad. La capacidad diagnostica de un buen medico esta relacionada directamente con su capacidad para poder ver todas las posibilidades diagnosticas para un cierto grupo de manifestaciones clínicas (signos, síntomas, laboratorio y gabinete) y su capacidad para discernir, sobre la base de su experiencia, cual de todos estos padecimientos es con mayor certeza la causa del proceso mórbido. Resulta muy apropiado considerar que un plan para la recuperación de proyectos de software pueda establecerse sobre la base de un proceso similar al que caracteriza a estos procedimientos médicos. Plan de Recuperación Identificando el Problema Fases, Actividades y Artefactos del Plan de Recuperación ¿Es posible la Recuperación? ¿Cómo Recuperar? Identificación de los Signos y Síntomas de Abandono del proyecto Determinación de las Causas de Abandono del Proyecto Diagnostico Diferencial del Proyecto de Software Estudio de Factibilidad para la Recuperación Fases, Actividades y Artefactos del Plan de Recuperación Estrategia de Recuperación del Proyecto en base al Diagnostico Integral.
Ejecución de la Estrategia de Recuperación. Diagrama de Casos de Uso que muestra la Interacción del Usuario con las Diferentes Actividades Caso de Estudio Los Involucrados (Actores) Clínica para la Rehabilitación y Prevención de Adicciones (CRPA): Solicita un ERP con el objetivo de mejorar el negocio.
Adrian Ramos: Encargado del área administrativa y representante por parte de la CRPA ante ITe Consultores.
ITe Consultores: empresa dedicada al desarrollo de software a la medida.
Leonel Hinojosa: Empleado de ITe Consultores y primer consultor a cargo del proyecto
Mauro Escalante: Empleado de ITe Consultores quien tiene la responsabilidad de darle continuidad al proyecto CRPA Antecedentes Considerando que:
 
1) Del caso de estudio no es posible conocer el tiempo estimado para el desarrollo del proyecto,
 
2) Se sabe que al menos existen tres meses de retraso,
 
3) El sistema tiene que ser atacado desde sus primeras etapas y
 
4) Ya se ha invertido tiempo en un segundo análisis de requerimientos;
 
Se propone lo siguiente: a. Recuperar la etapa de negociación con miras a continuar el desarrollo del proyecto, sin perder de vista el retraso de tres meses, lo que conllevaría a una repercusión en costos
 
b. Cerrar el proyecto, recuperando el trabajo llevado a cabo en el segundo análisis. Independientemente de la decisión final tomada, el plan de recuperación debería ser tomado en cuenta como un referente para el desarrollo de posteriores proyectos. Resumen Contexto del Desarrollo del Proyecto Diagnostico Diferencial Hacia la Recuperación del Proyecto Identificación de los Signos y Síntomas de Abandono del Proyecto Realizar el Diagnostico Diferencial Reglas de producción aplicadas durante el Diagnostico diferencial al caso de estudio SI CRPA Estudio de Factibilidad para la Recuperación Tenemos que tomar el proceso de recuperación como un aliado para el éxito por lo que tenemos que mitigar las características de un proyecto con problemas.
El enfoque en la recuperación de un proyecto se basa en la combinación de tres estrategias fundamentales: Reducción del tamaño del software, Incremento de la productividad del proceso de desarrollo y ajuste de la planeación.
El enfoque proactivo de la Gerencia de Riesgos está basado en la Planeación de Proyectos, Gerencia de Riesgos y Seguimiento y Control de Proyectos
Antes de iniciar el plan de recuperación, es necesario evaluar la situación para determinar el tipo de plan específico que se requiere, es decir, cual o cuales de estas estrategias aplicar Conclusiones Gracias por su Atención Expositora: Karla Sequen Expositora: Karla López Expositor: Melvin Rustrían Expositor: Bryan García Expositora: Mónica Lemus Expositor: Edwin Barrios Expositor: Sebastían Carías Expositor: Otto Reyes Expositor: Jonathan Trejo Grupo #4 RECUPERACIÓN DE UN PROYECTO DE SOFTWARE
Full transcript