0184 planificacion de_proyectos_dirigida_por_la_arquitectura_ppda

1,164 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,164
On SlideShare
0
From Embeds
0
Number of Embeds
47
Actions
Shares
0
Downloads
58
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

0184 planificacion de_proyectos_dirigida_por_la_arquitectura_ppda

  1. 1. Estrategia de Gestión de Proyectos Dirigida por la Arquitectura <br />Ing. Mariel Feder, MC, PMP<br />
  2. 2. Qué es la gestión de un proyecto?<br />Gestionar un proyecto consiste en asegurar que se entregará un producto que cumpla con las especificaciones dentro del plazo y costo acordado, con el nivel de calidad pactado<br />Entorno de Naturaleza Cambiante<br />Incertidumbre (RRHH, tecnológicos, negocio)<br />
  3. 3. Ciclo de vida del proyecto<br />
  4. 4. Inicialización<br />Análisis de consecuencias<br />Definición de magnitudes<br />Análisis de alternativas<br />Análisis técnicos (viabilidad, mat, rec, etc)<br />Análisis de inversión y rentabilidad<br />Análisis de riesgo<br />
  5. 5. Planificación<br />Esquema de trabajo para alcanzar el objetivo<br />Estimaciones<br />Se itera durante el proyecto<br />
  6. 6. Producción o Implementación<br />Administración<br />Ejecución<br />Control<br />Cierre<br />
  7. 7. Administración<br />Planificación <br />general<br />Planificación <br />específica<br />Ejecución<br />Retroalimentación<br />Inicio<br />Planificación<br />Control<br />Producción<br />Etapas en la gestión de un proyecto<br />
  8. 8. Arquitectura de Software<br />Disciplina joven<br />Bass, Clements y Kazman: La arquitectura de un programa o sistema de computación es la estructura o estructuras del sistema, que comprenden sus componentes de software, las propiedades externas de los componentes, y la relación entre ellos, que coincide con la propuesta por Soni, Nord y Hofmeister<br />
  9. 9. Ciclo de vida del Desarrollo del Producto<br />Orden de las actividades que ocurren durante el desarrollo<br />
  10. 10. Cascada (Royce, 1970)<br />Secuencia de fases que no se repite:<br />Planificar el proyecto antes de comenzar<br />Definir el comportamiento externo esperado del sistema antes de definir su funcionamiento interno.<br />Documentar los resultados de cada actividad<br />Diseñar el sistema antes de codificarlo<br />Testear el sistema una vez que está construido.<br />
  11. 11. Cascada<br />Requerimientos<br />Arquitectura<br />Diseño<br />Codificación y testing unitario<br />Integración<br />Operación<br />Ciclo de vida en Cascada<br />
  12. 12. Requerimientos<br />Arquitectura<br />Diseño<br />Diseño<br />Codificación y testing unitario<br />Codificación y testing unitario<br />Integración<br />Integración<br />Operación<br />Operación<br />Ciclo de vida de desarrollo incremental<br />Desarrollo Incremental (Hirsch, 1985)<br />
  13. 13. Evolutivo (Basili - Turner, 1975)<br />Requerimientos<br />Requerimientos<br />Diseño<br />Diseño<br />Codificación y testing unitario<br />Codificación y testing unitario<br />Integración<br />Integración<br />Operación<br />Operación<br />Ciclo de Vida Evolutivo<br />
  14. 14. Otros<br />Espiral (Boehm 1988)<br />Prototipación<br />Etc<br />
  15. 15. Proceso para Gestión de Proyectos dirigidos por la arquitectura<br />
  16. 16. Ciclo de vida para PDA<br />Autores como Paulish, importancia a Arquitectura previa.<br />Necesaria para PDA<br />Ciclo cascada/incremental<br />
  17. 17. Planificación del Proyecto<br />Proyectos bien gestionados comienzan como proyectos bien planificados.<br />Cuándo: en paralelo con la definición del a arquitectura.<br />Presión externa. Problema de estimaciones tempranas.<br />Cronograma viable, metas intermedias.<br />
  18. 18. Estimación<br />Pequeño grupo arq. de alto nivel<br />Mecanismos de estimación top-down (Cocomo, Puntos Funcion, Slim, Price-S)<br />Basarse en componentes para estimación Bottom Up (vista lógica de Krutchen). Responsabilidad del arquitecto<br />Integración de ambas estimaciones.<br />
  19. 19. Top-Down vs Bottom Up<br />Bottom up: mayor precision en cada componente<br />Top down: incluye otras tareas<br />Integración entre ambas<br />Cota mínima: Bottom up<br />
  20. 20. Identificación<br />Análisis<br />Planificación<br />Seguimiento<br />Ciclo de gestión de Riesgo<br />Evaluación<br />Análisis de Riesgo<br />
  21. 21. Identificación<br />Análisis<br />Planificación<br />Seguimiento<br />Ciclo de gestión de Riesgo<br />Evaluación<br />Análisis de Riesgo<br />
  22. 22. Riesgos y Arquitectura<br />Arquitectura como entrada importante<br />Riesgos técnicos<br />
  23. 23. Riesgos y Arquitectura – Check list<br />Experiencia de los equipos de desarrollo en las plataformas, lenguajes y herramientas seleccionadas<br />Estabilidad de las herramientas y plataformas<br />Disponibilidad de las herramientas y plataformas<br />Integrabilidad de las plataformas seleccionadas<br />Interoperabilidad entre los componentes diseñados<br />
  24. 24. Riesgos y Arquitectura – Check list<br />Nivel de complejidad, testeabilidad y acoplamiento de los componentes<br />Identificación de los componentes críticos ya sea por su importancia para el funcionamiento del producto o por su complejidad.<br />Atributos de calidad requeridos que resulten críticos para el producto (ej.: performance, seguridad, amigabilidad, etc.) y que la arquitectura debe garantizar<br />
  25. 25. Plan de Versiones<br />Desarrollo simultáneo?<br />Desarrollos en paralelo y en secuencia<br />Identificación de paquetes o componentes y precedencias<br />Puntos de control, plan de versiones<br />Arquitectura como input para este proceso<br />
  26. 26. Criterios para orden y contenido de las versiones<br />Dirigido por el riesgo<br />Dirigido por las necesidades del usuario/mercado<br />Secuencia lógica<br />Dirigido por la capacitación<br />Combinación<br />
  27. 27. Arquitectura<br />Identificación de componentes o paquetes por funcionalidad<br />Complejidad y criticidad de los componentes (entrada también para la estrategia de testing).<br />
  28. 28. Recursos Humanos<br />Reclutamiento: Perfiles necesarios<br />Organización de los equipos: Vertical, Horizontal<br />
  29. 29. Organización de equipos horizontal<br />Equipo 3<br />Capa/componente 3<br />Equipo 2<br />Capa/componente 2<br />Equipo 1<br />Capa/componente 1<br />Organización de equipos horizontal<br />
  30. 30. Org. Equipos horizontal<br />Expertos en el componente<br />Uniformidad en el componente<br />Equipos simultáneos<br />Visibilidad parcial<br />
  31. 31. Org. Equipos Vertical<br />Equipo 2<br />Equipo 1<br />Equipo 3<br />Capa/componente 3<br />Capa/componente 2<br />Capa/componente 1<br />
  32. 32. Org. Equipos vertical<br />Posibilidad de un solo equipo (serialización)<br />Evitar problemas de comunicación.<br />Visión completa de la funcionalidad<br />Componentes menos cohesivos o redundancia<br />
  33. 33. Proyectos de gran porte<br />Combinaciones:<br />Equipos horizontales y sub-equipos verticales o viceversa, en base a la arquitectura.<br />Integrar participantes del diseño<br />Visión más global<br />Compromiso con la estimación<br />
  34. 34. Organización del cronograma<br />WBS – Work BreakDown Structure<br />Orientadas a la función<br />Orientadas a la fase<br />Orientadas al producto<br />Híbridos<br />
  35. 35. Proyecto<br />Diseño<br />Requerimientos<br />Integración<br /> y Testing<br />Implementación<br />Arquitectura<br />Implantación<br />Modulo 1<br />Modulo 2<br />Modulo 1<br />Modulo 2<br />Modulo 2<br />Modulo 1<br />Modulo 2<br />Modulo 1<br />WBS Orientada a la fase<br />WBS Orientada a la Fase<br />
  36. 36. Proyecto<br />Modulo 2<br />Modulo 1<br />Implantación<br />Análisis<br />Análisis<br />Implantación<br />Testing e <br />Integración<br />Diseño<br />Testing<br />Diseño<br />Implementación<br />Implementación<br />WBS orientada al producto<br />WBS Orientada al Producto<br />
  37. 37. Cronograma<br />Sugerencia: imitar el ciclo de vida.<br />Hitos según plan de versiones<br />Componentes de las iteraciones surgen del arquitectura<br />
  38. 38. Cronograma<br />
  39. 39. Factores a considerar<br />Estimación del esfuerzo de cada componente<br />Cantidad de recursos humanos, perfiles y requerimientos de cada componente<br />Secuencia de desarrollo según el plan de versiones.<br />Otras restricciones:<br />Tiempo máximo de desarrollo<br />Presupuesto<br />Flujo de caja, etc.<br />
  40. 40. Resumen del Proceso<br />
  41. 41. Proceso de planificación y organización del proyecto<br />Ing. de Requerimientos<br />Integración<br />de<br />estimaciones<br />Estimación Top-Down<br />Estimación Bottom-Up<br />Arquitectura<br />Plan de Versiones<br />Confección del cronograma<br />Análisis de Riesgo<br />Organización de los equipos<br />
  42. 42. Resumen Proceso<br />A partir de los requerimientos funcionales y no funcionales se diseña la arquitectura del producto mientras en paralelo se realiza la estimación top-down del proyecto.<br />A partir de la arquitectura se realiza una estimación bottom-up de cada uno de los componentes identificados.<br />Se integran ambas estimaciones en la que se utilizará para la planificación del proyecto.<br />Se realiza el análisis de riesgo, incorporando a la arquitectura como fuente de posibles riesgos que pueden afectar al proyecto. Algunos de los riesgos identificados pueden ocasionar la toma de decisiones que afecten la arquitectura con lo que se repite el ciclo.<br />
  43. 43. Resumen del Proceso<br />A partir de la arquitectura, los requerimientos o necesidades del usuario y del análisis de riesgo, se confecciona el plan de versiones.<br />A partir de la arquitectura, se organizan los equipos que participarán en el proyecto.<br />A partir del plan de versiones, del resultado del proceso de estimación, de las tareas de prevención y de las decisiones tomadas a partir del análisis de riesgo, y de los equipos previstos se confecciona el cronograma. Algunas consideraciones en el momento de confeccionar el cronograma para tener en cuenta todas las restricciones del proyecto pueden afectar la organización de los equipos, con lo que se vuelve a iterar el ciclo hasta encontrar el punto de equilibro.<br />Una vez definidos el plan de versiones y el cronograma, puede comenzar el desarrollo del proyecto, el cual se gestionará para mantenerlo dentro de lo previsto en los documentos obtenidos como resultado del proceso descripto <br />
  44. 44. Referencias Bibliográficas<br />Feder, Mariel. Gestión de proyectos dirigida por la Arquitectura. Congreso Argentino de Ciencias de la Computación. 2003<br />A guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, www.pmi.org.<br />Humphrey, W.S, Managing the software process <br />Bass, Clements y Kazman 1998. Software Architecture in Practice. Massachusetts, USA. Addison Wesley.<br />Soni D, Nord R y Hofmeister C, Software Architecture in Industrial Applications, en Proceedings of the 17th International Conference on Software Engineering, New York: ACM Press, 1995.<br />Davis Alan M., Software Life Cycle Models. Software Engineering project management, editado por Richard H Thayer, 2ª edición. IEEE Computer Society Press, 1988<br />Royce W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc. 1970 WESCON Technical Papers, Vol. 14, 1970<br />Hirsch E., Evolutionary Acquisition of Command and Control Systems, Program Manager, Nov. Dec. 1985.<br />Giddings R.V, Accommodating Uncertainty in Software Design, Comm ACM, Vol 27, N° 5, May 1984.<br />
  45. 45. Referencias Bibliográficas<br />Gomaa H y Scott D, Prototyping as a Tool in the Specification of User Requirements, Proc. 5th IEEE International Conference on Software Engineering, IEEE CS Press, Los Alamitos, California, 1981.<br />Boehm B.W. A Spiral Model of Software Development and Enhancement, Computer, May 1988.<br />Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, 2002.<br />Boehm B, Software Engineering Economics, E Englewood Cliffs, NJ, Prentice Hall 1981.<br />Boehm B. et al, Software Cost Estimation with Cocomo II, Upper Saddel River, NJ, Prentice Hall, 2000.<br />Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, 2002.<br />KRUTCHEN Philippe. Noviembre 1995. The 4+1 View Model of Architecture. IEEE Software, 12(6), pp 42-50.<br />Higuera R.P, Software Risk Management, CMU/SEI-96-TR-012 ESC-TR-96-012, Software Engineering Institute (SEI), www.sei.cmu.edu<br />
  46. 46. Referencias Bibliográficas<br />Grey S, Practical Risk Assessment for Project Management, John Wiley & Sons<br />Karolak D.W, Software Engineering Risk Management, IEEE Computer Society Press<br />Michaels J.V, Technical Risk Management, Prentice Hall<br />BASS L. et al. Quality Attribute Design Primitives. Technical Note CMU/SEI-2000-TN-017. Diciembre 2000<br />BASS L., et al. Quality Attribute Design Primitives and the Attribute Drive Design Method. SEI, Carnegie Mellon University, Pittsburgh.<br />MOUSQUES Gastón. 2002. Transparencias Curso de Arquitectura. Ingeniería de Sistemas, Universidad ORT, Uruguay.<br />KAZMAN R. et al. Octubre 1999. Attribute Based Architectural Styles. Technical Report CMU/SEI-99-TR022.<br />Thayer R, Software Engineering Project Management <br />Rees F, Equipos de trabajo, Prentice Hall 1997<br />Simons, Lucarelli, Work Breakdown Structures <br />Gido, Clements, Network Planning and Scheduling <br />Pinto J, Project Management Handbook, PMI<br />

×