SG #29

Premios SG Guía 2010

Anonymous — Thu, 26 Aug 2010 16:43:39 +0000

Premios SG Guía 2010 Anonymous Thu, 08/26/2010 - 11:43

Publicado en

SG #29

Este verano llevamos a cabo nuestro ejercicio anual para sondear y difundir cuáles son las herramientas y tecnologías favoritas de nuestros lectores.

Este ejercicio se realiza en un proceso de dos etapas:

Primero se abre un wiki en el que invitamos a nuestros lectores a indicar las categorías que desean incluir, así como los productos participantes en cada una.
Posteriormente generamos una encuesta online y convocamos a que nuestros lectores voten por sus productos favoritos.

Poco más de 500 personas participaron en este ejercicio. Vale la pena recalcar que los resultados se generaron a partir de la votación en línea, y no son un indicativo de la postura de Software Guru respecto a ninguno de estos. El que un producto haya quedado en primer lugar simplemente que entre los lectores de SG, ese producto es el más popular.

Sin mayor preámbulo, prosigamos a ver quienes fueron los ganadores de este año. En cada categoría se muestra primero al ganador y posteriormente al segundo y tercer lugar.

Administración de proyectos

Microsoft Project
Rational Project Conductor
JIRA

Gestión de datos: Servidor RDBMS

MySQL
Oracle
PostgreSQL

Gestión de datos: Almacen NO SQL

Cassandra
CouchDB
MongoDB

Gestión de datos: Herramienta de administración

Quest Toad
IBM InfoSphere Data Architect
EMS SQL Management Studio

Gestión de datos: Herramienta de modelado

IBM Rational Rose Data Modeler
CA Erwin Data Modeler
Oracle SQL Developer Data Modeler

Gestión de datos: Cliente SQL

Oracle SQL Developer
Squirrel SQL Client
Navicat 8

Gestión de datos: ETL e integración

IBM Information Server
Oracle Warehouse Builder
Kettle Pentaho Data Integration

Gestión de datos: Data warehouse

Oracle
IBM
Microsoft

Gestión de datos: Business Intelligence

IBM Cognos
Oracle Business Intelligence Suite
Pentaho BI Suite

IDE: editor de código

Notepad++
TextMate
Vi(m)

IDE: Multilenguaje

Eclipse
Netbeans
Microsoft Visual Studio

IDE: Java

IBM Rational Application Developer for WebSphere Software
J Creator Pro
IntelliJ IDEA

IDE: PHP

Zend Studio
PHP Editor
phpDesigner

IDE: web

Adobe Dreamweaver
Aptana Studio
IBM Rational Application Developer for WebSphere Software

IDE: aplicaciones móviles

Eclipse
Netbeans (Mobility Pack)
Microsoft Visual Studio

Lenguajes declarativos y 4GL

GeneXus
PowerBuilder
4D

Framework arquitectónico para aplicaciones web

Grails
ASP .Net MVC
Ruby on Rails

Framework para ajax/javascript

JQuery
ExtJS
Dojo

Gestión de requerimientos

IBM Rational Requirements Composer
Microsoft Team Foundation Server
Borland CaliberRM

Gestión de issues, defectos y cambios

Bugzilla
IBM Rational ClearQuest
Mantis

Control de versiones

Subversion
CVS
Git

Build management

Apache Ant
Apache Maven
IBM Rational Build Forge

Integración continua

Apache Continuum
Hudson
Atlassian Bamboo

Lenguaje alternativo para la JVM

Groovy
JRuby
Jython

Modelado con UML

IBM Rational Software Modeler
ArgoUML
Sparx Enterprise Architect

Gestión de arquitectura de sw

IBM Rational System Architect
Microsoft Visual Studio Ultimate
Sparx Enterprise Architect

Testing & QA: Gestión de pruebas

IBM Rational Quality Manager
TestLink
Microfocus QADirector

Testing & QA: Pruebas funcionales

IBM Rational Functional Tester
Compuware TestPartner
Borland SilkTest

Testing & QA: Pruebas de desempeño

Apache JMeter
IBM Rational Performance Tester
Embarcadero DBOptimizer

Testing & QA: Análisis de código (profiling)

Microsoft Visual Studio
IBM Rational PurifyPlus
JProbe

Monitoreo de aplicaciones

IBM Tivoli
Oracle
HP Business Availability Center

Hypervisors

VMware vSphere
Oracle VM Server
Windows Server 2008 R2 • Hyper-V

Gestión de virtualización

VMWare vCenter
IBM Tivoli
Excelerate vKernel

Plataforma SOA

IBM WebSphere
Oracle Fusion
JBoss Enterprise SOA

Portal Empresarial

IBM WebSphere Portal
Apache JetSpeed
Oracle Portal

Content Management System

Joomla
WordPress
Drupal

Plataforma para aplicaciones móviles

Android
iPhone
Java ME

Plataforma de cómputo en la nube

Google App Engine
Amazon Web Services
Windows Azure

Estrategia, framework o metodología de desarrollo

Scrum
Unified Process (RUP, EUP, OpenUP, etc)
Team Software Process (TSP) / Personal Software Process (PSP)

Hosting de servidores virtuales y dedicados para desarrolladores

Neubox
Rackspace (Managed Private Cloud)
Sandino Networks

La Importancia de Generar Mente de Obra Calificada

Anonymous — Sun, 22 Aug 2010 21:46:00 +0000

La Importancia de Generar Mente de Obra Calificada Anonymous Sun, 08/22/2010 - 16:46

Publicado en

SG #29

Carrera

Autor

Carlos Castilla

El sector público y la iniciativa privada hablan frecuentemente sobre la necesidad impostergable de generar plazas de empleo en el país. ¿Pero quién se ha dado a la tarea de enfatizar la pertinencia de formar talento que responda a las exigencias internacionales? Es de especial importancia que la iniciativa privada e instituciones de educación superior conjunten esfuerzos con un sentido estratégico, para atender las necesidades de formar mente de obra en las áreas que la actividad económica demanda.

La industria de las TI en México tiene proyectado crecer de una manera importante en los próximos cinco años, lo cual implica incorporar a nuevos proyectos, recursos humanos calificados. Como en su momento lo fue el sector maquilador, hoy en día el sector de tecnologías de información es una plataforma estratégica para el desarrollo económico de muchos países.

Como ejemplo la India, cuya industria de las TI ha crecido en promedio 50% durante la última década y actualmente equivale aproximadamente al 10% de su PIB. Este explosivo crecimiento ha sido posible, en gran parte, por el rápido y persistente incremento de las exportaciones de software. Además, el gobierno de India se ha mostrado altamente receptivo al capital extranjero para mantenerse competitivo. Sin embargo, México tiene en sus manos la gran oportunidad de captar mucho más interés de empresas asentadas en Estados Unidos, Canadá y Europa principalmente. No sólo por su posición geográfica estratégica o por su zona horaria, también por el desarrollo de su industria de TI en lo particular, así como por los proyectos conjuntos donde convergen iniciativa privada, universidades y gobierno.

Durante los años más recientes, mucho más evidente en el último trienio, las compañías estadounidenses han encontrado en México una valiosa mina de empresas y mente de obra calificada, bilingüe, con experiencia en el desarrollo de software y en la prestación de servicios de Business Process Outsourcing (BPO). Este contexto ha permitido al sector crecer quizá más que ninguna otra industria, y se proyecta que durante el presente año reportará un dinamismo positivo: una tasa de crecimiento estimada del 8%, exportaciones calculadas de software y aplicaciones por $4 mil 230 millones de dólares, un mínimo de 2 mil 350 empresas, 10% de ellas con certificados de calidad; 32 estados con políticas de TI, 22 parques tecnológicos y 157 universidades con programas de tecnología.

Sin embargo, y a pesar del excelente desempeño del Programa de Software (Prosoft) de la Secretaría de Economía, para alcanzar las metas planteadas por este fondo para el año 2013 -llegar a $15 mil millones de dólares de facturación, generar 625 mil empleos directos y de aportar el 22.3% del PIB-, la industria de las TI tiene frente a sí grandes desafíos, los cuales y en gran medida, pueden salvarse a través de una profunda reforma educativa. Una reforma que incorpore acciones académicas y disciplina formativa que ayude a los estudiantes desde la educación básica, a incorporar el inglés como segunda lengua, puesto que este tema es una enorme barrera que obstaculiza al país para exportar conocimiento tecnológico. Para que esto ocurra es necesario que empresas, universidades y gobierno trabajen bajo un esquema tripartita que les permita alcanzar metas y lograr objetivos que se traduzcan en un escenario altamente competitivo.

Acertadamente ya hay proyectos en este sentido. En algunas empresas, como es el caso de Neoris, contamos con programas que ofrecen a los alumnos de los últimos semestres de la carrera la oportunidad de capacitarse brindándoles la posibilidad de formarlos como desarrolladores y consultores con niveles de competitividad internacional. Estos proyectos son una realidad gracias al trabajo conjunto de universidades y empresas. La parte de la fórmula que aún falta es la decisión de las autoridades educativas federales y locales, para sumarse a efecto de incorporar en la política educativa pública las acciones necesarias para aumentar el dominio del idioma inglés.

Es muy importante para el país el ocuparnos todos –empresas, universidades y gobierno-, en formar la mente de obra que hará que México aproveche en el corto y mediano plazo la oportunidad de convertirse en un proveedor internacional de conocimiento y servicios de TI.

En definitiva, la competitividad es un tema que debemos atender con mucho más decisión, apoyándonos en una política basada en una reforma educativa de fondo. No todas las respuestas a las exigencias que impone el mundo están en las ventajas de costo de producción de México y Tratado de Libre Comercio de América del Norte. México necesita conservar sus ventajas actuales, pero además debe alinear su política educativa a las exigencias que impone la competitividad internacional. Adicionalmente debe ejecutar acciones que faciliten a la gente el acceso de la tecnología, que es una ventana al mundo y, también, una herramienta importante para reducir la brecha educativa que existe entre la educación pública y privada.

Bio

