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

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!