Ciencias de la Computación (plan 1994) 2014-1

Optativas, Temas Selectos de Ingeniería de Software B

1. MEJORAS EN TODA LA EMPRESA

   GENERALMENTE ES REQUERIDO EN CARÁCTER DE URGENCIA:

   -MEJORAR EL PROCESO DE DESARROLLO DE SISTEMAS

   -migrar a arquitecturas modernas

   -explotar los avances tecnológicos

   -gestión de solicitudes de los usuarios para mejoras en el sistema

   -mejorar la capacidad de respuesta y la calidad general

   Los ejecutivos de IS con frecuencia afirman que las crisis del día a día evita que el personal de desarrollo de la entrega de nuevos sistemas estratégicos.

   Por otra parte, no existe un enfoque definido para la migración de los servicios de información masiva, el envejecimiento en las arquitecturas estratégicas y plataformas tecnológicas del mañana.

   BUSINESS DRIVEN SCENARIOS ESCENARIOS ORIENTADOS EN NEGOCIOS.

   EL ESQUEMA DE REDESARROLLO utiliza un proceso DE CUATRO ETAPAS QUE INCLUYEN: LA PLANEACIÓN CORPORATIVA DE REDESARROLLO, INVENTARIO / ANALISIS, POSICIONAMIENTO Y TRANSFORMACIÓN.

   La planificación corporativa de redesarrollo evalúa la arquitectura actual y planes a largo plazo, examina los proyectos en curso, determina una estrategia de transición gradual de los sistemas, en su conjunto, y recomienda diversos enfoques de reurbanización para aplicaciones individuales.

   Inventario / Análisis son los pasos organizacionales a través de los cuales se llevan a cabo la evaluación de las solicitudes y el proceso de planificación.

   Posicionamiento, detalles de los procesos de mejora de código que proporcionan la productividad a corto plazo y beneficios de calidad, mientras que los sistemas son preparados para ser migrados, y para su reutilización.

   Transformación, aplica la tecnología de ingeniería inversa y hacia adelante para apoyar el rediseño del sistema, re-especificación, y la regeneración.

   En conjunto, las cuatro etapas aplican la gama completa de herramientas y técnicas de reingeniería en todos los aspectos del proceso de reconstrucción.

   Concepto de Escenario: Síntomas de Conjuntos de problemas en o de las aplicaciones

   Ejemplos de Escenarios.

   1. INTEGRACION DE APLICACIONES.- Cross functional analysis e integración de sistemas stand alone. Ejemplo: Sistemas de Nómina, Seguros y Pensiones que deben de ser integrados en un Sistema de Recursos Humanos. Síntomas de este escenario pueden ser:
      • Múltiples sistemas independientes (stand alone) que pueden estar procesando datos similares redundante e ionconsistentemente.
      • Inadecuada o inexistente compartición de datos entre sistemas está limitando severamente los niveles de servicios del cliente/usuario .
      • Existen datos redundantes y procesos que se traslapan, dentro de sistemas que pertenecen a diferentes áreas y para usuarios diferentes.
      • Dado que se han tenido que crear workarounds existen varios piezas de sw disgregados que deberían estar unificadas.
      • Usuarios obtienen diferentes respuestas a una misma pregunta que se plantea en los diferentes sistemas (ejemplo: un registro de una persona, puede tener varias versiones diferentes del nombre de la persona.
      • Muy costoso el mantenimiento, dado que no hay integración. Muy costoso operar dado que son varios sistemas.
   2. REEMPLAZO DE APLICACIONES.- Es el más complejo. Comúnmente se tiende a querer ignorar las aplicaciones existentes cuando se construyen sistemas de reemplazo por ser viejas. Pero típicamente un porcentaje de datos y de procedimientos complejos representan una porción de lo que se llaman “reglas de negocio” que permanecen sin cambios en la nueva arquitectura que se pretende crear. Este escenario ayuda a descubrir y capitalizar el re-uso de aquellas porciones de sistemas que se pueden aprovechar en la creación de los nuevos. Los principales síntomas pueden ser:
      • Arquitectura actual no cumple con los requerimientos del negocio.
      • La base técnica actual es anticuada u obsoleta.
      • El usuario requiere mejoras funcionales que son difíciles, o imposibles, para añadir a la arquitectura actual.
      • Integración con nuevas aplicaciones es muy difícil o imposible.
      • El negocio ha cambiado a tal grado que los sistemas actuales ya no soportan a la organización.
   3. ESTABILIZACION DE APLICACIONES.- Es el escenario que se aplica mas comúnmente. En este se analizan las debilidades básicas en la aplicación actual, se definen los nuevos requerimientos , y se produce un plan detallado de la implementación para la actualización del actual sistema. Este escenario no considera cambios en la arquitectura. Síntomas:
      • Larga y creciente lista de nuevos requerimientos pendientes.
      • Altas tasas de fracaso del sistema o de la confiabilidad, y problemas de integridad.
      • Largos plazos de entrega delas modificaciones, pobre respuesta de las áreas de sistemas, insatisfacción del usuario.
      • Larga curva de aprendizaje, alta rotación, equipos junior, o baja moral entre el equipo de soporte.
      • Altos costos de mantenimiento que no corresponden a lo que espera el negocio como regreso.
      • Personal de mantenimiento esta trabajando en iniciativas de rediseño o re-desarrollo.
   4. MIGRACION DE APLICACIONES LEGACY A NUEVAS CODIFICACION BAJO UNA ARQUITECTURA “CLIENTE/SERVIDOR” (antes) o “CLOUD”(ahora).- Los sistemas actuales necesitan ser re-modularizados y re-hosted a un ambiente “Cloud” por ejemplo. Síntomas:
      • La Dirección está buscando la ruta de implementación más rápida bajo la nube.
      • La organización acepta la necesidad de una arquitectura de base de datos relacional en un ambiente distribuido.
   5. DATA WAREHOUSE
   6. ANALISIS DEL REPERTORIO DE APLICACIONES DE TODO UN CORPORATIVO
   7. AGREGAR GUI (GRAPHICAL USER FRONT-END) A UNO O MAS SISTEMAS
   8. ACTUALIZACIONES DE APLICACIONES COBOL
   9. CONVERSION DE LENGUAJE
   10. ASIMILACION DE PAQUETES
   11. REDOCUMENTACION
   12. CONSOLIDACION DE SISTEMAS REDUNDANTES
   13. MIGRACION A UNA BASE DE DATOS RELACIONAL

   Una vez que se identifica un escenario, una lista de requerimientos de este escenario pude ser comparada contra las necesidades de la aplicación. Y entonces esto identifica los pasos a seguir en la evaluación y en la implementación.

   Introducción y propósito del Seminario

   1. Organizaciones y estructuras típicas de las Empresas o Instituciones en donde se insertan los especialistas en Desarrollo, Implementación y Soporte Técnico de SW.

   2. Contexto general empresarial o institucional en relación al Desarrollo, Implementación y Soporte Técnico de Software.

   3. Principales Procesos y Tomadores de Decisiones de negocios en las empresas e instituciones.

   4. Principales modelos comerciales para el Desarrollo, Implementación y Soporte Técnico de SW.

   5. Cómo y quienes llevan a cabo los Procesos de Pre-venta, Venta y Post-venta de los Proyectos de Desarrollo, Implementación y Soporte Técnico de SW en la comercialización de los mismos.

2. El Marco Conceptual en la Administración de Proyectos

   1. ¿Que se conoce como Proyecto?

   2. Evaluaciones de las Oportunidades de Negocio relacionados con Proyectos

   3. Principales Tipos de Proyectos a considerar.

      • Proyectos de Desarrollo de Sistemas/Aplicaciones y de Implementación de SW

        1. Estimación

        2. Desarrollo de Propuestas

      • Proyectos de Mantenimiento

        1. Órdenes de trabajo ( apertura y cierre)

        2. Procesos involucrados con las órdenes de trabajo

        3. Tipos de Operación de Mantenimento (Tradicional y Outsourcing)

      • Proyectos de Reingeniería de Sistemas/Aplicaciones (Re-Desarrollo)

        1. Introducción

        2. Escenarios posibles

        3. Resumen de la Estructura de un Proyecto de este tipo

      • Revisiones posteriores a ser realizadas al término del proyecto

   4. ¿Que entendemos por Administrar un Proyecto?

   5. El contexto de la Administración de Proyectos

      • Las Fases de un Proyecto y su ciclo de vida

      • Las Organizaciones involucradas

      • La organización de un Proyecto

      • Todos somos vendedores

      • Definición y Responsabilidades de un Gerente de Proyecto

      • Los principales roles requeridos en la Administración de Proyectos

   6. Evaluación de la Propuesta de Servicios asociados a un Proyecto

3. Los Procesos de la Administración de Proyectos

   1. Los Procesos del Proyecto

   2. Grupos de Procesos

   3. Interacción entre los Procesos

   4. Personalización de la interacción entre Procesos

4. Las Áreas del Conocimiento de la Administración de Proyectos

   1. Principales Elementos que integran el Proyecto a ser Administrado

   2. Administración del Alcance del Proyecto

   3. Administración del Tiempo que deberá durar el Proyecto

   4. Administración de los Costos del Proyecto

   5. Administración de la Calidad del Proyecto

   6. Administración del Personal que participa en el Proyecto

   7. Administración de como debe comunicarse el Proyecto

   8. Administración de Riesgos

   9. Administración de los Insumos y Entregables requeridos por el Proyecto

5. Introducción al Proceso de Aseguramiento de la Calidad “Six Sigma” con un enfoque de Administración de Proyectos

   1. Principales conceptos a considerar

   2. Selección de Proyecto(s) a ser revisados

   3. Metodología de Mejoramiento de Procesos

      • Definición

      • Medición

      • Análisis

      • Mejora

      • Control

Bibliografía básica:

• Clifford F. Gray, Erik W. Larson, Administración de Proyectos. Mc Graw Hill, Cuarta Edición, ISBN 13: 978-970-10-7235-6, 2009.

• PMI Standards Committee. A guide to the Project Management Body of Knowledge

(PMBOK) Project Management Institute.

Material de Consulta:

• Steven J. Cohn, PMP. The ART of Project Management . Unisys Corporation Project Management Course.

• TEAMprogram. Project/Program Management Quick Reference Guide. Unisys Crporation.

• HCL James Martin, Inc. The Systems Redevelopment Methodology (TSRM) User Guide.

• NCR Six Sigma: Green Belt Course. An Introduction to Six Sigma and Green Belt Certification. NCR Corporation.