Proyecto Kinect: Metodología de diseño centrado en el uso

A continuación se detalla, en qué consiste la metodología de diseño centrado en el uso, el por qué de su elección y los diferentes modelos a realizar para conseguir la elaboración final del sistema.

La metodología de diseño centrado en el uso propone un proceso sistemático basado en modelos abstractos para diseñar un sistema de la forma más sencilla posible, siendo éste compatible con todas las tareas que los usuarios necesitan llevar a cabo.

La elección de esta metodología viene motivada a que la aplicación gira en torno a diferentes usuarios objetivo que necesitan llevar a cabo diferentes tipos de uso de la aplicación. Esta metodología, por tanto, está enfocada y considera especialmente el uso que el usuario hace o hará de la aplicación, es por ello que se trata de la metodología idónea para llevar a cabo el desarrollo de este proyecto y facilitar un producto software con garantías de éxito y aceptación.

El diseño centrado en el uso descansa en la elaboración de tres modelos abstractos estrechamente relacionados que se siguen en este TFG. Estos modelos son: modelo de roles, modelo de tareas y un modelo de contenidos.

• El modelo de roles captura las características más destacadas de los papeles que desempeñan los usuarios en relación con el sistema.
• El modelo de tareas representa la estructura del trabajo o los pasos que los usuarios necesitan llevar a cabo en relación con el sistema.
• El modelo de contenidos representa los contenidos y la organización de la interfaz de usuario, necesarios para apoyar las tareas identificadas en el modelo de tareas.

Proceso basado en modelos abstractos en el diseño centrado en el uso

Conceptualmente, una derivación sencilla y directa une el diseño final a los casos de uso que apoyan los roles de usuario. Cada pantalla, formulario u otra interacción corresponden a un prototipo abstracto que apoya un grupo de casos de uso interrelacionados.

Este post, pese a que es teórico, lo creo muy importante en la ayuda que supone para la realización del proyecto. Se trata de aplicar y seguir una metodología que aporta las pautas y relaciones necesarias para que todo encaje de la mejor manera en el proyecto.

Nota: todos los modelos realizados para el diseño del sistema los puedo compartir previa solicitud en forma de comentario en este mismo blog.

Álvaro Alcolea

Kanban, como método productivo en el desarrollo software

El trabajo en equipo cobra una gran importancia cuando hablamos de productividad en la gestión de proyectos. Para conseguir una alta productividad en el equipo de trabajo tiene que haber una buena organización y una gran coordinación. El método que comento en este post trata de dividir el proceso productivo en varias fases claramente delimitadas, con el único objetivo de mejorar la eficiencia y el trabajo en equipo.

Kanban es una palabra de origen japones que significa algo así como "tarjetas visuales", las cuales son un elemento clave de este método productivo. Surgió en Toyota, el fabricante japonés de automóviles, para poder mejorar su producción de vehículos dividiendo el proceso en fases bien delimitadas que se tenían que cubrir correctamente para pasar a la siguiente fase, garantizando con ello un producto de calidad. De ese sistema originario surge el método Kanban, pensado y aplicado por David J. Anderson, con el que adapta la filosofía original al desarrollo de software, un proceso que se asemeja bastante al proceso industrial. Se trata de fijar diferentes fases, equipos de trabajo y el requisito de que cada tarea funcione correctamente y sea de la mayor calidad.

Objetivos

• Lograr un producto de calidad.
• Acabar con el caos, gestionar la saturación y los cuellos de botella.

Principios básicos a seguir

