El documento presenta las seis mejores prácticas para la gestión de proyectos de TI: 1) controlar cambios, 2) administrar requerimientos, 3) usar arquitecturas basadas en componentes, 4) desarrollar iterativamente, 5) verificar calidad, y 6) modelar visualmente. También discute conceptos como qué es un proyecto, riesgos, y fracasos comunes de proyectos.

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.

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