CICLO DE SOBREEXPECTACION PARA EL DESARROLLO DE APLICACIONES, 2014

Publicado: 29 de julio del 2014

Analista(s): Thomas E. Murphy, Nathan Wilson, Maritess Sobejana

Demandas de negocio digitales cambian tanto las aplicaciones que ofrece, así como el funcionamiento de las TI. Herramientas están siendo afectadas por la adopción de la nube y mecanismos sociales, pero muchas soluciones son inmaduras ya que el mercado evoluciona rápidamente.

TABLA DE CONTENIDOS

ANÁLISIS.......................................................................................................................................3

Qué necesitas saber.................................................................................................................3

El Hype Cycle............................................................................................................................3

Matriz de Prioridades...............................................................................................................5

OFF THE HYPE CYCLE................................................................................................................7

EN AUMENTO...........................................................................................................................7

SDA para servicios de aplicación..........................................................................................7

Comunidades de servicios de aplicaciones...........................................................................9

Java Enterprise Edition Version 7.......................................................................................11

Programación reactiva.......................................................................................................12

Desarrollo de escala Web...................................................................................................14

CEAP Productividad alta.....................................................................................................15

DevOps...............................................................................................................................17

Comunidad crowdsourced no probada..............................................................................19

Automatización de publicación de aplicaciones.................................................................21

Desarrollo orientado al funcionamiento............................................................................24

Web orientado a eventos...................................................................................................25

Contenedores móviles........................................................................................................26

Comunidad crowdsourced probada...................................................................................28

EN LA CIMA................................................................................................................................30

Diseño de aplicaciones optimizado en nube..........................................................................30

Desarrollo ágil de clase empresarial.......................................................................................31

ADLM PaaS.............................................................................................................................33

Gobierno de servicios de aplicaciones....................................................................................35

Página 1 de 43

Pruebas de software...............................................................................................................37

Desarrollo móvil híbrido.........................................................................................................39

Frameworks PaaS...................................................................................................................40

APIs web pública....................................................................................................................41

Diseño sensible.......................................................................................................................41

Gestión del portafolio de aplicaciones...................................................................................41

Herramientas UX....................................................................................................................41

Pruebas de seguridad de aplicaciones interactivas................................................................41

Desplazamiento en el canal........................................................................................................41

Tiendas de app móvil empresarial..........................................................................................41

Obtención y simulación de requisitos....................................................................................41

Gestión de datos de prueba...................................................................................................41

Apps.......................................................................................................................................41

Ocultación de datos dinámicos..............................................................................................41

Suites ADLM federadas..........................................................................................................41

Herramientas y servicio de prueba en la nube.......................................................................41

Pruebas SOA...........................................................................................................................41

Lenguajes de programación funcional....................................................................................41

Análisis de composición de software......................................................................................41

Versiones distribuidas............................................................................................................41

Escalando la pendiente..............................................................................................................42

Aplicaciones de gestión de proyectos y portafolio de TI........................................................42

Pruebas de seguridad de aplicaciones estáticas.....................................................................42

Integración continua..............................................................................................................42

Metodología de desarrollo ágil orientado a proyectos..........................................................42

Arquitectura orientada a web................................................................................................42

Ocultación de datos estáticos................................................................................................42

Desarrollo móvil nativo..........................................................................................................42

Apéndices...................................................................................................................................42

Fases del ciclo Hype, índice de beneficios y niveles de madurez............................................42

Lectura recomendada Gartner...............................................................................................42

Página 2 de 43

LISTA DE TABLAS

Tabla 1. Fases Hype Cycle...........................................................................................................42

Tabla 2. Clasificación beneficio...................................................................................................42

Tabla 3. Niveles de madurez......................................................................................................42

LISTA DE FIGURAS

Figura 1. Ciclo de sobre-expectación para el desarrollo de aplicaciones, 2014............................4

Figura 2. Matriz de prioridades para el desarrollo de aplicaciones, 2014....................................6

Figura 3. Ciclo de sobre-expectación para el desarrollo de aplicaciones, 2013..........................42

ANÁLISIS

Qué necesitas saberEl mercado de desarrollo de aplicaciones (AD) está siendo afectado por una serie de factores incluyendo ágiles, DevOps, computación móvil y el cambio a la computación en nube. TI está bajo una creciente presión debido al manejo de negocio digital para ofrecer soluciones innovadoras que implican una colaboración más estrecha y más rápida al mercado, el interés en los principios DevOps y una necesidad de nuevas competencias en el desarrollo móvil, la nube y la experiencia del usuario (UX). Los vendedores están respondiendo con una plétora de nuevos productos, muchos de los cuales son actualmente soluciones parciales.

Como ves en las tecnologías a lo largo del lado izquierdo de la tabla del Disparador Innovación al Apogeo de Expectativas Infladas, verás que hay una fuerte inclinación hacia las tecnologías de nube, móviles y DevOps. Líderes de desarrollo de aplicaciones deben continuamente admitir nuevas tecnologías y disciplinas para mantener sus empresas competitivas. Sin embargo, usted debería esperar que estas soluciones vayan cambiando drásticamente y con frecuencia son fragmentos de la solución completa, y por lo tanto deben ser utilizados con una mentalidad de solución táctica. Utilice este Hype Cycle como guía para controlar el desarrollo de estas tecnologías y disciplinas, que adoptan cuando encajan en la estrategia de su organización.

El Hype CycleDesarrollo móvil se está convirtiendo en una competencia básica necesaria para las organizaciones de AD (notar que esta investigación crea una visión específica para móviles de DA). Nuevas herramientas, frameworks y plataformas requieren un cambio significativo en las habilidades necesarias en la organización de AD. Mientras AD móvil se ha convertido en un punto focal para la mayoría de las organizaciones, las herramientas, normas y prácticas están siendo sometidas a una gran cantidad de cambios. La demanda de TI impulsa más allá de su zona de confort, requiriendo empresas para adoptar tecnologías en fase inicial lo más pronto que harían normalmente. A menudo, esto se ha hecho a través de las relaciones con terceros por la externalización del desarrollo y prueba de aplicaciones móviles. Sin embargo, a medida que seguimos adelante para permitir que los negocios digitales, estas tecnologías, habilidades y prácticas organizacionales deban madurar.

El empuje constante para las organizaciones de TI a ser más sensible está obligando a las metodologías de DA sobre el punto de inflexión. Ágil está creciendo rápidamente y más organizaciones están

Página 3 de 43

eliminando los métodos tradicionales de cascada por ser demasiado lento. Mientras ágil está madurando, encontrando cómo escalar al otro lado de los roles y de grandes proyectos es todavía relativamente nuevo. El creciente reconocimiento ahora es que una entrega más rápida requiere algo más que el desarrollo ágil, que está controlando el impulso a las prácticas DevOps y cambiando el enfoque alejándose de una mentalidad de proyecto a una mentalidad de producto. Los ítems de metodología en este Hype Cycle reflejan las prácticas que se pueden utilizar para mejorar la eficacia de una organización ágil. Es importante señalar que los desafíos no son puramente tecnológicos y cambios de herramientas, pero un gran cambio en una cultura que debe extenderse más allá de la organización de TI. Los primeros en adoptar han sido capaces de lograr resultados positivos en la mejora de tiempo de mercado y reducir los tiempos totales de iteración, permitiendo así a los negocios a ser más sensible y obtener un feedback de mercado más rápido.

Para una visión general de la madurez de estos nuevos temas, así como la evolución de los otros temas de AD que damos seguimiento, véase la figura 1.

Página 4 de 43

Figura 1. Ciclo de sobre-expectación para el desarrollo de aplicaciones, 2014

Página 5 de 43

Matriz de PrioridadesSi bien hay algunas importantes tecnologías proyectadas para convertirse en la corriente principal en el próximo año, la tarea más importante para las organizaciones de TI es prepararse para el gran número de tendencias transformacional y de alta importancia que se convertirá en la corriente principal en los próximos dos a cinco años. Estos impactos son numerosos y lo suficientemente grande para que las organizaciones no puedan esperar a que entren la categoría "dos años o menos" antes de dirigirse a ellos. Los temas principales de estos elementos son similares a la Hype Cycle en general. Las tecnologías disruptivas centrados en la nube y móvil va a cambiar el tipo de aplicaciones que desarrollamos, mientras que las metodologías ágiles, integración continua y automatización de publicación cambiarán la forma en que los desarrollamos.

Ninguna de las tecnologías y disciplinas AD obtuvo una calificación de "bajo beneficio" en la Matriz de prioridades. Este es el resultado de la concentración de esta Hype Cycle sólo en las tecnologías y disciplinas que tienen el mayor impacto en el negocio (ver figura 2).

Página 6 de 43

Figura 2. Matriz de prioridades para el desarrollo de aplicaciones, 2014Beneficio Años a la aprobación generalizada

Menos de 2 años 2 a 5 años 5 a 10 años Más de 10 años

Transformacional Metodología de desarrollo ágil orientada a proyectos

AppsAPIs web pública

DevOps

Alto

Aplicaciones de gestión de proyectos y portafolios de TI

Desarrollo móvil nativo

Arquitectura orientada a web

Gobierno de servicio de aplicaciones

Herramientas y servicios de pruebas en nube

Diseño de aplicaciones optimizado en nube

Desarrollo móvil híbrido

Contenedores móviles

Obtención y simulación de requisitos

Diseño sensible

SDA para servicio de aplicaciones

Pruebas SOA

Pruebas de seguridad de aplicaciones estáticas

Ocultación de datos estáticos

Gestión de datos de prueba

Automatización de publicación de aplicaciones

Desarrollo orientado al funcionamiento

Desarrollo ágil de clase empresarial

CEAP Productividad alta

Pruebas de seguridad de aplicaciones interactivas

Desarrollo a escala web

Gestión del portafolio de aplicaciones

Moderado

Integración continua Pruebas de software

Versiones distribuidas

Tienda de app móvil empresarial

Suites ADLM federadas

Lenguajes de programación funcional

Frameworks PaaS

Programación reactiva

Análisis de composición de software

Comunidad crowdsourced probadas

ADLM PaaS

Comunidades de servicios de aplicaciones

Ocultación de datos dinámicos

Web orientado a eventos

Java Enterprise Edition versión 7

Comunidad crowdsourced no probada

Herramientas UX

Bajo

A partir de julio de 2014

Fuente: Gartner (julio 2014)

Página 7 de 43

OFF THE HYPE CYCLEEste año el contenido del Hype Cycle permaneció relativamente constante al año pasado. Nosotros no presentamos un gran número de artículos, debido parcialmente a que el frente-final del ciclo ya está sobrecargado.

Arquitecturas modelo-impulso fueron marcados como "obsoleto antes del altiplano" el año pasado y fue removido del Hype Cycle de éste año.

Programación conjunto, una idea interesante que no ha ganado fuerza en el mercado se ha removido.

Plataforma de aplicación Cloud - habilitada (CEAP) se ha dividido en dos perfiles: frameworks PaaS y la alta - productividad CEAP para representar mejor a las variaciones del mercado.

También hemos añadido un nuevo perfil, comunidades de servicios de aplicación, debido a la creciente utilización de multitud de fuentes o el desarrollo comunitario como un apoyo a la innovación ágil.

EN AUMENTO

SDA para servicios de aplicaciónAnálisis por: Yefim V. Natis

Definición: Arquitectura definida por software (SDA) es un patrón de diseño donde una capacidad de TI se virtualiza por la exposición de un conjunto de APIs virtuales. SDA para servicios de aplicaciones (SDAS) virtualiza servicios de aplicación. API de servicios virtuales son traducidos por un intermediario (capa de puerta de enlace), lo cual puede introducir algunas capacidades adicionales sustanciales en la gestión, la agilidad y el enriquecimiento de los servicios de aplicaciones. Los consumidores operan servicios de aplicaciones virtuales, diseñadas para satisfacer los requisitos de los mejores consumidores, desacopladas de la arquitectura interna de las aplicaciones.

Justificación de rapidez de posición y adopción: Amplio uso de la arquitectura orientada a servicios (SOA) provocada por la adopción generalizada de múltiples canales, la nube y las aplicaciones móviles, crea grandes y crecientes colecciones de las API de servicios que requieren la gestión de su seguridad, el cumplimiento, la escalabilidad, la optimización de costes y la racionalidad de sus principios de diseño. Para controlar los entornos de aplicaciones de estilo SOA, las principales organizaciones de TI aplican el modelo de SDA a la gestión de sus API de estilo SOA.

SDA se origina a partir de modelos como el definido por software de redes y almacenamiento definido por software. En su esencia es el principio de la virtualización de una capacidad de TI con el objetivo primordial de la estandarización, incluso la mercantilización de la capacidad (o la creación de redes de almacenamiento de productos de hardware en estos casos). SDA permite que el mundo de las API virtuales y la API "físico" para evolucionar de forma independiente. En el caso de almacenamiento definido por software, por ejemplo, las APIs propietarias internas del hardware de almacenamiento son sustituidos por las API de propósito general externalizados que ya no se acoplan con el hardware subyacente. Como resultado de ello, el hardware de almacenamiento se puede actualizar, cambiar y se mezcla sin necesidad de un cambio en el diseño de las aplicaciones que utilizan el almacenamiento. El software intermediario que traduce las APIs estandarizadas externas a las APIs propietarias internas también se puede utilizar para añadir más valor, como la gestión, el seguimiento, la optimización o la seguridad.

Página 8 de 43

Cuando se aplica a los servicios de aplicaciones, SDA actúa como la extensión de los principios de SOA centrales. El nuevo principio es la introducción de las API virtuales. Estos representan las capacidades funcionales, pero no las aplican directamente. En vez, conducen a una capa de control de la virtualización (gateway SDA) donde se convierten a algún patrón de invocaciones de la API de interiores "físicas", aquellos que están directamente asociados con implementaciones de servicios y, en definitiva los datos de la aplicación. La puerta de entrada SDA se convierte en un intermediario entre el mundo exterior que ve las API virtuales y las aplicaciones. Más allá de la virtualización de API de servicios de aplicaciones, la puerta de entrada SDA permite el seguimiento, control y facturación del tráfico de invocación, la adición de la seguridad, la vigilancia del cumplimiento y una variedad de otras capacidades de valor añadido. Una capacidad notable es la oportunidad para que los consumidores puedan crear sus propias APIs virtuales que no tienen acceso directo a la base de aplicaciones y bajo un estricto control de la puerta de entrada SDA. La puerta de enlace puede ser distribuido, replicado y federado para evitar la creación de cuellos de botella o un punto único de fallo.

Para inyectar control en el gráfico cada vez mayor de servicios de aplicación asociados con la práctica de la difusión de SOA en el diseño de aplicaciones, las principales organizaciones de TI utilizan tecnologías tales como gestores de la API, puertas de enlace de la API, plataformas de gobierno de SOA y algunos buses de servicios empresariales más avanzadas y iPaaS, cada uno de los cuales es equipada en algún grado para la gestión de una biblioteca de APIs. Para la mayoría de las organizaciones, el uso de esta tecnología es el medio para un objetivo táctico de consolidar las gestiones básicas de la API. Pocas organizaciones hasta ahora ven este enfoque como un patrón arquitectónico, lo que requiere el diseño, la planificación, la disciplina y el cumplimiento de las políticas (como el aislamiento de las API exterior e interior).

