Categoría : Diseño

La imagen es el reflejo de la empresa

post image

Por Mariu Castejón
Designer at OpenSistemas

Vivimos en un mundo en el que estamos bombardeados con imágenes de todo tipo. El uso adecuado de ella y en nuestro propio beneficio es crucial para la supervivencia de una empresa en el mercado.

En una empresa, da igual del tamaño que sea, la importancia de la imagen es algo esencial, ya que esta proyecta significativamente la reacción ante el público y, además, la imagen a parte de representar a nuestra empresa debe de perdurar en el mercado actual tan competitivo.

Leer Más →

Botton of the Ninth, el arte aplicado a las tecnologías

Por Facundo Ferré Luparia
Web Designer de OpenSistemas

Los pioneros en el arte, clásicamente, han sido los que se han descubierto como exploradores de su propio medio en lugares hasta el momento intactos. Cuando el medio cambia, no tardan en surgir nuevas formas de expresión encabezadas por un primer paso. La evolución del medio digital proporciona una tabla rasa sobre la que volver a crear y descubrir. Tal es el caso de Ryan Woodward, conocido ilustrador y profesor de animación, conocido en gran parte por su cortometraje Thought of you.

Leer Más →

Less Is More

Por Soledad Carracedo Junior Open Source Consultant de OpenSistemas He querido recoger en este post algunas de las tendencias en diseño que estarán presente en este 2014: simplicidad, responsive, simplicidad y diseño multidispositivo. Diseño plano y simplicidad… cogidos de la mano La tendencia en diseño web es ir a lo plano para llegar fácilmente a […]

Leer Más →

Blender

En este post, he decidido hablaros de una herramienta llamada Blender, la cual ha sido el instrumento principal en la realización de mi PFC en la Universidad Politécnica de Madrid. El proyecto consistía en la simulación de efectos meteorológicos, tales como avalanchas o incendios, y a pesar de que en un principio la utilización de […]

Leer Más →

Listado de características v/s Casos de Uso.

Se supone que cuando empezamos en un desarrollo tenemos un listado de características con lo que debe hacer el sistema y luego hacemos nuestros Casos de Uso. El tema es ¿Cuál debo hacer?, ¿Es mejor cumplir una característica completa? o ¿enfocarnos en los casos de uso?, la respuesta es “depende“.

Plantéo el siguiente escenario:

La aplicación debe :

  • Enviar un SMS que indique tiempo al cual se encuentra un Autobus desde un paradero al recibir un SMS con el siguiente formato: “Paradero LineadeAutoBus” Ej.: 105 591

Esto de “la aplicación debe” son nuestro Listado de Características.

Y como consecuencia de este Listado de Características obtenemos los famosos Casos de Uso, que serán nuestra compañía el resto del desarrollo.

Los Casos de Uso son:

¿Con que partimos para desarrollar?, pues tenemos las 2 alternativas:

  1. Realizar la Característica 1.
  2. Realizar un caso de uso.

Para decidir se considera el nivel de visibilidad comprometido, si el cliente tiene un poco de paciencia podemos partir por los casos de uso; si no partimos con la característica.

Estoy seguro que el desarrollo con casos de uso nos permitirá un diseño elegante desde un primer momento, pero que a lo mejor tardaremos un poco más en mostrar algo completo – recordemos que los clientes quieren resultados, no diagramas de Ingeniería que sólo nosotros entendemos – debemos hablarle en su lenguaje.

Si tenemos un poco más de tiempo conviene comenzar con los Casos de Uso, si no tratemos más “visual” el entregable y realizemos primero alguna de las características. Finalmente el producto tendrá la calidad de hacer lo que tiene que hacer, de haber aplicado principios de OO y la elegancia de los patrones de diseño.

Leer Más →

Cultura de Prototipos/Maquetas

Como todos sabemos – pero nos cuesta aceptarlo – la única constante en Desarrollo de Software es el cambio.

El maldito cambio, simplemente debemos ser más inteligentes: Tener en la cabeza que las cosas cambian y que nuestra obsesión por implementar funcionalidad lo antes posible con classes perfectas nos lleve a codificar de más.

¡Pero un momento!, ¿codificar de más?, si – aunque me costó creerlo mientras antes se empieza a escribir código más tarde finalizaremos el proyecto.

¿Por qué?, por que nuestra obsesión no considera que los cambios ocurrirán y que el cliente simplemente quería otra cosa, o se ajustó esta regla de negocio y tal, y tal, y tal, y tal …….

Solución: Cultura de Prototipo.

  1. Conversamos con el cliente.
  2. Formalizamos lo conversado en una Lista de Características.
  3. Revisamos con el cliente esta lista.
  4. Especificamos los requisitos de las características que tienen mayor prioridad.
  5. Hacemos un protipo – sin funcionalidad.
  6. Revisamos con el cliente el Prototipo/Maqueta (que tardamos a lo más 2 horas en hacerlo con HTML o drag&drop), revisamos la Lista de Características y así nos aseguramos que vamos bien con el cliente.
  7. Repetimos en cada iteración que sea necesario.
  8. Continuamos con los paso habituales de Desarrollo Iterativo e Incremental.

Se ve muy simplista, estoy de acuerdo, lo importante es que ya estamos listos para:

  1. Asegurar que el sistema hará lo que el cliente quiere.
  2. Aplicar principios de OO.
  3. Aplicar patrones de Diseño y le damos caracter de Ingeniería a la obra de arte.

En ese orden, funciona créanme!.

Con un gran amigo aprendimos que no hay que mostrar los diagramas de classes, ni nada parecido al cliente. Le mostramos los artefactos en su propio lenguaje: Un listado de características en el cual identifique cláramente lo que quería.

A pesar de todo esto siempre surgirán nuevos cambios, pero ya tendremos una arquitectura extensible y no hemos perdido horas de trabajo de implementación – No existen malos equipos, sólo malos líderes.

¿Si, te parece que eso lo implementemos en la próxima versión?

Leer Más →

1 2