Carlos Castilla es Director General en Neoris de México. Actualmente está a cargo de la generación de negocios y supervisión de procesos de calidad para la Unidad México, participando en la creación de estrategias de Nearshore para el mercado de Estados Unidos. Sus funciones también incluyen la dirección de 3 de los 6 Centros Globales de Soluciones, en Budapest, Culiacán y Monterrey, así como la coordinación de 1,800 consultores.de Estados Unidos. Sus funciones también incluyen la dirección de 3 de los 6 Centros Globales de Soluciones, en Budapest, Culiacán y Monterrey, así como la coordinación de 1,800 consultores.

Gestión de Infraestructura

Anonymous — Sun, 22 Aug 2010 21:36:54 +0000

Gestión de Infraestructura Anonymous Sun, 08/22/2010 - 16:36

Publicado en

SG #29

Infraestructura

Autor

Armando Galeana

En la mayoría de las organizaciones de TI, el costo de la adquisición y gestión de infraestructura absorbe la mayor parte de su presupuesto. El gasto excesivo se debe a la complejidad de la infraestructura, aplicaciones redundantes, alta personalización y soporte para una amplia gama de sistemas. A su vez, se espera que la organización de TI mejore los niveles de servicio, y agregue nuevos servicios al mismo tiempo que satisface la fuerza de trabajo y minimiza los riesgos.

Los analistas de la industria coinciden en que el esquema tradicional de aquisición y mantenimiento de herramientas para gestión de infraestructura de software están llegando a su fin. Esto se debe a la madurez de la próxima generación de las soluciones de infraestructura construidas sobre una base en ITIL v3 y entregada como Plataforma como Servicio (PaaS) o Software como Servicio (SaaS). Esto reduce los costos de inversión en más de un 80% en licencias de software convencional y permite personalizaciones configuradas por el usuario.

Mientras que las herramientas son una parte clave de la mezcla, se necesita una solución con buena arquitectura y artesanos calificados para llevar la visión a una buena realización. La gestión integrada de infraestructura es sobre todo la transformación de la infraestructura y la ejecución tanto de la visión y la madurez necesaria para que TI se convierta en el socio de negocios de la empresa que requiere para desarrollar una ventaja competitiva sustentable, aprovechando a TI como un arma.

Desafío del día

A medida que venimos de años muy difíciles en términos económicos, nos enfrentamos a desafíos en la reducción de costos para el crecimiento de nuestros negocios. Las condiciones económicas han afectado cada tejido de las empresas y, en particular, a las TI. La recesión ha aumentado la necesidad e importancia para los CIOs de reducir los costos al mismo tiempo que mejoran la calidad y disponibilidad de los servicios a sus usuarios. Más allá de esto, se les ha solicitado en aumento a los líderes de TI demostrar cómo pueden ayudar con la mejora de resultados de negocio y mejorar así la competitividad de las empresas. Desafortunadamente, enfrentar este desafío con inmadurez e infraestructura muy compleja es como tratar de ganar una carrera de Fórmula Uno con una minivan –—ninguna está a la altura del desafío.

Gestión integrada de la infraestructura

La gestión de infraestructura integrada fue originalmente definida por CompuCom en 2003 para describir la integración de herramientas, automatización y tecnologías de auto-sanación/auto-asistencia. El objetivo en aquel entonces era reducir los costos de apoyo en la infraestructura por aprovechamiento de clase mundial en el centro de servicio estrechamente integrado con una o dos torres de servicio. Esto produjo importantes mejoras en las tasas de primera resolución (más del 90%), mientras se reducían significativamente los altos costos de entrega de 2° nivel. El cambio en el trabajo obtuvo un ahorro significativo de costos en soporte y aumentó la productividad del usuario final en virtud de la disminución de tiempo de inactividad en la espera de la restauración del sistema o el uso de aplicaciones.

El costo y la complejidad de la infraestructura en la mayoría de las empresas está inhibiendo la agilidad de la entrega completa, rendimiento y ahorro del costo. Una completa reingeniería de procesos a través de todos los límites funcionales es necesaria en TI para lograr la calidad del servicio y el rendimiento que la empresa requiere. Este enfoque holístico es el catalizador que impulsa el cambio evolutivo de la actividad de gestión integrada de infraestructura con la innovación.

Entregar este nivel de rendimiento y la madurez que requiere la integración de nuevos conjuntos de herramientas que soportan todos los procesos de ITIL v3 no es trivial. Tras una búsqueda exhaustiva, se han identificado un conjunto de herramientas de referencia que contiene los componentes clave y necesarios para construir una solución completa y aprovechar plenamente los resultados previstos en las formas anteriores de gestión Integrada de Infraestructura.

Elevando la madurez de la infraestructura

Conforme se busca mejorar la madurez de su gestión de TI, las organizaciones deben resolver cuestiones que tienen que ver con estandarización, políticas, aspectos cruzados de los departamentos. Hacia los niveles más avanzados de madurez está el enfoque real al negocio, donde la infraestructura está completamente alineada y bajo control, y su enfoque se centra en perfeccionar su infraestructura y procesos para alinearse con la estrategia del negocio y contribuir en el crecimiento del negocio.

La gestión integrada de infraestructura se trata de colaboración, asociación estratégica con nuestros clientes y un compromiso de avanzar en su madurez de infraestructura. Es un viaje que podemos tomar juntos, y nuestro mutuo objetivo es lograr el nivel de desarrollo que se requiere y que entregará el valor de negocio más grande.

El desarrollo de una ruta incluye:

Identificar sus actuales puntos de dolor y objetivos – estabilizar metas claras y objetivas para mejorar y establecer plazos realistas para lograr los objetivos.
Identificando su actual nivel de madurez en la infraestructura – Realizar una evaluación de la madurez de referencia que incluye una evaluación completa de los costos, métricas y tecnología, y resultados de punto de referencia con la ayuda de expertos en los estándares de la industria. Obtener ayuda experta dentro de los recursos externos en el trazado y comparación de su organización contra una amplia base de datos en la evaluación.
Establecer una revisión clara para el futuro estado de tu TI – Obtener asesoramiento experto de un proveedor líder de servicios para ayudar a desarrollar un programa y una hoja de ruta para un progreso.

Conclusión

La transformación y cambio sustentable es absolutamente posible, y está a su alcance. Sin embargo, no es ningún secreto que las personas y organizaciones en el pasado han retrazado proyectos de este tipo por intentos fallidos de los demás. Es más fácil no hacer nada y evitar correr el riesgo de fracasar en un cambio radical en la organización. Sin embargo, este cambio es una gran oportunidad para todas las empresas hoy en día. Brinda un potencial a cualquier organización de TI para convertirse en un catalizador de negocio orientado al cambio de la obtención de beneficios transformacionales en términos de: reducción de costos, mejora del rendimiento, increíble calidad, y más importante, la fuerte entrega del valor empresarial.

Este trabajo muestra que la gestión integrada de infraestructura tiene la capacidad de simplificar drásticamente a la empresa, tanto en TI como en sus operaciones, mientras que al mismo tiempo mejora la comunicación entre TI y el negocio a través de la innovación y la aplicación exitosa de nuevas tecnologías.

Bio

Armando Galeana es Gerente de Desarrollo de Negocios en CcompuCom, empresa multinacional especializada en la gestión de infraestructura de TI.

Reflexión: Alterando los objetos de forma dinámica

Anonymous — Sun, 22 Aug 2010 21:05:14 +0000

Reflexión: Alterando los objetos de forma dinámica Anonymous Sun, 08/22/2010 - 16:05

Publicado en

SG #29

Fundamentos

Autor

Josué Martínez Buenrrostro

De acuerdo con la Real Academia de la Lengua Española, reflexión es la “acción y efecto de reflexionar”, en tanto que reflexionar es: “considerar nueva o detenidamente algo”.

Por otro lado, Wikipedia describe la reflexión en informática como “la capacidad que tiene un programa de ordenador para observar y opcionalmente modificar su estructura de alto nivel”.

La reflexión en la programación de software es la característica de un lenguaje que permite conocer su estructura de manera dinámica (en tiempo de ejecución).

Ejemplo
El listado 1 muestra el código de un programa en java que tiene la siguiente funcionalidad:

Crear una clase del tipo que se proporcione en el primer parámetro.
Crear un objeto a partir de la clase creada en el punto anterior.
Obtener el valor de la propiedad indicada en el segundo parámetro.
Modificar el valor de la propiedad que se obtuvo en el punto anterior con el valor del tercer parámetro.

package org.josuemb;
import java.lang.reflect.Field;

public class EjemploReflexion
{

   @SuppressWarnings(“unchecked”) // Evita un warning al compilar

  public static void main(String[] args) {

    try {
      if (args.length < 3)
      {
        System.out.println(“Error en llamado\n”);
        System.out.println(“Sintaxis:”);
        System.out.println(“\tjava EjemploReflexion NombreClase NombrePropiedad Valor”);
        System.exit(1);
      }

      System.out.println(“Creando clase [“+args[0]+”] de manera dinamica...”);
      Class clase = Class.forName(args[0]);

      System.out.println(“Creando objeto de tipo [“+clase.getName()+”] de manera dinamica...”);
      Object objeto = clase.newInstance();

      System.out.println(“Obteniendo propiedad [“+args[1]+”] del nuevo objeto de manera dinamica...”);
      Field propiedad = objeto.getClass().getDeclaredField(args[1]);

      // Es necesario establecer esta propiedad para acceder a los campos
      // de la clase directamente.
      propiedad.setAccessible(true);

      // Obtiene el valor de la propiedad
      Object valor1 = propiedad.get(objeto);

      // Imprime el valor de la propiedad
      System.out.println(propiedad.getName() + “=” + valor1);

      System.out.println(“Modificando valor de propiedad [“+propiedad.getName()+”]...”);

      //Establece el nuevo valor a la propiedad
      propiedad.set(objeto, args[2]);

      // Obtiene el valor de la propiedad
      Object valor2 = propiedad.get(objeto);

      // Imprime el valor de la propiedad
      System.out.println(propiedad.getName()+” = “+valor2);

      System.exit(0);

    } catch (Exception e) {
      e.printStackTrace();
    } // catch
  } // main
} // EjemploReflexion

