SG #27

Reduce la Complejidad de tus Proyectos de Software

Anonymous — Wed, 24 Feb 2010 02:41:37 +0000

Reduce la Complejidad de tus Proyectos de Software Anonymous Tue, 02/23/2010 - 20:41

Publicado en

SG #27

Gestión de Proyectos

Autor

Jorge Valdés Garciatorres

La disciplina de dirección de proyectos es compleja. Involucra nueve áreas de conocimiento que conforman cinco grupos de procesos. El gerente de proyecto tiene que entender los principios y dinámicas que se dan al trabajar en grupo, el ciclo de vida de las expectativas y cómo administrarlo adecuadamente; además de entender los aspectos técnicos del proyecto y del negocio, también debe tener excelentes habilidades interpersonales, particularmente la de ser un buen comunicador. Evidentemente para una sola persona tener un buen nivel de dominio de todos esos temas es muy difícil.

No somos pocos los que hemos sido parte o hemos presenciado los grandes desafíos que representa el llevar a cabo exitósamente un proyecto de desarrollo de software, donde los módulos o programas hagan todo lo que se espera de ellos de forma confiable, y además se deje satisfechos a todos los actores. En esta entrega quiero compartir contigo algunos consejos para reducir la complejidad de tu proyecto de desarrollo de software, espero que te sean de utilidad.

1. Funcionalidad

Ya sea que se busque mejorar una versión existente de un programa o aplicación, o que se trate de desarrollar una nueva, la recomendación es “menos es mejor”. Entre mayor funcionalidad se incluya en el producto final, el proyecto será más complejo, habrá que tener en el radar mayor número de requerimientos, las pruebas y los casos de prueba crecerán de manera proporcional a las funciones incluidas. Aplicando algunas técnicas ágiles, se puede trabajar muy de cerca con el cliente para poder identificar toda la funcionalidad requerida y hacer una priorización que nos permita entregar funcionalidad básica y a partir de ahí ir añadiendo mayor nivel de sofisticación en versiones subsecuentes.

2. Entregables

Nuevamente, cuando hablamos de los distintos productos que componen el proyecto, debemos tratar de reducir su número para poder contener la complejidad del proyecto. Normalmente, si el número de entregables es mayor, se requerirán múltiples procesos técnicos para producirlos, lo que sin lugar a dudas implica una mayor complejidad. Así que trata de reducir al máximo los entregables de tu proyecto, evidentemente este punto está de alguna forma relacionado con el anterior.

3. Clientes y actores del proyecto

Yo soy un creyente impulsor del proyecto uni-cliente. Aunque esto no siempre es posible, es importante tener en cuenta que entre más gente participe como cliente o actor clave del proyecto, los requerimientos y el enfoque de solución tendrá un número mayor de “puertas” que negociar. La dificultad de poner de acuerdo, administrar las expectativas y comunicar a un grupo de personas respecto a lo que el proyecto (y el producto del proyecto) pretende lograr, crece de manera exponencial; para ello, basta aplicar la fórmula para calcular los canales de comunicación que propone la Guía PMBOK®:

Canales de comunicación = n*(n-1/2)

donde n es igual al número de participantes en el proyecto.

Por eso, es muy recomendable tratar de “negociar” el que haya un grupo reducido de clientes o patrocinadores del proyecto.

4. Duración

Nadie, al menos hasta donde yo sé, tiene una bola de cristal que le diga lo que va a pasar en el futuro. Entre más lejana esté la fecha de término de tu proyecto, más compleja será su administración. Esto es particularmente cierto para la administración de riesgos, pues será más difícil cumplir con las fechas esperadas, y habrá mayor tiempo para que las expectativas crezcan o para que al cliente o a nosotros se nos ocurran mayor funcionalidad. Es así que establecer la duración de tu proyecto en periodos de 4 a 6 meses es una buena idea. Por supuesto que cumplir con los puntos anteriores, sobre todo el 1 y 2 contribuirá a facilitar este punto de manera directa.

5. Tamaño

En términos generales, entre más grande el proyecto, típicamente serán necesarias más interfaces, mayor coordinación, más integrantes en el equipo, y muy probablemente el número de incidentes con los que tendremos que lidiar irán en incremento, tomando más tiempo en la resolución de conflictos. Por ello, en la medida de lo posible será necesario establecer y acotar el alcance del proyecto de manera que cada versión del producto a generar involucre un número reducido de participantes, funciones y entregables.

Habilidades del gerente de proyecto

Aplicar los consejos aquí asentados no es tarea fácil. Sobre todo cuando hay una marcada tendencia en las corporaciones a conducir proyectos que abarcan más áreas funcionales y que quieren dar respuesta a problemas más grandes. Por eso las habilidades del gerente de proyecto para negociar y persuadir al cliente de las ventajas de aplicar, al menos dos, de estos cinco consejos, pueden representar la diferencia para estar más cerca de los objetivos de tiempo, costo, calidad, alcance y cumplimiento de expectativas del proyecto. No olvidemos que, al final del camino... no hay proyecto perfecto.

Bio

Jorge Valdés Garciatorres es Socio Director de la firma de consultoría de negocios TenStep Latinoamérica y Vicepresidente de Desarrollo Profesional en el PMI Capítulo México, es miembro de Toast Masters International en donde es Vicepresidente de Relaciones Públicas en el Club BIAM. Cuenta con más de 20 años de experiencia y tiene las certificaciones de Profesional en Dirección de Proyectos (PMP), la de ITIL Foundations por EXIN y la de Competent Communicator por TMI.

Entre lo Estático y lo Dinámico: El papel del analista y del programador

Anonymous — Wed, 24 Feb 2010 02:31:11 +0000

Entre lo Estático y lo Dinámico: El papel del analista y del programador Anonymous Tue, 02/23/2010 - 20:31

Publicado en

SG #27

Fundamentos

Autor

Ricardo Rangel

Al escuchar la expresión “Programador Analista” es probable que se nos venga a la mente la idea de que es una persona que se encarga de automatizar soluciones a ciertas necesidades de información de una empresa.

Esto es cierto cuando el proyecto es muy simple y es para una tarea muy específica, por ejemplo, para hacer algún cálculo o para exportar cierta información, sin embargo, en proyectos de tamaño normal o grande, por lo general son varias personas las que participan, entre ellas, un programador (o varios) y un analista, es decir las actividades se reparten. En este artículo veremos cual es la función de ambos, principalmente desde un punto de vista inicial y crucial para un proyecto: El diseño.

El papel del analista desde el punto de vista del diseño

El analista se ocupa del sistema desde un punto de vista “estático”, es decir, se encarga de recabar los requerimientos y darle forma a los cimientos y estructura del sistema. Así mismo se preocupa de que las reglas de negocio se cumplan y sean soportadas por la estructura.

El papel del programador desde el punto de vista del diseño

El programador se ocupa del sistema desde un punto de vista “dinámico”, es decir, se preocupa por como los objetos de negocio van a interactuar entre si para la lograr la funcionalidad requerida del sistema dentro de la estructura y reglas de negocio que el analista estableció desde un principio. Podríamos decir que el programador interactúa con los objetos cuando estos ya tienen vida, por lo que normalmente veremos una instancia de objeto, en los diagramas del Programador: Objeto: Clase.

Herramientas de modelado

Para lograr sus objetivos, tanto el analista como el programador deben de hacer uso de técnicas de modelado, una de las técnicas mas comunes es UML. El Lenguaje Unificado de Modelado es un lenguaje estándar para escribir planos de software y permite visualizar, especificar, construir y documentar los artefactos de un sistema.

UML se compone de diversos tipos de diagramas y es aquí donde es fácil confundirse y perderse entre todos los tipos de diagramas y modelos que UML ofrece y preguntarse ¿Cuál es mi papel dentro del sistema? ¿Qué tipo de diagramas debo de hacer? ¿Debo de usar todos los diagramas UML? ¿Como programador, debo diagramar o puedo simplemente empezar a programar basado en los casos de uso? La respuesta a todas estas preguntas es que el analista debe hacer ciertos diagramas y el programador debe de hacer otros tipos de diagramas.

Los diagramas y modelos del analista

Debido a que el analista ve al sistema desde un punto de vista estático, debe de hacer uso de aquellos diagramas que le permitan establecer los cimientos y la estructura del sistema, por lo que los diagramas UML que le servirán para lograr este objetivo son:

Diagrama de Casos de Uso. Es un diagrama de comportamiento que muestra como se relacionan los casos de uso con los actores del sistema.
Detalle de Casos de Uso. Es la descripción de las actividades que debe realizar un caso de uso. Este es quizás el elemento más importante del que hace uso el analista ya que es aquí donde describe en detalle como debe de funcionar el sistema y es el documento en el que se basara el programador.
Diagrama Entidad Relación (Diseño Lógico). Es el diagrama de bases de datos que contiene las entidades y las relaciones entre estas.
Diagrama de Actividades. Es un diagrama de comportamiento que muestra el flujo existente en un conjunto de actividades. También el programador puede usar un diagrama de actividades para aclarar un control de flujo en su codificación.
Diagrama de Despliegue. Es un diagrama estructural que muestra las relaciones entre conjuntos de nodos, artefactos, componentes, etc. Un ejemplo de diagrama de Despliegue es la Arquitectura Cliente-Servidor. El analista es el que debe decidir qué tecnología se va a usar, si el sistema será Web o local, si utilizará la red para transferencia de datos o utilizara archivos planos, etc.

Figura 1. Ejemplo de diagrama de casos de uso

Los diagramas y modelos del programador

En cuanto al programador, debido a que ve al sistema desde un punto de vista dinámico, debe de hacer uso de aquellos diagramas que le permitan observar cómo los objetos se relacionan entre si. Los diagramas UML que el programador podría usar son:

