Como creamos una aplicacion web en drails

En Drails seguimos un desarrollo por etapas definido desde el primer día. Preferimos seguir todas las fases para obtener un resultado óptimo. Seguimos el proceso que puedes ver a continuación para que lo conozcas de antemano:

¡Tienes una idea!

Todo parte de una idea que puedes tener acerca de un proyecto de empresa, producto o servicio que necesite de una página web. Ahora necesitas apoyo tecnológico.

Reunión inicial

  • Datos de proyecto
    Documento

    Datos de proyecto

    Documento con información general del proyecto.

    Datos acerca del perfil del usuario al que está destinado, cuales son los problemas actuales, perfil de la empresa, historia y visión empresarial, persona al cargo del área de la web, puntos fuertes y débiles y un largo etc.

    No es obligatorio, pero este documento nos ayuda a orientar nuestras etapas posteriores.

  • Requisitos funcionales
    Documento

    Requisitos funcionales

    Documento con descripciones breves de todas las funcionalidades que se esperan de la aplicación web.

    Por ejemplo si se pueden registrar usuarios, o incluir comentarios, etc.

    Sufrira cambios a lo largo del desarrollo, ya que a menudo los tests a los usuarios revelarán posibles mejoras.

  • Guión gráfico
    Documento

    Guión gráfico

    Complementando a los requisitos funcionales es probable que se añada este documento.

    Es un prototipo en papel de la aplicación web.

    Sirven para dar una idea visual de lo que se espera del proyecto y simplificar de alguna forma los requisitos funcionales.

Lo primero es que te pongas en contacto con nosotros para ver de que manera te podemos ayudar. Concretaremos una cita para que nos expliques esa gran idea que tienes. En caso contrario, si no es posible vernos en persona, inicialmente siempre podemos estudiar más el proyecto por teléfono, correo electrónico o google hangouts.

Después de esta fase se redactarán varios documentos: los datos del proyecto, los requisitos funcionales y un guion grafico.

Presupuesto del proyecto

  • Presupuesto
    Documento

    Presupuesto

    El presupuesto puede ser abierto, donde nos pides unos requisitos o funcionalidades y calculamos su precio o cerrado, donde nos indicas un importe máximo y tratamos de incluir todas las funcionalidades posibles.

Modificaremos los requisitos funcionales para adaptarlos a tu presupuesto o bien, a partir de tus requisitos te daremos uno. Has de tener en cuenta que a menudo los test a los usuarios revelaran posibles mejoras o funcionalidades no necesarias y por tanto el presupuesto y los requisitos funcionales pueden variar (siempre bajo tu consentimiento).

Te pediremos que firmes la aceptación de los requisitos funcionales además de una señal para comenzar con el proyecto.

Design sprint

  • Bocetos
    Documento

    Bocetos

    Bocetos variados del interfaz del usuario . Se dibujan a partir de todas las ideas en el design sprint.
  • Wireframes
    Maqueta

    Wireframes

    Es una version mas elaborada del interfaz del usuario. Se obtiene a partir de los bocetos.
  • Prototipo en papel
    Maqueta en papel

    Prototipo en papel

    Diseños a partir de los wireframes para ser probados directamente en los usuarios. Se empleara papel ya que permite hacer correcciones del interfaz de usuario en tiempo record.
  • Maqueta de diseño
    Imagen

    Maqueta de diseño

    Imagen del aspecto que podria tener alguna/s pantallas de la aplicación web una vez acabada. Útil para proyectos donde la imagen es una parte fundamental del proyecto.
  • Maqueta en HTML
    Maqueta

    Maqueta en HTML

    Maqueta semifuncional de la aplicación donde se puede apreciar algunas interacciones del usuario.

En esta fase se definirán los elementos del interfaz de usuario. Puede durar entre 3 y 5 días. Es una fase importante, pues detectando errores a largo plazo se ahorra tiempo y trabajo.

1. Entender el problema y crear soluciones

El primer día se intentará comprender el problema actual existente. Se generarán multitud de ideas, se apuntarán todas ellas en notas y se harán bocetos en papel de posibles diseños de la aplicación.

