Your SlideShare is downloading. ×
Conferencia Gestión de Proyectos de TI
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Conferencia Gestión de Proyectos de TI

13,221
views

Published on

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

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

Published in: Business

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
13,221
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
1,395
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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