CLOUD COMPUTING

Es un término que se define como una tecnología que ofrece servicios a través de la plataforma de internet. Los usuarios de este servicio tienen acceso de forma gratuita o de pago todo depende del servicio que se necesite usar. 

 El término es una tendencia que responde a múltiples características integradas. Uno de los ejemplos de está “nube” es el servicio que presta Google Apps que incorpora desde un navegador hasta el almacenamiento de datos en sus servidores. Los programas deben estar en los servidores en línea y puedas accesar a los servicios y la información a través de internet.

Características del cloud Computing

Una de las principales diferencias del Could Computing es que no hay necesidad de conocer la infraestructura detrás de esta, pasa a ser “una nube” donde las aplicaciones y servicios pueden fácilmente crecer (escalar), funcionar rápido y casi nunca fallan, sin conocer los detalles del funcionamiento de esta “nube”.
Este tipo de servicio se paga según alguna métrica de consumo, no por el equipo usado en sí, sino por ejemplo en el consumo de electricidad o por uso de CPU/hora como en el caso de Amazon EC2. Entre otras características podemos mencionar:

• Auto Reparable: En caso de fallo, el ultimo backup de la aplicación pasa a ser automáticamente la copia primaria y se genera uno nuevo.
• Escalable: Todo el sistema/arquitectura es predecible y eficiente. Si un servidor maneja 1000 transacciones, 2 servidores manejaran 2000 transacciones.
• Regidos por un acuerdo de nivel de servicio (SLA) que define varias políticas como cuales son los tiempos esperados de rendimiento y en caso de pico, debe crear más instancias. En el caso de AWS aún se pregunta si su SLA es adecuado.
• Virtualizado: las aplicaciones son independientes del hardware en el que corran, incluso varias aplicaciones pueden corren en una misma maquina o una aplicación puede usar varias maquinas a la vez.
• Multiproposito: El sistema está creado de tal forma que permite a diferentes clientes compartir la infraestructura sin preocuparse de ello y sin comprometer su seguridad y privacidad.

Ventajas y desventajas del Cloud Computing

Entre las ventajas de la Clound Computing se pueden mencionar:

• Acceso a la información y los servicios desde cualquier lugar.
• Servicios gratuitos y de pago según las necesidades del usuario.
• Empresas con facilidad de escalabilidad
• Capacidad de procesamiento y almacenamiento sin instalar máquinas localmente.

Entre las desventajas podemos mencionar:

• Acceso de toda la información a terceras empresas.
• Dependencia de los servicios en línea.

¿QUE ES MDA?

Model Driven Architecture (MDA) es una aproximación para el refinamiento o síntesis de software. MDA ha sido propuesto por la OMG  y OMG´S MDA es una arquitectura  estándar creada y utilizada por la industria de manera innovadora. MDA está basado en transformaciones MOF (Meta Object Facility) y específicamente trata del tema de transformaciones entre modelos  y generación automática de código fuente.

MDA define el inicio del proceso de desarrollo bajo modelos PIM (Platform Independent Model), clasificación dada a modelos de software que son completamente independientes de plataformas o tecnologías en las cuales será implementado. Un modelo independiente de plataforma puede representar muchos modelos del tipo PSM (Platform Specific Model), como es para Java un modelo EJB, por ejemplo. Una vez de pose de un PSM, es posible generar el código fuente de la aplicación, siendo la más grande premisa de MDA lo de separar el espacio del problema y el espacio de la solución, es decir: la especificación de los procesos de la implementación de la solución. Dichos conceptos mejoran la calidad del software generado, posibilitando portabilidad e interoperabilidad entre aplicaciones. La calidad final del producto generado también es incrementada cuando la pensamos, mirando hacía un proceso manual y normal de desarrollo, susceptible a fallos y errores humanos. Model Driven Architecture viene a confirmar la necesidad actual de la industria, que busca siempre optimizar el complejo proceso de desarrollo, pues de hecho el número de tecnologías utilizadas en el actual panorama productivo de sistemas es algo que pone aún más complejo su desarrollo, eternamente en busca de mano de obra especializada a cada proyecto en tecnologías que debe abarcar.

MDA define un ciclo de vida completo para la concepción de software: diseño, desarrollo, integración y manutención haciendo uso de estándares abiertos. MDA representa una grande evolución y utiliza el estándar UML como lenguaje patrón en la definición de modelos transformables y XMI (Xml Metadala Interchange) para gestionar y representar modelos de software bajo el patrón XML.

La productividad y la calidad son ventajas que también deben ser citadas una vez que MDA permite transformaciones que visan ahorrar el trabajo de desarrollo, permitiendo pensar solamente en el espacio del problema, que es lo que de verdad importa. Otros beneficios citados son: Reducir el coste, reducir el tiempo, permitir un retorno más rápido bajo las aplicaciones desarrolladas y rápida inclusión de nuevos tecnologías en software legado.

MDA antes de más nada, fornece la base en nuestra estrategia de desarrollo automático orientado a SOA y teniendo como inicio la especificación de procesos de negocio haciendo uso de MAPS. 