2. Acotar las ideas

El conjunto de ideas generadas se simplificará con las que realmente son útiles. Una aplicación web deberá ser fácil de entender por parte de sus usuarios. El objetivo es obtener el producto mínimo viable (MVP).

3. Crear prototipo semi funcional y probar en usuarios

A partir de los bocetos seleccionados, dependiendo del estado actual del proyecto se generará una versión semi-funcional (wireframes,prototipos en papel , maqueta de diseño o maqueta en HTML) para ser probada en usuarios específicos. Este prototipo será el que se pruebe en usuarios comprobando que el interfaz de usuario es fácil de entender y que genera una buena experiencia al usuario (UX). . Preferimos que el cliente seleccione a los usuarios de prueba, ya que él siempre conoce mejor el tipo de cliente al que se dirige la aplicación.

Organización del proyecto

  • Presupuesto
    Documento

    Presupuesto

    El presupuesto puede ser abierto, donde nos pides unos requisitos o funcionalidades y calculamos su precio o cerrado, donde nos indicas un importe máximo y tratamos de incluir todas las funcionalidades posibles.
  • Requisitos funcionales
    Documento

    Requisitos funcionales

    Documento con descripciones breves de todas las funcionalidades que se esperan de la aplicación web.

    Por ejemplo si se pueden registrar usuarios, o incluir comentarios, etc.

    Sufrira cambios a lo largo del desarrollo, ya que a menudo los tests a los usuarios revelarán posibles mejoras.

  • Design Brief
    Documento

    Design Brief

    No es más que un documento de orientación técnica que de forma coloquial describe la funcionalidad esperada de la interfaz del usuario.

    Ayudará a nuestros desarrolladores en la implementación y codificación.

  • Calendario de desarrollo
    Documento

    Calendario de desarrollo

    Podremos dividir la aplicación en funcionalidades separadas (por ejemplo registro de usuarios, creación de elementos, etc). Para cada una de estas funcionalidades se estimara su duración en el tiempo y una fecha aproximada en la que los usuarios de pruebas pueden realizar su evaluación.
  • Esquema de base de datos
    Documento

    Esquema de base de datos

    El esquema de la base de datos define las relaciones entre los distintos objetos o modelos de la aplicación.
  • Pruebas de usuario
    Prueba

    Pruebas de usuario

    Con alguna de las maquetas existentes se pide a posibles usuarios que ejecuten acciones y se comprueba la efectividad del interfaz del usuario.

    Encontrar pronto defectos o problemas repercute positivamente en los tiempos de entrega y en su presupuesto. Por ello es una parte fundamental de un proyecto.

  • Especificación técnica
    Documento

    Especificación técnica

    En caso de que la aplicación sea de múltiples sistemas interconectados (cluster) o sea de considerable complejidad, realizaremos una especificación técnica donde se detallen cada uno de los sistemas o elementos.

A partir de los datos de las fases anteriores ya tendremos suficiente información para hacer un cálculo más riguroso acerca de la aplicación.

Puede ocurrir que los cambios adicionales sean de funcionalidad añadida y no entren dentro del presupuesto inicial. De igual forma puede ocurrir que en tu idea inicial hayas añadido demasiada funcionalidad extra y desaconsejemos su implementación inicial de acuerdo al MVP. Por lo que consultaremos de nuevo contigo, y si nos das tu conformidad, modificaremos los requisitos funcionales y el presupuesto.

Desarrollo y codificación

Es el corazón del desarrollo de todo proyecto. Con la documentación generada en las fases anteriores podemos empezar a desarrollar la aplicación.

Cada vez que terminemos una funcionalidad, subiremos el nuevo código a un servidor de pruebas (microrelease) para acceso del cliente y de los usuarios de pruebas (testing). En base a las pruebas de los usuarios y de la opinión del cliente se podrán hacer modificaciones en el proyecto.

El ciclo de microrelease - testing se repetirá por cada funcionalidad de la aplicación hasta la finalización de la misma.

Periodo de soporte gratuito

Durante este periodo resolveremos todas tus dudas acerca de la aplicación, su funcionamiento así como posibles errores.