Nuevas Metodologias de Ingeniería de Software

 Nuevas Metodologías Metodologías de Ingeniería Ingeniería de Software William Hernando Álvarez Villota Luis Fernando Díaz Muñoz Juan Sebastián Erazo Chamorro Robín Adrián Rúales Bastidas  Institución universitaria universitaria CESMAG San Juan de Pasto, Republica de Colombia [email protected] [email protected] [email protected] [email protected] [email protected]

I.

INTRODUCCIÓN

El desarrollo del siguiente formato contiene información sobre las nuevas metodologías de ingeniería de software, los métodos de desarrollo de software que han innovado y cambiado la perspectiva del manejo de la ingeniería de software, de igual manera también las ventajas y desventajas que pueden  presentar cada uno de los métodos métodos a mencionar. II.

ABSTRACT

The development of the following format contains information on new methodologies of software engineering, methods of software development have innovated and changed management  perspective of software engineering, likewise also the advantages and disadvantages that can present each of the methods mentioned. III.

¿QUE ES METODOLOGIA EN INGENIERIA DE SOFTWARE?

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un  proceso de software detallado detallado y completo. Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado. La metodología dentro de la ingeniería del software es un tema que produce cierto tipo de confusión tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software, de

tal manera, que en muchos proyectos la aplicación de una metodología no se la aprecia de la manera que debe, tomando este un concepto del cual poco se conoce. Entre las metodologías que hay para la ingeniería de software no hay una que se pueda decir que es superior a las demás, en cambio todas las metodologías según la problemática son bienintencionadas, solo que,  por obvias razones las metodologías modernas o nuevas se ven encaminadas a problemáticas y necesidades actuales. Gracias a los avances que hay dentro de la informática, muchos profesionales de las tecnologías de la información como algunos de los clientes han visto la necesidad de usar unos pasos predefinidos para el desarrollo del software de calidad, es decir seguir un lineamiento metódico: una una metodología. metodología. b Que metodología utilizar dentro de la Ingeniería  de Software

Dentro de la buena utilización de una metodología dentro de la ingeniería de software, el paso más importante y el cual decide que rumbo tomara el desarrollo del software es la elección de cual metodología hacer uso, hay una serie de metodologías que se pueden llamar “tradicionales”, las cuales son

 propuestas en el periodo de los años 90 del siglo XX, que tenían como propósito ayudar a los profesionales indicando pautas para realizar y documentar cada una de las tareas del desarrollo del software, las cuales tienen un problema con respecto al contexto informático, que es tomarlo como la extensión de un  proyecto burocrático tradicional. Así utilizando pasos que sugieren un desarrollo de la tarea de forma

 burocrática, reiterada, con ambigüedades, etc. Dejando a un lado cosas como la calidad, satisfacción, competitividad y los beneficios que puede tomar el desarrollo del Software. Gran parte de las metodologías tradicionales ya no funcionan, estando ya obsoletas desde casi todas las perspectivas, obligando a algunas a ser revisadas y adaptadas pero con una funcionalidad limitada a proyectos que pueden tornarse  poco innovadores.

Entre las metodologías modernas se pueden destacar:

Las metodologías que surgieron y surgen desde los años 90 hasta aquí suelen tener una visión diferente  porque son conscientes de que el mundo del software es un campo amplio y que está en constante cambio, utilizando un desarrollo preciso como para que todas las personas puedan seguirlas y sea de utilidad como  pauta común; pero de la misma forma tiene que ser adaptable para que se pueda aplicar en proyectos diferentes y suficientemente sencilla para que su ejecución no sea muy grave, pero sea completamente y complejamente provechosa, resumiendo en una solo concepto: Metodología ágil.

Hay muchas más, pero quizá éstas sean las más  populares en el momento.





 

¿Qué cosas no podemos tomar  metodologías de Ingeniería de Software? 

¿Qué tipo de metodologías hay dentro de la  Ingeniería de Software? 

Como se puede ver las metodologías se pueden “dividir” en dos tipos las cuales son: metodologías

tradicionales y metodologías modernas. Entre las metodologías tradicionales podemos encontrar: 







Desarrollo de sistemas de Jackson (JSD). De los años 80. Ingeniería de la información. De los 80 también. Structured System Analysis and Design Method (SSADM). También de los 80. Muy  popular en Europa, ya que tiene su origen el Reino Unido. Metodología METRICA, promovida por el Ministerio de las Administraciones Públicas del gobierno de España

Algunas, como las dos primeras (Jackson, Ingeniería de la información), tienen un interés  principalmente histórico. Otras, como SSADM o MÉTRICA, tienen cierta vigencia, en especial en lo que concierne a proyectos públicos.

Rational Unified Process. (Proceso Racional Unificado - RUP) Agile Unified Process. (Proceso Ágil Unificado - AUP) Programación Orientada A Aspectos (POA) Arquitectura Orientada a Servicios (SOA)



como