Listado 1. EjemploReflexion.java.

El ejemplo EjemploReflexion funciona con cualquier clase. La única restricción (por sencillez en la programación) es que la propiedad a modificar sea de tipo java.lang.String.

Para simplificar aún más la prueba se proporciona también la clase Cliente. Esta se muestra en el listado 2.

package org.josuemb;

public class Cliente {

  private String nombre;
  private String lugar;

  public String getNombre()
  {
    return nombre;
  }

  public void setNombre(String nombre)
  {
    this.nombre = nombre;
  }

  public String getLugar()
  {
    return lugar;
  }

  public void setLugar(String lugar)
  {
    this.lugar = lugar;
  }

}

Listado 2. Cliente.java.

Para ejecutar el ejemplo solo es necesario compilar ambas clases y ejecutarlas mediante el comando:

java EjemploReflexion org.josuemb.Cliente nombre Josue

En caso de que se desee ejecutar el ejemplo con otra clase, la sintaxis sería:

java EjemploReflexion [NombreClase] [NombrePropiedad] [Valor]

El resultado de la ejecución es el siguiente:

$ java org.josuemb.EjemploReflexion org.josuemb.Cliente nombre Josue
Creando clase [org.josuemb.Cliente] de manera dinamica...
Creando objeto de tipo [org.josuemb.Cliente] de manera dinámica...
Obteniendo propiedad [nombre] del nuevo objeto de manera dinamica...
nombre=null
Modificando valor de propiedad [nombre]...
nombre=Josue

Versión Groovy

A continuación muestro el mismo ejemplo en el lenguaje Groovy. El concepto es el mismo, simplemente que las características de Groovy permiten que la sintaxis sea más sencilla.

  if(args.size() < 3 ) {
  println “””Error en llamado

  Sintaxis:
  groovy EjemploReflexion.groovy NombreClase NombrePropiedad Valor”””
  System.exit 1
  }

  println “Creando clase [${args[0]}] de manera dinamica...”

  def clase = args[0] as Class;

  println “Creando objeto de tipo [$clase.name] de manera dinamica...”
  def objeto = clase.newInstance()

  println “Obteniendo propiedad [${args[1]}] del nuevo objeto de manera dinamica...

  println “${args[1]}=${objeto[args[1]]}”

  //Establece el nuevo valor a la propiedad
  objeto[args[1]] = args[2]

  println “Modificando valor de propiedad [${args[1]}]...”
  objeto[args[1]] = args[2]

  println “${args[1]}=${objeto[args[1]]}”

Listado 3. EjemploReflexion.groovy.

package org.josuemb

class Cliente{
  String nombre
  String lugar
}

Listado 4. Cliente.groovy.

Para ejecutar el ejemplo solo es necesario compilar la clase Cliente mediante el comando:

groovyc EjemploReflexion.groovy

Y después ejecutar el Script EjemploReflexion mediante el comando:

groovy EjemploReflexion.groovy org.josuemb.Cliente nombre Josue

En caso de que se desee ejecutar el ejemplo con otra clase, la sintaxis sería:

groovy EjemploReflexion.groovy [NombreClase] [nombrePropiedad] [Valor]

El resultado será equivalente al del ejemplo con java.

Conclusión

La reflexión es una capacidad muy útil que proveen la mayoría de los lenguajes de programación modernos como Java, Groovy, Python, Ruby, C#, entre otros. Nos permite conocer la estructura interna de una clase, sus propiedades, constructores, métodos (parámetros de los mismos), ejecutar los métodos, e incluso obtener y modificar información de miembros privados de una clase. Todo esto sin necesidad de tener el código fuente ni la documentación de una clase. También por medio de la reflexión podemos lograr que un programa pueda adaptarse dinámicamente a distintas situaciones, en tiempo de ejecución.

Referencias

Reflexión (informática), Wikipedia.
G. McCluskey. Using Java Reflection, Sun Developer Network.
D. Sosnoski. Java Programming dynamics”, IBM developerWorks. h

Bio

Josué Martínez Buenrrostro (@josuemb) es Sr. Software Architect Java en Quarksoft. Estudió Ing. en Comunicaciones y Electrónica en el IPN y ha desarrollado software profesionalmente por más de 14 años. Es un usuario y promotor activo del Software Libre (FLOSS), y considera que la industria del software puede ser un motor de desarrollo para México con un alto potencial que aún no ha sido explotado.

Pruebas de usabilidad en sitios web

Anonymous — Sun, 22 Aug 2010 19:56:19 +0000

Pruebas de usabilidad en sitios web Anonymous Sun, 08/22/2010 - 14:56

Publicado en

SG #29

Prueba de Software

Autor

La usabilidad se ha convertido en un factor importante de diferenciación en las aplicaciones de software. Como usuarios, cada vez le damos un mayor peso a este elemento. Las pruebas de usabilidad se vuelven cada vez más importantes, a medida que los usuarios buscan mayor satisfacción respecto a facilidad de uso, navegabilidad, adaptabilidad, simplicidad, estética.

¿Qué entendemos por usabilidad?

Si bien es cierto que el término “Usabilidad” no tiene una validez como tal según la Real Academia de la Lengua Española, es ya bastante conocido dentro del medio de TI.

De acuerdo con lo señalado en el estándar ISO/IEC 25010 dentro del cual se identifican características de la calidad del software entre las cuales se encuentra la usabilidad, ésta se define como: “la capacidad de un producto de software para ser entendido, aprendido, utilizado y atractivo hacia el usuario, cuando se usa bajo condiciones específicas”. Es decir que la usabilidad comprende a su vez una serie de atributos del software relacionados con el esfuerzo necesario para su uso, y la valoración individual de tal uso; los atributos que se mencionan tienen que ver con el aprendizaje, la comprensión, la operatividad, y lo atractivo del software.

Al igual que el aspecto funcional, la usabilidad se debe considerar desde el inicio de cualquier proyecto de desarrollo de software. Intentar hacerlo solamente hacia el final del proyecto puede traer graves consecuencias ya que implicará modificar si no todos, sí una gran parte del diseño de interfaces del sistema.

Pruebas de usabilidad

Al igual que con otros aspectos, es importante probar para validar el nivel de usabilidad que muestra un producto de software.

Las pruebas de usabilidad se suelen llevar a cabo observando a las personas mientras tienen bajo uso el producto a probar, y a su vez este grupo de personas es seleccionado considerando ciertas características, según las condiciones que se desean valorar, categorizándolos por ejemplo como usuarios expertos, medios o inexpertos.

Las métricas de usabilidad suelen parecer subjetivas, pues requieren de un juicio individual que dependerá de las circunstancias, del objeto a evaluar o las condiciones bajo las cuales es usado en su valoración. Sin embargo, existen estándares internacionales, normas, guías de comportamiento respecto a los cuales evaluar, así como parámetros que brindan una pauta sobre qué tan “usable” o no es un aplicativo web.

Es deseable (mas no indispensable) contar con un laboratorio de usabilidad para llevar a cabo este tipo de pruebas especiales. El inconveniente es el alto costo que esto puede representar por el equipo que debe montarse para registrar/grabar en video (preferentemente) las actividades de los usuarios y con diferentes cámaras, a fin de ubicarlas desde diversos ángulos, asegurando poder captar las reacciones del usuario durante su experiencia de uso del sistema.

Aspectos de usabilidad a evaluar

Para llevar a cabo pruebas de usabilidad, será importante establecer algunas guías clave que permitan orientar el rumbo del ingeniero de pruebas, permitiéndole capturar información relacionada con aspectos como los que describimos a continuación.

Facilidad de aprendizaje: es deseable que la interfaz sea simple, con funcionalidades accesibles y bien definidas, en general fácil de aprender y de utilizar; asegurarse de que se utilizan guías de estilo, que permitirán alcanzar la consistencia del look & feel del sistema; los usuarios deben ser capaces de trabajar en el sitio web la primera vez sin ningún tipo de ayuda o aprendizaje previos; aAsegurarse que se subrayen los hipervínculos y se maneje el estándar azul como el color para los enlaces no visitados; validar que en las barras de navegación el diseño sea lo suficientemente claro como para que el usuario sepa dónde hacer clic; cuidar que no se utilicen los fondos oscuros y los colores llamativos (a menos que sea la función u objetivo primordial de la página web), evitar además subrayar las palabras, puesto que un usuario podría confundirlas con hipervínculos.

Accesibilidad: validar que sea incluido el manejo de las combinaciones con el comando ALT en las imágenes para hacer los sitios web más accesibles a los usuarios con capacidades diferentes; asegurarse de incluir orden tabular entre los campos para facilidad de navegación durante la selección ó captura obligada de datos; se recomienda que la página web maneje combinaciones de color tales que la lectura no sea difícil, y cuidar el uso de colores rojos y verdes para ayudar a los usuarios daltónicos; asegurarse sobre el uso de alto contraste y fuentes bastante legibles a fin de ayudar a los que tienen menor capacidad visual; validar que se permita al usuario controlar tipo y tamaño de las fuentes para una lectura más cómoda; el sitio web deberá ofrecer contenido alternativo si las funciones de los scripts, applets y plugins no son accesibles.

Flexibilidad: asegurarse que el usuario no tenga que intercalar continuamente entre las acciones de hacer clic y escribir; validar que al usuario se le solicite escribir lo menos posible, máxime cuando existen otras alternativas como un botón de selección o un enlace, lo cual puede además evitar la captura incorrecta de datos.

Tiempo de respuesta: considerar que el tiempo máximo de descarga de una página no sobrepase el máximo aceptable de acuerdo al tipo de operación, considerando una velocidad de conexión promedio de los usuarios.

Reducción de la carga cognitiva: asegurarse de contar con páginas ligeras en contenido no sobrecargándolas con demasiado texto; validar que el usuario pueda acceder a cualquier página en la menor cantidad posible de clics de ratón, preferentemente menos de tres.

Recuperabilidad: asegurarse de considerar los errores del usuario; el sistema debiera incluir una retroalimentación apropiada para informar al usuario y que éste pueda tomar las acciones correspondientes; asegurarse que la página web no sólo muestre mensajes de error útiles, sino que permita al usuario saber dónde está ubicado dentro del sistema, mostrando rutas de navegación.

