Conferencia Gestión de Proyectos de TI

Gestión de Proyectos de TI Exp. Hanz Cocchi Guerrero IT Project Manager

Agenda

¿Que es un Proyecto?

Problemas con el Software.

¿Que son los riesgos?

¿Qué deberíamos hacer?

Seis mejores prácticas.

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? Costos Tiempos Calidad

Alarmante Problema

Solución

Enfoque integral del ciclo de vida

Técnicas formales y herramientas

Ingeniería de software

Fuente: 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

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

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

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ó? Lo que el cliente realmente necesitaba

¿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

Aná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 riesgo

Considerar (riesgo, probabilidad de riesgo, impacto)

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

Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Administrar requerimientos

Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente

Administrar 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

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ño Los Casos de Uso direccionan el trabajo desde el análisis hasta el test Modelo de Casos de Uso Modelo de Implementación Modelo de Test verifica Realización influenciados por

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

Desarrollar Software Iterativamente

Cada iteración resulta en un release ejecutable

Planeamiento Inicial Planeamiento Requerimientos Análisis y Diseño Implementación Prueba Distribución Evaluación Ambiente de Administración

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

Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente

Verificar 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

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

Seis “Mejores Prácticas” Controlar Cambios Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente Verificar Calidad Administrar requerimientos

Diseñar el proceso Logical Design Conceptual Design Scenarios Physical Design Components, User Interface, and Physical Database Objects and Services, User Interface, and Logical Database

Modelar Software Visualmente

Diagramas de Casos de Uso

Diagramas de Clases

Diagramas de Estados

Diagramas de Componentes

Diagramas de Implementación

El Modelamiento Visual eleva el nivel de abstracción Código Clases Subsistemas

Modelar 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

Utilizar 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

Utilizar Arquitecturas Basadas en Componentes Vista Lógica Vista de Implementación Programadores Administración del Software Vista del Proceso Vista de Desarrollo Topología Distribución, Instalación Comunicación Ingeniería Conceptual Physical Vista de Caso de Uso Usuario Funcionalidad Performance Escalabilidad Rendimiento Integradores

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

Arquitectura basada en componentes System- software Middleware Negocio Aplicación

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

Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente

Controlar 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”

Workspace de Administración Integración Desarrollo en paralelo Administración del Build CM es mucho más que check-in y check-out ALERT REPORT

Controlar 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

Seis “Mejores Prácticas” Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente

Preguntas!????

Referencias