Gestión de Proyectos de TI
DEFINICION
Es un esfuerzo temporal que se lleva a cabo para crear un producto o servicio
Gestió...
Requirements Management, enfoque sistemático que involucra:
                   Ø     Obtener, organizar y documentar la fu...
selección de los elementos estructurales, y sus interfaces, por los cuales el sistema está
compuesto
comportamiento, espec...
Upcoming SlideShare
Loading in...5
×

Gestion De Proyectos De Ti

2,903

Published on

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,903
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
85
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gestion De Proyectos De Ti

  1. 1. Gestión de Proyectos de TI DEFINICION Es un esfuerzo temporal que se lleva a cabo para crear un producto o servicio Gestión son todas las actividades y tareas ejecutadas por una o mas personas con el propósito de planificar y controlar las actividades de otros para alcanzar un objetivo o completar una actividad que no puede ser realizada por otros actuando independientemente ¿Qué es un proyecto? 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 Porque el fracaso de los proyectos ti Gestion ineficiente de los proyectos ti, representa la Fuentes mas comun de fracasos en los proyectos de ti (43%). El sobredimensionamiento del alcance, otras de las causas del fracaso de los proyectos ti (21%) Los altos directivos no comprenden adecuadamente los temas que conciernen a la ti (26%) 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 ¿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 Seis Mejores Prácticas 1. ADMINISTRAR REQUERIMIENTOS 2. Desarrollar Iterativamente 3. Verificar la Calidad 4. Modelar Visualmente 5. Utilizar Arquitecturas Basadas en Componentes 6. Controlar los Cambios al Software 1. ADMINISTRAR REQUERIMIENTOS
  2. 2. 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 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 2. Desarrollar 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 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 3. Verificar la Calidad La actividad fundamental de esta práctica es el testing Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance 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. 4. Modelar Visualmente Modelar Software Visualmente: Ø Diagramas de Casos de Uso Ø Diagramas de Clases Ø Diagramas de Estados Ø Diagramas de Componentes Ø Diagramas de Implementación 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 5. Utilizar Arquitecturas Basadas en Componentes La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software
  3. 3. 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 6. Controlar los Cambios al Software 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

×