CALIDAD Y TÉCNICAS DE EVALUACIÓN DE LOS SISTEMAS

1. CALIDAD Y TÉCNICAS DE EVALUACIÓN DE LOS SISTEMAS GESTIÓN DE PROYECTOS (PMBOK) PIERRE SERGEI ZUPPA AZÚA

2. GESTIÓN DE PROYECTOS Es la disciplina que guía e integra los procesos de planificar, captar, dinamizar, organizar talentos y administrar recursos, con el fin de culminar todo el trabajo, pero sobretodo cumplir con el alcance, dentro de límites de tiempo, y costo definidos: sin estrés y con buen clima interpersonal. También requiere liderar los talentos, evaluar y regular continuamente las acciones necesarias y suficientes.

3. ENFOQUES DE PROYECTO Ejemplos: • lean (producción esbelta) • Reiterativo • Incremental • fase Sin importar la metodología utilizada, se deben considerar los objetivos totales del proyecto, los tiempos, los costos, los roles y responsabilidades de cada participante (Interesados o stakeholders).

4. PMBOK Project Management Body of Knowledge Desarrollada por el PMI formada por el conjunto de conocimientos en Dirección/ Gestión/ Administración de Proyectos generalmente reconocidos como «buenas prácticas», y que se constituye como estándarde Administración de proyectos. Esta guía comprende: • Los procesos y contextos de un proyecto. • Las áreas de conocimientos específicos para la gestión de un proyecto.

5. ¿POR QUÉ USAR PMBOK? La ventaja de utilizar es que es de aplicación general, es decir que las practicas y conocimientos descritos en él pueden ser, en su mayoría, adaptados a muchas realidades organizacionales. Además, puede decirse que existe una conciencia global acerca de su valor y utilidad. Áreas del conocimiento Procesos básicos

6. MARCO DE REFERENCIA DE PROYECTOS DE TI Se desarrolla a partir de aspectos teóricos, conceptuales, legales, geográficos e institucionales del objeto a investigar.

7. FUNCIONES DEL MARCO DE REFERENCIA • Ayuda a prevenir errores que se han cometido en otros estudios. 2. Nos permite dar cuenta de cómo ha sido tratado un problema (qué tipos de estudios se han efectuado, con qué tipo de sujetos, cómo se han recolectado los datos, en qué lugares se han llevado a cabo, qué diseños se han utilizado). 3. Nos permite centrarnos en el problema evitando desviaciones del planteamiento original. 4. Conduce al establecimiento de hipótesis o afirmaciones que más tarde habrán de someterse a prueba en la realidad.

8. DISCUSIONES ACERCA DE LAS FALLAS Y EL ÉXITO El éxito del proyecto depende directamente del cuidado que se tenga en obtener y gestionar los requisitos del proyecto y del producto. Recopilar requisitos significa definir y gestionar las expectativas del cliente. Laplanificación del costo, del cronograma y de la calidad se efectúa en función de. Hay que distinguir entre requisitos del proyecto y requisitos del producto. Proyecto: pueden incluir los requisitos de la empresa, de dirección de proyectos, de entrega, etc. Producto: pueden incluir la información sobre requisitos técnicos, requisitos de seguridad, de desempeño, etc.

10. HERRAMIENTAS Y TÉCNICAS Entrevistas, cuestionarios, encuestas y observación: A través de estas técnicas, se obtiene información de los interesados, ya sea de manera formal o informal. Grupos de opinión: Se reúne a los interesados claves del proyecto junto con un moderador que guiará al grupo. Talleres facilitados: Se trata de sesiones en las que los interesados interfuncionales, se reúnen para definir los requisitos del producto. Estos talleres proporcionan una definición rápida de los requisitos de funcionabilidad y ayudan a conciliar las diferencias entres los interesados.

11. HERRAMIENTAS Y TÉCNICAS Técnicas grupales de creatividad: ayudan a identificar los requisitos del proyecto y/o del producto: • Tormenta de ideas (Brainstorm) y técnicas de grupo nominal • Técnica Delphi • Mapa conceptual • Diagrama de afinidad • Etc. Técnicas grupales de toma de decisiones: Es un proceso de evaluación de múltiples alternativas con relación a un resultado esperado. (Unanimidad, Mayoría, Pluralidad, Dictadura) Prototipos: Elaboración de una versión preliminar del producto final, para obtener una retroalimentación sobre los requisitos del producto, antes de construirlo

