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. 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. 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
