Consultoría y Asesoría

Presentación del tema: "Consultoría y Asesoría"— Transcripción de la presentación:

1 Consultoría y Asesoría
Migrando un Aplicativo Cliente/Servidor a Distribuido/WEB Consultoría y Asesoría Jose Estrada Gerente de Servicios

2 Agenda Objetivo Arquitectura Cliente/Servidor
Problemas de la Arquitectura Cliente/Servidor Aplicativo Cliente/Servidor Diseñando la nueva Solución Metodologia de RMPI bajo la Arquitectura Distribuida Aplicando la Nueva Metodología Aplicativo en entorno Distribuido

3 Objetivo

4 Objetivo Quieres llevar migrar tu Aplicativo Cliente/Servidor a WEB ? Nosotros te Ayudamos.... A continuación te mostramos cuales son los pasos para Migrar un Aplicativo en Arquitectura Cliente/Servidor a una Arquitectura Distribuida en WEB

5 Analisis de Situación Actual

6 Análisis de la Situación Actual
Arquitectura : Cliente/Servidor Arquitectura Obsoleta y no Escalable Poca/Nula Documentación de los Procesos No hay Estandares para el Desarrollo Pocos Informaticos conocen el Negocio de la Empresa Conformismo y Falta de Visión

7 Arquitectura Cliente/Servidor
Servidor de Base de Datos Cliente Vendedor / Platform-Specific API Interfaz de usuario Lógica de negocio Administracion del Sistema Administración de los datos Lógica de negocio “propietario” en procedimientos almacenados y triggers

8 Problemas con la arquitectura Cliente/Servidor
El manejo del código no particionado Volver a probar los cambios La administración de la máquina cliente El despliegue de cambio de la aplicación a los mútilples clientes La administración de la performance Deja la inversión del Hardware existente Falta de control centralizado Díficil de implementar la seguridad Cuello de bolletas en el servidor de la base de datos/por la muchas conexiones Lógica de negocio almacenada en la base de datos escrita en el lenguaje propietario No preparado para otras interfaces

9 Problemas de Seguridad en la Arquitecura Cliente/Servidor
El Driver de Conexión hacia la Base de Datos al estar instalado en el Cliente estamos expuestos a sufrir ataques indeseados por Usuarios con cierto conocimiento de Base de Datos o por intrusos ajenos a la Organización

10 Código No Particionado
El código para la Administración de la Lógica del Negocio se encuentra disperso a lo largo de la Aplicación sin ningún orden. esto hace que el mantenimiento al Aplicativo sea complejo y tedioso

11 Problemas en el Tiempo de Respuesta
En una Arquitectura C/S las conexiones son Síncronas, es decir un usuario está conectado a la Base de Datos durante el tiempo que el Aplicativo esté activo, sin un usuario abre el aplicativo y no realiza ninguna acción estará consumiendo una conexión.

12 Falta de un Control Centralizado
El desarrollador no sabe con certeza en que capa realizar los cambios o generación de nuevo Codigo La Lógica de Negocio al no estar Centralizada en un servidor de componentes se encuentra tanto en el lado del Cliente y la Base de Datos. Esto trae problemas al momento de querer cambiar reglas del Negocio; muchas veces las reglas del Negocio están repetidas Lógica del Negocio en el Cliente Lógica de Negocio en la Base de Datos

13 Gastos en el Hardware del Cliente
Cada vez se le aumenta más Lógica del Negocio al Cliente, requiriendo cada vez un Hardware más Robusto Cada vez que Incremente más Lógica del Negocio en el Cliente, este requerirá de un Hardware más Robusto

14 No está Preparado para Escalar
Lógica del Negocio Dispersa sin control : La logica al no estar centralizada no podra ser Reusada por otras aplicaciones y con ello se estara redundando el mismo codigo en diferente aplicaciones Arquitectura Aislada : Esta Arquitectura NO nos permite comunicarnos con otras Plataformas que trabajan bajo WebServices y estan orientadas a la Arquitectura SOA Arquitectura Obsoleta : Esta Arquitectura tiende a desaparecer por la misma necesidad de la empresa de entrar a un mundo mas globalizado y cada vez mas competitivo Desktop C/S

15 Poca/Nula Documentación del Sistema
Muchas veces por la Premura de entregar resultados se omite un paso muy importante dentro del proyecto : La documentación de los Procesos y el Modelamiento. La documentación es la sustentación técnica del Proyecto, esto sirve de mucha ayuda cuando un nuevo integrante quiere conocer cuales son los procesos y los Flujos Internos que sigue el mismo o se desea hacer un rediseño. No hay Documentación de los Procesos X El desarrollador muchas veces tiene que explorar entre cientos de líneas de código para entender que hace el Programa, se pierden Horas/Hombre.

