domingo, 31 de agosto de 2008

Tecnologías Java


Un nuevo blog de informática ha nacido: Tecnologías Java. Como bien indica su nombre, el blog estará dedicado a lo que es el vasto y maravilloso mundo de las tecnologías Java.

Los autores que mantendrán este blog son:
  • Paola A. Grajeda: quien cuenta con amplia experiencia en desarrollo de aplicaciones enterprise escritas en Java. Actualmente trabaja como consultora de tecnología y analista desarrolladora Java. Es estudiante de Sistemas en la Facultad de Ingeniería de la Universidad de Buenos Aires y se encuentra cursando las últimas materias de la carrera.
  • Adrián M. Paredes: el mismo que ya conocen, si siguen este blog. También desarrollador Java, y estudiante de la Facultad de Ingeniería de la UBA.
Tecnologías Java se ha abierto esta semana y ya pueden encontrarse dos interesantes entradas:
¿Qué podrán encontrar en el futuro en este blog? Esperemos que mucho. En principio sabemos que muy pronto se vendrá la segunda parte de la Introducción a EJB 3 (que planeo redactar durante el mes de septiembre), y tal vez más adelante tengamos notas sobre los contenedores JBoss y Glassfish, sobre RichFaces, JFreeChart, Seam, Hibernate, y no sólo tecnologías para JavaEE, también es posible que escribamos artículos dedicados a aplicaciones desktop y aplicaciones JavaME para celulares.

Es un proyecto ambicioso, considerando la disponibilidad horaria de los autores. Sin embargo, Tecnologías Java aspira a ser más que un blog; aspira a ser, en un futuro (esperemos) no tan lejano, una referencia muy útil para el mundo de desarrollo Java.

Como dice un viejo proverbio chino: "Un viaje de tres mil leguas empieza con un solo paso".


Espero que les sirva.

Por un mundo más libre!
Salud!

martes, 19 de agosto de 2008

El Sistema Operativo Más Sencillo

Sinceramente, no me imagino que pueda existir un usuario que prefiera utilizar un sistema operativo (SO) que no sea el más sencillo posible. Lo ideal es que resulte transparente al usuario final. Un SO no debe obstaculizar la ejecución de los programas que los usuarios utilizan a diario para trabajar. Por eso, nadie quiere tener problemas con él. Es más común encontrar usuarios dispuestos a tolerar bugs de aplicaciones, que bugs de SO. Los bugs de los sistemas operativos resultan altamente irritantes.

Durante muchos años, la publicidad de Microsoft nos ha vendido que Windows es el SO más sencillo de usar. Muchos, hoy en día, lo siguen creyendo. Me aventuro a pensar que más del 90% de los usuarios de PC deben tener esta convicción. En los últimos años, han surgidos miles de blogs y páginas idolatrando a las distintas distribuciones de Linux. Hoy, Linux es una opción muy estable y fuerte para PC. No es tan popular como el monstruo de Microsoft, pero los usuarios de Linux (muchísimo más fundamentalistas que los de Windows) se han encargado de propagar por todos los medios la idea de que Linux es más estable, sencillo y seguro.

Creo que no cabe duda que cualquier distribución de Linux es más segura que todas las versiones de Windows juntas. Practicamente no existen virus que ataquen al SO del pungüino (Tux para los amigos), ni fallas de seguridad importantes (agujero como el que se encontró hace poco en los algoritmos de encriptación que usa Debian no es nada comparado a todos los backdoor y vulnerabilidades que siempre tuvo Windows). En el terreno de estabilidad, los dos parecen bastante parejos (quizá Linux siga ganando un poco más la batalla como servidor). Pero si nos adentramos en el terreno de lo "sencillo", de la usabilidad, nos enfrentamos a conceptos subjetivos y a mucho-fanático-que-anda-dando-vuelta.

Parafraseando a Obi-Wan Kenobi en Star Wars Episode III: "Sólo los tiranos piensan en absolutos".

