Planificación y gestión de proyectos TIC

Planificación y gestión de proyectos TIC Enrique Barreiro Alonso [email_address] Escola Superior de Enxeñería Informática www.ei.uvigo.es Jornada INNOVAR, DE LA ESTRATEGIA A LA PRÁCTICA Confederaci ón de Empresarios de Pontevedra Vigo, 13 de junio de 2007

Planificación estratégica de las TIC Desarrollo e implantación de una estrategia TIC Buen conocimiento de Infraestructura actual Tendencias tecnológicas potenciales Necesidades de la empresa a satisfacer por los sistemas TIC Perspectivas de infraestructura TIC Especificación de objetivos futuros Proceso de planificación e innovación TIC

Planificación de la estrategia TIC: actividades Clasificación de los sistemas TIC Planificación estratégica Definición de la infraestructura prevista Plan de migración Implantación de la estrategia TIC Actividad 1 Actividad 2 Actividad 3 Actividad 4 Actividad 5

Actividad 1: clasificación de sistemas TIC Importancia estratégica de los sistemas TIC: Evaluación de los sistemas TIC en cuanto a su papel en la evolución de la infraestructura TIC a largo plazo

Actividad 1: clasificación de sistemas TIC Análisis de la cartera de sistemas existentes en relación con: Objetivos estratégicos de la empresa Requisitos que la empresa demandará de las TIC Técnica: cuadrícula de sistemas ESTRATÉGICO : sistemas TIC críticos para el éxito futuro de la empresa. ALTO POTENCIAL : sistemas TIC que pueden tener importancia estratégica en el futuro para la empresa. OPERATIVO CLAVE : sistemas TIC que sostienen actividades actualmente críticas, sin las cuales la empresa se encontraría en una desventaja importante (control de stocks, facturación,…) DE SOPORTE : sistemas TIC que mejoran la eficacia de la empresa pero no son críticos por sí mismos para operaciones reales (sistemas de apoyo a la toma de decisiones, por ejemplo) ESTRATÉGICO ALTO POTENCIAL OPERATIVO CLAVE DE SOPORTE

Actividad 1: clasificación de sistemas TIC Clasificación de los sistemas TIC según su importancia para las actividades principales de la empresa Permite priorizar la atención dedicada a los sistemas en términos de planificación estratégica de las TIC Objetivos para cada sistema: mejorar su valor de continuación elevando su calidad y/o contribución Incorporar a la estrategia TIC los cambios que faciliten esa acción (etapa de Planificación Estratégica) ALTA ALTA BAJA BAJA C ALIDAD T ÉCNICA C ONTRIBUCIÓN Cuestionar su valor de continuación Objetivo : incrementar su contribución a la empresa Objetivo : incrementar su calidad técnica

Actividad 2: planificación estratégica de las TIC Planificación a corto y medio plazo en el marco de los objetivos a largo plazo Desviaciones del plan a largo plazo: desarrollos tácticos para satisfacer necesidades inmediatas Se contemplará la solución del paquete como un sistema desechable y se introducirá al menor coste posible, con el objetivo de reemplazarlo por la solución prevista en el momento adecuado (plan de migración) Plan a largo plazo Plan a corto plazo Plan a medio plazo Se necesita adquirir un paquete de ventas para dar soporte a un nuevo producto a corto plazo El plan a medio plazo proporciona la funcionalidad precisa dentro de un sistema de gestión integrado (ERP) para todos los productos

Actividad 2: planificación estratégica de las TIC Objetivos comerciales Auditoría de sistemas Estrategia comercial Revisión técnica Aportaciones necesarias para desarrollar la estrategia TIC Sistemas actuales Oportunidades tecnológicas Estrategia TIC

Actividad 2: planificación estratégica de las TIC Necesidades a alto nivel Necesidades pormenorizadas Documento de Estrategia TIC Aprobación por la dirección general Elaboración de la arquitectura. Planes detallados de migración Plan de proyecto Todo el proceso debe estar dirigido dentro del marco de un procedimiento

Actividad 2: planificación estratégica de las TIC Introducción y alcance de la estrategia Principales necesidades comerciales Posición actual de la infraestructura Nuevas oportunidades tecnológicas Infraestructura prevista Implicaciones para el usuario Esquema del plan de entregas Costes Riesgos Conclusión Especificar si la estrategia es un objetivo para toda la empresa o para alguna/s partes de ella Esquema de la dirección estratégica de la empresa y sus retos más importantes para las TIC. Examen del entorno actual y de hasta qué punto puede satisfacer objetivos y necesidades futuras Cualquier tecnología que tenga potencial para solucionar problemas de la empresa Una visión de alto nivel de la solución técnica propuesta Cualquier nueva habilidad o formación necesaria para el conjunto de usuarios Principales hitos en la implantación de la infraestructura prevista El coste total del trabajo Análisis de riesgos de la propuesta