16 Falta de Estandares en el Desarrollo
No hay un estandar unico para la codificación tanto a lado del cliente y del Servidor de Base de Datos , por la falta de control cada Desarrollador a escrito el código de acuerdo a su criterio, esto trae consigo un gran desorden y en muchas casos el código es poco entendible al momento de realizar tareas de Mantenimiento

17 Pocos Informaticos conocen el Negocio
Un Problema que hemos detectado es que muchos informaticos NO conocen el negocio de la empresa, esto es debido a que la mayoria se preocupa por labores netamente de programación pero pocos hacen enfasis en el dominio del conocimiento del negocio que es en muchos casos lo que deseamos automatizar

18 Conformismo y Falta de Visión
Un Problema frecuente es el conformismo, la idea de que “Nunca voy a necesitar cambiar mi Arquitectura...si todo funciona bien” se viene abajo cuando hay que compartir informacion en linea con aplicaciones externas via WebServices por ejemplo o cuando debemos generar una interfaz WEB de nuestra aplicación .... Que haremos.....? Pues reescribir todo la Logica del Negocio, la Falta de visión a largo plazo genera un caos cuando el Aplicativo C/S tiene que escalar a otras plataformas, esto en muchos casos puede costar el puesto de Trabajo a los lideres del Area Informatica. Que el avanze Tecnologico no te tome de sorpresa, en Techera dictamos cursos de PowerBuilder Distribuido y WEB.... Te esperamos

19 Cuales son los Pasos para migrar mi Aplicativo a Distribuido-WEB ?

20 Diseñando la nueva Solución
La experiencia nos ha enseñado que los Proyectos deben contener Las siguientes etapas : Redacción del Plan de Proyecto Explicación de la Nueva Arquitectura Metodología de Desarrollo a Cinco Capas Análisis y Modelamiento del Aplicativo Diseño de los Prototipos Separando las Tareas antes del Desarrollo Generación de Código Pruebas Unitarias Pruebas Integrales / Casos de Prueba Preparación de los Manuales del Sistema, Usuario y Guía de Operación Transferencia Tecnológica del Proyecto al Reponsable del Area

21 Redacción del Plan de Proyecto
El Plan de Proyecto contiene en forma general cuales seran las etapas para la generación del nuevo Aplicativo El Plan de Proyecto es casi como un acuerdo Previo de Las tareas a realizar ; este documento lo revisa el Area Informatica para dar su consentimiento, este documento contiene : Objetivos Funciones principales Tiempos Estimados Estándares propuestos Documentos de gestión de Riesgos Metodología

22 Gestión de Riesgos durante el Proyecto
El documento de Gestión de Riesgos nos permite planificar todos los posibles eventos que pueden suceder a lo largo del Proyecto. Este documento también nos indica como haremos para mitigar las incidencias. Riesgos del Proyecto El Lider del Proyecto debera mitigar los Riesgos, evitando que estos afecten el éxito del proyecto

23 Explicación de la Nueva Arquitectura
Servidor de base de datos Servidor de Aplicaciones Cliente Lógica de negocio Cache de Conexiones Manejo de las transacciones Transparencia de los datos a los usuarios Balanceo de carga Administración de los datos Interfaz de usuario Alguna lógica de negocio (reducida) Características de la arquitectura Multitier número imprevisible de clientes/transacciones Aplicaciones abiertas a la Internet/extranet Principios de la arquitectura Multitier Encapsula o particiona la lógica de negocio en objetos. Mueve o distribuye la lógica de negocio a una máquina dedicada. Proporciona acceso a los objetos almacenados en un servidor de aplicaciones. El servidor de aplicaciones recibe los requerimientos de procesos desde los clientes. El servidor direcciona los requerimientos a los objetos de negocio para procesar. Ejemplos: Lógica de Negocio: autorización de tarjeta de crédito, carga de impuestos Cache de datos estáticos: Estados, partes/productos Servicios para recursos especializados: Gateway para mainframe/fax server

24 Ventajas y Desventajas
Cientes “más delgados” Disminuye la administración del cliente Encapsulación de la lógica Mejor perfomance Escalabilidad Consistencia, control y seguridad Reutilización de componentes existentes Posicionamiento para la Web Desventajas Cambios en los hábitos de programación Más curvas de aprendizaje

