Conferencia Gestión de Proyectos de TI

14.409 visualizaciones

Publicado el

Diapositiva de la exposición que di en la UNAC Lima Perú

Publicado en: Empresariales
0 comentarios
6 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
14.409
En SlideShare
0
De insertados
0
Número de insertados
291
Acciones
Compartido
0
Descargas
1.451
Comentarios
0
Recomendaciones
6
Insertados 0
No insertados

No hay notas en la diapositiva.

Conferencia Gestión de Proyectos de TI

  1. 1. Gestión de Proyectos de TI Exp. Hanz Cocchi Guerrero IT Project Manager
  2. 2. Agenda <ul><li>¿Que es un Proyecto? </li></ul><ul><li>Problemas con el Software. </li></ul><ul><li>¿Que son los riesgos? </li></ul><ul><li>¿Qué deberíamos hacer? </li></ul><ul><li>Seis mejores prácticas. </li></ul>
  3. 3. <ul><li>Es un proceso temporal que tiene un inicio y fin. </li></ul><ul><li>Su resultado es un producto o servicio único. </li></ul><ul><li>Esta constituido por un conjunto de actividades interrelacionadas que se desarrollan por una sola vez, que constituyen una inversión para el negocio </li></ul><ul><li>Tiene objetivos, alcances y productos entregables específicos y un programa y presupuesto definidos. </li></ul><ul><li>Existen proyectos De Tecnologías de la Información y de e-Business, Desarrollo interno, Desarrollo por terceros, Evaluación e implantación de paquetes, De Soporte Técnico, Adquisición e instalación de hardware/software, Redes y/o comunicaciones </li></ul><ul><li>Se controla : </li></ul>¿Qué es un proyecto? Costos Tiempos Calidad
  4. 4. Alarmante Problema <ul><li>Solución </li></ul><ul><ul><li>Enfoque integral del ciclo de vida </li></ul></ul><ul><ul><li>Técnicas formales y herramientas </li></ul></ul><ul><ul><li>Ingeniería de software </li></ul></ul>Fuente: The Standish Group 2001 <ul><li>Demanda insatisfecha </li></ul><ul><ul><li>Plazos y costos excedidos </li></ul></ul><ul><ul><li>Insuficiente productividad </li></ul></ul><ul><ul><li>Calidad inadecuada </li></ul></ul><ul><li>Causas </li></ul><ul><ul><li>Naturaleza del software </li></ul></ul><ul><ul><li>Inadecuado enfoque gerencial </li></ul></ul><ul><ul><li>Carencia de tecnología </li></ul></ul>71% de todos los proyectos fallan, ya sea que se han excedido el presupuesto o empiezan a funcionar después del plazo original. Cada año, 75 millones de dólares se pierden por fallas de los proyectos en los Estados Unidos
  5. 5. Porque fracasa el proyecto? Como lo explicó el cliente Como lo entendió el líder del proyecto Como lo diseñó el analista Como lo escribió el programador Como lo recibieron los probadores beta Como lo describió el Consultor de Negocios
  6. 6. Porque fracasa el proyecto? Como se documentó Las operaciones instaladas Lo que se le cobró al Cliente El soporte que se le dio Como se comercializó Lo que el cliente realmente necesitaba
  7. 7. <ul><li>No se comprendieron las necesidades del usuario </li></ul><ul><li>No se previó el impacto de los requerimientos de cambios </li></ul><ul><li>Se descubrieron muy tarde falencias graves en el Proyecto </li></ul><ul><li>Hay módulos que no se pueden integrar </li></ul><ul><li>Interferencias entre los miembros del equipo </li></ul><ul><li>No cumplen sus objetivos </li></ul><ul><li>Se exceden considerablemente en el tiempo </li></ul><ul><li>Se exceden de su presupuesto </li></ul>¿Por qué fracasó? Lo que el cliente realmente necesitaba
  8. 8. ¿Qué es un riesgo del proyecto? <ul><li>Cualquier factor que puede interferir en terminación exitosa del proyecto </li></ul><ul><li>Es reconocer que un problema puede suceder </li></ul><ul><li>Fases del análisis del riesgo </li></ul><ul><ul><li>Identificación del riesgo </li></ul></ul><ul><ul><li>Análisis y cuantificación </li></ul></ul><ul><ul><li>Plan de mitigación </li></ul></ul><ul><ul><li>Asignar responsables </li></ul></ul>
  9. 9. Análisis de Riesgo <ul><li>Estimación del riesgo </li></ul><ul><ul><li>Establecer una escala que refleje la probabilidad observada de riesgo. </li></ul></ul><ul><ul><ul><ul><li>Bastante improbable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Improbable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Moderado </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Probable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Bastante probable </li></ul></ul></ul></ul><ul><li>Impacto (pesos) </li></ul><ul><ul><li>Estimación del impacto de riesgo en el proyecto </li></ul></ul><ul><li>Cálculo de riesgo </li></ul><ul><ul><ul><li>Considerar (riesgo, probabilidad de riesgo, impacto) </li></ul></ul></ul>
  10. 10. ¿Qué se debería hacer? <ul><li>Defina el alcance del proyecto. </li></ul><ul><li>Utilice métricas en su proyecto. ¿Cuánto pesa el software? </li></ul><ul><li>Gestione los riesgos con anticipación. </li></ul><ul><li>Use una metodología probada. </li></ul><ul><li>Modele las amenazas de su proyecto. </li></ul><ul><li>Use herramientas de Verificación de código. </li></ul><ul><li>Haga pruebas exhaustivas. </li></ul>
  11. 12. Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Administrar requerimientos
  12. 13. Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente
  13. 14. Administrar los requerimientos <ul><li>Requirements Management, enfoque sistemático que involucra: </li></ul><ul><ul><li>Obtener, organizar y documentar la funcionalidad y restricciones requeridas a un sistema </li></ul></ul><ul><ul><li>Analizar los cambios solicitados y evaluar impactos </li></ul></ul><ul><ul><li>Registrar y documentar las alternativas y decisiones tomadas </li></ul></ul><ul><li>Área Clave de Proceso para CMM nivel 2 </li></ul>
  14. 15. Administrar los requerimientos <ul><li>Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso </li></ul><ul><li>Los Casos de Uso son importantes instrumentos de planificación </li></ul>Modelo de Diseño Los Casos de Uso direccionan el trabajo desde el análisis hasta el test Modelo de Casos de Uso Modelo de Implementación Modelo de Test verifica Realización influenciados por
  15. 16. Administrar los requerimientos <ul><li>Las comunicaciones están basadas en requerimientos bien definidos </li></ul><ul><li>Los requerimientos pueden ser priorizados, filtrados y monitoreados </li></ul><ul><li>Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto </li></ul><ul><li>Las inconsistencias se detectan fácilmente </li></ul><ul><li>Con herramientas adecuadas: repositorio de requerimientos, con atributos y relaciones </li></ul>
  16. 17. Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Administrar requerimientos
  17. 18. Desarrollar Software Iterativamente <ul><li>Cada iteración resulta en un release ejecutable </li></ul>Planeamiento Inicial Planeamiento Requerimientos Análisis y Diseño Implementación Prueba Distribución Evaluación Ambiente de Administración
  18. 19. Desarrollar Software Iterativamente <ul><li>Los desentendimientos importantes se evidencian tempranamente </li></ul><ul><li>Se alienta el feedback del usuario </li></ul><ul><li>Focalización en los temas más críticos, sin distracciones </li></ul><ul><li>Testing continuo e iterativo: evaluación objetiva </li></ul><ul><li>Inconsistencias entre requerimientos, diseños e implementaciones se detectan tempranamente </li></ul>
  19. 20. Desarrollar Software Iterativamente <ul><li>Carga de trabajo mejor repartida en el tiempo </li></ul><ul><li>El equipo puede analizar las lecciones aprendidas en las primeras iteraciones </li></ul><ul><li>Integración progresiva en lugar de Big Bang </li></ul><ul><li>Se facilita la reutilización </li></ul><ul><li>Arquitectura más robusta </li></ul>
  20. 21. Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente
  21. 22. Verificar la Calidad del Software <ul><li>La actividad fundamental de esta práctica es el testing </li></ul><ul><li>Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance </li></ul>Desarrollo Implementación Costo Encontrar y reparar un problema de software después de la implementación puede resultar de 100 a 1000 veces más costoso
  22. 23. Verificar la Calidad del Software <ul><li>La evaluación del estado del proyecto es objetiva, se evalúan resultados de test. </li></ul><ul><li>Se exponen inconsistencias en requerimientos, diseños e implementaciones </li></ul><ul><li>Se focaliza en las áreas de riesgo más alto </li></ul><ul><li>Los defectos se identifican en forma temprana </li></ul><ul><li>Existen herramientas automatizadas para el testing de funcionalidad, confiabilidad y performance. </li></ul>
  23. 24. Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Verificar Calidad Administrar requerimientos
  24. 25. Diseñar el proceso Logical Design Conceptual Design Scenarios Physical Design Components, User Interface, and Physical Database Objects and Services, User Interface, and Logical Database
  25. 26. Modelar Software Visualmente <ul><li>Diagramas de Casos de Uso </li></ul><ul><li>Diagramas de Clases </li></ul><ul><li>Diagramas de Estados </li></ul><ul><li>Diagramas de Componentes </li></ul><ul><li>Diagramas de Implementación </li></ul>El Modelamiento Visual eleva el nivel de abstracción Código Clases Subsistemas
  26. 27. Modelar Software Visualmente <ul><li>Los casos de uso permiten especificar comportamiento sin ambigüedades </li></ul><ul><li>Quedan expuestas las arquitecturas inflexibles o no modulares </li></ul><ul><li>El diseño refleja sus inconsistencias más rápidamente </li></ul><ul><li>Existen herramientas que proveen soporte para la modelamiento visual </li></ul>
  27. 28. Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Administrar requerimientos
  28. 29. Utilizar Arquitecturas Basadas en Componentes <ul><li>La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software </li></ul><ul><ul><li>selección de los elementos estructurales, y sus interfaces, por los cuales el sistema está compuesto </li></ul></ul><ul><ul><li>comportamiento, especificado como colaboraciones entre los elementos </li></ul></ul><ul><ul><li>composición en subsistemas de los elementos estructurales y de comportamiento </li></ul></ul><ul><ul><li>estilo de arquitectura que guía a la organización </li></ul></ul>
  29. 30. Utilizar Arquitecturas Basadas en Componentes Vista Lógica Vista de Implementación Programadores Administración del Software Vista del Proceso Vista de Desarrollo Topología Distribución, Instalación Comunicación Ingeniería Conceptual Physical Vista de Caso de Uso Usuario Funcionalidad Performance Escalabilidad Rendimiento Integradores
  30. 31. Utilizar Arquitecturas Basadas en Componentes <ul><li>Un componente de software puede definirse como una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida </li></ul><ul><li>Realización física de una abstracción en el diseño </li></ul>Arquitectura basada en componentes System- software Middleware Negocio Aplicación
  31. 32. Utilizar Arquitecturas Basadas en Componentes <ul><li>Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar y probar componentes bien formados </li></ul><ul><li>Desarrollar componentes para ser reutilizados. Formar la base de rehúso de la organización </li></ul><ul><li>Industria de infraestructura de componentes </li></ul><ul><li>COM+ - Microsoft Component Object Model </li></ul><ul><li>CORBA - Common Object Request Broker Architecture - OMG </li></ul><ul><li>JavaBeans – SUN </li></ul><ul><li>Assemblys .NET </li></ul><ul><li>Servicios Web </li></ul>
  32. 33. Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente
  33. 34. Controlar los Cambios al Software <ul><li>Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo </li></ul><ul><li>Establecer “workspaces” seguros para cada desarrollador </li></ul><ul><li>Automatizar la integración y la administración de “builds” </li></ul>Workspace de Administración Integración Desarrollo en paralelo Administración del Build CM es mucho más que check-in y check-out ALERT REPORT
  34. 35. Controlar los Cambios al Software: Beneficios <ul><li>Las solicitudes de cambios formales facilitan la claridad de comunicación </li></ul><ul><li>Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo </li></ul><ul><li>Las estadísticas de cantidad de cambios proveen buenas métricas para evaluar objetivamente el estado del proyecto </li></ul><ul><li>La propagación del cambio es evaluable y controlable </li></ul><ul><li>Los cambios pueden ser mantenidos en sistemas automáticos </li></ul>
  35. 36. Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
  36. 37. Preguntas!????
  37. 38. Referencias <ul><li>El ciclo de vida de desarrollo de Seguridad http://www.microsoft.com/spanish/msdn/articulos/archivo/030505/voices/sdl.mspx </li></ul><ul><li>Ingeniería de Software </li></ul><ul><li>http://www.ingenierosoftware.com/ </li></ul><ul><li>Contrato para desarrollo de Software </li></ul><ul><li>http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5003/desarrol.htm </li></ul>

×