Diagrama Entidad Relación (Diseño Físico). Es el diagrama de bases de datos que contiene las tablas, las relaciones entre estas, tipos de datos, llaves primarias, etc.
Tarjetas CRC. Son una extensión informal de UML y permiten definir responsabilidades dentro de un flujo de eventos. Son muy útiles para diseñar interfaces de usuario.
Diagrama de clases. Es un diagrama estructural que muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Las clases son entidades que contienen objetos conocidos como propiedades y métodos. Las clases son fundamentales para la programación orientada a objetos y se basan en las entidades existentes del negocio.
Diagrama de paquetes. Es un diagrama estructural de agrupación que muestra la organización del modelo en paquetes (Lo que en .Net se conoce como Namespaces para organizar las clases). Sin embargo los paquetes también pueden encapsular otras entidades, como por ejemplo Casos de Uso.
Diagrama de objetos (o de instancias). Representa a un conjunto de objetos y sus relaciones en un momento concreto. Como decíamos anteriormente, el programador convive directamente con los objetos cuando estos ya tienen vida, por lo que este tipo de diagrama le será muy útil.
Modelado de artefactos. Los artefactos en UML son librerías (dll), archivos ejecutables (exe), archivos de código fuente, archivos de datos. El modelado de artefactos permite plasmar la relación que hay entre estos objetos dentro de un proyecto.
Diagramas de secuencia. Muestra los objetos que intervienen en el escenario con líneas discontinuas verticales y los mensajes pasados entre los objetos como vectores horizontales. Muy útil cuando los objetos de varias clases tienen que interactuar entre sí.
Modelado de colaboraciones. Es una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento.
Modelado de interfaces y componentes.Un componente es una parte lógica y reemplazable de un sistema que conforma y proporciona la implementación de un conjunto de interfaces. Una interfaz es una colección de operaciones que sirven para especificar un servicio de una clase o un componente. Esto permite establecer una frontera entre aquellas partes del sistema que pueden cambiar y las que no. Cuando participan varios programadores en un proyecto, las interfaces permiten establecer un punto de partida y obligarlos a utilizar los nombres de los objetos para evitar confusiones.
Máquinas de Estados. Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos.
Patrones y Frameworks. Un framework es una microarquitectura que incluye un conjunto de mecanismos que colaboran para resolver un problema en común. Por ejemplo, cuando se desarrolla un framework para conexión a bases de datos y que contiene todo lo necesario para solicitar datos en conjunto, para ejecutar como comandos como Delete, Update, Insert, etc. Este framework, al ser genérico, podrá ser utilizado en cualquier otra aplicación. Al ser utilizado en varios proyectos, es entonces cuando el framework se convierte en un patrón, es decir, se convierte en una solución común a un problema común: la conexión a bases de datos.

Figura 2. Ejemplo de diagrama de objetos.

Figura 3. Ejemplo de diagrama de secuencia

Desmitificando el papel del analista con respecto a los diagramas

Es curioso darse cuenta al revisar toda esta información de que, el que tiene un abanico más amplio de diagramas y modelos por realizar es el programador y no el analista como podría pensarse. Esto es debido a que el programador trabaja con los objetos cuando estos ya tienen vida, y modelar le permitirá visualizar cómo deben comportarse los objetos antes de codificarlos.

Precauciones al utilizar UML

UML es un lenguaje de modelado muy poderoso que si no se usa correctamente puede inclusive ser contraproducente. Se debe de tener bien claro qué diagramas deben de hacerse y cuales pueden omitirse, y quién los debe hacer. Tomemos en cuenta que hacer diagramas es una tarea que lleva mucho tiempo, por lo que se recomienda usarlos con discreción (con excepción de los diagramas del analista que son fundamentales, no así los del programador).

Mientras que los diagramas del analista tienen por objetivo establecer los cimientos del sistema, los diagramas del programador tienen por objetivo ayudarle a el a comprender cómo deben de interrelacionarse los objetos de negocio para lograr la funcionalidad deseada, por lo que si el programador tiene claro ciertas partes del proyecto, no será necesario que diagrame todos y cada uno de los aspectos de este. UML debe de servir al programador y no el programador a UML.

La relación entre el analista y el programador

Se recomienda ampliamente a las empresas que en sus proyectos de tamaño mediano o grande, no escatimen en recursos y tengan a un analista y un programador (o varios), ya que en el transcurso del desarrollo del proyecto surge una relación muy interesante entre ambos, dando como consecuencia una retroalimentación completa. En cambio si una sola persona esta a cargo de todo, podría perder la objetividad y creer que esta haciendo las cosas bien cuando en realidad puede ser que no sea así.

Por ejemplo cuando el analista le pide al programador desarrollar algo, este al intentar implementarlo podría darse cuenta de que el requerimiento no es factible o que esta incompleto. De hecho, lo mas común es que el programador (que es el que realmente lucha con la aplicación cara a cara) le haga observaciones al analista, este corrige, y le vuelve a pedir el requerimiento, hasta que el programador se da cuenta de que lo que se esta pidiendo esta correcto y es factible implementarlo. Este patrón se repite durante todo el proyecto.

También es común que el analista al revisar lo que el hizo el programador, se de cuenta de que a pesar de estar bien programado, no esta del todo correcto lo que le solicito, y tendrá que regresar a su escritorio a replantear algunas cosas, y darle nuevamente los ajustes al programador.

Conclusión

El modelado es muy importante en el diseño de un sistema para no terminar construyendo una mesa de ping pong cuando en realidad se quería construir una mesa de billar. Sin embargo, los modelos deben de hacerse en base a los objetivos que persigue cada participante en el desarrollo.

Referencias:
[1] G. Booch, J. Rumbaugh & I. Jacobson. El Lenguaje Unificado de Modelado, 2 ed. Addison Wesley, 2006.
[2] J. Gorman. “UML For .Net Developers”. http://parlezuml.com

Bio

Ricardo Rangel Ramírez es Lic. 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, y el Análisis, Diseño y Desarrollo de Sistemas. riccardorangel@hotmail.com

Fomentar el Ingreso y la Permanencia en Carreras de TI

Anonymous — Wed, 24 Feb 2010 01:33:28 +0000

Fomentar el Ingreso y la Permanencia en Carreras de TI Anonymous Tue, 02/23/2010 - 19:33

Publicado en

SG #27

Carrera

Autor

Oscar Rodríguez

En años recientes se ha visto una clara disminución en el ingreso de estudiantes a carreras tecnológicas, especialmente en el área de la computación, así como un alto índice de deserción, lo que ocasiona un problema de falta de personal calificado en áreas de Tecnologías de la Información (TI).

Lo anterior es un hecho a nivel internacional. En el caso particular de México, este fenómeno pone en riesgo las metas de crecimiento económico de muchos sectores de la industria, dada la cada vez mayor necesidad de especialistas en éstas áreas. Partiendo de un análisis de indicadores que podrían dar una idea de las perspectivas en las áreas de TI, buscando hacer énfasis en la importancia de tener más personal calificado en dichas áreas, para finalizar con propuestas de actividades necesarias para fomentar el ingreso y la permanencia en carreras relacionadas con la computación y las TI.

Impacto de las TI en la economía y el mercado de trabajo actual

Cada día es más común escuchar términos como la economía del conocimiento, negocios basados en conocimiento o trabajadores del conocimiento. Estos términos e ideas están cambiando el enfoque de los antiguos modelos, al ver al capital humano como el factor crítico de éxito más importante. La economía del conocimiento es un término que ha sido adoptado para describir a los sectores productivos que muestran un mayor dinamismo y crecimiento originado por la producción y el uso intensivo de la información. Estos sectores difícilmente podrían subsistir sin las TI.

Un dato que resalta la importancia del sector de las TICs en la economía, es el efecto que tiene en los indicadores económicos de un país. Las estadísticas de la OCDE indican que la inversión total no residencial en el sector de TIC se duplicó y en algunos casos se cuadruplicó entre 1980 y 2005, dentro de las cuales el componente de mayor crecimiento fue el software. Otro dato importante son las exportaciones de TIC. En el caso de México, este rubro representó un total de más de 43 mil millones de dólares en el 2005. Sin embargo, como se observa en la Gráfica 1, el crecimiento de México no ha sido tan positivo como el de otros países, siendo China (país no miembro de la OCDE) el país con mayor crecimiento.

De lo anterior podemos observar que las TIC son un sector de alto crecimiento, sobre todo en el caso del software. Asimismo, México no ha explotado su potencial y posición estratégica como vecino del mayor consumidor de recursos de TIC. La actual coyuntura económica puede ofrecer oportunidades que no debemos desaprovechar.

Hoy existe una transferencia de inmigrantes expertos en áreas de alta tecnología desde Estados Unidos hacia sus países de origen, es decir que EEUU está perdiendo “mente de obra” altamente calificada, la cual será necesario suplir una vez que se restablezca la situación económica. Esta puede ser una oportunidad para suplir dichos puestos con personal capacitado en México, o por medio de servicios de outsoursing con empresas mexicanas de alta tecnología. Las oportunidades de crecimiento en el sector de las TIC, ha llevado a que distintos actores del gobierno mexicano realicen esfuerzos por potenciar el desarrollo del sector, tal es el caso del programa PROSOFT de la Secretaría de Economía, que tiene entre sus objetivos la formación de recursos humanos calificados en el área del desarrollo de software. Sin embargo, estos objetivos no podrán cumplirse si no logramos que más estudiantes ingresen en carreras de TI, y sobre todo, que los que ingresen no desistan.

El problema de la baja en la demanda de carreras de TI

Diversas instituciones de educación a lo largo del mundo se han preocupado por la baja en la demanda de carreras de computación, así como en el incremento en la deserción escolar. Esta baja en la demanda ha sido tal, que se estima que el porcentaje de disminución ha estado entre el 70 y 80% alrededor del mundo. Esto es difícil de entender cuando se observan datos como las necesidades actuales y las proyecciones futuras para el sector de las TI, las cuales hacen ver la necesidad de una gran cantidad de recursos humanos especializados en el área.

Las causas de la baja demanda de carreras de TI pueden ser muy diversas. Se ha identificado que un factor importante es el que los estudiantes perciben que no habrá empleos para este sector [3]. También se ha observado que las perspectivas de empleo es uno de los principales factores para elegir una carrera en sistemas de información [7]. Un factor para no elegir estudiar una carrera en Sistemas de Información, es la percepción que los estudiantes tienen sobre las actividades que realiza un especialista en dicha área y la confusión que existe dada la gran variedad de carreras relacionadas con la computación. Otro posible factor relacionado con la deserción, es la dificultad de los estudiantes para aprender a programar es una de las principales causas en la deserción de los mismos [5].

Gráfica 1. Comparativa del crecimiento en exportaciones de TIC de México contra las de Estados Unidos y China.

Por otra parte, algunos especialistas en el sector han observado un comportamiento de altas y bajas en la demanda de carreras de TI que han dependido de dos eventos concretos. El primero fue la introducción de la PC durante los 80s, y el segundo evento fue el nacimiento del Internet y las empresas “punto-com” a mediados de los 90s. No obstante, después de un rápido crecimiento en ambos eventos, se observó una baja acelerada.

Datos recientes muestran que podría estar empezando un resurgimiento del interés de los estudiantes por cursar carreras del área de las ciencias de la computación en Estados Unidos, dado que en el 2008 se registró un aumento en la matricula en programas relacionados con la computación, lo que no sucedía desde hace más de seis años. Dado que las causas de la baja demanda y la deserción escolar en carreras de TI pueden ser diversas, es importante entender cuáles son los factores que llevan a un estudiante a ingresar en una carrera y mantenerse en ella.

Como se observa, la baja demanda y la deserción escolar en carreras de TI es algo preocupante en muchos sectores a nivel mundial. Sin embargo, tomando en cuenta los datos recientes ya descritos, podrían establecerse programas que ayuden a revertir esta situación.

Entonces, ¿qué necesitamos?

El primer punto a considerar es la difusión de la información relacionada con las oportunidades de empleo y remuneraciones que presenta el sector de las TI. No resulta difícil encontrar datos relevantes que hagan ver la importancia de estudiar y mantenerse en una carrera relacionada con el uso, gestión o desarrollo de sistemas de información, dado que este sector tiene la ventaja de ser uno de los de mayor crecimiento en la actualidad.

Por otra parte, la revista Software Guru, anualmente publica los resultados de una encuesta sobre los salarios en el sector del software. De la edición 2007 de dicha encuesta, se observa que se reporta un promedio ponderado de ingreso mensual de $19,946 pesos. También se observa que la mayor concentración (63%) se encuentra en rangos de $7,000 a $25,000 pesos. Siendo sólo el 11.8% los que reportan un ingreso menor a $7,000 pesos, mientras que el 24,2% reporta un sueldo superior a $25,000 pesos. Estos datos sugieren que el sector de profesionistas en software es uno de los mejor pagados en el país, sobre todo si consideramos que el ingreso promedio mensual, según datos del observatorio laboral, fue de $10,330 pesos global durante el 2008.

El sector de las TI presenta oportunidades de desarrollo económico muy interesantes, lo que podría ser un factor importante para convencer estudiantes para tomar una carrera en esta área. No obstante, los beneficios económicos no son todo en la elección de una carrera. También los estudiantes deben sentirse competentes para desempeñarse en la profesión para la que se preparan. En el caso de las TI, parece ser que una de las principales barreras en este sentido es la programación.

Una estrategia de enseñanza de la programación

La enseñanza de la programación ha sido una de las principales áreas de investigación en ciencias de la computación. Sin embargo, parece que los académicos en el área hemos fallado en ésta labor. Al parecer, uno de los aspectos más difíciles de manejar es el entendimiento de grandes porciones de un programa. Uno de los principales aspectos que parece dificultar la programación es el manejo de conceptos abstractos para resolver problemas.

Debemos buscar la manera de enseñar a los estudiantes a pensar sobre el proceso de programación. Podemos considerar que la enseñanza de la programación debe ser un proceso gradual, iniciando por enseñar a los estudiantes a pensar en el proceso de la programación y su utilización para resolver problemas, quizá por medio de algún lenguaje de programación sencillo. Una vez dominado lo anterior, entonces podemos pensar en la enseñanza de lenguajes de programación más potentes y complejos.

Junto con lo anterior, es preciso identificar todas aquellas materias que pueden contribuir para desarrollar las habilidades que podrían hacer que los estudiantes se conviertan en buenos programadores. Dentro de estas habilidades, la capacidad de resolver problemas parece estar entre las principales [1]; y para desarrollar dicha habilidad, la capacidad de abstracción es esencial [4]. Quizá las materias que más contribuyen al desarrollo de estas habilidades son las relacionadas con las matemáticas.

Mostrar la importancia y utilidad de materias clave para el desarrollo profesional

Si bien es probable que algunas de las herramientas que se les enseña a los alumnos no serán aplicadas de forma directa en su desarrollo profesional, muchas de ellas resultan indispensables para desarrollar habilidades necesarias en la profesión. Como ejemplo está el caso de la capacidad de abstracción y resolución de problemas que son de las habilidades que pueden ser desarrolladas por medio de cursos básicos como las matemáticas. Sin embargo, si los estudiantes no están consientes de ello es probable que no aprovechen estas materias de forma adecuada.

Un ejemplo de lo anterior lo presenta Parhami [6], quien describe los esfuerzos que se están llevando a cabo en la carrera de Ingeniería en Computación de la Universidad de California, en donde los estudiantes llevan un seminario introductorio a la carrera, en el que analizan diversos problemas de la vida real en donde las herramientas que aprenderán a lo largo de la carrera pueden ser útiles para resolverlos.

Por su parte, Felleisen y Krishnamurthi [2] van un poco más allá y proponen la alineación de las ciencias de la computación con las matemáticas a nivel de preparatoria de forma que ésta primera se convierta en un tema esencial para todo estudiante. Estos autores proponen ideas de cómo se pueden presentar algunos problemas de algebra para resolver cuestiones de programación.

Para lograr un mayor interés en los cursos que deben llevar los estudiantes de carreras de TI, debemos buscar esquemas que ayuden a mostrar la utilidad de los conocimientos que se adquieren en cada curso, para resolver problemáticas propias de la profesión hacia la cual queremos dirigir a los alumnos.

Conclusion

En este artículo he expuesto algunas ideas que podrían contribuir a reducir la deserción y aumentar el ingreso en carreras de TI. Lograr este objetivo es crítico si queremos alcanzar las metas de crecimiento en el sector de las TI en el país. Sin embargo, si no logramos formar los profesionistas necesarios para ocupar los puestos que se requerirán en el sector, difícilmente se lograrán las metas que tanto el gobierno como la industria se han planteado. Por lo tanto, tenemos un reto que debe ser abordado tanto por la academia como por el gobierno y la industria, el cual es lograr un mayor ingreso y permanencia de estudiantes en carreras de TI. Sin duda el reto no es fácil, pero algo debemos hacer.

Referencias:
[1] C. Cegielski & D. Hall, “What Makes a Good Programmer?”, Communications of the ACM, 49(10), 2006.
[2] M. Felleisen & S. Krishnamurthi, “Viewpoint: Why Computer Science Doesn’t Matter”, Communications of the ACM, 52(7), 2009.
[3] W. Huang, J. Greene & J. Jay, “Outsourcing and the Decrease of IS Program Enrollment”, Communications of the ACM, 51(6), 2008.
[4] J. Krmaer, “Is Abstraction the Key to Computing?”, Communications of the ACM, 50(4), 2007.
[5] B. Manaris, “Dropping CS Enrollments: Or The Emperor’s New Clothes?”, Inroads - SIGCSE Bulletin, 39(4), 2007.
[6] B. Parhami, “Puzzling Problems in Computer Engineering”. IEEE Computer, 42(3), 2009.
[7] C. Scott et al, “More than a Bumper Sticker: The Factors Influencing Information Systems Career Choices”, Communications of the Association for Information Systems, 24, 2009.

Bio

Oscar Rodriguez es Doctor en Ciencias de la Computación y miembro del Sistema Nacional de Investigadores. Profesor-Investigador
de tiempo completo en la división de estudios de posgrado e investigación del Instituto Tecnológico de Hermosillo. Sus áreas de investigación e interés incluyen la Ingeniería del Software y la Gestión del Conocimiento. omrodriguez@ith.mx

Lean-Agile lo mejor de dos mundos

Anonymous — Wed, 24 Feb 2010 00:26:18 +0000

Lean-Agile lo mejor de dos mundos Anonymous Tue, 02/23/2010 - 18:26

Publicado en

SG #27

Agilidad

Autor

Masa K. Maeda

Agile (desarrollo ágil) ha estado resonando en Norteamérica desde mediados de los 90’s. En Asia y Europa se ha estado adoptando por poco más de una década. En Latinoamérica apenas está por alcanzar media década, con Brasil como el país a la delantera, y países como Argentina, Perú y Chile tomando fuerza en buena medida gracias a la cercanía geográfica y la fuerza económica de Brasil.

En México ya existían unos cuantos casos aislados, y en el 2009 aumentó significativamente el interés en distintas industrias aunque todavía hay mucho desconocimiento. Yo, por ejemplo, viviendo en los E.U. pasé en 2009 alrededor de 120 días hábiles en México evangelizando e intentando hacer negocios ofreciendo servicios para la adopción de lean (desarrollo esbelto) y agile. Rápidamente me dí cuenta que todavía se conoce poco sobre agile, y mucho menos sobre lean.Lean se originó en Japón dentro del área de manufactura en los 70’s y gradualmente se expandió a otras áreas tales como gestión, manejo de oficinas, y eventualmente desarrollo de software. Muy probablemente la primer publicación de gran influencia sobre desarrollo de software lean fue el libro titulado “Lean Software Development: An Agile Toolkit” de Mary y Tom Poppendieck [1].

Bueno pero, ¿si agile es considerado lo más novedoso y fabuloso entonces por qué queremos prestarle atención a lean? ¿quiere eso decir que agile es incompleto o no es tan bueno como parecía? Por un lado, agile es altamente compatible con lean (en buena medida los valores y principios agile tienen fundamentos lean), y por otro lado no existe un modelo, estándar, metodología o práctica que sea una bala de plata.

Agile ha demostrado ser mucho más efectivo no necesariamente porque es una nueva receta, sino porque resalta aspectos que habían sido ignorados o se les había prestado poca atención. De manera similar, lean nos ayuda a ajustar el enfoque de lo que es importante para lograr el éxito de los proyectos. Ambos son muy efectivos por si mismos, y juntos hacen una combinación fabulosa.

Lean nos indica que debemos prestar atención a siete factores:

Eliminar todo aquello que genera desperdicio, es decir, que no agrega valor al producto o servicio a generar para satisfacer la necesidad real de usuario.
Aprendizaje sobre el producto o servicio a generar, así como también incrementar el nivel de conocimiento y experiencia de todas las personas involucradas, tanto ingenieros como gerentes, ejecutivos, diseñadores, arquitectos, e inclusive el cliente.
Saber tomar decisiones en el momento adecuado (comparado con tomar decisiones temprano) basándonos en el tipo de pensamiento adecuado.
Entregar productos o servicios de manera temprana en lugar de manera rápida o monolítica.
Darle a la gente poder de decisión mediante auto-organización, liderazgo, motivación y experiencia.
Construir productos y servicios con integridad tanto a nivel de lo que el usuario percibe como a nivel de el producto mismo (la calidad que el usuario percibe y la calidad real).
Considerar el todo. Las mejoras no pueden ser en tan solo un subconjunto de lo que se requiere para generar el producto o servicio, sino en todo lo que comprende al producto y todo aquello requerido alrededor del producto para su creación.

