Mitos sobre la Ingeniería de Software

La ingeniería de Software, así como otras disciplinas, está rodeada de mitos y pensamientos falsos sobre ella, los cuales se van creando no solo por personas ajenas a este campo sino también por algunos conocedores que ignoran ciertos aspectos, todo esto lo que hace es propagar información errónea sobre este campo; aquí algunos ejemplos:

- Entre más programadores, más rápido se terminará de construir el software. 

- La documentación es una pérdida de tiempo, mejor se empieza a programar de una. 

- Con solo un objetivo general basta para empezar a escribir el programa. 

- Es fácil y rápido hacer cambios y depurar el software. 

- El trabajo termina cuando el programa funciona y se termina de escribir el código. 

- Entre más grande sea la documentación del software, mejor será. 

- Entre más grande y complejo sea el software, más tendencia tendrá a fallar. La función del desarrollador es solo escribir el código.

ASP Vs. SAAS

La tecnología siempre ha causado impacto, tanto en el mercado como en nuestras vidas; y actualmente gracias al acelerado crecimiento de esta, las empresas y organizaciones se han visto afectadas positivamente, ya que les ha ayudado en la optimización de sus procesos, la prestación de un mejor servicio a sus clientes, la generación de mayores ingresos y en la reducción de costos.

Últimamente las empresas han decidido abrir su mercado a través del Internet, y colocan a disposición productos y servicios online para dar mayor flexibilidad y que además sus clientes accedan a de forma fácil, el único requisito es tener algún dispositivo con conexión a Internet. En este ensayo hablaremos sobre dos modelos de distribución de software que son útiles en lo mencionado anteriormente: ASP y SAAS.

En general, trabajan bajo un concepto llamado “Computación centralizada”, en el cual en vez de tener un servicio instalado en cada máquina cliente, se crea uno solo en un equipo central y los clientes acceden a este a través de la red (ya sea local o Internet). Con esto no hay la necesidad de instalar nada en nuestros equipos, sino que alquilamos un software a manera de servicio de manera remota a través de un navegador web.

Esta implementación trae muchas ventajas, como la actualización y mejoras del software, ya que al estar en la red, cuando se hace un cambio en el servidor, al momento de acceder los clientes tendrán las mejoras listas sin necesidad de hacerlo independientemente y de pagar por ello; además se ahorra dinero en soporte. Otra ventaja es que los usuarios no pagan licencias porque no se necesita instalar ningún software o complemento, en algunos casos los clientes pagan, pero solo una cuota mensual por el uso. Los servicios se vuelven muy flexibles, al estar en la red cuentan con una disponibilidad de 24 horas al día, los 7 días de la semana y la prestación de este desde cualquier lugar. Se evita el pirateo del producto.

Aunque parece perfecto, también tiene sus desventajas para tener en cuenta, la conexión de red juega un papel importante porque el rendimiento del servicio se verá afectado por esta. Algunos servicios funcionan bajo un navegador específico, lo que provoca malestar entre los usuarios y puede provocar el rechazo al uso. Un aspecto que genera mucha preocupación es la seguridad de los datos, ya que por lo general las empresas no gastan demasiado en esto o a veces encargan a terceros para esta labor. Tampoco podemos integrar estos servicios con los que tenemos en nuestro equipo.

ASP y SAAS son modelos similares, pero no hay que confundirlos como comúnmente se hace porque tienen aspectos que los hacen diferir. Uno de estos es el desarrollo de la aplicación; mientras en SAAS la empresa propietaria del servicio es la misma que la desarrolla y la provee, en ASP se busca a otra empresa solo para que aloje el servicio, lo que provoca que en SAAS el tiempo de implementación sea más rápido, las actualizaciones sean más rápidas y no tengan que pagar por soporte.

Otra diferencia notoria es que la mayor parte de las ASPs tienen una configuración única y personalizada por el usuario. En cambio en SAAS al estar dirigido a un mayor número de clientes es preferible que todos tengan un único modelo de datos, compartiendo algunos recursos como la base de datos y servidores.

Como podemos notar SAAS tiene una ligera ventaja, pero ambos modelos son usados en la actualidad para satisfacer las necesidades, y no sería raro que todas las empresas empezarán de ahora en adelante a funcionar así.

Aclarando conceptos: Arquitectura Cliente-Servidor y SOA

1. ¿Es lo mismo la arquitectura Cliente-Servidor que SOA? 

No es lo mismo ya que la arquitectura Cliente-Servidor básicamente es un modelo de distribución de información, en cuanto SOA es una arquitectura que básicamente toma el objetivo de una empresa para así empezar a interactuar con los clientes. 

2. ¿Es la arquitectura Cliente-Servidor la base de SOA? 

No es la base fundamental pero si tendrían algún tipo de relación como para poder montar un servicio para clientes estableciendo comunicación a través de la arquitectura Cliente-Servidor pero también tendríamos otra alternativa que sería montar un servicio para clientes. 

3. Cómo se acopla SOA y Cliente-Servidor con SAAS y ASP? 

Con SOA podríamos crear el servidor o el software dependiendo de su utilización y utilidad como servicio a un cliente y en Cliente-Servidor seria la plataforma para este servicio. 

En esta instancia entraría “SAAS” y “ASP”, ya dado este servicio lo podría dar a distribuir mediante SOA o SAAS, ya que este podría ser un servicio estándar para una organización. 

4. Estándares de SOA 

- Demandar la rentabilidad de la inversión en cada servicio: Incorpore cada servicio en un proceso de negocio activo que genere rentabilidad de la inversión (ROI). 

- Definir un Comité de Gestión de Servicios: El comité de gestión de SOA será el responsable de identificar los escenarios de uso de los servicios potenciales y evaluarlos para saber si se justifica la transformación de una función en un servicio. 

- Organizar adecuadamente los comités de gestión: Para organizaciones de desarrollo centralizado debe designar un único grupo que realice la evaluación, especificación y control de todos los servicios. Y para empresas con un modelo de desarrollo distribuido se debe en crear comités de gestión en torno a aplicaciones principales. 

- Crear y especificar tareas y responsabilidades: Normalmente, los procesos de negocio unidos por servicios abarcan varias aplicaciones y, muy frecuentemente, varias plataformas y organizaciones. Por eso resulta de vital importancia definir a los participantes clave y aclarar sus funciones. 

- Ir más allá de la solicitud-respuesta: No se pueden crear procesos de negocios reales únicamente con los servicios de solicitud-respuesta por esta razón se tiene que tener presente la necesidad de servicios dirigidos por eventos cuando establezca la capa de transporte de servicio de su infraestructura. 

- Tener en cuenta los estándares emergentes: Muchos de los estándares relacionados con SOA todavía están evolucionando. Si tiene que tomar una decisión sobre un estándar que se encuentra en proceso de formación, debe solucionar el problema inmediato con la tecnología disponible pero considerar el estado y planificar la futura incorporación de estándares emergentes. 

- Desarrollar para expandir y soportar todas las tecnologías y plataformas: Evite crear su infraestructura con enfoques SOA o soluciones que limiten sus opciones a plataformas, servidores de aplicación o lenguajes de programación específicos. 

5. ¿SOA es lo mismo que Web-service? 

No es lo mismo ya que SOA es la utilización de servicios para dar un soporte a los requisitos del negocio. Todos estos son servicios que implican análisis y por lo general da como resultado del negoció un Web-service, en este caso SOA es mucho más que eso ya que es la unión de muchos servicios débilmente acoplados. 

6. Ejemplos de implementación de SOA en Colombia. 

Banco Santander 

Coomeva 

Protección A.F.P. 

Davivienda