conferencia gestión de proyectos de ti

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.


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?


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


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


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


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ó?


¿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


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)


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


Seis “Mejores Prácticas”Seis “Mejores Prácticas”

Controlar Cambios

Administrar requerimientos

ArquitecturasBasadas en

Componentes

DesarrollarIterativamente

Verificar Calidad

ModelarVisualmente



Controlar Cambios



Componentes


Verificar Calidad

ModelarVisualmente


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



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



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



Controlar Cambios



Componentes


Verificar Calidad

ModelarVisualmente


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



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



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



Controlar Cambios

Administrar Requerimientos


Componentes


Verificar Calidad

ModelarVisualmente


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


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.



Controlar Cambios



Componentes


Verificar Calidad

ModelarVisualmente

Verificar Calidad


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


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


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



Controlar Cambios



Componentes


Verificar Calidad

ModelarVisualmente


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


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


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


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



Controlar Cambios



Componentes


Verificar Calidad

ModelarVisualmente


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


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



Controlar Cambios



Componentes


Verificar Calidad

ModelizarVisualmente


Preguntas!????Preguntas!????


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