Actividad 3: infraestructura prevista Modelo inicial: arquitectura lógica Puede no ser totalmente realista, ignorando los sistemas existentes Garantiza que el objetivo no se verá dificultado por suposiciones sobre el tipo de sistemas que existirá en el futuro: Expresa las funciones necesarias para satisfacer los requisitos sin interferencias del detalle de la implantación Modelo inicial: arquitectura lógica

Actividad 3: infraestructura prevista Pasar de la visión lógica a la física Considerar el potencial para utilizar sistemas existentes y nuevas oportunidades proporcionadas por la tecnología emergente Elevado coste e incertidumbre de la tecnología emergente: Basar la infraestructura en tecnología emergente sólo cuando implique beneficios significativos Sistemas heredados (“legacy systems”) Servicios fiables (fallos identificados) Problema: necesidades iniciales diferentes de las actuales Arquitectura lógica Arquitectura física

Arquitectura de un sistema de información Política de la arquitectura Todos los sistemas deben situarse dentro de una arquitectura de sistema explícita Necesario organizar la estructura en relación con la aplicación, datos y componentes técnicos y documentar la relación entre los diferentes aspectos Toda la actividad TIC debe dirigirse en el marco de trabajo definido por la arquitectura. Cualquier desarrollo excepcional necesario fuera de este marco debe ser aprobado previamente La arquitectura forma un marco de diseño evolutivo para la infraestructura de las TIC Continúa siendo mantenida y revisada Cambios dirigidos bajo el control de versiones de la arquitectura Difundir para que se utilice siempre la versión actual de la arquitectura como base de diseños, desarrollos o adquisiciones. Documento de arquitectura Datos Aplicaciones Componentes

Arquitectura de un sistema de información Problema: diseñar la arquitectura de los sistemas TIC con un exceso de conceptos orientados a la implantación Reduce la posibilidad de seguimiento entre requisitos y el diseño Enfocarse en un espacio de solución específica inhibe la exploración de alternativas La solución puede satisfacer necesidades inmediatas pero no requisitos más amplios y futuros El diseñador puede perder de vista el diseño global, dada la gran cantidad de detalles de implantación

Arquitectura de un sistema de información Arquitectura de datos Arquitectura lógica Arquitectura física Arquitectura técnica Arquitectura de la documentación Comunicación de la arquitectura Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa 5 Etapa 6

Etapa 1: Arquitectura de datos Debe representar las necesidades de información de la empresa Falta de coherencia en una arquitectura de datos y aplicación de normas de datos asociadas Problemas en el flujo de la información Sistema de pedidos Sistema de reclamaciones Analizar impacto reclamaciones en nuevos pedidos Código cliente: 2004-377 Nombre cliente: Manuel Pérez DNI: 36082400 Código cliente: 7833-AB Nombre cliente: Manuel Pérez NIF: 36082400-P

Etapa 1: Arquitectura de datos Modelo de datos Normas de datos Visión de alto nivel Definir duplicidades, diferencias semánticas, … Con el tiempo se llega a nivel de detalle, modelando cada elemento e identificando sus atributos En una primera versión se pueden definir sólo los datos necesarios para compartir información entre diferentes sistemas Indican definiciones comunes de los componentes de los elementos de datos: Información de nombre y dirección Campos de fecha Números de pieza Campos de moneda … Modelos de datos sistemas actuales Necesidades de Información de usuarios

Etapa 1: Arquitectura de datos Para desarrollar una planificación efectiva, la organización debe conocer claramente sus requerimientos de información a corto y largo plazo Los directivos deben definir: Cómo usan la información Dónde la consiguen Cuáles son sus objetivos Cómo toman las decisiones Cuáles son sus necesidades de datos Dos métodos habituales Matriz de análisis empresarial Factores críticos de éxito

Etapa 1: Arquitectura de datos Fuente: Laudon & Laudon, Sistemas de Información Gerencial

Etapa 1: Arquitectura de datos Contabilidad Información de entrada Facturas de proveedores Facturas a clientes Datos de proveedores Datos de clientes Información de salida Libros contables Balances/Cuentas anuales Facturación Información de entrada Presupuestos Informes de producto entregado Datos de clientes Información de salida Facturas a clientes Previsión de cobros Personal Información de entrada Datos personales Datos laborales Horas trabajadas Información de salida Carpeta de empleado Listado de pagos Expedientes de obra Información de entrada Datos de la obra Datos del cliente Plazos de entrega Presupuesto Información de salida Carpeta de expediente Presupuesto Estadísticas de presupuestos Compras Información de entrada Datos de proveedores Necesidades en materias primas Albaranes de entrega Datos de materias primas Información de salida Órdenes de pedido Informes de pedidos Pedidos pendientes Pedidos recibidos Pedidos totales Almacén Información de entrada Datos de materias primas Albaranes de entrega Información de salida Movimientos diarios de materias primas Informes de stock

