conferencia gestión de proyectos de ti
DESCRIPTION
Diapositiva de la exposición que di en la UNAC Lima PerúTRANSCRIPT
Gestión de Proyectos de TIGestión de Proyectos de TIExp. Hanz Cocchi GuerreroIT Project ManagerExp. Hanz Cocchi GuerreroIT Project Manager
2Gestión de Proyectos de TI
AgendaAgenda
¿Que es un Proyecto?Problemas con el Software.¿Que son los riesgos?¿Qué deberíamos hacer?Seis mejores prácticas.
¿Que es un Proyecto?Problemas con el Software.¿Que son los riesgos?¿Qué deberíamos hacer?Seis mejores prácticas.
3Gestión de Proyectos de TI
CostosTiempo
sCalidad
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
Se controla :
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
Se controla :
¿Qué es un proyecto?¿Qué es un proyecto?
4Gestión de Proyectos de TI
Alarmante ProblemaAlarmante Problema
Solución Enfoque integral del ciclo de vida Técnicas formales y herramientas Ingeniería de software
Solución Enfoque integral del ciclo de vida Técnicas formales y herramientas Ingeniería de software
71% de todos los proyectos fallan, ya sea que se han excedido el presupuesto o empiezan a funcionar después del plazo original. Cada año, 75 millones de dólares se pierden por fallas de los proyectos en los
Estados Unidos
Fuente: The Standish Group 2001Fuente: The Standish Group 2001 Demanda insatisfecha
Plazos y costos excedidos Insuficiente productividad Calidad inadecuada
Causas Naturaleza del software Inadecuado enfoque gerencial Carencia de tecnología
Demanda insatisfecha Plazos y costos excedidos Insuficiente productividad Calidad inadecuada
Causas Naturaleza del software Inadecuado enfoque gerencial Carencia de tecnología
5Gestión de Proyectos de TI
Porque fracasa el proyecto?Porque fracasa el proyecto?
Como lo explicó el
cliente
Como lo entendió el
líder del proyecto
Como lo diseñó el analista
Como lo escribió el
programador
Como lo recibieron los probadores
beta
Como lo describió el Consultor de
Negocios
6Gestión de Proyectos de TI
Porque fracasa el proyecto?Porque fracasa el proyecto?
Como se documentó
Las operaciones instaladas
Lo que se le cobró al Cliente
El soporte que se le
dio
Como se comercializó
Lo que el cliente realmente necesitaba
7Gestión de Proyectos de TI
Lo que el cliente realmente necesitaba
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
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
¿Por qué fracasó?¿Por qué fracasó?
8Gestión de Proyectos de TI
¿Qué es un riesgo del proyecto?¿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
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
9Gestión de Proyectos de TI
Análisis de RiesgoAnálisis de Riesgo
Estimación del riesgo Establecer una escala que refleje la probabilidad
observada de riesgo. Bastante improbable Improbable Moderado Probable Bastante probable
Impacto (pesos) Estimación del impacto de riesgo en el proyecto
Cálculo de riesgoConsiderar (riesgo, probabilidad de riesgo, impacto)
Estimación del riesgo Establecer una escala que refleje la probabilidad
observada de riesgo. Bastante improbable Improbable Moderado Probable Bastante probable
Impacto (pesos) Estimación del impacto de riesgo en el proyecto
Cálculo de riesgoConsiderar (riesgo, probabilidad de riesgo, impacto)
10Gestión de Proyectos de TI
¿Qué se debería hacer?¿Qué se debería hacer?
Defina el alcance del proyecto.Utilice métricas en su proyecto.
¿Cuánto pesa el software?Gestione los riesgos con anticipación.Use una metodología probada.Modele las amenazas de su proyecto.Use herramientas de Verificación de
código.Haga pruebas exhaustivas.
Defina el alcance del proyecto.Utilice métricas en su proyecto.
¿Cuánto pesa el software?Gestione los riesgos con anticipación.Use una metodología probada.Modele las amenazas de su proyecto.Use herramientas de Verificación de
código.Haga pruebas exhaustivas.
11Gestión de Proyectos de TI
12Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
13Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
14Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
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
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
15Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
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
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
Modelo de DiseñoModelo de Implementación Modelo de Test
verificaRealización influenciados porLos Casos de Uso
direccionan el trabajo desde el análisis hasta el
test
Modelo de Casos de Uso
16Gestión de Proyectos de TI
Administrar los requerimientosAdministrar los requerimientos
Las comunicaciones están basadas en requerimientos bien definidos
Los requerimientos pueden ser priorizados, filtrados y monitoreados
Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto
Las inconsistencias se detectan fácilmente Con herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones
Las comunicaciones están basadas en requerimientos bien definidos
Los requerimientos pueden ser priorizados, filtrados y monitoreados
Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto
Las inconsistencias se detectan fácilmente Con herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones
17Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
18Gestión de Proyectos de TI
PlaneamientoPlaneamientoInicialInicial
PlaneamientoPlaneamiento
RequerimientosRequerimientosAnálisis y DiseñoAnálisis y Diseño
ImplementaciónImplementación
PruebaPrueba
DistribuciónDistribución
EvaluaciónEvaluación
Ambiente deAmbiente deAdministraciónAdministración
Desarrollar Software IterativamenteDesarrollar Software Iterativamente
Cada iteración resulta en un release ejecutable
Cada iteración resulta en un release ejecutable
19Gestión de Proyectos de TI
Desarrollar Software IterativamenteDesarrollar Software 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
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
20Gestión de Proyectos de TI
Desarrollar Software IterativamenteDesarrollar Software Iterativamente
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
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
21Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
22Gestión de Proyectos de TI
Verificar la Calidad del SoftwareVerificar la Calidad del Software
La actividad fundamental de esta práctica es el testing
Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
La actividad fundamental de esta práctica es el testing
Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
Desarrollo Implementación
Costo
Encontrar y reparar un problema de software después de la implementación puede resultar de 100 a 1000 veces más costoso
23Gestión de Proyectos de TI
Verificar la Calidad del SoftwareVerificar la Calidad del Software
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.
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.
24Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
Verificar Calidad
25Gestión de Proyectos de TI
Diseñar el procesoDiseñar el proceso
Logical DesignLogical DesignConceptual DesignConceptual Design
ScenariosPhysical DesignPhysical Design
Components,User Interface, and Physical Database
Objects and Services,User Interface, and Logical Database
26Gestión de Proyectos de TI
Modelar Software VisualmenteModelar Software Visualmente
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación
Código
Clases
Subsistemas
El Modelamiento Visual
eleva el nivel de abstracción
27Gestión de Proyectos de TI
Modelar Software VisualmenteModelar Software Visualmente
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
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
28Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
29Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes
La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software 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
La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software 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
30Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes
Vista Lógica
Usuario Funcionalidad
Vista de Implementación
Programadores Administración del Software
Vista del Proceso
PerformanceEscalabilidadRendimiento
Integradores
Vista de Desarrollo
Topología Distribución, Instalación
Comunicación
Ingeniería
Conceptual Physical
Vista de Caso de Uso
31Gestión de Proyectos de TI
System-System-softwaresoftware
MiddlewareMiddleware
NegocioNegocio
AplicaciónAplicación
Arquitectura basada en
componentes
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes Un componente de software puede definirse como
una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida
Realización física de una abstracción en el diseño
Un componente de software puede definirse como una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida
Realización física de una abstracción en el diseño
32Gestión de Proyectos de TI
Utilizar Arquitecturas Basadas en ComponentesUtilizar Arquitecturas Basadas en Componentes Definir arquitecturas muy modulares e identificar,
aislar, diseñar, desarrollar y probar componentes bien formados
Desarrollar componentes para ser reutilizados. Formar la base de rehúso de la organización
Industria de infraestructura de componentes COM+ - Microsoft Component Object Model CORBA - Common Object Request Broker
Architecture - OMG JavaBeans – SUN Assemblys .NET Servicios Web
Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar y probar componentes bien formados
Desarrollar componentes para ser reutilizados. Formar la base de rehúso de la organización
Industria de infraestructura de componentes COM+ - Microsoft Component Object Model CORBA - Common Object Request Broker
Architecture - OMG JavaBeans – SUN Assemblys .NET Servicios Web
33Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelarVisualmente
34Gestión de Proyectos de TI
Controlar los Cambios al SoftwareControlar los Cambios al Software Controlar, registrar y monitorear los cambios para posibilitar
el desarrollo iterativo Establecer “workspaces” seguros para cada desarrollador Automatizar la integración y la administración de “builds”
Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo
Establecer “workspaces” seguros para cada desarrollador Automatizar la integración y la administración de “builds”
ALERTREPORT
Workspacede Administración
Integración
Desarrollo en paralelo
Administración del Build
CM es mucho más que check-in y check-out
35Gestión de Proyectos de TI
Controlar los Cambios al Software: BeneficiosControlar los Cambios al Software: Beneficios
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
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
36Gestión de Proyectos de TI
Seis “Mejores Prácticas”Seis “Mejores Prácticas”
Controlar Cambios
Administrar Requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelizarVisualmente
37Gestión de Proyectos de TI
Preguntas!????Preguntas!????
38Gestión de Proyectos de TI
ReferenciasReferencias
•El ciclo de vida de desarrollo de Seguridad http://www.microsoft.com/spanish/msdn/articulos/archivo/030505/voices/sdl.mspx
•Ingeniería de Softwarehttp://www.ingenierosoftware.com/
•Contrato para desarrollo de Softwarehttp://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5003/desarrol.htm