Buena Imagen y Estética: asegurarse que el sitio web brinda un entorno agradable, a través del cual se facilite el entendimiento de la información presentada.

Métodos de prueba para evaluar la usabilidad
Existe una gran variedad de métodos para evaluar la usabilidad de un sistema de software, o en este caso un sitio web. Entre los más comunes están los siguientes:

Observación en un entorno controlado centrándose en tareas concretas y removiendo la influencia de factores externos.
Observación y análisis de la interacción que lleva a cabo el usuario con ciertos módulos del sistema, con colaboración consciente del usuario.
Observación en el entorno natural.
Evaluación de la estética en general del sistema y en particular de todas las pantallas.
Grabación automática de ciertos escenarios en la interacción usuario-máquina (usualmente grabación en video dentro de un laboratorio con cámaras estratégicamente colocadas).
Entrevistas elaboradas especialmente sobre el uso de un sitio web en particular.
Logging automático en las aplicaciones para el análisis de duración de sesiones y patrones de acciones repetitivas.
Comparación con estándares de diseño y normas.
Uso de “expertos” para evaluar.
Aplicación de cuestionarios.

Tips finales

Finalmente, para cerrar esta entrega, vale la pena mencionar que, al momento de evaluar la experiencia de usuario durante la navegación en sitios web, resulta conveniente considerar, además de los ya referidos métodos y aspectos de Usabilidad, una serie de tips o “lemas” interesantes enunciados por Brad Myers:

Si se ve diferente, debe hacer algo diferente.
Si se ve igual, debería hacer lo mismo.
Es más importante dar poder al usuario, no acelerar el “sistema”.
No sobrecargar los “buffers” del usuario.
Cada acción debería tener una reacción.
Todos cometemos errores, pero todos los errores deberían poder corregirse.
Entre más se hace algo, más fácil debería ser convertirse en experto.
Consistencia, consistencia, consistencia.
El usuario debe estar de buen humor al terminar.
Nada debiera dejarse simplemente “para explicarse en el manual”.
“Bonito/simpático” no son buenos adjetivos para un sistema.
El color es información.
Un gramo de buen diseño vale kilos de soporte técnico.

Referencias

N. Bevan. "Quality in use: meeting user needs for quality", Journal of Systems and Software, Vol 49, Issue 1.
B. Myers. Overview of HCI Design and Implementation.

Bio

Luis Vinicio León Carrillo es Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-fundador. lleon@e-quallity.net

Sandra Berenice Ruiz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba de software. A lo largo de su trayectoria profesional ha actuado como ingeniero de pruebas, líder de proyecto, administradora de proyectos de pruebas, y Directora de Operaciones. Ha sido profesora de la UAG, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

Historia y futuro de la interfaz hombre-máquina

Anonymous — Sun, 22 Aug 2010 19:30:32 +0000

Historia y futuro de la interfaz hombre-máquina Anonymous Sun, 08/22/2010 - 14:30

Publicado en

SG #29

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Frecuentemente nos mostramos maravillados de cómo ha avanzado la manera en que interactuamos con la computadora en los últimos años, sin detenernos a pensar cuánta verdad hay –o no– detrás de esta afirmación. A fin de cuentas, hace apenas unos años el uso de las computadoras era verdaderamente limitado, mientras que hoy en día están en todos lados, y parecería que cualquiera es capaz de manejarlas (al menos, en sus funciones básicas).

Yo sostengo que esta es una afirmación falsa, basada en las apreciaciones de gente ajena a nuestro campo, y producto más de la popularización que de un verdadero cambio cualitativo. Claro está, al poner en duda lo universalmente aceptado, recae en mí sustentar mi afirmación. Vamos, pues, con un breve recorrido de cómo ha evolucionado dicha interacción hasta el día de hoy.

Los inicios

Si tomamos como punto de partida a la primer computadora electrónica ENIAC en 1943, podemos decir que éstas computadoras no tenían nada que hoy reconoceríamos como interfaz —tanto instrucciones como datos eran introducidos directamente a las ubicaciones de memoria al iniciar la ejecución a través de tarjetas perforadas, y eran leídos de los registros del procesador, mostrándolos directamente en un volcado binario, hacia tarjetas o cintas perforadas, que debían ser traducidas a algo legible empleando dispositivos mecánicos independientes.

Teletipos y terminales

El primer avance resultó en una dirección obvia, pero facilitó tremendamente tanto el uso como el aprovechamiento de los resultados: La interfaz textual. No hablo aún de una pantalla, sino de la adecuación del teletipo, híbrido de teclado e impresora, que comenzó su existencia como un reemplazo más ágil y confiable que el código Morse para la comunicación a larga distancia. El teletipo permitía ingresar programas mucho más complejos a memoria, lo cual llevó a que naciera y popularizara un concepto que nos parece muy ajeno a las interfaces de usuario: el de los archivos. Aparecieron los primeros editores (obviamente, mucho más espartanos de lo que conocemos hoy, y orientados a trabajo línea por línea), y como consecuencia directa, los programas pudieron comenzar a presentar una mucho mayor complejidad —llevando a la introducción de bibliotecas de código y a las diversas abstracciones y estrategias para manejar la complejidad.

La transición del teletipo a la pantalla no es tan simple como podría parecer. Dejando de lado la mera complejidad técnica (relativa al estado del arte de la época) de crear dispositivos independientes y de relativo bajo costo capaces de mantener comunicación con la computadora central generando la imagen en pantalla del texto que iban recibiendo —lo cual implicaba que tuvieran una memoria interna, aunque mínima para estándares modernos–, las ventajas de tener terminales con cierto grado de inteligencia se hicieron obvias y comenzaron a aparecer terminales con diferentes estándares capaces de reposicionar el cursor o de desplegar texto con atributos (negritas, subrayado, colores), caracteres semi-gráficos, hasta verdaderas capacidades de formularios como las que manejaban las IBM 3270, que comenzaron a permitir desacoplar la lógica de un programa de su presentación tal como hoy lo vemos en los navegadores Web.

Las terminales además fueron centrales para la aparición de computadoras multitarea/multiusuario. Quienes gustamos de utilizar sistemas Unix utilizamos como una de nuestras herramientas más poderosas al emulador de terminal, o como le dice el resto del mundo, la ventana negra. Si bien las terminales como producto de hardware hace mucho tiempo que ya no existen para propósitos prácticos, la interfaz de línea de comandos programable permite un grado de expresividad tan rico que no ha podido ser reemplazado por ningún otro medio.

WIMP: Window, Icon, Menu, Pointer

En diciembre de 1968, en los laboratorios de Palo Alto de Xerox, Douglas Engelbart presentó la que al día de hoy se conoce como la madre de todas las demos: La introducción de la interfaz gráfica básica que seguimos utilizando hoy en día, manejada a través de un apuntador controlado por un mouse, presentando ventanas para la visualización de las diferentes aplicaciones en uso (o vistas de una misma aplicación), iconos representando atajos a las acciones de sistema disponibles, y con un menú como elemento estándar presentando las acciones relacionadas con cada aplicación activa. Y, claro, para la entrada y manipulación de datos dentro de cada aplicación, el dispositivo primario seguirá siendo el teclado.

La demostración de Engelbart incluía ejemplos de aplicaciones verdaderamente revolucionarias en esa época, como la videoconferencia, el correo electrónico, el hipertexto o un editor colaborativo de tiempo real.

Aunque ha habido refinamientos sucesivos y grandes cambios en la parte estética de esta propuesta, para las computadoras de uso general seguimos utilizando este esquema de interacción —con más de cuarenta años de antigüedad. Es por ello que no considero que hemos avanzado mucho en este ámbito.

Interfaces de propósito acotado

Posiblemente el mayor cambio en las interfaces de usuario viene de que, cada vez con mayor fuerza, tenemos dispositivos con gran poder de proceso de cómputo sin un formato de computadora de propósito general. No me parece casualidad que hoy veamos con entusiasmo a las interfaces innovadoras presentes en teléfonos celulares o consolas de videojuego — estamos llegando al punto en que vamos encontrando formas muy convenientes de interactuar con computadoras de propósito acotado, aunque éstas no sean adecuadas para aquellas de propósito general. Ilustro esto con dos ejemplos:

Con la generación actual de consolas de videojuegos, Nintendo se anotó el mayor éxito al introducir su Wii: Una consola de relativamente bajas prestaciones y muy inferior a su competencia en las áreas en que típicamente competían, la capacidad gráfica. Sin embargo, su apuesta más fuerte fue hacia una interfaz novedosa: Los controles basados en acelerómetros, que permitieron modelar diferentes actividades como nunca antes se habían presentado en videojuegos.

Por otro lado, el iPod de Apple introdujo una interfaz largamente prometida, basada en una pantalla táctil de tamaño reducido, y orientada a equipos destinados al entretenimiento, a la consulta rápida de información, y especialmente popularizada a través del teléfono aparecido poco tiempo después. Sin embargo, si bien esta interfaz ha resultado natural para una gran cantidad de personas, resultaría indudablemente impráctica y antiergonómica para una computadora de propósito general.

Y claro, seguiremos viendo nuevas interfaces dedicadas a tareas específicas — las más exitosas serán, sin duda, las más transparentes: Las que se integren de manera transparente a las tareas, mejorando nuestra vida sin requerir que reparemos siquiera en su existencia. Por ejemplo, ¿cuánta gente está consciente de la cantidad de cálculos que se realizan en un automóvil? ¿No es acaso uno de los mejores ejemplos de cómputo ubicuo que se ha insertado silenciosamente en nuestras vidas?

Otras ideas

Han habido, claro, otras muchas propuestas de interfaces para computadoras de uso general, sin embargo todavía no han madurado suficiente o sólo son aplicables en contextos muy específicos. Algunos ejemplos son:

Pantallas táctiles. Desde mediados de los 1980, Hewlett-Packard introdujo su línea de computadoras HP110, con una pantalla sensible al tacto. Esta interfaz prometía ser más ágil y natural que el mouse (que requiere un nivel de coordinación no trivial). Y si bien esta interfaz tuvo un moderado éxito en áreas como los kioscos (cajeros automáticos, estaciones de servicio), nunca fue del todo aceptada para uso en computadoras de propósito general por lo poco ergonómico que resulta tener que levantar la mano constantemente para apuntar la pantalla.
Reconocimiento de voz. La ciencia ficción de los 1970 (piensen en HAL de 2001) presentó a la voz como la principal forma de interacción hacia la computadora (y un combinación de voz y despliegue en pantallas para los resultados). Se han ensayado interfaces de reconocimiento de voz, pero su uso todavía es limitado, principalmente por la dificultad que presenta el lenguaje humano. Además de esto, fuera de dar comandos puntuales, “dictar” un texto a la computadora no es una tarea trivial: al redactar un texto, el proceso normal que seguimos implica ir hacia atrás y hacia adelante, corrigiendo el texto, reemplazando y reformulando las frases. Una interfaz de dictado debe distinguir el texto de las órdenes, lo cual requerirá un entrenamiento complejo.
Manipulación 3D. Presentar la información como objetos del mundo real, manipulables a través de guantes o gestos, aparece como muy atractivo. Podemos ver un ejemplo muy cuidadosamente desarrollado de una interfaz basada en estas ideas en la película Minority Report. El poder de procesamiento y el hardware especializado para hacer este tipo de manipulaciones, sin embargo, no justifica –al día de hoy– el costo que significaría. Hay aplicaciones, claro, para las que este costo sí se justifica; en México, la Dirección General de Servicios de Cómputo Académico de la UNAM cuenta con la computadora especializada Ixtli para simulación y visualización, y si están interesados en conocer esta tecnología pueden solicitar visitas guiadas donde se demuestra su funcionamiento.

Claro, hay muchas más ideas en el tintero, y en los años por venir seguro se acumularán. Sin embargo, a pesar de las innovaciones que se han dado en dispositivos de uso específico, en el caso de las interfaces para interactuar con computadoras de uso general no ha habido cambios substantivos en los últimos 40 años. Me resisto a creeer que esto sea porque el modelo actual sea perfecto; tenemos la tarea de proponer, adoptar y evaluar nuevos modelos de interacción.

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. www.gwolf.org

El Prisma Lean-Agile

Anonymous — Sat, 21 Aug 2010 19:30:26 +0000

El Prisma Lean-Agile Anonymous Sat, 08/21/2010 - 14:30

Publicado en

SG #29

Agilidad

Autor

Masa K. Maeda

La mayoría de los ejecutivos y líderes a los que asesoro tienen dificultad para terminar sus proyectos a tiempo y dentro de presupuesto, lo cual es frustrante para ellos. Un aspecto que los frustra aún más es el hecho de que los clientes parecen nunca estar satisfechos. Mucho se ha publicado en cuanto a maneras de atacar estos problemas, pero la mayoría de las estrategias se quedan cortas, especialmente en cuanto a la satisfacción del cliente.

Recientemente Jim Highsmith propuso el Triángulo Agile, el cual nos da una base mas sólida para resolver este problema. Yo he propuesto una extensión al triángulo de Highsmith, resultando en un prisma para gestión de proyectos basado en Lean-Agile. En este artículo explico dicha estrategia.

El triángulo de hierro

La teoría tradicional de la gestión de proyectos se basa en el concepto del “triangulo de hierro”. Éste consiste en una descripción gráfica de las tres consideraciones clave para gestionar proyectos: alcance, costo, e itinerario (ver Figura 1). La teoría de este triángulo indica que podemos mantener fijos dos de estos aspectos, pero no los tres (ej. si fijamos costo e itinerario, debemos ser flexibles con el alcance). En la vida real la gran mayoría de las empresas pretenden fijar los tres, por lo que la flexibilidad no es permitida, o es permitida cuando ya es demasiado tarde. Muchos ejecutivos evitan las fluctuaciones porque piensan que es una señal de falla e incompetencia. El resultado es una mala calidad de los productos y servicios resultantes, y quien paga las consecuencias es el cliente.

Figura 1. El triángulo de hierro.

Yo conocí el triángulo de hierro durante un curso de administración de proyectos hace muchos años. Dado que yo siempre he puesto particular interés a la calidad, cuando el instructor terminó su explicación sobre el triángulo le pregunté en qué parte de éste se encontraba la calidad. Él pensó al respecto por un momento y dijo que la calidad estaba en el centro del triangulo de manera implícita. Si eso era cierto entonces, ¿por qué no lo mencionó durante su explicación? Además, la calidad es demasiado importante como para “estar implícita”. Decidí no regresar a ese curso.

Terminar los proyectos dentro de tiempo, costo y alcance no garantiza clientes satisfechos.

El primer triángulo ágil

Poco después de la publicación del manifiesto ágil se creó un nuevo triángulo basado en los valores y principios de Agile (ver Figura 2). Dicho tríangulo considera los mismos elementos que el triángulo tradicional, pero se dibuja de forma invertida, con el alcance en la parte inferior. La forma de interpretarlo es que para que un proyecto sea exitoso se debe fijar el alcance del proyecto y dejar que el costo e itinerario se ajusten adecuadamente. Es decir, los ejecutivos deben permitir el monto de dinero y tiempo necesario para que el alcance se logre. El problema con esta visión es que es difícil de implementar en las empresas debido a la flexibilidad que implica.

Figura 2. El triángulo ágil.

El nuevo triángulo ágil

El costo e itinerario son más bien un impedimento. Casi siempre estamos cortos de por lo menos uno de ellos. El alcance también es un problema porque con demasiada frecuencia los proyectos son muy ambiciosos y terminan siendo recortados. A fin de cuentas esto quiere decir que los tres son de hecho restricciones. Jim Highsmith se dio cuenta que el triángulo agile original es incompleto y propuso uno nuevo (ver Figura 3). Este triángulo tiene calidad como uno de los tres aspectos que considerar. El segundo aspecto son, sin sorpresa, las restricciones: costo, tiempo, y alcance, que deben ser gestionadas de manera tal que se maximicen la calidad y el valor esperado. El tercer aspecto es el mas importante: el valor, el cual es la medida de satisfacción del usuario porque el producto o servicio le da lo que realmente desea y necesita.

Figura 3. El nuevo triángulo ágil.

Cuando leí sobre esta propuesta de Highsmith estuve placenteramente sorprendido y definitivamente concuerdo con ella. Un producto exitoso es aquel que provee el valor más alto posible al cliente. El beneficio para la empresa es la recurrencia de clientes y los inversionistas felices.

El prisma lean-agile

Para entender el razonamiento detrás del prisma lean-agile, primero compartiré con ustedes una historia reciente con un cliente al que asesoré.

Cierto hotel de lujo recientemente me pidió que evaluara el software de automatización de operaciones que habían desarrollado. El sistema desarrollado era bastante completo e incluía aspectos tales como gestión de servicio a cuartos, actividad telefónica, front desk, estacionamiento, lavandería, cajas de seguridad. El gerente de sistemas, llamémoslo Pedro, era el creador del sistema —literalmente— y me mostró lo que había hecho hasta ese entonces. Atinadamente me mostró la funcionalidad en los lugares donde las acciones se llevaban a cabo. Por ejemplo, me llevó al front desk para mostrarme las operaciones que se llevan a cabo ahí y la manera en que el sistema era usado. El tono de su voz durante las explicaciones cambiaba de orgullo a frustración y viceversa. Pedro eventualmente dijo: “no entiendo por qué los empleados cometen tantos errores al usar el sistema si todo está claro, y tampoco por qué me llaman a todas horas del día y de la noche con preguntas innecesarias”. Pedro estaba en lo cierto en cuanto a que la mayoría de los problemas realmente no existían, y en cuanto a que la mayoría de los problemas eran por error humano. Su convicción era que el personal no sabía cómo usar computadoras adecuadamente.

Mi conversación con Pedro ese día comenzó frente a un pizarrón en una sala de juntas, donde él dibujó un diagrama mostrando su estrategia de automatización, incluyendo lo que ya se ha hecho y las perspectivas. Sus planes eran razonablemente sólidos desde el punto de vista técnico. Algunos aspectos que no me gustaron fueron el enfoque reactivo y la falta de atención a la calidad, así como falta de atención a los usuarios. Pedro consideraba que sus sistemas han agregado mucho valor debido al alto monto de automatización y la confiabilidad del código. Sin embargo, los usuarios no estaban satisfechos. Algo faltaba ...

Pedro me llevó alrededor del hotel para mostrarme las diferentes aplicaciones en el lugar donde son utilizadas y con datos vivos. Comenzamos en la zona de registro en el lobby, de ahí las operaciones de uso directo por los clientes, las operaciones a nivel de servicios, y finalmente infraestructura. Yo estaba sorprendido en dos sentidos opuestos. Por un lado, el sistema era muy completo en términos del alcance y profundidad de su funcionalidad. Sin embargo la usabilidad del sistema era bastante mala, consistía en un gran conjunto de ventanas apiladas, todas con apariencia similar, sin una secuencia intuitiva, y con poca tolerancia a error humano. Incluso hubo ocasiones en las que Pedro mismo tuvo que hacer una pausa para determinar el estado de la aplicación y evitar cometer un error mientras me explicaba la funcionalidad.

Entendí por qué los empleados del hotel estaban teniendo tanta dificultad con los sistemas y que Pedro fuera requerido continuamente. Parecía ser que Pedro no se daba cuenta de las causas raíz, pero admitió la necesidad de mejora una vez que se las señalaba. Un área de mejora importante era la calidad; y con eso no quiero decir necesariamente que los sistemas tenían muchos defectos sino más bien que la usabilidad necesitaba más trabajo. La parte que faltaba era un diseño adecuado de la interfase de usuario. La funcionalidad de las aplicaciones era definitivamente adecuada, pero el mal diseño de la interfase de usuario hacía que la funcionalidad fuera de poco valor ya que los usuarios confrontaban todo tipo de retos que resultan en retrasos, errores, frustración, y hasta abandono. El lenguage de una interfase de usuario debe tener coherencia estructural con enfoque en facilidad de uso sin perdida de funcionalidad.