SDA relativamente maduro en algunas áreas específicas (tales como definido por software de redes y almacenamiento), pero no es reconocido como un modelo arquitectónico general aplicable en muchos contextos que sufren alta complejidad y escala desafiante. SDA aplica a las aplicaciones y servicios de aplicación aún no está igualmente reconocido como un modelo arquitectónico valioso incluso por las organizaciones que ya tácticamente (y accidentalmente) se aplican algunos de sus principios. Sin embargo, Gartner cree que en los próximos dos a cinco años la mayoría de las organizaciones de TI a su vez a SDA y SDAS como el avance de la SOA, enriquecido con las oportunidades de la inyección de la gestión, la seguridad, la privacidad, el cumplimiento, seguimiento y facturación, seguimiento de la actividad empresarial, la capacidad de recuperación control, optimización escala y el contexto en el funcionamiento de la gráfica de escala Web ágil y abierto de servicios de aplicaciones. La virtualización de servicios de aplicaciones a través de SDA permitirá innovación seguro alrededor de los activos de información de la empresa. Como proveedores de tecnología pertinentes reconocen la puntuación de oportunidad que representa SDAS, Gartner espera un rápido crecimiento de la promoción, la inversión y sobre expectación (antes de la adopción masiva trae a la realidad y, finalmente, a su meseta de la productividad).

Consejo al usuario:

Utilice los principios fundamentales de SOA en la mayor parte del diseño de la aplicación. Construir la tecnología para controlar el acceso y la interacción entre las API de servicios. Comenzar a diseñar y gestionar APIs externas por separado del servicio de API interno para las

aplicaciones bajo su gestión.

Página 9 de 43

En la selección de tecnologías de gestión de API, dar preferencia a los proveedores que tengan una visión estratégica para el papel de esta tecnología en las operaciones de una organización de TI y tienen una hoja de ruta para aumentar el alcance de sus capacidades técnicas.

Impacto en el negocio: SDA aplica a los servicios de aplicaciones SOA permite a escala Web. Introducción de los principios arquitectónicos rectores para la gestión de entornos SOA a gran escala permitirá a las principales organizaciones de TI a escalar e innovar, evitando el aumento de los riesgos para la integridad o la rendición de cuentas de sus operaciones. Negocio digital Web-escala en la corriente principal de TI no puede materializarse sin tal sistema emergente de gestión y control. Con ello, las empresas dominantes pueden esperar mayores tasas de innovación, de escala más fácil y la cooperación avanzada entre negocios, TI, clientes y socios de la empresa.

Clasificación Beneficio: Alto

Penetración de mercado: 1% a 5% de audiencia objetivo

Madurez: Emergentes

Los vendedores de la muestra: Apigee; Axway (Vordel); CA (Capa 7); IBM; Intel (Mashery); MuleSoft; Software AG; WSO2

Lectura recomendada: "Transforme su negocio con el Nexus de Fuerzas"

"El efecto Nexus y Cómo el Nexus de Fuerzas altera establecidos Modelos de arquitectura"

"El efecto Nexus: Cómo Cloud Computing altera establecidos Modelos de arquitectura"

"La arquitectura orientada a servicios"

Comunidades de servicios de aplicacionesAnálisis por: Gilbert van der Heiden; Kris Doering

Definición: las comunidades de servicios de aplicación se refieren a la utilización comercial de los proveedores de servicios de multitud de abastecimiento para ofrecer servicios de aplicaciones para usuarios finales organizaciones. Los proveedores de servicios pueden crear su propia comunidad de multitud de fuentes internas con su banco de empleados que tienen habilidades de plataforma de aplicación distinta y experiencia. Por otra parte, los proveedores de servicios pueden incrustar comunidades de multitud de fuentes externas en sus propios modelos de entrega globales o locales. En cualquier caso, el proveedor de servicios controla la interacción con el usuario final.

Justificación de rapidez de posición y adopción: Comunidades de servicios de aplicación están todavía en su infancia y verán tracción en línea con el creciente interés en la multitud de abastecimiento y comunidades especialmente multitud de fuentes. Ya ha habido muchas interacciones con los proveedores de servicios y usuarios finales para hacer frente a su acercamiento a, y el interés en, el crowdsourcing. Aunque se identificó un crecimiento definitivo de las comunidades de multitud de fuentes, comunidades servicios de aplicaciones Sin embargo, han visto más baja tracción. Los proveedores de servicios están probando el agua con sus propias ofertas multitud de fuentes basado en sus bancos internos. Con un promedio de utilización de 80%, los proveedores de servicios, por tanto, tienen un 20% de los recursos disponibles en un momento dado para que actúen como "la multitud". Cuando los proveedores de servicios están utilizando su público interno como parte de sus servicios de aplicaciones externas para sus clientes, estas multitudes se convierten en comunidades de servicios de aplicación.

Página 10 de 43

Las interacciones con los proveedores de servicios han dado lugar a ejemplos anecdóticos de algunos proveedores de servicios que utilizan las comunidades de servicios de aplicaciones basados en los recursos internos para servicios de pruebas. Hay un ejemplo de un proveedor de servicios globales que creó una comunidad de servicios de aplicación en cooperación con un cliente en la industria de servicios financieros. Esta distinta oferta de comunidad es en realidad un portal de crowdsourcing en toda regla, con los servicios de aplicación del concurso impulsado por el cliente, con el apoyo de la multitud proveedor de servicios. Dependiendo del éxito, un proveedor de servicios puede agregar recursos crowdsourced externos para hacer frente a las demandas del cliente. Desde la perspectiva del cliente, el proveedor de servicios sigue siendo responsable del servicio respecto a los niveles de servicio acordados. En este momento no hay ejemplos de comunidades de aprovisionamiento de aplicaciones que son controlados e impulsados por los usuarios finales.

Como una comunidad de servicios de aplicación va comúnmente estar compuesto por empleados internos al proveedor de servicios, y el costo total de las comunidades de servicios de aplicación no puede ser menor que el despliegue de los servicios tradicionales a base de entrega globales de desarrollo de aplicaciones. Sin embargo, los beneficios de las comunidades de servicios de aplicaciones a un usuario final serán de potencial más alto de los servicios innovadores, menor tiempo de comercialización de nuevas soluciones, una mayor experiencia de usuario de los entregables y una mayor calidad de la funcionalidad de la aplicación desarrollada.

Con el aumento de la tracción de colaboración abierta distribuida en general, y las comunidades crowdsourced específicamente, se espera que la tracción a las comunidades servicios de aplicaciones se acelere. Los proveedores de servicios que actualmente están probando las capacidades internas de crowdsourcing van a comercializarlos una vez se hayan identificado el modelo adecuado para flexionar los recursos, y abordar los riesgos y obligaciones comerciales, al tiempo que ofrece mejores garantías al usuario final los clientes en competencia con las empresas de colaboración abierta distribuida.

Consejo al usuario: Los usuarios finales considerando crowdsourcing para servicios de aplicación deben determinar, en primer lugar, el interés interno y la voluntad de invertir en el crowdsourcing. Como mínimo, debe haber un compromiso de los propietarios de aplicaciones para desplegar crowdsourcing para sus aplicaciones, aunque se produzcan a través de un acuerdo de servicios gestionados con un proveedor de servicios. Entonces la organización debería identificar los proveedores de servicios que tienen la capacidad de soportar los servicios de aplicación y verificar el enfoque proveedores para aplicar crowdsourcing como parte de sus servicios de aplicación.

Desde una perspectiva del usuario final las organizaciones deben buscar un enfoque profesionalizado para implementar comunidades de aplicación, ya sea originaria con un banco público interno o capacidades multitud externos. Profesionalizado implica el uso de una Declaración de Trabajo (servicios) en virtud de un acuerdo de servicio formal (compromisos, los objetivos, IP, indemnización, garantías) con las métricas relacionadas (como fugas defecto, a tiempo, dentro del presupuesto de funcionamiento de transacción, la productividad) y la fijación de precios crowdsourcing (por defecto, sólo para la solución ganadora, por proyecto y resultado).

Impacto en el negocio: No hay duda de que el uso de las comunidades de aplicación tendrá un impacto claro, ya que refleja la nueva ola de reducción de costes en la prestación de servicios de aplicación después de abastecimiento global. Tenga en cuenta que el abastecimiento de la comunidad y de entrega global no es mutuamente exclusivo. Tampoco el abastecimiento de la comunidad va a reemplazar la entrega global. La fuente de la comunidad de aplicaciones es sólo otra manera de la entrega de servicios de aplicación y se debe utilizar junto con la entrega global.

Página 11 de 43

Estas capacidades de expansión están actualmente impulsadas principalmente por la expansión de las empresas que ofrecen servicios de crowdsourcing, basados en la comunidad de servicios. Empresas de crouwdsourcing están ofreciendo servicios “probados” y “no probados” basados en la comunidad de servicios que compiten con los servicios de aplicaciones tradicionales para aumentar grandes ofertas. Además TopCoder (desarrollo) y uTest (pruebas) a compañías como Ziptask, Kaggle, CrowdFlower, Passbrains y Elance, por nombrar algunos, todos ofrecen servicios profesionales para ayudar a las organizaciones de usuarios finales desplegar sus multitudes.

Los servicios incluyen asesoramiento sobre la selección de las personas para las comunidades definidas, seguido por la dirección potencial de la comunidad en nombre del cliente; con las políticas de seguridad y cumplimiento incluido y los requisitos de la agregación de capacidades de gestión y diseño.

Organizaciones de usuarios finales que consideren el uso de fuentes comunitarias de aplicación ya pueden desafiar a sus proveedores de servicios de aplicaciones instaladas, ya que muchos están poniendo a prueba la fuente comunitaria de aplicación en función de sus capacidades internas del banco. Puede ser que no promueven activamente en el momento, pero el tiempo ha llegado para poner un poco de presión sobre los proveedores!

Clasificación Beneficio: Moderado

Penetración de mercado: 1% a 5% de audiencia objetivo

Madurez: Emergentes

Los vendedores de la muestra: CrowdFlower; Elance; Freelancer.com; GetACoder; Guru; Kaggle; Passbrains; topcoder; uTest; Ziptask

Lectura recomendada: "Piloto del empleo de Comunidades Crowdsourced para el desarrollo de aplicaciones para lograr innovación ágil"

"El aprovechamiento de un pozo de Talento Global a través de crowdsourcing puede aumentar la velocidad y ofrecer innovación"

"Recursos Externos 2014: Aprovechando las tendencias de mercado clave va manejar la agilidad, velocidad y la Innovación empresarial"

"Usar Crowdsourcing como multiplicador de la fuerza en el desarrollo de aplicaciones"

Java Enterprise Edition Version 7Análisis por: Mark Driver

Definición: Plataforma Java, Enterprise Edition (Java EE) es un Proceso de la Comunidad Java (JCP), arquitectura gestionada y modelo de programación para aplicaciones empresariales Java multiplataforma. Java EE es implementado como servidores de aplicaciones Java EE por muchos comerciales y algunos de código abierto, proveedores al estilo de la comunidad.

Justificación de rapidez de posición y adopción: El modelo de programación Java EE domina proyectos de software empresarial de gama alta. Decenas de miles de empresas dominantes utilizan Java EE como su plataforma para aplicaciones de misión crítica. Los principales proveedores de software de aplicaciones independientes (ISVs) y proveedores de infraestructura de aplicaciones utilizan Java EE para el nuevo desarrollo de software. Las implementaciones de plataformas van de alto costo, de alta gama a bajo costo, las ofertas del mercado de masas.

Página 12 de 43

Aunque Java EE versión 6 es corriente hoy en día, las nuevas versiones de Java EE han tomado tradicionalmente varios años para alcanzar una masa crítica de adopción; en consecuencia, no esperamos que Java EE Versión 7 para reemplazar la mayoría de despliegues Java EE 6 durante al menos tres años.

Consejo al usuario: JCP ofrece casos de pruebas de cumplimiento y las implementaciones de referencia para los componentes de Java EE. Java EE versión 6 es la corriente principal y fuertemente apalancadas a través de la industria de TI hoy en día; la más reciente edición de la especificación Java EE, versión 7, fue aprobado oficialmente por el grupo de trabajo JCP en abril de 2013. Una de las áreas clave de Java EE es el fortalecimiento y la ampliación de características y funciones en la nube centrada. Con este fin, Java EE 7 añade nuevas tecnologías web, tales como HTML5, la especificación WebSocket, JavaScript Object Notation (JSON) y apoyo REST. Como se sospechaba, esta versión también mejora en la tecnología de Inclusión de Contextos y Dependencias (CDI) de Java EE. En general, sin embargo, esperamos que Java EE 7 sirva como un comunicado de transición, permitiendo a Oracle y sus socios del JCP para abordar de manera más agresiva diseños de aplicaciones en la nube centrada en la versión de Java EE 8. Java EE 7 se centra en apuntar y mejorar las características tecnológicas bien establecidas, pero también añade elementos fundamentales (es decir, la especificación WebSocket) para permitir a Java EE 7 (y versiones futuras) apoyar de manera más agresiva aspectos en la nube centrada.

Preste mucha atención a las características y funciones dentro de la especificación Java EE 7, en la medida en que es la primera de varios avances que sustancialmente van a modernizar y transformar el diseño de aplicaciones Java para apoyar plenamente el diseño en nube centrada.

Como era de esperar, varias aplicaciones Java EE líderes del mercado han apoyado partes de la especificación Java EE 7 antes de que estas características fueran publicadas oficialmente; sin embargo, la certificación oficial de Java EE 7 entre los servidores de aplicaciones principales pueden retrasarse por varios meses (incluso años).

Impacto en el negocio: Las nuevas características de Java EE aumentan sustancialmente la productividad del desarrollador y permitirán a los desarrolladores apuntar implementaciones en nube a un costo menor. Por otra parte, continuando con la inversión estratégica por ISVs, incluyendo grandes proveedores, como SAP y Oracle, solidifica aún más el largo plazo el poder de permanencia de Java y el modelo de programación estándar Java EE. Sin embargo, Java EE tiene el reto de evolucionar más allá de su centro de datos enfocada en la historia de abarcar y apoyar directamente emergentes modelos de diseño de aplicaciones en la nube central. Java EE 7 es la primera versión para apoyar directamente a esta transición, pero toda esta transición se llevará a varias versiones de Java EE y varios años en completarse.

Clasificación Beneficio: Moderado

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Emergentes

Los vendedores de la muestra: IBM; Oracle; Red Hat (JBoss); SAP

Programación reactivaAnálisis por: Mark Driver

Página 13 de 43

Definición: Programación reactiva es un modelo de diseño del programa enfocado a los flujos de datos y la propagación de cambiar los valores de datos. Con este fin, la programación reactiva y mejores prácticas también incorporan elementos de programación orientada a eventos - es decir, secuencias de solicitud/respuesta asíncronas y sin bloqueo.

Justificación de rapidez de posición y adopción: El concepto de programación reactiva y temas relacionados, tales como la programación reactiva funcional y programación orientada a eventos no son nuevos en la informática; estos conceptos se remontan a varias décadas. Pero al igual que la programación funcional y procesamiento masivamente paralelo, este tema ha hecho recientemente su camino en los portafolios y las prácticas de moderna, convencional, organizaciones de desarrollo de aplicaciones centrada a TI a través de los requisitos del proyecto "escala Web". Patrones y técnicas de diseño de programación reactiva soportan aplicaciones masivamente escalables, centrándose en las rutas de comunicación asíncronos - aspectos críticos de soluciones en la nube de la próxima generación. Esperamos que el interés y la posterior sobre expectación alrededor de la programación reactiva a crecer hasta el año 2016 como la siguiente generación de soluciones a grandes datos y móviles exigen nuevos enfoques para que coincida con los requisitos de escala masiva.

Consejo al usuario: Considerar el papel de patrones de diseño de programación reactiva, mejores prácticas y tecnologías de apoyo para hacer frente a las necesidades de los sistemas de próxima generación que deben procesar grandes cantidades de datos de eventos en tiempo real. Estas tecnologías pueden simplificar el proceso de desarrollo y reducir los costos de mantenimiento a largo plazo, pero vendrán a costa de nuevas adopciones de tecnología (por ejemplo, las lenguajes y frameworks) y nuevos conjuntos de habilidades de desarrollador.

