SG #54 https://sg.com.mx/ en SPINGERE La empresa especializada en medición y estimación de Software https://sg.com.mx/revista/54/spingere-la-empresa-especializada-medici-n-y-estimaci-n-software <span class="field field--name-title field--type-string field--label-hidden">SPINGERE La empresa especializada en medición y estimación de Software</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/Spingere.png" width="3164" height="2005" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 18:57</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/seccion-revista/contenido-patrocinado" hreflang="und">Contenido patrocinado</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p data-entity-type="" data-entity-uuid="" style="text-align: center;"><span><img alt="" height="173" src="https://lh5.googleusercontent.com/khNLCnb850ZkD2uldMlJ4_vV_8cMNNO9o2T0_-q7v7ubgHEJsKBCAJZNmX_49CFWmgp9iJLcasiswtWLI-MkY-2AWt9aV_bCXcDdxffIlW4zLgMNA8nQN1ih-ouuDbUymhvMXvWA3zuuVj7zmQ" style="font-size: 13.008px;" width="273" /><span title="Click and drag to resize">​</span></span></p> <p dir="ltr"><span>Alguna vez te has preguntado: ¿si lo que pagas por los proyectos de software es adecuado?, ¿si el tiempo/costo/esfuerzo que te dan como estimado para desarrollar un aplicativo es confiable?, ¿si hay alguna forma adecuada de determinar la productividad de un equipo de desarrollo?, ¿si es posible tener un control cuantitativo de tus proveedores y tus proyectos? ¿si estás contratando con las mejores condiciones para el Estado?</span></p> <p dir="ltr"><span>Existen varios estudios que presentan resultados no satisfactorios, que reflejan la falta de madurez de la disciplina de ingeniería de software, y en consecuencia los malos resultados en los proyectos desarrollados, por ejemplo, un estudio del Standish Group &nbsp;(2012) muestra que el desarrollo de proyectos exitosos es de menor al 40% , un estudio de McKinsey &nbsp;(2012) que indica que “en promedio, los grandes proyectos de TI se exceden en un 45% sobre el presupuesto y 7% sobre el tiempo, mientras que entregan 56% menos del valor esperado”, otro ejemplo es el estudio de KPMG (2010) donde se menciona, entre otras cosas que &nbsp;“..un increíble 70% de las organizaciones han sufrido al menos un proyecto fallido en los 12 meses anteriores”</span></p> <p dir="ltr"><span>El The Global Information Technology Report (2016), proyecto especial del Foro Económico Mundial (www.weforum.org/gitr), establece que el mundo está entrando en la Cuarta Revolución Industrial, que es caracterizada por la convergencia de tecnologías digitales, físicas y biológicas, menciona claramente que esta Revolución no está definida por ningún conjunto de tecnologías emergentes, pero si por la transición &nbsp;de nuevos sistemas que serán construidos sobre la infraestructura de la revolución digital, siendo las tecnologías (TIC’s) la columna vertebral de esta revolución.</span></p> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span>Es claro, por tanto, los avances de la tecnología van a demandar la generación de una mayor cantidad de software, ¿se puede desarrollar software sin tener medidas de tamaño? La respuesta es sí, en la mayoría de los casos así se hace, sin embargo, esto fomenta que el desarrollo de software sea un arte, y no un proceso ingenieril, con resultados como los ya mencionados.</span></p> <p dir="ltr"><span>“According to testimony by the Government Accountability Office last September, if were established more realistic baselines of requirements, cost, schedule and risk during project’s planning phases, nearly half of canceled or over budget IT programs could be avoided. That would save $5.5 billion annually, according to a study made by Price Systems LLC, a software and consulting company in Mount Laurel, N.J., USA. The study consider 104 Government IT executives” (PMI, 2007)</span></p> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span>Medir el software de manera formal mediante estándares, nos puede redituar en eficiencia del gasto y transparencia en la contratación, en tener mejores estimaciones de costos y gestionar mejor los proyectos tanto en el sector público como en el privado, además de blindar los procesos de compras, y dar cumplimiento a la normatividad para el caso de la Administración Pública Federal (APF). </span></p> <p dir="ltr"><span>SPINGERE presenta una oferta especializada en servicios de consultoría y de capacitación orientados a la medición, estimación y evaluación cuantitativa de proyectos de software, es la primera empresa especializada al respecto en México y América Latina, en idioma español, su oferta está basada en investigación aplicada desarrollada en México y presentada en distintas conferencias nacionales e internacionales. </span></p> <p dir="ltr"><span>Dentro de los beneficios que han obtenido nuestros clientes tanto del sector gobierno como de la iniciativa privada se encuentran:</span></p> <ul> <li dir="ltr"> <p dir="ltr"><span>Certeza en la estimación de proyectos</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Eficiencia en uso del presupuesto y transparencia</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Gestión cuantitativa de las capacidades de desarrollo de software</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Mejor control de los proveedores</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Cumplimiento a normatividad (MAAGTICSI y LFMyN)</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Blindaje del gasto ante auditorías</span></p> </li> <li dir="ltr"> <p dir="ltr"><span>Mejoras en procesos&nbsp;de desarrollo de SW</span></p> </li> </ul> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span>La manera en que lo hacemos es a través de nuestra metodología de servicios denominada y registrada “Software Accountability Office - SAO ® “, que es una oficina integrada por un grupo de especialistas en gestión cuantitativa de proyectos, que te ayuda a dimensionar, estimar y evaluar proyectos de software, utilizando estándares internacionales como COSMIC (ISO/IEC 19761) o ISO 25000 apoyados de la investigación aplicada que se realiza.</span></p> <p dir="ltr"><span><img alt="" data-entity-type="" data-entity-uuid="" height="346" src="https://lh5.googleusercontent.com/zbvgsrCp3cZNsFiyUAQ594It6h1ws2XmvCqpbgF8hq_ZYcXk0nyNPwWMmZXNxyavmfD4dwViyIrWJBJaQceORAtwFrNbb-07Z_ozUyNCE-1F2nVnYZXmbXn2n-qOggfwqYSfT5ULyKs-Cu3ScQ" width="400" /></span></p> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span>Desde 2009, SPINGERE ha comercializado servicios relacionados con el método COSMIC, en abril 2014 fue designado como es el único “vendor” autorizado por el “Common Software Measurement International Consortium (COSMIC)” para proporcionar consultoría, capacitación e implementación de ISO/IEC 19761, así como realizar investigación al respecto en México, situación que se ratificó en febrero de 2017, ambas ocasiones mediante una carta emitida por el Consorcio COSMIC y apostillada por la Secretaría de Relaciones Exteriores. </span></p> <p dir="ltr"><span>¿Necesitas tener certeza de lo que pagas por el software? ¿Deseas disponer de elementos cuantitativos que te permitan negociar las propuestas presentadas por tus proveedores? ¿Te gustaría tener un mejor control de tus proveedores y tus proyectos? ¿Quieres saber si estás contratando con las mejores condiciones para el Estado? ¿deseas blindar tus contratos de fábrica de software respecto del gasto ejercido?, Contáctanos y conoce nuestra oferta de servicio y los beneficios que puede traer a tu organización en </span><a href="http://www.spingere.com.mx"><span>www.spingere.com.mx</span></a></p> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span>En mayo de este año se realizará el 2do Congreso Nacional de Medición y Estimación de Software (CNMES17), durante el congreso los ponentes más representativos a nivel Nacional e Internacional, expondrán sus experiencias basadas en las últimas tendencias en medición y estimación de software con la finalidad de enriquecer el conocimiento de los asistentes y orientarlos para un eficiente desarrollo del software. Este esfuerzo es promovido por la Asociación Mexicana de Métricas de Software (AMMS), SPINGERE y el Consorcio COSMIC, quienes han concentrado un grupo de expertos en los temas de Medición y Estimación de Software, así como usuarios de estos métodos, con la intención de difundir la teoría y la práctica a través de la participación en conferencias.</span></p> <p dir="ltr"><span>Entre los ponentes confirmados se encuentran: Dr. Alain Abran (Chairman de COSMIC), Frank Vogelezang (presidente de COSMIC), Dr. Francisco Valdés Souto (Profr. Asociado C de la FC-UNAM y Fundador de la AMMS). La información completa del evento la encuentras en </span><a href="http://www.cnmes.mx"><span>www.cnmes.mx</span></a></p> <p><span><span>&nbsp;</span></span></p> <p dir="ltr"><span><img alt="" data-entity-type="" data-entity-uuid="" height="419" src="https://lh6.googleusercontent.com/e_LcIY5IZC__sCV61uGfLA8txQZmQ24Bo_IqMq6rB-uxWO8RTBblVjq8bFljp95sNdwATidr7v1s8IHsMBOBHYOfzwTV2-4FVzvx9ezDCT6uKbboNFEaPwry-rfqIk5RbaDRh4BnpJTvjOnG5Q" width="589" /></span></p> <p><span>&nbsp;</span></p> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 03 May 2017 23:57:34 +0000 ana2lp 7275 at https://sg.com.mx https://sg.com.mx/revista/54/spingere-la-empresa-especializada-medici-n-y-estimaci-n-software#comments Radar SG54 https://sg.com.mx/revista/54/radar-sg54 <span class="field field--name-title field--type-string field--label-hidden">Radar SG54</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/pexels-photo-256112.jpeg" width="1280" height="853" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 18:36</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/secci%C3%B3n-revista/lo-que-viene" hreflang="und">Lo que viene</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><h3 dir="ltr">Jenkins lanza Blue Ocean para facilitar continuous delivery</h3> <p dir="ltr">Jenkins, el servidor open source de automatización para entrega continua anunció la disponibilidad de Blue Ocean 1.0. Esta es una nueva interfaz diseñada para fácilmente crear, visualizar y diagnosticar pipelines de entrega continua. El objetivo es que Blue Ocean permita a equipos novatos con poco conocimiento de Jenkins arrancar rápidamente en su adopción hacia la entrega continua. Entre sus capacidades destacan:</p> <ul> <li dir="ltr"> <p dir="ltr">editor visual para pipelines, de manera que por medio de drag-and-drop puedas crear tu pipeline; visualización de pipelines;</p> </li> <li dir="ltr"> <p dir="ltr">analizador de pipeline que provee un diagnóstico y localiza problemas sin necesidad de estar buscando en las bitácoras;</p> </li> <li dir="ltr"> <p dir="ltr">dashboard personalizado para solo ver los pipelines que te interesan;</p> </li> <li dir="ltr"> <p dir="ltr">integración profunda con github.</p> </li> </ul> <p dir="ltr"><a href="https://jenkins.io/projects/blueocean/">https://jenkins.io/projects/blueocean</a></p> <p dir="ltr">——</p> <h3 dir="ltr">Microsoft posicionándose como jugador de Industria 4.0</h3> <p dir="ltr">Ante la ola de la Industria 4.0, las empresas de manufactura comienzan a preguntarse qué necesitan hacer para comunicar y dotar de inteligencia a sus líneas de producción. Empresas proveedoras de equipo industrial como GE, Bosch y Siemens están levantando la mano para involucrarse en este espacio. Del lado de los proveedores tradicionales de software, Microsoft es de los más activos y recientemente actualizó las capacidades de su Azure IoT Suite, ofreciendo una solución preconfigurada llamada “Connected Factory” que facilita el arranque de soluciones de internet industrial o industria 4.0. Otra capacidad nueva es poder hacer analítica de datos en dispositivos en la orilla (edge) para poder analizar los datos en tu misma red sin tener que transmitirlos a la nube; esto da ventajas de velocidad, seguridad y consumo de banda ancha. Microsoft también dio a conocer una iniciativa SaaS para IoT denominada Azure IoT Central. Esta será una oferta SaaS para IoT completamente administrada que busca reducir significativamente la complejidad de las soluciones IoT. El servicio todavía no está abierto al público pero puedes conocer más al respecto en <a href="http://microsoftiotcentral.com">http://microsoftiotcentral.com</a></p> <p dir="ltr">——</p> <h3 dir="ltr">Docker sugiere contenedores para modernizar aplicaciones</h3> <p dir="ltr">Durante DockerCon 2017, Docker dio a conocer una iniciativa denominada “Modernize Traditional Applications” que básicamente consiste en envolver aplicaciones legadas en contenedores para moverlas del hardware que utilizan actualmente hacia infraestructura moderna administrada como nube híbrida. La promesa es que sin necesidad de cambiar código fuente se obtengan mejoras en utilización de recursos, escalabilidad, uptime y seguridad, entre otros. Para sustentar esta oferta, Docker ofrece una versión especial de su tecnología llamada Docker Enterprise Edition. Adicionalmente, empresas como Microsoft, Cisco y HPE están involucradas en la iniciativa para asegurar que sus productos soporten adecuadamente a las empresas que deseen tomar este camino para modernizar sus aplicaciones. <a href="http://www.docker.com/MTA">http://www.docker.com/MTA</a></p> <p dir="ltr">——-</p> <h3 dir="ltr">Next.js, el framework para facilitar React</h3> <p dir="ltr">En el mundo del front-end, posiblemente la tecnología más candente en estos momentos sea React. Con esta popularidad, también han surgido frameworks para React, y uno de los que más nos gusta es Next.js. Este framework pequeño pero poderoso busca reducir significativamente la complejidad de construir aplicaciones React. La primer versión de Next.js apenas fue publicada en octubre del 2016, y en marzo de 2017 ya tenemos la segunda. Entre las capacidades incluidas en esta nueva versión está el soporte a componentes CSS que permite que los desarrolladores escriban CSS de forma tradicional abstrayéndose de las particularidades de CSS en React. Todo parece indicar que React tendrá fuerza por varios años, y Next se está posicionando como una buena opción de framework, así que si tienes oportunidad échate un clavado en <a href="https://github.com/zeit/next.js">https://github.com/zeit/next.js</a></p> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 03 May 2017 23:36:52 +0000 ana2lp 7274 at https://sg.com.mx Noticias SG54 https://sg.com.mx/revista/54/noticias <span class="field field--name-title field--type-string field--label-hidden">Noticias SG54</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/man-hands-reading-boy.jpg" width="1280" height="853" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 18:05</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/seccion-revista/noticias" hreflang="und">Noticias</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><h3 dir="ltr"><span>Hackatour Querétaro</span></h3> <p dir="ltr"><span>Querétaro fue la primer parada oficial del Hackatour 2017 de Software Guru el viernes 24 y sábado 25 de marzo de 2017 en las instalaciones de la Facultad de Informática de la Universidad Autónoma de Querétaro. El hackathon formó parte de la celebración de los 30 años de la Facultad de Informática de la UAQ con el patrocinio de Red Hat. Los 130 participantes se organizaron en 28 equipos distintos que construyeron un prototipo para resolver algún problema relacionado con las siguientes temáticas: Ecología y sustentabilidad, inclusión de personas con capacidades distintas o lucha contra el crimen. Consulta las siguientes paradas del Hackatour en &nbsp;</span><a href="https://sg.com.mx/hackatour/"><span>https://sg.com.mx/hackatour/</span></a></p> <h3 dir="ltr"><span>SG Talento, el evento de reclutamiento</span></h3> <p dir="ltr"><span>El pasado 23 de Febrero, con más de 230 asistentes, 5 empresas virtuales, más de 70 candidatos , más de 10 expositores y más de 100 vacantes en CDMX, MTY, GDL y USA se vivió la primera edición del SG Talento. SG Talento es un evento de reclutamiento, networking y sesiones de desarrollo profesional, que reúne a las empresas más reconocidas en TI para ofrecer sus vacantes de trabajo en México y Estados Unidos, además de ofertas para capacitaciones como cursos, talleres, certificaciones, etc. En SG Talento también puedes disfrutar de charlas con ponentes expertos en TI que comparten sus conocimientos y experiencia a través de las sesiones de Desarrollo Profesional. Si quieres conocer más eventos como este puedes visitar</span><a href="https://sgtalento.com/eventos"><span> https://sgtalento.com/eventos</span></a></p> <h3 dir="ltr"><span>Así se vivió Data Day México 2da. Edición</span></h3> <p dir="ltr"><span>El pasado martes 28 de Marzo tuvimos la oportunidad de compartir con cerca de 400 apasionados de los datos en la segunda edición del Data Day, el evento de datos más grande de México. Los contenidos se dividieron en 3 grandes tracks: &nbsp;Data Science MBA, Data Science + Machine Intelligence y Big Data Engineering, y hubo talleres prácticos a cargo de empresas como RStudio y Amazon Web Services. La próxima edición de Data Day será en marzo de 2018. Mantente al tanto en </span><a href="http://sg.com.mx/dataday"><span>http://sg.com.mx/dataday</span></a></p> <h3 dir="ltr"><span>Primera edición del Festival de la FIRST® LEGO® League Jr. en México</span></h3> <p dir="ltr"><span>El sábado 8 de abril se llevó a cabo la primera edición del FestivalFIRST LEGO League Jr. en nuestro país, en el Centro Cultural España, donde 150 niños divididos en equipos, exhibieron los proyectos resultantes de este programa, cada uno pensado en resolver un reto a través de distintas soluciones que mezclan tecnología y creatividad.</span></p> <h3 dir="ltr"><span>DOCKERCON 2017</span></h3> <p dir="ltr"><span>Más de 5,000 personas se dieron cita en la ciudad de Austin, TX del 17 al 20 de mayo para conocer las novedades alrededor la tecnología docker durante DockerCon. Entre los anuncios más importantes del evento podemos mencionar: la nueva capacidad de multi-stage builds para crear imágenes más ligeras; LinuxKit, un toolkit para construir distribuciones de Linux minimizadas e inmutables; y Moby Project, un proyecto open source para modularizar el desarrollo de la plataforma docker. Al ver el amplio interés de tantas personas y empresas de distintas verticales, nos queda claro que la tecnología de contenedores está alcanzando un punto importante en su madurez y está dejando de ser algo solamente para pioneros.</span></p> <p dir="ltr">&nbsp;</p> <p><span id="docs-internal-guid-2c27042a-cce9-4a84-0d53-b2b7b13faf1f">&nbsp;</span></p> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 03 May 2017 23:05:36 +0000 ana2lp 7258 at https://sg.com.mx https://sg.com.mx/revista/54/noticias#comments Integración Continua https://sg.com.mx/revista/54/integraci-n-continua <span class="field field--name-title field--type-string field--label-hidden">Integración Continua</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/intcontinua.png" width="803" height="452" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 17:10</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/buzz/autores/pedro-galvan" hreflang="und">Pedro Galván</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr"><span>El desarrollo de software está lleno de mejores prácticas de las que frecuentemente hablamos, pero rara vez hacemos. Uno de estos casos es el de tener un proceso automatizado para ensamblar y probar versiones ejecutables de nuestro software, de manera que el equipo de desarrollo pueda construir y probar varias veces al día el software en que están trabajando. Este concepto es conocido como “integración continua” y es una de las prácticas de Extreme Programming, sin embargo no es necesario estar siguiendo Extreme Programming para aplicarla.</span></p><p dir="ltr"><span>*Nota: a lo largo de este artículo menciono frecuentemente el concepto de “integrar” software. Esto se refiere al proceso específico de generar una versión ejecutable de un software, que puede involucrar compilar el código fuente, empaquetarlo, incluir archivos de configuración, etcétera; es lo que en inglés se expresa como “to build software”. Adicionalmente, mencionaremos el producto resultante de este proceso, que en inglés se conoce como “software build”, y en español lo estaré llamando “versión ejecutable”.</span></p><p dir="ltr"><span>¿Qué es?</span></p><p dir="ltr"><span>Martin Fowler es uno de los autores más reconocidos en el ámbito de prácticas ágiles y define la integración continua de la siguiente manera: </span></p><p dir="ltr"><span>“La integración continua es una práctica en la que miembros de un equipo integran su trabajo frecuentemente, típicamente cada persona integra al menos una vez al día, generando varias versiones por día. Cada versión ejecutable es verificada por un sistema automático de integración y pruebas para detectar errores de integración lo más rápido posible.”</span></p><p dir="ltr"><span>Implementar esta práctica exitosamente involucra ciertos requisitos:</span></p><ul><li dir="ltr"><p dir="ltr"><span>Tener un repositorio maestro donde esté disponible todo el código fuente y del que cualquier integrante del equipo pueda obtenerlo.</span></p></li><li dir="ltr"><p dir="ltr"><span>Automatizar el proceso de integración para que cualquier persona pueda generar una versión ejecutable del sistema a partir del código fuente.</span></p></li><li dir="ltr"><p dir="ltr"><span>Automatizar las pruebas para que sea posible ejecutar la matriz (suite) de pruebas en cualquier momento con un solo comando.</span></p></li><li dir="ltr"><p dir="ltr"><span>Asegurar que cualquiera puede obtener el ejecutable más reciente y tener la confianza de que es la mejor versión hasta el momento.</span></p></li></ul><p dir="ltr"><span>Todo esto requiere bastante disciplina y requiere un esfuerzo significativo para introducirlo a un proyecto, pero una vez habilitado es sencillo mantenerlo y brinda grandes beneficios.</span></p><h3 dir="ltr"><span>Beneficios</span></h3><p dir="ltr"><span>Estos son algunos beneficios puntuales de la integración continua:</span></p><ul><li dir="ltr"><p dir="ltr"><span>Reducir problemas de integración.</span></p></li><li dir="ltr"><p dir="ltr"><span>Mejorar la visibilidad del estatus del producto de software.</span></p></li><li dir="ltr"><p dir="ltr"><span>Acelerar la detección de fallas.</span></p></li><li dir="ltr"><p dir="ltr"><span>Disminuir el tiempo dedicado a depurar errores.</span></p></li><li dir="ltr"><p dir="ltr"><span>Evitar la espera para averiguar si un código funciona.</span></p></li></ul><p dir="ltr"><span>En resumen, los beneficios de la integración continua consisten en “resolver problemas rápidamente”. Dado que el software es integrado frecuentemente, cuando se encuentra un error típicamente no es necesario retroceder mucho para descubrir donde se introdujo la falla. En comparación, cuando un equipo no sigue una estrategia de integración continua los periodos entre integración son largos y la base de código es muy distinta entre cada integración por lo que cuando se encuentran errores hay que revisar mucho más código, lo cual requiere un mayor tiempo y esfuerzo.</span></p><p dir="ltr"><span>En palabras de Fowler, “la integración continua no elimina los defectos, pero si hace que sea mucho más fácil encontrarlos y corregirlos”.</span></p><h3 dir="ltr"><span>¿Cómo se hace?</span></h3><p dir="ltr"><span>Aunque implantar una estrategia de integración continua no es algo trivial, sí es algo que está al alcance de cualquier organización que desarrolla software sin importar su tamaño, presupuesto o tecnología utilizada. Más que nada es cuestión de que el equipo entienda las prácticas y sea disciplinado.</span></p><p dir="ltr"><span>Comencemos por las prácticas en las que se basa la integración continua [2]:</span></p><ul><li dir="ltr"><p dir="ltr"><span>Mantener un repositorio único del código fuente.</span></p></li><li dir="ltr"><p dir="ltr"><span>Automatizar el proceso de integración (build).</span></p></li><li dir="ltr"><p dir="ltr"><span>Hacer que el producto de software se pueda probar a sí mismo.</span></p></li><li dir="ltr"><p dir="ltr"><span>Cada que se generan nuevas versiones en el repositorio (“hacer commit”) se debe generar una nueva integración en una máquina designada para ello (integration machine).</span></p></li><li dir="ltr"><p dir="ltr"><span>Mantener rápido el proceso de integración.</span></p></li><li dir="ltr"><p dir="ltr"><span>El ambiente de prueba debe ser un clon del ambiente de producción.</span></p></li><li dir="ltr"><p dir="ltr"><span>Los integrantes del equipo deben poder obtener fácilmente la versión ejecutable más reciente.</span></p></li><li dir="ltr"><p dir="ltr"><span>Todos deben poder conocer el estatus en cualquier momento.</span></p></li><li dir="ltr"><p dir="ltr"><span>Automatizar el despliegue.</span></p></li></ul><p dir="ltr"><span>Vale la pena aclarar que aunque la primera práctica indica mantener un repositorio único de código fuente, esto no significa que se tenga que usar un sistema de control de versiones centralizado. Hay que recordar que en un sistema de control de versiones distribuido (DVCS) también hay un repositorio único, es simplemente que tiene varias copias distribuidas.</span></p><p dir="ltr"><span>Una vez que hemos entendido las prácticas y principios podemos entrar a actividades específicas. A continuación describo un posible flujo de actividades para implementar dichas prácticas:</span></p><ol><li dir="ltr"><p dir="ltr"><span>Cada desarrollador obtiene una copia del código en su espacio de trabajo privado.</span></p></li><li dir="ltr"><p dir="ltr"><span>Cuando un desarrollador termina su trabajo, envía sus cambios al repositorio.</span></p></li><li dir="ltr"><p dir="ltr"><span>El servidor de integración continua monitorea el repositorio y detecta los cambios automáticamente.</span></p></li><li dir="ltr"><p dir="ltr"><span>El servidor (de integración continua) integra el sistema y corre las pruebas unitarias y de integración.</span></p></li><li dir="ltr"><p dir="ltr"><span>El servidor publica los artefactos ejecutables.</span></p></li><li dir="ltr"><p dir="ltr"><span>El servidor asigna una etiqueta a la nueva versión y su ejecutable.</span></p></li><li dir="ltr"><p dir="ltr"><span>El servidor informa al equipo el resultado de la integración.</span></p></li><li dir="ltr"><p dir="ltr"><span>Si la integración o pruebas fallan, el servidor alerta al equipo y el equipo lo resuelve lo antes posible.</span></p></li><li dir="ltr"><p dir="ltr"><span>Se continúa integrando frecuentemente a lo largo del proyecto.</span></p></li></ol><p dir="ltr"><span>Para que todo esto funcione se pueden establecer políticas que los integrantes del equipo deban cumplir, tales como: </span></p><ul><li dir="ltr"><p dir="ltr"><span>Registrar (commit) su código al menos una vez al día.</span></p></li><li dir="ltr"><p dir="ltr"><span>No registrar código con errores.</span></p></li><li dir="ltr"><p dir="ltr"><span>No registrar código sin probar.</span></p></li><li dir="ltr"><p dir="ltr"><span>No generar nuevas versiones con código que no funciona.</span></p></li><li dir="ltr"><p dir="ltr"><span>No pueden terminar sus actividades del día hasta haber registrado su código y que el sistema se integre exitosamente.</span></p></li></ul><p dir="ltr"><span>Algunos equipos generan rituales alrededor de estas políticas para ellos mismos controlar que se cumplan sin necesidad de supervisión de algún coordinador o gerente.</span></p><h3 dir="ltr"><span>Entrega y despliegue continuo</span></h3><p dir="ltr"><span>¿Qué sucede si extendemos el concepto de la integración continua hasta llevarlo al despliegue a producción? Es decir, que cada que se cambia el código de la aplicación, automáticamente se genere un build nuevo, y si pasa exitosamente todas las pruebas automáticamente se libere a producción. Esto es lo que se conoce con el nombre de despliegue continuo (continuous deployment) y aunque parezca utópico, es algo que sí existe y hay organizaciones que lo hacen [2].</span></p><p dir="ltr"><span>¿Qué sucede si queremos quedarnos un pasito antes y simplemente dejar el código “listo para producción”, y solamente si estamos seguros que queremos hacerlo, entonces ya “presionemos el botón” para poner en producción? Justamente eso es lo que se conoce como entrega continua (continuous delivery) y es una práctica recomendada, especialmente en el contexto DevOps [3].</span></p><p dir="ltr"><span>Aunque la entrega continua parezca simplemente agregar un paso más a la integración continua y no tener mayores consecuencias, en realidad no es solo eso ya que por lo pronto involucra tener automatizadas todas las pruebas y scripts para migración de datos así como para rollback en caso de fallas. Adicionalmente, tiene un impacto importante en el modelo de ciclo de vida de software ya que embebe prácticas ágiles en el mismo proceso de planeación y construcción de software. Tan es así, que hay quienes dicen que para realmente estar haciendo “Agile” necesitas tener entrega continua, sino lo que estás haciendo no puede ser llamado Agile [4]. A fin de cuentas, la meta de la entrega continua es poner al cliente al mando de lo que se libera y cuándo se libera.</span></p><p dir="ltr"><span>Pero bueno, es un hecho que antes de correr hay que caminar, así que antes de pensar en entrega continua necesitamos dominar la integración continua.</span></p><p><span style="font-size: 13.008px;">Referencias</span></p><ol><li dir="ltr"><p dir="ltr"><span>M. Fowler. “Continuous Integration”. </span><a href="http://swgu.ru/su"><span>http://swgu.ru/su</span></a></p></li><li dir="ltr"><p dir="ltr"><span>T. Fitz. “Continuous deployment at IMVU: Doing the impossible 50 times a day”. </span><a href="http://swgu.ru/sw"><span>http://swgu.ru/sw</span></a></p></li><li dir="ltr"><p dir="ltr"><span>J. Humble. “Continuous Delivery vs. Continuous Deployment”. &nbsp;</span><a href="http://swgu.ru/sx"><span>http://swgu.ru/sx</span></a></p></li><li dir="ltr"><p dir="ltr"><span>I. Buchanan. “Why Agile Development needs Continuous Delivery”. </span><span><a href="http://swgu.ru/sy">http://swgu.ru/sy</a></span></p></li></ol><p><span>&nbsp;</span></p></div> <div class="text-formatted field field--name-field-autor-bio field--type-text-long field--label-above"> <div class="field__label">Bio</div> <div class="field__item"><p><span style="font-size: 13.008px;">Pedro Galván Kondo es director editorial de Software Guru.</span></p></div> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/buzz/tags/integraci-n-continua" hreflang="und">Integración continua</a></li> </ul> </div> Wed, 03 May 2017 22:10:52 +0000 ana2lp 7259 at https://sg.com.mx https://sg.com.mx/revista/54/integraci-n-continua#comments Entrega Continua: ¿Cómo llegamos aquí? https://sg.com.mx/revista/54/entrega-continua <span class="field field--name-title field--type-string field--label-hidden">Entrega Continua: ¿Cómo llegamos aquí?</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/intcontinua1.png" width="811" height="277" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 17:00</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/sgvirtual/speakers/electric-cloud" hreflang="und">Electric Cloud</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr">En prácticamente cualquier industria, el éxito de una organización depende cada vez más de la capacidad de su software. La web, el cómputo móvil y las aplicaciones embebidas definen la forma en que los clientes perciben a una marca, la forma en que sus empleados colaboran, y la competitividad de la empresa. Los usuarios cada vez toleran menos la inconveniencia y buscan gratificación inmediata. El no lograr cumplir dichas expectativas puede ser fatal para la empresa. Para mantenerse competitivas, empresas como Amazon, Facebook y Etsy han adoptado una disciplina conocida como entrega continua.</p><p dir="ltr">La entrega continua es una disciplina que lleva la práctica del desarrollo ágil a su conclusión lógica, creando software que siempre está listo para ser liberado. Para lograrlo incorpora prácticas y herramientas de Agile, integración continua y DevOps para transformar la manera en que se entrega software. Al automatizar tareas rutinarias y tardadas como la compilación pruebas e instalación -y ejecutarlas de forma temprana y frecuente- la entrega continua hace que el proceso de software sea más predecible y repetible, mejorando significativamente la calidad y frecuencia de las entregas.</p><p dir="ltr">Pero … ¿cómo llegamos aquí? Aunque pudiera parecer que la entrega continua es una simple moda o algo que solamente aplica para startups, en realidad no es así. La entrega continua es, como ya lo indicamos, una continuación del desarrollo ágil hasta su conclusión. Explico esto a continuación …</p><h3 dir="ltr">Primero, fuimos ágiles</h3><p dir="ltr">El manifiesto ágil define 12 principios, y el primero de estos dice “... satisfacer al cliente por medio de la entrega temprana y continua de software valioso”.</p><p dir="ltr">Es decir, las metodologías ágiles nos enseñaron a agregar valor a los productos de software una historia a la vez, de manera que aceleremos los ciclos de retroalimentación y continuamente estemos alineando los productos que construimos con las necesidades del mercado. Estas metodologías promueven la integración continua, y esto provocó un flujo de liberaciones más pequeñas y frecuentes, que llegaron hacia los equipos de calidad y operación de TI.</p><h3 dir="ltr">Luego adoptamos DevOps</h3><p dir="ltr">DevOps está surgiendo como un modelo de operación que une a todos los involucrados en la cadena de producción de software para colaborativamente perseguir metas de negocio conjuntas, tales como entregar un nuevo producto de alta calidad que opere de manera estable.</p><p dir="ltr">Al estandarizar los procesos, configuración de versiones y aumentar la colaboración, DevOps habilita a los equipos para trabajar juntos de manera más eficaz y eficiente, mejorando la velocidad y predictibilidad.</p><p dir="ltr">Es difícil definir qué es DevOps. Pero es sencillo ver lo que DevOps hace. Habilita la confianza y coordinación transparente entre equipos alineados con un solo propósito: poner en producción software grandioso. En esencia, DevOps no se trata de desarrollo ni de operaciones, se trata del negocio.</p><h3 dir="ltr">Ahora entregamos, de manera continua</h3><p dir="ltr">La entrega continua lleva Agile a su conclusión lógica con una forma de trabajo que asegura que el software siempre está listo para liberarse. Para lograrlo, se apoya en prácticas de Agile, integración continua y DevOps.</p><p dir="ltr">La entrega continua es un proceso de punta a punta que abarca el ciclo entero de construcción, prueba, despliegue y liberación. Para que la integración continua sea una realidad, debemos automatizar estas actividades. Esto habilita a las organizaciones para innovar, reducir costos y diferenciarse en mercados competitivos, por medio de un proceso eficiente de entrega de software.</p><h3 dir="ltr">¿Cómo determinar si haces entrega continua?</h3><p dir="ltr">Sabes que estás haciendo integración continua cuando:</p><ul><li dir="ltr"><p dir="ltr">Tu software se puede liberar a lo largo de su ciclo de vida.</p></li><li dir="ltr"><p dir="ltr">Tu equipo le da mayor prioridad a mantener el software listo para liberar que a incorporar nuevas capacidades.</p></li><li dir="ltr"><p dir="ltr">El equipo puede obtener retroalimentación rápida y automatizada sobre el estatus del producto.</p></li><li dir="ltr"><p dir="ltr">Es posible mover cualquier versión del software a cualquier ambiente (staging, producción) con un solo comando.</p></li></ul><p dir="ltr">La prueba clave de si has logrado o no la entrega continua es que el usuario de negocio pueda solicitar en cualquier momento que la versión actual de desarrollo pueda ser liberada a producción, y el equipo no sienta temor por esto.</p><p><span id="docs-internal-guid-d42181b4-cced-3403-2bb7-5979381cf514">Este texto es una versión traducida y editada del artículo “Continuous Delivery: What is it? How did we get here?” publicado en el sitio web de Electric Cloud. <a href="http://electric-cloud.com/resources/continuous-delivery-101/what-is-continuous-delivery/">http://electric-cloud.com/resources/continuous-delivery-101/what-is-continuous-delivery</a></span></p></div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/buzz/tags/integraci-n-continua" hreflang="und">Integración continua</a></li> </ul> </div> Wed, 03 May 2017 22:00:49 +0000 ana2lp 7260 at https://sg.com.mx https://sg.com.mx/revista/54/entrega-continua#comments El Caso de Negocio de la Entrega Continua https://sg.com.mx/revista/54/el-caso-negocio-la-entrega-continua <span class="field field--name-title field--type-string field--label-hidden">El Caso de Negocio de la Entrega Continua</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/intcontinua2.png" width="811" height="465" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 16:50</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/sgvirtual/speakers/atlassian" hreflang="und">Atlassian</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr">¿Qué sientes cuando escuchas la frase “liberación a producción”? ¿Tranquilidad? ¿Emoción? Si tu equipo todavía depende de pruebas manuales e instala en producción manualmente, lo más seguro es que sientas cosas cercanas al miedo y preocupación.</p><p dir="ltr">La figura 1 ilustra el ciclo emocional típico de hacer liberación manual de software. Se comienza por un periodo de impasibilidad, que al llegar la fecha original de entrega se convierte en urgencia, después de lograr la entrega se convierte en alivio, luego en celebración y finalmente en complacencia.</p><p dir="ltr"><img src="https://lh3.googleusercontent.com/OOBCtD9fQNOhZ3UOPw4HWtpyJC6A1pfVk12V-o7bm3SQh2Qqc9-plIPOAW2mJg97a8sjTBOFJ9EUtuLFeSyyudWMZDGOgmb_8H1OsUwiDyMB2-JnIwcj7ustyQEcrdJgbTVUWUy2" width="624" height="352" /></p><p dir="ltr">Figura 1. Ciclo emocional de la entrega manual</p><p dir="ltr">Es por ello que el desarrollo de software se está moviendo hacia la continuidad. El énfasis reciente en la integración continua, pruebas automatizadas, monitoreo constante y analítica todas apuntan a una clara tendencia: aumentar la capacidad para reaccionar. Conforme las organizaciones exploran lo que estos cambios implican para ellas, invariablemente descubren la entrega continua.</p><p dir="ltr">Que quede claro: la entrega continua no es algo que solo aplica para empresas “unicornio”. Cualquier equipo puede y debería practicar la entrega continua. Este artículo revisa el caso de negocio alrededor de hacer este cambio. Aborda el trabajo requerido y beneficios que traerá.</p><h3 dir="ltr">Beneficios principales de la entrega continua</h3><p dir="ltr">Tiempos de reacción más cortos. El beneficio más claro de la entrega continua es que permite reaccionar rápidamente a estímulos; ya sea que el mercado tenga un cambio repentino o el negocio cambie la estrategia. ¿A qué empresa no le gustaría tener esa capacidad de ajustar sus productos digitales rápidamente?</p><p dir="ltr">Reducción de riesgo. En la mayoría de las organizaciones, liberar un sistema a producción es todo un logro digno de presumirse. ¿Y por qué no? Se hacen disponibles nuevas capacidades a los usuarios y se corrigen defectos. Todo mundo está feliz, ¿cierto? El problema es que típicamente liberar una nueva versión involucra un gran esfuerzo de parte de los equipos de QA y operaciones. En comparación, bajo un modelo de entrega continua el software se libera constantemente (no necesariamente al usuario final). Así que la ceremonia y riesgo de una nueva versión se reduce. Si confías en tu procedimiento de liberación a diario, encontrarás y corregirás las deficiencias mucho más rápido que si solo lo haces pocas veces al año.</p><p dir="ltr">Descubrir ineficiencias y costos. Cualquier organización de software incurre en costos para liberar software, y en la mayoría de los casos, estos costos no están claros. La entrega continua hace este proceso mucho más transparente, no solo al equipo de desarrollo sino también hacia la dirección. Al construir un pipeline, quedará claro donde se involucran actividades manuales, cuáles son los cuellos de botella, y qué actividades se pueden automatizar fácilmente. Una vez implementado, el pipeline crea un ciclo virtuoso; en lugar del procedimiento largo y obscuro se establecen incentivos claros para una dinámica sana de entrega de software.</p><p dir="ltr">Flexibilidad para liberar. Moverse a un modelo de entrega continua requiere establecer infraestructura, tanto en un contexto operativo como de arquitectura de software. Pero una vez que se cuenta con ella, provee al negocio más flexibilidad sobre cómo libera nuevas capacidades y correcciones al software. Por ejemplo, es posible liberar funcionalidad específica solamente a un subconjunto de usuarios para asegurar que se comportan de la manera esperada antes de liberarlas a todos los usuarios. La funcionalidad se puede construir y probar, pero dejar escondida para habilitarla en el momento deseado. Por ejemplo, si el equipo de marketing hace un anuncio importante que va acompañado de nueva funcionalidad en el sistema de software, no tienes que liberar una nueva versión en ese momento.</p><h3 dir="ltr">No solo es para unicornios</h3><p dir="ltr">Ante estos beneficios, parecería que la entrega continua es algo mágico, solo al alcance de pocos. No lo es. Tan solo es un ajuste en la forma en la que pensamos sobre el diseño, construcción y entrega de software, soportado por una inversión enfocada en las iniciativas requeridas para implementarla. La mayoría de las implementaciones fallidas de entrega continua se deben a esta falta de este compromiso.</p><p dir="ltr">Dado que la entrega continua requiere cambiar o agregar procesos, herramientas y roles, puede sentirse como un cambio demasiado grande. Esto es agudizado por el hecho de que hay que cambiar áreas que previamente habían sido ignoradas o a las que se les había dado baja prioridad. El lado positivo es que los humanos somos muy adaptables, especialmente si estamos motivados por la expectativa de tener un proceso de liberación que no sea un infierno.</p><p dir="ltr">La inversión inicial más grande es lograr un acuerdo de que la transición a la entrega continua es una meta de negocio digna de perseguirse, que solo se puede lograr por medio de la participación y compromiso de la organización de software y la dirección de negocio.</p><p dir="ltr">“Durante los próximos meses no vamos a agregar nueva funcionalidad al sistema y mejor nos dedicaremos a trabajar en automatizar pruebas y construir infraestructura para integrar y liberar versiones”, dijo ningún gerente de producto nunca. La forma de conseguir que los gerentes y usuarios de negocio apoyen este esfuerzo es mostrarles qué tan rápido podrán liberar nuevas capacidades una vez que los esfuerzos de la entrega continua comiencen a rendir frutos. Imagina un mundo en el que un gerente de producto tiene una nueva idea para incorporar en un software y en cuestión de días ésta es liberada a un subconjunto de usuarios, instrumentada con analítica de eventos para evaluar la reacción de los usuarios; esta es la promesa de la entrega continua.</p><p dir="ltr">En realidad, no es necesario detener por completo la construcción de nuevas características hasta que se implante entrega continua. Simplemente es cuestión de que todas las áreas del negocio estén convencidos de los beneficios a largo plazo. Esto no suena tan difícil, pero se requiere bastante disciplina para mantener este compromiso durante un periodo largo de tiempo, de manera que la iniciativa de implementación de entrega continua no quede en segundo plano o se termine abandonando.</p><h3 dir="ltr">Áreas que requieren inversión</h3><p dir="ltr">Adoptar una práctica de entrega continua va mucho más allá de adquirir herramientas de software. Hay diversas áreas en las que se debe invertir para obtener los beneficios de la entrega continua.</p><p dir="ltr">Pruebas automatizadas. Todas las capacidades del sistema deben poder ser probadas de forma automatizada. Esto incluye no sólo pruebas unitarias, sino también de integración y sistema. Las pruebas deben ser coordinadas de forma automatizada, usando una herramienta para ello. Adoptar una práctica de pruebas automatizadas desde cero, puede tomarle a una organización de software de 6 a 18 meses.</p><p dir="ltr">Cambios en arquitectura aplicativa. Es necesario evolucionar la arquitectura de las aplicaciones hacia servicios. En el caso de software que no es SaaS, es necesario establecer una arquitectura de componentes y control de configuración que permita que cada componente se pueda liberar de manera independiente. De esta manera podemos habilitar capacidades como feature flagging y versiones canario. Aunque este cambio puede parecer demasiado complicado o costoso, brinda beneficios más allá de la entrega continua ya que al desacoplar sistemas complejos en componentes o servicios bien definidos y con bajo acoplamiento es más fácil tanto desarrollarlos como reutilizarlos de forma independiente. A la mayoría de los equipos les toma entre 4 y 8 iteraciones cambiar la arquitectura de una aplicación hacia servicios.</p><p dir="ltr">Granja de integración y prueba. Cada que se genera una nueva versión del código del navegador Firefox se disparan automáticamente miles de pruebas que requieren más de 200 horas de CPU. Poder soportar esto requiere una inversión significativa en hardware, ya sea interno o en la nube. Tu granja de integración y prueba requiere suficiente capacidad para soportar entrega continua, lo cual acelerará tu ciclo de retroalimentación de desarrollo y facilitará probar contra distintos sistemas operativos, navegadores, etcétera. Ajustar la capacidad de tu granja es un proceso continuo, por lo que típicamente lo más conveniente es utilizar servicios de cómputo en la nube para este propósito.</p><p dir="ltr">Cambio cultural. La entrega continua requiere un cambio cultural, ya que en esencia se están reemplazando controles humanos por un flujo continuo y automatizado. Inevitablemente, esto provocará que se eliminen silos y habrá personas que se sientan amenazadas ante el prospecto de perder el control. Aunque esto es un proceso continuo, el periodo más intenso durará entre 2 y 6 meses.</p><p dir="ltr">Reclutamiento enfocado. Para avanzar de manera sostenida en la adopción de entrega continua puede ser necesario contratar personas que se dediquen solamente a trabajar en la infraestructura requerida para la entrega continua. La duración de estos contratos típicamente será de 2 a 6 meses.</p><p><span id="docs-internal-guid-bf0ebccb-ccee-cc53-f0ef-03aed42253e6">Este texto es una versión traducida y editada del artículo “The business case for continuous delivery” publicado por la empresa Atlassian en <a href="https://www.atlassian.com/continuous-delivery/business-case-for-continuous-delivery">https://www.atlassian.com/continuous-delivery/business-case-for-continuous-delivery</a> &nbsp;</span></p></div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/buzz/tags/integraci-n-continua" hreflang="und">Integración continua</a></li> </ul> </div> Wed, 03 May 2017 21:50:03 +0000 ana2lp 7261 at https://sg.com.mx https://sg.com.mx/revista/54/el-caso-negocio-la-entrega-continua#comments Evalúa la Capacidad de tu Organización para Entrega Continua https://sg.com.mx/revista/54/eval-la-capacidad-tu-organizaci-n-para-entrega-continua <span class="field field--name-title field--type-string field--label-hidden">Evalúa la Capacidad de tu Organización para Entrega Continua</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/evalua.jpeg" width="940" height="627" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 16:45</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/buzz/autores/pedro-galvan" hreflang="und">Pedro Galván</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr">El concepto de entrega continua está ganando tracción en las organizaciones; sin embargo, su adopción no es trivial. El cambio de entregas poco frecuentes a un flujo continuo puede intimidar a cualquiera. Adicionalmente, las organizaciones grandes y/o con varias décadas de operación típicamente tienen una gran variedad de herramientas independientes para soportar el desarrollo y gestión de software, que no se integran entre sí. Así que antes de comenzar un esfuerzo de adopción de entrega continua, bien vale la pena evaluar nuestro estatus actual.</p><p dir="ltr">En este artículo presento un modelo de evaluación de capacidad para entrega continua desarrollado por la empresa Electric Cloud y documentado a mayor detalle en su whitepaper “The Journey to Enterprise Continuous Delivery” [1]. El objetivo es que las organizaciones puedan evaluar sus capacidades actuales relacionadas con entrega continua y establecer un mapa de ruta para su adopción.</p><p dir="ltr">El modelo considera 3 dimensiones:</p><ol><li dir="ltr"><p dir="ltr">Tecnología</p></li><li dir="ltr"><p dir="ltr">Personas</p></li><li dir="ltr"><p dir="ltr">Procesos</p></li></ol><p dir="ltr">En cada dimensión se identifican cinco niveles y para cada uno se indican rasgos comunes.</p><p dir="ltr">Aunque cada dimensión es independiente, las organizaciones típicamente maduran de forma concurrente a través de ellas. Es decir, difícilmente encontraremos una organización que mejore significativamente sus procesos sin mejorar en sus personas y tecnología.</p><h3 dir="ltr">Personas</h3><p dir="ltr">Una organización requiere la cultura adecuada para soportar e incentivar la entrega continua. Desafortunadamente, demasiadas organizaciones perciben que el trabajo necesario para establecer la colaboración y comunicación necesaria es un obstáculo demasiado grande que bloquea la productividad. Es solo cuando estos equipos maduran que se dan cuenta de la importancia de su cooperación.</p><p><br /><br /></p><div dir="ltr"><table><colgroup><col width="65" /><col width="249" /><col width="311" /></colgroup><tbody><tr><td><p dir="ltr">Nivel</p></td><td><p dir="ltr">Rasgos comunes</p></td><td><p dir="ltr">Resultados</p></td></tr><tr><td><p dir="ltr">0</p></td><td><p dir="ltr">Integrantes con personalidad de “divas”. No hay compromiso.</p><br /><br /></td><td><p dir="ltr">La creatividad es vista como la clave, así que hay resistencia a usar estándares o procedimientos. La calidad no es consistente. Se dan problemas en la integración ya que cada persona defiende su forma de hacer las cosas.</p></td></tr><tr><td><p dir="ltr">1</p></td><td><p dir="ltr">Las personas están aisladas; la comunicación se hace por correo electrónico y típicamente es reactiva; el liderazgo es “a la antigua” que se reúne 1 o 2 veces por semana para ver avance; los integrantes con menor experiencia no tienen mentoría.</p></td><td><p dir="ltr">La comunicación típicamente sólo se da de forma vertical (entre jefes y sus coordinados); hay poca colaboración y la retroalimentación entre pares no se recibe bien; se opera en modo reactivo. Las personas se dedican a solamente hacer lo que tiene asignado en el plan de trabajo y se alarman cuando este cambia.</p></td></tr><tr><td><p dir="ltr">2</p></td><td><p dir="ltr">Algo de colaboración entre equipos; los programadores se enfocan en construir componentes individuales que luego “pasan” a que otros revisen, liberen y mantengan; las iniciativas para de mentoreo se dan de forma silvestre.</p></td><td><p dir="ltr">Hay algo de colaboración pero no es muy efectiva; las personas están algo conscientes de las metas de negocio pero su enfoque está en proteger agendas individuales.</p></td></tr><tr><td><p dir="ltr">3</p></td><td><p dir="ltr">Amplia conciencia de las metas de negocio; hay interés en colaborar para conseguir las metas; se busca y aprecia la retroalimentación; se da algo de atención a la mentoría.</p></td><td><p dir="ltr">Alta adaptabilidad al cambio, las personas entienden los objetivos y respetan los planes pero entienden que los planes pueden cambiar; hay interés en la satisfacción del cliente, reflejada en jidoka (cualquiera puede detener la línea de producción) y kaizen (mejora continua).</p></td></tr><tr><td><p dir="ltr">4</p></td><td><p dir="ltr">La colaboración y cooperación son clave para cualquier actividad; hay amplio interés en la mentoría.</p></td><td><p dir="ltr">Los equipos son dirigidos por la mejora continua y continuamente se ajustan a las necesidades del negocio.</p></td></tr></tbody></table></div><p>&nbsp;</p><h3 dir="ltr">Procesos</h3><p dir="ltr">La entrega continua implica un flujo a través del cual todos los involucrados colaboran para entregar mayor valor al usuario de forma consistente. Esto implica una planeación y estilo de liderazgo distinto al tradicional, pero cualquier organización puede lograr establecerlo con la dedicación y compromiso requeridos.</p><p>&nbsp;</p><div dir="ltr"><table><colgroup><col width="58" /><col width="249" /><col width="318" /></colgroup><tbody><tr><td><p dir="ltr">Nivel</p></td><td><p dir="ltr">Rasgos comunes</p></td><td><p dir="ltr">Resultados</p></td></tr><tr><td><p dir="ltr">0</p></td><td><p dir="ltr">No hay planes ni procesos, solo procedimientos ad-hoc.</p></td><td><p dir="ltr">Construir software es considerado una actividad creativa, no de ingeniería; la mayoría del tiempo se dedica a generar y discutir formas de hacer las cosas.</p></td></tr><tr><td><p dir="ltr">1</p></td><td><p dir="ltr">Existen planes de proyecto pero faltan procesos bien definidos para gestionar peticiones (cambio, diseño, escalamiento); no hay pruebas continuas.</p></td><td><p dir="ltr">La falta de procedimientos para atender peticiones resulta en “bomberazos” frecuentes. Esto impacta incluso al código fuente, que está regado en distintas ramas y repositorios.</p></td></tr><tr><td><p dir="ltr">2</p></td><td><p dir="ltr">Hay procesos definidos (ej. Integración continua, pruebas, despliegue) pero la ejecución no es consistente o integrada de punta a punta; es común que se utilice Scrum.</p></td><td><p dir="ltr">Los procesos son vistos como engorrosos, así que las personas toman atajos.</p></td></tr><tr><td><p dir="ltr">3</p></td><td><p dir="ltr">Existen procesos bien definidos, integrados y automatizados; la última versión del código está en una sola rama del repositorio; es común que se utilice Kanban.</p></td><td><p dir="ltr">Dado que los procesos están cuidadosamente planeados e instrumentados, tienden a hacerse invisibles, permitiendo que las personas se enfoquen en sus responsabilidades principales.</p></td></tr><tr><td><p dir="ltr">4</p></td><td><p dir="ltr">Existen procesos de mejora continua para satisfacer requerimientos de negocio dinámicos apoyándose en herramientas de monitoreo del proceso.</p></td><td><p dir="ltr">Los procesos se mejoran de manera continua utilizando datos en tiempo real como parte de su ciclo de retroalimentación.</p></td></tr></tbody></table></div><p dir="ltr">Tecnología</p><p dir="ltr">Existen una gran oferta de herramientas para instrumentar la entrega continua. Sin embargo, siempre hay que tener en cuenta que las herramientas por sí solas no resuelven el problema. Conforme las organizaciones maduran en las otras 2 dimensiones, hacen que las herramientas se ajusten a sus necesidades, en lugar de estas ajustarse a las capacidades de las herramientas.</p><p><br /><br /></p><div dir="ltr"><table><colgroup><col width="54" /><col width="274" /><col width="297" /></colgroup><tbody><tr><td><p dir="ltr">Nivel</p></td><td><p dir="ltr">Rasgos comunes</p></td><td><p dir="ltr">Resultados</p></td></tr><tr><td><p dir="ltr">0</p></td><td><p dir="ltr">Procedimientos manuales; herramientas open source básicas.</p></td><td><p dir="ltr">Fuera de algo de scripting básico, hay poca automatización.</p></td></tr><tr><td><p dir="ltr">1</p></td><td><p dir="ltr">Distintos equipos utilizan distintas herramientas para actividades específicas (ej. Integrar, probar) no integradas entre sí, típicamente administradas por personas distintas sin un proceso o entendimiento común.</p></td><td><p dir="ltr">Se depende de personas para integración manual; las personas se convierten en cuellos de botella; la salida de una persona del equipo tiene un gran impacto.</p></td></tr><tr><td><p dir="ltr">2</p></td><td><p dir="ltr">Se crea infraestructura común pero no se considera el proceso de punta a punta ni hay una buena integración.</p></td><td><p dir="ltr">Los mejores recursos técnicos dedican su valioso tiempo a construir y mantener herramientas en lugar de resolver problemas del producto o negocio. No hay estandarización a través de áreas o departamentos, así que transferir la propiedad de un producto digital a otra área/departamento es caótico.</p></td></tr><tr><td><p dir="ltr">3</p></td><td><p dir="ltr">Hay automatización a través de todo el ciclo de integración/prueba/despliegue; la configuración y aprovisionamiento de la infraestructura también está automatizada; se utiliza infraestructura centralizada y elástica disponible bajo esquema de autoservicio.</p></td><td><p dir="ltr">La tecnología se encarga de la orquestación; las herramientas están tan integradas que pasan desapercibidas; se genera ejecutables de manera rápida y confiable, cuando hay errores se reportan en tiempo real.</p></td></tr><tr><td><p dir="ltr">4</p></td><td><p dir="ltr">Por medio de dashboards cualquiera puede estar enterado del estatus en tiempo real; el negocio determina qué se libera y cuándo.</p></td><td><p dir="ltr">Cuando se necesitan ajustes, se puede modificar las herramientas y procesos en tiempo real con impacto mínimo a la operación.</p></td></tr></tbody></table></div><p>&nbsp;</p><p dir="ltr">Adoptar una disciplina de entrega continua involucra tener la cultura, procesos y herramientas adecuadas. Espero que este sencillo modelo te ayude a determinar donde está tu organización.</p><p>&nbsp;</p><p dir="ltr">Referencias</p><p dir="ltr"><a href="http://swgu.ru/sz">http://swgu.ru/sz</a></p><p>&nbsp;</p></div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/buzz/tags/integraci-n-continua" hreflang="und">Integración continua</a></li> </ul> </div> Wed, 03 May 2017 21:45:15 +0000 ana2lp 7262 at https://sg.com.mx https://sg.com.mx/revista/54/eval-la-capacidad-tu-organizaci-n-para-entrega-continua#comments La prueba de software y los special purpose languages https://sg.com.mx/revista/54/la-prueba-software-y-los-special-purpose-languages <span class="field field--name-title field--type-string field--label-hidden">La prueba de software y los special purpose languages</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/automata.png" width="641" height="188" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 16:11</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/secci%C3%B3n-revista/prueba-software" hreflang="und">Prueba de Software</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/buzz/autores/luis-vinicio-leon-carrillo" hreflang="und">Luis Vinicio León Carrillo</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>PARTE 6. Máquinas Abstractas y Lenguajes&nbsp;</p><p dir="ltr"><span>Comenzamos abordando los lenguajes formales de una manera más bien no-procedural, en términos algebraicos y de conjuntos; después lo hicimos de una forma más procedural, utilizando gramáticas. En este número los abordaremos con un enfoque </span><span>muy</span><span> procedural, mediante Máquinas de (Conjuntos de) Estados Finitos (o </span><span>Finite States Machines</span><span>), </span><span>MEFs</span><span>. </span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Pero antes de continuar: dado que en el número anterior no aparecieron referencias bibliográficas, las anexo al final de esta columna. Si quisieran profundizar en lo que abordaremos en este número, pueden consultar algún texto sobre Análisis y Diseño de Algoritmos (en particular la sección de </span><span>NP-Completeness</span><span>). Y (como creo haber dicho) si quisieran ahondar en los otros temas que hemos abordado pueden consultar textos sobre Autómatas y Lenguajes Formales y Compiladores. </span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Sin pretensión de tratar de ser exhaustivos aquí, y limitándonos solo a la formalidad suficiente para poder ser claros (aunque sacrificando precisión), vayamos a nuestro tema.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Máquinas de (Conjuntos de) Estados Finitos (MEFs)</span></p><p dir="ltr"><span>Las Máquinas de Turing (ver definición más adelante) son un tipo de MEFs con las que se abordó la cuestión de la “</span><span>computabilidad</span><span>” (otro enfoque fueron las </span><span>funciones recursivas</span><span>), tratando de descubrir los alcances y las limitaciones de las máquinas (computadoras) que estaban construyéndose/por construirse (Turing publicó su trabajo más importante en 1936).</span></p><p dir="ltr">&nbsp;</p><p dir="ltr"><span>Las MEFs que presentaremos aquí tienen en común que: </span></p><ul><li dir="ltr"><p dir="ltr"><span>están constituidas por un conjunto finito de estados en los que la MEF puede encontrarse cuando procesa la cadena de entrada; hay un estado inicial en que la MEF comienza su procesamiento y un estado (o más, dependiendo del tipo de MEF) en el (los) que puede terminarlo;</span></p></li><li dir="ltr"><p dir="ltr"><span>los símbolos que conforman la cadena de entrada son elementos de un conjunto finito (el “Alfabeto”); </span></p></li><li dir="ltr"><p dir="ltr"><span>las operaciones de la MEF se definen mediante una relación (en el sentido matemático) de transición </span><span>ρ </span><span>&nbsp;, que toma el estado en el que se encuentra la MEF en ese momento y el símbolo actual de la cadena de entrada (y, como veremos, eventualmente otras cosas, dependiendo del tipo de MEF), y regresa el estado al que la MEF debe moverse (y eventualmente otras cosas, como veremos); si la relación de transición </span><span>ρ </span><span>&nbsp;es una función (en el sentido matemático), entonces se le denota con </span><span>δ</span><span>&nbsp;y se dice que la MEF es determinística, en caso contrario se denota con </span><span>ρ </span><span>&nbsp;y se dice que es no-determinística.</span></p></li></ul><p dir="ltr"><span>Aquí usaremos dos convenciones: a) considerar que la MEF termina su procesamiento indicando que no acepta la cadena de entrada cuando alcanza una transición en la relación/función de transición que no haya sido explicitada; y b) mostraremos la MEF mediante un grafo, en el cual los nodos serán los estados y en las aristas colocaremos los elementos que terminen de definir las transiciones de la relación/función de tansición.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Veamos ahora las MEFs particulares.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Autómatas Finitos (AFs)</span></p><p dir="ltr"><span>Los AFs (ó </span><span>Finite Automata</span><span>) se definen como quíntuples de la forma &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>AF </span><span>= </span><span>〈</span><span>S,ι, F, A, ρ </span><span>〉</span><span>&nbsp;</span><span>, &nbsp;&nbsp;&nbsp;&nbsp;en los cuales &nbsp;&nbsp;&nbsp;</span></p><p dir="ltr"><span>S</span><span> &nbsp;&nbsp;&nbsp;es el conjunto de eStados, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>ι</span><span>&nbsp;&nbsp;( </span><span>∈</span><span>S </span><span>) es el estado </span><span>i</span><span>nicial,</span></p><p dir="ltr"><span>F</span><span> &nbsp;&nbsp;( </span><span>⊂</span><span>S </span><span>) es el conjunto de estados Finales, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>A</span><span> &nbsp;&nbsp;es el Alfabeto del lenguaje de la cadena de entrada, &nbsp;&nbsp;y &nbsp;</span></p><p dir="ltr"><span>ρ &nbsp;</span><span>(</span><span>ó </span><span>δ</span><span>&nbsp;)</span><span>&nbsp;&nbsp;</span><span>es la Relación (ó Función) de transición &nbsp;&nbsp;&nbsp;</span><span>ρ </span><span>(</span><span>ó </span><span>δ</span><span>&nbsp;</span><span>)</span><span> : </span><span>(</span><span> s</span><span>1</span><span>, a </span><span>&nbsp;</span><span>)</span><span>→</span><span> &nbsp;s</span><span>2</span><span> , </span><span>para &nbsp;&nbsp;&nbsp;</span><span>s</span><span>1</span><span>, s</span><span>2 </span><span>∈ S, &nbsp;&nbsp;a ∈ A.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Como podrá verificarse, el siguiente AF es determinístico y procesa el lenguaje &nbsp;&nbsp;&nbsp;</span><span>a</span><span>m</span><span> b</span><span>n</span><span> e</span><span>i</span><span>d</span><span>k</span><span> &nbsp;</span><span>, &nbsp;</span><span>para </span><span>m, n, i, k </span><span>&nbsp;</span><span>≥</span><span>1</span><span> e independientes entre sí. </span></p><p dir="ltr"><span><img src="https://lh4.googleusercontent.com/vb9loow2v9mP_IVxu1KRjOtGWS6Q5GyuldHc-CAg7VyEUGpEwekr2_m0YfdwG1lCTY_OBLegnfOHcmpaTVoaDH8c_Q7NBlTf0lM-66OXmJwUI0S66LZEmITOSGI54DEPdc5uXqsrpa58L9YSHQ" width="340" height="79" /></span></p><p dir="ltr"><span>El AF inicia el procesamiento en el estado </span><span>ι</span><span>; lee una </span><span>a</span><span> &nbsp;de la cadena de entrada y pasa al </span><span>Estado 1</span><span>, en el cual lee cero más &nbsp;</span><span>a’</span><span>s (la transición es un ciclo); después procesa una o más &nbsp;</span><span>b’</span><span>s (al menos una), luego una o más &nbsp;</span><span>e’</span><span>s (al menos una), y finalmente una o más &nbsp;</span><span>d’</span><span>s (al &nbsp;menos una). Siguiendo nuestra convención, si nos encontráramos en el </span><span>Estado 2</span><span> y en la cadena de entrada no tuviéramos una </span><span>b</span><span> o una </span><span>c</span><span> el autómata no aceptaría la cadena y terminaría su procesamiento.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Se ha demostrado que los AFs procesan solamente los Lenguajes Regulares (pero todos ellos). En particular, no pueden procesar los Lenguajes Libres de Contexto porque no tienen memoria que les permita empatar caracteres por pares, como lo requieren este tipo de lenguajes.</span></p><p dir="ltr"><span>Se ha demostrado también que en el caso de los AFs el no-determinismo no implica mayor poder de procesamiento.</span></p><p dir="ltr"><span>Igualmente, se ha demostrado que para cada Expresión Regular existe un AF que procesa el mismo lenguaje y viceversa (de hecho, lo usual es que las herramientas que procesan textos mediante Expresiones Regulares primero las transformen en AFs &nbsp;–como las usadas para definir analizadores léxicos </span><span>lex</span><span> y </span><span>flex</span><span>).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Autómatas de Pila (APs)</span></p><p dir="ltr"><span>Los APs (ó </span><span>Push Down Automata</span><span>) se definen como séxtuples de la forma &nbsp;&nbsp;&nbsp;</span><span>AP </span><span>= </span><span>〈</span><span>S,ι, F, A, Σ, ρ </span><span>〉</span><span>, &nbsp;&nbsp;&nbsp;en los cuales &nbsp;&nbsp;</span></p><p dir="ltr"><span>S</span><span> &nbsp;&nbsp;&nbsp;es el conjunto de eStados,</span><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>ι</span><span> &nbsp;</span><span>&nbsp;&nbsp;( </span><span>∈</span><span>S </span><span>) es el estado </span><span>i</span><span>nicial,</span></p><p dir="ltr"><span>F</span><span> &nbsp;( </span><span>⊂</span><span>S </span><span>) es el conjunto de estados Finales, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>A</span><span> &nbsp;&nbsp;es el Alfabeto del lenguaje de la cadena de entrada, &nbsp;&nbsp;</span></p><p dir="ltr"><span>Σ &nbsp;&nbsp;</span><span>es el alfabeto de la pila (o </span><span>Stack</span><span>), que es el tipo de memoria que tienen los APs &nbsp;( </span><span>#</span><span>∈</span><span>Σ , A </span><span>⊂</span><span>Σ &nbsp;</span><span>) , &nbsp;&nbsp;y </span><span>&nbsp;</span></p><p dir="ltr"><span>ρ &nbsp;</span><span>(</span><span>ó </span><span>δ</span><span>)</span><span>es la Relación (ó Función) de transición &nbsp;</span><span>ρ </span><span>(ó</span><span> δ</span><span>) </span><span>: </span><span>( </span><span>s</span><span>1</span><span>, a, σ</span><span>1 </span><span>) → (</span><span> σ</span><span>2 </span><span>, s</span><span>2</span><span>)</span><span>, </span><span>para </span><span>s</span><span>1</span><span>, </span><span>s</span><span>2</span><span> ∈ S, a ∈ A, σ</span><span>1</span><span>, σ</span><span>2</span><span>∈</span><span>Σ.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Como podrá verificarse, el siguiente AP es determinístico y procesa el lenguaje &nbsp;&nbsp;&nbsp;&nbsp;</span><span>a</span><span>i</span><span> b</span><span>n</span><span> e</span><span>n</span><span>d</span><span> i</span><span> &nbsp;</span><span>, &nbsp;</span><span>para </span><span>n, i</span><span>≥</span><span> &nbsp;</span><span>1</span><span>.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span><img src="https://lh3.googleusercontent.com/qfPcOPhPrYw9fMHyZ9X0lqnAuMv41u5fgbFGLRoi5qrkMHUdoJZd8-XsJwwIIWPgy5FpCwtQjJYJwAOdRFjcqQi1X2xMgOOGXGNISyTt3znEMcGaqAA-MG7FlAXsioJlXS0vNWGk-jwmk7dyzQ" width="561" height="105" /></span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Iniciamos en </span><span>ι</span><span> y pasamos al </span><span>Estado 1</span><span> sin leer símbolos la cadena de entrada (eso significa la primera </span><span>λ</span><span> de la primera transición), no sacamos elemento alguno de la pila (eso significa la segunda </span><span>λ</span><span>) y metemos “</span><span>#</span><span>” a la pila.</span></p><p dir="ltr"><span>Del </span><span>Estado 1</span><span> pasamos al </span><span>Estado 2</span><span> leyendo una </span><span>a </span><span>de la cadena de entrada sin sacar elemento alguno de la pila y metiendo una </span><span>a </span><span>a la pila. En el </span><span>Estado 2</span><span> repetimos cero o más veces lo siguiente (la transición es un ciclo): leer una </span><span>a </span><span>de la cadena de entrada, no sacar elemento alguno de la pila y meter una </span><span>a</span><span> a la pila. </span></p><p dir="ltr"><span>En las siguientes transiciones (hasta la del </span><span>Estado 3</span><span>) ejecutamos un proceso semejante al anterior pero ahora con las </span><span>b</span><span>´s: por cada </span><span>b</span><span> que leemos de la cadena metemos una </span><span>b</span><span> a la pila.</span></p><p dir="ltr"><span>Las 2 transiciones subsiguientes (hasta la del </span><span>Estado 4</span><span>) se ocupan de sacar una </span><span>b</span><span> de la pila por cada </span><span>e</span><span> que se lee de la cadena de entrada. </span></p><p dir="ltr"><span>Las 2 transiciones subsiguientes (hasta la del </span><span>Estado 5</span><span>) sacan una </span><span>a</span><span> de la pila por cada </span><span>d</span><span> que lean de la cadena de entrada.</span></p><p dir="ltr"><span>La última transición no lee elemento alguno de la cadena de entrada y saca el </span><span>#</span><span> de la pila sin meter elemento alguno en ella.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Se ha demostrado que los APs procesan solamente los Lenguajes Libres de Contexto (pero todos ellos). En particular, no pueden procesar los Lenguajes Sensibles al Contexto porque la pila sólo les permita empatar caracteres por pares anidados y no en tercias o por pares no anidados, como lo requieren algunos lenguajes de este tipo.</span></p><p dir="ltr"><span>También se ha demostrado que para los AP el no-determinismo sí implica mayor poder de procesamiento, por lo que en los Lenguajes Libres de Contexto (LLC) tenemos los LLC no-determinísticos englobando a los LLC determinísticos. </span></p><p dir="ltr"><span>Un caso concreto es el lenguaje &nbsp;&nbsp;&nbsp;</span><span>a</span><span>i</span><span> b</span><span>i</span><span>∪ </span><span>a</span><span>i</span><span> b</span><span>2i</span><span> &nbsp;</span><span>, &nbsp;</span><span>para </span><span>m, i </span><span>&nbsp;</span><span>≥</span><span> &nbsp;</span><span>0 &nbsp;&nbsp;</span><span>que es un LLC para el que no existe un AP determinístico que lo procese.</span></p><p dir="ltr"><span>Igualmente, se ha demostrado que para cada Gramática Libre de Contexto existe un AP que procesa el mismo lenguaje, y viceversa (de hecho, lo usual es que las herramientas que procesan ese tipo de gramáticas (“determinísticas”) primero las transformen en APs (determinísticos) &nbsp;–como las usadas para definir analizadores sintácticos </span><span>yacc</span><span> y </span><span>bison</span><span>).</span></p><p><span><span>&nbsp;</span></span></p><ol><li dir="ltr"><p dir="ltr"><span>Máquinas de Turing (MTs)</span></p></li></ol><p dir="ltr"><span>Las MT (ó </span><span>Turing Machines</span><span>) se definen como séxtuples de la forma &nbsp;&nbsp;&nbsp;</span><span>MT </span><span>= </span><span>〈</span><span>S,ι, h, A, Γ, ρ </span><span>〉</span><span>, &nbsp;&nbsp;&nbsp;en los cuales &nbsp;&nbsp;</span></p><p dir="ltr"><span>S</span><span> &nbsp;&nbsp;&nbsp;es el conjunto de eStados del AF, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>ι</span><span> &nbsp;</span><span>&nbsp;&nbsp;( </span><span>∈</span><span>S </span><span>) es el estado </span><span>i</span><span>nicial,</span></p><p dir="ltr"><span>h</span><span> &nbsp;&nbsp;(</span><span>∈</span><span>S </span><span>) es </span><span>el</span><span> estado Final, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><span>A</span><span> &nbsp;&nbsp;es el Alfabeto del lenguaje de la cadena de entrada, &nbsp;&nbsp;</span></p><p dir="ltr"><span>Π &nbsp;</span><span>es el alfabeto de la cinta de Procesamiento, el tipo de memoria que tienen las MTs &nbsp;&nbsp;&nbsp;( </span><span>#</span><span>, </span><span>$</span><span>∈</span><span>Σ ; A </span><span>⊂</span><span>Π &nbsp;&nbsp;</span><span>), &nbsp;&nbsp;&nbsp;y </span><span>&nbsp;&nbsp;</span></p><p dir="ltr"><span>ρ &nbsp;</span><span>(</span><span>ó </span><span>δ</span><span>)</span><span>es la Relación (ó Función) de transición &nbsp;</span><span>ρ </span><span>(</span><span>ó </span><span>δ</span><span>) </span><span>: </span><span>( </span><span>s</span><span>1</span><span>, π</span><span>1 </span><span>) → ( </span><span>π</span><span>2 </span><span>,μ, s</span><span>2</span><span>)</span><span>, </span><span>para &nbsp;&nbsp;&nbsp;</span><span>s</span><span>1</span><span>, </span><span>s</span><span>2</span><span> ∈ S, &nbsp;&nbsp;&nbsp;π</span><span>1 </span><span>, π</span><span>2 </span><span>∈</span><span>Π</span><span>,</span></p><p dir="ltr"><span>μ = L </span><span>(mover la cabeza a la celda de la derecha) ó </span><span>μ = R</span><span> (moverla a la de la izquierda).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>En el caso de las MT tomaremos la convención de que la cadena de entrada se coloca en la cinta de la siguiente manera: primero se coloca un “</span><span>#</span><span>”, luego la cadena de entrada, y un “</span><span>$</span><span>” después de ella.</span></p><p dir="ltr"><span>Se ha demostrado que las MTs procesan solamente (pero todos) los Lenguajes Estructurados por Frases (o “Recursivamente Enumerables”). En particular, no pueden procesar los Lenguajes Generales (así como no son susceptibles de ser definidos con reglas, tampoco lo son de ser procesados por máquinas).</span></p><p dir="ltr"><span>En el caso de las MTs el no-determinismo no implica mayor poder de procesamiento.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Los trabajos con las MTs han dado lugar a lo que se conoce como la Tesis de Turing:</span></p><p dir="ltr"><span> &nbsp;&nbsp;&nbsp;Las MTs modelan exactamente lo que pueden realizar las computadoras.</span></p><p dir="ltr"><span>Esta Tesis es muy relevante y útil: aún cuando (se asume que) las MTs tienen el mismo poder de procesamiento que las computadoras, estas máquinas abstractas son muy simples en su funcionamiento, lo cual facilita realizar demostraciones sobre las capacidades y limitaciones de las computadoras.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>En las MT tenemos varias clases muy importantes, que procedemos a revisar.</span></p><p><span><span>&nbsp;</span></span></p><ol start="2"><li dir="ltr"><p dir="ltr"><span>Autómatas Delimitados Linealmente (ADLs)</span></p></li></ol><p dir="ltr"><span>Los ADLs (ó </span><span>Linear Bounded Automata</span><span>) son MTs que para procesar una cadena solo requieren una cantidad de celdas en la cinta de procesamiento prácticamente igual a la de la cadena de entrada. Los ADLs pueden procesar los Lenguajes Sensibles al Contexto.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Como podrán verificar, el siguiente ADL es determinístico que procesa el lenguaje &nbsp;&nbsp;&nbsp;</span><span>a</span><span>i</span><span> b</span><span>n</span><span> e</span><span>i</span><span>d</span><span> n</span><span> &nbsp;</span><span>, &nbsp;</span><span>para </span><span>n, i</span><span>≥</span><span>1</span><span> .</span></p><p dir="ltr"><span><img src="https://lh6.googleusercontent.com/zZnmR3RuCCaMzJkl25Qogc-RKUR1c0nngzHbALvWxWL4GWMI80_2H0MrBzaQ4kGCvL_hB8XthMSiDfl18vvuqndDl4Xpr6SHLLVBEySGNEXpcQMK5U_XWsve_yHI71x92JEDnoNo2h_ts5ZwPg" width="433" height="347" /></span></p><p dir="ltr"><span>La MT inicia en </span><span>ι</span><span> y pasa al </span><span>Estado 1</span><span> leyendo el “</span><span>#</span><span>” que antecede a la cadena de entrada, escribiendo el mismo “</span><span>#</span><span>” y moviéndose a la celda de la derecha.</span></p><p dir="ltr"><span>Del </span><span>Estado 1</span><span> pasa al </span><span>Estado 2</span><span> leyendo una </span><span>a </span><span>de la cadena de entrada, escribiendo una </span><span>A </span><span>y moviéndose a la derecha. </span></p><p dir="ltr"><span>En el </span><span>Estado 2</span><span> podemos repetir cero o más veces algunas de las siguientes operaciones (en realidad deberíamos dibujar 3 ciclos en el autómata, uno para cada transición, pero por motivos de espacio dibujamos solo uno y apilamos las transiciones): </span></p><ol><li dir="ltr"><p dir="ltr"><span>leer una </span><span>a </span><span>de la cadena de entrada, escribir una </span><span>a </span><span>y moverse a la derecha (o sea: nos saltamos las </span><span>a</span><span>’s);</span></p></li><li dir="ltr"><p dir="ltr"><span>leer una </span><span>b </span><span>de la cadena de entrada, escribir una </span><span>b </span><span>y moverse a la derecha (nos saltamos las </span><span>b</span><span>‘s);</span></p></li><li dir="ltr"><p dir="ltr"><span>leer una </span><span>E </span><span>de la cadena de entrada, escribir una </span><span>E </span><span>y moverse a la derecha (nos saltamos las </span><span>E</span><span>’s).</span></p></li></ol><p dir="ltr"><span>Después pasamos al </span><span>Estado 3 </span><span>leyendo la primera </span><span>e</span><span>, transformándola en </span><span>E</span><span> y moviéndonos a la izquierda; luego nos movemos hacia la izquierda saltándonos todas las </span><span>a</span><span>’s, </span><span>b</span><span>’s, y </span><span>E</span><span>’s hasta encontrar una </span><span>A</span><span>, nos movemos a la derecha y llegamos nuevamente al </span><span>Estado 1</span><span>.</span></p><p dir="ltr"><span>Enseguida podemos repetir cero o más veces las operaciones de las transiciones de los </span><span>Estados 1, 2 </span><span>y </span><span>3</span><span>, las cuales se pueden resumir como “cambiar una </span><span>e</span><span> por </span><span>E</span><span> por cada </span><span>a</span><span> que se haya cambiado antes por </span><span>A</span><span>” (con ello verificamos si hay igual cantidad de </span><span>a</span><span>‘s que de </span><span>e</span><span>‘s). Dejamos de hacer eso cuando encontramos una </span><span>b</span><span>; entonces escribimos </span><span>b</span><span>, nos movemos a la izquierda y vamos al </span><span>Estado 4</span><span>. Leemos una</span><span> A</span><span>, escribimos una </span><span>A</span><span> y vamos al </span><span>Estado 5</span><span>.</span></p><p dir="ltr"><span>En las transiciones de los </span><span>Estados 5, 6 </span><span>y</span><span> 7</span><span> realizamos con y las </span><span>b</span><span>‘s y </span><span>d</span><span>‘s algo semejante a lo que hicimos con las </span><span>a</span><span>‘s y </span><span>e</span><span>‘s en los los </span><span>Estados 1, 2 </span><span>y</span><span> 3</span><span>: “cambiar una </span><span>d</span><span> por </span><span>D</span><span> por cada </span><span>b</span><span> que se haya cambiado antes por </span><span>B</span><span>” para verificar si hay igual cantidad de </span><span>b</span><span>‘s que de </span><span>d</span><span>‘s. Dejamos de hacer eso cuando encontramos una </span><span>E</span><span>; entonces escribimos una </span><span>E</span><span>, nos movemos a la izquierda y vamos al </span><span>Estado 8</span><span>, donde nos saltamos todas las </span><span>D</span><span>‘s y </span><span>E</span><span>‘s moviéndonos a la derecha hasta encontrar el </span><span># </span><span>&nbsp;que debe venir después del final de la cadena de entrada.</span></p><p><span><span>&nbsp;</span></span></p><ol start="3"><li dir="ltr"><p dir="ltr"><span>Máquinas de Turing que terminan (MTts</span><span>term</span><span>) – Algoritmos</span></p></li></ol><p dir="ltr"><span>Las MTs</span><span>term</span><span> son MTs que siempre terminan cuando procesan cualquier cadena &nbsp;–aunque eventualmente después de </span><span>mucho</span><span> tiempo. &nbsp;Las MTs</span><span>term</span><span> pueden procesar los Lenguajes Decidibles (o “Recursivos”).</span></p><p dir="ltr"><span>La penúltima frase puede parecer obvia, especialmente con tanta ciencia ficción y con tan altas expectativas puestas sobre la </span><span>nouvelle Artificial Intelligence</span><span>, pero ocurre que hay problemas que una MT simplemente no puede resolver (y, de acuerdo a la Tesis de Turing, tampoco las computadoras). Un ejemplo es la demostración de teoremas en el Cálculo de Predicados de Primer Orden, que describiremos aquí rápida e informalmente: desde hace décadas tenemos sistemas de inferencia (finalmente, MTs) que pueden generan todos los teoremas en ese Cálculo; inicialmente se pudo pensar que, para saber si una fórmula era un teorema, simplemente bastaría con comparar esa fórmula con cada uno de los teoremas que fuera generando el sistema; &nbsp;y efectivamente, si la fórmula es un teorema, en algún momento (quizás en un día, quizás en 1,000,000 de años) el sistema anunciará que encontró un teorema que es equivalente a nuestra fórmula; sin embargo, si la fórmula no es un teorema, el sistema (la MT) </span><span>nunca</span><span> terminará porque no generará un teorema equivalente a nuestra fórmula.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>A partir de algo como lo anterior, es que se suele definir </span><span>Algoritmo</span><span> como una MT que siempre termina (MT</span><span>term</span><span>).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Problemas, Algoritmos y Heurísticas </span></p><p dir="ltr"><span>Ahora bien: hay problemas para los cuales no se han encontrado algoritmos </span><span>eficientes</span><span> que los resuelvan (y se presume que no existen). En esos casos se suele optar por abstenerse de buscar la solución</span><span> óptima</span><span> mediante la revisión de todas las alternativas en el grafo de búsqueda, y en su lugar recorrer solo parte de él para encontrar </span><span>buena </span><span>solución. A estos métodos solemos llamarlos </span><span>Heurísticas</span><span>.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Para ejemplificar lo anterior tomemos el </span><span>Problema del Vendedor Viajero</span><span> (PVV): Un Vendedor debe visitar </span><span>n-1</span><span> ciudades partiendo de una inicial, considerando que viajar de una ciudad a otra tiene un costo asociado. </span></p><p dir="ltr"><span>El PVV se puede modelar mediante un grafo dirigido con pesos en las aristas. </span></p><p dir="ltr"><span>Sabemos que, dado un grafo dirigido con </span><span>n</span><span> nodos, la cantidad máxima de </span><span>aristas</span><span> (dirigidas) es </span><span>n (n+1),</span><span> pero: cuántas </span><span>rutas</span><span> hay en ese grafo? Eso nos permitiría saber cuántas rutas tenemos que comparar para escoger </span><span>la</span><span> de costo mínimo.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Para simplificar nuestro análisis, pensemos que el costo para ir a de una ciudad a otra es el mismo de ida que de vuelta. Tenemos entonces un grafo no dirigido con </span><span>n</span><span> nodos, por lo cual la cantidad máxima de aristas es &nbsp;&nbsp;</span><span>n (n+1) / 2 </span><span>. &nbsp;Ahora bien, cuando el grafo…</span></p><ul><li dir="ltr"><p dir="ltr"><span>tiene </span><span>3 nodos</span><span>, partiendo del nodo inicial solo tenemos </span><span>2 rutas</span><span> para visitar los otros 2 nodos.</span></p></li><li dir="ltr"><p dir="ltr"><span>tiene </span><span>4 nodos</span><span>, partiendo del inicial podemos iniciar 3 rutas yendo a cada uno d los otros 3 nodos, y entonces nos quedan 2 nodos por visitar en cada caso que como vimos en el punto anterior, genera 2 rutas cada uno; por tanto tendríamos </span><span>6 rutas</span><span>.</span></p></li><li dir="ltr"><p dir="ltr"><span>tiene </span><span>5 nodos</span><span>, partiendo del inicial podemos iniciar 4 rutas yendo a cada uno d los otros 4 nodos, y entonces nos quedan 3 nodos por visitar en cada caso que como vimos en el punto anterior, genera 2 rutas cada uno; tendríamos entonces </span><span>24 rutas</span><span>.</span></p></li></ul><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Supongamos que en general, si el grafo tiene </span><span>n </span><span>nodos, habrá </span><span>n! </span><span>( = </span><span>1*2*3*…*n </span><span>) rutas. </span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>En la siguiente tabla se muestran los valores para las curvas &nbsp;&nbsp;&nbsp;</span><span>log</span><span>2</span><span> n</span><span> &nbsp;(la búsqueda en un árbol binario con </span><span>n</span><span> datos requiere una cantidad de operaciones múltiplo de </span><span>log</span><span>2</span><span> n</span><span> &nbsp;), &nbsp;&nbsp;&nbsp;</span><span>n</span><span>&nbsp;&nbsp;, &nbsp;&nbsp;&nbsp;</span><span>n</span><span> 2</span><span> &nbsp;(ordenar &nbsp;</span><span>n</span><span> datos con el método de “Burbuja” requiere una cantidad de operaciones múltiplo de </span><span>n</span><span> 2</span><span> &nbsp;), y &nbsp;&nbsp;</span><span>2</span><span> n</span><span> &nbsp;</span><span>&nbsp;</span><span>. &nbsp;( &nbsp;</span><span>n!</span><span> &nbsp;</span><span>•</span><span>2</span><span> n</span><span> a partir de &nbsp;</span><span>n=4 </span><span>).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span><img src="https://lh5.googleusercontent.com/uyoyUIBa7c-lEIhtwb8PA86TWEoq3845decNzGPQ4Yrgy4zX4P06zCMdENCpMOYrqyb_z0M8qIvKPeuLje1WgF7y9va9paAH1owsvd0hW7CXvTCMrlvX_kYmjh8nMq2kXaHT8LWDgxG4gk-5eQ" width="665" height="72" /></span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Los numeros en </span><span>azul </span><span>son aproximaciones mías (suficientemente acertadas para nuestro propósito); el resto los produjo la computadora. (El primero de ellos se leería “uno por diez elevado a la tres por diez elevado a la 2” = </span><span>1*10</span><span> 300</span><span> &nbsp;).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Hoy hablamos de </span><span>Internet of Things</span><span>, y de </span><span>BIG Data</span><span>. Supongamos que nos topamos con un problema equivalente al PVV con una cantidad de ciudades igual a </span><span>10</span><span>9</span><span> . (Si cada ciudad se llevara un Byte, entonces estamos hablando de un GigaByte, nada extraordinario en </span><span>BIG Data</span><span>).</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Para hacer nuestro análisis sin problemas de desbordamiento, tomemos valores no de &nbsp;</span><span>n! &nbsp;</span><span>sino de &nbsp;</span><span>n</span><span>2</span><span> &nbsp;(para </span><span>n=100, &nbsp;n! </span><span>vale casi</span><span> 10</span><span>158 </span><span>). Haciéndolo así, con un GigaByte de ciudades, el algoritmo que revisara todas las rutas para encontrar la óptima tendría que realizar </span><span>10</span><span>300,000,000</span><span> operaciones (</span><span>ver la tabla</span><span>). &nbsp;Eso implica mucho, o poco tiempo? </span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Supongamos que podemos paralelizar mil millones de supercomputadoras que pueden realizar cada una </span><span>10</span><span>21</span><span> operaciones por segundo (un millón de PetaFlops). En un año todas ellas podrían realizar </span><span>10</span><span>9</span><span>*365*24*60*60*10</span><span>21</span><span>= 10</span><span>9</span><span>*3.1536</span><span> *</span><span>10</span><span>7</span><span>*</span><span>10</span><span>21</span><span> = 3.1536 *</span><span>10</span><span>37</span><span> operaciones, &nbsp;así es que (asumiendo que una operación bastara para procesar una ruta completa) para obtener la ruta óptima para un grafo con </span><span>10</span><span>9</span><span> nodos, el algoritmo del PVV se tardaría &nbsp;solamente </span><span>10</span><span>300,000,000-37</span><span> &nbsp;años. </span></p><p dir="ltr"><span>Esperar a obtener el resultado es, al menos, impráctico. Por supuesto, la estrategia a seguir sería utilizar una Heurística.</span></p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Con los elementos del análisis anterior estamos en posición de responder la pregunta que nos había quedado pendiente en un número anterior, acerca de la eficiencia con la que podemos procesar los distintos tipos de lenguajes que hemos venido revisando. La ofrecemos en la siguiente tabla, considerando una cadena de entrada de longitud </span><span>n </span><span>(como dijimos al principio, debido a que nos limitamos solo a la formalidad suficiente, es necesario sacrificar precisión):</span></p><p><span><span><img src="/sites/default/files/images/stories/imagenes.png" width="338" height="242" /></span></span></p><p>Tabla 2. Eficiencia para probar distintos lenguajes.</p><p><span><span>&nbsp;</span></span></p><p dir="ltr"><span>Referencias </span></p><p dir="ltr"><span>[1]</span><span>Luis Vinicio León Carrillo: </span><span>Traducción de Frases del Español al Francés en un Dominio restringido</span><span>; Tesis de Licenciatura, ITESO, 1990</span></p><p dir="ltr"><span>[2]</span><span>Pierre Janton: </span><span>Einfürhrung in die Esperantologie</span><span>; Georg Olms, 1993.</span></p><p dir="ltr"><span>[3]</span><span>Roland Hausser: </span><span>Foundations of Computational Linguistics</span><span>; Springer, 1999.</span></p></div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> Wed, 03 May 2017 21:11:28 +0000 ana2lp 7276 at https://sg.com.mx https://sg.com.mx/revista/54/la-prueba-software-y-los-special-purpose-languages#comments Cómo Hacer Investigación de Usuarios en Equipos Ágiles https://sg.com.mx/revista/54/c-mo-hacer-investigaci-n-usuarios-equipos-giles <span class="field field--name-title field--type-string field--label-hidden">Cómo Hacer Investigación de Usuarios en Equipos Ágiles</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/uxanalytics.png" width="440" height="330" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 01:24</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/buzz/seccion-revista/user-experience" hreflang="und">User eXperience</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/buzz/autores/misael-leon" hreflang="und">Misael León</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr">La clave para prosperar en el entorno competitivo de los productos digitales, sin duda, es centrarse en la Experiencia del Usuario (UX). La gente simplemente no va a pagar dinero por un producto que no se adapte a sus necesidades.</p> <p dir="ltr">Por su lado, Agile se ha convertido en la estrategia más común en la industria del software. Según una encuesta del 2015 [1] sólo el 2% de las empresas todavía operan bajo el modelo tradicional de desarrollo en cascada. Simplemente, Agile funciona.</p> <p dir="ltr">Los equipos ágiles pueden adaptarse rápidamente al cambio en las preferencias del usuario. Y la Investigación de Usuarios es la herramienta para detectar ese pulso de cambio. Sin embargo, existen todavía varios conceptos erróneos que se interponen en el camino de investigar usuarios en equipos ágiles. En este artículo encontrarás algunas recomendaciones prácticas para hacer que funcionen juntos.</p> <h3 dir="ltr">No hay UX sin el usuario</h3> <p dir="ltr">En el centro de UX se encuentra la investigación de usuarios, la cual consiste en un conjunto de técnicas para comprender los comportamientos, necesidades y motivaciones de los usuarios a través de la observación y la medición.</p> <p dir="ltr">Existen actividades específicas de investigación de usuarios que pueden ayudarte en cada etapa del proceso de desarrollo del producto: entrevistas [2]; pruebas de usabilidad [3], investigación contextual; ejercicios generativos; encuestas; analytics; pruebas A/B. El desafío es identificar cuál es el adecuado para el problema que deseas resolver y asignar tiempo suficiente para ejecutarlo y obtener valor de él. La clave reside en probar poco y a menudo.</p> <h3 dir="ltr">Mitos de investigación de usuarios en equipos ágiles</h3> <p dir="ltr">Cuando trates de introducir la investigación de usuarios en un equipo ágil, escucharás objeciones como: "toma demasiado tiempo", "es el trabajo de otra persona", "oh no, eso es muy caro", "es muy difícil", "ya no tenemos tiempo en este sprint". Estos mitos son el resultado de una mentalidad enfocada a shipping features. El trabajo se recompensa en función de cuántas características se liberan; y no de cuánto estamos cambiando el comportamiento del usuario hacia nuestros objetivos de negocio.</p> <p dir="ltr">Por lo general, bajo Agile no existe un paso dedicado a la investigación que esté bien diferenciado. La investigación y los requerimientos se combinan a menudo en un solo paso. El desarrollo se guía por un prototipo o wireframe, los cuales pueden o no reflejar lo que los usuarios realmente quieren. Normalmente, este trabajo de investigación no tiene un responsable. No hay tiempo dedicado para explorar las motivaciones de los usuarios, sus expectativas y cómo utilizan el producto. En el mejor de los casos, los propietarios de productos presentan especificaciones de diseño justo antes que comience el desarrollo.</p> <h3 dir="ltr">Rompiendo los mitos</h3> <p dir="ltr">Para incorporar las actividades de la investigación de usuarios en tu proceso ágil, todo el equipo debe cambiar a una visión del producto centrada en el usuario. El cambio comienza cuando el aprendizaje de los usuarios está en el centro de tu trabajo. Sí, seguirás liberando features, pero éstas se alinearán a cambiar el comportamiento del usuario y mejorar el producto.</p> <p dir="ltr">1. Prueba pequeñas hipótesis</p> <p dir="ltr">Evalúa pequeñas partes de tu producto mediante la formulación de una hipótesis sobre cómo resolver un problema con un nuevo diseño o función. Por ejemplo, podrías decir: "Creemos que si implementamos una funcionalidad de alerta de conflictos podremos reducir los tickets de soporte en un 30%.”</p> <p dir="ltr">De repente, el trabajo cambia. Ahora el objetivo es reducir los tickets de soporte, no liberar una funcionalidad determinada. Esto significa que el equipo explorará opciones como la creación de un rol de moderador. No hay necesidad de investigar el producto completo, solamente esa pequeña idea.</p> <p dir="ltr">2. Asignar el trabajo de investigación</p> <p dir="ltr">Para que las actividades de investigación de usuarios sean tomadas en serio, tienen que ser visibles y ser priorizadas, así que deben ser incluidas en el backlog; de esta manera ya no podrán ser ignoradas. Este es otro paso para pasar de una cultura de shipping a una cultura de continuo aprendizaje.</p> <p dir="ltr">3. Maximiza el uso del tiempo</p> <p dir="ltr">El rápido ritmo de los sprints podría no permitir profundizar en la investigación de usuarios. Debes ser creativo en la aplicación de los métodos que utilizas. Por ejemplo, puedes realizar una prueba de usabilidad de una porción pequeña del producto y al mismo tiempo realizar una entrevista regular con preguntas más subjetivas. De esta manera se maximiza el tiempo de la sesión.</p> <p dir="ltr">También puedes reclutar usuarios ya familiarizados con el producto para que su curva de aprendizaje durante la prueba no sea muy prolongada.</p> <p dir="ltr">Otro tip útil es programar sesiones de investigación regulares con los usuarios. Esto hace que convierta en una rutina semanal y todos en el equipo saben que determinado día es "el día de investigar usuarios".</p> <p dir="ltr">Al final lo que importa es tener claro lo que se quiere validar y encontrar la técnica correcta para encontrar las respuestas a tus incógnitas.</p> <p dir="ltr">4. Involucra a todo el equipo</p> <p dir="ltr">Para construir un entendimiento compartido de los problemas del usuario no hay sustituto para invitar a todo el mundo del equipo a las sesiones. Ser testigo de cómo a los usuarios se les dificulta completar una tarea, motivará inmediatamente a los desarrolladores a querer arreglarlo de inmediato.</p> <p dir="ltr">Idealmente, podrías instruir al resto del equipo a ejecutar las sesiones por sí mismos. Inicialmente, podrían tomar notas, hablar con los clientes y hacer preguntas sencillas. Con el tiempo se verán tan acostumbrados al proceso que serán capaces de hacerlo por su cuenta.</p> <h3 dir="ltr">Consejos para equipos locales</h3> <p dir="ltr">Atlassian, la compañía que creó JIRA y Confluence, hizo un gran trabajo construyendo su propio laboratorio de investigación de usuarios, ellos lo llaman el Atlab [4]. No es de ninguna manera un laboratorio costoso o de alta tecnología. Es un espacio de trabajo exclusivamente dedicado a hacer este tipo de investigaciones; siempre disponible para todos. Más que eso, lograron crear la mentalidad correcta del equipo alrededor de solucionar problemas reales de gente real.</p> <h3 dir="ltr">Consejos para equipos distribuidos y usuarios remotos</h3> <p dir="ltr">La investigación de usuarios también se puede realizar de forma remota. A continuación comparto algunos consejos:</p> <ul> <li dir="ltr"> <p dir="ltr">Las pruebas de usabilidad se pueden realizar a través de videollamadas. El ideal es usar alguna herramienta que muestre lo que sucede en la computadora del usuario (desktop sharing) y también muestre su webcam, de esta manera puedes observar tanto las acciones que realiza en pantalla como sus expresiones faciales conforme trata de usar tu producto.</p> </li> <li dir="ltr"> <p dir="ltr">Para crear diagramas de afinidad que ayuden a interpretar los resultados de tu investigación puedes utilizar post-its virtuales en Google Drawings o algo similar. Si bien no es lo ideal, es mejor que no realizar ninguna investigación UX en absoluto.</p> </li> <li dir="ltr"> <p dir="ltr">Para reclutar usuarios que prueben y evalúen tu producto puedes utilizar herramientas como <a href="https://ethn.io/">ethn.io</a> o <a href="https://www.usertesting.com/">usertesting.com</a></p> </li> <li dir="ltr"> <p dir="ltr">Ejecuta Tree Tests, Card Sorting o Surveys con <a href="https://www.optimalworkshop.com/">optimalworkshop.com</a></p> </li> <li dir="ltr"> <p dir="ltr">Prioriza tu backlog con la encuesta de satisfacción de la Metodología Kano en <a href="http://featur.me">FeatUR.me</a></p> </li> </ul> <h3 dir="ltr">Incorporación en ciclo ágil</h3> <p dir="ltr">La figura 1 muestra cómo se incorporan actividades de investigación de usuarios en un ciclo de vida ágil. Antes de entrar al ciclo de desarrollo (marcado en amarillo) debemos incluir un ciclo de investigación y validación de ideas (marcado en rojo). Este ciclo de “descubrimiento” se realiza un par de semanas antes de iniciar el sprint, de tal manera que al final tendrás un prototipo ya validado. El cual a su vez se convertirá en el documento de requerimientos que hará posible la planeación del sprint y el desarrollo de lo planeado.</p> <p dir="ltr">En ambos ciclos hay actividades de investigación específicas que puedes realizar. Recuerda, probar poco y a menudo es la clave.</p> <p dir="ltr"><img alt="Fig1" data-entity-type="file" data-entity-uuid="6592e86b-5b2d-4811-bb9e-e45d41c0d489" src="/sites/default/files/inline-images/SG54-ux1.jpg" width="700" /></p> <p dir="ltr">Figura 1. Investigación de usuarios en un ciclo ágil</p> <h3 dir="ltr">Conclusión</h3> <p dir="ltr">Establecer una práctica de investigación de usuarios llevará tiempo, pero poco a poco ayudarás a tu equipo a integrar la voz del cliente en su trabajo. El tiempo que dediques a este cambio de mentalidad valdrá cada segundo que inviertas.</p> <p dir="ltr">Todos los integrantes de tu equipo se beneficiarán:</p> <ul> <li dir="ltr"> <p dir="ltr">Los product managers ahorrarán dinero. Ellos pueden asegurarse de que están construyendo lo correcto, y que ahorrarán tiempo para mantener la preparación del producto aún más.</p> </li> <li dir="ltr"> <p dir="ltr">Los diseñadores estarán seguros sobre sus decisiones de diseño. Ellos tendrán una mejor comprensión del problema y ​​validarán sus suposiciones con usuarios reales.</p> </li> <li dir="ltr"> <p dir="ltr">Los desarrolladores pueden ver su trabajo siendo utilizado en tiempo real. Podrán idear soluciones alternativas al problema que están observando. Desarrollarán empatía para las personas que utilizan lo que ellos construyen.</p> </li> </ul> <p dir="ltr">No es posible crear soluciones significativas sin incluir la perspectiva del cliente. La gente simplemente no va a pagar dinero por productos que no se adapten a sus necesidades y su estilo de vida.</p> <p dir="ltr">Referencias</p> <ol> <li dir="ltr"> <p dir="ltr">John Jeremiah. “Survey: Is agile the new norm?”. TechBeacon.  <a href="http://swgu.ru/sg">http://swgu.ru/sg</a></p> </li> <li dir="ltr"> <p dir="ltr">“Moderated User Research: Unveiling insights with 1-on-1 interviews”. UX Team by Nearsoft. <a href="http://swgu.ru/sh">http://swgu.ru/sh</a></p> </li> <li dir="ltr"> <p dir="ltr">“Elito Method: Users reactions vs. assumptions.” UX Team by Nearsoft. <a href="http://swgu.ru/si">http://swgu.ru/si</a></p> </li> <li dir="ltr"> <p dir="ltr">Becky White. “Atlab: Set up your own user research lab”. <a href="http://swgu.ru/sj">http://swgu.ru/sj</a></p> </li> </ol> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/tags/ux-0" hreflang="und">ux</a></li> <li><a href="/tags/user-experience" hreflang="und">User Experience</a></li> </ul> </div> Wed, 03 May 2017 06:24:20 +0000 ana2lp 7268 at https://sg.com.mx https://sg.com.mx/revista/54/c-mo-hacer-investigaci-n-usuarios-equipos-giles#comments Selenium WebDriver en un Ambiente de Pruebas Continuas https://sg.com.mx/revista/54/selenium-webdriver-un-ambiente-pruebas-continuas <span class="field field--name-title field--type-string field--label-hidden">Selenium WebDriver en un Ambiente de Pruebas Continuas</span> <div class="images-container clearfix"> <div class="image-preview clearfix"> <div class="image-wrapper clearfix"> <div class="field field--name-field-image field--type-image field--label-hidden field__item"> <img src="/sites/default/files/images/selenium-logo.png" width="200" height="181" alt="" typeof="foaf:Image" /> </div> </div> </div> </div> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><a title="View user profile." href="/user/47654" lang="" about="/user/47654" typeof="schema:Person" property="schema:name" datatype="" class="username">ana2lp</a></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 05/03/2017 - 01:21</span> <div class="field field--name-field-numrevista field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Publicado en</h3> <ul class='links field__items'> <li><a href="/revista/54" hreflang="und">SG #54</a></li> </ul> </div> <div class="field field--name-field-seccion field--type-entity-reference field--label-hidden field--entity-reference-target-type-taxonomy-term clearfix"> <ul class='links field__items'> <li><a href="/revista/secciones/tutorial" hreflang="und">Tutorial</a></li> </ul> </div> <div class="field field--name-field-autor field--type-entity-reference field--label-inline field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label inline">Autor</h3> <ul class='links field__items'> <li><a href="/buzz/autores/gilberto-sanchez-mares" hreflang="und">Gilberto Sánchez Mares</a></li> </ul> </div> <div class="text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p dir="ltr">Selenium automatiza los navegadores. ¡Eso es todo! Lo que hagas con ese poder depende de ti. Principalmente, es para la automatización de aplicaciones web con fines de pruebas, pero ciertamente no se limita a eso. Las tareas aburridas de administración basadas en web pueden (¡y deben!) ser automatizadas. Una definición muy concreta y directa, pero vamos a ampliar un poco más la definición.</p> <p dir="ltr">El texto anterior es la introducción en la página principal de SeleniumHQ [1]. Selenium es un conjunto de herramientas de código abierto que nos ayuda a automatizar acciones que un usuario puede realizar sobre aplicaciones web. Cada herramienta dentro de este conjunto tiene un enfoque diferente para apoyar el proceso de automatización de pruebas.</p> <p dir="ltr">Los cuatro componentes de Selenium son:</p> <ol> <li dir="ltr"> <p dir="ltr">Selenium IDE: es un entorno de desarrollo integrado para scripts de Selenium. Se implementa como una extensión de Firefox y permite grabar, editar y depurar pruebas. Este IDE incluye todo el Selenium Core, que permite grabar y reproducir de forma fácil las pruebas en el entorno real en el cual se ejecutarán. Se recomienda su uso para prototipos de pruebas, debido a que no es capaz de generar ciclos ni condiciones.</p> </li> <li dir="ltr"> <p dir="ltr">Selenium RC (Remote Control): es una herramienta para automatizar pruebas de interfaz de usuario (UI) de aplicaciones web. Consta de dos componentes: a) un servidor que actúa como proxy para controlar e interactuar con un navegador web. b) bibliotecas para crear programas para el servidor usando una amplia gama de lenguajes de programación. Fue la herramienta original de Selenium para pruebas web pero a partir de la versión 2 fue integrado con WebDriver y se prefiere usar este último.</p> </li> <li dir="ltr"> <p dir="ltr">Selenium WebDriver: también es una herramienta para automatizar pruebas UI de aplicaciones web pero implementa un enfoque más moderno y estable que Selenium RC. WebDriver, a diferencia de RC no utiliza un middleware sino que controla el navegador comunicándose directamente con él.</p> </li> <li dir="ltr"> <p dir="ltr">Selenium Grid: se especializan en ejecutar múltiples pruebas a través de diferentes navegadores, sistemas operativo y máquinas. Puede conectarse con Selenium Remote especificando el navegador, la versión del navegador y el sistema operativo que desee. Hay dos elementos principales: hub y nodos.</p> </li> </ol> <p dir="ltr">En este artículo nos enfocaremos en WebDriver. Como ya comentamos, es un framework de automatización web que permite ejecutar casos de prueba sobre distintos navegadores. Debido a que es posible utilizar lenguajes de programación para la creación de scripts de pruebas, podemos tener estructuras de control como condiciones y bucles para controlar el comportamiento. Algunos de los lenguajes soportados son: Java, C#, Python, Ruby, PHP y JavaScript.</p> <h3 dir="ltr">Arquitectura</h3> <p dir="ltr">A primera vista puede parecer que Selenium está manejando el navegador directamente desde nuestro código, sin embargo este proceso es un poco más complejo de lo que pareciera. La arquitectura de WebDriver está dividida en tres partes principales: lenguaje de vinculación, WebDriver API y drivers.</p> <p dir="ltr">Para ver cómo es que interactúan las partes entre sí, digamos que se ha escrito el script de prueba usando Java (lenguaje de vinculación) para comunicarse con la API de WebDriver. El código generado va a emitir comandos a través del WebDriver wire protocol, el cual es un servicio REST capaz de interpretar dichos comandos. El driver es un ejecutable que básicamente escucha en un puerto de la máquina local cuando se ejecutan las pruebas y espera que los comandos entren. Una vez que los comandos son captados por el driver, estos son interpretados y ejecutados sobre el navegador.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="191" src="https://lh6.googleusercontent.com/evJruv6Nx8xYXLQqJ8BgqPZNBALNjPI4bSbhNuLIc74j8nnLTauv7CJXb3R1yxeGw3bgsPClOlrdDsMSEZfi8Lr-F3EfWppL6WOiquIxmlmcnZAtaGwsFZW4L9BFdBqRhCe4Eg8q" width="589" /></p> <p dir="ltr"><em>Figura 1. Arquitectura WebDriver.</em></p> <h3 dir="ltr">Ventajas y desventajas</h3> <p dir="ltr">La tabla 1 lista un comparativo de WebDriver contra otras herramientas que cumplen un propósito similar.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="585" src="https://lh5.googleusercontent.com/uIzyAezxDyM81bFPkd75OGHCohNPFjbEPEPvJoDjpd-FfmQX-vVzuzeA2uYh8_QIKmPm0alDMR8DRzub3c2p_pad8Hh8XfcdQeHyLu79WiD3OywqhtNvwGNojgBaCnG49V3nmso1" width="589" /></p> <p dir="ltr"><em>Tabla 1. Tabla comparativa</em></p> <h3 dir="ltr">Continuous Testing con WebDriver</h3> <p dir="ltr">Continuous Testing (CT) es en realidad una metáfora para un mecanismo de retroalimentación continua que impulsa la entrega de software funcional. La retroalimentación automatizada en cada punto de control es un disparador automático para el siguiente proceso en la cadena de entrega si la retroalimentación es para avanzar. Si la retroalimentación no avanza, el proceso se detiene inmediatamente y se toman medidas correctivas. Las organizaciones de TI tradicionales pueden acortar el camino para implementar CT reutilizando y realineando las capacidades de automatización de pruebas existentes.</p> <p dir="ltr">Si se cuenta con un proceso de integración continua, la automatización de pruebas de UI es relativamente sencilla ya que se puede llevar a cabo con Selenium WebDriver y una herramienta de CI como Jenkins. El único requisito es utilizar un framework de pruebas unitarias como lo es TestNG, JUnit, NUnit, PHPUnit, etc. La figura 2 muestra un mapeo entre herramientas a través de distintas actividades y disciplinas del ciclo de desarrollo de software.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="308" src="https://lh5.googleusercontent.com/pTMF8vyvtBAnEeJ8uOv1IeoTIcv6a6t98XusM9mGIkOKJXXiR1Xz9B-ikcv7SuqgI6Qdss3jpXmhm6PsIf9mhTVCvAdLrE5dzRCWLl7buXN3102HXgJ1sSIUvMu7-c_wFFBBJFl-qv1Bp6PUeg" width="589" /></p> <p dir="ltr"><em>Figura 2. Selenium WebDriver dentro del proceso de integración continua.</em></p> <h3 dir="ltr">Ejemplo</h3> <p dir="ltr">A continuación, se presenta un ejemplo de cómo realizar pruebas dirigidas por datos (data driven testing) con el framework de pruebas unitarias TesNG. El ejercicio consistirá en probar el formulario de registro de usuario en la página Mercury Tours (<a href="http://newtours.demoaut.com">http://newtours.demoaut.com</a>). Todos los archivos y código usado para el ejercicio se encuentran disponibles en <a href="https://github.com/gsanchez-tiempodev/SoftwareGuruDemo">https://github.com/gsanchez-tiempodev/SoftwareGuruDemo</a></p> <p dir="ltr">El caso de prueba que se ejecuta es el siguiente:</p> <p dir="ltr"><strong>Descripción</strong>: Registrar usuario para la página Mercury Tours</p> <p dir="ltr"><strong>Procedimiento</strong>:</p> <ol> <li dir="ltr"> <p dir="ltr">Navegar a la página de Mercury Tours</p> </li> <li dir="ltr"> <p dir="ltr">Dar click en enlace REGISTER</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;First Name&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Last Name&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Phone&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Email&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Address&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;City&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;State&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Postal Code&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Seleccionar &lt;Country&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;User Name&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Password&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Ingresar &lt;Confirm Password&gt;</p> </li> <li dir="ltr"> <p dir="ltr">Dar Click en botón Submit</p> </li> </ol> <p dir="ltr"><strong>Resultado esperado</strong>:</p> <p dir="ltr">Página con el mensaje: “Dear &lt;First Name&gt;, Thank you for registering. You may now sign-in using the user name and password you've just entered. Note: Your user name is &lt;User Name&gt;.“</p> <p dir="ltr">Cómo podemos ver, necesitamos llenar una cantidad considerable de campos en el formulario de registro, por lo que será útil alimentar los datos de prueba desde una hoja de cálculo. Así que preparamos un archivo FlightRegisterData.xls con una hoja llamada RegisterUser que contenga los datos mostrados en la figura 3, cuyas columnas corresponden a los campos que requerimos introducir en la forma de registro.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="68" src="https://lh5.googleusercontent.com/vvvpCWKCPhYwCr2U369lJY7D5llhpbnwNYyUn-EkYwX4u7R7QAPPcWJjI6eIrAPLEtcn9MzYbGjionCfklZ2t4WqWEnRZoqvudwo7mSQLfQOEVbDcR68zlL0OwlCld-6fRDD1Cf2JTswnqNB5w" width="589" /></p> <p dir="ltr"><em>Figura 3. Datos de Prueba.</em></p> <p dir="ltr">Nuestra clase principal llamada RegisterUsers.java, es donde se llamarán todos los métodos del negocio y algunos métodos comunes.</p> <p dir="ltr">Para extraer los datos de nuestro archivo de Excel, creamos un arreglo bidimensional de objetos (Object[][]) que guardará los valores del Excel. Para iniciar el método que nos ayudará a la recolección de los datos, utilizamos la anotación @DataProvider y le damos un nombre, en este caso lo llamamos UserRegistration. Dicho método se apoya en una utilería para leer datos de nuestra hoja de Excel y vaciarlos en el arreglo de objetos que regresamos como resultado.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="117" src="https://lh5.googleusercontent.com/ADKYDQomll1CLEVva9jmHuR1_qUOrtmiB0AE70O1vhKEfdNuC8L-gmPQewJ6tk--uGD_fwZGHdC3Ne2m4GCPQZ9bNGGVf1UPVPAMyB9jIIl-1am5_lnb4Ilcb04vrS40wRi0F9DG" width="589" /></p> <p dir="ltr"><em>Listado 1. Leer datos de prueba</em></p> <p dir="ltr">Tenemos un método setUp con la anotación @BeforeTest que se encarga de abrir un navegador, ir al url de inicio y maximizar el navegador antes de que cualquiera de nuestras pruebas se ejecute. Al finalizar la ejecución queremos cerrar el navegador y terminar el driver que lo manipula, así que para ello creamos un método que llamamos tearDown y le ponemos la anotación @AfterTest. Antes de que se vuelva a llenar el formato de registro en cada iteración, deseamos que se le vuelva a dar click al enlace REGISTER; para realizar dicha acción creamos un método clickRegister con la anotación @BeforeMethod.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="216" src="https://lh6.googleusercontent.com/Yee9_20GkbDEAN-JR9aYTewpPxR61b8tr3cjb78KBRFQ29NZLuczmY2ABfH2r8Ul3Wj08rXG8hK8pePjhFFgfQOR9xrXSzecpx3BJ6Sbf8ucIWkGCesyyl1mrb5_hMg2aMYi8rTR" width="589" /></p> <p dir="ltr"><em>Listado 2. setUp, tearDown y clickRegister</em></p> <p dir="ltr">El método contactInformation es el que se encarga de correr nuestra prueba y por ello lleva la anotación @Test. La firma de argumentos de este método es del tipo String … dataProvider, &nbsp;la cual nos indica que acepta n número de argumentos (para este ejemplo serán 11). En este caso, vamos a estructurar los datos en 3 grupos: información de contacto (columnas 0 a 3), dirección de correo (columnas 4 a 8) e información de usuario (columnas 9 y 10). &nbsp;Separamos los datos y nos apoyamos en los métodos addContactInfo, addMailingInfo y submitUserInfo. Finalmente, hacemos un assert para validar que la página de resultado contiene el nombre del usuario.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="337" src="https://lh4.googleusercontent.com/akJeWK7ClcUdcUJKZLuQoFOE_p8hlrtjRvwTqS5rFVu5EmvuJvz2X71PyVpxYHuzsPc9yGufibhR_EhkmbG96FpTav7uFG9AhDfpfEGt8Wuxz3WxfI9Qgz1ga87lExWAiAbWaCD7" width="589" /></p> <p dir="ltr"><em>Listado 3. Método de prueba</em></p> <p dir="ltr">La clase Common.java define métodos reutilizables de acciones que se pueden ejecutar sobre los objetos web tales como escribir en un text box, seleccionar un elemento de un combo box, navegar a la página web, etcétera. Estas acciones se logran por medio de métodos que implementa el driver de selenium. El listado 4 tiene un ejemplo. El contenido completo se puede ver en el repositorio.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="307" src="https://lh4.googleusercontent.com/sxW8S7kJVhtoTNPG0UEMSqGNd0dmWoZrXhkYraSkrv4Lu4Gc2_zmzblggxEbfUiK83Zi1hCXe5Zl4C1xeZ5oCtq098Rd0GaiBtxZUoUy5UiXd7LCJK6LZYJu8Q2EU9NbdfP-R4Ye" width="589" /></p> <p dir="ltr"><em>Listado 4. Algunos métodos en Common.java</em></p> <p dir="ltr">Por su parte, Business.java contiene los métodos que siguen reglas de negocio, como lo puede ser un login, un alta de usuarios, etc. Un ejemplo es el método addMailingInfo, el cual utiliza los métodos definidos en Common.java para realizar el llenado de la información de correo del usuario que se va a registrar. <img alt="" data-entity-type="" data-entity-uuid="" height="161" src="https://lh5.googleusercontent.com/IFppsN_hPgIVTeJW2g-C8GoKLm7pp8S8PMpBVifIU8NoSteoEPKZt_jFFf9zmHqLVjABksEJ-xkNl0RQXWc1rfjBTv4Rd-kL5LzikYr74H4kTrcQNW1nt6DdDQnwxhMGHrr2rj-w" width="662" /></p> <p dir="ltr"><em>Listado 5. addMailingInfo</em></p> <p dir="ltr">Finalmente, en la figura 4 se muestran los resultados generados por TestNG al ejecutar nuestra prueba aplicando los distintos datos.</p> <p dir="ltr"><img alt="" data-entity-type="" data-entity-uuid="" height="279" src="https://lh3.googleusercontent.com/J1ZS8nx4dFQQ1tNBFWYUhSOeh49dtdFLwfLp506IHm_V_22M1bkzc3-JEkc8y8_n3n6l_ST4pHHrl8al7rZcwT8lQSuxWek_CwHHn2aHiKDhVI8L71cMCOSu5YUObhCERYrXZuYE" width="662" /></p> <p dir="ltr"><em>Figura 4. Resultados de ejecución generados por TestNG.</em></p> <p>&nbsp;</p> <p dir="ltr">Referencias</p> <ol> <li dir="ltr"> <p dir="ltr">SeleniumHQ. <a href="http://www.seleniumhq.org/">http://www.seleniumhq.org</a></p> </li> <li dir="ltr"> <p dir="ltr">“Introduction to Selenium”. Guru99. <a href="http://swgu.ru/sk">http://swgu.ru/sk</a></p> </li> <li dir="ltr"> <p dir="ltr">S. Honnamane &amp; R. Bar. “Jumpstarting DevOps with Continuous Testing”. Cognizant 20-20 Insights. <a href="http://swgu.ru/sl">http://swgu.ru/sl</a></p> </li> </ol> <p>&nbsp;</p> </div> <div class="text-formatted field field--name-field-autor-bio field--type-text-long field--label-above"> <div class="field__label">Bio</div> <div class="field__item"><p><span style="font-size: 13.008px;">Gilberto Sánchez Mares es Test Automation Engineer con experiencia de 5 años en diseño e implementación de proyectos de pruebas automatizadas utilizando varios frameworks y herramientas de automatización.&nbsp;</span><a href="mailto:gilberto.sanchez@upa.edu.mx" style="font-size: 13.008px;">gilberto.sanchez@upa.edu.mx</a></p> </div> </div> <section class="field field--name-comment field--type-comment field--label-above comment-wrapper"> </section> <div class="field field--name-field-tags field--type-entity-reference field--label-above field--entity-reference-target-type-taxonomy-term clearfix"> <h3 class="field__label">Tags</h3> <ul class='links field__items'> <li><a href="/tags/testing" hreflang="und">Testing</a></li> </ul> </div> Wed, 03 May 2017 06:21:57 +0000 ana2lp 7267 at https://sg.com.mx https://sg.com.mx/revista/54/selenium-webdriver-un-ambiente-pruebas-continuas#comments