• Comienza con lo que haces ahora. Kanban es un método productivo y, como tal, no dice cómo hacer el trabajo. El equipo de trabajo debe saber como hacer su trabajo y será Kanban el que mostrará si se está haciendo bien o si por el contrario hay que cambiar algo.
• Mejora continua. Este método apuesta por el lema de "si algo no funciona, cámbialo" o "si algo puede funcionar mejor, mejóralo". Los miembros del equipo deberán estar preparados para la aplicación de cambios continuos, con el objetivo de mejorar sus rutinas de trabajo.
• Respeta el proceso en curso, los roles y funciones de cada miembro del equipo. Los miembros del equipo deben saber lo que tienen que hacer y cuáles son sus funciones en cada momento.
• Un líder para cada nivel. Se trata de tener iniciativa y realizar una gestión correcta de la tarea que tengas asignada. Se trata de que cada subgrupo de trabajo y cada miembro que lo compone tenga clara su función y la ejecute correctamente.

Elementos que debe incluir un sistema o método productivo

1) Visualización del flujo de trabajo: se debe crear un tablero, que tiene que ser visible y accesible para todos los miembros del equipo. Además el tablero incluye una serie de fases que indican los pasos por los que debe pasar una tarea (en progreso, realizadas, bloqueadas, etc.).

2) Limitación del trabajo en curso (Stop Starting, Start Finishing): la tarea que se empiece debe terminarse antes de empezar con otra tarea. Con esto se prioriza el trabajo y las tareas de mayor importancia son terminadas antes de empezar con otras.

3) Gestión del flujo: es necesario controlar el funcionamiento del proyecto, se trata de comprobar si las tareas son realizadas correctamente, o por el contrario, si algún miembro tiene problemas con alguna tarea.

4) Dejar claras las reglas del método: se debe entender el método y las reglas a seguir por cada miembro del equipo.

5) Mejora en equipo: la mejora constante cobra importancia en este método, la mejora del proyecto debe verse a través de los recursos que tenemos y de la experiencia de los miembros del equipo.


Para terminar les dejo un vídeo que explica todo el proceso de una forma más esquemática:

Visto este método se pueden sacar ventajas, como por ejemplo, flexibilidad a la hora de realizar el flujo de tareas, priorizar las mismas y, además, la supervisión del equipo a través de un tablero de tareas.

Les animo a utilizar este método y comprobar sus resultados.

¡Saludos!

XP (Xtreme Programming), una metodología 'agile' (Parte II)

En la Parte I se hablaba de expresar la metodología de programación extrema a través de diferentes prácticas, en concreto unas 12: (en lengua inglesa puede verlas haciendo click aquí)

Foto extraída de www.xprogramming.com

1. Equipo completo, forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
2. Planificación, se hacen las historias de usuario y se planifica en qué orden se van a hacer. La planificación se revisa continuamente.
3. Versiones pequeñas, las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que puedan ser vistas funcionando.
4. Test del cliente, el cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
5. Diseño simple, hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
6. Pareja de programadores, los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
7. Desarrollo guiado por las pruebas automáticas, se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se realicen, mejor.
8. Integración continua, se debe tener siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recopilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando fallara algo, no se sabría qué es lo que falla de todo lo que habíamos metido.
9. El código es de todos, cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
10. Normas de codificación, debe formalizarse un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
11. Metáforas, hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
12. Ritmo sostenible, se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer. Tampoco se debe hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.

Pese a que personalmente no he hecho uso (aún) de esta metodología que acabo de comentar, su uso y sus practicas las recomiendo encarecidamente. Su uso es recomendable, en primer lugar, por su programación organizada y satisfacción que proporciona al programador, y en segundo lugar, por su aplicación en proyectos programados a corto plazo y con condiciones de altas comisiones en caso de fallo.

¡Saludos!

XP (Xtreme Programming), una metodología 'agile' (Parte I)

XP es una metodología desarrollada por Kent Beck en el verano de 1996:

"Todo en el sofware cambia. Los requisitos cambian. El diseño cambia. El negocio cambia. La tecnología cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en sí mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando éste tiene lugar"

Es una metodología ligera para el desarrollo de software basada generalmente en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado. Es la metodología más destacada entre todos los procesos y metodologías ágiles de desarrollo software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Aquellos que defienden XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. 