Impacto en el negocio: Programación reactiva tiene muchas similitudes con el patrón observador utilizado comúnmente en la programación orientada a objetos. Sin embargo, integrando los conceptos de flujo de datos en el lenguaje de programación harían más fácil expresar estos conceptos y podrían por lo tanto incrementar la granularidad de la gráfica de flujo de datos. Por ejemplo, el patrón observador comúnmente describe los flujos de datos entre el conjunto objetos/clases, mientras que la programación reactiva orientada a objetos podría apuntar a los miembros de objetos/clases. Las técnicas y tecnologías de programación reactiva van a hacer su camino en la mayoría de los principales portafolios de TI hasta el 2018. Sin embargo, la mayoría de los adoptantes no abandonarán las inversiones existentes; más bien, las plataformas principales ampliarán para apoyar nuevos lenguajes y frameworks, y algunos lenguajes y frameworks líderes en el mercado van a evolucionar para apoyar estos conceptos también.

Clasificación Beneficio: Moderado

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Emergentes

Los vendedores de la muestra: Joyent; Typesafe

Lectura recomendada: “Nuevas prácticas en arquitectura de aplicaciones: Qué aprender de los grandes sitios web”

“El efecto Nexus y cómo el Nexus de fuerzas alteran los modelos de arquitectura establecidos”

Página 14 de 43

Desarrollo de escala WebAnálisis por: Nathan Wilson

Definición: Basado en los principios de manufactura escasa aplicadas al desarrollo, el desarrollo de escala Web se centra en el ajuste de desarrollo en un flujo constante de la funcionalidad de la idea a la producción. Utilizando Kanban, cada historia se empuja en la producción, ya que se ha completado. Cuando sea necesario, alterna funcionales y otras técnicas de despliegue oscuro para ocultar la funcionalidad hasta que otras historias están completas. Desarrollo de escala Web requiere que los equipos que tienen una definición bien desarrollada de pruebas de unidad, funcionales y de aceptación automatizados "Lista" y extensas.

Justificación de rapidez de posición y adopción: En el último año, ha habido un aumento en el número de organizaciones de TI que desean adoptar modelos de desarrollo de flujo continuo de escala Web. Para reflejar esto, el perfil de la tecnología "Desarrollo Kanban" ha pasado a denominarse "Desarrollo de escala Web". También se ha movido rápidamente por la ladera de la Ilustración hacia el pico de expectativas infladas.

Es típico para las empresas adquirir tres a cinco años de experiencia en el desarrollo ágil antes de que tengan los procesos, herramientas y suites amplias pruebas que se requieren para este modelo de desarrollo. El dominio de una metodología basada en las iteraciones es un requisito previo para esta metodología de desarrollo. En orden para que esta metodología tenga éxito, una organización necesita tener un bien definido y - seguida definición de hecho (DOD). El DOD debe especificar todas las tareas que deben completarse para una historia a ser lanzado a la producción. Se necesita un conjunto completo de pruebas automatizadas con el fin de tener confianza en que los cambios no han introducido defectos significativos. Como la velocidad de liberación de los sistemas de producción aumenta, prácticas y herramientas DevOps maduras se vuelven más esenciales.

Consejo al usuario: Desarrollo a escala web debe ser un objetivo a largo plazo para los equipos ágiles. Siga principios magros de la mejora continua, lotes pequeños y tiempos de ciclo reducidos mediante la reducción progresiva de la duración de la iteración de los proyectos. Enfoque tiempo en la eliminación de obstáculos para ciclos más cortos y combinando cadencia de desarrollo para el resto del proceso. Mejorar la cobertura de prueba automatizada, e invertir en herramientas DevOps que permitan a los ciclos de pruebas de regresión y de implementación ser más rápidos.

Una vez que una organización es competente en iteraciones y duraciones semanales, y se ha desarrollado un amplio abanico de pruebas automatizadas, está listo para pasar a un proceso de desarrollo escala web/kanban.

Una vez que se eliminan las iteraciones, es esencial para continuar la programación retrospectiva regular para apoyar la mejora continua. Habilidades de gestión críticos incluyen ajustar el correcto trabajo en los límites de progreso (WIP) y actuar para reducir el tiempo de ciclo de inicio de una historia para su implementación en el sistema de producción.

Impacto en el negocio: Desarrollo de escala Web puede proporcionarse al desarrollo de software más sensible disponible actualmente. El carácter continuo de desarrollo de escala Web es un cambio importante de la práctica actual de proporcionar un gran conjunto de cambios en un solo lanzamiento. Pasar de proyectos para producir software comunica a que un flujo continuo de software requerirá cambios generalizados, tanto dentro como fuera de las TI.

Página 15 de 43

La capacidad de respuesta que está habilitado por el desarrollo de escala Web debe estar combinado con una priorización rigurosa del trabajo estando ejecutado para asegurarse de que la funcionalidad más importante para la organización sea entregada lo más rápido posible. Es importante que el desarrollo de escala Web este hecho en conjunto con los procesos DevOps y herramientas de implementación automatizada de manera que el flujo global de las mejoras de software puedan estar sincronizadas e incrementadas.

Clasificación Beneficio: Alta

Penetración de mercado: menos que el 1% de audiencia objetivo

Madurez: embrionario

Lectura recomendada: “Habilitar la agilidad corporativa mediante prácticas de desarrollo a escala web”

“El impacto de DevOps y escala web de TI en el desarrollo de aplicaciones”

“El logro de Entrega Continua”

“Pasar de un basado en proyectos a una Organización de aplicaciones basado en producto”

CEAP Productividad altaAnálisis por: Yefim V. Natis

Definición: De alta productividad, plataformas de aplicaciones habilitado en nube (CEAP) son software para la creación de una aplicación PaaS privada (aPaaS), una aPaaS o SaaS públicas. CEAP Productividad alta respalda al de desarrollo de aplicaciones basado en modelos con el núcleo de características de la nube: dimensionamiento rápido, la gobernanza de autoservicio y multiusuario. Ofrecen un diseño gráfico y típicamente algunas secuencias de comandos o programación estructurada limitado. La lógica de negocio de la aplicación normalmente se codifica en los metadatos y se interpreta ya sea en tiempo de ejecución o código generado para tiempo de ejecución.

Justificación de rapidez de posición y adopción: CEAPs de productividad alta son el desarrollo de aplicaciones basado en modelos y plataformas de ejecución diseñados para empresas de TI y organizaciones de negocios también como vendedores de software independientes (ISVs) para desarrollar servicios de aplicaciones en nube (incluyendo SaaS) con productividad alta, resultados rápidos, bajo costo y demanda reducida para habilidades técnicas avanzadas. Estas plataformas son típicamente nativas de la nube (la nubosidad está incrustado en la propia plataforma, en contraste con frameworks PaaS basados en la nube). La productividad alta es un subproducto del diseño típico de plataforma básica de nube. En orden a crear una plataforma básica de nube (eso es, una plataforma que ejerce lógica de negocios, internamente aísla intrusos y permite que las versiones no interfieran con las personalizaciones) es típicamente basado en metadatos. Como tal, las plataformas básicas de nube son también basadas en modelo y por lo tanto ofrecen alta productividad. Sin embargo, para llegar a este nivel de servicio, las plataformas comúnmente deben abstenerse de modelos de programación pre-nube estándar y ofrecer en gran parte (o completo) entornos de programación de aplicaciones de propiedad y de ejecución.

La naturaleza propietaria de la mayor parte de la CEAP productividad alta hace que estas plataformas no aptas para la migración directa de aplicaciones empresariales pre-nube existentes o habilidades de ingeniería. Sin embargo, en esta etapa de la adopción de la nube para el nuevo desarrollo de aplicaciones, la mayoría de las empresas desean preservar sus inversiones en software y habilidades. También prefieren conservar la oportunidad de volver a utilizar el entorno de la plataforma familiar en caso de que la adopción plataforma en la nube no se entregue. Interrupción no graduable, entorno de

Página 16 de 43

nube-nativa de la CEAP de productividad alta va en contra de estos requisitos. Muchas organizaciones que buscan establecer un entorno de turno privado PaaS (y aplicaciones startup ISVs) al alto mando, compatible con versiones anteriores frameworks PaaS de software, como Pivotal CF, en vez de Apprenda o Red Hat OpenShift Enterprise. Otros señalan la relativa inmadurez de estas plataformas y deciden construir un entorno privado IaaS (utilizando una plataforma de gestión en nube como OpenStack o VIVIware vCloud Suite) y desplegar plataforma tradicional middleware allí (modelo IaaS+, renunciando a la mayor parte de los beneficios de una PaaS).

Mientras que el alto control de frameworks PaaS ofrecen una mayor potencia de programación, también imponen los requisitos de alto costo para capacidades de ingeniería y de habilidades de gestión, lo que aumenta el costo total de los proyectos de aplicaciones en nube. Compatibilidad con versiones anteriores de los frameworks de PaaS también les impide la plena aplicación de las características de la nube nativo para aplicaciones. Algunas de la nubosidad de las aplicaciones desarrolladas utilizando alto control de frameworks PaaS dependen de los desarrolladores de aplicaciones y varía en la calidad de los resultados. Pero la naturaleza propietaria de la CEAP de productividad alta y la falta de apoyo de los megavendedores ralentizan su adopción. Las aPaaS de alta productividad (servicios de nube pública, en lugar del software de nube privada) es probable que dirija el camino, ya que los suscriptores interesados en alta productividad son propensos a preferir los servicios soportados por los proveedores de nube que el software que deben mantenerse a sí mismos, por lo tanto también ralentizar la adquisición de la CEAP de productividad alta. (Una nube privada bien diseñado resuelve este problema: Central de TI, es el comprador de software, y desarrolladores de aplicaciones son los suscriptores que están igualmente dispuestos a usar privada o público servicios en nube. Pero tales nubes privadas estratégicas son todavía relativamente raras.)

Mientras que los modelos de programación no familiares y perturbadores de la mayoría de CEAP de productividad alta ralentizan su adopción, la demanda de la productividad y la calidad en nube garantizada de la aplicación sigue siendo alta entre la corriente principal de TI y las organizaciones empresariales. Como las limitaciones de IaaS + y el alto mando de frameworks PaaS se hacen evidentes, los usuarios demandarán una mayor productividad. La mayoría de los proveedores de frameworks PaaS agregarán capacidad CEAP de productividad alta a sus ofertas de la plataforma, en el proceso de empujar la visibilidad, la popularidad y la expectación en torno a la CEAP de productividad alta hasta la cima de expectativas infladas y en la meseta de la productividad corriente eventual.

Consejo al usuario: Si los proveedores de tecnología es una preocupación, pero una alta productividad es un requisito, elegir la CEAP de productividad alta para aplicaciones que tienen vida útil prevista a corto y tiempo de pago a corto. Estas condiciones mitigar en parte la dependencia de un proveedor que resulta de la naturaleza propia de estas plataformas por los usuarios que permiten, si es necesario, para mover y rediseñar las aplicaciones sin una pérdida de la inversión inicial.

Dar preferencia a vendedores de CEAP de productividad alta que también ofrecen alto control de software de la estructura PaaS, especialmente si el CEAP se construye con el framework como su fundamento. Estas ofrendas son raros hoy en día, pero en el futuro van a ofrecer la máxima flexibilidad de plataformas coordinadas tanto para la alta productividad y alto control del desarrollo de la aplicación y ejecución.

Evite la CEAP de productividad alta en la planificación para migrar aplicaciones pre-nube existentes a un entorno de nube privada con un cambio mínimo. Estas plataformas son adecuadas para un nuevo desarrollo en la nube natal, pero no para la instalación de accesorios o incluso la modernización de aplicaciones pre-existentes.

Página 17 de 43

Impacto en el negocio: CEAP de productividad alta garantiza un comportamiento en la nube nativo de aplicaciones de negocio, permitiendo a los desarrolladores concentrarse principalmente en el diseño de aplicaciones de negocio, reduciendo los errores e ineficiencias potenciales, mejorando la productividad de TI y acortando el tiempo de los resultados de los proyectos de TI:

El uso de CEAP productividad alta puede permitir que algunos creación de aplicaciones por los usuarios de negocio, fuera de, o bajo la observación de TI.

El uso de la CEAP productividad alta optimiza el diseño de aplicaciones en nube y ejecución para la mayoría, más simple, aplicaciones de negocios, sino que aumenta la dependencia de proveedores del usuario.

Clasificación Beneficio: Alta

Penetración de mercado: 5% a 20% de la audiencia objetivo

Madurez: adolescente

Los vendedores de la muestra: Keyed In Solutions; Mendix; MIOsoft; OutSystems; Progress Software; Software AG

DevOpsAnálisis por: Ronni J. Colville; Jim Duggan

Definición: DevOps representa un cambio en la cultura de TI, enfocándose en la entrega de servicio de TI rápido a través de la adquisición de lo ágil, prácticas magras en el contexto de un enfoque orientado al sistema. DevOps enfatiza la gente (y la cultura), y busca mejorar la colaboración entre los equipos de operaciones y desarrollo. Implementaciones DevOps utilizan la tecnología - especialmente herramientas de automatización que pueden aprovechar una infraestructura cada vez más programable y dinámica desde una perspectiva de ciclo de vida.

Justificación de rapidez de posición y adopción: DevOps no posee un conjunto concreto de mandatos o estándares, o un conocido framework (por ejemplo, ITIL o Integrado Modelo de Madurez y Capacidad [CMMI]), haciendo a esto un tema de interpretación más liberal. Para muchos es bastante difícil de alcanzar para hacer que sea difícil saber por dónde empezar y cómo medir el éxito. Esto puede acelerar la adquisición - o potencialmente inhibirla. DevOps se asocia principalmente con la integración y la prestación continua de servicios de TI como un medio de proporcionar vínculos a través del ciclo de vida de la aplicación, desde el desarrollo hasta la producción. Conceptos de DevOps son cada vez más generalizados en los proyectos en la nube y en entornos más tradicionales de la empresa. La creación de equipos DevOps trae desarrollo y operaciones de personal en conjunto para gestionar de manera más consistente una visión de extremo a extremo de un servicio de aplicaciones o de TI. Para algunas organizaciones de TI, la racionalización de los despliegues de lanzamiento desde el desarrollo hasta la producción es la primera área de atención; aquí es donde existe el dolor de prestación de servicios más aguda.

Prácticas DevOps incluyen la creación de proceso común para los equipos de desarrollo y operaciones; formación de equipos para gestionar el aprovisionamiento y las prácticas de extremo a extremo para la promoción y puesta en lanzamiento; un enfoque en la alta fidelidad entre entornos; prácticas estándar y automatizados para la construcción o la integración; mayores niveles de automatización de pruebas y cobertura de la prueba; automatización de los pasos del proceso manuales y escrituras informales; y

Página 18 de 43

simulación más completa de las condiciones de producción en todo el ciclo de vida de la aplicación en el proceso de lanzamiento.

Tanto Dev y Ops buscan herramientas para reemplazar secuencias de comandos personalizadas con modelos de aplicación o servicio coherentes, mejorar el éxito de implementación a través de las configuraciones más predecibles. La adopción de estas herramientas no se asocia con el desarrollo o apoyo a la producción personal, sino más bien con los grupos que se sitúan en el desarrollo y la producción, y por lo general se crea una instancia para hacer frente a las aplicaciones web específicas con una necesidad de aumentar la velocidad de lanzamiento. Para facilitar y mejorar las pruebas y la integración continua, herramientas que ofrecen el seguimiento específico a los testeadores y personal de operaciones también están comenzando a emerger. Otro de los retos de adopción de DevOps es el requisito para conectividad. Cadenas de herramientas son críticos para DevOps para permitir la integración de la automatización de función específica de una parte del ciclo de vida a otra.