Etapa 1: Arquitectura de datos Normas de datos Definición precisa de los campos de cada elemento de datos Restricciones aplicadas a los campos (intervalos de números, caracteres válidos,…) Normas de datos Datos Datos Datos Normas de datos

Etapa 2: Arquitectura lógica La estructura implica una jerarquía: todos los contactos con clientes se llevan a cabo a través del departamento de servicio al cliente Diferentes funciones controlan el contenido de la transacción Cada área principal se dividirá posteriormente en los distintos procesos A nivel de implantación, cada área formará un sistema independiente Servicio al cliente Demandas de clientes Reclamaciones Ventas Control de stocks Distribución Arquitectura lógica

Arquitectura lógica: mapa de procesos COMPRAS ALMACÉN DISEÑO PRODUCCIÓN CONTABILIDAD PERSONAL FACTURACIÓN EXPEDIENTES Facturas Proveedores Materias primas Materias primas Necesidades materias primas Necesidades Materias primas Datos obra Órdenes fabricación Presupuestos Presupuestos Facturas clientes Material fabricado Equipos trabajo Salarios CALIDAD

Arquitectura lógica: diagramas de flujo de datos (DFD)

Arquitectura lógica: diagramas de casos de uso

Arquitectura lógica: escenarios y casos de uso Caminos alternativos A2: No existen apartamentos disponibles: el sistema muestra un mensaje y solicita que se escojan otras fechas A3: … Sistema 2 - El sistema busca y muestra relación de apartamentos disponibles en esas fechas 4 – El sistema solicita los datos del cliente 6 – El sistema registra los datos del cliente y asocia la reserva con éste 7 – El caso de uso finaliza Actor 1 - El empleado introduce fecha de inicio y fin 3 – El empleado escoge un apartamento 5 – El empleado introduce los datos del cliente Flujo básico de eventos Postcondiciones : los datos de la reserva quedan registrados en el sistema de forma permanente Precondiciones : el empleado ha introducido correctamente su login y password Actores : Empleado Caso de Uso: Tramitar reserva

Arquitectura lógica: Diagramas de actividades Seleccionar Nueva venta Generar nueva venta Introducir artículo Registrar artículo Mostrar descripción y precio Mostrar total con impuestos Introducir pago Calcular cambio Generar recibo Cajero Sistema ¿Hay más artículos? Sí No

Arquitectura lógica: Diagramas de secuencia del sistema (DSS) : Sistema : Cajero crearNuevaVenta() introducirArticulo(artID, cantidad) descripción, total *[más artículos] finalizarVenta() total con impuestos realizarPago(cantidad) cambio devuelto, recibo La caja puede encerrar un área de iteración. El *[...] indica que la caja es para iterar Valor(es) de retorno asociado(s) con el mensaje anterior. Es una abstracción que ignora la presentación y el medio. La línea de retorno es opcional si no se devuelve nada. Un mensaje con parámetros. Es una abstracción que representa el evento del sistema de entrada de los datos del pago mediante algún mecanismo

Etapa 3: Arquitectura física Red ATM Sistema de televentas Sistema de pedidos B.D. de clientes B.D. de productos Cuentas de clientes Aprovisionamiento Actualización de productos

Etapa 4: Arquitectura técnica Arquitectura técnica: define el conjunto de componentes recomendado para la infraestructura TIC: Plataforma: hardware, procesamiento, memoria,… Servicios de red: transmisión de voz y datos Sistema operativo: compatibilidad, dependencia de plataforma,… Base de datos: da soporte a la arquitectura de datos Aplicaciones de red: correo electrónico, EDI, internet, intranet, software de trabajo en grupo Protocolos de comunicaciones Configuración del sistema: cliente/servidor, almacenamiento de datos en repositorio central, almacenamiento distribuido,… Aplicaciones: gran dependencia de la plataforma y el sistema operativo, problemas de cambio de cultura, coste,… Entornos de desarrollo: evitar cambios continuos Debe construirse sobre la base de las arquitecturas lógica y física

Etapa 4: Arquitectura técnica Gestión de las adquisiciones TIC: garantizar que solamente se introducen componentes recomendados Lista pública y conocida de componentes técnicos recomendados en la arquitectura técnica Gestionar adecuadamente las actividades de compra Establecer mecanismos para posibles excepciones Revisar periódicamente la arquitectura técnica para adaptarla a los cambios tecnológicos y a las necesidades de la empresa