Así como diversas metodologías como Scrum, XP, o FDD surgieron a partir de agile con influencia de lean, la metodología de Kanban surgió a partir de lean con influencia de agile y teoría de restricciones. En contraste con Scrum, por ejemplo, Kanban no requiere de iteraciones, y nos permite tener una visualización más completa del desarrollo la cual permite ver variaciones de manera temprana y por lo tanto tomar acción más efectivamente.

Lean en conjunto con agile nos provee de una serie de herramientas muy poderosas, comenzando con el hecho de que generan un cambio en la manera de ver proyectos, cómo gestionarlos y cómo desarrollarlos.

Nos muestran una forma de ser exitosos sin tener que continuar con los hábitos que consumen recursos tanto materiales como humanos
de manera desmesurada. Son elementos que no podemos darnos el lujo de ignorar dada la situación económica actual.

Lecturas recomendadas:
[1] M. Poppendieck & T. Poppendieck, Lean Software Development.
Addison-Wesley, 2003
[2] M. Poppendieck & T. Poppendieck, Leading Lean Software Development. Addison-Wesley, 2009
[3] A. Shalloway, G. Beaver, J.R. Trott, Lean-Agile Software Development.
Addison-Wesley, 2009.
[4] J. Highmith, Agile Project Management, 2nd ed. Addison-Wesley, 2009.

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

Modularización Efectiva en Java

Anonymous — Tue, 23 Feb 2010 22:30:32 +0000

Modularización Efectiva en Java Anonymous Tue, 02/23/2010 - 16:30

Publicado en

SG #27

Arquitectura

Autor

Agustín Ramos

El software continuamente evoluciona hacia sistemas de mayor complejidad, y no tenemos argumentos para pensar que esta tendencia cambiará. Por otro lado, cada vez se requiere que estos sistemas sean más confiables y flexibles. ¿Cómo podemos abordar este problema?

Una de las herramientas más efectivas para atacar este problema es la modularización. Esta consiste en particionar un sistema de acuerdo a ciertos principios de diseño y a una estrategia de desarrollo, gobernando las dependencias entre las partes resultantes. Sin embargo, implementar una modularización adecuada no es algo trivial; las técnicas disponibles son diversas y no existe consenso sobre cuales son las mejores en cada caso.

Adicionalmente, la modularización en sí misma introduce nuevos retos, entre los que se cuentan la dificultad de configuración y el denominado “infierno de dependencias”.

En este artículo exploraremos el estado actual de la modularización en cuanto a la plataforma Java se refiere y señalaremos algunos principios de diseño, patrones, prácticas y tecnologías que puedes emplear para introducir una estrategia de modularización efectiva en tus desarrollos.

Historia vs Status Quo

A principios de los 70s David Parnas sentó las bases de la modularización en su ensayo “On the Criteria To Be Used in Decomposing Systems into Modules” [1] que tuvo gran impacto en la manera en que construimos software desde entonces. El problema deriva en que, en general, hemos fallado en aplicar de manera efectiva este conocimiento en el software que desarrollamos día a día. Parte de esta falla proviene del hecho de que el software es cada vez más complejo y utilizado en más contextos.

Otra razón tiene que ver con lo que Markus Völter [2] señala como un énfasis en la tecnología en lugar del diseño: una gran cantidad de desarrolladores conocen los aspectos técnicos de la implementación de un EJB o un web service, pero se encuentran muy limitados al establecer criterios de granularidad, agregación y empaquetamiento que proveerán a un sistema con características tan deseadas como la facilidad para realizar cambios. La tercer causa es que los conceptos planteados por Parnas y otros pioneros son aplicados principalmente a nivel de clases y objetos. Sin embargo, el tamaño y complejidad del software desarrollado hoy en día exige nuevos niveles de agregación y una definición de módulo a un nivel de abstracción más alto.

Esta situación ha provocado que surjan esfuerzos para remediarla. Por un lado, un renovado énfasis de los gurús del software sobre buenos principios y prácticas de diseño más que sobre tecnologías de implementación. Por otro lado, el advenimiento de iniciativas como el proyecto Jigsaw [3] para modularizar el propio JDK y la explosión de interés en OSGi [4] como fundamento para implementar arquitecturas modulares sobre la JVM.

Beneficios de la modularización

El impacto principal de una estrategia efectiva de modularización es en la “mantenibilidad” del sistema de software, es decir, qué tan fácil es realizar cambios a éste para agregar y modificar funcionalidad, corregir errores o sustituir partes del mismo. Tal como nos muestra la figura 1, conforme los elementos de nuestro sistema presentan mayor cohesión y menor acoplamiento, tendremos sistemas más fáciles de mantener.

Figura 1. El impacto de la modularidad en los sistemas

La modularización también tiene un gran impacto en la capacidad de reuso de un sistema. Mediante una modularización adecuada es mucho más fácil localizar, cambiar o sustituir un aspecto del sistema, así como utilizar partes del mismo en otras aplicaciones.

Efectos negativos de la modularización

Maximizar la modularización y por consecuencia, el reuso, tiene otros efectos no tan deseables. Específicamente, existe la llamada paradoja
del reuso, la cual se ilustra en la figura 2. Entre más modular y reusable es un diseño, más difícil es usar partes del mismo. Esto se debe a que, a diferencia de un diseño monolítico, donde para usar el sistema simplemente debemos copiarlo o instalarlo en el lugar adecuado, en un sistema modular debemos estar conscientes de las dependencias entre y hacia otros módulos y saber manejarlas adecuadamente.

Figura 2. Maximizar el reuso dificulta el uso.

De no hacerlo, es probable que nos involucremos en lo que coloquialmente conocemos como “infierno de dependencias”, que puede tomar distintas formas:

Demasiadas dependencias. Una aplicación con muchas dependencias puede tener características negativas como dificultad de instalar y configurar, gran tamaño, inestabilidad y fragilidad relativa al cambio de estas dependencias.
Dependencias cíclicas. Se da cuando un módulo A depende de otro módulo B, el cual a su vez depende directa o indirectamente de A. Esta situación denota que no existe una correcta separación de las responsabilidades, ya que siempre que usemos A necesitaremos usar B o viceversa. No hay posibilidad de reuso más que en conjunto. Frecuentemente esto no quiere decir que no pueda existir reuso, solamente que el código no fue colocado en el lugar adecuado para permitirlo de manera más granular.
Largas cadenas de dependencias. Se da cuando una cadena de dependencias transitivas es muy larga. Una dependencia transitiva es aquella que se obtiene de manera indirecta cuando un módulo que utilizamos hace a su vez uso de otros módulos. Al tener largas cadenas de dependencias, puede resultar muy laborioso determinar cuales son todas las dependencias necesarias para poder usar el módulo que realmente es de nuestro interés.
Dependencias en conflicto. Se da cuando queremos usar dos módulos, cada una de los cuales tiene dependencias transitivas hacia versiones específicas pero diferentes de un tercero. En esta situación no podemos simplemente descartar una de las versiones porque, o bien el sistema no compilará, o peor aún, tendrá defectos que no serán visibles hasta el momento de ejecución, pudiendo incluso permanecer escondidos por largo tiempo.

Tener largas cadenas de dependencias o dependencias en conflicto típicamente es consecuencia de reusar componentes genéricos como librerías y frameworks desarrollados por terceros. Dichas librerías a su vez tratan de maximizar el reuso, sobre todo de componentes de bajo nivel, como los usados para el manejo de bitácoras (logging), colecciones, XML, bytecode, etc.

Y para cada una de estas tareas existe una amplia variedad de componentes, lo cual complica aun más la situación. Tener demasiadas dependencias puede ser consecuencia de la complejidad intrínseca del software que estamos desarrollando, pero al igual que las dependencias cíclicas, suele ser consecuencia de un mal diseño.

Algunos de estos problemas pueden ser manejados, al menos parcialmente, mediante ciertas prácticas y técnicas que describiremos más adelante. Pero resulta evidente que intentar hacer uso efectivo de la modularización puede introducirnos más dificultad que beneficios (en la mitología griega, la Hidra es un monstruo policefálico al que tras cortarle una cabeza, le salen dos nuevas). Es por esto que para aprovecharla y no sucumbir ante ella, primero debemos entender qué características son recurrentes en un diseño modular efectivo y posteriormente conocer técnicas que nos permiten llegar ahí.

Características de un diseño modular efectivo

Dividir un sistema en capas es un buen comienzo, pero en la mayoría de los casos no es suficiente. Más allá del tan citado y poco entendido lineamiento de “alta cohesión y bajo acoplamiento”, un diseño modular efectivo tiende a presentar las siguientes características:

Cada módulo tiene un conjunto de responsabilidades muy pequeño y bien definido.
Cada módulo tiene un nombre que permite identificar claramente sus responsabilidades.
Cada módulo provee una inferfaz que define el contrato del mismo en términos de requerimientos y responsabilidades, y es el mecanismo a través del cual puede ser utilizado.
Existen módulos abstractos, con pocas dependencias y altamente estables.
Existen también módulos concretos, que presentan cierto grado de inestabilidad debido a que usan a otros módulos para llevar a cabo el trabajo real. Estos módulos presentan un nivel de cohesión alto.
Existen pocas o ninguna dependencias entre módulos concretos.
Los módulos de alto nivel (capas superiores) tienen dependencias hacia módulos abstractos y pocas o ninguna dependencias hacia módulos concretos.
No existen dependencias cíclicas entre los módulos.
Las responsabilidades bien definidas de los módulos, así como los límites y fronteras entre los mismos, facilitan que los cambios se realicen de manera local, minimizando el impacto en todo el sistema (ver figura 3).
El nivel de granularidad de los módulos es tal que establece un buen balance entre potencial de reuso y facilidad de uso.

Figura 3. La modularización permite localizar los cambios.

¿Qué hace falta?

El concepto de modularización no es nada nuevo. Hoy en día todo desarrollador hace uso de una amplia gama de tecnologías de diseño y programación orientadas a explotarlo, entre los que se cuentan: descomposición en capas, tecnologías de objetos, tecnologías de aspectos, patrones de diseño, etc. Pero mi tesis es que en general hemos fallado en usar apropiadamente estas tecnologías para impartir una buena modularización a nuestros desarrollos y que hacerlo no es trivial debido a los problemas involucrados. ¿Qué hace falta? Guías; guías en forma de principios, prácticas y patrones, tanto de diseño como de estrategias de desarrollo.

Principios de diseño

Una reflexión sobre las características comunes a los diseños modulares efectivos, permite reconocer que son, al menos parcialmente, consecuencia de aplicar correctamente los principios de diseño conocidos en conjunto como SOLID, a un nivel de abstracción mayor que el de clases y objetos. Los principios SOLID fueron popularizados por Robert C. Martin [5], y el acrónimo se forma tomando la primera letra en inglés del nombre de cada principio. Éstos son:

Principio de única responsabilidad: No debería existir más de una razón para que una clase deba cambiar.
Principio abierto-cerrado: Los elementos de software deben estar abiertos a extensiones, pero cerrados a modificarse.
Principio de substitución de Liskov: Las funciones que hacen referencia a clases base deben ser capaces de trabajar con clases derivadas sin saberlo.
Principio de segregación de interfaces: Los elementos de software ‘cliente’ no deben ser forzados a depender de interfaces que no utilizan.
Principio de inversión de dependencias: Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Robert C. Martin indica que: “la unidad de reuso es la unidad de liberación (the granule of reuse is the granule of release)” [6]. En el caso de Java, la unidad de liberación se traduce al JAR, no clases o paquetes, tampoco el WAR o el EAR. El JAR es la unidad de instalación más común en el desarrollo en Java, y el reconocimiento de esto está en el centro del desarrollo de tecnologías que buscan llevar la práctica de la modularización a otros niveles. Es así que en Java debemos considerar que un módulo equivale a un JAR.

Patrones

Kirk Knoernschild trabaja actualmente en un compendio de patrones relacionados con la modularización [7]. Con la aplicación de estos patrones se pretende balancear adecuadamente el nivel de granularidad de los módulos, maximizar el reuso al igual que la flexibilidad y la facilidad de entender el sistema, así como minimizar las dependencias existentes entre los módulos (acoplamiento). Aunque actualmente no están formulados en la estructura convencional de patrones a la que estamos acostumbrados, son muy buena guía, y son patrones en el sentido de que no son invenciones: son soluciones efectivas y recurrentes probadas en la industria. Los patrones son:

Patrones básicos

Administra las relaciones. Se refiere a la práctica de diseñar explícitamente las relaciones entre los módulos, en lugar de dejar que ocurran por accidente.
Reuso de módulos. Enfatiza el reuso a nivel de módulos (JARs).
Módulos cohesivos. Los módulos deben tener un buen nivel de cohesión, de otra manera deberían formar parte de otro módulo o ser módulos separados.
Reuso de clases. Las clases que no son reusadas en conjunto, pertenecen a módulos distintos.

Patrones de dependencias

Dependencias acíclicas. Las relaciones entre los módulos deben ser acíclicas.
Capas físicas. Las relaciones entre módulos no deben violar las capas físicas conceptuales del sistema.
Independencia del contenedor. Considera las dependencias que tienen los módulos hacia el contenedor (e.g. servidor de aplicaciones) y extráelas como dependencias hacia otros módulos abstractos.
Despliegue independiente. Los módulos deben ser unidades desplegables de manera independiente.
Excepciones co-localizadas. Las excepciones deberían estar empaquetadas junto o cerca de las clases que las arrojan.

Patrones de usabilidad

Interfaz publicada. Haz explícita la interfaz pública de cada módulo.
Configuración externa. Los módulos deberían ser configurables de manera externa.
Fachada de módulos. Crea una fachada que sirva como un punto de entrada a los módulos que conforman la implementación.

Patrones de extensibilidad

Módulos estables. Los módulos hacia los que existen muchas dependencias deberían ser estables.
Módulos abstractos. Las dependencias deben ser hacia módulos abstractos o hacia las partes abstractas de los mismos.
Fábrica de implementación. Utiliza el patrón factory para crear las clases de implementación dentro de un módulo.
Abstracciones separadas. Separa las abstracciones de las clases que las realizan.

Patrones de utilería

Compilación nivelada. Ejecuta la compilación y generación del JAR en un orden coherente con la nivelación de los módulos.
Componente de pruebas. Para cada módulo, crea un componente de prueba correspondiente que valida su comportamiento e ilustra su uso.

Estos patrones son explicados de forma práctica en el artículo “Applied Modularity” [8], donde se describe paso a paso la transformación de un sistema con una modularización inadecuada hacia un diseño mucho más efectivo mediante la aplicación sucesiva de varios de estos patrones. Sin embargo, el camino para transformar un sistema legado de gran tamaño hacia un diseño más modular y flexible, en la práctica suele ser más complejo y requiere técnicas más sofisticadas varios de estos patrones. Sin embargo, el camino para transformar un sistema legado de gran tamaño hacia un diseño más modular y flexible, en la práctica suele ser más complejo y requiere técnicas más sofisticadas.

Prácticas

Además de la contribución de Kirk al dar nombre y sistematizar estos patrones, existen otras prácticas que resultan muy valiosas tanto para soportar el desarrollo de sistemas explícitamente modulares como para otros que, aunque semi-monolíticos, hacen uso de software altamente modular. Dichas prácticas son:

Esquema apropiado de versionamiento. Un cambio interno en una versión estable de un módulo debe hacerse explícito mediante su identificador de versión. Los módulos que están atravesando un periodo de desarrollo muy activo y son por tanto altamente inestables, pero son utilizados por otros módulos, deberían marcarse con alguna etiqueta especial como “SNAPSHOT”. Si ya de por sí el tener muchos módulos puede resultar complejo, no usar un buen esquema de versionamiento te traerá muchas dificultades.
Repositorios de dependencias dentro de la organización. Los repositorios de dependencias resuelven, entre otros, el problema de concentrar en un solo lugar las distintas versiones de módulos reusables, internos y externos, así como la estructura de las dependencias entre estos. Con esto se logra quitarle al desarrollador la tarea de averiguar todo el grafo de módulos y versiones de estos que debe importar cuando quiere utilizar una versión específica de un módulo particular, ya que esta información se encuentra en forma de meta-datos dentro del repositorio.
Sistema de compilación integrado con el repositorio de dependencias. El mayor provecho del repositorio se obtiene cuando la herramienta con la cual transformamos el código fuente en artefactos desplegables (JARs, documentación, reportes, etc) está integrada con él. De esta manera, la herramienta de construcción descarga las dependencias conforme son requeridas y puede incluso detectar conflictos de dependencias, ofrecer una solución de los mismos o dejar ésta en manos del desarrollador.

Tecnologías y herramientas

Las tecnologías que soportan las prácticas del diseño modular se pueden clasificar dependiendo del momento en que son efectivas: tiempo de desarrollo y tiempo de ejecución.

En tiempo de desarrollo, los repositorios de dependencias y los sistemas que automatizan la construcción de los artefactos integrándose con estos repositorios son las herramientas más relevantes, siendo Nexus, Maven y Ivy los más populares y maduros. No obstante, en esta categoría hacen falta herramientas más poderosas que ayuden a los desarrolladores a administrar mejor las dependencias. Específicamente, estas herramientas aún no incorporan nociones como “rango de versiones compatibles” o “características proporcionadas por un módulo” que facilitarían enormemente el reuso de módulos.

Otro tipo de herramienta (o extensión de las ya existentes) que hace falta es un administrador de perfiles de dependencias, que le permita a un desarrollador crear, analizar, publicar y mantener configuraciones de dependencias que a veces cuesta tanto trabajo hacer funcionar bien, debido a incompatibilidades entre los módulos. En las tecnologías para modularización usadas en tiempo de ejecución ya tenemos un estándar de facto: OSGi.

OSGi

OSGi es la especificación de un sistema dinámico de módulos para Java. Tiene una larga historia que comenzó en el mundo de los dispositivos embebidos y la automatización, pero que gradualmente ha penetrado en otros mercados, incluido el de las denominadas aplicaciones empresariales (término que no me parece adecuado, pero la mayoría parece entender a qué se refiere). OSGi no solo proporciona un entorno de ejecución en el cual una aplicación modular puede ser desplegada, versionada y administrada, sino que permite que cada módulo tenga un ciclo de vida independiente, dando una capacidad dinámica que habilita a toda una nueva generación de aplicaciones.

Al día de hoy, los principales fabricantes de servidores de aplicaciones y ESBs (Enterprise Service Bus) ya adoptaron OSGi como fundamento sobre el cual construir las últimas versiones de sus ofertas o están en proceso de hacerlo. Estos mismos fabricantes se encuentran trabajando en “completar” OSGi con las capacidades que la mayoría de los desarrolladores necesitan (transacciones distribuidas, manipulación de bytecode para utilizar aspectos, tecnologías ORM, etc), a través del OSGi Enterprise Expert Group.

En general, aún no se recomienda a la mayoría de los desarrolladores de aplicaciones utilizar OSGi de manera directa, debido a la complejidad intrínseca, la falta de herramientas que ayuden a enfrentarla y a que tecnologías a las que los desarrolladores están habituados no son sencillas de usar dentro de OSGi o sencillamente aún no están disponibles. Sin embargo, eventualmente todos los usuarios de Java Enterprise Edition nos beneficiaremos indirectamente de OSGi, y de requerirlo, también podremos explotar directamente sus beneficios. Ejemplos concretos de esto son la versión Open Alpha de Websphere 7 y Spring DM Server.

Conclusiones

La modularización es un aspecto que debemos tener presente en nuestros desarrollos. Es un tema clave en lo que a mantenibilidad y reuso se refiere. Implementar una estrategia de modularización efectiva no es sencillo y aún falta mucho soporte de herramientas, pero cuando se logra, los beneficios obtenidos superan el costo involucrado.

La plataforma Java continúa moviéndose rápidamente hacia sistemas altamente modulares a través de la enorme cantidad de componentes reusables que existen y a través de tecnologías que promueven y explotan el reuso, en desarrollo y tiempo de ejecución. No obstante, el uso de herramientas y tecnologías como OSGi no son la solución completa ni el aspecto más importante para una modularización efectiva: el diseño continúa siendo la clave.

Referencias:
[1] D. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, Communications of the ACM, vol.15, 1972.
[2] M. Völter. “Software Architecture Patterns”. http://bit.ly/sg27r7
[3] Project Jigsaw, http://bit.ly/sg27r8
[4] OSGi Alliance, http://www.osgi.org
[5] R.C. Martin, “The Principles of OOD”. http://bit.ly/sg27r9
[6] R.C. Martin, “Granularity”. http://bit.ly/sg27r10
[7] K. Knoernschild, “Modularity Patterns”. http://bit.ly/sg27r11
[8] K. Knoernschild, “Applied Modularity – Part 1”. http://bit.ly/sg27r12

Bio

Agustín T. Ramos Fonseca se desempeña como ingeniero de software en Certum. Tiene 7 años de experiencia en el desarrollo de aplicaciones corporativas y es miembro de la IEEE y ACM. Sus intereses se centran en servicios internet altamente escalables, plataformas para sistemas transaccionales masivamente distribuidos, servicios móviles y geoposicionales, así como líneas de productos y arqueología de software. @MachinesAreUs

Estrategia Corporativa de Seguridad

Anonymous — Tue, 23 Feb 2010 15:42:43 +0000

Estrategia Corporativa de Seguridad Anonymous Tue, 02/23/2010 - 09:42

Publicado en

SG #27

Seguridad

Autor

Ariel Sucari

Hace pocos años las noticias en las secciones policiales de los periódicos del mundo lucían muy distintas a las actuales. Podíamos ver cosas tales como: “Gran robo a un banco perpetrado por comando fuertemente armado” o “Haciéndose pasar por empleados de limpieza, roban asombrosa cantidad de dinero y joyas”. Hoy en día los titulares se ven bastante distintos, en un mundo en donde el fraude digital crece a una tasa escalofriante del 300 por ciento anual, podemos leer: “Hacker sube datos personales de 6 millones de chilenos a internet para demostrar lo mal protegida que está la información en su país” o “Hacker roba más de 130 millones de números de tarjetas de crédito y débito”. Aunque las noticias de los robos físicos todavía existen, la última estadística de la Federal Trade Commission dice que, del monto robado en Estados Unidos el año pasado, el 94% fue digital.

Los principales factores que facilitan esta modalidad de robo son:

Riesgo. Las empresas desconocen por completo qué tan fácil o difícil es acceder a su información, por lo tanto no definen una clara estrategia para defenderse.
Gasto. Del gasto total en seguridad, las empresas solo gastan un 10% para proteger la seguridad de sus aplicaciones, mientras que el otro 90% lo gastan en proteger la seguridad perimetral. Conociendo esto, los Hackers eligen atacar a través de las aplicaciones, haciendo que el gasto de las empresas esté totalmente desbalanceado. De hecho, el 75% de los ataques se dan por medio de las aplicaciones.
Experiencia y capacitación. El 64% de los desarrolladores no confía en sus habilidades para desarrollar aplicaciones seguras. Esta métrica hace que 2 de cada 3 aplicaciones sean vulnerables.

Para vencer a los hackers de una manera estratégica, las empresas se están enfocando en 3 aspectos fundamentales: procesos, herramientas y capacitación.

Es importante aclarar que las tres cosas deben ir juntas, pues si implementamos procesos sin herramientas, nos quedamos en una solución netamente académica. No nos sirve de nada tener el mejor de los procesos, si no logramos automatizar las prácticas con herramientas.

Por el contrario, si sólo implementamos una herramienta (sin proceso), lo único que estaremos haciendo será automatizar el caos; por último, pero no menos importante, si tenemos un proceso automatizado con herramientas, sólo nos resta que nuestra gente sepa utilizarlo para beneficio de la organización, para lo que deberemos capacitarlos y prepararlos para su uso.

Procesos

La clave en este punto es integrar las prácticas de seguridad al proceso de desarrollo. Si nos ponemos a escribir un proceso de seguridad sin tener en cuenta el proceso actual de desarrollo, lo único que haremos será perder el tiempo, pues el cambio entre una manera de trabajar y la otra será tan grande que nadie la adoptará.

El problema aquí es que hay pocas personas o consultorías con experiencia en el mercado que cuenten con la habilidad para integrar estos procesos, ya que se requiere conocer, tanto de desarrollo de software como de seguridad de TI. Afortunadamente las que pueden hacerlo ya se han abocado a esta tarea con grandes resultados.

En la figura 1 muestro un ejemplo gráfico de esta consolidación, donde pueden verse en la parte inferior las prácticas de seguridad y en la superior las típicas de un proceso de desarrollo de software.

Figura 1. Prácticas de seguridad y desarrollo de software.

Herramientas

En el mercado actual de herramientas de desarrollo de software seguro, existen varias opciones buenas. Más que recomendarles aquí alguna en específico, lo importante es recalcar la importancia de contar con al menos alguna de ellas.

Si nosotros le preguntáramos a cualquier persona si concibe revisar manualmente que su máquina está infectada de virus, sin utilizar una herramienta (antivirus), su respuesta sería un NO inmediato.

Sin embargo, mucha gente todavía no comprende que suena igual de descabellado pretender revisar que las aplicaciones de una empresa sean seguras, sin utilizar una herramienta especializad que lo compruebe.

La clave para involucrar a todo el equipo de TI en esta lucha contra el delito, es contar con una herramienta que nos permita integrarlo y hacerlo trabajar de acuerdo al proceso definido, moviéndonos de manera paulatina desde la etapa uno, a la etapa 3 mostrada en la figura 2.

Figura 2. Fases de implantación de una estrategia corporativa de seguridad.

En la fase 1, el área de seguridad no puede con todo el trabajo y la cobertura de aplicaciones probadas es muy baja. En la fase 2, se define un proceso que asigna responsabilidades a las áreas de calidad y desarrollo de la empresa y se coloca una herramienta que permita darles visibilidad acerca de la cobertura y los progresos. Por último en la fase 3, seguridad juega el rol que realmente le corresponde: Definidor y auditor de las políticas; mientras que los equipos de calidad y desarrollo ejecutan las prácticas de seguridad que ya tienen inmersas en sus respectivos procesos de manera automatizada.

De esta manera la cobertura de aplicaciones probadas es mucho mayor a la de la fase 1 y el esfuerzo queda distribuido entre todo el equipo de TI. Al momento de buscar una herramienta, debe buscarse una que pueda utilizarse por desarrolladores, auditores, oficiales de seguridad y testers; además de que la misma cubra las técnicas de prueba tanto de caja negra como de caja blanca.

Capacitación

El último eslabón de la cadena, y a su vez el más importante, es la capacitación. Una vez que el proceso está diseñado y las herramientas instaladas y configuradas, lo que resta es que la gente de la organización los utilice. Para esto, debe hacerse un despliegue organizacional y una gestión del cambio adecuados acompañados de una capacitación. La solución entonces, se dice completa y exitosa.

Conclusión

El camino hacia las aplicaciones seguras no termina nunca, pero en cada organización decidimos en qué parte del camino queremos estar. Podemos avanzar hacia conocer nuestros riesgos y administrarlos, o quedarnos parados y rogar porque el próximo ataque no sea hacia nosotros.

Bio

Ariel Sucari es director de operaciones de la subsidiaria en Madrid de ItEra. Es graduado como maestro en negocios e Ingeniero en Sistemas, ha participado y coordinado proyectos de ingeniería del Software en Inglaterra, Estados Unidos, Argentina, Venezuela, Perú, España y México durante los últimos 10 años. Actualmente desarrolla nuevas ofertas de seguridad de la información que son divulgadas en conferencias, publicaciones y seminarios. ariel.sucari@iteraprocess.com

Arquitectura de Software

Anonymous — Mon, 22 Feb 2010 21:50:26 +0000

Arquitectura de Software Anonymous Mon, 02/22/2010 - 15:50

Publicado en

SG #27

Arquitectura

Autor

Humberto Cervantes

En el ámbito del software cada vez es más común escuchar el término “arquitectura de software”, y encontrar oportunidades de empleo para “arquitectos de software”. Aún así, este concepto tiende a ser malentendido y la falta de comprensión al respecto de sus principios frecuentemente repercute de manera negativa en la construcción de sistemas de software.

El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo. Al igual que en la ingeniería civil, las decisiones críticas relativas al diseño general de un sistema de software complejo deben de hacerse desde un principio. El no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el producto final satisfaga las necesidades de los clientes. Además, el costo de las correcciones relacionadas con problemas en la arquitectura es muy elevado. Es así que la arquitectura de software juega un papel fundamental dentro del desarrollo.

¿Qué es la arquitectura de software?

Antes de elaborar sobre el tema, es conveniente definir el concepto ya que hoy en día el término de arquitectura se usa para referirse a varios aspectos relacionados con las TI. De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos.”[1]

El término “elementos” dentro de la definición del SEI es vago a propósito, pues puede referirse a distintas entidades relacionadas con el sistema. Los elementos pueden ser entidades que existen en tiempo de ejecución (objetos, hilos), entidades lógicas que existen en tiempo de desarrollo (clases, componentes) y entidades físicas (nodos, directorios). Por otro lado, las relaciones entre elementos dependen de propiedades visibles (o públicas) de los elementos, quedando ocultos los detalles de implementación. Finalmente, cada conjunto de elementos relacionados de un tipo particular corresponde a una estructura distinta, de ahí que la arquitectura esta compuesta por distintas estructuras.

¿Por qué es importante la arquitectura de software?

La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición deba transitar por muchos componentes antes de que se devuelva una respuesta podría tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los componentes estén altamente acoplados entre ellos limitará severamente la modificabilidad. Curiosamente, la estructuración tiene un impacto mucho menor respecto a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los requerimientos funcionales que se le imponen.

Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto.

Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos.

El ciclo de desarrollo de la arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, esta dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo.

A continuación se describen dichas etapas.

Requerimientos. La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones.

Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías por que están “de moda”.

Documentación. Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama.

Evaluación. Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.

El rol de arquitecto

Las actividades descritas anteriormente requieren de habilidades particulares que son la responsabilidad del arquitecto de software. El arquitecto es un líder técnico que debe conocer los principios relacionados con la arquitectura de software, tener un amplio conocimiento respecto a la tecnología, y tener excelentes habilidades de comunicación escrita y oral.

Desafortunadamente, en la actualidad pocos arquitectos de software que laboran en la industria han recibido una formación teórica respecto al tema. Esto se debe a que no es sino hasta épocas recientes que se han establecido de manera más formal los conceptos relacionados con la arquitectura de software, y que actualmente pocas instituciones ofrecen cursos enfocados en el tema. El desconocimiento de los principios relativos a la arquitectura de software frecuentemente impacta de manera negativa a los proyectos de desarrollo.

Apenas empezamos

A lo largo de las distintas entregas de esta columna que inicia se buscará dar una panorámica del tema de arquitectura de software y se discutirá de manera más detallada aspectos como:

requerimientos que influyen en la arquitectura,
el diseño, documentación y evaluación de la arquitectura,
los retos relacionados con la introducción de prácticas de arquitectura de software en un contexto organizacional,
la arquitectura de software dentro de las metodologías de desarrollo,
el perfil del arquitecto de software.

Referencias:

[1] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd Edition, Addison Wesley, 2003

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. Actualmente está en camino a obtener la certificación “Software Architecture Professional” por parte del Software Engineering Institute.
www.humbertocervantes.net

Creación de Software en México: ¿Estamos educando creadores de software?

Anonymous — Mon, 22 Feb 2010 21:12:07 +0000

Creación de Software en México: ¿Estamos educando creadores de software? Anonymous Mon, 02/22/2010 - 15:12

Publicado en

SG #27

Columna invitada

Autor

Marco A. Dorantes

El microprocesador digital ha resultado ser una pieza de tecnología de enorme impacto en la sociedad. Al parecer, apenas estamos empezando a descubrir la punta del iceberg en cuanto a las aplicaciones de cómputo digital y las implicaciones de éste en nuestras sociedades. Como otros avances tecnológicos, las computadoras son objeto para la creatividad y para el consumo masivo, o por lo menos eso es lo que se pretende, y no parece haber marcha atrás.

Las computadoras, como herramientas, se sitúan al lado de otras herramientas tecnológicas como el microscopio o el telescopio, sobre las cuales —cuando se tiene el conocimiento para usarlas— podemos apoyarnos para enfocar nuevos y diversos cuadros de la realidad.

Pero, ¿cómo están tomadas las posiciones para la creación de software internacionalmente y en México en particular? ¿Quiénes están ubicados y bien apuntalados en sus posiciones como creadores de software y quiénes han elegido una posición tan solo de consumidores del mismo? No falta quien opine que en México sí estamos creando software y que sí estamos preparados para seguir haciéndolo, y haciéndolo bien, que sí vamos por buen camino o que ya están puestos los trazos hacia un mejor desempeño de las futuras generaciones en esta área.

En la parte de la realidad que alcanzo a observar, no hay bases para sostener tal opinión. Encuentro, de ordinario, un entusiasmo falaz que disemina un sentido de autocomplacencia que cancela el cuestionamiento y la autocrítica sobre nuestra posición real en el panorama mundial en cuanto al diseño de software. Encuentro a veces un frenesí por consumir software, para sólo ostentar lo de moda o hablar de ello, como único fin, pero muy poco acerca de crear software que entregue valor directo y sensible al usuario final. Ese, quien no tiene otra opción que tolerar la absurda excusa “no hay sistema” como respuesta estándar ante la incompetencia de quien pretende emplear tecnología de software para proveer productos o servicios sin diseñar mejores procedimientos organizacionales y mejores sistemas informáticos.

La situación es deprimente al escuchar a quienes están en posiciones de liderazgo en esta área —dentro de instituciones académicas y también en empresas del ramo— y sus opiniones al respecto están basadas exclusivamente en información proveniente ya sea de la mercadotecnia o de erradas analogías con otras industrias como la industria de la construcción o de la manufactura de principios del siglo pasado. ¿Cuál es el mensaje implícito que hacen llegar a quienes los escuchan buscando dirección profesional? El cuadro es realmente patético al observar los esquemas que se proponen y se autorizan para la preparación del personal técnico que supuestamente estará a cargo de la supervisión y creación de soluciones de negocio basadas en software.

Dichos esquemas se adscriben fielmente a los sistemas tradicionales de escolarización y adoctrinamiento de masas, donde la memorización mecánica, control del pensamiento y ambiente carcelario han inspirado históricamente expresiones artísticas cuya aparente exageración nos espolea hacia la reflexión: ¿Cuáles son las condiciones para la creación de mejor software?

La preparación que resulta necesaria para la creación de mejor software suele tomar sendas poco populares en México, rumbos en las dimensiones del capital humano, los procesos de desarrollo, el diseño lógico, y las herramientas tecnológicas. Tan sólo en la dimensión del capital humano, obras como Peopleware [1], The Peopleware Papers [2] y Software for Your Head [3], nos ayudan a entender que el impacto que tiene sobre los resultados el perfil del personal es de un orden de magnitud muy superior al del resto de los factores.

En pocas palabras: el impacto relativo al proceso de desarrollo o a una arquitectura particular será, a lo mucho, marginal si está ausente el personal adecuado para sacar provecho de dicho proceso de desarrollo o para evolucionar dicha arquitectura. Esta área de actividad —cuya demanda parece que permanecerá— también requiere una mejora continua del estado de conciencia, tanto en quienes buscan aplicar el software a problemas reales como quienes pretenden proveer los servicios profesionales para crear soluciones basadas en software a dichos problemas, elevando las expectativas de educación en ambas partes.

De otro modo, con las expectativas de educación y preparación actuales, no veo otro panorama futuro mas que la continuación del conformismo, donde los clientes y proveedores de sistemas informáticos se deberán conformar con los sistemas que merecen. ¿Hay sólo una manera correcta para crear soluciones de negocio basadas en software? ¿Qué diferencia hay entre quienes responden afirmativamente a esa pregunta y quienes abrazan al dogmatismo como modelo estándar de vida? ¿Qué acaso lo que impone la realidad no es suficiente para adoptar valores, principios, patrones y prácticas que coloquen al aprendizaje continuo en el centro de nuestros proyectos en lugar de pretender que nuestra industria es igual a otras, e.g. ingeniería civil, y que debe funcionar con premisas fundamentales, métricas de desempeño, y demás políticas, similares?

¿Qué forma entonces podrá tener una estrategia plural de preparación para proyectos de creación de soluciones de negocio basadas en software? Sugiero poner atención a lo que han propuesto practicantes como Gerald M. Weinberg en su serie Quality Software Management [4]; de cuya influencia y síntesis actual se ha derivado el Manifesto for Agile Software Development[5]. Pero teniendo cuidado de no errar por la inercia de tomar las buenas ideas como si fueran dogmas permanentes; al contrario, insertando modelos de adopción en los cuales siempre esté presente el sentido de aprendizaje y de adaptación a nuevas condiciones de contexto. Por cierto, precisamente ese patrón adaptativo y de aprendizaje es parte de la esencia fundamental del manifiesto para el desarrollo ágil de software, desde sus inicios.

El mapa de las habilidades necesarias para presentarse muy bien equipado en un proyecto de creación de soluciones de negocio basadas en software ha estado ahí por ya largo tiempo. ¿Qué vas a hacer al respecto estimado lector? ¿Esperar a que alguien más te dicte qué pasos dar en tu carrera profesional la cual, ya sea como usuario o proveedor, con mucha seguridad se verá transformada positiva o negativamente por un empleo adecuado o descuidado de la tecnología de software? ¿Qué caracteriza tu plan de preparación técnica: el cortoplacismo y la continuación de los mismos patrones problemáticos populares, o la progresión en cada vez mejores niveles de entendimiento y aprendizaje?

Se hace relevante la reflexión acerca de esa tan mencionada palabra: educación. ¿Qué es la educación? ¿Dejaremos que se mantenga como sinónimo de escolarización y adoctrinamiento, como dice la canción “…No necesitamos educación, no necesitamos control mental…” o atenderemos las advertencias que nos hacen personas como Denise Dresser al referirse a un "México Amurallado" [6]?:

“México, el país donde en la escuela pública se aprende poco de ciencia, pero se aprende mucho de sometimiento; se aprende poco de tecnología, pero se aprende mucho de simulación; se aprende poco de álgebra, pero se aprende mucho de cumplimientos mediocres, negociaciones injustas y beneficios extralegales.”

Referencias
[1] T. DeMarco & T. Lister, Peopleware, 2nd ed. Dorset House, 1999.
[2] L. Constantine, The Peopleware Papers, 2nd ed. Prentice Hall, 2001.
[3] J. McCarthy & M. McCarthy, Software for your Head. Addison-Wesley, 2002.
[4] G. Weinberg, Quality Software Management, Vol 1-4. Dorset House, 1991-1997.
[5] Agile Manifesto. http://agilemanifesto.org
[6] D. Dresser, “México Amurallado”, . https://youtu.be/vI2YWd33rZY

Bio

Marco A. Dorantes es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software. http://blogs.msdn.com/marcod

Voto Electrónico: Analizando su conveniencia

Anonymous — Mon, 22 Feb 2010 19:54:34 +0000

Voto Electrónico: Analizando su conveniencia Anonymous Mon, 02/22/2010 - 13:54

Publicado en

SG #27

Programar es un Estilo de Vida

Autor

Gunnar Wolf

El tema de la votación electrónica comienza a sonar nuevamente en el debate político de nuestro país. De prosperar la discusión, toda decisión respecto a su implementación implicará sin duda a los expertos en desarrollo y medición de calidad de software de nuestro país. Adelantánadonos a los hechos, analicemos brevemente lo que esto significaría para nuestra sociedad.

Contrario a lo que muchos esperarían, los promotores de la concientización en seguridad en cómputo somos los primeros en recalcar que los fallos –conceptuales y de implementación– hacen que las estaciones computarizadas de emisión y contabilización de votos sean, desde su planteamiento, una causa perdida. Ninguna de las numerosas implementaciones a la fecha han salido airosas ante el escrutinio de expertos en seguridad; muy por el contrario, empresas del tamaño de Sequoia o Diebold, las principales proveedoras de estaciones de voto, han llegado a amenazar a investigadores para evitar que publiquen sus resultados.

Diversos argumentos han sido esgrimidos a favor del voto electrónico, pero pueden ser resumidos en tres:

Disminución de costos. Un adecuado proceso democrático es caro. La papelería electoral debe ser impresa con candados suficientes para asegurar su unicidad, deben proveerse mecanismos para garantizar que sólo los electores autorizados emitan su voto, y debe haber garantías de no manipulación para todos los componentes involucrados en el proceso. La automatización del proceso ayudaría a implementar estos candados a un menor costo.
Agilidad en la obtención de resultados. No hay nada que genere mayor falta de confianza y suspicacia en los procesos que una demora en la publicación de los resultados. Se ha argumentado que a través del voto electrónico, los resultados pueden ser anunciados prácticamente de inmediato tras haberse cerrado la casilla.
Confiabilidad de los actores. La experiencia de muchos países en torno a los fraudes electorales apunta dolorosamente a la falta de integridad de los actores involucrados en el proceso — Personas susceptibles a la compra de conciencias, a la extorsión, o directamente a la violencia física; si todo el proceso es controlado por computadoras, éstos factores deberían perder peso.

A continuación analicemos por qué los tres argumentos caen por su propio peso.

Agilidad en la obtención de resultados