Implementación DevOps no es un proceso formal; por lo tanto, la adopción es algo irregular. Muchos aspiran a alcanzar la fluidez y agilidad prometida, pero pocos lo hacen. Las organizaciones de TI que aprovechan técnicas de paso-capas pueden estratificar y clasificar las aplicaciones y encontrar aplicaciones que podrían ser buenos objetivos para la adopción. Esperamos que esta bifurcación (enfoque de desarrollo y enfoque de operaciones) que continúe durante los próximos dos años, pero a medida que más aplicaciones o servicios de TI a ser basado en ágil o centrada en el cliente, la adopción de DevOps seguirá rápidamente. DevOps no excluye el uso de otros frameworks o metodologías como ITIL. La incorporación de algunos de estos enfoques de mejores prácticas puede mejorar la prestación de servicios en general.

Consejo al usuario: La expectación DevOps está empezando a alcanzar su punto máximo entre los proveedores de herramientas, con el término que se aplica de manera agresiva y reclamaciones outrunning capacidades demostradas. Muchos vendedores están adaptando sus portafolios existentes y calificándolos DevOps para llamar la atención. Algunos vendedores están adquiriendo soluciones puntuales pequeñas desarrolladas específicamente para DevOps para aumentar sus portafolios. Esperamos que esto continúe. Las organizaciones de TI deben establecer criterios clave que diferenciarán los rasgos DevOps (fuerte integración de cadena de herramientas, flujo de trabajo, la continuidad, el contexto, la especificidad, la automatización) de herramientas de gestión tradicionales.

Adopción o incorporación exitosa de este enfoque no se logrará mediante una compra de la herramienta, pero es contingente a un cambio a veces difícil de la filosofía organizacional. Debido a que DevOps no es preceptivo, es probable que el resultado en una variedad de manifestaciones, hace más difícil saber si uno está realmente "haciendo" DevOps. Sin embargo, la falta de un marco de proceso formal no debe impedir que las organizaciones de TI a partir de la elaboración de sus propios procesos repetibles para agilidad y control. Debido DevOps está emergiendo en la definición y en la práctica, las organizaciones de TI deben acercarse a ella como un conjunto de principios rectores, no como dogma proceso. Seleccione un proyecto que involucra a los equipos de desarrollo y operaciones para probar el ajuste de un enfoque basado en DevOps en su empresa. A menudo, esto se alinea con un entorno de aplicación. Si se aprueba, la posibilidad de ampliar DevOps para incorporar arquitectura técnica. Como mínimo, examinar las actividades a lo largo del continuum desarrollador-a-operaciones existentes, y buscar oportunidades donde la adopción de procesos de comunicación más ágiles y patrones puede mejorar los despliegues de producción.

Impacto en el negocio: DevOps está enfocado en mejorar los resultados de negocio a través de la adopción de la mejora continua y principios de lanzamiento incrementales adoptadas de las metodologías ágiles.

Página 19 de 43

Mientras agilidad a menudo equivale a la velocidad, hay un impacto tanto paradójico; y más pequeños, actualizaciones más frecuentes a la producción pueden trabajar para mejorar la estabilidad y el control general, reduciendo así el riesgo.

Clasificación Beneficio: Transformacional

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Adolescente

Los vendedores de la muestra: Boundary; CFEngine; Chief; Circonus; Puppet Labs; SaltStack

Lectura recomendada: “Deconstruyendo DevOps”

“Cadena de herramientas de trabajo DevOps para entregar la gestión de procesos de TI integrable”

“Aprovechando DevOps y otros frameworks de proceso requiere una importante inversión en las personas y proceso”

“DevOps y monitoreo: Nuevas herramientas para nuevos entornos”

“Señal de catalizadores del crecimiento de DevOps”

“Automatización del lanzamiento de la aplicación es una llave para DevOps”

Comunidad crowdsourced no probadaAnálisis por: Kris Doering; Gilbert van der Heiden

Definición: Comunidad crowdsourced no probada consiste de individuos que se han suscrito a un portal de una compañía crowdsourcing y se les permite competir por cualquier trabajo crowsourced que desean sin tener el probado compañía crowdsourcing (verificar y aprobar) si en realidad tienen las credenciales adecuadas que se requieren para realizar el trabajo. Una comunidad crowdsource no probada refleja el grupo de individuos que responde a un concurso para la duración del concurso.

Justificación de rapidez de posición y adopción: Comunidades no probadas tienen sus ventajas distintas, ya que tienen el potencial de producir resultados valiosos a partir de individuos que no tienen experiencia formal en el área (como los aficionados). Con gran parte del trabajo de una empresa corwdsourcing con individuos no probados, el supuesto es que personas sin experiencia no responderían a los concursos que requieren conocimientos, o se eliminan durante el proceso de selección. Sin embargo, las comunidades no probadas son específicamente útiles para pruebas exploratorias y usabilidad desde la perspectiva del consumidor, o para la ideación, definición de valor, definición de requerimientos, opiniones estáticas de requisitos funcionales, diseño de experiencia de usuario, y otro trabajo que requiere imaginación, la creatividad y el razonamiento lógico.

Dado que las comunidades no probadas incluyen tanto los expertos como los aficionados, que también se aplican a cualquier trabajo que no implica conocimientos de dominio específico, como la codificación, la planificación, las especificaciones de la escritura, la estrategia de pruebas, diseños técnicos y funcionales, la integración de tareas, la seguridad, el cumplimiento y el conocimiento normativo. Además, cualquier trabajo que requiere experiencia funcional o no funcional de dominio específico para ser ejecutado con éxito también puede ser abordado por las comunidades no probadas.

Página 20 de 43

De manera similar a las comunidades crowdsourced examinados, comunidades crowdsourced no probadas pueden estar bajo el control del propio cliente, o por medio de una función de asistente de la compañía crowdsourcing que posee el portal para acceder a la comunidad. Comunidades no probadas son en su mayoría bajo el control del cliente en sí, mientras que las comunidades examinados en general son controladas por la empresa crowdsourcing a través de un asistente asignado (copiloto).

Ya hemos puesto comunidades crowdsourced no probadas en una posición pre-pico, ya que no son nuevos y han existido durante más de cinco años. Con las compañías de crowdsourcing que tienen un La base de suscriptores de cientos de miles de millones de personas, el potencial es enorme. Es especialmente cierto con un mayor uso de los servicios basados en la nube, y el impulso para aumentar la experiencia del consumidor en una economía donde la digitalización de las organizaciones de usuarios finales deben innovar más rápido. Crowdsourcing proporciona los medios para probar la innovación e identificar ideas innovadoras y crear soluciones innovadoras más rápidas. Comunidades crowdsourced no probadas son uno de estos significados de crowdsourcing.

Consejo al usuario: las organizaciones deben considerar objetivamente comunidades crowdsourced no probadas como alternativa para cualquier trabajo que:

Puede ser desglosado en tareas que pueden ser manejados por personas Puede ser de origen y entregado a través de un entorno basado en Web Tiene poco negocio o riesgo de reputación.

Debido a la naturaleza de la competencia entre una gran cantidad de individuos a nivel de tarea, no probadas. Comunidades crowdsourced tienen el potencial de ofrecer soluciones innovadoras en un tiempo muy corto.

Las organizaciones deben tener fuertes capacidades de gestión e integración de los requisitos a implementar correctamente las comunidades crowdsourced no probadas bajo control directo de la organización. Cuando los requisitos de capacidades faltan, las organizaciones deben trabajar a través de crowdsourcing empresas controlar la comunidad. Sin embargo, cuando la integración (de los individuos de tareas crowdsourced) capacidades faltan, las organizaciones deben considerar esperar hasta que puedan asignar a una multitud curador. Curadores Multitud son arquitectos típicamente fuertes o desarrolladores con la mezcla correcta de proyecto liderazgo y habilidades de comunicación, cuyo papel en una organización es diseñar, gestionar e integrar concursos crowdsourcing.

Debido a la falta de control de las personas que pueden competir por el trabajo, y un enfoque común en donde propios clientes controlan la comunidad, hay algunos retos específicos que las comunidades crowdsourcing no probadas plantean, y las organizaciones deben abordar estos a través de un riesgo de evaluación:

Las respuestas a las preguntas y tareas que no pueden hacer frente a los requisitos previstos y requerirán tiempo y esfuerzo extra para asegurar los encuestados están en la misma página. Este problema por sí mismo tiene la riesgo añadido de expansión a través de múltiples tareas en un solo proyecto de crowdsourcing, por el que interpretaciones inconsistentes de explicaciones conducen a los entregables que son difíciles de integrar.

La privacidad y la integridad de los datos es más probable cuando las organizaciones inexpertos corren concursos ya que a menudo carecen de experiencia en la gestión de requisitos adecuado y no garantizan internamente que el concurso se estructura de la manera correcta. Una vez que el concurso se inicia, la comunidad puede pedir preguntas y empresas sin experiencia podrían proporcionar más información (o exponer más datos) se requiere que.

En general, las comunidades no probadas requieren más iteraciones o más concursos para entregar resultados de calidad similar a las de las comunidades examinados. Cuantas más

Página 21 de 43

respuestas - cuanto más tiempo la obligación de validar cada uno. La razón adicional es que, en las comunidades no probadas bajo el control de un cliente, el paso de verificación es a menudo ausente. Esto implica que cualquier propuesta también recibe la revisión por pares de otros individuos de la comunidad (como un grupo de control).

La reputación de los individuos y el cliente están menos protegidos por el crowdsourcing miembros de la empresa y los clientes sin experiencia y la comunidad podrían perturbar el proceso o no para hacer frente a los clientes y la comunidad preguntas. Las TI también podría conducir a la calidad insuficiente a nivel de tareas y los resultados que no se pueden integrar.

Impacto en el negocio: los administradores de TI se enfrentan a la presión de los directores generales y CIO para reducir los costos y optimizar recursos. Están bajo la presión de las partes interesadas para proporcionar soluciones innovadoras rápidamente. Uso comunidades crowdsourced no probadas pueden ayudar a reducir los costos operativos y de personal, ya que Realiza tareas y la dotación de personal, según sea necesario. El proceso requiere de abordaje limitado, limitado aprovisionamiento, ningún salario en curso, no hay gastos generales (tales como el espacio de oficina), y el cliente paga sólo por los resultados que coinciden con sus criterios y objetivos.

Los impactos únicos de las comunidades crowdsourced no probados seguirán siendo limitados, como tal, comunidades requieren más gestión, más iteraciones y entregar resultados de calidad inferior. También tener prestaciones del proyecto más complejos que son más difíciles de integrar en comparación con el proceso y los resultados de las comunidades crowdsourced examinados.

Clasificación Beneficio: Moderado

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Adolescente

Los vendedores de la muestra: Elance; Kaggle; Passbrains; uTest; Ziptask

Lectura recomendada: "Piloto del empleo de Comunidades Crowdsourced para el desarrollo de aplicación para lograr Innovación Ágil"

"El aprovechamiento de un Talento Global a través de crowdsourcing puede aumentar la velocidad y entrega de innovación"

"Usar Crowdsourcing como multiplicador de la fuerza en el desarrollo de aplicaciones"

Automatización de publicación de aplicacionesAnálisis por: Ronni Colville J.; Colin Fletcher

Definición: Automatización Liberación de Aplicaciones (ARA) ofrece herramientas de automatización para permitir las mejores prácticas en mover artefactos relacionados, aplicaciones, configuraciones y datos aún juntos a través de la aplicación Ciclo vital. Para ello, las herramientas ARA proporcionan una combinación de automatización, capacidades de modelado medio ambiente y gestión de flujo de trabajo para mejorar simultáneamente la calidad y la velocidad de versiones de aplicaciones. Estas herramientas son una parte clave de permitir que la meta de lograr DevOps entrega continua con un gran número de rápidos, pequeños lanzamientos.

Justificación de rapidez de posición y adopción: Al igual que con muchos procesos, las organizaciones de TI a menudo son muy fragmentado en su acercamiento a versiones de aplicaciones. En algunos casos,

Página 22 de 43

el proceso es liderado por las operaciones, aunque también puede ser (y cada vez más) gestiona desde la parte de desarrollo de la organización o una empresa conjunta de los dos grupos, como en DevOps. Esto da como resultado predecible en la fragmentación adquisición herramienta debido a diferentes compradores que buscan en diferentes herramientas, en lugar de un enfoque consolidado mirando una herramienta que puede escalar y resolver retos similares para los diferentes grupos de desarrollo de aplicaciones. La intención de herramientas de ARA es cinco veces:

• Acelerar el tiempo de comercialización asociada con el desarrollo ágil, reduciendo el tiempo que se necesita para implementar y configurar en todos los entornos.

• Eliminar la necesidad de construir y mantener scripts personalizados para la implementación de aplicaciones y actualizaciones mediante la estandarización y documentación de los procesos de implementación a través de diversos entornos.

• Reducir los errores de configuración y el tiempo de inactividad asociados con los lanzamientos individuales dentro de un único entorno o en múltiples entornos.

• Coordinar y automatizar comunicados entre varias personas, los grupos y los pasos del proceso que por lo general se mantienen manualmente en hojas de cálculo, correo electrónico o ambos.

• Mueva la base de conocimientos de caras, programadores de secuencias de comandos especializados a los recursos menos costosos.

La adopción y utilización de estas herramientas son todavía emergentes, pero que siguen atrayendo a una gran cantidad de atención por parte de las grandes empresas y las empresas con aplicaciones orientadas a la web. Aunque el uso actual de las herramientas se limita normalmente a un pequeño porcentaje de todas las aplicaciones en una cartera de aplicaciones empresariales, se espera que este porcentaje aumente en línea con el crecimiento de la adopción continuada de desarrollo ágil y Web y de aplicaciones cloud arquitecturas. Los mayores competidores de estas herramientas son scripts internos y los procesos manuales, que son blancos fáciles como las presiones de costos y competitivas en las organizaciones de TI siguen aumentando.

Además, la popularidad y la mente la cuota de mercado en torno DevOps siga creciendo y llamar la atención significativa a la mejora de la liberación y el despliegue o despliegues continuos. Este impulso del mercado también ha resultado en reciente adquisición significativa y actividad de desarrollo entre los vendedores que representa probablemente continuaron cerca - y mucho - inversión a largo plazo en el mercado. Este enfoque también impulsa el atractivo de tratar el método de despliegue de aplicaciones como la de codificación de la aplicación. Algunas organizaciones están modelando sus despliegues de aplicaciones después de grandes proveedores de cloud y herramientas que permiten a los equipos de soporte de aplicaciones e ingenieros de sistemas para desarrollar scripts automatizados proporcionados por nuevas herramientas comerciales que han surgido de la comunidad de código abierto aprovechamiento.

Consejo al usuario: Tenga en cuenta que los procesos de ARA no lo son, y es poco probable llegar a ser, muy estandarizado. Evalúe su madurez gestión del ciclo de vida de la aplicación - en concreto alrededor de los procesos de implementación - y buscar una herramienta o herramientas que pueden ayudar a automatizar la implementación de estos procesos a través de múltiples equipos de desarrollo y operaciones. Cuestiones de organización y políticos siguen siendo importantes y no pueden abordarse únicamente por una compra de herramientas. Además, el mejor conocimiento que tiene de los flujos de trabajo actuales para la liberación de aplicaciones (sobre todo si se hace de forma manual), más fácil será la transición a un flujo de trabajo automatizado, lo que aumentará el tiempo de valorar para las herramientas.