La mente humana tiende a ser fanática, tiende a pendular entre los extremos con cada decisión bivalente a tomar. Esto significa: hoy soy fanático a morir de Java, mañana descubro que Java no era perfecto y me hago fanático a morir de .NET, pero también encuentro que .NET no es perfecto y vuelvo a Java, pero no tan al extremo, y así mi fanatismo oscila como un péndulo que es detenido de a poco por la fricción, hasta paralizarse en un punto medio, que a menudo es el más indicado.

Hoy en día, decir que Windows es más fácil de usar que Linux es haberse quedado en el tiempo o haberse convertido en un fundamentalista. Lo mismo al revés. Linux no es más sencillo que Windows. Windows no es más sencillo que Linux.

La distribución de Linux que más se parece en prestaciones, difusión y usabilidad a Windows es Ubuntu. La última versión estable hasta el momento, Ubuntu Hardy Heron, es muy sencilla. Sinceramente, entre Windows Vista Ultimate y Ubuntu Hardy Heron, yo elijo el segundo, y no por cuestiones ideológicas. Ubuntu Hardy Heron me pareció más fácil de usar.

Pero, como toda opinión sobre usabilidad, la afirmación anterior es subjetiva. Seguramente habrá muchos usuarios que les parezca más sencillo Windows Vista.

Mi opinión tiene fundamento. Muchas veces me ha pasado que para hacer algo que necesito, en Windows tengo que instalar dos o tres aplicaciones (a veces privativas) y aprender a usar complicadas interfaces gráficas y, en cambio, en Ubuntu, basta con un único programa o un simple comando de consola.

Para los windowseros que no me creen, a continuación menciono tres simples ejemplos.

Mirar archivos de video 3GP capturados con un celular

Para Windows la solución fue instalar una aplicación pesada como QuickTime (que en particular a mí siempre me resultó molesta) o convertir los archivos a AVI con un conversor (como resultado los archivos terminan pesando más).

Para Ubuntu la solución fue abrir una consola y escribir:

$ sudo wget http://www.medibuntu.org/sources.list.d/hardy.list -O /etc/apt/sources.list.d/medibuntu.list

$ wget -q http://packages.medibuntu.org/medibuntu-key.gpg -O- | sudo apt-key add - && sudo apt-get update


Encontrar estas dos líneas para agregar el repositorio de medibuntu a mi sources.list y actualizar el sistema, me costó menos de cinco minutos de googleo. Bajar el QuickTime e instalarlo, todos saben lo molesto que es.

Y encima hay distribuciones de Linux en las que ni siquiera hace falta instalar los codecs necesarios porque ya vienen instalados por defecto.

Girar un video

Necesitaba puntualmente girar un video (también un 3gp). Con Windows la única opción que encontré fue bajarme un programa conversor de 3gp a AVI, un programa que permitiera rotar AVIs y después volver convertir a 3gp si lo deseaba.

Con Ubuntu simplemente tuve que bajar/instalar un codificador GPL llamado memcoder, tipeando en la consola:

$ sudo apt-get install mencoder

Y luego el comando para rotar la imagen los grados que yo necesitaba:

$ mencoder -vf rotate=3 -oac pcm -ovc lavc 27-05-07_2346.3gp -o salida.3gp


Si a alguien le interesa, la explicación de este comando la encontré en este post de mundogeek.

Montar una ISO

Si alguno aún sigue preguntándose por qué Ubuntu me parece más sencillo que Windows, espere a leer este ejemplo, que para mí es el mejor.

Para montar un archivo ISO de un CD o DVD en una unidad virtual, en Windows es necesario una aplicación como Daemon Tools, que encima es propietaria.

Con Linux, el montaje de un archivo ISO es trivial, ya que lo soporta el mismo comando mount del SO y no se necesita instalar ningún programa. Simplemente teniendo cargado el módulo loop del kernel, que casi siempre está, uno puede abrir una consola y escribir:

$ sudo mount -t iso9660 -o loop archivo.iso /media/iso

Y si no me creen, échenle un vistazo a esta página de guia-ubuntu.

Conclusión

Algunas tareas son más sencillas con Windows. Algunas tareas son más sencillas con Ubuntu. Hablo de estos dos SO porque son los que conozco. Lo importante es: lo que puede parecerle fácil a un usuario, puede resultarle difícil a otro, y viceversa. Quizá algunos necesiten sí o sí manipular una ventana y tengan miedo de abrir una consola; quizá otros, como yo, a veces se mareen con una interfaz gráfica rebuscada y prefieran algo más simple y directo como escribir una línea de texto. "Sobre gustos no hay nada escrito".

Espero que les haya servido.

Por un mundo más libre!
Salud!

domingo, 10 de agosto de 2008

Team Skill 6: Construyendo el Sistema Correcto

Diseñar e implementar el sistema correcto es el más grande trabajo de todos. Una técnica útil es usar los requerimientos y los casos de uso para guiar la implementación de la arquitectura y el diseño. Como estuvimos viendo en los post anteriores, Managing Software Requirements - A Unified Approach es un libro que propone una metodología para capturar y administrar requerimientos durante todo el proceso de desarrollo de software, organizada en Team Skills o Habilidades Grupales.

Llegamos a la última Habilidad Grupal, la que se encarga de la fase de construcción. En esta fase, debemos confirmar continuamente que el desarrollo esté progresando, confirmar que los resultados del desarrollo son correctos y aprender a administrar los cambios que ocurren durante el proceso. Es necesario mantener la trazabilidad de los requerimientos y los casos de uso y establecer procesos de verificación y/o validación mediante pruebas de aceptación de diferente profundidad y cobertura, para corroborar que se siga construyendo el sistema correcto, el sistema que el usuario pidió y el analista relevó.

Verificación mediante Trazabilidad

La verificación es un enfoque analítico que permite un monitoreo constante de la evolución de las funcionalidades del proyecto, los requerimientos, el diseño y la implementación. La Verificación está soportada por el uso de técnicas de trazabilidad para relacionar unas partes del proyecto con otras.

Trazabilidad es la habilidad de trazar la implementación a través de las fases de especificación, arquitectura, diseño, construcción y testing. Es significativa para la calidad del software. A través del uso de la trazabilidad podemos verificar que:
  • Todos los elementos del proyecto se contabilizan.
  • Todos los elementos del proyecto tienen un propósito.
Según la IEEE, la trazabilidad es el grado por el cual una relación puede ser establecida entre dos o más productos del proceso de desarrollo o el grado por el cual cada elemento del producto de desarrollo de software establece una razón para su existencia.

La trazabilidad puede ser:
  • Implícita: cuando nace de las relaciones entre productos.
  • Explícita: cuando nace del desarrollo de las relaciones derivadas de consideraciones hechas por el equipo de desarrollo.
Aunque la verificación es una técnica analítica, los autores de Managing Software Requirements, Dean Leffingwell y Don Widrig, afirman que es importante recordar que pensar es importante. No podemos simplemente aplicar las técnicas de verificación mecánicamente.

Validación mediante Pruebas de Aceptación

La validación es la otra cara del enfoque V&V para asegurar que el sistema está construido correctamente, haciendo foco en las pruebas y en el uso de las técnicas de trazabilidad para seleccionar componentes del sistema que requieren pruebas. Al igual que en la verificación, usamos técnicas de validación para asegurar que:
  • Todos los elementos del proyecto están correctamente probados.
  • Todas las pruebas tienen un propósito útil.
Según la IEEE, la validación es el proceso de evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requerimientos específicos. Para llevar a cabo la validación se utilizan las Pruebas de Aceptación. A través de ellas, el cliente debe validar que el producto trabaje de la forma en que realmente necesita que lo haga.

Las actividades primarias de la validación consisten en actividades de testing. Debemos tratar de probar contra los requerimientos y no contra la implementación. El proceso de desarrollo debe incluir planificación para actividades de prueba, debe proveer tiempo y recursos para diseñar las pruebas y proveer tiempo y recursos para ejecutarlas, a nivel de pruebas unitarias y pruebas globales del sistema.

Análisis de Riesgos

Necesitaremos aplicar un Análisis de Riesgos para ayudar a decidir qué porción del sistema necesita Verificación y Validación (V&V) y en qué cantidad. Obviamente verificar y validar todas y cada una de las funcionalidades es poco práctico y puede llevar a un producto inseguro que cause daño a los usuarios.

Un correcto Análisis de Riesgos servirá para decidir cuáles son los riesgos a mitigar en el sistema, para decidir el alcance de las actividades de V&V y para realizar un análisis de costo y beneficio que será entrada directa para el cálculo del ROI.

Administración de Cambios

Leffingwell y Widrig aseguran que construir el sistema correcto también depende de la Administración de Cambios. Hasta que la Ingeniería de Software surgió como carrera, los desarrolladores tuvieron que aprender a las patadas que el cambio es parte de la vida, que todo proyecto debe contar con un plan para soportar los cambios y diseñar un proceso con el cual poder gerenciarlos. La Administración de Cambios nos ayudará a saber que el sistema que estamos construyendo es el sistema correcto y, además, que continúa siendo el sistema correcto durante todo el ciclo de vida del proyecto.

Un proceso para la administración de cambios podría ser:
  • Reconocer que el cambio es inevitable
  • Hacer un baseline de los requerimientos
  • Establecer un único canal para establecer el cambio
  • Establecer un sistema de control de cambios
  • Administrar el cambio jerárquicamente: esto se refiere a que los cambios deben ser administrados top-down y no bottom-up, como se suele hacer (problema conocido como "efecto dominó"); los cambios deben comenzar por la visión, construyendo un documento Delta de Visión (como vimos en el Team Skill 3), que luego atraviese todas las disciplinas posteriores.

Entradas Relacionadas

lunes, 4 de agosto de 2008

Historia de los Lenguajes de Programación

La línea de tiempo se origina en noviembre de 1954 con FORTRAN. Continúa en octubre de 1956 y comienzan las bifurcaciones, pasando por una gran cantidad de lenguajes, versiones y paradigmas, recorriendo la breve pero intensa historia de la programación, hasta el fin de las ramas más modernas, que son las de PHP4 y PHP5, en enero y mayo de 2008 respectivamente, Ruby 1.8.7, también en mayo, y los últimos updates de Java de julio, el mes pasado.

Gracias al post publicado ayer en Mazziblog, "un blog colectivo sobre música, informática, TV, tecnología, diseño, cine y algunas cosas más", titulado "Sólo para Lingüistas", me enteré de esta fabulosa Timeline que nos cuenta la historia de los lenguajes de programación en forma gráfica.

Una verdadera delicia que ningún programador se puede perder.

Link

Computer Language History

viernes, 1 de agosto de 2008

Team Skill 5: Refinando la Definición del Sistema

Según Managing Software Requirements - A Unified Approach de Dean Leffingwell y Don Widrig (ISBN: 0-201-61593-2), los requerimientos son la clave de las técnicas de comunicación para capturar las necesidades del usuario, de manera que el desarrollador pueda crear un sistema para satisfacer esas necesidades. Además, los requerimientos necesitan ser especificados lo suficiente para que podamos decir cuándo se han cumplido. Tenemos que recordar que toda esta metodología de Team Skills apunta más a un entorno orientado al plan (como puede ser RUP) que a un entorno ágil, por ende, mucho de lo que escribí en mi post anterior sobre user stories no aplica en este contexto.

Paquete de SRS moderno

Los requerimientos pueden estar organizados y documentados en una variedad de formas. Managing Software Requirements introduce el concepto de Paquete de SRS (Software Requirement Specification) moderno, una construcción lógica que nos permite documentar requerimientos en Casos de Uso, documentos, base de datos de formularios u otras técnicas.