Etapa 4: Arquitectura técnica Introducción Justificación Sistemas de sobremesa Servidores de archivos Componentes de red Protocolos de red Sistemas operativos Aplicaciones Servicios Proceso de aprobación Excepciones Autoridad Contactos Razonamiento empleado para aceptar los componentes recomendados (coste de adquisición, de mantenimiento, compatibilidad,…) Especificación técnica de PCs o estaciones de trabajo (sistema operativo, memoria, disco,…) Definición técnica de los servidores de archivos (Novell, NT, UNIX,…) Elementos de red para diferentes propósitos Protocolos de red para diferentes propósitos Sistemas operativos para las diferentes máquinas Listado de aplicaciones soportadas (por ejemplo, SPSS para cálculos estadísticos,…) Servicios disponibles (por ejemplo, acceso a Internet mediante un ISP) Relación entre la elección del componente recomendado y la aprobación del proyecto y procedimientos de compra Procedimiento de autorización de excepciones Responsable de la gestión de la política TIC Personas que actúan como fuentes técnicas Componentes técnicos recomendados

Etapa 5: Arquitectura de la documentación Necesario diseñar normas para los documentos En muchas actividades el producto más importante es un documento (contribución a un proceso más amplio o un objetivo en sí mismo) Tipo de documentación Planes de proyecto Planes de calidad Especificaciones de requisitos Documentación del diseño Acuerdos de servicio Contratos externos Manuales de usuario Documentos de discusión Formularios (por ejemplo, peticiones de cambio) Cartas e informes Adopción de una norma Ahorra tiempo para determinar estructura y diseño de los diferentes documentos Se evitan confusiones entre diferentes categorías de documentación Los usuarios se habitúan a una estructura del documento La empresa o el departamento presenta una imagen coherente

Etapa 6: Comunicación de la arquitectura Es necesario comunicar la arquitectura TIC a toda la empresa En papel o electrónicamente (página en la intranet) Presentaciones abiertas que impliquen tanto al personal técnico como a los usuarios Reducción de libertad para configuraciones propias Generación de resistencia al cambio Proyectos “insignia” como medios de implantación de la arquitectura

Actividad 4: plan de migración No es probable alcanzar el objetivo en una sola etapa Necesidad de un plan detallado de migración Puede llevar varios años, por lo que es posible que no se alcance la arquitectura física prevista: Cambios en el entorno de la empresa Cambios en las TIC Problemas en la planificación,… Representar la evolución de los sistemas en la infraestructura de las TIC “ instantáneas” de la arquitectura física en diferentes momentos Desarrollos tácticos a corto plazo

Actividad 4: plan de migración PBX PEDIDOS Red FASE 1: POSICIÓN ACTUAL Sistema de clientes mayoristas BD de productos BD de clientes Sistema de clientes minoristas BD de productos BD de clientes

Actividad 4: plan de migración PBX PEDIDOS Red FASE 2: FINAL DEL AÑO 1 PASARELA Sistema de clientes mayoristas BD de productos BD de clientes Sistema de clientes minoristas BD de productos BD de clientes

Actividad 4: plan de migración PBX Sistema de clientes mayoristas BD de productos BD de clientes PEDIDOS Red FASE 3: FINAL DEL AÑO 2 Sistema de clientes minoristas

Actividad 4: plan de migración AÑO 3: SITUACIÓN FINAL B.D. de clientes (nueva) Sistema de servicio al cliente (nuevo) B.D. de productos (nueva versión) Sistema de almacenamiento (nueva versión) Control de fabricación (nueva versión) Red ATM Actualización de productos