Comprender y utilizar sus requisitos específicos para las aplicaciones y plataformas para reducir el alcance de los objetivos de la evaluación, y para determinar si se necesitarán uno demasiado o múltiples

Página 23 de 43

herramientas de uno o más proveedores. Aunque la mayoría de los fabricantes ofrecen una combinación de automatización, modelado medio ambiente y gestión de flujo de trabajo, los puntos fuertes, el alcance (aplicación, soporte de la plataforma y versión) y envasado de estas capacidades respectivas variar significativamente entre los vendedores. Aunque esperamos que esta brecha continúe disminuyendo, es importante comprender el apoyo actual y futuros mapas de carreteras.

Incluya integraciones con el desarrollo y la gestión de operaciones de TI (ITOM) herramientas existentes en sus criterios de evaluación de productos, con la mirada puesta en la construcción el uso nicho de estas herramientas en su entorno de aprovisionamiento y la configuración más amplia. Las organizaciones que desean extender el ciclo de vida de la aplicación, más allá del desarrollo de entornos de producción utilizando un modelo de aplicación coherente, deben evaluar las herramientas de desarrollo con características ARA o soluciones puntuales ARA que proporcionan integración out-of-the-box con herramientas de desarrollo. Además, evaluar la integración con las infraestructuras cloud existentes o previstas o herramientas CMP para la capacidad de automatización de versión de la aplicación en curso.

Impacto en el negocio: herramientas ARA hasta la fecha tienen los procesos de negocio más afectadas de manera significativa y positivamente y servicios que deben evolucionar rápidamente para mantenerse competitivos y confían a menudo en aplicaciones ágiles desarrollado, basados en la web. Dicho esto, las herramientas ARA producen beneficios de mitigación agilidad, el costo y el riesgo para la mayoría de los tipos de aplicaciones, mejorando la calidad, reduciendo los errores humanos, y aumentar la velocidad de los comunicados a través de una mayor coherencia y estandarización.

La agilidad empresarial se mejora al reducir el tiempo que se necesita para implementar y configurar las aplicaciones a través de múltiples entornos, acelerando así la capacidad de la empresa para reaccionar a los cambios del mercado. El ahorro de costes se realiza a través de una reducción significativa de las interacciones manuales requeridos por frecuencia alta habilidad y el personal de alto costo. El riesgo es inherente mitigado por la documentación y estandarización de los procesos y configuraciones a través de múltiples dominios tecnológicos herramientas ARA.

Clasificación beneficio: alta

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: adolescente

Los vendedores de la muestra: automic; Software BMC; CA (Nolio); Chef; Electric Cloud; HP; IBM (UrbanCode); MidVision; Laboratorios de marionetas; SaltStack; Software Serena; VMware; XebiaLabs

Lectura recomendada: "Vendros fresco en DevOps, 2014"

"Cool Vendors en DevOps, 2013"

"Conoce la Aplicación de lanzamiento Paisaje Automatización Vendor a favoritos los mejores vendedores para su organización"

"Cool Vendors en DevOps 2012"

"Cool Vendors en administración de lanzamientos de 2011"

"Desde el desarrollo hasta la producción: Integración del cambio, configuración y puesta en libertad"

"La automatización de la liberación de aplicaciones es una clave para DevOps"

Página 24 de 43

"Perseguir comunicados de infraestructura más pequeños"

"DevOps cadenas de herramientas de trabajo para entregar la gestión de procesos de TI integradable"

"Alineación de cambio en la gestión de configuración y liberación"

"¿Cómo construir un equipo de publicación DevOps"

"Maangement Mejores prácticas en cambio, configuración y liberación"

"Cuadrante Mágico para la gestión del ciclo de vida de aplicaciones"

"¿Estás listo para mejorar la velocidad de liberación?"

Desarrollo orientado al funcionamientoAnálisis por: Nathan Wilson

Definición: Desarrollo orientado al funcionamiento (TDC) es un pariente cercano del desarrollo basado en pruebas (TDD) y el desarrollo impulsado por la aceptación de la prueba (ATDD). Todo se trata de prácticas en el que las pruebas se escriben antes de escribir el código. Aunque TDD y ATDD describen pruebas en una forma técnica que es familiar para los ingenieros de desarrollo y pruebas, BDD expresa requisitos (funcionamientos) de una manera no técnica que se pueden convertir en pruebas automatizadas. Este proceso mejora la comunicación entre los usuarios finales, analistas de negocios, desarrolladores y probadores.

Justificación de rapidez de posición y adopción: Desde que el concepto "prueba de primera" fue popularizado por el desarrollo de la programación extrema (XP) en 1999, que en gran parte ha sido realizada por los desarrolladores que escriben pruebas unitarias en un proceso que se hizo conocido como TDD. ATDD se usa con menos frecuencia para mover el desarrollo de la prueba primero en la prueba de integración de alto nivel. BDD extiende el concepto más cercano al usuario, documentando el comportamiento deseado del software en el idioma del usuario final. BDD recién ahora está siendo descubierto por los departamentos de TI como una manera de mover la práctica de la prueba de escritura antes de código hasta las capas de ensayo-cliente visible. Aunque BDD es ampliamente aceptado en muchas empresas de software ágil de vanguardia, su penetración en los departamentos de TI de las empresas se sitúa significativamente.

Como una práctica emergente, BDD emplea principalmente herramientas de código abierto, y su uso requiere habilidades de codificación. Esto crea una brecha de habilidades significativas en la mayoría de las organizaciones de la garantía / de prueba de calidad. Aunque Gartner espera ver una mejora continua en las herramientas de BDD, esperamos que las habilidades cambiar para continuar como la codificación y secuencias de comandos se vuelven cada vez más una competencia básica de pruebas.

Consejo al usuario: Por la forma en que se promueve la colaboración, el TDC es una buena práctica para todos los proyectos ágiles. Es útil, independientemente de su ciclo de vida del desarrollo de software. Involucrar a los usuarios, los analistas de negocio y probadores en el proceso de desarrollo al mismo tiempo que los desarrolladores. Desarrollar el plan de ensayos y pruebas automatizadas simultáneamente con el código. Utilice herramientas lingüísticas BDD, como pepino, JBehave y FitNesse, para construir pruebas automatizadas que sean verificables por el dueño del producto y el usuario final.

Las pruebas automatizadas requieren un conjunto de habilidades diferentes de manual tradicional y pruebas exploratorias. Debido a que las pruebas se escriben antes de que el código en BDD, de

Página 25 de 43

grabación / reproducción herramientas de automatización de pruebas no se pueden utilizar, aumentando así la brecha de habilidades. Invertir en capacitación para mejorar las habilidades de codificación, y esperar para utilizar algunos de sus desarrolladores principales de su probador tiempo para codificar los arneses de prueba.

Impacto en el negocio: las empresas deben ver BDD no como una herramienta de prueba automatizada, sino como una forma de mejorar la colaboración en proyectos de software. Dado que las pruebas de TDC son accesibles a un público no técnico, que pueden ser desarrollados en conjunto con el consumidor de TI y el analista de negocios, lo que garantiza que el software cumple con la necesidad de destino. Escribiendo las pruebas antes del código maximiza los beneficios de escribir pruebas automatizadas, garantizando que las pruebas están disponibles tan pronto como sea posible en el proceso de desarrollo. Por lo tanto, el TDC asegura no sólo que el código está escrito correctamente, sino también que el código correcto se escribe.

Aunque el concepto de usar la definición de la prueba como un documento de comunicación y la planificación se puede aplicar a la mayoría de los proyectos de TI, las herramientas actuales de TDC se centran en la prueba de los proyectos de desarrollo de aplicaciones personalizadas. Para otros proyectos de TI, puede ser necesario convertir manualmente las descripciones de comportamiento en scripts de prueba tradicionales.

Clasificación beneficio: alta

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: emergente

Vendedores de la muestra: ThoughtWorks

Lectura recomendada: "Evitar el caos en el desarrollo ágil de hecho que define"

"Acelerar el desarrollo de pruebas automatizadas"

"Siete lecciones proyectos tradicionales pueden aprender de ágil"

Web orientado a eventosAnálisis por: Ray Valdes; David Mitchell Smith

Definición: Por eventos web se refiere al uso de los marcos y las bibliotecas que apoyan una rosca, sin bloqueo de entrada / salida (I / O), modelo de procesamiento de eventos, en oposición a base de hilo o enfoques basados en el proceso de manejo de peticiones concurrentes.

Justificación de rapidez de posición y adopción: la programación impulsada por eventos es una tendencia entre los desarrolladores web que ha ganado fuerza significativa en los últimos años, debido a las ganancias en el rendimiento y la eficiencia en comparación con los enfoques tradicionales a base de hilo.

En la actualidad hay muchas opciones para las bibliotecas y los marcos que apoyan esta arquitectura de programación, y para diferentes plataformas de idiomas, incluyendo Python (Tornado, Retorcido y bibliotecas GEvent), Java (Vert.x), JavaScript (NodeJS), C (libevent), Akka (Scala) y Rubí (Máquina de eventos). Estas herramientas no son directamente comparables. Por ejemplo, Tornado es un marco, mientras Twisted es una biblioteca. Ambos están escritos en Python, y que a menudo se comparan uno contra el otro, sino que también son complementarios. Tornado puede ser implementado en la parte

Página 26 de 43

superior de Twisted, por ejemplo. Servidores HTTP que emplean este enfoque incluyen Nginx. Idiomas con apoyo integrado para la programación orientada a eventos incluyen Erlang (el comportamiento predeterminado gen-evento).

Además de las bibliotecas del lado del servidor, el uso de la tecnología de evento basado en navegador está aumentando. El API WebSockets es parte de la familia de especificaciones HTML5 y proveedores como Kaazing y tecnología push son vendedores con productos que apoyan el concurso completo basado en el navegador.

Hay algunos sitios de alto perfil que utilizan herramientas orientadas a eventos. Por ejemplo, FriendFeed (una startup web social adquirida por Facebook) desarrolló el marco Tornado para manejar las solicitudes web de alto volumen de una manera escalable. Yammer, LinkedIn y eBay están utilizando Node.js para algunos de sus sistemas en línea.

La crítica expresó en contra de programación orientada a eventos es que el código puede llegar a ser complejo, debido al uso de las devoluciones de llamada que fragmentan la lógica de flujo visible. Al mismo tiempo, este enfoque parece cumplir con la promesa de alta eficiencia y alto rendimiento para un determinado nivel de capacidad de hardware del servidor.

Consejo al usuario: Los desarrolladores deben entender el patrón programador orientado a eventos y la diferencia entre los marcos de gestión de eventos de bajo nivel y de alto nivel.

Impacto en el negocio: las bibliotecas y los marcos por eventos tienen el potencial para aumentar la eficiencia (mediante el uso de los recursos de hardware), mejorar la productividad de los desarrolladores (y con ello mejorar la experiencia del usuario), y, en algunos casos, mejorar la productividad de los desarrolladores (al permitir el uso de lenguajes dinámicos como Python, Ruby o javasript, que puede ser más fácil para la escritura de código).

Clasificación beneficio: Moderado

Penetración en el mercado: el 1% y el 5% del público objetivo

Madurez: Adolescente

Vendedores de la muestra: Facebook; Joyent; Kaazing; NodeJS; tornado

Contenedores móvilesAnálisis por: Van L. de Baker; Chris Silva

Definición: Hay dos tipos de contenedores móviles incluyen contenedores de aplicación de las políticas que protegen los contenedores de propiedad intelectual y de desarrollo corporativo que mejoran HTML5 o aplicaciones de códigos mixtos. Los contenedores pueden hacer cumplir de datos y gestión de aplicaciones para los usuarios móviles de aplicaciones empresariales a través de la inyección de la política o envoltura. Contenedores de Desarrollo permiten el despliegue de aplicaciones con código de HTML5 encapsuladas en una envoltura que da acceso a las funciones nativas de los dispositivos. Algunos contenedores incorporan tanto HTML5 y código nativo navegador alojada ejecutar juntos.

Justificación de rapidez de posición y adopción: "Contenedor" es un término abusado que a menudo tiene una definición arbitraria. Persona, funciones y definiciones sandbox y contenedores a menudo se superponen. Contenedores móviles están ganando relevancia debido a dos necesidades. La primera es la necesidad de gestionar y asegurar los datos empresariales en los smartphones de los usuarios y las

Página 27 de 43

tabletas. Los tres contenedores nativas para esta necesidad que son más comunes hoy en día son app neutral (envoltura), kit de desarrollo de software de aplicación específica y la virtualización de aplicaciones. El segundo motor es la creciente popularidad de desarrollo de aplicaciones con HTML5. Para la mayoría, la unidad a utilizar HTML5 es la capacidad de construir una aplicación con una sola base de código: HTML5 (HTML / JavaScript, CSS), que puede abarcar dispositivos con diferentes sistemas operativos aprovechando el navegador, pero desplegado como una aplicación nativa. Codificación con HTML5 permite una mayor flexibilidad para el desarrollo de aplicaciones multicanal que abordan una amplia gama de teléfonos inteligentes, tabletas, escritorio y otros navegadores compatibles ya que ambos sitios web y aplicaciones móviles. El contenedor proporciona acceso a los recursos de hardware y permite el despliegue y gestión de aplicaciones empresariales móviles contra las políticas emitidas desde una consola de EMM. Una ventaja importante de este enfoque es ser capaz de desplegar dinámicamente nuevas versiones de aplicaciones sin pasar por la tienda de aplicaciones de embalaje y procesos requeridos con aplicaciones nativas. Contenedores Developer se proporcionan típicamente por cualquiera de los proveedores de aplicaciones móviles de la plataforma de desarrollo o los marcos de desarrollo, y van desde simples implementaciones PhoneGap a contenedores con características completas. Estos contenedores con características completas proporcionan características típicamente no disponibles en aplicaciones HTML5 puros, tales como la identificación y autenticación del usuario, pruebas de aplicaciones, análisis dentro de la aplicación, los requisitos de cifrado de datos, y las API que las soluciones de middleware móvil de apalancamiento de los proveedores de plataformas. El interés en todos estos contenedores ha crecido de manera constante, con un marcado incremento en el último año, pero la adopción aún es incipiente. La falta de normas sencillas, la fragmentación del mercado y herramientas de gestión y de política de propiedad a inhibir el crecimiento de este mercado. Sin embargo, el interés es alto ya que las empresas buscan diferentes niveles de apoyo para asegurar sus datos a través de segmentos de usuarios móviles y simplificar el desarrollo de aplicaciones.

Consejo al usuario: contenedores móviles son una estrategia importante para todas las empresas de soporte de datos corporativos y aplicaciones en los negocios y los dispositivos de propiedad de los usuarios. Contenedores Desarrollador son un método eficaz de los envases y la implementación de HTML5 apps como aplicaciones nativas envuelto. Como contenedores móviles maduran, Gartner cree que habrá más variación en las protecciones ofrecidas. Además las políticas para la gestión con el apoyo de los depósitos móviles como un medio para que los vendedores para diferenciar sus productos en un mercado para la gestión móvil es rápido constricción. Ofrendas de contenedores móviles deben mantenerse al día con el desarrollo de los controles de gestión en diversos Oss móvil y HTML5, y continuar añadiendo características y APIs. Use contenedores móviles para asegurar los datos corporativos y simplificar el desarrollo de aplicaciones. Una advertencia para los desarrolladores es que los dos tipos de contenedores móviles muestran evidencia de algunos problemas de compatibilidad, que puede causar problemas para las empresas que quieren asegurar los datos y ampliar la funcionalidad de la aplicación en la misma aplicación.