En otras palabras, un Paquete de SRS moderno es un paquete de información que describe el comportamiento externo del sistema en forma completa. Sirve para crear un modelo conceptual del sistema a construir. Todo desarrollo debe fluir de los requerimientos especificados en el Paquete de SRS moderno. Nada debe ser desarrollado fuera de este paquete. Todas las especificaciones en el paquete deben ser reflejadas en las actividades de desarrollo. Dado que estos son los elementos que rigen, se deduce que todas las actividades, tales como las limitaciones reglamentarias, deben reflejar el paquete y viceversa. El paquete de SRS Moderno debe ser revisado y actualizado a través de todo el ciclo de vida del proyecto. El equipo de desarrollo, a través de la WBS, será el encargado de la creación y el mantenimiento de los componentes que se incluirán. El paquete debe especificar qué funciones deben realizarse, requerimientos funcionales, requerimientos no funcionales y restricciones de diseño.
El paquete de SRS moderno sirve para:

  • Establecer una base para la comunicación entre las partes
  • Representar un acuerdo entre las partes
  • Establecer un estándar de referencia para la administración del proyecto
  • Input para diseño e implementación
  • Input para testing y aseguramiento de la calidad (QA)
  • Controlar la evolución del sistema durante la fase de desarrollo del proyecto

Medidas de Calidad en los Requerimientos de Software

En esta Habilidad Grupal, Dean Leffingwell y Don Widrig proporcionan una serie de medidas para evaluar la calidad de los paquetes y de los diversos elementos que figuran en él.

Un conjunto de requerimientos debe ser:
  • Correcto: si y sólo si cada requerimiento definido representa algo requerido por el sistema
  • Completo: si y sólo si describen todos los requerimientos de importancia para el usuario
  • Consistente: si y sólo si ningún subconjunto de requerimientos individuales entra en conflicto con otro
  • No ambiguo: si y sólo si puede ser sujeto a una única interpretación
  • Verificable: si y sólo si existe un procedimiento finito y estimable que pueda determinar que el software conforma con el requerimiento
  • Modificable: si y sólo si cualquier cambio puede ser realizado fácil, completa y consistentemente
  • Rastreable: si y sólo si cada uno de los componentes es claro y si existe un mecanismo que hace posible referirse a ese requerimiento en futuros esfuerzos de desarrollo
  • Entendible: si y sólo si la comunidad de usuarios y el equipo de desarrollo pueden comprender completamente los requerimientos individuales y la funcionalidad agregada por el conjunto

Medidas de Calidad del Paquete SRS

Los siguientes son algunos de los componentes que debería contener un buen SRS:
  • Una buena Tabla de Contenidos (TOC)
  • Un buen índice
  • Una historia de revisión incluyendo: número de revisión, la fecha de cada revisión, un pequeño sumario de las revisiones hechas sobre la información publicada y el nombre de la persona responsable de los cambios en el documento
De más está decir que si damos un vistazo al template SRS de RUP (cualquiera, el extendido o el reducido para proyectos más pequeños) vemos que cumple con todas estas medidas de calidad y más.

Técnicas para especificar Requerimientos

Managing Software Requirements especifica que, donde sea necesario, la documentación de requerimientos debe ser complementada con uno o más métodos o especificaciones formales (especificaciones más tradicionales o estructuradas).

No voy a entrar en detalle sobre este tema. Simplemente transcribo una enumeración de algunas de las técnicas de especificación de requerimientos más conocidas en el mundo de la Ingeniería de Software:
  • Pseudocódigo
  • Máquinas de estado finito (autómatas)
  • Árboles de decisión
  • Diagramas de actividad (o de flujo)
  • Modelos de entidad-relación (DER)
  • Análisis orientado a Objetos (diagrama de clases y compañía)
  • Análisis estructurado (DFD y compañía)

Entradas Relacionadas