Entregable V. Juan Pablo Mejía Wagner AMENAZAS Y VULNERABILIDADES DE LA IMPLEMENTACIÓN DE UN SOFTWARE

Transcripción

1 2009 Entregable V Juan Pablo Mejía Wagner AMENAZAS Y VULNERABILIDADES DE LA IMPLEMENTACIÓN DE UN SOFTWARE

2 Tabla de contenido 1. Aseguramiento de Calidad Administración de riesgos[2] Problemas en la Implementación[5] Referencias Bibliografía... 9

3 Entregable 5 Objetivo específico: Investigar e identificar amenazas y vulnerabilidades que se presentan en la implementación de e-scm para analizar cómo intervienen en la cadena de valor del negocio. Actividades: Análisis de amenazas y vulnerabilidades de la implementación de un software. Amenazas y vulnerabilidades de la implementación de un software. 1. Aseguramiento de Calidad El aseguramiento de calidad es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfaga los requisitos dados de calidad, entre estas actividades encontramos: Mecanismos de reportes de monitoreo de tareas. Análisis de riesgos. Efectividad y diseño del plan de contingencia. Gestión de cambios. Construcción de estándares de calidad. Definición de métricas. Plan de gerencia de la calidad del software. Gerencia de calidad del software. Implementación del modelo de reportes. Creación de las pruebas de datos. Documentación de operación. Planes de integración. Mejora de la integración. Asistencia técnica y consultoría. Registro de control de soporte. Revisión del ciclo de vida. Plan de verificación y validación. Ejecución de tareas de verificación y validación. Recolección y análisis de datos métricos. Plan de pruebas.

4 Desarrollo de pruebas de requerimientos. Ejecución de las pruebas. Plan de gerencia de la configuración. Desarrollo de la identificación de la configuración. Mejora de la configuración de control. Plan de la documentación Implementación de la documentación. Producción y distribución de la documentación. Plan de entrenamiento 2. Administración de riesgos[2] Un riesgo es la probabilidad de ocurrencia de un evento adverso para el proyecto. La administración de riesgos es el proceso continuo basado en el conocimiento, evaluación, manejo de los riesgos y sus impactos que mejora la toma de decisiones organizacionales. La administración de riesgos se guía como un conjunto de pasos secuenciales, lógicos y sistemáticos que se deben seguir para identificar, valorar y manejar los riesgos asociados a los procesos de la organización, los cuales ejecutados en forma organizada le permiten encontrar soluciones reales a los riesgos detectados minimizando las pérdidas o maximizando las oportunidades. Algunos riesgos que podemos encontrar son: Riesgos relativos a la planificación, control y seguimiento del proyecto 1. Planificación demasiado optimista. 2. La planificación omite actividades necesarias o las subestima. Esto suele ocurrir con frecuencia en relación a la documentación (en particular el tiempo necesario para integrar escritos, validar (testing) código, depurar código y sincronizar artefactos. 3. Las tareas no se distribuyen equitativamente entre los miembros del equipo. 4. El esfuerzo es mayor que el estimado. Esto frecuentemente ocurre durante el diseño e implementación de aspectos desconocidos, dominados a medio o especificados en forma superficial. 5. Se saltan pasos del proceso de desarrollo, se ignoran artefactos previos relevantes o se elaboran artefactos para "salir del paso". 6. Escatimar en calidad. 7. La revisión del gerente es más lenta de lo esperado. 8. Se pierde mucho tiempo en reuniones. 9. El equipo no hace seguimiento a sus tareas y/o plan de actividades. 10. No se hace seguimiento a los riesgos. Riesgos relativos a requerimientos y relación con el cliente

5 1. Cambios en los requerimientos (también denominado volatilidad de requerimientos). 2. Requerimientos demasiado ambiciosos para el tiempo disponible. 3. Expectativas irreales del cliente. A veces, los mismos desarrolladores son culpables de estimular una inflación de expectativas en el cliente. 4. Al cliente se le consulta demasiado tarde y éste no le gusta o no le sirve el producto por lo que hay que volver a diseñar el producto. Riesgos relativos al diseño e implementación 1. En medio de la implementación encontrarse con que el diseño es demasiado sencillo y hay que volver a hacerlo. 2. Un diseño demasiado complejo que exige tomar en cuenta complicaciones innecesarias e improductivas. 3. No se especifican claramente las interfaces entre los componentes software. 4. Se desarrollan funciones innecesarias. 5. El trabajo con un entorno software desconocido causa problemas imprevistos. 6. El diseño no separa claramente las capas o la implementación no respeta esa separación. Riesgos respecto al uso de herramientas y bibliotecas de código 1. Las herramientas de desarrollo o los componentes externos de software no están disponibles en el momento deseado. 2. La curva de aprendizaje para la nueva herramienta o para componentes externos de software es más larga de lo esperado. 3. Se adopta una herramienta por estar de moda y los costos de adoptarla en la mitad del desarrollo de un proyecto sobrepasen los beneficios de utilizarla. También puede denominarse ilusión por una panacea. 4. Se decide desarrollar una herramienta propia sin medir los costos de hacerlo. 5. No se puede implementar la funcionalidad deseada con el lenguaje o bibliotecas utilizados: hay que adoptar otras bibliotecas o desarrollar una propia. 6. Las bibliotecas son de baja calidad y obligan a crear trabajo adicional para evitar los defectos de las bibliotecas. Riesgos relativos al equipo 1. El equipo se desmoraliza, bien sea por la situación interna del equipo, por los comentarios externos de los gerentes, por la lentitud de su avance o por la tasa de defectos que encuentra. 2. Los miembros del equipo no logran trabajar bien juntos. 3. Problemas de comunicación entre los miembros del equipo. 4. Los coordinadores no delegan algunas de sus funciones y se convierten en cuellos de botella.

6 5. Algún miembro no cumple con sus tareas. 6. No se consultan decisiones claves sino que se imponen. 7. Faltan personas con habilidades específicas. 8. Algunos de los miembros del equipo no se sienten comprometidos con el desarrollo. 9. Se forma uno o más cliques en el equipo. 10. El equipo no confía en uno de sus miembros. 11. Algunos de los miembros del equipo no aportan sus ideas u opiniones al equipo. 12. Se toman decisiones que nadie cumple. 13. El equipo diluye sus diferencias en vez de resolverlas. 14. Un miembro del equipo sólo quiere realizar tareas que le gustan. 3. Problemas en la Implementación[5] El Gartner Group afirma que, un 65% de los proyectos de implementación de CRM fallan, mientras que Kolsky (2004) dice que el 55% de las veces fallan, y navarro se extiende también dando explicaciones, revisando los procesos y la forma como se implementa un SCM podemos evaluar y extraer las siguientes razones: Tecnología que se enlaza con procesos erróneos del negocio. Falta de análisis de los procesos de negocio y su adaptación a las nuevas tecnologías. (se puede apoyar con la ayuda con análisis de la cadena de valor) Centrarse en la compra de la tecnología para apoyar la iniciativa específica del negocio. Se deben centrar los recursos en la totalidad de la implementación de la solución para que se integren procesos, tecnología y personal, para que funcione como un sistema. Falta de administración de cambios, cambios de comportamiento y de procesos, falta de evaluaciones y seguimientos de impacto en la implementación. Hay que tener en cuenta que la tecnología sólo tiene sentido tras tener perfectamente definidos los objetivos de negocio. Falta de apoyo por parte de la dirección, debido a la falta de conocimiento de las oportunidades que la solución ofrece. No existe "pasión por el cliente", en la cultura de la organización. Retorno de la inversión poco claro, debido a que no es un sector maduro y existe un desconocimiento generalizado sobre su ROI. Falta de visión y estrategia, es un problema habitual no tener una estrategia claramente definida y, por tanto, unos objetivos de negocio medibles en los procesos que afecta. Además, el problema se

7 incrementa cuando no existe una correcta asignación de recursos y una correcta metodología para el desarrollo del proyecto. No redefinir los procesos, al igual que en otro tipo de proyectos tecnológicos.

8 4. Referencias [1] CAO Bin, YE Qiang, B2C E-Commerce's Customer Relationship Management Based on the Long Tail, School of Management, Harbin Institute of Technology, [2] DeLima Marsh, %20Marsh%20Sept%201% pdf, 28 de marzo de [3] Universidad Simón Bolivar, 1 de mayo de [4] Qualitrain, 22 de agosto de [5]

9 5. Bibliografía [1] Ravi Kalakota & Marcia Robinson E-Business Roadmap for Success (Addison-Wesley 1999)). [2] Wood, Daniel, SAP SCM applications and modeling for supply chain management (with BW primer), John Wiley & Sons, [3] Juan Fernando Zuluaga, Diferencias de SEO para B2C y B2B, [4] B2B, el modelo exitoso para la nueva economía., [5] Centro Europeo de Empresas e Innovación de Navarra, Guía informativa del negocio entre empresas que se desarrolla a través de Internet., [6]