Archivo para la categoría Blogroll

Aniversario y renovación

Ya con poco más de un año en funcionamiento, es hora de una renovación en el blog. Básicamente esto ha significado el cambio del tema Ambiru que tan buen servicio me prestó siempre, por algo nuevo con características que al menos para mí, son novedosas.

En primera aproximación he adoptado el tema Albeo por Elena G, lo que permite disponer de dos columnas y con esto mismo, activar algunos widgets.

La idea es facilitar la navegación por el sitio, al disponer de enlaces y listas de posts populares o recientes, ahora en un lugar más prominente. Espero que esto signifique una mayor permanencia de los lectores dentro del blog y la promoción de algunos posts importantes pero que ya sea por su título o tematica, no son directamente a los que caen quienes llegan por Google o desde la Wikipedia.

Además y como bono, el cambio de tema ha resulto el problema de la suscripción por RSS. No sé la razón, pero de de un tiempo para acá los enlaces RSS habían dejado de funcionar y aunque tampoco sé la razón, parece ser que ahora con el cambio de tema, han vuelto a trabajar correctamente.

Ya con cuarenta mil visitas acumuladas y con un nivel de nuevos hits de poco más de tres mil a la semana, espero que los cambios con motivo al aniversario del blog sean bienvenidos por todos, tanto los lectores regulares como los de ocasión.

Entre los pendientes del primer año de operación me queda el tratar temas como los patrones de diseño, libros recomendados o las consabidas evaluaciones de software; esto junto con mis preocupaciones de siempre como las prácticas o el soporte al proceso de desarrollo. Sinceramente encuentro muy satisfactorio el mantener el blog y espero poder continuar enriqueciendolo por mucho más tiempo aún. Sé que por temas no voy a quedarme corto, ya que la profesión sigue siendo muy amplia y de momento siento que solo he rascado un poco la superficie de la misma.

Anuncios

2 comentarios

Características que debe tener un Documento de Arquitectura

Encontré en el blog de Angel “Java” Lopez, una traducción de la lista de características de un buen documento de arquitectura del sistema que es traducción del trabajo de Michael Stal, bávaro de origen, quien nos dice las siguientes características:

  • Describa la arquitectura de arriba a abajo: presente la visión general primero, y luego vaya tratando cada uno de los puntos más en detalle, ya sea de diseño o implementación.
  • Agregue un glosario: algo que podemos olvidar, pero muchos términos serán desconocidos o confusos, o peor, serán mal entendidos por alguien que tenga un contexto distinto al nuestro.
  • Cada vez que introduzca un término que se conoce por una sigla, no presuma que todo el mundo sabe qué significa: coloque la sigla, y las palabras completas que describe.
  • Que no exceda las 50 páginas: si es más extenso, no será leído en detalle. Recuerde que muchas personas que lo lean serán personas con cargos de responsabilidad, que pueden no tener todo el tiempo del mundo para leer su obra maestra.
  • Todos los documentos de arquitectura que entregue, deben usar la misma plantilla: distintos tipos de letras y formatos entre documentos, confunden a los lectores. La estructura debe ser la misma para todos: si usa una tabla de contenido, un resumen, una conclusión en un documento, deberá usarse en todos.
  • Si usa diagramas, úselos consistentemente. Si para explicar un concepto usa UML, cuando tenga que exponer un concepto similar siga con ese tipo de diagrama. Y use los mismos elementos: si en un diagrama UML usó algunos estereotipos, siga usándolos cuando sean necesarios, con las mismas notaciones e íconos.
  • Agregue referencias a otros documentos que pueden ser importantes para entender algún concepto o explicitar una fuente consultada.
  • Explique siempre cómo la arquitectura descrita cumple con los requerimientos que se quieren alcanzar. Debe haber una trazabilidad desde los requerimientos a la arquitectura definida.
  • Coloque al comienzo un resumen: sea gentil con el lector, prepárelo para lo que va a encontrar. Por lo mismo, si un documento lleva varias páginas y abarca varios temas, incluya un índice. Si es necesario, describa los prerrequisitos que debe cumplir de antemano un lector que quiera entender el documento.
  • Si tiene que entregar varios documentos, estructure el conjunto como un árbol. El documento raíz describirá la arquitectura desde un punto de vista alto, estratégico. Desde ahí, los documentos nodos hijo irán explicando los subsistemas relevantes, y los elementos que atraviesan los demás, como seguridad y escalabilidad.
  • Describa la especificación de la arquitectura, y cómo esa especificación puede ponerse a prueba, como cuando programamos “unit tests”.
  • Compruebe que el documento acompañe, describa la implementación actual del sistema. Sino, será una pérdida de tiempo para quien lo lee, y hasta puede provocar errores, al tomar decisiones sobre una especificación que no corresponda con el producto actual.
  • Describa las decisiones de diseño en detalle, que no quede solamente la descripción de la decisión tomada, debe quedar claro que hubo una decisión en ese punto, por ejemplo, mencionando alguna alternativa.
  • Relacionado con lo anterior, no sólo describa el “cómo” sino también el “por qué”. Es importante que otra persona entienda las razones que llevaron a tomar un camino en el diseño.
  • Si se refiere a algún software entregado con el documento, o a utilizar, incluya la versión del mismo: no presuma que será evidente cuál es la versión a la que se refiere.
  • Agregue diagramas y dibujos para explicar las decisiones de diseño tomadas. Los diagramas llevan tiempo de armado, pero el resultado vale la pena.
  • Explique los diagramas: una imagen vale más que mil palabras, pero también hay que entenderla.
  • Pida que otras personas revisen el documento. Uno siempre escribe desde su propio contexto, y tal vez lo que a nosotros nos parece claro, para otro no lo sea. Trate que sea una persona que no esté en el mismo proyecto, para probar si el documento es entendible para alguien que no está al tanto de los conceptos tratados.
  • Use un sistema de control de versiones: no pierda la historia del documento.
  • Escriba los nombres del autor o autores, y forma de contactarlos, en caso de ser necesario. Incluya fecha y hora de versión.
  • No tiene que escribir todo el documento desde el principio al fin: vaya utilizando otros documentos menores que haya producido durante el proceso de discusión y diseño de arquitectura, pero asegúrese su consistencia. Recuerde: ¿cómo se come uno un elefante? Bocado a bocado.
  • No necesita explicar el sentido de cada patrón usado: remita su descripción a la literatura especializada.
  • Como en todo documento, sea consistente en el uso de los tiempos verbales, el uso o no de la forma pasiva, la forma de usar pronombres, si “dialoga” o no con el lector, el uso de la primera o tercera persona.