Impacto en el negocio: el uso de contenedores móviles para la seguridad y el cumplimiento de la política de móvil empresarial permite a las empresas establecer una seguridad común y estándar de autenticación para el apoyo a los usuarios de móviles de todo tipo. El uso de contenedores móviles desarrollador puede reducir el esfuerzo de desarrollo en la implementación de aplicaciones multicanal, y agilidad velocidad en el despliegue.

Clasificación beneficio: alta

Penetración de mercado: 5% a 20% de audiencia objetivo

Página 28 de 43

Madurez: Adolescente

Vendedores de la muestra: Adobe PhoneGap; Software de la antena; Apache Córdoba; Citrix; Buena Tecnología; IBM (luz de trabajo); Kony; MobileIron; Mocana; Symantec; Trigger.io

Lectura recomendada: "Aprender la Taxonomía de Arquitecturas de gestión de móviles y de punto final"

"Descripción de la tecnología de contenedores de aplicaciones móviles para la gestión y seguridad de los datos de la empresa"

"Los contenedores tienen un impacto importante en los proyectos de desarrollo de aplicaciones móviles HTML5"

"Arquitectura de la aplicación móvil"

Comunidad crowdsourced probadaAnálisis por: Kris Doering; Gilbert van der Heiden

Definición: Comunidades crowdsourced probados están compuestos de individuos seleccionados porque tienen una experiencia requerida. Sus credenciales son verificadas por una firma de crowdsourcing que selecciona personas para concursos.

Justificación de rapidez de posición y adopción: Comunidades Crowdsourcing son una opción de compra de componentes posible cuando las organizaciones están buscando el desarrollo de aplicaciones ágil y relativamente barato y probado. Comunidades Crowdsourced proporcionan acceso a la innovación que va más allá del pensamiento colectivo interno de una organización. Esta multitud se puede poner a trabajar en casi cualquier actividad, desde el diseño a la codificación y pruebas. Comunidades examinados presentan menos riesgo (en comparación con las comunidades no probadas) desde la perspectiva de la seguridad y la integridad, pero, ya que representan una pequeña parte de un grupo más grande, que a menudo tienen un menor número de personas para proponer soluciones y, por tanto, puede ofrecer un menor potencial de innovación. Una comunidad vetados está respaldada por la inversión en herramientas, plataformas y personas que verifiquen en la comunidad por la compañía que ofrece sus servicios, y por lo tanto tiene un valor más alto.

Antes de poder trabajar dentro de una comunidad crowdsourced probados, cada miembro ha sido a través de un proceso similar en virtud del control de la empresa crowdourcing que controla el portal y sus comunidades. Cada miembro ha sido identificado y categorizado por su experiencia (en años y profundidad) y en términos de dominios (que puede ser cualquier dominio de la compañía crowdsourcing desea apoyar). Dependientes en el proceso, el crowdsourcing empresas pueden identificar aún más las habilidades blandas, capacidades de liderazgo genérico, la motivación, las capacidades de aprendizaje, comportamiento competitivo, o habilidades para actuar como revisor. Una vez que la empresa crowdsourcing ha verificado la capacidad y las afirmaciones hechas por el individuo, el ser miembro definido de una comunidad crowdsourced probada.

Consejo al usuario: Organizaciones que enfrentan con demandas empresariales para la innovación, como la nueva funcionalidad, deben esperar antes de perseguir el uso de comunidades crowdsourced si carecen de los conocimientos especializados pertinentes. Aunque el uso de comunidades crowdsourced tiene una curva de aprendizaje, sino que también es un acercamiento a la compra de componentes que, en su caso, no debe pasarse por alto debido a la falta de conciencia, el conocimiento o la confianza. Se trata de un costo-efectivo viable e innovadora forma de desarrollar aplicaciones.

Página 29 de 43

Aunque el acceso directo basado en suscripción a las comunidades crowdsourced es una opción, comunidades examinados son mayormente entregados bajo el control de una compañía crowdsourcing. Organizaciones que buscan utilizar crowdsourcing deben usar comunidades crowdsourced probados hasta que adquieran experiencia. Comunidades crowdsourcing examinados bajo el control de una compañía crowdsourcing tienden a incluir una etapa de verificación en la base del ciclo por la tarea, por lo que un grupo de control comprueba los resultados o propuestas de los miembros antes de que sean entregados a la organización para la revisión final, la puntuación, y la aceptación . Esto reduce el riesgo de defectos y aumenta la calidad y la facilidad de integración de múltiples tareas dentro de un proyecto.

Las organizaciones deben asignar funciones y responsabilidades internas, incluyendo un director de proyecto y un curador multitud. Curatos Multitud suelen ser arquitectos o desarrolladores con la combinación adecuada de habilidades de liderazgo de proyectos y comunicación, cuyo papel en una organización es diseñar, administrar e integrar concursos crowdsourcing fuertes.

La reputación de cada comunidad investigados se debe comprobar (incluida la fiabilidad y la capacidad de los individuos seleccionados de entre la multitud) y el de cualquier empresa patrocinadora crowdsourcing. Por último, la identificación y mitigación de los riesgos del uso de las comunidades crowdsourced examinados deben llevarse a cabo para evitar posibles problemas con la calidad, la seguridad y la integración de soluciones de "ganar".

Impacto en el negocio: los administradores de TI que enfrentan la presión de los CEOs y CIOs para reducir los costos, optimizar los recursos y ofrecer soluciones innovar rápidamente puede utilizar comunidades crowdsourced examinados. La solución puede ayudar a reducir los costos operativos y de personal, ya que se acerca a las tareas y la dotación de personal, según sea necesario. También requiere menos de incorporación, aprovisionamiento limitado, ningún salario en curso, no hay gastos generales (tales como el espacio de oficina), y el cliente sólo paga por los resultados que las competencias de sus criterios de evaluación establecidos y objetivos.

Las organizaciones también pueden beneficiarse de una comunidad crowdsourced probada por:

• Competir para llegar a la mejor idea nueva, capitalizando el conocimiento colectivo de una comunidad conocida de los expertos.

• Ceder soluciones más rápidas a los problemas y soluciones que ya han sido probados por una comunidad de expertos designado.

• Las necesidades de llenado dirigido por elegir el personal mejor cualificado o la solución óptima desde una piscina vetados de los recursos y presentaciones.

Las organizaciones que ya han logrado importantes beneficios del uso de las comunidades crowdsourced probados para ofrecer ideas y soluciones innovadoras para satisfacer sus entornos cambiantes.

Clasificación Beneficio: Moderado

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Adolescente

Los vendedores de la muestra: CrowdFlower; Passbrains; TopCoder; uTest

Lectura recomendada: "Piloto de Uso de Comunidades Crowdsourced de Aplicación”

“Desarrollo para lograr innovación ágil”

Página 30 de 43

"El aprovechamiento de una de Talentos Global a través de crowdsourcing puede aumentar la velocidad y entrega de innovación"

"Usar Crowdsourcing como multiplicador de la fuerza en el desarrollo de aplicaciones"

EN LA CIMA

Diseño de aplicaciones optimizado en nubeAnálisis por: Mark Conductor

Definición: Soluciones optimizadas en la nube están diseñadas para sacar el máximo provecho de la clase mundial características de las plataformas de cloud computing. Escalabilidad horizontal, la tolerancia a fallos, alta rendimiento, eficiencia y facilidad de interoperabilidad son varios de los principios fundamentales que subyacen P exitosas soluciones de nube optimizada. Diseño de las aplicaciones optimizadas para la nube encarna las prácticas y los patrones necesarios para apoyar estos principios durante la entrega de soluciones.

Justificación de rapidez de posición y adopción: orientado a la nube diseño de la aplicación es aplicable a nuevas soluciones en la nube consciente entregada a través de la infraestructura como servicio (Laas), así como la aplicación plataforma como servicio (APAAS). Si bien la adopción (o, al menos, intento de adopción) de cloud optimizan las prácticas y patrones de diseño de aplicaciones permanece principalmente en el ámbito de la vanguardia Startups Web enfocada en soluciones de escala Web, los clientes de Gartner reportan mayores niveles de interés en construir sus propias aplicaciones en la nube para capturar la complejidad operativa y reducción de tiempo a precios de mercado los beneficios de servicios en la nube. El aumento de la adopción de la computación en nube privada, que tiende a manifestarse principalmente en informática de grano grueso y de virtualización de almacenamiento (por ejemplo, Laas), se proporcionar los departamentos de desarrollo de aplicaciones con recursos de autoservicio que sólo puede ser maximizado con el diseño de aplicaciones cloud-optimizada. Marcos de programación popular como Spring, Rieles y Node.js está evolucionando para abarcar y simplificar el uso de los principios de diseño en nube de aplicaciones optimizado.

Consejo al usuario: Para maximizar el potencial de los servicios en la nube se utiliza en la entrega de soluciones, desarrolladores y los arquitectos deben familiarizarse con las herramientas orientadas a eventos y programación paralela, añadiendo tales como el modelo de actor con el patrón modelo-vista-controlador muy gastado utilizado en muchas aplicaciones Web. Por otra parte, siendo conscientes de que el fracaso es inevitable será una consideración clave en el desarrollo de soluciones en la nube optimizada; "Diseño para el fracaso" se convertirá en una mejor práctica.

Impacto en el negocio: La falta de consideración y abordar los principios de aplicación de nube optimizada diseño se carga la empresa con un riesgo desconocido probable que se realizará en un momento inoportuno. Al mismo tiempo, la aplicación de toda la gama de esos principios a cada solución en la nube personalizada voluntad carga la empresa con costos innecesarios, requisitos intensivos de habilidades y pérdida de agilidad. ELLA Los líderes deben establecer lineamientos que definen cuándo y dónde las diversas prácticas de diseño en nube de aplicaciones optimizado debe aplicarse, sobre la base de factores de costo, riesgo y tiempo aplicables a un dada iniciativa entrega solución en la nube.

Clasificación Beneficio: Alto

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Emergentes

Página 31 de 43

Lectura recomendada: "Creación de Soluciones Cloud: Un Marco de Decisión"

"Simposio 2010 Q & A: Web y Cloud AD Ganancia Mind Compartir"

"Cómo equilibrar los beneficios empresariales y los costes de TI de SOA"

Desarrollo ágil de clase empresarialAnálisis por: David Norton; Nathan Wilson

Definición: El desarrollo ágil de clase empresarial (EAD) es el uso de centrado en el cliente, en colaboración y prácticas de cooperación con retroalimentación continua de los interesados. Captación se realiza en dinámica y cambiantes entornos heterogéneos a través del ciclo de vida del software para apoyar la continua entrega de soluciones adaptativas de clase empresarial. Desarrollo ágil de toda la empresa es una cuestión de madurez de los procesos y por lo general es táctico y sin relación con EAD, que es un bien gobernada estratégica iniciativa y una cuestión de escala.

Justificación de rapidez de posición y adopción: Adopción ágil a nivel de proyecto se ha convertido en la corriente principal, pero la madurez organizacional es todavía relativamente bajo en toda la industria. En la mayoría de los casos, se espera que EAD sea de abajo hacia arriba adopción basado en el desarrollo ágil a nivel de proyecto. Sin embargo, de arriba hacia abajo adopción estratégica está creciendo, impulsada por la información y la comunicación (TIC) iniciativas de transformación, o la demanda empresarial para una rápida comercialización. Adopción de arriba hacia abajo tiene sido acelerado por la creciente toma de conciencia del cliente de cuadros, como la entrega ágil Disciplinado (DAD) y Marco Agile escalado (SaFe).

A través de 2015, el 40% de las organizaciones adoptará activamente EAD para ganar la diferenciación de negocios para proyectos y programas que necesitan una estrecha colaboración y cooperación a través del proceso. Muchas personas en grupos de sistemas arquitectura, la oficina de gestión de proyectos (PMO), y la infraestructura y operaciones (l & O) organizaciones son resistentes a las prácticas ágiles, lo que impide la adopción EAD en escala. Aunque barreras significativas para EAD provienen de outsourcing y multisourcing, sistema integradores y proveedores de outsourcing están adoptando activamente prácticas ágiles como ofertas comerciales.

Hay un fuerte push-back de muchos profesionales ágiles en cualquier cosa que ven como un gran proceso o como comprometer los principios ágiles, lo que ha provocado un cisma dentro de la comunidad ágil relacionada con marcos ágiles.

Aviso al usuario: Desarrollar una visión a largo plazo de EAD. Toda la empresa, las organizaciones podrían estar haciendo muchos / proyectos ágiles independientes autónomos de desarrollo que son totalmente ajenos y cumplan específico necesidades tácticas. Los proyectos pueden ser primeras iteraciones de proyectos de desarrollo ágil destinados para ayudar a las organizaciones a entender cómo la solución de aplicación podría convertirse en una más completa solución, que posteriormente se integró en la cartera de soluciones de aplicación actual. Más proyectos de desarrollo ágil comienzan sin una verdadera preocupación por su impacto a largo plazo sobre la ecosistema de aplicaciones y más amplia arquitectura de la solución. Estos proyectos a menudo no logran escalar a soluciones de clase empresarial.

Evaluar el impacto de desarrollo ágil en arquitecturas de soluciones empresariales actuales y futuras así que la organización pueda tomar las mejores decisiones de negocio. Las organizaciones podrán decidir si continuar con el nivel de proyectos ágiles, o mover a una versión más formal de los métodos ágiles en relación con otros proyectos y programas y soluciones actuales, que pueden incluir la adopción de un marco ágil. Las organizaciones deben tener una clara estrategia de uso y apoyo específico, con las

Página 32 de 43

políticas indicando dónde se deben utilizar prácticas ágiles libremente con el proyecto o producto, y donde se debe utilizar con precaución o evitar. Definir las funciones ágiles y puntos de contacto con los principales interesados, incluyendo los desarrolladores de aplicaciones, información y soluciones a arquitectos, y los de la PMO, la calidad Assurance (QA) y l & o áreas.

Crear indicadores clave de rendimiento (KPls) que incluyen técnicas (densidad de defectos, la deuda técnica y QA) y negocio (valor atraso, capacidad de respuesta, la flexibilidad y el tiempo de comercialización) atributos y hacer que el cuadro de mandos KPI a disposición de todos los interesados. Definir EAD factores críticos de éxito específico para su organización basada en las mejores prácticas, como Scrum o Desarrollo del Sistema Dinámico Método (DSDM), y en las prácticas de ingeniería, como la integración continua, impulsado test- desarrollo y entrega continua. Considere enfoques ágiles de escala empresarial, tales como Empresa Scrum, seguro y DAD.

Reconocer que la gestión del ciclo de vida de desarrollo de aplicaciones de la herramienta (ADLM) y el proyecto y gestión de carteras (PPM) los proveedores se están moviendo agresivamente para brindar apoyo EAD, puente la brecha entre la ágil y nonagile. La mayoría de los clientes siguen siendo predominantemente mejores de su clase usuarios. Este refleja la estrategia de herramienta fragmentada de muchas organizaciones de usuarios finales antes de la adopción de EAD.

Impacto en el negocio: EAD es sobre los beneficios empresariales y los resultados del negocio; no es sólo un la tecnología y la cuestión de TI. La empresa debe tener claro el compromiso necesario para hacer EAD exitoso. Por lo tanto, los beneficios de EAD sólo pueden realmente ser realizados si la línea de negocio y los dueños del producto estructurar sus casos de negocios y mapas de carreteras con la entrega ágil de mente. Esto incluye la financiación y realización de los ingresos, y el proceso de gobernabilidad PMO.