12. SALIDAS Documentación de requisitos: Describe el modo en que los requisitos individuales cumplen con las necesidades del Proyecto. • Justificación del Proyecto (necesidad comercial u oportunidad) • Objetivos de la organización y el Proyecto • Requisitos de funcionabilidad del producto o servicio • Requisitos no funcionales (nivel de servicio, desempeño, seguridad, ect.) • Requisitos de calidad • Criterios de aceptación • Supuestos • Restricciones • Impactos del Proyecto en otras áreas o entidades • Etc.

13. SALIDA Plan de Gestión de requisitos : Documenta cómo se analizarán, documentarán y gestionarán los requisitos a lo largo del Proyecto. Matriz de trazabilidad de requisitos: Tabla que vincula los requisitos con el objetivo que le dio origen, que permite monitorizarlos a lo largo del ciclo de vida del Proyecto.

14. FASES DE INICIACIÓN Consiste en entender el problema o la oportunidad. En primer lugar se requiere diferenciar entre necesidad y solución. Necesidad: • Describe el fin para cliente • Especifica metas y objetivos • Deja abierta la pregunta de cómo hacerlo • La respuesta al porque se esta haciendo debe apuntar a una justificación de negocio. Solución: • Describe los medios para el equipo • Especifica estrategias e ideas para conseguir las metas y objetivos. • Especifica cómo hacerlo. • La respuesta al porque se esta haciendo debe apuntar al requerimiento del cliente. • Preguntar para identificar la necesidad real puede hacer sentir incomodo a terceros por desconfiar de su criterio.

15. FASE INICIAL Esta fase debe tener como output la generación del documento de requerimientos del proyecto, el cual no ofrece una solución sino que únicamente describe una necesidad. Este documento debe contener los siguientes apartados: • Descripción del problema o oportunidad • Impacto o efecto del problema • Identificar quien o que se encuentra afectado por el problema • Impacto de ignorar el problema • Situación deseada • Beneficios asociados a conseguir la situación deseada • Alineación con la estrategia de la organización • Conflicto de compatibilidades con otras áreas de la organización • Incertidumbres • Suposiciones clave • Limitaciones de la solución • Consideraciones del entorno • Información histórica de soporte • A partir de la recopilación de toda esta información, se requiere valorar nuevamente si merece la pena resolver el problema y determinar si existe una solución potencial. Coste del proyecto y nivel de personal típicos a lo largo del ciclo de vida del proyecto

16. ARTEFACTOS DE LA FASE DE INICIO Visión del negocio: Describe los objetivos y restricciones a alto nivel. Modelo de casos de uso. Especificación adicional: requisitos no funcionales. Glosario: Terminología clave del dominio. Lista de riesgos y planes de contingencia. El caso de negocio (business case). Prototipos exploratorios para probar conceptos o la arquitectura. Plan de iteración para la primera iteración de la fase de elaboración. Plan de fases.

17. CONCLUSIONES DE LA FASE DE INICIO Se deben comprobar los criterios de evaluación para continuar. Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda, también deben quedar bien establecidos algunos elementos claves para el correcto desarrollo del proyecto en cuestión, como por ejemplo: • Entendimiento de los requisitos, evidenciado por la fidelidad de los casos de uso principales. • Las estimaciones de tiempo, coste y riesgo deben ser creíbles. • Comprensión total de cualquier prototipo de la arquitectura desarrollado. • Los gastos hasta el momento se asemejan a los planeados. • Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo profundamente.

18. FASES DE PLANIFICACIÓN Consiste en Identificar la solución más óptima Con objeto de identificar soluciones que cubran la necesidad establecida se puede seguir el siguiente procedimiento: • Brainstorming grupal con miembros del futuro equipo de trabajo o stakeholders. • Comprobar en que grado satisfacen los planteamientos del documento de requerimientos del proyecto. • Seleccionar entre 2 y 5 soluciones. • Realizar un análisis detallado para identificar cual de ellas es la que mejor se adapta a la necesidad a cubrir e implica un coste asumible. Influencia de la estructura de la organización en los proyectos

19. ANÁLISIS FINANCIERO(COSTES VS BENEFICIOS) Para validar la viabilidad financiera del proyecto es necesario identificar los flujos de entrada de dinero que este puede generar, por ejemplo beneficios obtenidos por la implementación del proyecto (incremento en ventas, reducción en costes, etc…) y los gastos que representa la puesta en marcha y gestión del proyecto. Influencia de los interesados a lo largo del tiempo

