Diego Lopez Castan

Requerimientos Funcionales y No Funcionales

Diego — Wed, 16 May 2012 14:39:47 +0000

En un post anterior indiqué que eran los requerimientos , éstos indican que es lo que el sistema debe hacer, no en como debe hacerlo.

Los requerimientos se pueden dividir principalemente en dos grupos, un grupo que depende de las funciones y otro que depende de a quienes está definido.

Dentro de los requerimientos que definen funcionalidades se puede dividir en funcionales y no funcionales.

Requerimientos Funcionales :
Define la funcionalidad o las caracteristicas que el sistema deberá contar.
Como debe el sistema actuar ante diferentes circunstancias o errores.

Requerimientos No Funcionales :
Define restricciones adicionales con el que el sistema deberá contar.
Tambien indica limitaciones, prohibiciones y propiedades emergentes.

La otra definicion tiene que ver con a quien va dirigido el requerimiento:

Requerimientos de Usuarios:
Están dirigidos a los usuarios y clientes del sistema. Se redactan usando lenguaje natural para que cualquiera pueda entenderlos.

Requerimientos de Sistema:
Están dirigidos a las personas con skills técnicos, como ser analistas, programadores, arquitectos, etc.
Son escritos en un lenguaje técnico y mucho más preciso.

Wireframe

Diego — Wed, 16 May 2012 13:28:54 +0000

Se llama wireframe a los prototipos de baja fidelidad (calidad) ya sea de una página web o de una pantalla de la aplicación.
También se los suele llamar prototipos de bajo nivel, porque no tiene todas las caracteristicas de la aplicación esto hace que sea más fácil la modificación del mismo.
El objetivo principal que persigue es identificar los principales elementos como ser:

menú de navegación
secciones
imagenes/fotografias
elementos de los formularios
Calls to actions

Son tipicamente creados en blando y negro o tonos de grises.
Se utilizan para tener un rápido feedback de los usuarios.
La principal ventaja de los wireframes sobre otro tipo de representación de una app o una página es que es muy fácil modificarlo ya que no contamos con ninguna codificación.

Los wireframes pueden tener anotaciones como ser:

Identifiación del contenido
Contenido de la fuente de los datos.
Reglas para mostrar la información.
Reglas de proceso.
Errores.

Links herramientas wireframe:

Usuarios y el cambio

Diego — Thu, 03 May 2012 13:23:19 +0000

Es conocido que los usuarios “siempre” se resisten el cambio, generalmente esa resistencia se debe a sentimientos de miedo provocado por una incertidumbre ante lo desconocido.

En psicología existen tres zonas que identifican el aprendizaje estas son:

Zona de Confort: En ésta zona nos sentimos cómodos, seguros, en la que dominamos lo que estamos haciendo.
Zona de Aprendizaje o Desafío(Expansión): aquí nos encontramos ante situaciones nuevas que requieren nuestra atención para poder resolverlas, pero no generan miedo.
Zona de Pánico: en ésta zona se activan nuestras alarmas interiores, esto se debe a que consideramos que el desafío es de un nivel alto según nuestras capacidades. Los sentimientos de ira, pánico y ansiedad bloquean nuestra conducta y nos dificulta el hecho de poder aprender nuevos elementos.

El aprendizaje es una actividad que necesita un esfuerzo. El usuario toma un rol activo porque requiere de su voluntad y de su acción para moverse de una zona de confort zona que se llama de expansión.

Cuando diseñamos unas nuevas aplicaciones debemos minimizar el cambio debemos tener en cuenta las siguientes tareas:

Buscar patrones de diseño
Hacer metáforas
Hacer interfaces simples y autoexplicables
Incluir solo lo esencial en la interfaz

Requerimientos

Diego — Thu, 03 May 2012 13:16:34 +0000

“Un requerimiento es un servicio que el sistema de software debe satisfacer o una restricción bajo la cual el sistema debe operar”. [Sommerville 2002]

Un requisito define alguna actividad que el sistema debe ser capaz de hacer, o alguna restricción que éste debe realizar para que pueda cumplir con el objetivo requerido por el usuario.

El proceso de recolección de requerimientos es sin lugar a duda la fase más importante de la ing. del software.
Se suele indicar que existe un alto porcentaje de proyectos de desarrollo de software que suelen fallar porque:

Los requisitos se encuentran incompletos
Cambios constantes en los requisitos y las especificaciones
El sistema o la aplicación ya no es útil
Falta de participación del usuario
Expectativas poco realistas

El gran secreto de la definición de requerimientos es tener en claro realmente cual es el problema, y no caer en la ilusión de conocimiento.

Que son las Personas?

Diego — Wed, 02 May 2012 04:12:05 +0000

La generación de los documentos de Personas describen el target típico de los usuarios que utilizarán nuestra app o nuestro site.

Los diseñadores de UX crean los documentos Personas para crear un sentimiento de empatía, es decir para poder identificarse con los usuarios del sistema.

El contenido básico de la persona debe ser:

Foto
Nombre
Edad
Dirección
Ocupación
Biografía

Contenido Opcional:

Nivel de educación
Rango de salario
Citas personales
Actividades o hobbys
Conocimiento técnico
Conocimiento de redes sociales
Conocimiento sobre celulares
Motivación que lleva a usar nuestro producto
Objetivo

Obviamente los datos pueden ser reales o inventados.

Ilusion de Conocimiento

Diego — Wed, 02 May 2012 03:47:18 +0000

Antoni Gaudi comenzó a dirigir la construcción de la iglesia de la sagrada familia en Barcelona en 1886 y dijo que la construcción terminaría en 10 años. La conclusión de la obra está proyectada para 2026.

Solemos creer que tenemos profunda comprensión de como funcionan las cosas, pero esto no siempre es así. Se confunde saber que ocurre, con porque sucede. Es decir, se confunde el sentimiento de familiaridad como conocimiento genuino.

Otro ejemplo de Ilusión de conocimiento es la Opera House de Sidney. Ésta obra fue encargada por el gobierno Australiano en 1959. En 1960 se hizo análisis de cuanto costaría llevarla a cabo y se determinó que sería 7 millones de dolares. Al terminar la obra se determinó que el proyecto terminó costando 45 millones de dolares.

Hay que tener en cuenta la ley Hofstadter, ésta sostiene que siempre se lleva más tiempo del que esperabas incluso cuando tenes en cuenta la ley Hofstadter.

Killer features

Diego — Fri, 27 Apr 2012 15:32:47 +0000

Que es lo que tiene que tener nuestra app o programa para que sea famosa o que esté dentro del top 10? la respuesta es fácil … que tus apps tenga Killer features.

Este concepto se refiere a las funciones que hacen que una aplicación se diferencie del resto los programas del mercado.

Para explicarlo mejor está el ejemplo de Instagram, si bien existían varios servicios para compartir fotos (como flickr, tumblr, facebook o fotologs), la funcionalidad que se agrega es la de poder retocar las fotas de una manera sencilla y que parezcan profecionales, utilizando un sentimiento de “nostalgia”.

Esta aplicación primero salió para Apple OIS, ante la gran cantidad de usuarios registrados, se creo la version para el SO Android.
Instagram fue noticia porque hace unos días fue comprado por Facebook por 1000 millones de dólares. Info.
Instagram cuenta con más de 30 millones de usuarios, a lo que se puede agregar que Facebook ha pagado 33 dólares por usuario.

Que es el Scrum?

Diego — Fri, 27 Apr 2012 13:57:38 +0000

Scrum es una metodología ágil, que nos permite crear marco de trabajo para la gestión y desarrollo de software. Ésta metodología fue creada por Hirotaka Takeuchi e Ikujiro Nonaka en el año 1986, pero se adoptó como metodología de desarrollo de sistemas hace pocos años.
El proceso que describe el Scrum es iterativo e incremental.
Scrum define roles principales en Scrum son:

ScrumMaster: mantiene los procesos y trabaja de forma similar al director de proyecto.
Product Owner, que representa a los stakeholders (interesados externos o internos),
Team que incluye a los desarrolladores.

Scrum se divide en sprints, éstps son periodos que pueden variar entre una y cuatro semanas. Al termino de cada spring se debe realizar una entrega, sea parcial o total.

El sprint va a estar formado por requerimientos que son mantenidos en un listado llamado Product Backlog. Éstos requerimientos son a muy alto nivel, antes de que se empiece con el spring el requerimiento se va a analizar y separar en tareas más pequeñas. La prioridad de cada uno de los requerimientos se van a analisar en la reunión llamada Sprint Planning.
Para realizar el seguimiento de las tareas diariamente se realizan las reuniones llamadas daily meeting. Ésta reunión debe ser muy corta alrededor de 15 minutos. Durante la reunión, cada participante del equipo debe contestar tres preguntas:

¿Qué has hecho ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?.

En scrumrf se puede encontrar una muy fácil herramienta para definir ciclos sprints, llevar el backlog y definir las tareas.

Usabilidad 101

Diego — Fri, 27 Apr 2012 13:52:09 +0000

Quería compartir éste video en el cual se muestra con ejemplos concretos los problemas de usabilidad. Muchos de éstos problemas son por problemas de diseño otros tienen que ver con el contexto.

Video:

httpv://www.youtube.com/watch?v=evoa-ULOb0Y&feature=player_embedded

Casos de uso y Usabilidad

Diego — Fri, 27 Apr 2012 13:44:49 +0000

Los casos de uso son una excelente herramienta para poder describir el workflow de nuestra aplicación.
Con los casos de uso se puede obtener las interacciones que el usuario y el sistema realizan.
Tan importante como los pasos del caso de uso son las excepciones en ellas debemos completar cual es la interaccion que debe realizar el sistema.

El caso de uso debe tener los siguientes campos:

Id del requisito = identificación del caso de uso.
Nombre del requisito funcional = nombre del caso de uso.
Descripción = Breve descripción del caso de uso.
Precondición = Precondición del caso de uso, son los elementos necesarios antes de empezar con la tarea.
Secuencia = Secuencia del caso de uso paso a paso.
Postcondición = Postcondición del caso de uso, que sucede al terminar de realizar la tarea.
Excepciones = Excepciones por cada secuencia, describe las acciones que se deberán realizar si la secuencia no es correcta.