25 Herramientas a Usar Las siguientes son las Herramientas a usar para la Generación del nuevo Aplicativo con Interfaz WEB y bajo la Arquitectura Distribuida : Lenguaje de Programación – Componentes : PowerBuilder v.10.0 Lenguaje de Programación – JSP,Servlets, Struts: NetBeans v.3.5 Modelamiento de Procesos, Negocios, Clases: PowerDesigner v.11.0 Servidor de Aplicaciones (Componentes,Web): EAServer v.5.2 Diseño de Hojas de Estilos, Gráficos : DreamWeaver Redacción de Documentos : MS-Office

26 Las Aplicaciones Web Fácil para Usar Rápido acceso a la información
Contenido personalizado de acuerdo a los parámetros de los usuarios

27 Las Aplicaciones Web Perspectivas de los Clientes Reportes en línea
Información las 24 horas del día los 7 días de la semana Información Segura Poder exportar e importar los datos

28 Las Aplicaciones Web Porqué de las Aplicaciones Web?
Información en Línea Información las 24 horas del día Consulta de Servicios Web Independencia de Configuración de equipos clientes Clientes delgados Preparados para crecimientos de las empresas Información Electrónica

29 Las Aplicaciones Web Cómo Trabajan las Aplicaciones Web
El navegador puede considerarse como una interfaz de usuario universal. Dentro de sus funciones están la petición de las páginas Web, la representación adecuada de sus contenidos y la gestión de los posibles errores que se puedan producir. Para todo esto, los fabricantes de navegadores les han dotado de posibilidades de ejecución de programas de tipo script, con modelos de objetos que permiten manipular los contenidos de los documentos.

30 Las Aplicaciones Web Como es el flujo de información

31 Beneficios de las Aplicaciones Web
Globalización de los Servicios Integración de los Servicios Integración con Arquitecturas Móviles Escalabilidad

32 Beneficios de las Aplicaciones Web
Globalización de los Servicios Tener la información preparada para cualquier parte del mundo Soporte de todos los mecanismos de control Integración con otras plataformas Soporte de Tecnologías XML Soporte de Tecnologías Web Services Integración de Servicios Permite poder integrarse con diferentes servicios Web Informar a los clientes en Línea Generar reportes actualizados

33 Beneficios de las Aplicaciones Web
Integración con Móviles y Wireless Extender la funcionalidad para poder interactuar con clientes móviles: Acceder a través internet móvil Acceso Wireless desde équipos móviles Escalabilidad Las Aplicaciones Web, pueden escalar de acuerdo a las necesidades que se van generando, por estar basados sobre una tecnología Orientada a Objetos. Trabajan con las últimas tecnologías del mercado, las cuales les permite soportar los cambios. Trabajan sobre diferentes arquitecturas y esto es lo que les permite poder escalar a otras plataformas.

34 Seguridad en las Aplicaciones Web
Seguridad con Certificados Digitales Se realiza a través de Certificados quienes podrán validar el acceso a Través de claves públicas y privadas Seguridad a nivel Sistema Operativo Se realiza mediantes los usuarios que se tienen establecidos en las redes de las empresas Seguridad a través de Perfiles Son definidos perfiles para que los usuarios puedan acceder a los sitios web

35 Metología de Desarrollo a cinco Capas usando RMPI
Esta arquitectura separa y organiza las tareas del Proyecto, haciendo que las personas se puedan especializar en una determinada Capa. Esta arquitectura hace énfasis en la separación de las reglas del negocio de la empresa con la Interfaz para una correcta organización del software, se Divide en cinco capas : Capa de Presentación Capa de Aplicación Capa de Negocio Capa de Persistencia Capa de Datos

36 Metología de Desarrollo a cinco Capas
Capa de Presentacion (Paginas) Capa de Aplicación (Servlets) RMPI Capa de Negocios (Componentes) Capa de Datos (Tablas) Capa de Persistencia (Componentes)

37 Beneficios de Trabajar en esta Arquitectura
Análisis y Documentación por Cada Capa Eficiente organización y distribución de los objetos por cada capa Cada capa es modelada bajo UML usando PowerDesigner Alta Reusabilidad de los Objetos en cualquiera de las Capas. Especialización del Personal en alguna de las capas Fácil y optima comunicación entre las diferentes capas  Centralización de la Lógica del Negocio  Rápido diagnóstico de Errores y corrección de los mismos Preparados para escalar a la Arquitectura de SOA