http://www.m40s.com/mdaCast.aspx

¿QUE ES BPM?

BPM es “un conjunto de herramientas, tecnologías, técnicas, métodos y disciplinas de gestión concebidas para diseñar y ejecutar la automatización de procesos empresariales”.

Es decir, el BPM sirve para automatizar el ciclo de vida de los procesos. Todas las organizaciones realizan sus actividades según flujos de trabajo más o menos establecidos, y ese “más o menos” puede suponer el éxito o el fracaso de la empresa. Mediante las herramientas BPM una organización tendrá la posibilidad de definir en una aplicación informática sus procesos, organizar la información y el trabajo de las personas, controlar su ejecución en tiempo real y mediante una monitorización adecuada (indicadores, alertas, informes, cuadros de mandos) extraer conclusiones para alinearse con el objetivo último de lograr una mayor eficiencia.

Hay multitud de aplicaciones en el mercado que pueden ayudar a las empresas a definir y gestionar, de manera más o menos sencilla, sus procesos y contenidos. Destacan en general por ser herramientas ágiles y flexibles, que facilitan la capacidad de adaptación al cambio, sin que normalmente sea requerido un perfil técnico para implementar dichas modificaciones una vez implantado el sistema. La tendencia hace que se trate generalmente de herramientas web, que permiten comunicarse internamente a los empleados de la organización mediante portales empresariales, y que además ofrecen la posibilidad de abrir las puertas de la propia organización a clientes, proveedores, socios, etc., para que también éstos, si es necesario, intervengan de manera más activa en la ejecución de los procesos.


Es fácil intuir que para llevar a cabo una estrategia BPM se necesita tener cierto nivel de madurez empresarial y organizativa. El hecho de plantearse implantar un BPM, implica la necesidad de analizar qué y cómo se están haciendo las cosas en su empresa y si realmente dispone del control que necesita de sus procesos. Este acto de reflexión previo es realmente necesario, y como comentaremos en próximos post a este Blog, le permitirá abordar un proyecto de implantación de una herramienta BPM con mayor garantía de éxito.

http://prodintec.wordpress.com/2010/03/09/%C2%BFque-es-el-bpm/ 

¿QUE ES SOA?

La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje de programación, SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados.
Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.
La necesidad de tal marco se deriva de la evolución del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades específicas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue desarrollada sin consideración de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la empresa (como por ejemplo: la dirección del cliente) y funciones específicas de negocios (como por ejemplo: buscar un nombre) aparecían en todas partes y requerían un código complejo para, todos o muchos de los sistemas independientes.
Por consiguiente, los diversos sistemas de TI de la mayoría de las empresas hoy no pueden acceder o procesar los datos desde el uno al otro. Un simple proceso de negocio (como una venta para un pedido a un depósito enviado a una cuenta por cobrar) que tomaría segundos si los sistemas se podrían comunicar, ahora puede tomar semanas.
¿Qué puede hacer una empresa? Debería tener inversiones masivas en hardware, software y perfiles de individuos involucrados en la ejecución de cada una de las aplicaciones separadas? Con SOA, una empresa puede mantener sus inversiones en los sistemas legacy y la gente necesaria para mantenerlos. Esto evita continuos y costosos proyectos "de integración", como las mejoras a cualquier aplicación son transparentes a todas las otras. La información de negocio es siempre "hasta el último minuto", permitiendo mejores decisiones de negocio y mejorar las relaciones entre clientes y partners.
A menudo, SOA es una solución prometedora para los problemas de integración. El desafío es cómo llegar ahí.
Cómo crear un ambiente SOA El desarrollo de un ambiente SOA involucra un número de pasos. El primer paso es asegurar que todo el software nuevo que se instale sea compatible con SOA. El segundo paso es identificar las funciones dentro de los sistemas legacy que desean integrar y publicarlas como servicios. Por supuesto, esto no es tan fácil como suena. El desarrollo de estos servicios puede requerir de perfiles que no existen en la empresa. Y las herramientas necesarias para examinar los desarrollos y las etapas de despliegue pueden venir de diferentes proveedores, cada uno con su propia instalación, entrenamiento y temas de comunicación.

El Desarrollo de Aplicaciones Orientadas a Servicios (SODA) está diseñado para vencer muchos de los problemas de lenguajes de software inherentes en los sistemas legacy. SODA permite reutilizar aplicaciones existentes y proveer un camino para construir nuevas, basadas en estándares, con interfases flexibles.
Esta adopción habilita un alto nivel de abstracción tecnológica. Es decir, SODA encapsula y abstrae tecnologías tales como bases de datos, J2EE, .NET y CORBA de modo que los desarrolladores no afronten la complejidad técnica de la interacción con aplicaciones heterogéneas y sistemas de infraestructura. SODA así reduce significativamente el esfuerzo requerido para traducir nuevos desafíos de negocios dentro de aplicaciones funcionales.

http://tecnologia.iprofesional.com/notas/46399-Qu-es-SOA-la-arquitectura-orientada-a-servicios

¿QUE ES MDD?