Pienso que muchas de estas características valen también para los restantes documentos del proceso. Después  de todo, la claridad, la consistencia, el formato legible, el buen uso del lenguaje, el buen uso del UML, entre otras cosas son puntos que se toman en cuenta durante una Revisión de Forma y definitivamente tiene impacto en la calidad del documento.

Para ser justo con mis propios documentos, aprovecho para apuntar que ya varios de estos consejos se habían considerado en la progresión de documento en blanco y documento del proceso (véa también la segunda parte), por lo que hasta donde puedo ver, mi propia plantilla de arquitectura del sistema cumple con estas ideas.

, , , , , , ,

1 comentario

Sobre métodos ágiles

En los últimos días he tenido un muy interesante intercambio de opiniones con wigahluk en su blog Al que no puede con la sopa… doble ración sobre las diferencias entre el método ágil XP y RUP/UP. Sin embargo, rápidamente fueron más las coincidencias que las diferencias, ya que sin interesar la aproximación que se siga, todos los métodos persiguen metas comunes y es en eso, donde surgen los puntos de coincidencia.
Con todo, ciertamente vale mucho la pena la lectura de su artículo sobre el método ágil XP así que valga mi recomendación.

Lea le artículo completo: http://wigahluk.wordpress.com/2007/06/26/entre-la-xp-y-el-rup

, ,

Deja un comentario

Modelo de Calidad Tradicional del Software

Anteriormente había comentado que intentar establecer de antemano las propiedades que un sistema de software debe cumplir para satisfacer a los clientes y usuarios es llamado Modelo de Calidad y que en concreto este era un instrumento útil para saber que preguntar ante un sistema nuevo. Sin embargo hay que apuntar aquí siempre, y así lo hago, que el concepto de calidad debe ser relativo a cada organización de desarrollo y que debe ser perseguida no por medio de una lista de comprobación común a toda la industria sino por medio de algún mecanismo o procedimiento apropiadamente diseñado y sobre el cual se pueda discutir objetivamente con ayuda de algún plan.

Ahora eso sí, no por eso debemos dejar de conocer cual es ese modelo de calidad tradicionalmente aplicado al software, ya que es parte de la profesión y como buenos profesionales nos sirve de mucho el conocerlo.

El problema me surgió cuando intente encontrar una lista de estas cualidades. La verdad sea dicha, la ultima vez que la vi fue hace ya varios años; por lo que he intentado encontrar una lista apropiada aún si es informal, en la Internet.

Con mucha diferencia, la mejor de tales listas es la presentada por mcarrillo en su blog http://mcarrillo.wordpress.com/ en el post titulado Factores de la calidad del software donde nos menciona las siguientes cualidades o factores de calidad:

  1. Eficiencia: La eficiencia de un software es su capacidad para hacer un buen uso de los recursos del ordenador.
  2. Portabilidad: Es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
  3. Fácil de usar: Cuando el usuario puede comunicarse con él de manera cómoda.
  4. Compatibilidad: Facilidad de los productos para ser combinados con otros y usados en diferentes plataformas hardware o software.
  5. Corrección: Facilidad para solucionar los problemas que puedan presentarse.
  6. Extensibilidad: Facilidad que tiene los productos de adaptarse a cambios en su especificación.
  7. Robustez: Capacidad que tiene los productos de software de funcionar incluso en situaciones anormales.
  8. Verificabilidad: Es la facilidad de verificación de un software, es decir, probar que el software funcione correctamente.
  9. Reutilización: Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
  10. Integridad: Es la capacidad de un software de proteger sus propios componentes contra los procesos que no tengan el derecho de acceder.

Dichas cualidades se sabe que están presentes o debieran de estar presentes, en todo software de calidad. En cierta forma, al igual que con todos los modelos de calidad industriales, la lista es el resultado de la experiencia acumulada por el sector y tiene por detrás cierto nivel de teoría.

Así que valga la lista como referencia para cosas futuras.

, , , , ,

4 comentarios