Un enfoque holístico de la EAD en todo el proceso de desarrollo hace EAD beneficioso para una amplia gama de proyectos y productos. Los sistemas de diferenciación y de los sistemas de innovación se beneficiarán más de EAD, pero los sistemas de registro pueden y también beneficiarse de EAD.

Dominios de negocio con un cierto grado de incertidumbre, o donde el nivel y el ritmo de cambio en los negocios son cuestiones, serán buenos ajustes para la EAD. Además, los programas que requieren un enfoque más proactivo para fiscal gobierno puede beneficiarse de EAD.

Clasificación Beneficio: Alto

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Adolescente

Los vendedores de la muestra: CollabNet; HP; lBM; Microsoft; Rally; ThoughtWorks; VersionOne

Lectura recomendada: "predice 2014: Arquitectura Empresarial aplicación le permitirá

Desarrollo ágil y disponibilidad de escala web"

"Pasar de un proyecto basado en un producto a basado en Organización de la aplicación"

"Equipos ágiles necesitan los arquitectos de aplicaciones"

ADLM PaaSAnálisis por: Thomas E. Murphy

Página 33 de 43

Definición: vida de desarrollo de aplicaciones plataforma de gestión de ciclo como servicio (PaaS ADLM) soluciones se definen como herramientas en la nube entregada destinada a regular el desarrollo y entrega de software. Estas plataformas combinan capacidades ADLM centrales con extensibilidad basada en Web protocolos y entrega a través de la infraestructura de nube. Herramientas ADLM PaaS pueden apoyar en las instalaciones y aplicaciones en la nube.

Justificación de rapidez de posición y adopción: Aunque la mayoría de herramientas AdLM se entregan para interior despliegue, soluciones ADLM PaaS han estado disponibles desde hace varios años y cada vez hay más visibilidad de los principales actores (tales como HP, lBM y Microsoft). El número de soluciones en el mercado está creciendo y estamos viendo el Nexus de Fuerzas (confluencia del móvil, los grandes datos, cloud y social) el impacto de cómo funcionan los equipos de AD. Sin embargo, el mercado sigue evolucionando, con una falta de ampliamente normas compatibles con modelos de metadatos, la falta de definiciones estándar SEN / hielo y un amplio abanico de tipos de soluciones. Muchos de los vendedores en el mercado son todavía relativamente joven; muchos son pre-pública y con vencimiento en sus modelos de negocio para apoyar el uso a escala empresarial.

Proveedores de plataformas exitosas están viendo ahora los mercados se forman alrededor de sus ofertas, y los consumidores están experimentando el valor de la innovación más rápida ya que la comunidad construye nueva funcionalidad de la plataforma central. Estos mercados traen nuevas funcionalidades al mercado más rápidamente y son también la expansión del mercado direccionable para los productos. Como el proveedor se centra en el núcleo de TI, terceros pueden crear valor en la organización extendida (como la ampliación de los instrumentos de planificación ágiles más allá del equipo de desarrollo).

Un obstáculo para la adopción es la capacidad de hacer la transición de las actuales soluciones de correo locales en cloud-soluciones entregadas, ya que las soluciones en la nube de los proveedores tradicionales son a menudo nuevos productos, o los usuarios serán la transición de un proveedor existente a un nuevo proveedor. En este punto, la mayoría de las organizaciones se centran en soluciones TI de correo locales para ADLM pero esperamos que muchos de transición en apoyo de los equipos distribuidos y una mezcla de house in-y el trabajo subcontratado. La integración es a menudo el última área en la que los proveedores de invertir y la integración entre las herramientas sigue siendo desigual en la aplicación calidad. Como resultado, estas incursiones iniciales a menudo han limitado la extensibilidad o el apoyo para la integración de otra nube o conjuntos de herramientas on-locales. Sin embargo, las instalaciones de middleware de integración de terceros son aparece (como Tasktop Sync y Kovair Omnibus Plataforma de Integración) que puede unir soluciones ADLM dispares. El éxito de los usuarios comenzará a establecer el papel de la aplicación el desarrollo del ciclo de vida del arquitecto para definir estándares de procesos y modelos de datos.

Este enfoque en la integración y extensibilidad significa que los sistemas de ADLM internos actuales de registro (como los requisitos, casos de prueba, defectos y gestión de proyectos) se habilitará para crear nueva sistemas de participación que cruzan las fronteras de roles tradicionales y permiten una mayor flexibilidad en equipo. Las herramientas actuales tienen una variedad de modelos de entrega, pero la mayoría de las ofertas iniciales se están entregando a través de la nube pública, que actualmente impide la adopción. Sin embargo, 'la apelación de las prácticas DevOps continuarán impulsando la adopción como equipos buscan mejores formas de apoyar equipos distribuidos, y vendedores responden con soluciones adicionales.

Consejo al usuario: Las organizaciones de desarrollo deben explorar soluciones ADLM PaaS para pequeñas y medianas equipos, sobre todo cuando la población de usuarios pueden ser dinámica y la atención se centra en los métodos ágiles. Los equipos distribuidos o virtuales valorarán simplificación de ADLM PaaS de gestión de usuarios y se centran en colaboración. Asegúrese de que está cómodo con la

Página 34 de 43

seguridad de los datos y la protección contra la pérdida, o que son capaces de realizar copias de seguridad de datos en su ubicación.

Centrarse en las herramientas que se integran sin problemas con sus herramientas AdLM desplegados actualmente y estrechamente examinan instalaciones de integración empujando vendedores de claridad sobre las direcciones. También, busque la participación en los esfuerzos de normalización, tales como Open Services para la colaboración del ciclo de vida (OSLC) y la World Wide Web (W3C) Linked Data.

Las organizaciones que utilizan PaaS y, sobre todo, la plataforma de aplicaciones como un servicio (APAAS) son fuertes candidatos para ADLM PaaS.

Reconocer que la integración de los procesos del ciclo de vida de las aplicaciones se inicia con la estandarización interna de procesos y datos (como definiciones para el proceso de corrección de defectos, la gravedad y prioridad). Establecer un papel arquitecto ADLM para gestionar estas definiciones.

Impacto en el negocio: El impacto principal de ADLM PaaS es la presión está puesta en el mercado de crear herramientas que permiten la integración a través del ciclo de vida de desarrollo de aplicaciones heterogéneas herramientas de gestión y procesos. ADLM inicialmente comenzó con un enfoque en las pilas de proveedores individuales y integración que era APL-céntrica. Servicios ADLM entregados en la nube están cambiando las herramientas generales ADLM mercado para obtener las plataformas que utilizan una arquitectura orientada a mensajes y una arquitectura Web que apoya repositorios distribuidos, en lugar de un único repositorio monolítico. Esto se ajusta a las necesidades de la mayoría de las organizaciones de usuarios, donde los elementos de la pila de ADLM (tales como requisitos administración y gestión de la calidad) han sido adquiridos por equipos individuales (como negocio analistas y el equipo de control de calidad). Soluciones ADLM PaaS proporcionan flexibilidad. Conexión herramientas dispares y sus activos permite a los equipos para realizar el valor que se prometió inicialmente con ADLM.

Muy similar, esta es la adopción de métodos ágiles. Las soluciones ADLM PaaS proporcionan sólido apoyan y, en virtud del formato de entrega, que tienden a estar bien diseñado para la colaboración naturaleza de los métodos ágiles. Esto reduce la complejidad de la implementación y la colaboración de los equipos, y permite a las empresas escalar más fácilmente las prácticas y apoyo ágiles geográficamente equipos dispersos, aprovechando las tasas de trabajo y habilidades.

La empresa también se beneficia de ADLM PaaS través de la reducción de costes de aprovisionamiento y mantenimiento, así como la flexibilidad para que coincida con el cambio de las estructuras de trabajo y el uso interno (potencialmente distribuido) los trabajadores, combinado con el desarrollo externalizado o crowdsourcing. Por herramientas de avanzar hacia un formato más colaborativo y navegador entregado, creemos que el desarrollo y el negocio pueden integrarse con más fuerza. Esto proporcionará mayor la transparencia en el estado del proyecto, así como apoyar la capacidad de desarrollar colaborativamente requisitos y mover de manera eficiente a través de pruebas de aceptación del usuario.

Clasificación Beneficio: Moderado

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Emergentes

Los vendedores de la muestra: Atlassian; CollabNet; Elementool; Enalean; GitHub; HP; IBM; Kovair; Microsoft; QMetry; Rally; Tasktop; VersionOne; céfiro

Página 35 de 43

Lectura recomendada: "Plataforma como servicio: Definición, Taxonomía y Vendor Landscape, 2013"

"Magic Quadrant for Life de desarrollo de aplicaciones de gestión del ciclo"

"Cómo elegir productos ADLM como móviles y la nube Tecnologías Prolifera"

Gobierno de servicios de aplicacionesAnálisis por: Paolo Malinverno

Definición: Aplicación sen / gobierno hielos gestiona el ciclo de vida de la arquitectura orientada a servicios (SOA) y servicios de APIs, y el establecimiento de políticas y hacer cumplir para su definición / diseño / uso por aplicaciones. Gartner ha presentado recientemente la "gobernabilidad servicios de aplicación" para referirse a la unión de las funciones de tecnología del gobierno de SOA y la gestión de la API, con la opinión de que estos con el tiempo se unificaron los aspectos.

Justificación de rapidez de posición y adopción: Aplicación sen/ CIEM gobierno reconocidamente cadenas junto a tres de los más abusados (y mal) en términos de TI, pero esto es en definitiva lo que los dos conjuntos de funcionalidad (tecnología gobierno de SOA y gestión API) hacen, y el nombre deben ayudar aclarar la confusión, no genera nuevas dudas. Después de todo, en la mayoría de los oasis, los que hablan sobre los servicios de SOA y los que hablan de APIs significar lo mismo. Recuerde que una API, estrictamente hablando, se define como un método de acceso a un servicio (o una interfaz de servicio, para utilizar SOA terminología).

Todas las APIs y servicios pasan por varias etapas de su ciclo biológico (como se muestra en la Figura 2 en "Gobernar Sus Servicios y gestionar sus APIs Con gobernanza de los servicios de aplicación "). Los servicios de aplicaciones la gobernabilidad es una disciplina de gestión que rige cómo APIs y servicios evolucionan de una etapa a el otro.

Las características de las dos corrientes de la gobernanza servicios de aplicación son muy diferentes cuando se viene a colocarse en el Hype Cycle:

• Tecnologías de gobernabilidad SOA tradicionales han sido de alrededor de unos 10 años. Ellos son normalmente utilizado en en las instalaciones, proyectos SOA clásicos que son ahora la corriente principal. Sin embargo, SOA tecnologías de gobierno siempre han arrastrado madurez SOA por al menos dos años, porque (erróneamente) la mayor parte de los proyectos de SOA no veo la necesidad de una gobernanza hasta la una o dos años después del inicio del proyecto. Hace tres años, las tecnologías de gobierno SOA fueron cayendo en el Trough de desilusión.

• Gestión de API está madurando rápidamente, tiene un gran potencial de futuro (como API nube -gestión) y se utiliza normalmente en la nube para gestionar APIs que las empresas publican para su uso por las aplicaciones de empresa a consumidor (B2C) / B2B móviles y web.

La posición actual del análisis de la aplicación de tecnología de gobierno / hielos sen (y su vencimiento) es un promedio ponderado de las dos posiciones diferentes del ciclo de bombo, y tiene en cuenta la todavía creciente expectación en torno a la gestión de API. Bombo para la gestión de API probablemente abrumará uso establecido de tecnologías de gobernabilidad SOA (que se mueven mucho más lentamente) en el próximo año o dos. En ese momento, los dos espacios funcionales se han transformado en uno al otro, y será difícil distinguir entre ellos. Ya, terminología de gestión de la API se está apoderando (por ejemplo, los servicios en los proyectos de SOA son cada vez más llamados APIs). Sin embargo, por el momento es bueno para separar la gestión API nube entrada bombo Ciclo por su cuenta, incluso si es un subconjunto propio de aplicación gobernabilidad servicios.

Página 36 de 43

Consejo al usuario: A pesar de la superposición de funciones, especialmente en el / etapa operar correr, el gobierno de SOA tecnologías y gestión de API todavía se refieren a la utilización de diferentes vocabularios. Por un lado, quiere regir el diseño y el funcionamiento de los servicios. Por otra parte, desea gestionar la publicación de la API para las comunidades deseadas de los desarrolladores y el funcionamiento de APIs por el aplicaciones / apps que construyen. En un caso, se intenta impulsar la reutilización de servicios por parte, por lo general, interna los usuarios que no quieren ser gobernados. En el otro caso, intenta guiar Web y de aplicaciones móviles los desarrolladores utilizar las APIs mediante la aplicación de niveles de claridad y en gran parte por el hombre libre de la gerencia.

Vemos cada vez más clientes que buscan funcionalidad gobernabilidad servicios de aplicaciones contactando SOA proveedores de tecnología de gobierno y proveedores de administración de la API, con frecuencia siendo incierto las ofrendas en ambos lados. Prácticamente todos los fabricantes de ambos lados son muy conscientes de esta superposición, y que comercializan a ambas comunidades. Los clientes no deben ser confundidos por las diferentes terminologías utilizadas. Simplemente deben buscar la funcionalidad de gobierno o de gestión que necesitan, no importa cómo se etiqueta. Como señalado anteriormente, tomará aproximadamente dos años más para las diferencias en la terminología para alisar.

Gobernabilidad Servicios de aplicaciones es su póliza de seguro de obtener valor de sus servicios / APIs. Sin ella, ni siquiera será capaz de medir cuál es el valor que está recibiendo de ellos (si acaso).

Gobernabilidad Servicios de aplicaciones también juega un papel fundamental en F'aaS, y en aplicación naciente patrones de diseño como el definido por software arquitectura (SDA), donde una capacidad de TI se virtualiza por exponer un conjunto de ("exteriores") APls virtuales que desacoplar la implementación de la capacidad de su consumidores

Impacto en el negocio: El impacto en el negocio de la falta de gobernanza en los proyectos de SOA se ha discutido extensamente en la investigación de Gartner. Además, los servicios de publicación y APIs han sido las formas tradicionales a participar en los procesos B2B multiempresa. Este tipo de uso está aumentando rápidamente. Nube sen / hielo corredurías también serán grandes usuarios de la aplicación sen gobernanza / hielos en el futuro (ver "Diseñar una Gestión Sistemática API y Estrategia de Gobierno de Largo Plazo CSB Éxito").

El uso de Web APIs está aumentando aún más, por lo general el apoyo a nuevos canales de venta a través de aplicaciones móviles o Web. Empresas de todos los sectores están descubriendo poco a poco que pueden mejorar su negocio mediante la publicación de los datos y / o funcionalidad de circunscripciones específicas de los usuarios, por lo general fuera de la empresa. En particular, los centros de innovación en las organizaciones de tipo A aficionados a explorar nuevas formas de conectarse con sus clientes equiparan cada vez más un canal Web a un nuevo negocio oportunidad, y tener un buen manejo de la API es una manera de permitir que la medición y / mejora de su valor. APIs son nuevos canales de distribución. No CIO puede ignorar su potencial de negocio y la transformación que hará que en los departamentos de LT en el futuro, y debido a la omnipresente adopción de SOA y la creciente importancia de la telefonía móvil y el lote, la gestión de API es esencial en un Web-escala entorno empresarial digital. Sin ella, las organizaciones corren el riesgo de pérdida de productividad, la eficiencia y la integridad de sus procesos de información.

Clasificación Beneficio: Alto

Penetración de mercado: 5% a 20% de audiencia objetivo

Página 37 de 43

Madurez: Emergentes