El Desarrollo de Software Dirigido por Modelos (DSDM, también denominado MDD por su acrónimo en inglés, Model-Driven Development) es una propuesta para el desarrollo de software en la que se le atribuye a los modelos el papel principal de todo el proceso, frente a las propuestas tradicionales basadas en lenguajes de programación y plataformas de objetos y componentes de software.

Son varias las razones que han motivado la aparición de este nuevo paradigma. En primer lugar nos encontramos con la creciente complejidad de las aplicaciones de software, que han de satisfacer un mayor número de requisitos (heterogeneidad, distribución, alta disponibilidad, adaptabilidad, etc.) con mejores prestaciones y menores tiempos de desarrollo. Por otro lado, las nuevas tecnologías evolucionan demasiado deprisa (COM, DCOM, COM+, CORBA, CCM, J2EE, .NET, Web Services, SOA...), lo que hace que las inversiones en tecnologías concretas sean demasiado volátiles. Si bien es cierto que esos problemas no son nuevos en el campo de la Ingeniería de Software, está comprobado que la mejor forma de tratar con ellos es elevando el nivel de abstracción de los modelos desde las primeras etapas del desarrollo.

De hecho, el DSDM no es el primer intento por resolver este tipo de problemas. A lo largo de la evolución de la Ingeniería de Software hemos asistido a muchas propuestas para que los programas reflejen de una forma mejor y a más alto nivel, no sólo el dominio del problema, sino también para que traten de ocultar la complejidad de la tecnología sofware subyacente. Normalmente esto se ha llevado a cabo mediante la definición de lenguajes de programación, cada vez de más alto nivel (COBOL, Pascal, C, C++, Eiffel, Java, Python, Ruby, etc.), y la aparición de nuevas técnicas y mecanismos, por ejemplo los marcos de trabajo (frameworks) como Struts o Rails. Sin embargo, estos intentos no han conseguido lograr del todo su objetivo. Quizás una de las razones de su aparente fracaso es que estaban basados en las propias tecnologías del software, cuando es precisamente ahí donde residen la mayoría de los problemas.

Principios básicos del DSDM

Uno de los términos claves en la filosofía del DSDM es el concepto de modelo. De forma sencilla podríamos definir un modelo como una abstracción simplificada de un sistema o concepto del mundo real. Como tal, el modelo contiene un menor nivel de detalle que su correspondiente artefacto de la vida real. Sin embargo, ésta no es la única definición que encontraremos en la literatura sobre el término "modelo". A modo de ejemplo, las siguientes citas muestran algunas de las acepciones más comunes de este concepto en el ámbito de la Ingeniería de Software y del DSDM:

Un modelo es una descripción de un sistema, o parte de éste, escrito en un lenguaje bien definido. (Warmer y Kleppe, 2003).

Un modelo es una representación de una parte de la funcionalidad, estructura y/o comportamiento de un sistema (OMG, 2001).

Un modelo es una descripción o especificación de un sistema y su entorno definida para cierto propósito. Un modelo es representado habitualmente como una combinación de elementos gráficos y de texto. (Miller y Mukerji, 2003).

Según Wermer y Kleppe (2003), cada modelo se centra en la descripción de un único aspecto del sistema, de acuerdo a un propósito específico, y descrito hasta un cierto nivel de abstracción adecuado para el problema modelado. Tal descripción puede facilitarse de forma gráfica o textual (Miller y Mukerji, 2003), haciendo uso generalmente de lenguajes de modelado cuya semántica esté bien definida. A este respecto, la idea compartida por todos los paradigmas englobados dentro del DSDM es la conveniencia de utilizar para el modelado lenguajes de mayor nivel de abstracción que los lenguajes de programación habituales, esto es, lenguajes que manejen conceptos más cercanos al dominio de la aplicación. Así pues, dependiendo del ámbito DSDM que se trate, estos lenguajes que proporcionan mayor nivel de abstracción se denominanlenguajes de modelado (contexto de MDA) o lenguajes específicos del dominio (contexto de DSM y SF).

MODELO FLOR

El propósito del desarrollo de software es el desarrollo de un producto de software.
Los equipos no deben estar preocupados por el proceso de desarrollo del mismo.
Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final es alcanzado.
Construcción de prototipos
* Identificación de requerimientos
* Diseño rápido
* Utilizar el prototipo
* Revisar y mejorar
VENTAJAS Y DESVENTAJAS

• Útiles cuando los requerimientos son cambiables. 
• No se conoce cuando tengamos un producto aceptable.
• Cuando el usuario no se quiere comprometer con los requerimientos 
•  No se sabe cuántas iteraciones serán necesarias. 
• Cuando no se conoce bien la aplicación 
•  Dan una falsa ilusión al usuario sobre la velocidad del desarrollo. 
• Cuando se quiere probar una arquitectura o tecnología 
• Se puede volver al producto aun y cando no esté con los estándares . 
• Cuando se requiera rapidez en el desarrollo.  

http://es.scribd.com/doc/56609536/ModelosD
http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20-%2001.pdf

MODELO EN V

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

Ventajas y desventajas  del Modelo en “V”

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario