Clase proyecto sidet

Curso de Gestión de Proyectos

Cristian Sanchez Flores

[email protected]

SIDET 2010

Proyectos

mailto:[email protected]

mailto:[email protected]


Un Proyecto es

• Un emprendimiento temporario para lograr un resultado único.

• Temporario: Su extensión se prevé limitada en el tiempo.

• Producto único: no se ha realizado antes nada igual,


Un proyecto es una acción en la que recursos humanos, financieros y materiales se organizan de una nueva forma para acometer un trabajo único. En este trabajo, dadas unas especificaciones y dentro de unos límites de costes y tiempo, se intenta conseguir un cambio beneficioso dirigido por unos objetivos cualitativos y cuantitativos.

Definición de proyecto


Ejemplos de proyectos.

• Lanzamiento de un nuevo producto.

• Construcción de una nueva Planta

• Realización de un viaje.

• Desarrollo de un programa de entrenamiento.

• Instalación de un nuevo software.


¿cómo nace un proyecto?

A partir de un problema, oportunidad, necesidad se generauna IDEA

•Debemos Transformar esa idea en un OBJETIVO •Luego alcanzar ese objetivo obteniendo un PRODUCTO •Ese producto debe dar solución al problema u oportunidad original.•Esto lo haremos través de la realización de un proyecto dentro el marco de las ORGANIZACIONES involucradas.


Diferenciar

• La duración del proyecto, del ciclo de vida del producto del proyecto.

• La Definición del proyecto, de la gestión de la ejecución del proyecto.

• Los responsables pueden diferir.


•La gestión de proyectos TI es más compleja por:

Complejidad intrínseca al desarrollo de software

Imprecisión en la planificación del proyecto y estimación de los costos.Baja calidad de las aplicaciones.Dificultad de mantenimiento de las

aplicaciones.•Esto hace surgir una rama de la ciencia que se llama Ingeniería de Software que intenta resolver estos problemas

Proyectos de TI


Ciclo de vida de un proyecto

Es la forma en la que se divide un proyecto en etapas y cómo se avanza entre estas etapas

Según la metodología hay varios modelos, pero analizaremos los siguientes: En cascada Orientado a hitos Orientado a prototipos Programación extrema

Modelo en cascada (I)

Es el modelo clásico Las fases se deben ejecutar

de forma secuencial, pero se puede volver a la fase anterior

Cada etapa genera una documentación o un producto que recibe de entrada la siguiente fase

Especificaciónde requisitos

Análisis

Diseño

Codificación

Pruebas

Mantenimiento

Implantación

Modelo en cascada (II)

Objetivo de cada una de las etapas: Especificación de requisitos: Documento con la

especificación de requisitos (ERQ) Análisis: Documento de análisis funcional Diseño: Documento de diseño técnico Codificación: Código fuente de la aplicación y

manuales de usuario Pruebas: Documentación de pruebas Implantación: Documento de operación

Modelo en cascada (III) Ventajas

Minimiza la repetición de tareas de desarrollo La planificación es sencilla Facilita el control, permitiéndonos afrontar

proyectos grandes Inconvenientes

Solo es adecuado cuando hay requerimientos muy bien definidos y que no van a cambiar

Retroceder para corregir fases previas o introducir cambios es muy costoso

El cliente sólo ve los resultados al final

Modelo orientado a hitos (I)

Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto

Especificaciónde requisitos

Análisis

Diseño de arquitectura

Codificación y pruebas A

Codificación y pruebas B

Entrega B

Codificación y pruebas C

Entrega A

Entrega C

Modelo orientado a hitos (II)

Ventajas El cliente va viendo los resultados Permite reducir mucho el riesgo en proyectos

grandes si se gestionan sus módulos de menor prioridad con esta técnica

Inconvenientes Se analiza todo el sistema al principio, y se puede

perder mucho tiempo en la especificación y diseño de funcionalidades que al final no nos da tiempo a implementar

Modelo orientado a prototipos (I) Se desarrolla un primer

prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente.

El cliente aporta realimentación y con ella se desarrolla el siguiente prototipo

Se van repitiendo los ciclos de iteración hasta alcanzar una versión final.

Prototipo 1

Prototipo 2

Prototipo 3

Modelo orientado a prototipos (II) Ventajas

Es muy frecuente que los requisitos sean cambiantes, con lo cual se van adaptando los prototipos

El cliente ya puede ir trabajando con los prototipos, viendo el resultado y aportando feedback

Inconvenientes En proyectos grandes es imposible saber cuando se

terminará Los desarrolladores tienen a saltarse las fases de

análisis y diseño

Programación extrema (I)

Consiste en llevar la límite el modelo de prototipos, haciendo entregas continuas con pequeños cambios en la funcionalidad

Programación extrema (II) Sus principios fundamentales son:

Desarrollo iterativo e incremental Pruebas unitarias continuas Programación en parejas Frecuente interacción con el usuario Corrección de todos los errores antes de añadir

nueva funcionalidad Hacer entregas frecuentes Refactorización del código Propiedad del código compartida Simplicidad en el código

Programación extrema (III) Ventajas

Es muy realista con respecto a la relación con el cliente

Le da importancia el diseño simple y las pruebas, un punto normalmente descuidado

Aporta muy buenas ideas Inconvenientes

Solo vale para proyectos relativamente pequeños (entre 2 y 12 desarrolladores)

Sus principios no pueden ser aplicados a rajatabla, es necesario saber decidir cuando aplicar ciertas cosas y cuándo no


Cada área pasa por esos ProcesosProceso/Gestión Inici

oPlanificación Ejecución Control Cierre

Alcance

Tiempos

Costos

Riesgos

Logística

RRHH

Comunicaciones

Calidad

Integración


¿para qué?

• La Gestión de proyectos es el conjunto de conceptos técnicas y habilidades que permiten incrementar la probabilidad de éxito de un proyecto.

• ¿qué es un proyecto exitoso?

• ¿porqué hay tantos fracasos?


LAS 3 PROMESAS.

• DESEMPEÑO: el producto del proyecto cumple con lo esperado.

• TIEMPO: Se completa en el tiempo requerido.

• COSTO: Se completa dentro del presupuesto asignado.

• Interdependientes: se plantean múltiples trade-off entre las 3 dimensiones de éxito.

Errores frecuentes en las reuniones (I)

Acompañarse de gente con experiencia en reuniones

Nunca decir precios en reuniones de toma de requisitos (esperar al presupuesto)

No dar a entender que el proyecto es sencillo, puede dar una idea equivocada sobre el precio que le vamos a dar al cliente

No hablar de más, desvelando excesiva información sobre nuestra empresa u otros proyectos

Errores frecuentes en las reuniones (II)

Cuidar la vestimenta, las formas y el lenguaje corporal

No ignorar a los técnicos Tomar notas (puede estar bien grabarlas en

audio o incluso levantar un “acta” de la reunión y enviarla por email)

¡Cuidado con las conversaciones informales!

Especificación de Requisitos (I) La captura de requisitos es parte esencial: evita

cambios posteriores en el sistema y facilita el entendimiento con el cliente

Deben especificar lo siguiente: Funcionalidad Interfaz externa Rendimiento Atributos Restricciones de diseño

Especificación de Requisitos (II)

Como deben ser los requisitos: Completos Implementación independiente Consistentes y no ambiguos Precisos Verificables Que puedan ser leídos Modificables

Muy importante: que nos permitan hacer un presupuesto

Especificación de Requisitos (III)

La toma de requisitos: Introspección: ponerse en lugar del cliente e

imaginar como desea que funcione el sistema Reuniones con el cliente

Escuchar la problemática del cliente Entender la solución que espera Ser capaz de orientar y aconsejar al cliente durante la

entrevista para orientarlo hacia nuestros productos o tecnologías

Hay modelos estándard para la toma de requisitos, de los cuales se cubre lo que necesitemos

Presupuestación ¿Cuanto dinero va a costar realizar el proyecto? Lo más difícil a la hora de hacer un

presupuesto de un proyecto TI: Diferenciar las tareas a presupuestar Estimar el tiempo de cada tarea Acotarlo de forma que el cliente no nos pueda

“colar” tareas no estimadas inicialmente A la hora de poner un precio, las tareas de

implementación se suelen cobrar por hora, pero hay más cosas que contemplar en los presupuestos...

Qué presupuestar (I) Análisis: el análisis del problema posterior al

presupuesto previo a la elaboración del documento de análisis funcional y del diseño técnico

Consultoría: cuando el objetivo del proyecto es la recomendación de medidas apropiadas y prestación de asistencia en la aplicación de dichas recomendaciones.

Preparación del entorno: instalación de servidores, aplicaciones (CVS, IDEs, etc), etc.

Qué presupuestar (II) Implementación: las tareas de programación en

sí Dirección de proyecto: las horas que dedica el

director de proyecto a la coordinación de los programadores (se suele poner un 25% del tiempo de implementación)

Implantación: instalación de la aplicación en los entornos del cliente. Cuidado con las subidas de los hitos entregables a los entornos del cliente

Qué presupuestar (II) Formación: suele estar hasta bien visto por el

cliente dar un par de charlas de formación a los usuarios sobre la aplicación

Documentación: análisis funcional, diseño técnico, manuales, documentos de puesta en producción, etc.

Desplazamientos: cuando el cliente se encuentre a una distancia considerable, se incluyen dietas.

Material: sobre todo hardware que se va a instalar en el cliente...

Los márgenes Margen de riesgo

Se añade a las tareas para cubrir errores en las estimaciones

Margen comercial Se añade para cubrir las tareas comerciales y para

poder negociar bajando el precio al bajar este margen

Margen de calidad Se deja para el control de calidad del código

Margen al tiempo de entrega Se añade para cubrirse frente a que los recursos se

tenga que dedicar a otras tareas

El flujo de caja Determina los plazos en los que el cliente va a

pagar el proyecto Se suele intentar marcar hitos en el proyecto e

ir cobrando un porcentaje a la entrega de esos hitos

Muy importante no cobrar sólo al final del proyecto, sobre todo en proyectos largos, porque nos puede traer problemas financieros

Tener cuidado con empresas que pagan con pagarés a 30, 60 o incluso 90 días

Clausulas de penalización En algunos casos los clientes pueden pedir que

se incluyan clausulas que penalicen el retraso del proyecto

Limitarlas a un porcentaje del costo total del proyecto (un 20% como mucho)

Cubrirse las espaldas en la estimación de tiempos, sobre todo aplicando margen al tiempo de entrega

El cálculo de la rentabilidad Es muy importante tener un modelo de

presupuesto que luego nos permita hacer un cálculo de la rentabilidad sobre los tiempos estimados

Para ello durante la fase de implementación mediremos los tiempos que lleva cada tarea y los compararemos con el estimado (control de tareas)

Esto nos será de mucha ayuda en futuros presupuestos

Otras formas de presupuestar Muchas veces lo que se presupuestan no son

sólo proyectos, pueden ser: Productos de software ya terminados: lo que se

vende es la licencia y en muchos casos la implantación.

Mantenimientos mensuales: con una cuota fija al mes para realizar tareas de mantenimiento de una aplicación.

Packs de horas: se le cobran al cliente X horas que éste irá consumiendo según se vayan realizando desarrollos solicitados.

Licencias Una vez que tenemos un proyecto de software

desarrollado podemos establacer licencias para venderlo a varios clientes. Estas licencias pueden ser: Por empresa Por usuario de la empresa Por cliente de la empresa que utilice la aplicación Por CPU de servidor etc.


Volvamos al primer problema :

• Transformar la IDEA en un OBJETIVO del proyecto.

• dentro del Entorno Estratégico de la Empresa.

• requiere un • ENFOQUE METODOLÓGICO PRÁCTICO


el QUÉ del proyecto.

OBJETIVOidea

Expresión concreta del resultadoa obtener en términos de :Alcance, desempeño, tiempo y costo.


Objetivos específicos

• Se debe definir específicamente que debo lograr (en tiempos y/o costos y/o técnicamente) con la ejecución del proyecto para alcanzar el objetivo general.

• Cada objetivo específico que defina consumirá recursos para alcanzarse.


Características:• Deben ser: • concretos, no generales• verificable objetivamente que se alcanzó el

objetivo• realistas y alcanzables• Consistentes con los recursos disponibles

o previstos• Consistentes con los planes, políticas y

procedimientos de la empresa• No excesivamente complejos.


Entregables

• ¿Cómo alcanzo los objetivos específicos?

• ¿Qué debo tener al final del proyecto para decir que cada objetivo específico se alcanzó?

• Entregables: Resultados tangibles y verificables que marcan que uno o varios objetivos se alcanzaron.


Entregables

• Están relacionados con el “cómo” voy a realizar el proyecto. ¿ Qué productos voy a entregar para alcanzar el objetivo?

• Ej.: para poder obtener la información de un cliente en menos de 10 segundos puedo tener distintos entregables según como lo implemente:– Una bibliorato con un sistema fácil de índice – Un software con una base de datos .......


Ahora sí:

• La definición de los entregables dispara toda la metodología analítica conocida y en uso.

• A lo largo de la ejecución del proyecto toda la gestión de los cambios, la delegación y la gestión de riesgos se ve a la luz de la línea estratégica de la empresa.


Dos realidades

• Las empresas que realizan proyectos en su seno: el producto del proyecto se integra a la empresa.

• Las empresas que ejecutan proyectos para terceros: viven de ejecutar proyectos para otros.


Dos tipos de problemas

1.Incorrecta definición inicial del alcance y la especificación del mismo.

2. Modificaciones al alcance durante el desarrollo del proyecto

Por ej. – Un proyecto tiene un presupuesto de 1000 – Si se hubiera planificado desde el inicio, con el nuevo

alcance costaría 2000.– Pero al introducir la modificación durante la ejecución

del proyecto lleva los costos a 5.000 en lugar de 2000.

Education

Clase proyecto sidet