38 UML (Lenguaje Unificado de Modelamiento)
UML es un lenguaje estándar para crear planos de software. No es un lenguaje de programación. Sin embargo permite hacer una rápida transición del modelo al código. Es una herramienta de la ingeniería de software.

39 ¿Por qué utilizar UML? Porque recoge lo mejor de diferentes sistemas de modelamiento. Porque es adaptable a casi cualquier sistema. Porque puede ser utilizado en la mayoría de fases de un proyecto. ¿Qué ventajas trae esto?...

40 UML en un proyecto UML dispone de herramientas que pueden ser utilizadas en la mayoría de fases de un proyecto de ingeniería de software. Esto permite tener información consistente en cada fase. CADA MODELO HACE REFERENCIA A OTROS MODELOS.

41 Análisis y Modelamiento del Aplicativo
Los Diagramas usados en el Modelamiento para el Proyecto Son : Modelo de Negocios Diagrama de Casos de Uso Diagrama de Actividades Diagrama de Clases General Diagrama de Clases por cada Capa Diagrama de Secuencia Diagrama de Base de Datos Diagrama de Casos de uso Diagrama de Clases general Diagrama de Secuencia Diagramas usados dentro de la Metología de cinco Capas Modelo de Negocios Diagrama de Actividades Diagrama de Clases por cada Capa Diagrama de Base de Datos

42 Análisis y Modelamiento del Aplicativo – Modelo de Negocios
Hacer un Análisis de los procesos principales del sistema actual y en función a esto generar el Modelo de Negocios del Sistema, este Modelo muestra como interactúan las diferentes unidades organizacionales que hacen uso del Sistema.

43 Análisis y Modelamiento del Aplicativo – Diagrama de Actividades
El Diagrama de actividades Muestra el Flujo en los procesos Principales, esto nos permite ver como fluye la Información.

44 Análisis y Modelamiento del Aplicativo- Diagrama de Caso de Uso
El Diagrama de Casos de Uso nos permite describir la acción desde el punto de vista del Usuario, esta es una técnica de aciertos y errores hasta llegar a entender lo que el Usuario desea

45 Análisis y Modelamiento del Aplicativo- Diagrama de Clases
El Diagrama de clases muestra las diferentes entidades y como se interrelacionan una con otras.

46 Análisis y Modelamiento del Aplicativo- Diagrama de Secuencia
El Diagrama de secuencia Muestra el fjujo de información entre los Objetos de las Diferentes capas, nótese que bajo nuestra Metología se respeta el número de Capas.

47 Análisis y Modelamiento del Aplicativo- Modelo de Datos
El Modelo de Base de Datos muestra las Entidades que formaran parte de nuestro nuevo Modelo de Datos, este Modelo ha sido generado a partir del Diagrama de Clases.

48 Preparando los Prototipos
El Usuario debe validar si el Prototipo se ajusta a sus Requerimientos, en este punto la interacción con el usuario es alta, la idea es que el usuario sienta que el Aplicativo que se desarrolla se ajusta a su necesidades. Antes de comenzar el desarrollo se preparan los Prototipos para validarlos con el usuario; es muy importante que el usuario participe en las diferentes etapas del Proyecto para que el haga suyo el Proyecto y se sienta comprometido con el éxito del mismo. Una vez hecha las correcciones y teniendo la conformidad del usuario continuamos con el Desarrollo.

49 Separación de Tareas Antes de distribuir la carga de
Trabajo es importante conocer la Fortaleza de cada integrante del equipo de Desarrollo; el éxito del proyecto esta en descubrir las habilidades y destrezas de cada Integrante para realizar una correcta distribución de Trabajo. El Líder o Jefe de Proyecto debe asignar las Tareas de acuerdo a las Habilidades

50 Generación de Código – Agregando Operaciones
Desde PowerDesigner registramos las operaciones o métodos por cada Clase.

51 Generación de Código El PowerDesigner nos permite la Generación del código hacia PowerBuilder. Opción para generar código hacia PowerBuilder

52 Generación de Código – Paginas Dinamicas(JSP)
Se ingresa el código Java en las paginas Dinámicas: JSP. Donde se necesite hacer uso de la Lógica del Negocio accesamos a los componentes que residen en el EAServer.

53 Generación de Código – Escribiendo el código
Usando el PowerBuilder escribimos la Logica del Negocio en los componentes.