La sociedad actual vive obsesionada con la velocidad del acceso a la información. Los medios electrónicos de comunicación y el uso de Internet nos han acostumbrado a que la información debe estar disponible tan pronto ocurren los hechos, siendo cualquier demora excesiva. Todos los sistemas electorales reconocen que, para no alterar los resultados de una elección en proceso, no deben darse a conocer sus resultados parciales hasta que haya cerrado la última de las urnas. Sin embargo, una vez que ésta cierra, siempre hay un periodo de un par de horas en que es necesario esperar a que las autoridades electorales recopilen la información generada por decenas de miles de casillas para poder dar a conocer los resultados.

Además del apetito por la información expedita, la necesidad de tener los resultados de inmediato viene de los ocultamientos de información que tantas veces vimos en el pasado. Ejemplo de esto son las declaraciones que hizo –veinte años tarde– Manuel Bartlett Díaz, presidente de la Comisión Federal Electoral durante las elecciones de 1988: La decisión de no dar datos preliminares fue tomada por el presidente de la Madrid, dado que “si se oficializaba en ese momento –con datos parciales– que Cárdenas iba ganando, al final nadie aceptaría un resultado distinto.”

La situación ha cambiado radicalmente desde entonces. La población hoy comprende y acepta que, para evitar una demora cercana a una semana, el Instituto Federal Electoral y las autoridades correspondientes publican los resultados de encuestas, conteos y PREP típicamente dentro de las dos primeras horas tras haber concluído la votación, siempre que haya suficiente márgen estadístico para no causar confusión, pero que estos datos son extraoficiales.

Son sólo este par de horas el que ganaríamos con urnas electrónicas. El tiempo invertido por los funcionarios electorales en cada casilla en el conteo de votos emitidos es sólo una fracción del dedicado a las tareas de verificación y protocolización que deben llevarse a cabo antes de declarar concluída una elección.

Sumando ésto a que –por consideraciones de seguridad– las estaciones de voto nunca deben contar con conectividad a red (además de que ni los países más industrializados cuentan con una cobertura de Internet del 100% de su territorio), debe haber forzosamente un paso manual de comunicación de resultados al centro de control de la autoridad electoral, el argumento de reducción de tiempos queda descartado.

Confiabilidad de los actores

Algunos proponentes del voto electrónico mencionan que, con el voto tradicional en papel, los fraudes siempre han existido, y que hacerlo electrónico no agrava los riesgos — Sin embargo, al implementar el voto puramente electrónico estaríamos aumentando la profundidad a la que podrían llegar, e imposibilitando cualquier acción de auditoría o rendición de cuentas. El proceso electoral es, por excelencia, el que mayor auditabilidad demanda en una sociedad democrática. Como profesionales del desarrollo, estarán de acuerdo conmigo en la imposibilidad de demostrar que una base de código suficientemente grande está completamente libre de fallos, incluso teniendo a un equipo altamente especializado.

Además, verificar un determinado código fuente no garantiza que el sistema desplegado sea efectivamente resultado del programa analizado. Más aún, una sociedad democrática debe garantizar que cualquier ciudadano interesado pueda constatar el correcto conteo de votos. A fin de cuentas, ¿por qué el ciudadano promedio debe confiar en estos especialistas? Este argumento fue clave para la resolución adoptada en marzo del 2009 por la Corte Suprema de Alemania, declarando anticonstitucional las votaciones electrónicas porque (cito) «(...)excluye del control público a componentes centrales de la elección, y por tanto no alcanza a satisfacer las exigencias constitucionales».

Disminución de costos

Los candados para asegurar elecciones son muy caros — y el caso de México es extremo: es el sistema electoral más caro de América Latina;
cada sufragio emitido en las elecciones intermedias del 2009 tuvo un costo superior a los 17 dólares, aunque hay estimaciones que lo ubican en hasta 50 dólares, tomando en cuenta gastos ocultos.

Un rubro en el que sin duda podrían presentarse importantes ahorros es en la generación, manejo y custodia del material electoral. Sin embargo, estudios realizados sobre las estaciones de votación Diebold (responsables de la recopilación del 10% de los votos en los Estados Unidos),muestran que estas máquinas presentan un nivel de confiabilidad ante ataques verdaderamente bajo, y permiten —con un tiempo mínimo de acceso— la reprogramación resultando en resultados fraudulentos que serían prácticamente imposibles de lograr en una elección tradicional sin recurrir a métodos violentos.

Los expertos coinciden en que la única manera de que un sistema electrónico sea confiable es si genera un rastro impreso verificado por cada votante. La única garantía que un votante puede tener de que su voto fue registrado correctamente es que el sistema genere una boleta impresa y de carácter irrevocable, misma que sea verificada por el votante al instante, y se convierte en el documento probatorio de la elección. No hay manera de que el estado interno de una computadora sea suficientemente confiable y duradero para que lo consideremos evidencia electoral.

Llegamos entonces a una contradicción: El equipo de votación no es barato, en términos absolutos. Su adquisición por parte de un gobierno podría justificarse si se plantea prorratear a lo largo de varias elecciones — pero debe estar sujeto a una estricta vigilancia contínua, incluso en los periodos en que no será utilizado. Debe recibir mantenimiento, y debe abastecerse de insumos, para asegurar un rastro impreso verificado.

Además, en caso de sufrir un desperfecto, todas las casillas deben tener un plan de respaldo: Casi indefectiblemente, esto significaría tener papelería tradicional además del sistema electrónico. Por tanto, el supuesto ahorro puede volverse en contra nuestra, convirtiéndose en un gasto mucho mayor al que implican las votaciones tradicionales

Conclusiones

El que seamos entusiastas de la programación y de la mejoría de procesos no debe cegarnos ante los graves peligros que implica para toda la sociedad adoptar un esquema de votaciones electrónicas. Estos puntos, y muchos otros, han llevado a que muchas democracias bien instituídas y respetadas repudien a las urnas electrónicas. No permitamos que, una vez más, supuestos expertos vengan cambiarnos nuestro oro por espejitos. La democracia en nuestro país es jóven y aún muy débil, y migrar a un esquema de urnas electrónicas, más que aumentar la confiabilidad, no lograría más que perpetuar nuestra triste historia de fraudes.

Si quieres leer más al respecto, la versión extendida de este texto se encuentra disponible en http://gwolf.org/content/voto-electronico

Referencias

F. Heinz, “¿El voto electrónico mejora la democracia?”, Fundación Via Libre. http://bit.ly/sg27r1
A. Feldman, A. Halderman & E. Felten, “Security Analysis of the Diebold AccuVote-TS Voting Machine”, Center for Information Technology Policy Princeton University. http://bit.ly/sg27r2

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

Experiencia de Usuario: El nuevo diferenciador del software

Anonymous — Mon, 22 Feb 2010 19:32:10 +0000

Experiencia de Usuario: El nuevo diferenciador del software Anonymous Mon, 02/22/2010 - 13:32

Publicado en

SG #27

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

Parece ser que el principal elemento de diferenciación en el software durante los próximos años será lo que se conoce como “experiencia de usuario”, especialmente la que integre múltiples dispositivos y la nube. La interacción PC-humano continuará desarrollándose para crear aplicaciones intuitivas fluidas y naturales en su uso, esto se denomina Natural User Interface (NUI). Algunos ejemplos:

Si un usuario está viendo un video en su hogar, será posible continuar viéndolo en el celular, en la PC o en la consola de videojuegos en otra ubicación en forma instantánea.
Imagine una sala médica con una superficie interactiva con modelos 3D de los pacientes. Será práctico tanto en la enseñanza de medicina como para practicar operaciones reales.
En las tiendas AT&T de Estados Unidos es posible arrastrar dos modelos de teléfonos celulares en una superficie y comparar sus características, labor que manualmente es compleja cuando hay decenas de opciones. El sistema usa cámaras y otros sensores para determinar lo que sucede en el mundo real.
El reconocimiento de voz mejoró significativamente en Windows 7. Ahora es posible crear experiencias que toman ventaja del lenguaje hablado como nunca antes.

Evolución texto : gráfico : físico

A diferencia del mundo de comandos donde el usuario debe saber qué comandos emitir, en el mundo de la interfaz gráfica se facilita la exploración. La NUI requiere un contexto de dónde se encuentra el usuario, lo que quiere lograr y requiere una visualización muy responsiva como forma de retroalimentación. Las experiencias basadas en tacto deberán ser más sencillas y simples que las que usamos bajo el paradigma de la GUI. Las aplicaciones que tengan demasiadas opciones continuarán en el mundo GUI.

Ajax en esteroides

El punto de entrada a una mayor “experiencia de usuario” es el realizar el potencial de tecnologías como Windows Presentation Foundation (WPF), Silverlight, Adobe AIR, JavaFX o AJAX, las cuales han tenido diversas limitaciones que no han permitido lograr su potencial. En general, con estas tecnologías es posible construir un “capa de presentación” pero no una aplicación real completa –por ejemplo que pueda acceder al USB, aproveche la aceleración de tarjetas de video, y soporte bibliotecas nativas de la plataforma. Otras áreas importantes a evaluar en un RIA son: soporte a localización, seguridad, accesibilidad para gente de diferentes capacidades, requerimientos de que un administrador instale la aplicación, un “look and feel” que corresponde a la plataforma donde se ejecutará la aplicación. En este momento la competencia es por quién logra construir una plataforma que resuelva todos esos problemas y sea altamente capaz para implementar una NUI. En el caso de Microsoft, WPF 4.0 tiene una gran variedad de mejoras relacionadas a los problemas descritos, pero la estrategia de Microsoft se basa primariamente en el IDE: Visual Studio 2010, que por primera vez ofrece una variedad de controles de forma nativa para construir experiencias de usuario sin el alto costo que hasta hoy se requiere en el lado del diseño.

Conclusiones

El diferenciador de software continúa siendo la innovación en los problemas que se resuelven así como una “mejor experiencia de usuario”. La incorporación del NUI al mundo de los múltiples dispositivos unidos por la nube será un proceso gradual que establecerá una nueva plataforma tecnológica para la siguiente década. El precio de una laptop con capacidad multi-touch supera en menos del 20% al de una laptop convencional. En el 2010, es posible aplicar la diferenciación de experiencia de usuario en proyectos de bajo costo. ¡Hágalo hoy

Conozca más:

[1] Bill Buxton, Sketching User Experiences: Getting the Design Right and the Right Design, Morgan Kaufmann, 2007.

[2] Conferencia MIX10. http://www.microsoft.com/mix

[3] Touchless SDK. http://www.codeplex.com/touchless

[4] Visual Studio 2010. http://www.microsoft.com/visualstudio

Bio

Luis Daniel Soto es Director de Divulgación Tecnológica en América Latina para Microsoft. @luisdanielsoto