La "Programación estructurada" o la "Programación Orientada a Objetos" son  paradigmas o modelos de programación. Indican pautas de comportamiento en los sistemas de programación que por consecuente no tienen nada que ver con el ciclo de vida del software ni la manera en la que debe realizarse cada tarea para un proyecto. Los términos "Ciclo de vida en espiral ", " Ciclo de vida incremental ", " en Cascada", " con  prototipo", etc. fueron propuestos en los años 70 y 80 por autores hoy en día clásicos, como Barry Boehm o Winston W. Royce. Todavía aparecen en los libros, y probablemente tienen cierta vigencia dado que se tratan de ideas muy  básicas, que "no pasan de moda". Son esquemas generales de organización en las tareas del ciclo de vida, unas con respecto a otras y con respecto a otros aspectos como el tiempo, los requisitos o el riesgo. Actualmente se prefiere la denominación de PATRONES del ciclo de vida del software , aunque antaño fueron denominados simplemente distintos " Ciclos de vida " . Indican ideas estructurales sencillas en el proceso de desarrollo, y no la manera en la que debe realizarse cada tarea del ciclo para un proyecto concreto El

lenguaje UML (Unified  Languaje) es un gran logro de la

Modeling

ingeniería. Aún con sus carencias, y puntos criticables es un avance muy significativo: un lenguaje común para que todos los profesionales del desarrollo de sistemas expresen sus ideas pero el UML no indica a nadie la manera de realizar cada tarea en un proyecto concreto: tan solo es una herramienta para expresar ideas. Sin

embargo, algunas metodologías de las que hemos comentado, como RUP o METRICA hacen referencia a UML como herramienta  para expresar ideas. IV.

PROGRAMACIÓN ORIENTADA A ASPECTOS

La programación orientada a aspectos es una de las nuevas metodologías de programación, intenta separar componentes y aspectos por aparte arrojando como resultando mecanismos que puedan ser utilizados para componer todo un sistema de una manera que sea eficiente y a su vez fácil de entender. POA es un paradigma de programación la cual intenta permitir una modularización de las aplicaciones y posibilitar una separación de conceptos Se usa poa ya que existen conceptos que no pueden encapsularse dentro de una sola unidad funcional  puesto que atraviesan todo el sistema como por ejemplo: manejo de memoria, manejo de errores, sincronización, etc.

elementos que se cruzan entre sí como elementos de  primera clase. Para tener más claro el concepto de POA es necesario saber lo que es un aspecto: Se entiende por aspecto a una unidad modular que se disemina por la estructura de varias unidades funcionales, estos aspectos existen no solo al principio o al final sino tanto en la etapa de diseño como en la de implementación. Los aspectos son la unidad básica de la programación orientada a aspectos. El soporte necesitado para este tipo se logra mediante una nueva clase de lenguajes llamados LOA (lenguajes orientados a aspectos), lenguajes los cuales  brindan los mecanismos necesarios para poder capturar y junto con ello declarar los elementos que están diseminados por todo el sistema, son capaces de manejar uno o varias aspectos pero no pueden manejar aspectos diferentes a los cuales no fueron diseñados.    

Los aspectos deben ser identificables Los aspectos deben auto contenerse Los aspectos deben ser accesibles al modificar Los aspectos no deben interferir entre si

 Algunos LOA son:

La programación orientada a aspectos ayuda a resolver problemas de scattered (código disperso, un mismo servicio llamado de manera similar desde diferentes partes dentro del programa) y de tangled (código enmarañado, una misma operación tiene que acceder a diferentes servicios además de cumplir con la operación a la que está asignado)

    

Cool RIDL MALAJ AspectC AspectC++

Una implementación basada en POA consiste  principalmente en un lenguaje base para programar la funcionalidad básica, al igual que uno o varios lenguajes de aspectos para poder especificar los concerns, todo esto acompañado de un “tejedor” de

aspectos para la combinación de los diferentes lenguajes y por último uno o más programas de aspectos que puedan implementarlos. La gráfica siguiente demuestra cómo se enmarca en cada uno de los conceptos anteriores

POA es la consecución de la POO., donde la fortaleza del segundo se basa en la demostración de cuando hay que modelar conceptos comunes pero falla al modelar dichos conceptos, lo contrario pasa con POA puesto que logra dicho objetivo al tratar Ilustración 1 Programación orientada a aspectos [estructura (POA)]

Ventajas: 

Un código más natural, menos enredado y reducido





  



Facilidad para depurar y hacer modificaciones al código Código reusable que se puede acoplarar/desacoplar cuando sea requerido y/o necesario Razonamiento mejor sobre los conceptos Eliminación de la dispersión del código Implementaciones en el código, comprensibles, adaptables, limpias, fáciles de entender. Ayuda a superar los problemas causados  por el código mezclado y el código diseminado

 Desventajas: 







V.

Posibles choques entre el código funcional y en el código de aspectos Posibles choques entre el código de aspectos y los mecanismos del lenguaje, ejemplo: la herencia de un aspecto a otro Posibles choques entre los aspectos, ejemplo: dos aspectos que separados funcionan muy bien pero al juntarlos arrojan como resultado un comportamiento anormal. Los LOA actuales no cuentan con mecanismos suficientes para poder respetar por completo los principios de diseño como por ejemplo el encapsulamiento

subyacentes. En lugar de exigir que todos los datos y lógica de negocio residan en un mismo ordenador, el modelo de servicios facilita el acceso y consumo de los recursos de IT a través de la red. Puesto que los servicios están diseñados para ser independientes, autónomos y para interconectarse adecuadamente,  pueden combinarse y recombinarse con suma facilidad en aplicaciones complejas que respondan a las necesidades de cada momento en el seno de una organización. Las aplicaciones compuestas (también llamadas “dinámicas”) son lo que p ermite a las empresas mejorar y automatizar sus procesos manuales, disponer de una visión consistente de sus clientes y socios comerciales y orquestar sus procesos de negocio para que cumplan con las regulaciones legales y políticas internas. El resultado final es que las organizaciones que adoptan la orientación a servicios  pueden crear y reutilizar servicios y aplicaciones y adaptarlos ante los cambios evolutivos que se producen dentro y fuera de ellas, y con ello adquirir la agilidad necesaria para ganar ventaja competitiva. MODELOS.

ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

El acrónimo S.O.A. proviene de las palabras inglesas Service Oriented Architecture, establece un marco de diseño para la integración de aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada en estándares e independiente de la  plataforma, con la que SOA puede descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular. La estrategia de orientación a servicios permite la creación de servicios y aplicaciones compuestas que  pueden existir con independencia de las tecnologías

Ventajas 

  

 

Respuesta rápida a nuevas necesidades de negocio. Reducción del costo de desarrollo de IT. Capacidad de integrar a clientes y socios. Capacidad de generar nuevos modelos de negocios. Alinear objetivos de IT a objetivos de negocio. Apertura a nuevos mercados, canales y valor de sistemas existentes.





  

Permite la reutilización de componentes  prefabricados de servicio para implementaciones lógicas. Integra sistemas separados de distintas  plataformas. Eliminar duplicidad de sistemas. Automatiza los procesos de negocios. Mejorar la visibilidad de procesos de negocio.

 Desventajas: 









SOA depende de la implementación de estándares. Sin estándares, la comunicación entre aplicaciones requiere de mucho tiempo y código. SOA no es para: aplicaciones con alto nivel de transferencia de datos, aplicaciones que no requieren de implementación del tipo request/response y para aplicaciones que tienen un corto periodo de vida. Incrementalmente se hace difícil y costoso el ser capaz de cumplir con los protocolos y hablar con un servicio. Implica conocer los procesos del negocio, clasificarlos, extraer las funciones que son comunes a ellos, estandarizarlas y formar con ellas capas de servicios que serán requeridas  por cualquier proceso de negocio. En la medida en que un servicio de negocio, vaya siendo incorporado en la definición de los  procesos de negocio, dicho servicio aumentara su nivel de criticidad. Con lo cual cada que se requiera efectuar una actualización en dicho servicio (por ejemplo, un cambio en el código, una interfaz nueva, etc.), deberá evaluarse  previamente el impacto y tener mucho cuidado con su implementación. Sin embargo, parte de la problemática anterior, puede ser solventada en virtud a un buen diseño del servicio.

Utilización de las nuevas metodologías en  distintos países.

Debido a los beneficios que representa SOA & POA como nuevas metodologías y que van directamente aplicadas en el ámbito empresarial son muchos los países que han comenzado a desarrollar y/o utilizar estas estrategias, principalmente los países y empresas orientales que han sido los que en su mayoría

le apuestan más al uso de éstas metodologías puesto que ayudan a optimizar varios de sus procesos creando así un entorno más evolutivo de diversos campos en ellas arrojando así como resultado avances importantes en las mismas. VI.

BIBLIOGRAFÍA

[1] Joskowicz, José. Programación orientada a aspectos. Disponible en: http://iie.fing.edu.uy/%7Ejosej/docs/Programacion%2 0Orientada%20Aspectos%20%20Jose%20Joskowicz.pdf [2] Nieto Moreno, Juan Manuel. Escuela técnica superior de ingeniería informática. Introducción a la  programación orientada a aspectos. Disponible en: http://lsi.ugr.es/~pdo/MaterialTeoriaAlumnos/Tema% 206.-%20Dise%F1o%20OO/POA.pdf [3] Asteasuain, Fernando. Contreras, Ezequiel, Bernardo. Universidad nacional del sur. Programación orientada a aspectos. Disponible en: http://www.angelfire.com/ri2/aspectos/Tesis/tesis.pdf [4] Vic, CO “la tecla del escape”.   Metodologías de desarrollo del software. Disponible en: http://latecladeescape.com/h/2015/07/metodologiasde-desarrollo-del-software [1] MICROSOFT. La Arquitectura Orientada a Servicios (SOA) de Microsoft aplicada al mundo real. [Online]. Disponible en: www.microsoft.com/soa. [2] MARTIN, Isabel. RODRIGO, José. Arquitectura Orientada a Servicios (SOA). Disponible en:

https://emergingtechuva.wordpress.com/2013/11/25/a rquitectura-orientada-a-servicios-soa/ [3] SOAINT. SERVICIOS

ARQUITECTURA ORIENTADA A (SOA). Disponible en:

http://www.soaint.com/servicios/arquitecturaorientada-a-servicios/