Dejemos a un lado el caso de automatización de hoteles y consideremos un producto de consumo. Usted está buscando por un nuevo teléfono celular y pasa algún tiempo viendo diferentes modelos, buscando el que mejor satisface sus necesidades. Digamos que termina con tres para escoger. Uno de ellos es de bajo precio pero no ofrece toda la funcionalidad que desea; podemos dar ese por eliminado. Los otros dos aparatos tienen todas las características que necesita, tienen el mismo nivel de calidad, y el precio entre ellos es tan cercano que es irrelevante en la decisión. ¿Cuál escogería? El que le gusta más desde el punto de vista de diseño.

Es decir, aquel con el que usted se sentirá mejor sacando de su bolsillo para mostrarselo a sus amigos. Muy probablemente usted escogería el que le gusta más, aún si tuviera mayor costo. ¿Por qué? Porque el diseño innovador le importa a los consumidores y están dispuestos a pagar más por el.

El diseño innovador es importante para los usuarios, tanto como el valor y la calidad adquirida. Poner el diseño bajo la sombrilla de valor le daría menor importancia de la que de hecho tiene—similar a cómo la importancia de la calidad disminuiría si la ponemos bajo la sombrilla de valor.

W. Edwards Deming, quien fue altamente influencial en el desarrollo de lo que actualmente conocemos como Lean, enfatisó la importancia de prestarle atención a tres aspectos: sistemas, gente, y la mejora integral (la perspectiva holística). El pensamiento Lean nos dice que debemos prestar particular atención al valor entregado al cliente, tanto interno como externo. Habrá quienes puedan argumentar que el diseño cae dentro de la categoría de valor, o de calidad. Sin embargo, mi opinión es que eso equivaldría a lo que el triángulo de proyectos hace con la calidad, dándola como implícita. Adicionalmente, Lean pone un gran énfasis en el factor humano (lo que Taiichi Ohno llama “autonomación” o automatización inteligente), simplemente que en lugar de la perspectiva de humanos controlando un flujo de procesos de manufactura, aplicamos el concepto como la satisfacción de usuario interpretada como la motivación que tiene de usar un producto o servicio, más allá del valor que le provee su funcionalidad.

Tomando en cuenta esto, yo propongo que el diseño tenga un lugar explícito en la gestión de proyectos de tecnología, una vista que transforma el triángulo de Highsmit en un prisma, como se muestra en la Figura 4. Nótese que el valor está en la cima porque continúa siendo el aspecto central a considerar.

Figura 4. El prisma lean-agile.

La mayoría de ustedes han de recordar la guerra de los reproductores de música digital poco después de que ésta tecnología fue introducida. La competencia era furiosa y no había un ganador claro que estuviera como líder, hasta que Apple introdujo el iPod. Para ese entonces yo ya había adquirido un reproductor que tenía más características que el iPod y era más barato. Sin embargo, todos mis amigos que adquirieron iPods me dijeron que no les importaba si mi reproductor era “mejor”. Esto muestra como los clientes pueden llegar a darle mayor importancia al diseño y facilidad de uso que a la funcionalidad o el costo.

El diseño no está limitado a la interfase de usuario. Se refiere a encontrar nuevas maneras de hacer cosas tales como crear herramientas, la generación de procesos de desarrollo de software, las estrategias de gestión de proyectos, las actividades relacionadas a calidad, etcétera. El diseño innovador puede contribuir a la reducción de costos, por ejemplo, mejorando la eficiencia de nuestras herramientas y procesos. Lo que deseamos lograr es una evolución continua de la empresa y de los productos o servicios que generamos para mantener a nuestros clientes y empleados felices, y para mantenernos competitivos.

Pedro se tiene que enfocar en mejorar el diseño de sus sistemas de automatización de hoteles si desea darle a sus usuarios el valor correcto. Esto también le traerá beneficio a él mismo, no solo porque dará un mejor servicio sino porque las llamadas de soporte se reducirán significativamente.

Referencias

Project triangle, Wikipedia.
J. Hisghmith. Agile Project Management. Addison-Wesley, 2010.
Autonomation, Wikipedia.

Bio

Dr. Masa K. Maeda es Presidente y Fundador de Shojiki Solutions, una empresa dedicada a ayudar empresas en la adopción y mejoramiento del uso de metodologías Agile-Lean. Tiene más de 20 años de experiencia en la industria de software en Japón, México, y Estados Unidos. Obtuvo el Doctorado y Maestría en Sistemas Inteligentes y Ciencias de la Información en la Universidad de Tokushima en Japón y la Licenciatura en Ingeniería en Computación en la Universidad Nacional Autónoma de México. www.shojiki-solutions.com

Diseño de la Arquitectura

Anonymous — Sat, 21 Aug 2010 18:57:14 +0000

Diseño de la Arquitectura Anonymous Sat, 08/21/2010 - 13:57

Publicado en

SG #29

Arquitectura

Autor

Continuando con nuestro recorrido alrededor del tema de la arquitectura de software, en esta ocasión, nos enfocaremos en la actividad de diseño de la arquitectura.

Diseño y arquitectura
Por extraño que parezca, no existe una definición generalmente aceptada de la palabra “diseño”. Recientemente se ha propuesto la siguiente definición de este concepto:

El diseño es la especificación de un objeto, creado por algún agente, que busca alcanzar ciertos objetivos, en un entorno particular, usando un conjunto de componentes básicos, satisfaciendo un conjunto de requerimientos y sujetándose a ciertas restricciones.

Retomando la definición de arquitectura de software presentada en la primera edición de esta serie de artículos, las correspondencias de los elementos de la definición de diseño con la arquitectura son las siguientes:

El objeto se refiere a las distintas estructuras (físicas, lógicas, de ejecución) que componen a la arquitectura de software.
El agente es el (los) arquitecto(s) de software u otros encargados del diseño.
El entorno se refiere tanto al entorno de uso del sistema, por parte de los usuarios finales, como al entorno en que se desarrolla el sistema.
Los objetivos son la satisfacción de los requerimientos que influyen a la arquitectura (los drivers) y la estructuración con el fin de guiar el desarrollo.
Los componentes básicos son los conceptos de diseño a partir de los cuales se construye una arquitectura y que incluyen patrones de diseño y frameworks de tecnologías particulares.
El conjunto de requerimientos, que se presentaron en la columna anterior, incluyen tanto a los requerimientos funcionales como a los no-funcionales (principalmente los atributos de calidad).
Las restricciones, que también se discutieron en la columna anterior, son todas aquellas limitaciones impuestas ya sea por el cliente o bien por la organización misma de desarrollo.

Diseño guiado por atributos (ADD)
Existen diversos métodos de diseño de arquitectura de software. Uno que provee una guía para realizar el diseño arquitectural de forma sistémica es el Diseño Guiado por Atributos (Attribute Driven Design o ADD), que a continuación estudiaremos.

Este método recibe como entrada una lista de drivers arquitecturales y produce a su salida una serie de estructuras que conforman al diseño de la arquitectura. Se va aplicando de forma iterativa. Los pasos de ADD son los siguientes:

Revisar que se tiene suficiente información sobre los drivers arquitecturales.
Elegir un elemento a descomponer.
Elegir un sub-conjunto de drivers a satisfacer durante la iteración.
Elegir conceptos de diseño para satisfacer los drivers.
Aplicar los conceptos de diseño y asignar responsabilidades a los elementos resultantes.
Definir interfaces para los elementos resultantes.
Verificar la satisfacción de los drivers seleccionados en el paso 3.
Repetir los pasos anteriores para elementos que requieran un mayor refinamiento hasta cubrir la mayoría de los drivers.

ADD es un método que sigue un enfoque de “divide y vencerás”; en la primera iteración del diseño, el elemento a descomponer es el sistema en sí (paso 2). En iteraciones subsecuentes, el elemento a descomponer es un sub-elemento resultante de iteraciones previas. Generalmente se considera que el diseño de la arquitectura termina cuando se han tomado decisiones de diseño para satisfacer la mayor parte de los drivers en el tiempo permitido (pasos 7 y 8).

Conceptos de diseño
Al momento de realizar el diseño, el arquitecto dispone de una variedad de conceptos de diseño que le facilitan la creación de las diversas estructuras que conforman a la arquitectura. En el paso 4 del método, se eligen conceptos de diseño. A continuación describimos a qué se refiere esto.

Un concepto básico de diseño son los patrones de diseño, que son soluciones conceptuales a problemas recurrentes de diseño (tanto a nivel arquitectural como a nivel de diseño detallado). Estos patrones se describen en catálogos que explican, entre otras cosas, el contexto del problema, la solución conceptual y las implicaciones de la aplicación de la solución. Los patrones tienen nombres que permiten referirse a ellos de manera sencilla, algunos nombres son “cliente - servidor”, “capas”, “MVC”, “fábrica” u “observador”. Estos nombres dan lugar a un vocabulario de diseño que facilita la comunicación entre diseñadores. Una vez seleccionado un patrón, es necesario adecuarlo al contexto específico del problema (paso 5). Existe una gran cantidad de catálogos de patrones de diseño y un arquitecto experimentado debe conocer una buena cantidad de ellos o, al menos, saber en donde puede encontrarlos.

Otro tipo de concepto de diseño son los frameworks (marcos de trabajo) enfocados a tecnologías específicas. Estos frameworks, a diferencia de los patrones, no son conceptuales sino que son soluciones a nivel de código que se enfocan en resolver problemáticas particulares tales como la persistencia de objetos en bases de datos relacionales (ej. Hibernate), el soporte de aspectos tales como la seguridad y las transacciones (ej. Spring) o los aspectos de presentación (ej. JSF). Generalmente los frameworks son usados como librerías al momento de desarrollar código. Cabe señalar que los frameworks generalmente encapsulan a diversos patrones de diseño. Al igual que con los patrones, el arquitecto debe conocer una variedad de frameworks y saber dónde aplicarlos.

Existen tipos adicionales de conceptos de diseño que pueden ser usados durante el proceso de diseño, ejemplos de ello son las arquitecturas de referencia, que son diseños completos que sirven de punto de partida, o bien los componentes COTS (Commercial Off-the-Shelf), que son aplicaciones completas listas para ser integradas. Ejemplos de COTS incluyen middleware tales como buses de integración de servicios (ESB).

Un ejemplo
Para ejemplificar la aplicación del método ADD, a continuación mostraremos el resultado de algunos de los pasos del proceso para una iteración del diseño de arquitectura usando como base el ejemplo introducido en la columna anterior. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”.

Para este ejemplo, supondremos que ya se tiene suficiente información sobre los drivers (paso 1), que es la primera iteración, que el elemento a descomponer es el sistema entero (paso 2) y que se ha identificado el siguiente sub-conjunto de drivers para la iteración:

Caso de uso primario: Realizar consultas del catálogo de productos.
Atributos de calidad: Escenario de modificabilidad relativo a la facilidad para agregar nuevos sistemas externos de fabricantes de productos.
Restricción: Uso de librerías y herramientas Open Source.

El siguiente paso (4) indica que debemos elegir conceptos de diseño para satisfacer los drivers. Dado que se tienen escenarios de modificabilidad y que se está en una iteración inicial del diseño, en la cuál se busca crear la estructuración de alto nivel del sistema, se elige como concepto de diseño el patrón de “capas”, que permite agrupar responsabilidades generales del sistema. Por otro lado, se elige el concepto de diseño de “módulos” para agrupar funcionalidades a nivel de las distintas capas y soportar el caso de uso elegido. Finalmente, se opta por aplicar el patrón Inversión de Control para conectar los componentes que estarán contenidos en los módulos y facilitar la integración de nuevos módulos. Este patrón se aplica mediante la introducción del framework “Spring”, que es open source.

Posteriormente, en el paso 5 aplicamos los conceptos de diseño y asignamos responsabilidades a los elementos resultantes. La figura 1 muestra un posible resultado inicial de descomposición de la arquitectura. Durante este paso del diseño, además de aplicar los conceptos de diseño, se asignan responsabilidades a los elementos identificados. Ejemplos de asignaciones de responsabilidades serían:

La capa de integración contendrá el conjunto de elementos que permitirá a la aplicación comunicarse con los diferentes sistemas externos a través de diferentes canales.
El módulo de InterfazCatálogos contiene los componentes que permiten desplegar las pantallas asociadas al caso de uso de consulta de catálogo de productos.

El siguiente paso (6) consiste en definir interfaces para los elementos resultantes. En iteraciones iniciales, las interfaces entre los elementos no se detallan de forma extensa, sin embargo en iteraciones subsecuentes, dichas interfaces deben documentarse de forma más detallada.

Ahora verificamos la satisfacfción de los drivers seleccionados en el paso 3. El primer nivel de descomposición de la arquitectura cubre los requerimientos de la siguiente forma: la solución incluye módulos que permitirán al usuario realizar las consultas al catálogo de productos, adicionalmente la división en capas favorece la modificabilidad. La selección tecnológica también favorece la modificabilidad y se apega a las restricciones. Ver Figura 1.

Figura 1. Ejemplo de descomposición del sistema.

Conclusión
Dadas las limitaciones de espacio, el ejemplo previo y la estructura resultante son muy simples. Es importante señalar que la estructura mostrada tendría que seguir siendo refinada en iteraciones subsecuentes para satisfacer el conjunto de drivers arquitecturales. Por otro lado, como parte del diseño, tendrían que producirse estructuras adicionales para mostrar aspectos tales como la implantación o la interacción de los componentes en ejecución. En este sentido, hay que recalcar que el diseño de la arquitectura no es solo un diseño de muy “alto nivel” que muchas veces es sinónimo de “poco detallado” ya que éste debe ser tan detallado como se requiera a fin de satisfacer la mayoría de los drivers.

Por último, vale la pena mencionar que la idea de documentar las decisiones que se toman durante las actividades de diseño actualmente está cobrando cada vez más importancia. Esta documentación es importante pues permite que posteriormente se evalúe el diseño además de que permite comprender la toma de decisiones del arquitecto al momento de realizar el mantenimiento del sistema.

Referencias
[1] Ralph, P. y Wand, Y., “A Proposal for a Formal Definition of the Design Concept”, Lecture Notes in Business Information Processing, Vol. 14, pp 103-136, 2009.
[2] Wojcik, R. et Al, “Attribute Driven Design (ADD), Versión 2.0”, CMU/SEI-2006-TR-023, 2006.

Bio

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net

La MSc. Edith Valencia es arquitecto de software en la empresa QuarkSoft. Cuenta con más de 10 años de experiencia en la industria de software en México. Obtuvo la maestría con honores en Ingeniería de Software en la Universidad de York en El Reino Unido. Sus áreas de interés incluyen arquitecturas de software, ingeniería de procesos de software y metodologías ágiles. evalencia@quarksoft.net

IT Business Engagement

Anonymous — Sat, 21 Aug 2010 18:37:08 +0000

IT Business Engagement Anonymous Sat, 08/21/2010 - 13:37

Publicado en

SG #29

Autor

Arturo Peña Rodríguez

Tratando de dar una mejor explicación a la traducción del concepto “Engagement”, podríamos relacionarlo con términos como: obligación, compromiso, combate, etc. Pero en definitiva el sentido que se le da en inglés es mucho más amplio que los sinónimos que pudiéramos encontrar en español. Para efectos de este artículo se interpretará dicho término, como la forma de hacer frente a las obligaciones. Actuar en base a “Engagement” es diferente de “actuar en respuesta a”, el término establece una toma de acciones de forma proactiva y no de manara reactiva. IT Business Engagement es entonces la forma en que las Tecnologías de Información se integran al negocio interactuando y haciendo frente a los compromisos y expectativas en un ámbito de correlación.

IT Business Engagement busca lograr alinear las operaciones de TI a los objetivos y expectativas del negocio, creando un mejor entendimiento entre ambos, clarificando las ideas y teniendo un mejor soporte a los objetivos organizacionales. Con esto el área de TI tiene parámetros para la priorización de sus esfuerzos por medio de:

Conocimiento de la percepción del negocio.
Establecimiento de prioridades para el negocio.
Oportunidades para implementar herramientas de TI para crear cadenas de valor.
Creación de canales y formas de comunicación entre ambas partes.

Si establecemos un equipo de combate (business analysts) dedicado a entender y comunicar la estructura y funcionamiento del negocio, lograremos comprender los mensajes encriptados de las áreas del negocio. Tendremos un excelente equipo de traductores, no sólo de un representante, sino de los n representantes del negocio, que normalmente NO hablan el mismo idioma. Por esta razón, es importante considerar el desglose del negocio en términos altamente digeribles y que éstos se conviertan en una guía para que el área de TI cubra las necesidades. La figura 1 ilustra el siguiente desglose:

Estrategia y operación de TI. Es el centro del IT Business Engagement, no es suficiente pensar en alinear la estrategia de TI sino también asegurarnos que la operación está alineada y así evitar discordancia de lo planeado y lo que realmente se hace.
Objetivos de negocio y estrategias funcionales. Una forma errónea para hacer la planeación de objetivos en el área de TI es encontrar solamente una relación entre las iniciativas o servicios de TI y un objetivo de negocio. De ahí la vitalidad de comprender la alineación a las estrategias de todas las áreas.
Expectativas de los clientes. El negocio pide resultados según nuestra planeación, pero las expectativas (un reporte detallado de nuestro actuar) están primordialmente bajo la mira de los clientes, ya sea internos o externos. Si logramos cumplir estas expectativas deberíamos lograr también cumplir con el negocio. Ver Figura 1.

Figura 1. Desglose del negocio

Etapas
Un IT Business Engagement típicamente consta de las siguientes etapas:

Entendimiento. En la alineación debemos verificar que nuestras áreas de TI ya se encuentran en marcha, encontrar la relación de los servicios y proyectos que funcionan actualmente y aquellos que deberán cambiar según las estrategias de las áreas funcionales. En este punto se deben encontrar también coincidencias de servicios y proyectos que soportan más de un área. Dentro de los atributos de TI y la percepción de desempeño se encuentran los dominios de: gobierno, seguridad, confiabilidad, entrega de los servicios, atención de necesidades y oportunidades (proyectos de TI), capacidades del personal y la habilitación del negocio (innovación).
Concepción de la estrategia. Consiste en revisar nuestros servicios (catálogo de Servicios) y manejo del portafolio de proyectos, tomando en cuenta que son las dos principales fuentes de relación entre el negocio y TI. Para salir triunfantes ante tales retos, debemos estar conscientes de la pericia y conocimiento que muestra nuestro equipo en las áreas de oportunidad, procesos, prácticas y base de conocimiento, estas áreas deben ser superadas para evitar que los planes se cumplan a cabalidad.
Entrega y soporte. Además de contar con las mejores prácticas y conocimientos para llevar a cabo los servicios y proyectos ya alineados, la forma de medir, controlar y tomar acciones debe ser también en términos ya pactados con el negocio y sus áreas funcionales, por ejemplo un punto de avance, culminación de un proyecto (servicios podría hacer un time to market, el cumplimiento de la regulación a la que es sujeta el área funcional), etc. Un factor muy importante a considerar es el tiempo de interacción con los encargados del negocio para tratar temas de la estrategia y acciones que impactan los objetivos de los clientes, así como el de cuestionar el valor de los proyectos y servicios en marcha.
Evidenciar. Para el negocio, la cantidad de proyectos cerrados en tiempo o el porcentaje de tiempo muerto de un desarrollo podrían ser irrelevantes pero no si las métricas que se convierten en evidencia de valor y logro de metas funcionales, pues muestra la relación de proyectos ligados a ingresos y el tiempo que un cliente final ahorra (satisfacción de clientes) con las mejoras en el desarrollo de aplicaciones. El usar el término evidencia solo es distinto de las métricas si estas hacen sentido al negocio.

La Tabla 1 refleja los aspectos más relevantes de estas etapas.

Tabla 1. Estrategia y operación de TI apoyándonos en el IT Business Engagement.

Conclusión
Mantener los aspectos citados anteriormente son indispensables al planificar y operar las tecnologías de la información con una ideología del IT Business Engagement. Esta es una lista de puntos importantes en la implantación de Engagement.

Establecer un plan estratégico de TI considerando el Business Engagement:
Adecuación y gestión de los servicios / portafolio de TI de acuerdo al plan y haciendo uso de las mejores prácticas
No dar por sentado que los atributos generalmente asociados a TI se desempeñan de la mejor forma
El seguimiento y la evidencia de los esfuerzos de TI deben ser relevantes al negocio y los clientes relacionados.

Bio

Arturo Peña Rodríguez es Business Unit Manager en Itera, donde se desempeña como líder en arquitectura de soluciones en procesos y gobierno de tecnología a nivel nacional. Su proyecto actual consiste en trabajar en el desarrollo de soft skills para una mejor integración de los equipos de tecnología con el negocio. arturo.peña@iteraprocess.com

Trabajando con stored procedures en SQL Server

Anonymous — Sat, 21 Aug 2010 18:22:40 +0000

Trabajando con stored procedures en SQL Server Anonymous Sat, 08/21/2010 - 13:22

Publicado en

SG #29

Gestión de datos

Autor

Ricardo Rangel

El procesamiento de datos es una de las actividades más arduas a la que nos enfrentamos al desarrollar sistemas transaccionales, especialmente cuando se afectan grandes cantidades de datos. Por medio de procedimientos almacenados, o stored procedures (SP), el sistema de base de datos es capaz de ejecutar un conjunto de instrucciones bien coordinadas entre sí que afectan la información con el fin de lograr un objetivo dentro del sistema.

A continuación comparto algunas técnicas que pueden ser útiles para crear stored procedures confiables con una gran cantidad de instrucciones y gestionar los grandes bloques de información que se ven afectados por estos. Vale la pena mencionar que aunque este artículo utiliza como referencia las capacidades disponibles en SQL Server, la teoría básica y la mayoría de la sintáxis es aplicable a otros manejadores de base de datos.

Catálogo de procedimientos
La primera recomendación es tener un catálogo de stored procedures que nos ayude a tener un listado de los procedimientos con los que contamos. En su forma mínima, esta tabla simplemente tendría Id y nombre del proceso, pero puede extenderse para incluir otra información relevante, tal como desarrollador o fecha de actualización.

IdProceso	Proceso
1	Registro de Comisiones
2	Pago de Comisiones a Vendedores
3	Traspasos de cuentas entre Vendedores

Bitácora de operaciones
Para llevar un registro de qué información es afectada por un procedimiento, podemos crear una tabla de auditoria, en donde se escribirá el Id del Proceso que tuvo que ver con la entrada, eliminación o actualización del registro. Por ejemplo, supongamos que en el cuerpo de nuestro procedimiento para registro de comisiones contiene la instrucción:

INSERT INTO COMISION (IdEmpleado, Comision)
VALUES (@IdEmpleado, @Comision)

Inmediatamente después (y dentro de la misma transacción) podríamos colocar la siguiente instrucción, haciendo referencia a nuestro catalogo de procesos:

INSERT INTO BITACORA_OPERACION (IdProceso, DescProceso, FechaAlta)
VALUES (@IdProceso, @DescProceso, @Getdate)

En donde @IdProceso tiene el valor de 1, y @DescProceso contiene el texto ingresado por el usuario para justificar esta comisión. Esto es muy útil para el seguimiento a información e incluso puede ser un requerimiento de seguridad o cumplimiento de normas en un corporativo.

Evitar la ejecución duplicada
Imaginemos que ejecutamos nuestro procedimiento de calcular comisiones de vendedores y éste introduce la información en una tabla. ¿Qué sucedería si volviéramos a ejecutar el mismo proceso por error? Bueno, no es difícil de imaginar, tendríamos información duplicada. Para evitar esto, podemos apoyarnos en nuestra tabla de bitácora, consultando si nuestra operación ha sido ejecutada recientemente, antes de ejecutarla. A nivel de interfaz, podríamos mostrarle al usuario un mensaje más descriptivo.

Depuración de variables
En caso de no contar con herramientas con capacidades de depuración para stored procedures, se puede usar la instrucción Select para conocer los valores que van tomando las variables al ejecutar el proceso, por ejemplo:

SELECT @Variable AS Variable

Por otro lado, cuando hay una falla en la ejecución del procedimiento, es muy probable que el valor de la variable nos aparezca vacío, por lo que esta instrucción no es muy útil para depurar fallas. En ese caso, la recomendación sería basarnos en el mensaje de error que arroje el servidor de base de datos donde indica la línea de código donde se está dando el error, y entonces utilizar cerca de esa línea la instrucción PRINT para que nos de un valor que permita ejecutar esa instrucción fuera del procedimiento y poder observar lo que está sucediendo.

Por ejemplo si el mensaje de error indica que el Subquery asignado a una variable está regresando más de un valor, podemos hacer un print para conocer los valores que se están usando para armar el query, y detectar el problema.

PRINT @IdEmpleado
SET @VarIdComision =
(SELECT IdComision FROM Comision where IdEmpleado = @IdEmpleado)

Monitoreo de la información
No porque nuestros procedimientos no marquen errores significa que funcionan correctamente. Por ejemplo, si en un procedimiento tenemos la instrucción IF @Variable > 1 y el proceso nunca entra en el IF (cuando se supone que debió haber entrado), entonces hay algo mal. Una herramienta de análisis de código nos ayudaría a conocer nuestra cobertura de código, pero dado que éstas herramientas no son comunes para stored procedures, lo más seguro es que debamos recurrir a monitorear esto manualmente revisando nuestros datos y la bitácora de operaciones.

Bitácora de incidencias
Cuando ocurre algún error en nuestro proceso es bueno anotar en una bitácora por qué se dio el error y cómo se solucionó. En ocasiones, los errores se dan no porque esté mal nuestro proceso sino porque hay una inconsistencia en los datos. Por ejemplo si el proceso busca el Id de un registro con una fecha, pero existen dos registros con la misma fecha, SQL no sabrá cual tomar y el proceso fallará. Así que se toma la acción correctiva correspondiente y se anota en la bitácora para posibles futuras excepciones.

Separación en funciones
Cuando manejamos grandes cantidades de información, es normal que los procesos que desarrollemos tengan una gran cantidad de instrucciones dando como resultado código muy largo. El uso de funciones en SQL permite simplificar el código en ciertas secciones donde necesitemos obtener un valor. Las funciones las podremos invocar una y otra vez desde nuestros procedimientos.

DECLARE @SaldoActualCta Smallmoney
SET @SaldoActualCta = (SELECT dbo.fnc_ObtenerSaldoActualCuentaXIdCta(@IdCtaLote))

Manejo de cursores
Hay quienes argumentan que no es bueno el uso de cursores porque son supuestamente “lentos”, pero considero que hay ocasiones en que es inevitable, e inclusive muy útiles, ya que el uso de cursores nos permitirá avanzar registro por registro y especificar una o varias instrucciones en cada vuelta. Cuando se opte por usar cursores hay que tener cuidado de cerrarlos correctamente, principalmente cuando utilizamos cursores anidados (cursor dentro de otro cursor). Otra cosa a tomar en cuenta es que si se produce un error dentro del cursor, supongamos en un INSERT, cuando manejemos la excepción, también debemos cerrar el o los cursores involucrados. Por otro lado, para avanzar registro por registro no solamente se cuenta con la opción de cursores sino también con la instrucción WHILE, pero seria cuestión de revisar cual de estas opciones se adecua más a nuestras necesidades.

Tablas temporales
Esta es otra arma que tenemos a nuestra disposición al manejar grandes cantidades de información. Las tablas temporales permiten almacenar información temporalmente, de tal manera que podemos hacer uso de ella durante la ejecución de nuestro stored procedure. Recordemos también que existen las llamadas variables de tabla que son similares a las tablas temporales pero utilizan menos recursos y son ideales para almacenar poco volumen de datos. Se recomienda investigar a fondo las diferencias entre ambas opciones ya que su explicación excede el alcance de este artículo.

Disparadores y reglas
Los disparadores (también conocidos como triggers) son objetos de la base de datos que ejecutan acciones cuando se producen ciertos eventos. Por ejemplo imaginemos que a un vendedor inactivo no se le puede asignar una cuenta. Mediante un disparador podremos prevenir esta situación.

Si al ejecutar el procedimiento se da esta situación, entonces aparecerá un mensaje que impedirá que se termine de ejecutar el SP correctamente. Esto es bueno para nosotros, porque es una advertencia de que algo anda mal en nuestro procedimiento. Por otro lado, las reglas (rules) nos permiten establecer ciertos limites a la información. Por ejemplo, imaginemos que el saldo de un vendedor no puede ser menor a 1,000 pesos. Para esto podemos crear una regla.

El uso de disparadores y reglas en la construcción de procedimientos es fundamental. De hecho, se recomienda que antes de programar el procedimiento, se programen todos los disparadores y reglas necesarias. Esto nos obligará a programar el proceso respetando siempre las reglas de negocio preestablecidas. El uso de disparadores y reglas nos garantizara que la información que resulte de nuestros procesos será confiable.

Conclusión
Los stored procedures son fundamentales para el desempeño óptimo de un sistema de información. A los desarrolladores de sistemas de información nos corresponde implementar todo tipo de estrategias y técnicas que nos permitan tener el control de la información y garantizar que ésta sea confiable y precisa. Espero que los tips compartidos en este artículo los ayuden a lograr esta tarea.

Referencias
[1] Solid Quality Learning. Microsoft SQL Server 2005: Técnicas Aplicadas, Microsoft Press.

Bio

Ricardo Rangel Ramírez es Licenciado en Informática egresado de la Universidad de Ecatepec. Ha desarrollado software en plataforma .Net para diferentes empresas. Actualmente labora en el Departamento de Sistemas de Stanhome de México y en proyectos independientes. Sus principales habilidades son la gestión y explotación de información, así como el análisis, diseño y desarrollo de sistemas de información. riccardorangel@hotmail.com