Los vendedores de la muestra: Sscale; Apigee; Axway (\ / ordel); CA Technologies (Capa 7); IBM; lntel; lntel (Mashery); Métodos administrados; MuleSoft; Oracle; Software AG; Software SOA; Software Tibco; WSO2

Lectura recomendada: “Gobernar sus servicios y administrar sus APIs del gobierno corporativo de servicios de aplicaciones"

"Diseñar un API de administración sistemática y Estrategia de Gobernabilidad para Long-Term CSB Éxito"

"Magic Quadrant for SOA Governance Tecnologías"

"Cómo entender los criterios para el 2013 Aplicación Sen / hielos Gobierno Tecnologías Magia Cuadrante"

"Cuadrante Mágico de Aplicación Servicios Gobierno "

"Predice 2013: Desarrollo de Aplicaciones"

Pruebas de softwareAnálisis por: Gilbert van der Heiden; Kris Doering

Definición: Crowdtesting es el uso de las comunidades crowdsourced vetados o unvetted para el propósito de las pruebas de aplicaciones.

Justificación de rapidez de posición y adopción: Crowdtesting se ha añadido como un perfil en el Hype Cycle porque se ha convertido en un mercado en sí mismo con los jugadores claras y profesionalización rápida servicios y proveedores. Crowdtesting es uno de los primeros servicios de crowdsourcing comercializados, con empresas como uTest (más de 100.000 probadores) y Mob4Hire (60.000), y muchos más pequeños empresas que actúan más regional como el traje europeo Passbrains (4000), Bugcrowd de Australia (8000) y Crowdtest de Brasil (5000). Es también el servicio que los proveedores de servicios de aplicaciones (en menos ocho con capacidades globales de entrega están investigando el potencial comercial) Actualmente pilotaje para entregar con (crowdsourcing) socios o su banco interno. Con un promedio de 80% utilización de los recursos de servicios de aplicaciones (incluido el personal de pruebas), proveedores de servicios, por consiguiente desplegar el 20% de los esfuerzos exploratorios impredecibles y más como crowdtesting.

Desde la perspectiva del usuario final, crowdtesting es una ofrenda aceptable a veracidad y validación aplicaciones desde una perspectiva funcional y no funcional. Servicios crowdtesting común comprender las pruebas funcionales, pruebas de rendimiento, pruebas de usabilidad, pruebas de seguridad, localización pruebas y móvil de pruebas / movilidad. La mayoría de los servicios crowdtesting se entregan a través de un portal de crowdsourcing donde los clientes cargar la aplicación que se va a probar, o proporcionan acceso a Internet entornos o extremos delanteros Web que permiten realizar pruebas remotas de las aplicaciones implicadas – o entorno de aplicaciones (como el front-end web). Esto implica cada vez más basado en la nube aplicaciones como SaaS o aplicaciones se basan en PaaS. Con la combinación de la mayor la madurez de este tipo de soluciones basadas nativo nube y las ofertas de servicios crowdtesting, puede ser espera que crowdtesting dará un salto rápido hacia la madurez y la capacidad de llegar a la pendiente de La iluminación en los próximos dos años.

Sin embargo, desde la perspectiva del usuario final, crowdtesting es actualmente todavía impulsado principalmente por las aplicaciones que son más centrado en el usuario. Crowdtesting está, por lo tanto, más considerado y aplicado de los organizaciones que desarrollan aplicaciones de cara al cliente

Página 38 de 43

(principalmente móviles), donde la experiencia del usuario es fundamental, por lo tanto, los comentarios de los primeros usuarios se convierte en un insumo muy importante.

Consejo al usuario: Los usuarios finales deberían considerar sin duda crowdtesting, pero deben comenzar utilizando comunidades crowdsourced, ya sea unvetted (por ejemplo, para la prueba exploratoria o utilidad) o vetados (por funcionales, de rendimiento, localización y pruebas de seguridad). LF los requisitos internos capacidades de gestión son fuertes, el compromiso del propietario o propietarios de las aplicaciones es se justifica, las capacidades de la arquitectura y de integración para el dominio de aplicación respectiva son madura, y la organización sabe cómo romper los requisitos en los concursos, que pueden considerar crowdtesting través de comunidades crowdsourced bajo su propio control. En ese caso, la organización que interactuar con una compañía crowdsourcing puramente para acceder a la prueba multitud, pero controlar a la multitud a sí mismos. Si ninguno de los requisitos mencionados está en su lugar, organizaciones deberían abstenerse a sí mismos de crowdtesting ya que se producirá un error. Cuando al menos compromiso y capacidades de la arquitectura son competentes, con base en la comunidad crowdsourced sen / hielos de un empresa crowdsourcing son la mejor manera de empezar. En ese caso, la compañía crowdsourcing haría gestionar la multitud y entregar el crowdtesting como un servicio a la organización.

En todos los casos al considerar crowdtesting, la organización de usuario final debe verificar la prueba metodología y tecnología de prueba para poder entender y, en principio, controlan la diferencia entre defectos para identificar y minimizar las fugas de defectos y reinyección defecto. Esta verificación de la multitud mecanismos de control también deben incluirse en las obligaciones contractuales del crowdsourcing compañía cuando controlan la prueba. Para minimizar el riesgo para el usuario final, el coste real crowdtesting debe relacionarse con defectos encontrados en un marco de tiempo definido, no horas pasan. El tiempo de Se requiere bastidor para evitar recorridos largos que retrasan la aplicación efectiva de la aplicación probada, y permitir la organización de usuario final para mover el negocio de pruebas a otro crowdsourcing empresa si la prueba no tiene éxito (lo suficiente) en el marco de tiempo definido.

Impacto en el negocio: El principal impacto desde una perspectiva empresarial es el acceso más amplio a los probadores en todo el mundo para casi cualquier dominio o disciplina en muchos idiomas. También proporciona el beneficio de costo-eficiencia - si los requisitos previos están en su lugar - como crowdtesting se entrega "como servicio" con pago mayormente basado en recompensas por defectos encontrados (así que el pago sólo por defecto), o por dispositivo por plataforma (para aplicaciones móviles), o por presupuesto definido (impulsado por resultados basados en concurso y presupuesto preasignados).

Un efecto secundario se refiere a la facilidad de uso y pruebas exploratorias, permitiendo a las organizaciones verificar realidad la experiencia del usuario de un entorno de aplicación o aplicación, que es muy útil a partir de una comercialización y atención al cliente y la perspectiva gestión de la experiencia del consumidor. Especialmente en lo consumerización es un controlador básico de comportamiento de compra del cliente, como un agregado de individuo el comportamiento de compra del consumidor. Sin embargo, sin lugar a dudas, el uso crowdtesting conlleva un riesgo de seguridad y debe utilizarse de acuerdo con la empresa y los controles reglamentarios.

Clasificación Beneficio: Moderado

Penetración de mercado: 1% a 5% de audiencia objetivo

Madurez: Adolescente

Página 39 de 43

Los vendedores de la muestra: 99tests; Bugcrowd; Prueba Crowdsourced; CrowdTest; Mob4Hire; Passbrains; uTest

Lectura recomendada: "Piloto del empleo de Comunidades Crowdsourced para la Aplicación Desarrollo para lograr lnnovation Agile"

"Guía de proveedores al Servicio Application Testing Derecho Socio"

"Tendencias del Mercado: Cómo navegar con éxito La intensa competencia en pruebas de aplicaciones"

Desarrollo móvil híbridoAnálisis por: Ian Finley

Definición: desarrollo móvil híbrido permite a los desarrolladores utilizar las habilidades y tecnologías web para construir aplicaciones móviles que se pueden cargar en una tienda de aplicaciones, descargar a un dispositivo móvil y usado como una aplicación móvil nativa. Tecnologías híbridas permiten la reutilización de código a través de múltiples, móviles incompatibles Sistemas operativos y puede generar aplicaciones que se acercan a la apariencia de las aplicaciones nativas.

Justificación de rapidez de posición y adopción: Desarrollo móvil híbrido ofrece una productiva y de manera rentable para construir aplicaciones móviles altamente interactivas para los muchos dispositivos móviles y sistemas operativos versiones en uso por los clientes, socios y empleados. Mientras que muchos de los juegos, medios de comunicación y social aplicaciones que son los más populares en las tiendas de aplicaciones de consumo fueron desarrollados como aplicaciones nativas, la popularidad del desarrollo de híbridos sigue aumentando, especialmente dentro de aplicaciones empresariales grupos de desarrollo.

Dado el potencial alto costo y la complejidad del desarrollo de aplicaciones móviles nativas, muchas empresas prefieren utilizar el desarrollo móvil híbrido siempre que sea posible. Muchas empresas tienen estandarizado en el desarrollo Web como su principal forma de construir nuevo cliente, socio y aplicaciones de empleados utilizados a través de PC’s. Con el crecimiento del uso de dispositivos móviles, muchos de ellos también han construido sitios web móviles que utilizan las mismas Web activos, habilidades y tecnologías. Apalancamientos desarrollo de híbridos Estos activos, capacidades y tecnologías para la creación de aplicaciones móviles atractivas que se ven y se sienten similares a los construidos a través de desarrollo de aplicaciones móviles nativas. A diferencia de código nativo, código híbrido es altamente portátil a través de diferentes sistemas operativos móvil. Toda la principal plataforma de desarrollo de aplicaciones móviles (MADP) vendedores, que no sean de Apple y Google, han respondido a las necesidades de la empresa y abrazado híbrido desarrollo de aplicaciones móviles.

Consejo al usuario: Cuando un rico sitio web para móviles no cumplirá con los requerimientos del negocio, considere la construcción de un aplicación móvil con el desarrollo móvil nativa híbrido o. El desarrollo de híbridos se ve favorecida cuando el costo eficiencia y compatibilidad con dispositivos amplio son altas prioridades. Desarrollo nativo se ve favorecida en el más apps, donde Ul reactividad, rendimiento de los gráficos y la velocidad de procesamiento son de exigir primordial importancia. Tenga en cuenta que para las aplicaciones más exigentes, el desarrollo de híbridos podría ser una opción viable, pero no tiene ningún costo o la productividad ventaja sobre el desarrollo nativo. Considerar utilizando un MADP que soporta Web móvil, híbrido y el desarrollo nativo, pero no esperes un solo MADP ser la mejor opción para todas sus móviles de sitios web y aplicaciones.

Página 40 de 43

Impacto en el negocio: Las aplicaciones móviles construidas con el desarrollo móvil híbrido puede ayudar a las empresas a mejorar compromiso con el cliente y el empleado y socio de la productividad y la colaboración - a veces muy dramáticamente.

Clasificación beneficio: Alta

Penetración de mercado: 5% a 20% de audiencia objetivo

Madurez: Adolescente

Los vendedores de la muestra: Adobe PhoneGap; Apache Córdoba; IBM; salesforcecom; SAP; Telerik; Trigger.io

Lectura recomendada: "Puente del HTML5, Nativo Aplicaciones Gap Con Enfoque Híbrido"

"Aumentar la eficacia del equipo móvil mediante la comprensión de la Web, los nativos y Híbridos Compensaciones"

"Taxonomía, Definiciones y Vendor Landscape para móviles ad Tecnologías"

"Cuadrante Mágico para Plataformas de desarrollo de aplicaciones móviles"

Frameworks PaaSAnálisis por: Yefim Natis V.; Gregor Petri

Definición: Marco de trabajo de un PaaS es software de gestión diseñado para ofrecer middleware como servicio basado en nube. Marcos PaaS puede ser como la plataforma para una PaaS especializados o para una PaaS multifuncionales integrados. Marcos PaaS solo no forman un completo PaaS ya que incluir la infraestructura, pero no el propio middleware, pero todos los marcos de PaaS disponibles son distribuidos con algún middleware administrado. Según lo estipulado, los marcos de PaaS son suites de software diseñado para establecer una PaaS privadas o públicas en un centro de datos de la elección del usuario.

Justificación de rapidez de posición y adopción: marcos de PaaS son software de gestión que implementar infraestructura para la adopción, el aprovisionamiento, el seguimiento y la ampliación de la tecnología preparada pilas (particularmente middleware como servidores de aplicaciones, los DBMS y autobuses de servicios empresariales [ESB]). Marcos PaaS están diseñados para formar los servicios de nube privada o pública e incluir inquilino interfaces de gestión y auto-sen / usuario hielo. El PAAS formado utilizando marcos de PaaS es de la tipo basado en la nube (ver "Lo que los líderes de TI deben saber sobre Modelos de aplicaciones PaaS y Uso Patrones "). Las características de las nubes son facilitadas fuera de la propia middleware. Aunque el middleware puede tener que ser preparado de alguna manera, sigue siendo "consciente” de ser utilizado en un entorno de nube multiusuario (contraste que con las PaaS en la nube natal como Force.com, donde el propio middleware gestiona “nubosidad”. Esta disposición permite que los PaaS resultantes para apoyar modelos de programación pre-nube, habilidades y software, pero limita el grado de elasticidad y exige que el software de aplicación se comportan de una determinada manera para evitar la derrota del subyacente características de las nubes.

Marcos PaaS han surgido, como las principales implementaciones basadas en la nube PaaS pasaron de modelos de hardware compartido a compartido-OS (ver "Gartner modelo de referencia para la Elasticidad y Multiusuario "). Si bien los primeros compatibles con versiones públicas ofertas de PaaS

Página 41 de 43

como IBM SmartCloud Servicios de Aplicación (CPEA), Microsoft Azure con sus papeles workerNVeb o Engine Yard utilizaron completo máquinas virtuales (\ / MS) como el incremento mínimo de elasticidad (en hardware compartido), el siguiente generación, incluyendo salestorce.com Heroku, Red Hat OpenShift y Pivotal CF, utiliza OS recipientes como una unidad de elasticidad (compartido OS). Aunque IBM y Microsoft utilizan un marco PaaS tecnología para gestionar las máquinas virtuales para sus implementaciones de PaaS (Workload Deployer y Tela Controller, respectivamente), la mayoría de otros proveedores se basó en la infraestructura subyacente como un servicio infraestructura (LAAS). Para proporcionar la elasticidad-OS compartido, proveedores de plataformas deben establecer un software de gestión especializado, ya que el software los proveedores o Laas Laas a habilitar – tales como plataformas de gestión de nube - no (todavía) apoyar la gestión de contenedores del sistema operativo. La modelo-OS compartida de elasticidad es potencialmente más eficiente, más rápido y más elástica que shared- hardware porque su unidad de incremento es más ligero y más pequeño. Junto con el revés compatibilidad del modelo de programación, esto crea la creciente demanda de marco PaaS software.

APIs web pública

Diseño sensible

Gestión del portafolio de aplicaciones

Herramientas UX

Pruebas de seguridad de aplicaciones interactivas

Desplazamiento en el canal

Tiendas de app móvil empresarial

Obtención y simulación de requisitos

Gestión de datos de prueba

Apps

Ocultación de datos dinámicos

Suites ADLM federadas

Herramientas y servicio de prueba en la nube

Pruebas SOA

Lenguajes de programación funcional

Análisis de composición de software

Versiones distribuidas

Página 42 de 43

Escalando la pendiente

Aplicaciones de gestión de proyectos y portafolio de TI

Pruebas de seguridad de aplicaciones estáticas

Integración continua

Metodología de desarrollo ágil orientado a proyectos

Arquitectura orientada a web

Ocultación de datos estáticos

Desarrollo móvil nativo

Apéndices

Fases del ciclo Hype, índice de beneficios y niveles de madurez

Lectura recomendada Gartner

Tabla 1. Fases Hype Cycle

Tabla 2. Clasificación beneficio

Tabla 3. Niveles de madurez

Figura 3. Ciclo de sobre-expectación para el desarrollo de aplicaciones, 2013

Página 43 de 43