UNIVERSIDAD SANTO TOMA VICERECTORIA DE UNIVERSIDAD A DISTANCIA FACULTAD DE EDUCACION FACULTAD DE CIENCIA Y TECNOLOGIAS PROYECTO DE INVESTIGACIÓN: ALFABETIZACIÓN CIENTÍFICA Y TECNOLÓGICA EN LAS INSTITUCIONES EDUCATIVAS DE BÁSICA Y MEDIA Y EL DESARROLLO DE PENSAMIENTO CRÍTICO, LÓGICO Y MATEMÁTICO COMO FACTOR GENERADOR DE UNA INDUSTRIA DE SOFTWARE EN COLOMBIA ARTICULO: ESTADO DEL ARTE EN INGENIERIA DE SOFTWARE DESDE UNA MIRADA ACADEMICA MARIO DUSTANO CONTRERAS CASTRO PROGRAMA INGENIERIA EN INFORMATICA BOGOTA, JULIO DE 2017 1 ANTECEDENTE. FASES DE UN PROYECTO SOFTWARE Hacia el interior del programa de Ingeniería en Informática de la Facultad de Ciencias y Tecnologías de la VUAD de la Universidad Santo Tomás se sitúa al estudiante en un entorno informático, para que él mismo, inicie un proyecto en un sistema informático en cuanto a: propuesta, mantenimiento, mejoramiento en un Proyecto Software, Software Educativo, Sistema Telemático. Intervención de un Estudiante en un Proyecto Software Figura 1. Fases de un Proyecto Informático (Proyecto Software). Fuente Propia 2 Figura 2. Modelado del Negocio. Fuente Propia Figura 3. Ingeniería del Proyecto Modelo Análisis Orientado a Objetos. Fuente Propia 3 Figura 4. Ingeniería del Proyecto Modelo Análisis Estructurado. Fuente Propia Notas Aclaratoria Primera Nota. Las referencias son datos propiciados por terceros que faciliten la información sobre un hecho o investigación realizada, el termino referencia describe el proceso por el cual se menciona o se señala (que es lo mismo decir “se refiere”) a algún objeto o persona, es decir, son las informaciones que permiten adquirir conocimientos una determinada cuestión de interés personas, empleos, lugares, métodos, etc. Segunda Nota. Las gráficas de Google Trends representan con cuánta frecuencia se realiza una búsqueda de un término particular en varias regiones del mundo y en varios idiomas. El eje horizontal de la gráfica representa el tiempo (desde algún momento de 2004), y el eje vertical representa la frecuencia con la que se ha buscado el término globalmente. Tercera Nota. Un Modelo es un prototipo que sirve de referencia y ejemplo para todos los que diseñan y confeccionan productos de la misma naturaleza. Cuarta Nota. Como metodología se denomina la serie de métodos y técnicas de rigor científico que se aplican sistemáticamente durante un proceso de investigación para alcanzar un resultado teóricamente válido. En este sentido, la Metodología es el conjunto de métodos, conceptos o procedimientos basados en principios lógicos para alcanzar un objetivo Quinta Nota. Para las Fases de Análisis y Diseño se hace uso de metodologías porque se requiere de métodos, conceptos o procedimientos como diagramas, descripciones, diccionarios de datos e inclusive modelos de datos en un rigor u orden determinado. 4 REFERENTES DESDE 1970 HASTA 2017 PRIMER REFERENTE. SISTEMA DE INFORMACIÓN Referente:http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1024-94352009001100006 Un Sistema de Información(SI) es un conjunto formal de procesos que, operando sobre una colección de datos e información estructurados según las necesidades de la organización, recopilan, elaboran y distribuyen la información (o parte de ella) necesaria para las operaciones, las actividades de dirección y la toma de decisiones. Actualmente, los SI se enfrentan a dos retos fundamentales. En primer lugar, su diseño, desarrollo e implementación son procesos que confluyen en diferentes contextos, con distintos puntos de vista y suposiciones acerca de determinado dominio. Esto provoca problemas de comunicación por falta de entendimiento compartido y por la complejidad de la realidad. En segundo lugar, las representaciones en los SI deben corresponderse, lo más estrechamente posible, con la realidad y los procesos que ellos representan para que finalmente cumplan con los objetivos diseñados. Las cuatro principales funciones del SI son: • Recolección de la información: es la actividad de registrar o captar información para que pueda utilizarse con posterioridad. • Acopio o acumulación: consiste en la agrupación de la información recogida en lugares y momentos diferentes. • Tratamiento de la información: en él se pueden distinguir tres operaciones fundamentales: de ordenamiento, de cálculo aritmético-lógico y de transferencia de información. Una vez transformada la información, ella debe cumplir con una serie de requisitos de los cuales los más relevantes son: claridad, precisión, ser oportuna, directamente utilizable, coordinada, completa, jerarquizada, sintética y necesaria. • Difusión de la información: el problema de la difusión consiste en dar respuesta a tres preguntas fundamentales: cómo, cuándo y a quién. Los SI cumplirán tres objetivos básicos en las organizaciones: 1. Automatización de procesos operativos. 2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones. 3. Lograr ventajas competitivas por medio de su implantación y uso. Los Sistemas de Información pueden ser: Sistemas transaccionales. Sistemas de apoyo de las decisiones. Sistemas de Gestión de Información (SGI). Figura 5. Interés Mundial por Sistemas de Información. Fuente. https://www.google.es/trends 5 SEGUNDO REFERENTE. METODOLOGÍAS PARA DESARROLLO DE SOFTWARE Referente: ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. Si se toma como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, se puede clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una de estas categorías de metodologías. Metodologías Estructuradas Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE1 (Francia), MÉTRICA2 (España), SSADM3 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson4, Ward & Mellor5, Yourdon & DeMarco6 e Information Engineering7. Figura 6. Interés Mundial por Metodologías Estructuradas Fuente. https://www.google.es/trends 1 http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002) http://www.map.es/csi/metrica3/ (7.5.2003) 3 http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003) 4 http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003) 5 http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003) 6 http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003) 7 http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003) 2 6 Metodologías de Análisis y Diseño Orientadas a Objetos Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java8 o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML) 9, la notación OO más popular en la actualidad. Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP)10, OPEN11, MÉTRICA (que también soporta la notación estructurada). Figura 7. Interés Mundial por Metodologías de Análisis y Diseño Orientada a Objetos Fuente. https://www.google.es/trends Metodologías tradicionales (no ágiles) Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil. Figura 8. Interés Mundial por Metodologías Tradicionales (no ágiles). Fuente. https://www.google.es/trends 8 http://java.sun.com/ (7.5.2003) http://www.uml.org/ (7.5.2003) 10 http://www.rational.com/products/rup/index.jsp (7.5.2003) 11 http://www.open.org.au/ (17.9.2003) 9 7 Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Figura 9. Interés Mundial por Metodologías Agiles. Fuente. https://www.google.es/trends 8 Entre las metodologías ágiles identificadas se destacan: 1. Extreme Programming (XP). Figura 10. Metodología Programación Extrema XP. Fuente. https://www.mindmeister.com/es/258146343/metodolog-a-programaci-n-extrema-xp Figura 11. Interés Mundial por Metodología XP. Fuente. https://www.google.es/trends 9 2. Metodología Scrum. Referente. https://proyectosagiles.org/que-es-scrum/ Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Un proyecto con Scrum se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. Figura 12. Metodología SCRUM. Fuente. https://proyectosagiles.org/que-es-scrum/ Figura 13. Interés Mundial por Metodología Scrum. Fuente. https://www.google.es/trends 10 3. Familia de Metodologías Crystal. El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza). Por ejemplo. Clear es para equipos de hasta 8 personas o menos. Amarillo para equipos entre 10 a 20 personas. Naranja para equipos entre 20 a 50 persona. Roja para equipos entre 50 a 100 personas. Azul para equipos entre 100 a 200 personas. La Metodología Crystal puede ser usada en proyectos pequeños y como casi todos los otros métodos consisten en valores, técnicas y procesos. Se hace menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. La Metodología Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son: - Aspecto humano del equipo - Tamaño de un equipo (número de componentes) - Comunicación entre los componentes - Distintas políticas a seguir - Espacio físico de trabajo Figura 14. Interés Mundial por Familia de Metodologías Crystal. Fuente. https://www.google.es/trends 4. Feature Driven Development. Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el monitoreo constante del proyecto. Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Propone tener etapas de cierre cada dos semanas. Se obtienen resultados periódicos y tangibles. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorear. Define claramente entregas tangibles y formas de evaluación del progreso del proyecto. No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. 11 Figura 15. Interés Mundial por Familia de Metodología Feature Driven Development. Fuente. https://www.google.es/trends 2. Proceso Unificado Rational (RUP), una configuración ágil. Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización. Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organiza Principales características Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software. Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software Figura 16. Interés Mundial por RUP. Fuente. https://www.google.es/trends 12 5. Dynamic Systems Development Method (DSDM). El Método de Desarrollo de Sistemas Dinámicos (en inglés Dynamic Systems Development Method o DSDM) es un método que provee un framework para el desarrollo ágil de software, apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reúna las necesidades de la empresa en tiempo y presupuesto Su meta es entregar los sistemas del software a tiempo y en el presupuesto mientras ajustando para los requisitos cambiantes a lo largo del proceso de desarrollo. DSDM es uno de varios métodos Ágiles para el software en vías de desarrollo, y forma una parte de la Alianza Ágil. Figura 17. Interés Mundial por DSDM. Fuente. https://www.google.es/trends 6. Adaptive Software Development (ASD). El método ágil ASD (Adaptive Software Development) traducido en español significa Desarrollo Adaptable de Software es un modelo de implementación de patrones ágiles para desarrollo de software. Al igual que otras metodologías ágiles, su funcionamiento es cíclico y reconoce que en cada iteración se producirán cambios e incluso errores. El desarrollo de software adaptable (Adaptive Software Development - ASD) es una metodología de desarrollo que hace énfasis en aplicar las ideas que se originaron en el mundo de los sistemas complejos, adaptación continua del proceso al trabajo. Sus principales características del ASD son: - Iterativo. - Orientado a los componentes de software (la funcionalidad que el producto va a tener, características, etc.) más que a las tareas en las que se va a alcanzar dicho objetivo. - Tolerante a los cambios. - Guiado por los riesgos - La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo Figura 18. Interés Mundial por ASD. Fuente. https://www.google.es/trends 13 7. Open Source Software Development. Desarrollo del software de código abierto es el proceso por el que se desarrolla el software de código abierto, o de manera similar aquel software cuyo código fuente está disponible de manera pública. Estos son productos de software disponibles con su código fuente bajo una licencia de código abierto que permite estudiar, cambiar y mejorar el diseño de estos programas. Ejemplos de algunos productos populares de software de código abierto son Mozilla Firefox, Google Chromium, Android, LibreOffice y el paquete de oficina Apache OpenOffice Suite. El uso de software de código abierto es común porque los desarrolladores encuentran que pueden obtener un prototipo en pruebas y producción más rápido y prácticamente sin costo alguno. El resultado es un tiempo más corto para el mercado a un costo menor – es obvio para cualquier empresa que busque prosperar en el mercado-. Las bases de datos NoSQL subieron en popularidad sobre la ola de estas tendencias. Normalmente, de código abierto y construido con prácticas de software moderno en mente, las bases de datos NoSQL permiten un desarrollo más rápido a menor costo que con la antigua generación de bases de datos relacionales. Figura 19. Interés Mundial por Open Source Software Development. Fuente. https://www.google.es/trends 14 TERCER REFERENTE. MODELOS DE PROCESO DE DESARROLLO DE SOFTWARE Referente: ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 20. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Figura 20. Proceso de Desarrollo de Software. Fuente ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación. 3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente. Un modelo de proceso de software se define como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los Modelos de Proceso de Software se pueden enunciar como: 1. Modelo Codificar y Corregir Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir código. Corregir problemas en el código. Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. 15 Figura 21. Interés Mundial por Modelo Codificar y Corregir. Fuente. https://www.google.es/trends 2. Modelo en cascada El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. Figura 22. Interés Mundial por Modelo en Cascada. Fuente. https://www.google.es/trends 16 3. Modelo de Desarrollo Evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 23 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración. Figura 23. Modelo de desarrollo evolutivo. Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc Existen dos tipos de desarrollo evolutivo: Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Figura 24. Interés Mundial por Modelo Desarrollo Evolutivo. Fuente. https://www.google.es/trends 17 4. Método Formal de Sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. Desiciones Desarrollo Formal Especificación Informal Especificación Especificación de alto nivel (prototipo) Tranformación Interactiva Especificación de bajo nivel Transformación Automática Código Fuente Optimización Validación de Especificación Mantenimiento Figura 25. Paradigma de Programación Automática. Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc La Figura 25 ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. El mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). Observaciones sobre el Método Formal de Sistemas: Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias. Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo. Figura 26. Interés Mundial por Método Formal de Sistemas. Fuente. https://www.google.es/trends 18 5. Modelo de Desarrollo Basado en Reutilización de Componentes Este modelo consta de 4 fases según Figura 27. Figura 27. Desarrollo basado en reutilización de componentes Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc A continuación se describe cada fase: 1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). 3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. 4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada. Figura 28. Interés Mundial por Desarrollo basado en reutilización de componentes. Fuente. https://www.google.es/trends 19 6. Modelo de Desarrollo iterativo incremental El Modelo de Desarrollo iterativo incremental es una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 15). Es una combinación del Modelo de Cascada y Modelo Evolutivo. Figura 28. Modelo de desarrollo iterativo incremental. Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo. Figura 29. Interés Mundial por Modelo de Desarrollo iterativo incremental Fuente. https://www.google.es/trends 20 7. Modelo de Ciclo de Desarrollo en Espiral El ciclo de desarrollo en Espiral se representa como una espiral (ver Figura 30), en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Figura 30. Modelo de Ciclo de Desarrollo en Espiral Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc Cada ciclo de desarrollo se divide en cuatro fases: 8. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 9. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 10. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 11. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. 21 Figura 31. Interés Mundial por Modelo de Ciclo de Desarrollo en Espiral Fuente. https://www.google.es/trends 22 CUARTO REFERENTE. PROCESOS DE NEGOCIO Referente:https://www.ibm.com/support/knowledgecenter/es/SSAVUV_7.5.0/com.ib m.wbpm.wid.bpel.doc/topics/cunder.html Los procesos de negocio determinan la forma como un conjunto de actividades pueden lograr los objetivos específicos de una organización describiendo su forma de operar, tomar decisiones y establecer el flujo de la información necesario entre los participantes del proceso. Cada proceso es motivado por un evento interno o externo a la organización; se procesa la información de entrada, se manipulan los objetos necesarios, se toman las decisiones requeridas y se generan la información y los eventos de salida. Los procesos están restringidos por un conjunto de reglas de negocio, que determinan las políticas y la estructura de la información del negocio. Un proceso puede estar compuesto de subprocesos o actividades, reglas del negocio y de flujos de control (Figura 32). Figura 32. Representación de Procesos, Subproceso y Actividad. Fuente Propia Los procesos del negocio son la base de todo buen desarrollo de software y normalmente se identifican en la primera fase del proceso. Facilitan la abstracción del problema para construir la solución informática, y su análisis está orientado a la identificación de los objetivos generales, los requisitos del software, la selección del tipo de sistema de información y la arquitectura sobre la cual se debe construir el sistema. Figura 32. Interés Mundial por Proceso de Negocio. Fuente. https://www.google.es/trends 23 QUINTO REFERENTE. FLUJOS DE TRABAJO (WORKFLOWS) Referente: http://es.ccm.net/contents/221-workflow-gestion-de-los-procesoscomerciales El término "Workflow", que se traduce literalmente como "flujo de trabajo", hace referencia a la gestión modelada y computarizada de todas las tareas que deben llevarse a cabo y de los distintos protagonistas involucrados en realizar el proceso de negocios (también llamado proceso operativo). También puede traducirse el término Worflow como gestión electrónica de procesos de negocios. Un proceso de negocios representa interacciones bajo la forma de un intercambio de información entre los distintos protagonistas, por ejemplo: • Personas • Aplicaciones o servicios • Procesos de terceros En la práctica, un Workflow puede describir: • El circuito de validación. • Las tareas que deben realizarse entre los distintos participantes de un proceso. • Los plazos que deben respetarse. • Los modos de validación. En la figura 33 presentan un mapa conceptual de cómo un proceso del negocio puede ser automatizado desde su definición y su uso en un sistema (motor) administrador de workflow. Figura 33. Mapa Conceptual de un WorkFlow. Fuente Propia 24 Figura 34. Interés Mundial por WorkFlow. Fuente. https://www.google.es/trends 25 SEXTO REFERENTE. DIAGRAMAS UML Referente:http://biblo.una.edu.ve/docu.7/bases/marc/texto/t38840.pdf Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete. La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se re asignan a conexiones entre nodos en un gráfico en la forma analizada de la notación. La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional. Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos, símbolos bidimensionales, rutas y cadenas. Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas. Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas. Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. Un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos. Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama. Se presenta los diagramas UML: 26 Área Vista Diagramas Clase, asociación, generalización, dependencia, realización, interfaz. Vista Estática Diagrama Clases Vista de Casos de Uso Caso de Uso, Actor, Diagramas de asociación, extensión, Casos de Uso generalización. Vista de Implementación Diagramas de Componente, interfaz, Componentes dependencia, realización. Vista de Despliegue Diagramas de Nodo, componente, Despliegue dependencia, localización. Estructura Vista de máquina Estados Vista de actividad de Conceptos Principales de Diagramas de Estado, evento, transición, Estados acción. Diagramas de Estado, actividad, transición, Actividad determinación, división, unión. Diagramas de Interacción, objeto, mensaje, Secuencia activación. Comportamiento Vista de interacción Diagramas de Colaboración, interacción, rol Colaboración de colaboración, mensaje. Administración o Vista de Gestión de modelo modelo Extensión de UML Todas Gestión de Diagramas de Paquete, subsistema, modelo. Clases Todos Restricción, estereotipo, valores, etiquetados. 27 Figura 35. Interés Mundial por Diagramas UML. Fuente. https://www.google.es/trends 28 SEPTIMPO REFERENTE. ARQUITECTURA DE UN SISTEMA SOFTWARE Referente: http://www.lsi.us.es/docencia/get.php?id=5807 Definición de arquitectura de un sistema software (según Barbacci et al en 1998) “Es la estructura o estructuras del sistema, incluyendo: sus componentes software, las propiedades observables de dichos componentes y las relaciones entre ellos.” ♦ Diseño Arquitectónico: Concepción original (proceso) de la Arquitectura Software de un Sistema a fin de construirlo con la máxima calidad y dentro de un plazo y tiempo determinado. Figura 36. Arquitectura Software. Fuente http://www.lsi.us.es/docencia/get.php?id=5807 Programas= Algoritmos + Estructura de Datos ♦ ¿y la estructura de un sistema software? ♦ Aumento en complejidad de un sistema software: mayor importancia al diseño y especificación de la estructura global del sistema que a la elección de algoritmos y estructuras de datos (micro arquitectura) ♦ Es el primer documento en el que se establece una prioridad entre propiedades de calidad al tiempo que se recogen todos los requisitos y restricciones (funcionales, infraestructurales, estructurales…) ♦ Se recomienda comenzar en un alto grado de abstracción y refinar sucesivamente hasta alcanzar el nivel de componente ♦ Se recomienda seguir ‘buenas prácticas’ 29 Figura 37. Interés Mundial por Arquitectura de Software. Fuente. https://www.google.es/trends 30 OCTAVO REFERENTE. PATRONES DE SOFTWARE Referente:https://sophia.javeriana.edu.co/~acarrillo/POO/Material/CursoPOOAplicaci onesJava-BuenasPracticas.pdf Los patrones de software describen un problema que ocurre repetidas veces en algún contexto determinado del proceso de desarrollo de software, y entregan una buena solución ya probada. Esto ayuda a diseñar correctamente en menos tiempo, ayuda a construir problemas reutilizables y extensibles, y facilita la documentación y la comunicación con otros miembros del equipo de desarrollo. La idea de patrones de software tuvo su origen del campo de la arquitectura. Christopher Alexander, un arquitecto, escribió dos libros revolucionarios que describían patrones en arquitectura de construcción y planificación urbana: A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977) y The Timeless Way of Building (Oxford University Press, 1979). Las ideas presentadas en estos libros son aplicables a varios campos además de la arquitectura, incluyendo el software. En 1987, Ward Cunningham y Kent Beck usaron algunas de las ideas de Alexander y desarrollaron cinco patrones para el diseño de interfaces de usuario (UI), que publicaron en un artículo de OOPSLA'87 llamado Using Pattern Languages for Object-Oriented Programs. En 1994 Erich Gamma, Richard Helm, John Vlissides y Ralph Johnson publicaron uno de los libros más influyentes de esta década: Design Patterns. Este libro, también llamado "Gang of Four" (o GoF), popularizó la idea de patrones. Figura 38. Interés Mundial por Patrones de Software. Fuente. https://www.google.es/trends 31 NOVENO REFERENTE. PATRONES DE DISEÑO Referente:https://msdn.microsoft.com/es-es/library/bb972240.aspx “Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios). Grande fue mi sorpresa al averiguar que existen varios patrones de diseño popularmente conocidos, los cuales se clasifican como se muestra a continuación: Patrones Creacionales: Inicialización y configuración de objetos. Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes. Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos. Figura 39. Interés Mundial por Patrones de Diseño. Fuente. https://www.google.es/trends 32 DECIMO REFERENTE. PATRONES ARQUITECTONICOS Referente: https://ingeniods.wordpress.com/2013/09/16/patrones-arquitectonicos/ Los patrones arquitectónicos se utilizan para expresar una estructura de organización base o esquema para un software. Proporcionando un conjunto de sub-sistemas predefinidos, especificando sus responsabilidades, reglas, directrices que determinan la organización, comunicación, interacción y relaciones entre ellos. Los patrones arquitectónicos heredan mucha de la terminología y conceptos de patrones de diseño, pero se centran en proporcionar modelos y métodos re-utilizables específicamente para la arquitectura general de los sistemas de información. En otras palabras, quiere decir que a diferencia de los patrones de diseño estas son plantillas incompletas y no se pueden aplicar directamente al código con modificaciones meramente contextuales. Los patrones arquitectónicos a su vez se salen del código puro de la aplicación y suben e incluyen software, hardware, redes, inclusos las personas. Dentro de los patrones arquitectónicos podemos encontrar: Modelo Vista Controlador. Separa los datos (modelo) y la interfaz de usuario (vista/GUI), permitiendo modificaciones independientes en cada una las partes sin afectar la otra, o sea, para que los cambios realizados en la interfaz de usuario (GUI) no afectan el manejo de datos, y los datos pueden ser reorganizados sin cambiar la interfaz de usuario. Inyección de Dependencias. Es una aplicación de la “Inversión de Control – IoC”, concepto que hace exactamente eso, se invierte el flujo de control. El modelo permite que se inyecte no dependencias en sí, sino en su lugar, la información para satisfacerlas la relación a las dependencias. Arquitectura dirigida por eventos (Event-driven architecture o EDA). Es un patrón de arquitectura software que para orquestar su comportamiento se centra en torno a la producción, detección, consumo y respuestas ante “eventos”. Arquitectura orientada a servicios (SOA). La ‘Arquitectura Orientada a Servicios de cliente’ (Service Oriented Architecture), es un concepto de arquitectura de software donde el software consta de una composición de servicios, prestaciones y reglas, y son los requisitos del negocio los que dictaminan la manera en la que estas se ínter-relaciona. Está diseñado para que el sistema sea altamente escalable y flexible a nuevos requerimientos. Figura 40. Interés Mundial por Patrones Arquitectónicos. Fuente. https://www.google.es/trends 33 DECIMO PRIMER REFERENTE. INGENIERIA DE REQUERIMIENTOS Referente: http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2__Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4 Es el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de software. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que se comprende y define los sistemas de software complejos. Existen varias definiciones de requerimientos, de entre las cuales podemos citar las siguientes: Los Requerimientos fueron definidos por la IEEE como [IEEE90]: 1. Condición o capacidad requerida por el usuario para resolver un problema o alcanzar un objetivo 2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto 3. Representación documentada de una condición o capacidad como en 1 o 2. Según Zave: • Rama de la ingeniería del software que trata con el establecimiento de los objetivos, funciones y restricciones de los sistemas software. • Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer especificaciones precisas. Según Boehm: • Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema. Según Loucopoulos: • Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido. Figura 41. Interés Mundial por Ingeniería de Requerimientos. Fuente. https://www.google.es/trends 34 DECIMO SEGUNDO REFERENTE. FRAMEWORKS JAVA Referente: Estado del Arte de Frameworks Java Los patrones de diseño en la construcción de software se especifican acorde a la etapa donde se aplican: modelos de dominio, patrones arquitecturales (estilos), patrones de diseño, patrones de código específicos a una tecnología (idioms), patrones de diseño implementados en una API (Frameworks), patrones de procesos. Antes de formular que es Framework, se hace necesario definir que la Arquitectura de Componentes Software (Figura 42 es el conjunto de componentes12 y sus relaciones13, sus interfaces14, obligaciones, servicios o contratos15. Figura. 42. Arquitectura de Componentes Software. Adaptación Un Framework se define como un cascaron o una estructura en bruto donde se van colocando los componentes acorde con una necesidad, requerimiento o una exigencia basado en un análisis de alto nivel, como también, en una valoración crítica. Entones, un Framework es una abstracción de un componente de software (su construcción se basa en la experiencia) para resolver un problema en UN CONTEXTO (ojo no confundir con PATRON DE DISEÑO que es para resolver un problema en CUALQUIER contexto). Figura 43. Interés en Framework Java en el Mundo. Fuente https://www.google.es/trends 12 Representa una unidad coherente de funcionalidad 13 Indican que aspectos de un componente son usados por otros componentes y cómo la comunicación entre componentes procede sobre el tiempo 14 Es una estructura que especifica obligaciones o contratos de un Componente Software 15 Conjunto o una colección de operaciones a realizar por un componente software 35 Figura 44. Interés en Framework Java en Colombia. Fuente https://www.google.es/trends En la Figura 43, se observa el interes hacia el desarrollo deFramework Java en los últimos cinco años( desde 2011) ha permanecido con algunas excepciones hasta un 50% de la población de programación java. Figura 44. Interés en Microsoft .net Frameworks en el Mundo. Fuente https://www.google.es/trends Figura 45. Interés en Microsoft .net Frameworks en Colombia. Fuente https://www.google.es/trends 36 Hibernate Java Persistir objetos Java es la manera de almacenar permanentemente objetos en una tabla de una base de datos relacional o sea convertir objetos Java a columnas/registros de una base de datos y viceversa. Por lo tanto, la persistencia es serializar objetos Java 16 estructurados en forma de árbol a una base de ratos relacional estructurada de forma tabular y viceversa requiriendo el mapeo de los objetos Java a columnas y registros de la base de datos de una manera optimizada en velocidad y eficiencia. Hibernate Java es una herramienta de persistencia "objeto-java-a-base-de-datos" o de Mapeo Objeto-Relacional (ORM) haciendo de archivos declarativos (XML) para representar la transformación de los datos de un modelo relacional a un modelo orientado a objetos (Pojo) y viceversa. Figura 46. Interés por Hibernate Java. Fuente https://www.google.es/trends Frameworks Struts Teoría Comprobada. Framework Struts es un framework que implementa el patrón de arquitectura MVC en Java. El patrón de arquitectura MVC (Model-View-Controller) se define en el Model (Objetos de Negocio), la View (interfaz con el usuario u otro sistema) y el Controller (controlador del workflow17 de la aplicación). El Framework Struts 1.x implementa el patrón de arquitectura MVC separando el modelo o workflow de la aplicación (se puede programar desde un archivo XML), del modelo de objetos de negocio y de la generación de interfaz. Las acciones se ejecutan sobre el Model (Objetos de Negocio) y se implementan basándose en clases predefinidas por el framework a partir de un patrón de diseño Facade. La generación de la View (interfaz con el usuario u otro sistema) se realiza a partir de un conjunto de Tags predefinidos por Struts generando ventajas de mantenimiento y de desempeño (pooling de Tags, caching, etc). Así mismo, separa el desarrollo de interfaz del workflow y lógica de negocio permitiendo desarrollar ambas en paralelo. El Framework Struts 1.x permite la reutilización de componentes y puede hacer uso de múltiples interfaces de usuario (Html, sHtml, Wml, Desktop applications, etc.) y de múltiples idiomas, localismos, etc. 16 Consiste en obtener una secuencia de bytes que represente el estado de dicho objeto 17 Estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas 37 El Controller (controlador) Struts se encarga de tres tareas: 1. Validaciones simples: extendiendo la clase ActionForm, se realiza validaciones simples sin acceder al modelo, haciendo uso de expresiones regulares (comprobación formato y longitud de datos) 2. Validaciones Complejas: extendiendo la clase Action, se comprueba las reglas de negocio (modelo). Por ejemplo: Se realizan consultas contra la base de datos y se obtienen los errores de integridad, etc. Control de flujo o de Navegación: a través de un archivo de configuración (struts-conf) se gestiona el flujo de navegación entre páginas, que también se logra extendiendo la clase ActionForm y Action. Figura 47. Interés por Framework Struts Java. Fuente https://www.google.es/trends Frameworks Spring Teoría Comprobada. Spring es un framework liviano que generalmente los objetos que se programan no tienen dependencias en clases específicas de Spring. Sus características principales son inyección de dependencias y programación orientada a aspectos. Inyección de dependencias. El objetivo es lograr un bajo acoplamiento entre los objetos de una aplicación. Con el Patrón Inversión de Control18 (IoC), los objetos no crean o buscan sus dependencias (objetos con los cuales colabora) sino que éstas son dadas al objeto. El contenedor (la entidad que coordina cada objeto en el sistema) es el encargado de realizar este trabajo al momento de crear el objeto. Se invierte la responsabilidad en cuanto a la manera en que un objeto obtiene la referencia a otro objeto. De esta manera, los objetos conocen sus dependencias por su interfaz. Así la dependencia puede ser intercambiada por distintas implementaciones a través del contenedor. En resumen, se programa orientado a interface y se inyecta las implementaciones a través del contenedor. Programación orientada a aspectos (AOP). Se trata de un paradigma de programación que intenta separar las funcionalidades secundarias19 de la lógica de negocios. Módulos de Spring. En la Figura 48 se muestran los módulos del Spring. En su núcleo (Core) se encuentra el BeanFactory – el contenedor fundamental de Spring y quien se 18 IoC permite instanciar una clase (crear objetos) olvidando las dependencias que tiene. Para eso, primero se registran las clases en un Contenedor (IoC Container). Segundo, haciendo uso de Dependency Injection, se generan los Constructores de las clases registradas en el Contenedor (IoC Container), para así, recuperar fácilmente cualquier clase en cualquier otra clase. IoC también es famoso por el principio de HollyWood: “don’t call us, we’ll call you” (No nos llames, nosotros le llamaremos.) 19 “cross-cutting concerns” algo que se traduciría como “preocupaciones transversales” 38 encarga de la inyección de dependencias. El contenedor ApplicationContext se basa en BeanFactory, eventos de ciclo de vida, validación y mejor integración con AOP. Figura 48. Modulo del Framework Spring. Fuente http://www.j2eebrain.com/wp-content/uploads/Spring-Framework.png Figura 49. Interés por Framework Spring Java. Fuente https://www.google.es/trends 39 DECIMO TERCER REFERENTE. BUENAS PRÁCTICAS Referente:https://dsdsoa.wordpress.com/2016/10/09/buenas-practicas-soa/ Por buenas prácticas se entiende como un conjunto coherente de acciones que han rendido buen o incluso excelente servicio en un determinado contexto y que se espera que, en contextos similares, rindan similares resultados. Figura 50. Interés por Buenas Prácticas. Fuente https://www.google.es/trends Una de las mayores ventajas de usar Arquitectura Orientada a Servicios (SOA) un servicio puede ser reutilizado en la evolución y desarrollo de un proceso de negocio. Se debe entender que tal acercamiento a la construcción de aplicaciones compuestas y a procesos de negocios no funciona en ausencia de una plataforma de cumplimiento de estándares para la construcción de tales servicios. Para poder garantizar un correcto desarrollo de un sistema bajo los conceptos propuesto por SOA, se tiene que asegurar que los desarrolladores tengo bien en claro los siguientes aspectos: 1. Interfaces simples y de fácil consumo que esconden la complejidad 2. Reutilización futura sin límites 3. Complejidad técnica de la implementación en cada sistema de soporte 4. Necesidad de coordinación entre las diferentes líneas de negocios 5. Diferencia entere lógica de flujos de servicios y lógica de aplicación subyacente 6. Necesidades de seguridad de servicios diferentes de seguridad de aplicaciones de soporte 7. Los servicios como componentes de TI con gestión independiente Sumado a estos aspectos, hay buenas prácticas que los desarrollos basados en SOA deberían seguir o al menos tener en consideración: Mantener suites de pruebas de integración de servicios automatizadas: La suite debe ser ejecutable según las necesidades, con escaso o nulo tiempo de configuración, y debe “impactar” en los principales componentes dentro de cada nivel de la pila de servicio. Adoptar un marco de pruebas de servicios: A fin de automatizar y mantener suites de pruebas de integración de servicios, existen ciertas capacidades comunes que se deben desarrollar y reutilizar. Entre ellas se encuentran: 1. La capacidad de producir agentes de prueba en ausencia de la interfaz de usuario de una aplicación 2. Generación de mensajes de prueba, basados en la descripción del servicio Web Services Description Language (WSDL) 3. Variación de datos de entrada, usando una tabla de datos 40 4. 5. 6. 7. Scripts de desmontaje y configuración de datos Datos de salida de informes de pruebas Definición de resultados esperados Ejecución de pruebas en cada nivel integrado de la pila (por lo general, a través de un entorno de prueba unitaria) 8. Emulación de servicios externos (falsos) 9. Inspección y validación de mensajes de servicio de aplicaciones consumidoras 10. Envío de múltiples mensajes de prueba a través de subprocesos separados 11. Planificar pruebas de rendimiento: Es necesario tomar medidas de rendimiento para la implementación del servicio de manera temprana y permanente. No se puede esperar hasta el final, ya que los cambios de diseño pueden ser costosos. 12. Adicionalmente se deben tomar en cuenta toda buena práctica de desarrollo en general, como TDD (Desarrollo guiado por pruebas de software, o Test-driven development), para poder automatizar las pruebas sobre pequeñas partes de código/funcionalidad, y así lograr un mayor control sobre futuras actualizaciones. 41 DECIMO CUARTO REFERENTE. SOFTWARE A LA MEDIDA Referente: http://deviatan.com/software-a-la-medida/ Se puede contar con un software personalizado o a la medida hacia el interior de cualquier organización. Este software personalizado se convierte en un activo importante porque funciona de manera más efectiva y realiza las operaciones acorde con los requerimientos. Entonces, el software hecho a la medida es una solución que atiende las necesidades de cada empresa y canaliza los requerimientos de esta hacia una plataforma productiva y confiable. En la acción de determinar si su empresa u organización necesita un software hecho a la medida puede tener en cuenta los siguientes factores: - La empresa maneja una gran cantidad de entrada de datos - Si realiza actividades repetitivas día con día - Si desea ahorrar en mano de obra para ciertas actividades - Si necesita un manejo más eficaz en la relación con sus clientes - Si desea simplificar el tiempo en realizar tareas mundanas de la empresa - Si desea reducir significativamente los errores en ciertas tareas de su empresa. - Si desea cubrir una necesidad que ningún software genérico de su conocimiento puede realizar Es importante resaltar, que todo software a la medida desarrollado, debe de seguir un proceso de evaluación del prototipo y una vez que el software se encuentre correctamente testeado e instalado, es necesario que reciba el mantenimiento adecuado y de forma oportuna. Figura 51. Ejemplos de Software a la Medida. Fuente: http://deviatan.com/software-a-la-medida/ 42 Figura 52. Interés por Software a la Medida. Fuente https://www.google.es/trends 43