Actividad 4: plan de migración Desarrollo del plan de migración Dirigido por la función de las TIC en consulta con los representantes de los usuarios La línea de base debe construirse en torno a Lo que es técnicamente factible en el tiempo demandado; Los principales requisitos a satisfacer en el tiempo (presente y futuro) Las sinergias potenciales en desarrollo (v.gr., satisfacer dos requisitos a un tiempo puede ser más barato que hacerlo de forma independiente Imprescindible que sea un proceso realista Si no lo es, puede fallar la materialización de beneficios Actividad compleja, con un gran componente de iteración Sincronización con desarrollos previamente planificados Otros factores: disponibilidad de fondos

Actividad 4: plan de migración Sistema de clientes mayoristas Mayoristas (nueva versión) Sistema de clientes minoristas Minoristas (nueva versión) Pasarela Nuevo sistema de servicio al cliente Base de datos de productos Base de datos de clientes Sit. inicial Año 1 Año 2 Año 3

Actividad 4: plan de migración Reto principal del plan de migración: Aplicar cambios a la infraestructura de las TIC mientras continúa operando con la interrupción mínima para el funcionamiento de la empresa Gestión sólida del proyecto Control de cambios Apoyo de la dirección general

Actividad 5: implantación de la estrategia TIC Proceso de implantación muy complicado Considerar como proyecto cada actividad principal de la implantación Aplicación de técnicas de gestión de proyectos Examinar relaciones y dependencias entre proyectos Realizar un plan de programación con las principales etapas necesarias para la implantación de la estrategia Destacar los principales requisitos que satisface cada etapa La estrategia de las TIC Se congela como versión implantable Modificaciones aplicadas bajo el mecanismo de control de cambios

Actividad 5: implantación de la estrategia TIC Nueva red Sistema de pedidos Sistema de gestión de inventario Base de datos unificada Sistema de clientes DEPENDENCIAS ENTRE PROYECTOS TIC Implantar nueva red Desarrollar sistema de clientes y modificar sistema de pedidos Desarrollar base de datos unificada Desarrollar sistema de gestión de inventario … ETAPAS DE IMPLANTACIÓN DE LA ESTRATEGIA TIC

Actividad 5: implantación de la estrategia TIC Control de cambios Es el punto central del pensamiento estratégico durante la implantación y entrega El entorno continúa evolucionando Aparecen modificaciones de requisitos TIC Problemas en la implantación Aparición de soluciones alternativas Nuevas oportunidades tecnológicas Se producirán nuevas versiones de la estrategia Revisión y autorización previas antes de utilizarla en el plan de implantación Tratar la evolución de la estrategia y su implantación como una tarea en curso (como el mantenimiento)

Planificación de sistemas de información con Metrica3 PSI 1 Inicio del Plan de Sistemas de Información PSI 2 Definición y organización del PSI PSI 3 Estudio de información relevante PSI 4 Identificación de requisitos PSI 5 Estudio de los Sistemas de Información Actuales PSI 6 Diseño del Modelo de Sistema de Información PSI 7 Definición de la arquitectura tecnológica PSI 8 Definición del Plan de Acción PSI 9 Revisión y aprobación Secuencia de actividades del proceso PSI

Planificación de sistemas de información con Metrica3 Entradas externas Solicitud formal del PSI Estructura organizativa Información relevante Entorno tecnológico actual y estándar Requisitos del PSI Arquitectura de información Modelo de información Modelo de sistemas de información Arquitectura tecnológica Plan de Acción Plan de proyectos Plan de mantenimiento ESTUDIO DE VIABILIDAD DEL SISTEMA

Técnicas / prácticas utilizadas en las actividades del proceso PSI X X X X X X X X X Sesiones de trabajo X Presentación X Planificación X Modelo entidad/relación X Modelado de procesos de la organización X Matricial Impacto en la organización X X X Factores críticos de éxito Estimación X Diagrama de representación X X X X Diagrama de clases X X X X X Catalogación X X Análisis coste/beneficio PSI 9 PSI 8 PSI 7 PSI 6 PSI 5 PSI 4 PSI 3 PSI 2 PSI 1 ACTIVIDADES PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN

Gestión de proyectos TIC Gestión de proyectos: formular claramente los beneficios y garantizar que se alcanzan Objetivos definidos y realistas Duración limitada: estimación de tiempo Presupuesto conocido: estimación de costes Dirección del proyecto para producir el resultado deseado minimizando la utilización de recursos y permitiendo alcanzar la realización de los objetivos

Planificación del proyecto Imprescindible elaborar un plan para proyectos con duración mayor que 3-4 semanas Elementos principales de la planificación Desglose del trabajo Estimación del tiempo Dependencias entre actividades Recursos (personal y equipo necesarios, tanto internos como externos) Coste de la inversión en el proyecto Además debe reflejar Responsabilidades Acciones que aseguran la calidad y el control del proyecto Ciclo de vida del proyecto: transiciones entre etapas Desarrollo del plan del proyecto: proceso iterativo Diferentes caminos a seguir para alcanzar un objetivo Diferentes costes, riesgos y plazos

Ciclo de vida de los proyectos TIC Todos los proyectos TIC siguen un ciclo de vida Especificación de requisitos Diseño Implantación Integración Operación y mantenimiento Retirada del sistema ETAPA 1 ETAPA 2 ETAPA N

Ciclo de vida de los proyectos TIC Proceso Unificado de Desarrollo Inicio Elaboración Construcción Transición Requisitos Análisis Diseño Implementación Prueba Flujos de trabajo fundamentales Fases iter #1 iter #2 --- --- --- --- --- iter #n-1 iter #n Iteraciones una iteración en la fase de elaboración

Eventos en la gestión del proyecto Necesidad de identificar en el plan los eventos en la gestión del proyecto: reuniones y otras actividades de supervisión Hitos: un punto en el tiempo en que se alcanza un objetivo importante del proyecto Revisiones de la gestión: reuniones regulares del comité del proyecto (una vez al mes, cuando haya eventos significativos,…) Reuniones del comité de control de la configuración Revisiones de calidad Reuniones entre el jefe del proyecto y el equipo (o representantes)

Eventos en la gestión del proyecto hitos y productos a entregar información a los administradores documentos que describen el estado del software permite juzgar el proceso y actualizar costes y calendario establecimiento de hitos puntos finales de una actividad o tarea del proceso del software documentación que se presenta al administrador: informes cortos de los logros en una actividad representan el fin de una etapa lógica en el proyecto productos a entregar resultado que se entrega al cliente al final de una actividad principal del proceso (análisis, diseño,...) los productos son hitos, pero los hitos no son necesariamente productos a entregar (resultados internos utilizados por el administrador) Estudio viabilidad Especificación requerim. sistema Estudio del diseño Desarrollo prototipos Análisis de requerim. informe viabilidad requerim. usuarios informe evaluación diseño arquitectónico requerim. sistema ACTIVIDADES HITOS PRODUCTO

Plan de recursos estimación de recursos se especifica cada recurso mediante cuatro características descripción informe de disponibilidad fecha cronológica en la que se requiere el recurso tiempo durante el que será aplicado Especificar : Habilidades requeridas Disponibilidad Duración tareas. Fecha comienzo Especificar : Descripción Disponibilidad Duración del uso Fecha de distribución Personas Herramientas hardware/software Componentes software reutilizables Componentes desarrollados Componentes experimentados Componentes con experiencia parcial. Componentes nuevos RECURSOS

Estimación de costes Una planificación financiera satisfactoria depende de la identificación de todos los gastos del proyecto Esquema de estimaciones Costes de desarrollo de software basados en la extensión prevista del código Costes de desarrollo de software basados en un proceso análogo con desarrollos previos similares Costes de hardware basados en el número y tamaño aproximados de máquinas Costes de comunicación basados en cifras de tráfico aproximadas Costes de personal supuestos más allá del tiempo de vida del proyecto Estimaciones de costes de subcontratación Estimaciones de formación, viajes y otros gastos

Estimación de costes Es recomendable crear una biblioteca de diferentes escenarios de costes: Coste por usuario para PC o estaciones de trabajo (incluyendo software, conexión a red, etc). Costes por usuario para máquinas multiusuario Coste de almacenamiento en bases de datos por megabyte de datos Coste de desarrollo de diferentes tamaños de módulos de software (incluyendo pruebas, etc). Media de costes de operación por usuario Coste de enlaces de comunicaciones

Estimación de costes Los costes del ciclo de vida completo suelen olvidarse al formular los proyectos TIC Soporte de operación, incluyendo contratos de mantenimiento de hardware Fiabilidad Costes de mantenimiento de software Necesidades potenciales futuras (por ejemplo, escalabilidad) Necesidades del usuario Estos factores pueden tener importancia al escoger entre diversas opciones

Estimación de costes Costes consiguientes (o colaterales) Costes que no pertenecen propiamente al proyecto pero que son provocados por éste Mejora de la red Formación del usuario Costes de adecuación (control del entorno, mobiliario,…) Coste de aumento de la capacidad del ordenador … Costes generales Gestión del proyecto Procedimientos de garantía de calidad Formación para el proyecto Servicios de gestión de configuración Empleo de hardware Servicios burocráticos y administrativos …

Coste total de propiedad (TCO) TCO (Total Cost of Ownership) Costes de hardware Costes de software Costes de operación de TI administración del usuario, soporte del SO, malware, actualizaciones de seguridad, gestión de discos y almacenamiento, seguridad, … Costes de administración de TI Gestión de activos Financiación Formación,… Coste de las paradas de servicio Disponibilidad e impacto económico de la no disponibilidad Degradación del servicio e impacto económico de la degradación Costes de integración Costes de soporte

Estimación de costes y esfuerzo descomposición del problema en funciones a partir del ámbito del software F1 F2 Fn cálculo de las variables de estimación (LDC y/o PF) de F1 estimación coste de F1 estimación de esfuerzo de F1 cálculo de las variables de estimación (LDC y/o PF) de F2 aplicación de métricas de productividad o coste coste de F2 aplicación de métricas de productividad o coste coste de F1 coste de Fn esfuerzo de F2 esfuerzo de F1 esfuerzo de Fn estimación global del coste del proyecto estimación global del esfuerzo del proyecto estimación coste de F2 estimación de esfuerzo de F2

Estimación de costes y esfuerzo Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos. El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser. Funciones identificadas: interfaz de usuario y facilidades de control (IUFC) análisis geométrico de dos dimensiones (AG2D) análisis geométrico de tres dimensiones (AG3D) gestión de base de datos (GBD) facilidades de la interfaz gráfica (FIG) control periféricos (CP) módulos de análisis del diseño (MAD) Estimación en LDC de AG3D: optimista: 4600 más probable: 6900 pesimista: 8600 VE = (S opt + 4S m + S pes )/6 Función LDC estimada IUFC 2300 AG2D 5300 AG3D 6800 GBD 3350 FIG 4950 CP 2100 MAD 8400 Total 33200 Datos históricos : productividad media de la organización en proyectos similares: 620 LDC/pm Tarifa laboral: 8000 $ /mes Coste LDC: 13 $ descomposición de funciones métricas de proyectos anteriores Coste total proyecto: 431000 $ Esfuerzo estimado : 54 personas-mes

Medición y métricas en los proyectos TIC “ Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con números, tu conocimiento es precario y deficiente.” (Lord Kelvin) Métricas cualquier medida relacionada con un sistema, proceso o documentación de software. medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE Standard Glossary of Software Engineering, 1993) Ejemplos: métricas para calcular el tamaño del un producto en líneas de código métricas de la claridad de un párrafo en un texto escrito, por ejemplo, en un manual (índice de Fog) número de errores localizados en un producto software entregado número de personas-día necesarias para desarrollar un componente ... Se aplican a: Procesos (métricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error. Productos (métricas de predicción): complejidad ciclomática de un módulo, número de métodos y atributos asociados con los objetos de un diseño,... Permiten tomar decisiones Proceso de software Producto de software Métricas de predicción Métricas de control Decisiones administrativas

Programa del proyecto Se combinan todos los componentes básicos del plan del proyecto en un programa global Objetivo: generar un plan rentable y factible teniendo en cuenta todas las restricciones: Restricciones de tiempo Restricciones de coste Restricciones operativas Restricciones de recursos Dependencias del proyecto Herramientas gráficas: facilitan la gestión del proyecto Descripción del proyecto Descripción del proceso a medida que avanza Diversas técnicas Redes de actividades Diagramas de Gantt

Herramientas gráficas camino crítico trayectoria más larga en la red de actividad el calendario completo depende de este camino (los retrasos en estas actividades afectan a todo el proyecto) los retrasos en las demás actividades no afectan necesariamente al proyecto T1 T4 T2 INICIO M1 M3 M5 M2 T5 T8 T7 T6 T3 M4 T9 M7 FINAL T10 M6 T11 M8 T12 4/7/02 8 días 15 días 10 días 10 días 25 días 20 dias 15 días 5 días 15 días 7 días 15 días 10 días 25/7/02 25/7/02 18/7/02 14/7/02 4/8/02 25/8/02 5/9/02 11/8/02 19/9/02 RED DE ACTIVIDADES hito fuente: Ingeniería de Software , I. Sommerville, pp. 80-83 T11 (M8) 10 T12 T9 (M6) 7 T11 T5, T7 (M7) 15 T10 T3, T6 (M4) 15 T9 T4 (M5) 25 T8 T1 (M1) 20 T7 T1,T2 (M3) 5 T6 T2,T4 (M2) 10 T5 10 T4 T1 (M1) 15 T3 15 T2 8 T1 Dependencias Duración (días) Tarea

Herramientas gráficas 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 inicio final T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 M4 T9 M7 T10 M6 T11 M8 T12 DIAGRAMA DE GANTT flexibilidad en la fecha de finalización la calendarización inicial será, con toda seguridad, incorrecta. durante el desarrollo se deben comparar las estimaciones previas con las reales para revisar la calendarización del resto del proyecto. al conocer cifras reales, se debe revisar la red de actividades y reorganizar las actividades posteriores para reducir la longitud de la trayectoria crítica.

Detalle del plan El nivel de detalle de un plan de proyecto dependerá del propósito Planes esquemáticos Bocetos de planes a alto nivel que presentan las actividades principales Ofrecen una guía a grandes rasgos de la duración y estimaciones de coste Planes de trabajo Actividades principales Fechas de entrega previstas Planes detallados Dependencias entre todas las actividades Son la base de la gestión del trabajo Construcción abajo arriba: cada área genera su propio plan basado en el plan de trabajo

Plan de calidad Documentar las actividades y responsabilidades necesarias para asegurar la calidad y éxito en la entrega Verificación y validación Revisiones de calidad Control del cambio Gestión de la configuración Necesidad de recursos y habilidades Necesidades de formación Control de defectos y acciones correctoras

Contabilidad del proyecto Adopción de controles básicos al inicio y al final de los proyectos y mediante algún formulario de contabilidad del proyecto Controles básicos para gestionar la inversión del proyecto Sistema contable del proyecto Autorización del proyecto Cierre del proyecto

Sistema contable del proyecto Contabilidad del proyecto Facilita la disponibilidad de fondos para el proyecto Realiza el seguimiento de los gastos frente al presupuesto autorizado Necesidad de disponer de un método para calcular el coste de horas/persona ( cuota diaria ) diferente según las distintas categorías de personal Nómina + coste de otros beneficios (dietas, coche empresa,…) + gastos generales (formación, actualización,…) = Coste total Coste total Cuota diaria = ------------------------------------ Num. Personas x 200

PROYECTO DE ACTUALIZACIÓN DE RED LOCAL Inicio del proyecto: 1/12/2003 Nº proyecto: 1223 Jefe del proyecto: E. Barreiro 54,6 41 13,6 16 39 14 TOTAL 2,4 0,2 2,2 1 6 3 7 Verificación 8,1 7 1,1 0 4 1 6 Actualización servidor 3,1 1 2,1 1 7 2 5 Instalación de comunicaciones 4,3 2 2,3 12 1 3 4 Cableado 31,4 30 1,4 0 4 2 3 Compras de hardware 1,8 0,5 1,3 0 5 1 2 Identificación proveedores 3,5 0,3 3,2 2 12 2 1 Requisitos Total Externos Personal Construcción Técnicos Dirección Nº tarea

Autorización del proyecto Necesidad de obtener una autorización del proyecto que acuerde el compromiso para los recursos Fecha: Total: Firma: Materiales Personal TOTAL AÑO 4 AÑO 3 AÑO 2 AÑO 1 Costes: Resumen de beneficios: Número del proyecto: Fecha final prevista: Fecha inicial prevista: Jefe del proyecto: Descripción: Nombre del proyecto: Cliente del proyecto: AUTORIZACIÓN DEL PROYECTO

Cierre del proyecto Recomendable que exista un procedimiento para cerrar formalmente un proyecto Firma: Fecha: ¿Es preciso guardar el archivo del proyecto? (SI/NO) Resumen de beneficios: Devengos pendientes: Justificación de la diferencia (si existe): Variación: Coste real: Coste previsto: Fecha de terminación: Jefe del proyecto: Número del proyecto: Nombre del proyecto: INFORME DE CIERRE DEL PROYECTO

El valor de negocio de los SI El SI y su valor de negocio Los SI pueden tener diferentes valores para las empresas: Papel estratégico Supervivencia Desconocimiento empresa Tipos de beneficios Beneficios directos (productividad, rentabilidad,...) Beneficios al cliente (servicio, precios más bajos,...): la sociedad premia este valor añadido. Desde un punto de vista financiero: ¿Se produce suficiente retorno? Problemas: estimar beneficios y contabilizar costes

Modelos de coste de capital Modelos de coste de capital: Técnicas usadas para medir el valor de la inversión a largo plazo. Análisis y selección de varias propuestas. Proyectos de capital: Razones económicas: expansión de producción, reducción de costes,... Razones no económicas: control de polución, satisfacción de normativas legales y de cambios en valores. Proyectos de SI: proyectos a largo plazo Diferentes modelos: Método payback Tasa de retorno sobre la inversión Ratio coste-beneficio Valor actual neto Índice de rentabilidad Tasa interna de retorno

Modelos de coste de capital Tangibles Incrementos en productividad Costes operativos más bajos Reducciones en personal Gastos de computadores más bajos Menores costes de ventas Menores costes de oficinas Intangibles Mejor utilización de los activos Mejor control de recursos Mejor planificación organizativa Más flexibilidad organizativa Más información y más puntual Mayor aprendizaje en la organización Adecuación a normativas legales Mejora en la satisfacción de trabajadores Mejora en la toma de decisiones Mayor satisfacción de clientes Mejor imagen corporativa Hardware Telecomunicaciones Software Servicios Personal Beneficios Costes

Los SI como proyectos de capital Problemas al aplicar análisis financiero No expresan riesgo e incertezas de las estimaciones Costes y beneficios en distintos momentos de tiempo Inflación Cambios tecnológicos Cuantificación de beneficios intangibles: se potencian los sistemas transaccionales frente a los de toma de decisiones. Tiempo de vida: orientados a equipamiento de fabricación Obsolescencia SI: entre 5 y 8 años: periodo de recuperación más corto

Planificación y gestión de proyectos TIC

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Planificación y gestión de proyectos TIC (20)

Más de Enrique Barreiro (14)

Último (20)

Planificación y gestión de proyectos TIC

Notas del editor