20. CASH FLOWS Para identificar que proyecto nos aporta una mayor rentabilidad financiera. • Net PresentValue (NPV). Determina cuanto dinero va a generar el proyecto teniendo en cuenta el valor del dinero en el tiempo. • InternalRate of Return (IRR). Determina la rentabilidad de la inversión. • Paybackperiod. Determina cuando se recuperará la inversión (NPV = 0). • Cash hole. Determina la máxima inversión necesaria.

21. ANÁLISIS NO FINANCIERO (MODELO DE PUNTUACIÓN DE FACTORES PONDERADOS – DECISION MATRIX) Se inicia mediante la elaboración de un listado de atributos a valorar. Para cada uno de ellos se establece una ponderación y se asignan puntuaciones que denoten el nivel de cumplimiento de cada una de las soluciones.

22. Ventajas: • Permite el uso de diversos datos, incluidos los financieros. • Permite la implicación de gerencia y el análisis de sensibilidad. Desventajas: • Proceso altamente subjetivo. • Muestra el atractivo del proyecto pero no representa una justificación de negocio.

23. OTRAS HERRAMIENTAS Estudios de mercado Pruebas piloto. Prueba en área limitada. Prototyping. Construcción de una pequeña parte del proyecto para validar las correctas predicciones. Simulación por ordenador.

24. FASES DE CONTROL Consiste en desarrollo de la solución y elaboración de un plan En esta fase se desarrollará en un mayor detalle la solución escogida mediante el uso de un Logframe (esquema básico de definición del proyecto). • Objetivo • Propósito • Resultados • Actividades Para cada uno de estos niveles se debe especificar: • Indicadores que permitan verificar la evolución. • Medios para obtener la información necesaria para constituir los indicadores. • Supuestos clave y el riesgo asociado.

25. STAKEHOLDERS El logframe permitirá monitorizar y evaluar la evolución del mismo. Un logframe debe ser conciso y fácilmente comprensible por personas que se incorporan a mitad de proyecto. Paralelamente a la elaboración del logframe, se requiere realizar un análisis de los stakeholders del proyecto con el objetivo de gestionar las relaciones y prever oposiciones. Se considera stakeholders aquellos individuos o instituciones que: • Pueden ganar o perder dependiendo del éxito del proyecto. • Proveen fondos económicos • Proveen recursos al proyecto • Participa/trabaja en el proyecto • Se encuentran afectados por el rendimiento del proyecto • Se encuentran afectados por el resultado del proyecto

26. DOCUMENTO DE DEFINICIÓN DE PROYECTO  Se realiza con la finalidad de: • Identificar el trabajo a realizar. • Durante la ejecución, permite identificar cuando se esta sobrepasando los limites y permite renegociar el contrato original. • Establece el criterio para considerar completado el proyecto. • Establece los criterios para considerar exitoso el proyecto. • Permite llegar a acuerdos y facilitar la comunicación.

27. EL DOCUMENTO DEBE CONTENER • Breve descripción del problema u oportunidad • Breve descripción de la solución propuesta • Descripción del trabajo y la estrategia de ejecución. Identificar las diferentes grandes tareas y sus interrelaciones. Parte más importante del documento. Será la base para el WBS. • Entregables acordados. • Criterios de finalización de proyecto. • Riesgos e incertidumbres. • Suposiciones. • Plan preeliminar de ejecución. • Listado de los stakeholders involucrados. • Criterios de éxito del proyecto.

28. FASE CIERRE Se considerará que el proyecto ha llegado a su fin cuando todos los entregables hayan sido enviados al cliente, todo esté documentado y el cierre formal del proyecto haya sido aceptado por él. En ese momento los recursos asignados al proyecto se liberarán y entrará en juego el servicio de Soporte Post-Venta para resolver cualquier duda o incidencia que pudiera surgir.

29. CIERRE PMBOK - La administración y cierre de contratos: Evaluando el proceso y extrayendo de este las posibles lecciones aprendidas. - El cierre administrativo del proyecto: este proceso consiste en la revisión de todos los reportes de avance generados durante el proyecto, para garantizar que se hay cumplido con todas las actividades y se han obtenido los entregables esperados.

30. IMPORTANCIA DEL CIERRE DEL PROYECTO ¿Qué aprender después del cierre? • Incorporar a próximos proyectos actividades que no se habían visualizado. • Reconsiderar estimados en la duración o en el costo de una actividad. • Identificar riesgos, previamente no considerados. • Incorporar nuevas cláusulas o quitar trabas legales, para potenciar una contratación más transparente. • Determinar mejores especificaciones de calidad. • Introducir novedosos incentivos al personal. • Concientizar en lo referente a la necesidad de subcontratar algunas actividades, en las que no se tiene un know – howde primer nivel.