Su principal objetivo es aumentar la productividad al desarrollar software. Además del anterior objetivo se plantean otros como:

• Satisfacer al cliente.
• Potenciar el trabajo en grupo.
• Minimizar el riesgo actuando sobre las variables del proyecto: coste, tiempo, calidad y alcance.

Los valores que inspira esta metodología entre otros son:

• Comunicación.
• Sencillez.
• Retroalimentación.
• Valentía y coraje.

Las características en las que se basa:

• Basada en prueba y error.
• Fundamentada en valores y prácticas.
• Expresada en 12 prácticas esenciales, que se soportan unas a otras.

Hasta aquí la entrada de hoy, en la parte II ilustraré las practicas esenciales comentadas en las características.

¡Saludos!

Sé 'Agile', principios de las metodologías ágiles

Las metodologías ágiles para el desarrollo de software surgen ante la necesidad de ofrecer una alternativa a las metodologías tradicionales, caracterizadas por ser más pesadas, rígidas y dirigidas por la documentación que va siendo generada en cada una de las actividades desarrolladas.

En 2001 se realiza una reunión de expertos en la que se acuerda el denominado Manifiesto Ágil, poniendo al descubierto los mejores métodos para desarrollar software. 

Los 12 principios incluidos en el manifiesto son los que siguen: 

• Nuestra mayor prioridad es satisfacer al cliente a través de una entrega temprana y continua de software de valor.
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.
• Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
• La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.

En próximos post comentaré las metodologías ágiles de más relevancia en la actualidad.

Un saludo!

¡Bienvenida!

Bienvenidos,

este es mi blog, llamado "Un mundo de ingeniería". En él trataré de escribir de la forma más continuada posible, mostrando todo aquello que considere de interés y para lo que me encuentre investigando. 

Las vivencias, experiencias, conocimientos y competencias adquiridas hasta el momento me hacen sentirme con la obligación y necesidad de que, poco a poco, pueda compartirlas a través de este blog.

Si bien, aunque soy experto en la rama de informática y dentro de ella experto en tecnologías de la información, llegará el momento de hablar de otras ramas de ingeniería que puedan estar en conjunción con la primera. Las necesidades de tiempo, por ejemplo, impiden estudiar todo aquello que a uno le apasiona, en mi caso las ramas dedicadas a la aeronáutica, el diseño industrial, las telecomunicaciones, etc. 

En algunos casos varias ramas de ingeniería se encuentran y se tiene la necesidad de unirlas para crear algo extraordinario. Esa unión la tenemos presente en una gran mayoría de productos, como por ejemplo aviones, teléfonos móviles, y todo tipo de aparatos en los cuales tengamos una serie de tecnologías unidas y ensambladas para un único fin. La correcta unión de esta serie de tecnologías y ramas de investigación hace que podamos crear aquello que nos propongamos.

Por tanto, con este blog intentaré mostrar aquellas tecnologías que sean novedad para la sociedad y que puedan aportarnos algo bueno, con el claro objetivo de aprenderlas y aplicarlas al mundo.

Les dejo con un pasaje de la película Matrix (1999) con el que termino esta bienvenida.

- Ya era hora. Bienvenido. Supongo que ahora te sentirás un poco como Alicia cayendo por la madriguera del conejo.

+ Es posible.

- Puedo verlo en tus ojos.

(...)

- Esta es tu última elección. Después ya no podrás echarte atrás.

Si tomas la pastilla azul, fin de la historia. Despertarás en tu cama y creerás lo que quieras creerte.

Si tomas la pastilla roja te quedarás en el país de las maravillas, y yo te enseñaré hasta donde llega la madriguera del conejo.

(...)

- Recuerda. Lo único que te ofrezco es la verdad. Nada más.

Renunciemos a la plácida felicidad que otorga la pastilla azul y adentrémonos al mundo real. 

Un saludo a todos.