54 Generación de Código – Manejador de Componentes
El EAServer Manager nos permite una rápida y fácil Administración de los componentes registrados en el EAServer; recordemos que el EAServer es un Servidor de Aplicaciones certificado para la Arquitectura J2EE Componentes en el EAServer

55 Pruebas Unitarias Por cada opción terminada es recomendable realizar
el Testeo, se prueba la funcionalidad de la opción asi como El output resultante de esta prueba. Si el Desarrollador encuentra algun error procederá a Solucionarlo.

56 Pruebas Integrales – Casos de Prueba
Techera tiene su propia Metodología para el Testing Del Producto Desarrollado : Redactar al menos 25 casos de prueba Probar el aplicativo haciendo uso de los casos de prueba Revisar las fuentes del aplicativo con respecto a los estándares Revisar que el aplicativo cumpla la funcionalidad y tiempo de respuesta requeridos Revisión de posibles errores con su respectiva consecuencia Estimar tiempo de solución de errores o problemas en general encontrados al momento de realizar el testing Testear el Aplicativo hasta que se certifique su Total Calidad

57 Pruebas Integrales – Casos de Prueba
Los Casos de prueba son Importantes por que nos permiten probar los procesos principales del aplicativo, además de ser un documento para que nos permite certificar la calidad del Producto.

58 Manual de Usuario El Manual de Usuario es la guía para la persona que operará el Sistema, se describen las diferentes opciones del pplicativo paso a paso. Explicación por cada opción El Manual de usuario es entregado a los Usuarios del Aplicativo

59 Manual de Sistema El Manual del sistema contiene el plano arquitectónico del Sistema : Diagramas de UML -Análisis por Cada Capa -Casos de Prueba -Gestión de Riesgos -Modelo de Datos -Diccionario de Componentes y Datos Contiene el Plano Arquitectónico del Sistema El Manual del Sistema es entregado al Area Informática

60 Guia de Operación La Guía de Operación contiene los pasos a seguir en caso de necesitar volver a reinstalar todo el Aplicativo WEB, Componentes incluyendo la Base de Datos en otro Servidor. Guia rapida para Instalar al Aplicativo La Guia de Operación es entregado al Area Informática

61 Transferencia de Conocimientos
A Lo largo del proyecto el equipo de Techera va transfiriendo conocimiento al area Informática sobre la nueva Arquitectura , lo interesante de esta forma de trabajar es que el área Informática al final del Proyecto esta lo suficientemente capacitada como para asumir el Mantenimiento del Proyecto.

62 Clientes – Caso de Éxito

63 Caso de Éxito – Grupo Nuevo Mundo
Desarrollo de un Sistema Cotizador por Web para Pasajes, Hoteles y Tours sobre los distintos lugares del Mundo El Proyecto duró 3 Meses Se utilizó la tecnología Web basado sobre la Arquitectura de N-capas Herramientas Utilizadas: PowerBuilder PowerDesigner EAServer Adaptiver Server Enterprise (Base de datos) NetBeans DreamWever

64 Caso de Éxito – Yoli Coca Cola de México
Acapulco una linda ciudad ubicada al sur de México, fue el lugar donde TechEra pudo impartir una capacitación intensiva a la Empresa Coca Cola, esto se inició el 15 de Junio y concluyó el 28 de Junio, alcanzando todos los objetivos trazados, ambas partes dieron todo de sí, el personal de Coca Cola altamente preparados en el uso de PowerBuilder pudo recibir un entrenamiento sobre las Nuevas Arquitecturas de PowerBuilder y pudo apreciar que tan Robusto es PowerBuilder para las Aplicaciones Web y Móvil.

65 Clientes Contamos con clientes en los Diferentes Rubros, quienes ahora son nuestros socios estratégicos. Apuntamos a tener casos de Éxito y tomamos los proyectos de una forma personalizada. Mavila Hnos Innpares Fundición del Callao Licsa Paramonga Conservera Garrido Caja Rural Prymera Caja Rural Cruz de Chalpon

66 Importante Recordar… TechEra será parte de tu Negocio
Soluciones a medida y con nuevas tecnologías Empresa Nueva, con Nuevas Ideas

67 Otros Servicios TechEra, también ayuda a la difusión de la tecnología con material educativo Contamos con Libros y Revistas, escritas pro nuestros consultores Organizamos Eventos y participamos de las Conferencias de Tecnologías Compartimos conocimientos con los Especialista de otros países Tenemos en planes la edición de otros libros y artículos Nuestros profesionales siempre participan de los Foros de las Comunidades de Tecnología