Source: http://docplayer.es/2413190-Guia-de-aprendizaje-tema-7-gestion-de-riesgos-en-proyectos-software.html
Timestamp: 2016-12-04 16:51:46+00:00

Document:
⭐GUÍA DE APRENDIZAJE - TEMA 7 GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE
Download "GUÍA DE APRENDIZAJE - TEMA 7 GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE"
Mario Peralta Muñoz
1 GUÍA DE APRENDIZAJE - TEMA 7 GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE Objetivos: Plantear la importancia de realizar una adecuada gestión de riesgos en los proyectos software. Conocer los riesgos más habituales y algunos métodos para mantener el control. Índice: 1. Introducción. 2. Planificación de los riesgos Identificación Análisis Priorización Planificación de respuestas. 3. Supervisión y control de riesgos Supervisión Resolución o control. Bibliografía utilizada: CON PMI Connell, S. Desarrollo y Gestión de Proyectos Informáticos. McGraw- Hill Iberoamericana, Project Management Institute, A Guide to the Project Management Body of Knowledge, USA Cap. 5 Cap. 11 NOTAS DE USO: Se indica la referencia de la bibliografía básica (siglas y número de página). Ejemplo: GIL- 9/10 significa páginas 9 a 10 de la referencia GIL (ver tabla de bibliografía básica). Las transparencias que corresponden se indican entre corchetes. Ejemplo: [T13]. Se incluyen Ejercicios para realizar por parte de los alumnos. Se identifican con el símbolo. Contenido: Introducción [T5] - MAPA DEL TEMA RESPECTO A PMBOK. - Lugar que ocupan en el marco PMI de Gestión de Proyectos los conceptos, técnicas y herramientas del tema: 7 Gestión de Riesgos en Proyectos Software 12 Área Proceso Grupo Riesgos Identificación Planificación Análisis Cuantitativo Planificación de Respuestas Supervisión y Control Conceptos, técnicas y herramientas C=conceptos, T=técnicas y herramientas, O=salidas T: Listas de Comprobación de Riesgos C: Riesgos en Proyectos Software T: Tablas de Estimación de Riesgos Planificación T: Priorización de Riesgos O: Planes de Contingencia Planificación O: Plan C. Supervisión de riesgos en proyectos software Control C: Resolución o control de riesgos en proyectos software C: conceptos que amplían y extienden lo comentado del proceso en el tema 4, pero ahora particularizando en proyectos informáticos y especialmente proyectos software (PS). T: técnicas y herramientas útiles en el proceso. O: salidas (outputs), es decir, resultados del proceso. Concepto de Riesgo PMI-127/129, [T6] Riesgo en un proyecto: evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto. Un riesgo tiene una causa y, si ocurre (evento de riesgo), una consecuencia (efecto). Riesgos conocidos: aquellos que han sido identificados y analizados durante la planificación del proyecto. Habitualmente se gestionan los riesgos con efecto negativo, es decir, aquellos que suponen una amenaza para el éxito del proyecto. Concepto de Gestión de Riesgos CON-92, [T7] La función de la gestión de riesgos del software es identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la finalización satisfactoria de un proyecto software. Dependiendo del momento en que se detecta la ocurrencia del riesgo, existen cinco niveles de gestión de riesgos: 1. Control de crisis: intentar controlar los riesgos cuando ya se han convertido en problemas. 2. Arreglar cada error: reaccionar rápidamente cuando ya se ha producido el riesgo. 3. Mitigación de riesgos: planificar con antelación el tiempo que necesitaría para cubrir riesgos en caso de que ocurran, pero sin intentar eliminarlos inicialmente. 4. Prevención: crear y ejecutar, como parte del proyecto software, un plan para identificar riesgos y evitar que se conviertan en problemas. 5. Eliminación de causas principales: identificar y eliminar los factores que pueden provocar la presencia de algún tipo de riesgo. En este tema estudiaremos la gestión de riesgos en los niveles 4 y 5; si se pretende controlar los riesgos en los tres primeros niveles, está perdida la planificación del proyecto. PMI-127, [T8] Los seis procesos que forman la Gestión de Riesgos en el modelo PMI, son los siguientes: a) De planificación: 7 Gestión de Riesgos en Proyectos Software 23 - Planificación de la Gestión de Riesgos: decidir cómo abordar y planificar las actividades de gestión de riesgos en el proyecto. - Identificación de Riesgos: determinar cuales son los riesgos que pueden afectar al proyecto y documentar sus características. - Análisis Cualitativo de Riesgos: realizar un análisis cualitativo de los riesgos y sus condiciones para priorizar sus efectos sobre los objetivos del proyecto. - Análisis Cuantitativo de Riesgos: estimar la probabilidad y consecuencias de los riesgos y sus implicaciones sobre los objetivos del proyecto. - Planificación de Respuestas a los Riesgos: elaborar procedimientos y técnicas para oportunidades de mejora y reducir las amenazas a los objetivos del proyecto. b) De Control: - Supervisión y Control de Riesgos: supervisar los riesgos residuales, identificar nuevos riesgos, ejecutar planes de reducción de riesgos, y evaluar su efectividad a lo largo del ciclo de vida del proyecto. [T9] Nosotros los vamos a estudiar agrupados de la siguiente manera (grupos de procesos, procesos, actividades): - De Planificación - Identificación - Estimación (en PMBOK son los dos procesos de análisis) - Análisis - Priorización - Planificación de Respuestas - De Control - Supervisión y Control de Riesgos - Supervisión (monitorización) - Resolución o control No siempre se mantiene esta estructura de procesos y tareas. Por ejemplo, en el libro de Connell la Planificación de respuestas (llamado ahora planificación de la gestión) se incluye en el Control en lugar de la planificación). Planificación Identificación CON-94/95, [T10] Identificar los riesgos potenciales que pueden ocurrir en el proyecto. Los más habituales (aunque no de obligada aparición) en proyectos software son los mostrados en la tabla siguiente: Cambio de requisitos Meticulosidad en requerimientos o de los desarrolladores Escatimar en la calidad Planificaciones demasiado optimistas Diseño inadecuado Síndrome de la panacea ( esta herramienta ahorrará la mitad del trabajo ) Desarrollo orientado a la investigación (proyectos muy novedosos, más propios de investigación que de desarrollo) Personal mediocre 7 Gestión de Riesgos en Proyectos Software 34 Errores en la contratación Diferencias con los clientes Listas de Comprobación (Checklists) PMI-133, [T11] Se construyen a partir de información histórica. Ventaja: permiten una identificación de riesgos rápida y relativamente sencilla. Desventaja: es prácticamente imposible tener una lista que incluye todos los posibles riesgos en un proyecto software. Se resuelve utilizando la lista como punto de partida, pero permitiendo después incluir nuevos riesgos específicos del proyecto. CON-95/101, [T12] Nosotros vamos a emplear una lista muy completa, que agrupa los riesgos de proyectos software en las siguientes categorías: A. Elaboración de la Planificación B. Organización y Gestión C. Ambiente/Infraestructura de Desarrollo D. Usuarios finales E. Cliente F. Personal Contratado G. Requisitos H. Producto I. Fuerzas Mayores J. Personal K. Diseño e Implementación L. Proceso Esta lista será utilizada en el trabajo T4. De ahí los códigos incluidos. 111 riesgos. A. Elaboración de la Planificación A.1. Las definiciones de la planificación, de los recursos y del producto han sido impuestas por el cliente o un directivo superior, y no están equilibradas. A.2. Planificación optimista, «mejor caso» (en lugar de realista, «caso esperado»). A.3. La planificación no incluye tareas necesarias. A.4. La planificación se ha basado en la utilización de personas especificas de un equipo, pero estas personas no están disponibles. A.5. No se puede construir un producto de tal envergadura en el tiempo asignado. A.6. El producto es más grande que el estimado (en líneas de código, en el número de puntos función, o en relación con el tamaño del proyecto anterior). A.7. El esfuerzo es mayor que el estimado (por líneas de código, número de puntos función, módulos, etc.). A.8. La reestimación debida a un retraso en la planificación es demasiado optimista o ignora la historia del proyecto. A.9. La presión excesiva en la planificación reduce la productividad. A.10. La fecha final ha cambiado sin ajustarse al ámbito del producto o a los recursos disponibles. A.11. Un retraso en una tarea produce retrasos en cascada en las tareas dependientes. A.12. Las áreas desconocidas del producto llevan más tiempo del esperado en el diseño y en la implementación. B. Organización y Gestión B.1. El proyecto carece de un promotor efectivo en los superiores. B.2. El proyecto languidece demasiado en el inicio difuso. B.3. Los despidos y las reducciones de la plantilla reducen la capacidad del equipo. B.4. Dirección o marketing insisten en tomar decisiones técnicas que alargan la planificación. 7 Gestión de Riesgos en Proyectos Software 45 B.5. La estructura inadecuada de un equipo reduce la productividad. B.6. El ciclo de revisión/decisión de la directiva es más lento de lo esperado. B.7. El presupuesto varía el plan del proyecto. B.8. La dirección toma decisiones que reducen la motivación del equipo de desarrollo. B.9. Las tareas no técnicas encargadas a terceros necesitan más tiempo del esperado (aprobación del presupuesto, aprobación de la adquisición de material, revisiones legales, seguridad, etc.). B.10. La planificación es demasiado mala para ajustarse a la velocidad de desarrollo deseada. B.11. Los planes del proyecto se abandonan por la presión, llevando al caos y a un desarrollo ineficiente. B.12. La dirección pone más énfasis en las heroicidades que en informarse exactamente del estado, lo que reduce su habilidad para detectar y corregir problemas. C. Ambiente/Infraestructura de Desarrollo C.1. Los espacios no están disponibles en el momento necesario. C.2. Los espacios están disponibles pero no son adecuados (por ejemplo, falta de teléfonos, cableado de la red, mobiliario, material de oficina, etc.). C.3. Los espacios están sobreutilizados, son ruidosos o distraen. C.4. Las herramientas de desarrollo no están disponibles en el momento deseado. C.5. Las herramientas de desarrollo no funcionan como se esperaba; el personal de desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas. C.6. Las herramientas de desarrollo no se han elegido en función de sus características técnicas, y no proporcionan las prestaciones previstas. C.7. La curva de aprendizaje para la nueva herramienta de desarrollo es más larga de lo esperado. D. Usuarios Finales D.1. Los usuarios finales insisten en nuevos requisitos. D.2. En el último momento, a los usuarios finales no les gusta el producto, por lo que hay que volver a diseñarlo y a construirlo. D.3. Los usuarios no han realizado la compra del material necesario para el proyecto y, por tanto, no tienen la infraestructura necesaria. D.4. No se ha solicitado información al usuario, por lo que el producto al final no se ajusta a las necesidades del usuario, y hay que volver a crear el producto. E. Cliente E.1. El cliente insiste en nuevos requisitos. E.2. Los ciclos de revisión/decisión del cliente para los planes, prototipos y especificaciones son más lentos de lo esperado. E.3. El cliente no participa en los ciclos de revisión de los planes, prototipos y especificaciones, o es incapaz de hacerlo, resultando unos requisitos inestables y la necesidad de realizar unos cambios que consumen tiempo. E.4. El tiempo de comunicación del cliente (por ejemplo, tiempo para responder a las preguntas para aclarar los requisitos) es más lento del esperado. E.5. El cliente insiste en las decisiones técnicas' que alargan la planificación. E.6. El cliente intenta controlar el proceso de desarrollo, con lo que el progreso es más lento de lo esperado. E.7. Los componentes suministrados por el cliente no son adecuados para el producto que se está desarrollando, por lo que se tiene que hacer un trabajo extra de diseño e integración. E.8. Los componentes suministrados por el cliente tienen poca calidad, por lo que tienen que hacerse trabajos extra de comprobación, diseño e integración. E.9. Las herramientas de soporte y entornos impuestos por el cliente son incompatibles, tienen un bajo rendimiento o no funcionan de forma adecuada, con lo que se reduce la productividad. E.10. El cliente no acepta el software entregado, incluso aunque cumpla todas sus especificaciones. E.11. El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar. F. Personal Contratado F.1. El personal contratado no suministra los componentes en el período establecido. F.2. El personal contratado proporciona material de una calidad inaceptable, por lo que hay que añadir un tiempo extra para mejorar la calidad. F.3. Los proveedores no se integran en el proyecto, con lo que no se alcanza el nivel de rendimiento que se necesita. 7 Gestión de Riesgos en Proyectos Software 56 G. Requisitos G.1. Los requisitos se han adaptado, pero continúan cambiando. G.2. Los requisitos no se han definido correctamente. y su redefinición aumenta el ámbito del proyecto. G.3. Se añaden requisitos extra. G.4. Las partes del proyecto que se no se han especificado claramente consumen más tiempo del esperado. H. Producto H.1. Los módulos propensos a tener errores necesitan más trabajo de comprobación, diseño e implementación. H.2. Una calidad no aceptable requiere de un trabajo de comprobación, diseño e implementación superior al esperado. H.3. Utilizar lo último en informática alarga la planificación de forma impredecible. H.4. El desarrollo de funciones software erróneas requiere volver a diseñarlas y a implementarlas. H.5. El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla y a implementarla. H.6. El desarrollo de funciones software innecesarias alarga la planificación. H.7. Alcanzar el ámbito del producto o las restricciones de velocidad requiere más tiempo del esperado, incluyendo el tiempo para volver a diseñar e implementar. H.8. Unos requisitos rígidos de compatibilidad con el sistema existente necesitan un trabajo extra de comprobación, diseño e implementación. H.9. Los requisitos para crear interfaces con otros sistemas, otros sistemas complejos, u otros sistemas que no están bajo el control del equipo de desarrollo suponen un diseño, implementación y prueba no previstos. H.10.El requisito de trabajar con varios sistemas operativos necesita más tiempo del esperado. H.11.El trabajo con un entorno software desconocido causa problemas no previstos. H.12.El trabajo con un entorno hardware desconocido causa problemas imprevistos. H.13.El desarrollo de un tipo de componente nuevo para la organización consume más tiempo del esperado. H.14.Depender de una tecnología que aún está en fase de desarrollo alarga la planificación. I. Fuerzas mayores I.1. El producto depende de las normativas del gobierno, que pueden cambiar de forma inesperada. I.2. El producto depende de estándares técnicos provisionales, que pueden cambiar de forma inesperada. J. Personal J.1. La contratación tarda más de lo esperado. J.2. Las tareas preliminares (por ejemplo, formación, finalización de otros proyectos, adquisición de licencias) no se han completado a tiempo. J.3. La falta de relaciones entre la dirección y el equipo de desarrollo ralentiza la toma de decisiones. J.4. Los miembros del equipo no se implican en el proyecto, y por lo tanto no alcanzan el nivel de rendimiento deseado. J.5. La falta de motivación y de moral reduce la productividad. J.6. La falta de la especialización necesaria aumenta los defectos y la necesidad de repetir el trabajo. J.7. El personal necesita un tiempo extra para acostumbrarse a trabajar con herramientas o entornos nuevos. J.8. El personal necesita un tiempo extra para acostumbrarse a trabajar con hardware nuevo. J.9. El personal necesita un tiempo extra para aprender un lenguaje de programación nuevo. J.10. El personal contratado abandona el proyecto antes de su finalización. J.11. Alguien de la plantilla abandona el proyecto antes de su finalización. J.12. La incorporación de nuevo personal de desarrollo al proyecto ya avanzado, y el aprendizaje y comunicaciones extra imprevistas reducen la eficiencia de los miembros del equipo existentes. J.13. Los miembros del equipo no trabajan bien juntos. J.14. Los conflictos entre los miembros del equipo conducen a problemas en la comunicación y en el diseño, errores en la interfaz y tener que repetir algunos trabajos. J.15. Los miembros problemáticos de un equipo no son apartados, influyendo negativamente en la motivación del resto del equipo. J.16. Las personas más apropiadas para trabajar en el proyecto no están disponibles. 7 Gestión de Riesgos en Proyectos Software 67 J.17. Las personas más apropiadas para trabajar en el proyecto están disponibles, pero no se pueden incorporar por razones políticas o de otro tipo. J.18. Se necesitan personas para el proyecto con habilidades muy específicas y no se encuentran. J.19. Las personas clave sólo están disponibles una parte del tiempo. J.20. No hay suficiente personal disponible para el proyecto. J.21. Las tareas asignadas al personal no se ajustan a sus posibilidades. J.22. El personal trabaja más lento de lo esperado. J.23. El sabotaje por parte de la dirección del proyecto deriva en una planificación ineficiente e inefectiva. J.24. El sabotaje por parte del personal técnico deriva en una pérdida de trabajo o en un trabajo de poca calidad, por lo que hay que repetir algunos trabajos. K. Diseño e Implementación K.1. Un diseño demasiado sencillo no cubre las cuestiones principales, con lo que hay que volver a diseñar e implementar. K.2. Un diseño demasiado complejo exige tener en cuenta complicaciones innecesarias e improductivas en la implementación. K.3. Un mal diseño implica volver a diseñar e implementar. K.4. La utilización de metodologías desconocidas deriva en un periodo extra de formación y tener que volver atrás para corregir los errores iniciales cometidos en la metodología. K.5. El producto está implementado en un lenguaje de bajo nivel (por ejemplo, ensamblador) y la productividad es menor de la esperada. K.6. No se puede implementar la funcionalidad deseada con el lenguaje o bibliotecas utilizados: el personal de desarrollo tiene que utilizar otras bibliotecas, o crearlas él mismo para conseguir la funcionalidad deseada. K.7. Las bibliotecas de código o clases tienen poca calidad, y generan una comprobación extra, corrección de errores y la repetición de algunos trabajos. K.8. Se ha sobreestimado el ahorro en la planificación derivado del uso de herramientas para mejorar la productividad. K.9. Los componentes desarrollados por separado no se pueden integrar de forma sencilla, teniendo que volver a diseñar y repetir algunos trabajos. L. Proceso L.1. La burocracia produce un progreso más lento del esperado. L.2. La falta de un seguimiento exacto del progreso hace que se desconozca que el proyecto esté retrasado hasta que está muy avanzado. L.3. Las actividades iniciales de control de calidad son recortadas, haciendo que se tenga que repetir el trabajo. L.4. Un control de calidad inadecuado hace que los problemas de calidad que afectan a la planificación se conozcan tarde. L.5. La falta de rigor (ignorar los fundamentos y estándares del desarrollo de software) conduce a fallos de comunicación, problemas de calidad y repetición del trabajo. Un consumo de tiempo innecesario. L.6. El exceso de rigor (aferramiento burocrático a las políticas y estándares de software) lleva a gastar más tiempo en gestión del necesario. L.7. La creación de informes de estado a nivel de directiva lleva más tiempo al desarrollador de lo esperado. L.8. La falta de entusiasmo en la gestión de riesgos impide detectar los riesgos más importantes del proyecto. L.9. La gestión de riesgos del proyecto software consume más tiempo del esperado. Fuentes: Principies of Software Engineering Management (Gilb, 1998). Software Risk Management (Boehm, 1989). A Manager's Guide to Software Engineering (Pressman, 1993). Third Wave Project Management (Thomsett, 1993). Assessment and Control of Software Risks (Jones, 1994). Análisis 7 Gestión de Riesgos en Proyectos Software 78 CON-101/104, [T13] Una vez identificados los riesgos, el siguiente paso es analizar cada riesgo para determinar su impacto. Lo primero que medimos es la exposición a riesgos, definida como la probabilidad de ocurrencia del riesgo multiplicada por la magnitud de pérdida del riesgo (impacto). Por ejemplo: si existe un 25% de probabilidad de que ocurra un riesgo que retrasaría el proyecto en 4 semanas, entonces la exposición a este riesgo es de 0,25 4=1 semana. Tanto la estimación de la probabilidad de ocurrencia del riesgo como de la magnitud de pérdida por la ocurrencia del riesgo se realizan de forma subjetiva. Sin embargo, existen varias técnicas que pueden ayudar a hacer acotar la subjetividad tanto como sea posible: Solicitar la estimación de la persona más familiarizada con el sistema, o con más experiencia en proyectos parecidos. Utilizar el método Delphi: varios miembros de un grupo identifican riesgos y les asignan una probabilidad de ocurrencia y una magnitud de pérdida. Estas estimaciones son discutidas por el grupo y refinadas. Usar adjetivos (muy improbable, bastante improbable, improbable, probable, bastante probable, muy probable) y asignar un valor numérico a cada uno. PMI-134/135, [T14] Probabilidad: porcentaje de probabilidad de que ocurra un riesgo. Impacto: Efecto sobre los objetivos del proyecto en caso de ocurrir. Puede computarse en unidades de tiempo (retraso), unidades monetarias (incremento de costes), alcance (tamaño del producto en líneas de código, puntos función, etc.), Una manera más completa de estimar el impacto de un riesgo es trabajar con matrices bidimensionales que indican el impacto del riesgo en cada dimensión de los objetivos de un proyecto (coste, tiempo, alcance, calidad, ). Ver figura en [T14]. Priorización CON-104/107, [T15] Una vez identificados los riesgos, y realizada la estimación de la exposición a riesgos, el siguiente paso es priorizar los riesgos, de manera que se sepa dónde centrar el esfuerzo de la gestión de riesgos, como se muestra en la tabla de ejemplo siguiente. No es preciso realizar una ordenación estricta de la lista de riesgos, ya que tal vez prefiramos priorizar algunos riesgos que producirían alguna pérdida muy grande, independientemente del lugar que ocupen en la tabla. CON-105, [T16] Ejemplo de tabla de estimación y priorización de riesgos Riesgo Probabilidad de pérdida Magnitud de la pérdida (semanas) Exposición a riesgo (semanas) Añadir nuevas características desde marketing (sin conocer las características específicas) 35% Planificación demasiado optimista 50% Diseño inadecuado (hay que volver a diseñar) 15% Gestión de Riesgos en Proyectos Software 89 Riesgo Probabilidad de pérdida Magnitud de la pérdida (semanas) Exposición a riesgo (semanas) Las nuevas herramientas de programación no producen el ahorro prometido 30% Añadir un requisito para la actualización automática desde el servidor 5% Interfaz del subsistema de formato de gráficos inestable 25% La aprobación del proyecto tarda más de lo esperado 25% El personal contratado se retrasa en la entrega del subsistema encargado de formatear los gráficos 20% Los recursos no están disponibles en su momento 10% Los informes de estado a nivel de directiva necesitan más tiempo del previsto 10% Planificación de Respuestas PMI-143, [T17] En esta actividad se construye un plan de contingencia para cada uno de los riesgos identificados en las actividades anteriores, que se han elegido como significativos para gestionarlos. La colección de todos los planes de contingencia se suele agrupar en el llamado Plan de Respuestas a Riesgos. Este plan suele incluir: - Riesgos identificados, sus descripciones, aspectos del proyecto afectados (elementos del alcance), sus causas, efectos en los objetivos del proyecto. - Responsabilidades asignadas en cuanto a cada riesgo. - Resultados del análisis de riesgos (probabilidad, impacto, exposición), incluyendo su priorización. - Planes de contingencia - Respuestas previstas para aquellos riesgos que se han considerado prioritarios y que serán planificados. - Nivel de riesgo residual esperado después de que aplique la respuesta prevista. - Acciones específicas para implementar la estrategia de respuesta a cambios. - Presupuesto y tiempos para las respuestas. Supervisión y Control de Riesgos Identificados, analizados y priorizados los riesgos del proyecto, estamos ya en disposición de someterlos a control. El control de riesgos cubre dos actividades: resolución de riesgos y supervisión (monitorización). Supervisión PMI-144, [T18] Consiste en realizar un seguimiento de los riesgos durante la ejecución del proyecto. Un buen método es realizar seguimientos periódicos (semanales, por ejemplo) de los riesgos más significativos. 7 Gestión de Riesgos en Proyectos Software 910 Su finalidad es determinar si: - Las respuestas son implementadas según se planificó. - Las acciones de respuesta son tan efectivas como se esperaba o si nuevas respuestas deberían ser elaboradas. - Las asunciones del proyecto son todavía válidas. - La exposición a los riesgos ha cambiado y, en caso afirmativo, cual es la tendencia futura. - Un disparador (evento) de riesgo ha ocurrido. - Se han seguido las políticas y procedimientos adecuados. - Han ocurrido riesgos nuevos que no estaban previamente identificados. Resolución o control de riesgos CON-107/108, PMI-142/143, [T19] Qué hacer en este punto depende mucho del tipo de riesgo. Sin embargo, las acciones o estrategias que se pueden seguir son las siguientes: Evitar el riesgo: es decir, no realizar actividades arriesgadas cambiando el plan del proyecto. Trasladar el riesgo a un tercero (habitual en riesgos económicos) o a otra parte menos crítica del sistema. Conseguir información acerca del riesgo cuando éste no es muy conocido. Eliminar el origen del riesgo. Mitigar el riesgo. No se elimina el origen pero su cambia el plan para que su exposición sea menor. Comunicar el riesgo al resto del equipo, al cliente y a la dirección, para que estén prevenidos. Controlar/Aceptar el riesgo. Aceptar que puede ocurrir y hacer un plan de contingencias para minimizar su exposición. Recordar el riesgo para planes futuros. 7 Gestión de Riesgos en Proyectos Software 10 Documentos relacionados
LISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE Esta lista agrupa los riesgos de proyectos software en las siguientes categorías: A. Elaboración de la Planificación B. Organización y Gestión C. Más detalles TEMA 5. SEGUIMIENTO DE PROYECTOS: CONTROL DE CALIDAD, GESTIÓN DE RIESGOS Y GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
TEMA 5. SEGUIMIENTO DE PROYECTOS: CONTROL DE CALIDAD, GESTIÓN DE RIESGOS Y GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE 1. Calidad Objetivo primordial de la Ingeniería del software: Mejorar la calidad del Más detalles Ges3ón de Proyectos So9ware
Ges3ón de Proyectos So9ware Tema 2.1 Integración Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Ampliar los conocimientos básicos Más detalles Ingeniería del So9ware II
Ingeniería del So9ware II Tema 07. Ges+ón de Riesgos en Proyectos So9ware Pablo Sánchez Barreiro DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN p.sanchez@unican.es Este tema se publica bajo Licencia: Más detalles ANÁLISIS DE RIESGOS EN LA GESTIÓN DE PROYECTOS. Los riesgos son eventos o condiciones inciertas que, si se producen, tienen un
ANÁLISIS DE RIESGOS EN LA GESTIÓN DE PROYECTOS Los riesgos son eventos o condiciones inciertas que, si se producen, tienen un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, Más detalles Qué problemas amenazan el desarrollo?
3-Oct-07 Riesgos Riesgos Qué problemas amenazan el desarrollo? Un riesgo es una variable del proyecto que pone en peligro o impide el éxito del proyecto. 2 Riesgos Si le gusta correr riesgos, desarrolle Más detalles Seamos parte de la solución!
GRUPO VISIÓN PROSPECTIVA MÉXICO 2030 Gestión de Riesgos en Proyectos Mauricio Jessurun Solomou mjess@unisolmexico.com Luis Miguel Arroyo lmarroyoi@emsi.com.mx Julio, 2015 Gestión de Riesgos en Proyectos Más detalles Gestión práctica de riesgos para proyectos exitosos
Gestión práctica de riesgos para proyectos exitosos Mg. Franco Rigante, CISA, CRISC, PMP Partner, Grant Thornton Argentina DEFINICIÓN DE RIESGO Riesgo proviene del italiano risico o rischio a su vez, originado Más detalles Ingeniería del So:ware II
Ingeniería del So:ware II Tema 04 (1). Integración de Proyectos So:ware Carlos Blanco Bueno DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN carlos.blanco@unican.es Este tema se publica bajo Licencia: CreaRve Más detalles Entregable V. Juan Pablo Mejía Wagner AMENAZAS Y VULNERABILIDADES DE LA IMPLEMENTACIÓN DE UN SOFTWARE
2009 Entregable V Juan Pablo Mejía Wagner AMENAZAS Y VULNERABILIDADES DE LA IMPLEMENTACIÓN DE UN SOFTWARE Tabla de contenido 1. Aseguramiento de Calidad... 3 2. Administración de riesgos[2]... 4 3. Problemas Más detalles Administración de proyectos. Organizar, planificar y programar los proyectos de software
Administración de proyectos Organizar, planificar y programar los proyectos de software Administración de proyectos Trata de las actividades que hay que realizar para asegurar que el software se entregará Más detalles Más allá de las metodologías de desarrollo (Fecha de publicación: 13-10-2004) www.coelloconsultores.com
Más allá de las metodologías de desarrollo (Fecha de publicación: 13-10-2004) www.coelloconsultores.com Probablemente usted ha estado desarrollando proyectos de software por un periodo largo de tiempo, Más detalles Ingeniería del Software. La última lección. Resumen del curso. Buenas prácticas. Conclusión
La última lección Resumen del curso Buenas prácticas Malas prácticas Conclusión Objetivos Mostrar las técnicas básicas para planificar, gestionar y desarrollar productos de software complejos (Proyectos Más detalles Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo
Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para Más detalles Análisis de estrategias para la gestión de proyectos informáticos. TFC Área de Gestión de Proyectos
Análisis de estrategias para la gestión de proyectos informáticos TFC Área de Gestión de Proyectos Consultor: Ana Cristina Domingo Trocho Autor: David Prado Romanillos Fecha de entrega: 10/01/2012 Índice Más detalles SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras
Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras Más detalles Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR
Gerenciamiento de Proyectos Estándar PMI Cambio Organizacional UDELAR Agenda Concepto de Proyecto Qué es la dirección de proyectos? PMI y Guía del PMBOK Dirección de Proyectos Áreas de Conocimiento 2 Definición Más detalles Mantenimiento del Software
Mantenimiento del Software S1 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad Más detalles Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS
Escuela Politécnica Superior Proyectos de Desarrollo Software Capítulo 5 Dr. Daniel Tapias Curso 2014/ 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2: Más detalles Gestión del Riesgo. Un peso invertido en prevención de riesgos vale por muchos pesos gastados en recuperación ante problemas
Gestión del Riesgo Un peso invertido en prevención de riesgos vale por muchos pesos gastados en recuperación ante problemas 1 Bibliografía A guide to de Project Management Body of Knowledge (PMBOK), Project Más detalles DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA
DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión Más detalles Mantenimiento del Software
Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad Más detalles Impala Risk. Simulación de Riesgo en Proyectos. Servicios. Capacitación. www.impalarisk.com
Simulación de Riesgo en Proyectos Servicios Capacitación www.impalarisk.com Software Simulador de Riesgo en Proyectos El peor riesgo es desconocer el riesgo Los actuales Gerentes de Proyectos se enfrentan Más detalles Gestión de riesgos. 1. Definición y clasificación 2. Actividades. Estimación de riesgos. Identificación Análisis Evaluación. Control de riesgos
Gestión de riesgos 1. Definición y clasificación 2. Actividades Estimación de riesgos Identificación Análisis Evaluación Control de riesgos Planificación Supervisión 1 Definición The SEI Definition The Más detalles Rumboitil www.rumboitil.com e-mail: info@rumboitil.com
INDICE... Error! Marcador no definido. Unidad 3 Estrategia del Servicio... 2 3.1 Creación de Valor a través del Servicio.... 2 3.2 Gestión de la demanda.... 4 3.3 Gestión financiera.... 7 3.4 Procesos Más detalles TEMA 6.- LA PUESTA EN MARCHA DE PROYECTOS. LOS ASPECTOS A TENER EN CUENTA
TEMA 6.- LA PUESTA EN MARCHA DE PROYECTOS. LOS ASPECTOS A TENER EN CUENTA El Programa para el Fomento de la Intraemprendeduría en Ciclos Formativos de Formación Profesional es un proyecto financiado por Más detalles Modelos de desarrollo de software. septiembre de 2007 1
Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville, Más detalles GESTIÓN DE RIESGO. Subdirección de Desarrollo Organizacional Agosto 09 de 2013 Bogotá D.C.
GESTIÓN DE RIESGO Subdirección de Desarrollo Organizacional Agosto 09 de 2013 Bogotá D.C. MARCO NORMATIVO Con el propósito de desarrollar un sistema eficiente para la gestión de riesgos, el Ministerio Más detalles Clase 1: Introducción a la Dirección y Gestión de Proyectos Clase 2: PMBOK (Project Management Body of Knowledge) Clase 3: Gestión de la Integración
Project Management Objetivos - Adquirir los conocimientos y herramientas fundamentales aplicables al gerenciamiento de proyectos de acuerdo a la metodología de Project Management, contenidas en el Project Más detalles 1. PROCESOS DEL PROJECT MANAGEMENT
INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT Más detalles 11. GESTIÓN DE LOS RIESGOS DEL PROYECTO PROYECTO TÉCNICO
11. GESTIÓN DE LOS RIESGOS DEL PROYECTO PROYECTO TÉCNICO Documento redactado por Documento revisado por Documento aprobado por Joaquín De Abreu David Naranjo 30-08-12 Joaquín de Abreu 05-09-12 Jordi Labandeira Más detalles Tips para un Líder Ágil
Tips para un Líder Ágil Desde Lean hacia Agile Project Management Pablo Lledó PMP Economista Pablo Lledó, PMP 3 MBAs en Europa / Instructor 4 Empresas en marcha / Empresario 5 libros publicados / Autor Más detalles PRACTICA 1 Elaboración de un plan de proyecto utilizando Microsoft Project
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA PRACTICA 1 Elaboración de un plan de proyecto utilizando Microsoft Project AUTORES: Alfonso Franco Garcia Alicia Martín-Benito Escalona Más detalles Modelos de Proceso Tradicionales
Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo Más detalles FORMACIÓN DE HABILIDADES EN ADMINISTRACIÓN DE PROYECTOS
Expertos en Administración de Proyectos FORMACIÓN DE HABILIDADES EN ADMINISTRACIÓN DE PROYECTOS GRUPO CERRADO Agosto 14, 2013 La información contenida en este documento es confidencial, y no podrá ser Más detalles CICLO DE VIDA DEL SOFTWARE
CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en Más detalles Administración de Proyectos Informáticos. Visión general de la. María N. Moreno García Departamento de Informática y Automática
TEMA 1 Visión general de la administración de proyectos María N. Moreno García Departamento de Informática y Automática Universidad de Salamanca Contenidos 1. Introducción 2. Áreas de gestión de proyectos Más detalles PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.
PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón, Más detalles Implantación de Sistemas
Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de Más detalles Situación Actual. Al presupuesto asignado. Supervisión y Control a los servicios proporcionados por proveedores. Retraso en la atención oportuna
Situación Actual Las actividades emanadas de los procesos que se llevan a cabo en la Subdirección, requieren fortalecer los controles y seguimientos, por ejemplo: Al presupuesto asignado. Supervisión y Más detalles Administración de servicios: cómo brindar un mejor servicio con una CMDB
Administración de servicios: cómo brindar un mejor servicio con una CMDB CMDB y la administración de incidentes y problemas Autora:, ConnectSphere Limited, Reino Unido En la actualidad, las organizaciones Más detalles UNIVERSIDAD RICARDO PALMA
UNIVERSIDAD RICARDO PALMA SÍLABO I.- DATOS ADMINISTRATIVOS NOMBRE DEL CURSO : Administración de Proyectos Informáticos CÓDIGO DEL CURSO : II 0902 SEMESTRE : 2003-2 CREDITOS : Tres (3) HORAS SEMANALES : Más detalles 5.2.8 Planificar la Respuesta a los Riesgos 5.2.8 Planificar la Respuesta a los Riesgos La gestión de los riesgos pretende aumentar la probabilidad y el impacto de los eventos positivos y disminuir estos mismos factores para Más detalles Escuela Politécnica Superior. El Riesgo. Capítulo 9. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014 / 15 PROYECTOS
Escuela Politécnica Superior El Riesgo Capítulo 9 Dr. Daniel Tapias Curso 2014 / 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2: Qué es un proyecto? Capítulo Más detalles Resumen. Abstract. Palabras Claves: activos fijos, fases, procesos.
Administración del Ciclo de Vida de un Proyecto de un Sistema de Información para El Manejo de Activos Fijos del Grupo IIASA utilizando la Metodología PMI Norian Norelis Pilco Bustamante (1), Angel Wilmer Más detalles 6.5 Desarrollo del Cronograma
6.5 Desarrollo del Cronograma Procesos de un Área de Conocimiento Iniciación Planificación Ejecución Seguimiento y Control Cierre 4. Gestión de la Integración de Proyectos 4.1 Desarrollar el Acta de Constitución Más detalles MONITOREAR Y CONTROLAR LOS RIESGOS MONITOREAR Y CONTROLAR LOS RIESGOS MONITOREAR Y CONTROLAR LOS RIESGOS MONITOREAR Y CONTROLAR LOS RIESGOS
SESIÓN 8 MONITOREAR Y CONTROLAR LOS RIESGOS PROPÓSITO Y OBJETIVOS DEL PROCESO MONITOREAR Y CONTROLAR LOS RIESGOS FACTORES CRÍTICOS DE ÉXITO DEL PROCESO MONITOREAR Y CONTROLAR LOS RIESGOS HERRAMIENTAS Y Más detalles La Implementación de SAP R/3
SESIÓN 3 La implementación de SAP R/3 Etapas del Proyecto y Tareas a Realizar Entorno de la Implementación SAP Taller de Introducción a ERP SESIÓN 3/1 La Implementación de SAP R/3 El significado usual Más detalles Plan de estudios ISTQB: Nivel Fundamentos
Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE Más detalles 2.3 Animador Digital Especialista en 2D/3D
2.3 Animador Digital Especialista en 2D/3D 2.3.1 Descripción del puesto de trabajo Un animador digital/especialista en 2D-3D crea imágenes en movimiento en un medio digital utilizando técnicas de 2D ó Más detalles RISK MANAGEMENT. Su organización puede planificar pero no predecir su futuro
RISK MANAGEMENT Su organización puede planificar pero no predecir su futuro Cuando su organización conceptualiza que la operatoria del negocio se encuentra expuesta a una serie de riesgos que deben ser Más detalles 1. Marco Teórico. 1. Marco Teórico
1.1 Gestión del Servicio Para empezar, antes de entender qué es la gestión del servicio, se tiene que entender qué son para que de esa forma entendamos cómo la gestión de los mismos puede ayudar a los Más detalles Introducción a la Gerencia de Proyectos. Resumen. Introducción.
Introducción a la Gerencia de Proyectos Edwin Monzón C. Ing. de Planeamiento y Control de Proyectos, Compañía Minera San Martín Resumen A nivel mundial la utilización de estándares en la dirección de proyectos Más detalles Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software
Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile Más detalles Conceptos de Metodología y Modelo. Relaciones
Conceptos de Metodología y Modelo. Relaciones CRITERIOS orientan Se compone PRODUCTOS ASPECTOS DEL SISTEMA DE INFORMACION describe MODELO soportan HERRAMIENTAS Se compone METODOLOGIA De Complejidad del Más detalles Mestrado em Tecnologia da Informação. Gestão de Projetos de TI
Mestrado em Tecnologia da Informação Gestão de Projetos de TI Proyecto Proyecto se refiere a todas las acciones que deben realizarse para cumplir con una necesidad definida dentro de los plazos. Así, ya Más detalles IT Project Management Desarrollo de Software
IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación Más detalles SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS
Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil Más detalles GUÍA AVANZADA DE GESTIÓN DE RIESGOS LNCS
GUÍA AVANZADA DE GESTIÓN DE RIESGOS Diciembre 2008 AVISO LEGAL CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon Las distintas normas ISO mencionadas Más detalles Curso de preparación al examen de certificación en Dirección de Proyectos PMP, otorgada por el PMI
Curso de preparación al examen de certificación en Dirección de Proyectos PMP, otorgada por el PMI Presentación. El curso esta convocado por Escuela Técnica Superior de Arquitectura de Madrid (ETSAM) y Más detalles Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar
1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución Más detalles RIESGOS INFORMATICOS
1 INTRODUCCION RIESGOS INFORMATICOS LA GESTION DE LOS RIESGOS El principal objetivo de la administración de riesgos, como primera ley de la naturaleza, es garantizar la supervivencia de la organización, Más detalles El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los
ALEXANDRA PSICA, CMC DIRECTORA GENERAL INTERIS CONSULTING INC. El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los objetivos de la organización, al nivel de riesgo inherente Más detalles Máster en Project Management (PMP ) Objetivos del Programa
Máster en Project Management (PMP ) Objetivos del Programa Asignatura: Estructura de Conocimiento de la Gestión de Proyectos Lección 1: Introducción El objetivo de la lección es empezar a conocer la filosofía Más detalles Ingeniería del So=ware II
Ingeniería del So=ware II Tema 03. Fundamentos de Ges1ón de Proyectos Juan Hernández Marqués DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN juan.hernandez@unican.es Este tema se publica bajo Licencia: Más detalles METODOLOGÍA DE GESTION DE PROYECTOS
METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE Más detalles Escuela Técnica Superior de. Informática. Máster en Ingeniería Informática. aplicada a la Industria, la Ingeniería del. Software y a los Sistemas y
Escuela Técnica Superior de Informática Máster en Ingeniería Informática aplicada a la Industria, la Ingeniería del Software y a los Sistemas y Tecnologías de la Información GUÍA DOCENTE DE LA ASIGNATURA: Más detalles Cómo puedo administrar mejor los activos de software y mitigar el riesgo de las auditorías de cumplimiento?
RESUMEN DE LA SOLUCIÓN CA SERVICE MANAGEMENT: ADMINISTRACIÓN DE ACTIVOS DE SOFTWARE Cómo puedo administrar mejor los activos de software y mitigar el riesgo de las auditorías de cumplimiento? CA Service Más detalles Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente
Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente. Más detalles INFORMACIÓN GESTIONADA
INFORMACIÓN GESTIONADA La gestión de proyectos que usted puede desarrollar a partir de Soluciones Primavera para los sectores de ingeniería y construcción ORACLE ES LA COMPAÑÍA DE INFORMACIÓN Mejore los Más detalles 2. Las funciones de control interno y auditoría informáticos.
TEMA 9 AUDITORIA DE PROYECTO 1. Auditoría: Procedimiento reglado para analizar cualitativamente y cuantitativamente la eficiencia de un proceso, una tarea o un sistema. Las auditorias pueden ser internas Más detalles Curso de preparación al examen de certificación en Dirección de Proyectos PMP, otorgada por el PMI
Curso de preparación al examen de certificación en Dirección de Proyectos PMP, otorgada por el PMI Presentación. El curso esta convocado por Escuela Técnica Superior de Arquitectura de Madrid (ETSAM) y Más detalles Unidad III. Planificación del proyecto de software
Planificación del proyecto de software Unidad III 3.1. Aplicación de herramientas para estimación de tiempos y costos de desarrollo de software: GANTT, PERT/CPM, uso de software para la estimación de tiempos Más detalles Análisis de la gestión de configuración de software aplicada al modelo de espiral
3.010 CONCEPTO DE CICLO DE VIDA Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los Más detalles GUÍA AVANZADA DE GESTIÓN DE PROYECTOS
GUÍA AVANZADA DE GESTIÓN DE PROYECTOS Laboratorio Nacional de Calidad del Software Mayo 2009 NOTA DE EDICIÓN Esta guía ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de INTECO. Más detalles SEGURIDAD INFORMATICA GENERALIDADES DE LA SEGURIDAD INFORMATICA
SEGURIDAD INFORMATICA GENERALIDADES DE LA SEGURIDAD INFORMATICA Seguridad de la información? Vs Seguridad? ISO/IEC 17799 ISO/IEC 2700 -> SGSI Organización de Estándares Internacionales/Comisión Electrotécnica Más detalles I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L
I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del Más detalles Tema 2. Ingeniería del Software I feliu.trias@urjc.es
Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición Más detalles Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.
El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en Más detalles Informe técnico de negocios. Las diez principales razones para automatizar sus procesos de TI
Informe técnico de negocios Las diez principales razones para automatizar sus procesos de TI Índice 4 Herramientas y tendencias de administración del centro de datos 4 El desafío actual 4 Lo que viene Más detalles Ventajas de la migración a servicios de middleware modernos
Ventajas de la migración a servicios de middleware modernos Marcia Kaufman Directora de operaciones y analista jefe Patrocinado por Red Hat Introducción Las aplicaciones comerciales ya no se limitan a Más detalles ANÁLISIS MODAL DE FALLOS EFECTOS (A. M. F. E.)
ANÁLISIS MODAL DE FALLOS EFECTOS (A. M. F. E.) Y 1. INTRODUCCIÓN Este documento describe paso a paso el proceso de identificación, evaluación y prevención de deficiencias en los productos o servicios. Más detalles 3 3 X (1) Observaciones: (2) Observaciones: Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig.
Ciclo Académico: 2009 Año de la Carrera: Horas de Clases Semanales Régimen de Cursado 1 Teoría Práctica Otros (1) Anual 1er.Cuatr. 2do.Cuatr. Otros (2) 3 3 X (1) Observaciones: (2) Observaciones: Docente/s Más detalles MANAGEMENT CONSULTORES
MANAGEMENT CONSULTORES CURSO DE ADMINISTRACION Y DIRECCION DE PROYECTOS Cnel. Ramón L. Falcón 1435 C1406GNC 35 Buenos Aires, Argentina Tel.: 054-15-5468-3369 Fax: 054-11-4433-4202 Mail: mgm_consultas@mgmconsultores.com.ar Más detalles RECOMENDACIONES PARA EL DESARROLLO DE UNA POLÍTICA PARA LA GESTIÓN DE LA RELACIÓN CON EL CLIENTE
RECOMENDACIONES PARA EL DESARROLLO DE UNA POLÍTICA PARA LA GESTIÓN DE LA RELACIÓN CON EL CLIENTE Autor del documento: Centro de Apoyo Tecnológico a Emprendedores Datos de contacto: E-Mail: bilib@bilib.es Más detalles El Project Manager y la Gestión del Contrato con el Cliente
El Project Manager y la Gestión del Contrato con el Cliente José Rafael Alcalá Vocal PMI Madrid Responsable Servicios a Socios (joserafael.alcala@pmi-mad.org) Francisco Javier Rodríguez Vicepresidente Más detalles SISTEMAS DE INFORMACIÓN II TEORÍA
CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza Más detalles Fase de Planeación. Unidad
Fase de Planeación. Unidad 2 Una etapa primordial en la gestión de un proyecto es la Planeación. Durante ésta se realizan actividades para estimar costos y recursos asegurando que el proyecto satisfaga Más detalles CAPÍTULO 1. A fin de cumplir con los requisitos previos a la obtención del título de. Ingeniero en Sistemas Computacionales, se elabora este proyecto.
CAPÍTULO 1 1. INTRODUCCION 1.1. Antecedentes A fin de cumplir con los requisitos previos a la obtención del título de Ingeniero en Sistemas Computacionales, se elabora este proyecto. Este capitulo proporciona Más detalles 1. Seguridad, Respaldo, Continuidad Informática y Alta Disponibilidad ante Desastres
Seguridad, Respaldo, Continuidad y Alta Disponibilidad en el ámbito de la Administración Electrónica: Diseño del Centro de Respaldo y Hospedaje de la Junta de Andalucía José F. Quesada Gabinete de Sistemas Más detalles Resumen General del Manual de Organización y Funciones
Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de Más detalles Sistema de Gestión de la Seguridad de la Información
Sistema de Gestión de la Seguridad de la Información 1 Contenidos 1. Qué es un SGSI? 2. Para qué sirve un SGSI? 3. Qué incluye un SGSI? 4. Cómo se implementa un SGSI? 5. Qué tareas tiene la Gerencia en Más detalles Guía para la Administración del Riesgo v3 Departamento Administrativo de la Función Pública
Guía para la Administración del Riesgo v3 Departamento Administrativo de la Función Pública Dirección de Control Interno y Racionalización de Trámites Bogotá, D.C., Octubre de 2014 Índice Cómo interpretar Más detalles GUÍA PRÁCTICA DE GESTIÓN DE PROYECTOS
GUÍA PRÁCTICA DE GESTIÓN DE PROYECTOS Laboratorio Nacional de Calidad del Software Mayo 2009 NOTA DE EDICIÓN Esta guía ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de INTECO. Más detalles TEST (0 30 puntos por pregunta correcta, -0 075 puntos por error) [Marcar sólo una opción]
EXAMEN PARCIAL 1 TEST (0 30 puntos por pregunta correcta, -0 075 puntos por error) [Marcar sólo una opción] Indicar la opción errónea. Los proyectos se diferencian de los trabajos en que: a) Tienen un Más detalles Cristian Blanco www.cristianblanco.es
3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo Más detalles Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles
Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles Este apartado describirá en qué consiste la gestión de riesgos, cómo se deben escoger los controles, se darán recomendaciones Más detalles Catálogo de Servicios
Catálogo de Servicios Fecha: 14 de mayo de 2013 Índice 1 Presentación... 3 2 Servicios de Consultoría SQL Server... 4 2.1 Monitorización servidores SQL Server... 4 2.2 DBA Remoto... 5 2.3 Consolidación Más detalles 2016 © DocPlayer.es Política de privacidad | Condiciones del servicio | Feedback

References: Resolución 
 Resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución