Administración de la Producción de Sistemas Computacionales Si00-875 Módulo 2: Evaluación Preliminar del Proyecto Ing. Ignacio Cabral Perdomo, M.C. ITESM.

Presentación del tema: "Administración de la Producción de Sistemas Computacionales Si00-875 Módulo 2: Evaluación Preliminar del Proyecto Ing. Ignacio Cabral Perdomo, M.C. ITESM."— Transcripción de la presentación:

1 Administración de la Producción de Sistemas Computacionales Si00-875 Módulo 2: Evaluación Preliminar del Proyecto Ing. Ignacio Cabral Perdomo, M.C. ITESM - CCV

2 ¿Cómo organizamos el proyecto? No hay un patrón general que responda a: ¿Cómo se asignarán las responsabilidades del administrador del proyecto y los otros miembros del equipo? ¿Cómo se asignarán las responsabilidades del administrador del proyecto y los otros miembros del equipo? ¿A quién reportará el administrador del proyecto? ¿A qué nivel y en qué parte de la organización? ¿A quién reportará el administrador del proyecto? ¿A qué nivel y en qué parte de la organización?

3 ¿Habrá una oficina especial para el proyecto o permanecerán los contribuyentes al mismo en sus propios departamentos? ¿Habrá una oficina especial para el proyecto o permanecerán los contribuyentes al mismo en sus propios departamentos? ¿Quién es responsible del desarrollo y operación de los sistemas de control y planeación para multiproyectos? ¿Quién es responsible del desarrollo y operación de los sistemas de control y planeación para multiproyectos? En pocas palabras: ¿Cómo se organizará administrativamente el proyecto?

4 Alternativas Organizacionales para la Administración de Proyectos Se recomiendan tres principalmente: Se recomiendan tres principalmente: Puramente funcional. Puramente funcional. Matriz función-proyecto. Matriz función-proyecto. Proyecto puro. Proyecto puro. Se habla del “continuo organizacional”

5 Alternativas Organizacionales para la Administración de Proyectos

6

7

8

9

10

11

12 Principio básico del lugar de reporte “La función de administración del proyecto deberá reportar al administrador o ejecutivo de línea que resuelva realmente todos los conflictos dentro y entre los proyectos a ser administrados”. “La función de administración del proyecto deberá reportar al administrador o ejecutivo de línea que resuelva realmente todos los conflictos dentro y entre los proyectos a ser administrados”. Otros factores tales como tamaño, alcance, y naturaleza del proyecto afectan el sitio a donde se reportará.

13 Responsabilidades del administrador general del proyecto: Proveer dirección diaria a los administradores o especialistas asignados a la oficina del proyecto. Proveer dirección diaria a los administradores o especialistas asignados a la oficina del proyecto. Resolver conflictos de prioridades, recursos y otros que se presenten. Resolver conflictos de prioridades, recursos y otros que se presenten. Seleccionar al personal del proyecto basado en sus habilidades. Seleccionar al personal del proyecto basado en sus habilidades.

14 Responsabilidades del administrador general del proyecto: Desarrollar e implementar prácticas de administración de proyectos y sistemas de información para el control del proyecto. Desarrollar e implementar prácticas de administración de proyectos y sistemas de información para el control del proyecto. Informar a la alta dirección del progreso y problemas en todos los proyectos. Informar a la alta dirección del progreso y problemas en todos los proyectos.

15 El equipo staff para el proyecto: Tres opciones básicas: Asignar personas directamente a la oficina del proyecto, bajo el control del administrador del mismo. Asignar personas directamente a la oficina del proyecto, bajo el control del administrador del mismo. Asignar las tareas requeridas para el proyecto a departamentos funcionales específicos o staffs especializados. Asignar las tareas requeridas para el proyecto a departamentos funcionales específicos o staffs especializados. Contratar tareas y trabajos para el proyecto fuera de la organización. Contratar tareas y trabajos para el proyecto fuera de la organización. Pensemos: ¿qué ventajas tiene cada una de ellas? ¿cuándo usar una u otra?

16 Servicios de soporte a la ADP: Responsable del proyecto.Responsable del proyecto. Contabilidad del proyecto. Contabilidad del proyecto. Servicios administrativos especializados para la ADP. Servicios administrativos especializados para la ADP. Planeación. Planeación. Estimación. Estimación. Identificación de interfaces. Identificación de interfaces. Presupuestos. Presupuestos. Control del alcance de trabajos. Control del alcance de trabajos. Autorización y control de trabajos. Autorización y control de trabajos.

17 Servicios de soporte a la ADP: Control y programación de tiempos.Control y programación de tiempos. Control de costos. Control de costos. Monitoreo y evaluación del proyecto. Monitoreo y evaluación del proyecto. Administración general. Administración general. Servicios especializados de soporte en procesamiento de datos (por ejemplo Lotus Notes o herramientas de groupware). Servicios especializados de soporte en procesamiento de datos (por ejemplo Lotus Notes o herramientas de groupware). Un proyecto grande es en realidad una tarea muy compleja

18 Los roles clave en la ADP: Nivel ejecutivo:Nivel ejecutivo: El administrador general El administrador general El patrocinador del proyecto El patrocinador del proyecto Nivel multiproyectos: Nivel multiproyectos: El administrador de la administración del proyecto. El administrador de la administración del proyecto. Nivel proyecto: Nivel proyecto: El administrador del proyecto El administrador del proyecto Nivel de departamento funcional o contribuyente al proyecto: Nivel de departamento funcional o contribuyente al proyecto: El líder funcional del proyecto. El líder funcional del proyecto.

19 El administrador general: Su papel en la DP está enfocado en el proceso de administración de proyectos generales de toda la organización, y cómo están integrados éstos con otros aspectos de la organización. Asegurar proyectos correctosAsegurar proyectos correctos Proveer recursos adecuados Proveer recursos adecuados Asegurar que se usen prácticas adecuadas de ADP Asegurar que se usen prácticas adecuadas de ADP Monitorear el desempeño general de los proyectos. Monitorear el desempeño general de los proyectos.

20 El administrador de la ADP: Planea, organiza, evalúa, dirije, controla y lleva el proyecto de inicio a fin. Responsabilidades: Producir el producto final o resultado dentro de las especificaciones técnicas, de costos y de tiempos con los recursos disponibles en la organización. Producir el producto final o resultado dentro de las especificaciones técnicas, de costos y de tiempos con los recursos disponibles en la organización. Cumplir los objetivos de ganancia del proyecto si está por contrato. Cumplir los objetivos de ganancia del proyecto si está por contrato. Integrar los esfuerzos de todos los miembros contribuyentes al proyecto, proveer liderazgo al equipo. Integrar los esfuerzos de todos los miembros contribuyentes al proyecto, proveer liderazgo al equipo. Alertar a la alta administración, en cualquier momento, si las requerimientos técnicos, de costo, o de tiempo no se cumplirán. Alertar a la alta administración, en cualquier momento, si las requerimientos técnicos, de costo, o de tiempo no se cumplirán.

21 El administrador de la ADP: Tomar o forzar las decisiones requeridas para asegurar que los objetivos del proyecto se cumplirán. Tomar o forzar las decisiones requeridas para asegurar que los objetivos del proyecto se cumplirán. Recomendar la finalización del proyecto o una solución alternativa si los objetivos del proyecto no pueden ser alcanzados. Recomendar la finalización del proyecto o una solución alternativa si los objetivos del proyecto no pueden ser alcanzados.

22 El administrador de la ADP: Servir como el primer punto de contacto entre el proyecto con el cliente, la alta administración y los administradores funcionales. Servir como el primer punto de contacto entre el proyecto con el cliente, la alta administración y los administradores funcionales. Negociar “contratos” (órdenes de trabajo) con los diversos departamentos funcionales para desempeñar labores de acuerdo a las especificaciones y dentro de los tiempos y costos señalados. Negociar “contratos” (órdenes de trabajo) con los diversos departamentos funcionales para desempeñar labores de acuerdo a las especificaciones y dentro de los tiempos y costos señalados.

23 Responsabilidades y autoridad Las responsabilidades y autoridad asignadas a cada persona dependen de: Las responsabilidades y autoridad asignadas a cada persona dependen de: El tamaño y la naturaleza de la organización. El tamaño y la naturaleza de la organización. El tamaño y naturaleza del proyecto y de su actual fase en el ciclo de vida. El tamaño y naturaleza del proyecto y de su actual fase en el ciclo de vida. El número de proyectos ejecutándose. El número de proyectos ejecutándose. Las capacidades de los administradores involucrados. Las capacidades de los administradores involucrados. La madurez de la función de ADP dentro de la organización. La madurez de la función de ADP dentro de la organización.

24 Algunas características Características personales de administradores de ADP efectivos: Características personales de administradores de ADP efectivos: Flexibilidad y adaptabilidad. Flexibilidad y adaptabilidad. Preferencia por la iniciativa y el liderazgo. Preferencia por la iniciativa y el liderazgo. Agresividad, confiable, persuasivo y con influencia verbal. Agresividad, confiable, persuasivo y con influencia verbal. Ambicioso, activo. Ambicioso, activo. Efectivo en comunicación e integrador. Efectivo en comunicación e integrador. Amplio campo de intereses personales. Amplio campo de intereses personales.

25 Algunas características Entusiasmo, imaginación y espontaneidad. Entusiasmo, imaginación y espontaneidad. Capaz de balancear soluciones técnicas con tiempo, costo y factores humanos. Capaz de balancear soluciones técnicas con tiempo, costo y factores humanos. Bien organizado y disciplinado. Bien organizado y disciplinado. Un generalista más que un especialista. Un generalista más que un especialista. Capaz de dedicar la mayor parte de su tiempo a la planeación y control. Capaz de dedicar la mayor parte de su tiempo a la planeación y control. Capaz de identificar problemas. Capaz de identificar problemas. Hacer decisiones correctamente. Hacer decisiones correctamente. Capaz de mantener un balance justo en el uso de su tiempo. Capaz de mantener un balance justo en el uso de su tiempo.

26 El administrador del Proyecto Integrador Habilidades Habilidades de equipo y personas Habilidades administrativas básicas y de negocios Habilidades técnicas (Disciplina de su especialidad) Habilidades en ADP (Métodos y herramientas) Conocimiento del papel del patrocinador del proyecto Conocimiento Ambiente del proyecto

27 El papel del Administrador de proyectos A one-track mind cannot effectively manage a two-track railroad Russel Ackoff Russel Ackoff Lidiar con la resistencia. Lidiar con la resistencia. Necesidad de flexibilidad. Necesidad de flexibilidad. Es una labor difícil y que requiere experiencia y muchas características especiales. Es una labor difícil y que requiere experiencia y muchas características especiales.

28 El papel del Administrador de proyectos Algunas ideas: Algunas ideas: Algunas veces la negativa a cooperar es causada por quienes se sienten amenazados.Algunas veces la negativa a cooperar es causada por quienes se sienten amenazados. “Si usted hace lo que siempre ha hecho, obtendrá lo que siempre ha obtenido”. “Si usted hace lo que siempre ha hecho, obtendrá lo que siempre ha obtenido”. “Si usted trata algo repetidamente y no tiene éxito, entonces ¡Trate algo diferente!” “Si usted trata algo repetidamente y no tiene éxito, entonces ¡Trate algo diferente!”

29 El papel del Administrador de proyectos Algunas ideas: Algunas ideas: In any system of men or machines, the element in the system with the greatest flexibility in its behavior will control the system. Ross Ashby

30 Evaluación preliminar del proyecto Cinco preguntas básicas ¿Involucra el trabajo la integración de muchos componentes en un todo operacional funcionando? 1

31 Cinco preguntas básicas ¿ Es el trabajo muy grande o complejo técnicamente ? 2

32 Cinco preguntas básicas ¿ Cree firmemente la alta gerencia que un individuo solo deberá estar disponible para servir como un punto focal para información y responsabilidad ? 3

33 Cinco preguntas básicas ¿ Está siendo desarrollado el proyecto en un ambiente de requerimientos cambiantes ? 4

34 Cinco preguntas básicas ¿ Requiere la tarea que un grupo diverso de profesionales sean reunidos para trabajar por un objetivo común ? 5

35 Conceptos básicos Todo proyecto inicia con un problema. Al terminarse el proyecto podemos cuestionar: ¿ Cumple el producto final con solucionar el problema del usuario ? ¿ Está satisfecho el usuario con el proceso de desarrollo ? ¿ Está la alta administración satisfecha con el producto así como con el proceso ? ¿ Está satisfecho el equipo del proyecto ?

36 ¿Por qué tienen éxito los proyectos al usar ADP? Básicamente: Un inicio limpio de todas las actividades. Planeación y control de actividades y del proceso. Un enfoque profesional y de calidad para el desarrollo.

37 Razones para la ADP de Software Razón 1. El creciente tamaño y complejidad de los proyectos de desarrollo de software está haciendo que la administración casual de proyectos sea imposible. Razón 2. El desempeño consistente y predecible no es posible usando la administración casual de proyectos.

38 Razones para la ADP de Software Razón 3. Al usar administración casual, no es posible el delegar efectivamente las tareas de administración del proyecto mientras se retiene el control sobre todo el proyecto. Razón 4. La curva de aprendizaje para el nuevo administrador de proyecto es inaceptablemente larga cuando se usa la administración casual.

39 Ciclos de vida del software Identificación de requerimientos DiseñoCódigo Prueba y liberación Mantenimiento Análisispostfinalización Mercadotecnia Análisis y Evaluación Ciclo de vida del desarrollo de SW Ciclo de vida de la administración del proyecto Según Roetzheim, 1988 Structured Computer Project Management

40 Entrevistas y Documentos del Cliente Análisis de requerimientos alternativas Estimación Diseñopreliminar Evaluación del Proyecto Estudio de FactibilidaddelProyecto Evaluaciónpreliminardelproyecto Fase de Análisis y Evaluación del Proyecto

41 Fase de Mercadotecnia del Producto Se obtiene como resultado la propuesta del proyecto. Definir exactamente qué se intenta hacer por el cliente.Definir exactamente qué se intenta hacer por el cliente. Convencer al cliente que la propuesta cumplirá con sus necesidades. Convencer al cliente que la propuesta cumplirá con sus necesidades. Decir al cliente cómo se intenta producir el software. Decir al cliente cómo se intenta producir el software. No dejar duda en la mente del cliente de que se és capaz de producir el software. No dejar duda en la mente del cliente de que se és capaz de producir el software. Incluir toda la información necesaria para permitir que el propio documento “venda” el producto. Incluir toda la información necesaria para permitir que el propio documento “venda” el producto.

42 Fase de Diseño Preliminar Actividades de la etapa de Diseño Espec. De Diseño del sistema Espec. De funcional del programa Plan de Proyecto Espec. De Diseño del programa

43 Nuestra brújula a lo largo del proyecto: El diagrama de fases del proyecto (Rakos, 1993) DefiniciónAnálisisDiseño ProgramaciónPruebasAceptación Operación

44 ¿ Cómo construímos una casa ? La primera cuestión es que existen de varios tamaños. Puede construirla una sola persona Requiere: Mdelado mínimo Proceso simple Herramientas simples

45 Construída más eficientemente y a tiempo por un equipo completo. Requiere: Modelado Proceso bien definido Herramientas poderosas Fuente: Rational Corporation

46 ¿Qué pasa con un rascacielos? Fuente: Rational Corporation

47 Arquitectura Temprana Progreso: Limitado Limitado conocimiento de la teoría. Fuente: Rational Corporation

48 Arquitectura Moderna Progreso Avances en materiales Avances en materiales Avances en análisis Avances en análisis Avances en ADP Avances en ADP Scalas: 5 veces la cúpula del 5 veces la cúpula del panteón de Roma. 3 veces la altura de 3 veces la altura de la pirámide de Keops. Fuente: Rational Corporation

49 Modelando una Casa Requerimos de un proyecto. También de una maqueta Fuente: Rational Corporation

50 Ejercicio: Discutir en grupo cómo se comparan las fases del proyecto de software con la construcción de una casa: DefiniciónAnálisisDiseñoProgramación Pruebas del sistema AceptaciónOperación

51 Fase de Definición del Proyecto El objetivo primordial de esta fase es el obtener el suficiente entendimiento del problema del usuario con el fin de estimar costos y tiempos. 3 Actividades principales: Obtención de los requerimientos del usuario. Obtención de los requerimientos del usuario. Decisión de hacer o nó el proyecto. Decisión de hacer o nó el proyecto. Escritura de la propuesta del proyecto. Escritura de la propuesta del proyecto.

52 Actividades de la Fase de Definición Documento de requerimientos (DR) Firma del DR por el usuario y el equipo del proyecto Plan Preliminar del Proyecto (PPP) Propuesta preliminar resultado del análisis Propuesta de Desarrollo

53 El Documento de Requerimientos (DR) Establece el problema del usuario y las soluciones generales requeridas.Establece el problema del usuario y las soluciones generales requeridas. Está escrito en el lenguaje de trabajo del usuario, no en términos computacionales. Está escrito en el lenguaje de trabajo del usuario, no en términos computacionales. Se utiliza en ocasiones como una “requisición para propuesta” (contratos externos a la compañía). Se utiliza en ocasiones como una “requisición para propuesta” (contratos externos a la compañía). Se dedicará mucho tiempo con el usuario, quien no es una persona técnica. Se dedicará mucho tiempo con el usuario, quien no es una persona técnica.

54 La Entrevista con el Usuario Información correcta = buen DRInformación correcta = buen DR Problema real: encontrar al verdadero usuario final del producto. Problema real: encontrar al verdadero usuario final del producto. Primer paso fundamental: aprender del negocio. Primer paso fundamental: aprender del negocio. Planear la entrevista. Planear la entrevista.

55 La Entrevista con el Usuario Iniciar con las salidas. Iniciar con las salidas. ¿ Cómo fluye la información entre los departamentos e individuos ? ¿ Cómo fluye la información entre los departamentos e individuos ? Determinar: frecuencia, tiempos y exactitud. Determinar: frecuencia, tiempos y exactitud. Continuar con las entradas (¿qué información se requiere para producir las salidas?) Continuar con las entradas (¿qué información se requiere para producir las salidas?) Las cinco Ws: Who? What? Where? When? Why? Las cinco Ws: Who? What? Where? When? Why? El “cómo” pasa a la etapa de diseño. El “cómo” pasa a la etapa de diseño.

56 Contenido del DR 1. Introducción. 1. Introducción. Identificar la compañía y a los responsables de la autorización del proyecto, así como al usuario.Identificar la compañía y a los responsables de la autorización del proyecto, así como al usuario. Problemas a ser resueltos, historia del problema, ejemplos de la situación problemática, motivaciones para darle solución. Problemas a ser resueltos, historia del problema, ejemplos de la situación problemática, motivaciones para darle solución. Esta sección sensibiliza al equipo con el usuario y su problema.

57 Contenido del DR 2. Objetivos del Proyecto. 2. Objetivos del Proyecto. Un estatuto simple sobre el por qué estamos proponiendo el desarrollo. Se pueden mencionar restricciones de tiempo y dinero. 3. Principales Funciones. Estatutos simples (sin detalles) acerca de cómo funcionará el sistema, basados en los objetivos del proyecto.

58 Contenido del DR 4. Salidas Generales. 4. Salidas Generales. Descripción simple de la información requerida del sistema. Nota: detallar toda la información (nó pantallas o reportes) requerida. 5. Entradas generales de información. Revisar las salidas y determinar los datos de entrada necesarios para producirla. Nota: Un usuario sin experiencia no podrá determinar este punto. Puede ser llenado después por el analista.

59 Contenido del DR 6. Desempeño. 6. Desempeño. Número de transacciones a procesar, cantidad de datos a almacenar, frecuencia de reportes. Describir todo en términos de promedios y máximos. 7. Crecimiento. Estimar el crecimiento del negocio y los años que el sistema funcionará..

60 Contenido del DR 8. Operación y ambiente. 8. Operación y ambiente. Lugar físico donde residirá el sistema, dónde estarán las terminales, quién lo usará. Medidas de seguridad para ambientes hostiles. 9. Compatibilidad, interfaces. Aclarar si se requiere comunicación con otros equipos, protocolos posibles, acceso distribuído, etc., además de otros productos de software con los que interaccionará el sistema.

61 Contenido del DR 10. Disponibilidad. 10. Disponibilidad. Indicar el MTBF (Mean Time Between Failures) y el MTR (Mean Time to Repair). 11. Interface humana. Experiencia computacional requerida por el usuario, indicar cómo manejarán los nuevos usuarios al sistema (conducido por menús, ayuda en linea, etc.)

62 Contenido del DR 12. Impacto organizacional. 12. Impacto organizacional. Qué departamentos serán afectados y cómo cambiará su forma de trabajo. Cómo interaccionará el sistema con sistemas manuales (existentes o nuevos). 13. Mantenimiento y soporte. Tiempo de garantía y tiempo de respuesta cuando se notifiquen fallas.

63 Contenido del DR 14. Documentación y Entrenamiento. 14. Documentación y Entrenamiento. Qué documentos y/o cursos se requerirán. Manuales para usuario, operadores y mantenimiento del sistema. Cursos de entrenamiento para usuarios. 15. Ventajas del sistema (sólo para RFP). Solicitar datos a los vendedores sobre su situación competitiva, posición en el mercado, por qué sienten que deben ser seleccionados.

64 Contenido del DR 16. Términos y condiciones (sólo para RFP). 16. Términos y condiciones (sólo para RFP). Establecer las bases para la selección, cuándo y cómo se notificará el ganador del concurso o de la licitación. Se puede anexar cualquier otro punto que reforce este documento

65 Responsabilidades del usuario El usuario tiene que cumplir dos responsabilidades fundamentales: El usuario tiene que cumplir dos responsabilidades fundamentales: Estar disponible (o tener disponibilidad de tiempo) Estar disponible (o tener disponibilidad de tiempo) Tener cierta autoridad para hacer decisiones con respecto al sistema propuesto. Tener cierta autoridad para hacer decisiones con respecto al sistema propuesto.Cuidado: Se deben seleccionar bien los usuarios, nuevamente: ¿Quién es realmente el usuario del sistema?

66 Decisión: Go/No-Go Dos preguntas básicas: Dos preguntas básicas: ¿Es técnicamente factible el proyecto? ¿Es técnicamente factible el proyecto? ¿Lo puedo (o podemos) hacer? ¿Lo puedo (o podemos) hacer? Cuando se opte por la decisión NO, la mejor forma de decirlo es con razones financieras, NUNCA decir: ¡No puedo! Existen ocasiones en que se debe llevar a cabo el proyecto forzosamente.

67 ¿Por qué es importante hacer la evaluación preliminar? Se asegura que el proyecto sea o no aceptado y sobre todo que sea entregado a tiempo y dentro del presupuesto. Se asegura que el proyecto sea o no aceptado y sobre todo que sea entregado a tiempo y dentro del presupuesto. Va a influir en la decisión go/no go Va a influir en la decisión go/no go

68 Puntos críticos de decisión ¿Qué son dichos puntos? Son puntos identificables en la vida del proyecto en los cuales el proyecto es evaluado y se hace una decisión sobre si continuar al siguiente paso del desarrollo o dejarlo a un lado. Son puntos identificables en la vida del proyecto en los cuales el proyecto es evaluado y se hace una decisión sobre si continuar al siguiente paso del desarrollo o dejarlo a un lado.

69 Puntos críticos de decisión Hay tres principales Factibilidad Diseño Desarrollo Operación Puntos críticos de decisión

70 Beneficios Las revisiones de los estimados de costo y desempeño serán más precisos que los estimados previos. Las revisiones de los estimados de costo y desempeño serán más precisos que los estimados previos. Se pueden solicitar fondos extras sustanciales con el fin de proceder al siguiente paso. Se pueden solicitar fondos extras sustanciales con el fin de proceder al siguiente paso. El proyecto está en un punto lógico de paro. El proyecto está en un punto lógico de paro.

71 Puntos críticos de decisión Preguntas básicas ¿Es técnicamente factible el proyecto? ¿Es técnicamente factible el proyecto? ¿Es económicamente factible? ¿Es económicamente factible? ¿Podrá terminarse en el tiempo asignado? ¿Podrá terminarse en el tiempo asignado? ¿Cuáles son los riesgos al aceptar el proyecto? ¿Cuáles son los riesgos al aceptar el proyecto? ¿Cuáles son los beneficios? ¿Cuáles son los beneficios? Los beneficios, ¿superan a los riesgos? Los beneficios, ¿superan a los riesgos?

72 Componentes principales de un proyecto de informática 1. De trabajo intensivo Involucran el gasto significativo de mano de obra humana en la organización para desarrollar un producto nuevo y personalizado. Ejemplos: programas de software, entrenamiento, instalación, mantenimiento y diseño de tarjetas electrónicas.

73 Componentes principales de un proyecto de informática 2. Productos estándar Involucran la venta de productos de “estantería” Ejemplos: componentes computacionales, software empacado, sistemas operativos y aplicaciones estándares ya listas.

74 Calculando lo básico Determinar las cuentas a incluir Descomponer el proyecto Características del proyecto Estimar el trabajo intensivo Estimar la compra de productos Estimar la renta de productos Resumir los cálculos de cuentas Según: Roetzheim, 1988

75 Completando el análisis financiero del proyecto Herramientas Retorno sobre la inversión (ROI).Retorno sobre la inversión (ROI). Vuelta de activos (Asset Turnover). Vuelta de activos (Asset Turnover). Índice de Roetzheim. Índice de Roetzheim. Índice de Disman. Índice de Disman. Índice de Olsen. Índice de Olsen.

76 Evaluación de riesgos Tema muy importante. Le dedicaremos otro juego de filminas a este tema.

77 Impacto en la estrategia y objetivos tácticos corporativos El aspecto cuantitativo no es el único factor. El aspecto cuantitativo no es el único factor. Puede haber otros usos y explotaciones del hardware y del software. Puede haber otros usos y explotaciones del hardware y del software. El proyecto puede servir como un medio de entrenamiento al personal. El proyecto puede servir como un medio de entrenamiento al personal. Oportunidad de ganar reputación en un área de “expertise”. Oportunidad de ganar reputación en un área de “expertise”.

78 Modelo de contribución de valor Es un modelo que nos permite combinar toda la información obtenida de los análisis anteriores y de ahí partir a la decisión go/no go para el proyecto. Es un modelo que nos permite combinar toda la información obtenida de los análisis anteriores y de ahí partir a la decisión go/no go para el proyecto.

79 Modelo de contribución de valor Pasos a seguir: Pasos a seguir: Enlista y pondera los criterios de alto nivel Enlista y pondera los criterios expandidos Define las guías para valuar

80 Modelo de contribución de valor Criterios de alto nivel: FactoresFinancieros Modelo de Contribución de la empresa Factores de riesgo Factoresestratégicos 0.5 0.30.2 Nota: todos suman 1 1

81 Modelo de contribución de valor Criterios expandidos: FactoresFinancieros Modelo de Contribución de la empresa Factores de riesgo Factoresestratégicos 0.5 0.30.2 ROI Índice de Roetzheim Otros usos del SW DesarrollarexperienciaEntrenam.potencial 0.50.5 0.50.20.3 1

82 Modelo de contribución de valor Definiendo la valuación: FactoresFinancieros Modelo de Contribución de la empresa Factores de riesgo Factoresestratégicos 0.5 0.30.2 ROI Índice de Roetzheim Otros usos del SW DesarrollarexperienciaEntrenam.potencial 0.50.5 0.50.20.3 1 90 80601090 598550 Total del Proyecto:69.3