Herramienta de apoyo en la creación de

una aplicación para un dispositivo móvil

Introducción:
Este documento apoya en la realización de una aplicación móvil. Se describe el proceso de preparación
aplicado en la fases de análisis y diseño que soportan un desarrollo exitoso. La aplicación puede ser
ejecutará en dispositivos iOS o Android, al igual que una aplicación web, o incluso una aplicación de
escritorio para Mac o Windows.

Este documento está dividido en dos secciones.

1. El primero, Ideas y Objetivos, es donde se colocan las ideas básicas para la aplicación.
2. En el segundo, Diseñando la especificación, se colocan los detalles de lo que se supone que
debe hacer la aplicación.
 CREANDO UNA APLICACIÓN ESPECÍFICA
PARTE UNO
1. Ideas y objetivos

En esta primera parte del proceso, proporciona la información básica sobre quién es cliente, qué tipo
de aplicación se le hará y qué hará la aplicación.
1.1. Descripción de la compañía:
Nombre de la compañía :
Dirección: Ciudad: Estado: CP :
Nombre del Contacto principal: e-mail :
Teléfono:

1.2. Descripción de la aplicación:

Nombre del proyecto (Título del trabajo)

¿ Qué tipo de aplicación será esta? Marque todo lo que corresponda, incluso si no se realizarán hasta
una versión futura. Eso ayudará a planificar y ahorrar dinero a largo plazo.
iPhone/iPad Basado en web Android Macintosh Windows

¿Cuál es su presupuesto para la primera versión de la aplicación? remarcar

$0 - 5,000 ----- $5,000 - 20,000---- $20,000 - 50,000--- $50,000 - $100,000----
Arriba $100,000
¿Cuál es la fecha límite para la primera versión?:
¿Cuándo te gustaría comenzar?:

1.3. Fase de diseño

Antes de comenzar a programar la aplicación, se requiere saber exactamente qué se supone que
debe hacer. Esta fase de diseño implica tres áreas principales: apariencia, interfaz de usuario y
funcionalidad.
 La apariencia es el diseño visual básico, como logotipos, pantallas de presentación, ya sea
que atraiga a adultos o niños, etc.
 La interfaz de usuario son las pantallas, los botones, los menús, las listas y los mensajes
reales que definen cómo el usuario trabaja el programa.
 El diseño funcional es determinar exactamente qué hará el programa y realizar un
seguimiento de.
 ¿El cliente diseñará la apariencia de la aplicación, o se necesita que se le diseñe? Describir la
decisión:

¿El cliente diseñará la interfaz de usuario o se necesita que se le diseñe? Describir la decisión:

¿El cliente diseñará la funcionalidad de la aplicación o se necesita que se le diseñe? escribir la

decisión:

1.4. Detalles de la aplicación

Escriba una descripción general de toda la aplicación y lo que hace. Considere libre de revisar esta
descripción cuando piense en cosas nuevas que deberían cubrirse. Use más páginas si las necesita.
Cada hora que dedique a esta descripción le ahorrará dinero en trabajo de programador e ilustrador.
Cuanto más preciso sea, menos se tiene que adivinar.

1.5. Recursos
Muchas aplicaciones requieren recursos como imágenes y sonidos que deben adquirirse. Es posible
que podamos utilizar recursos preexistentes que ya tenga, o podemos necesitar licenciarlos de un
tercero o incluso crearlos desde cero.

También es posible que necesite licenciar datos de un tercero, como un diccionario, una biblioteca
de mapas o quizás una fuente RSS. Es necesario saber dónde obtener dicha información, y cuanto
más pueda obtener para disminuir o considerar algún costo extra.

Haga una lista detallada de todas las imágenes, sonidos, películas, bases de datos web, fuentes RSS y
otros recursos que necesitará para la aplicación. Al lado de cada elemento, marque "tener", "licencia"
o "nuevo".
(enumere los recursos necesarios aquí)
1.6. Fondos
OK, tenemos que pensar en esto. Hay varias maneras de financiar una aplicación móvil. Cuando
descubras cuál (o más) funcionará para ti, estás listo para continuar. A continuación se enumeran
algunos de los métodos comunes, junto con nuestros pensamientos sobre ellos.

1. La tienda de aplicaciones. Hay dos formas básicas de ganar dinero en iTunes Store de Apple o en
Google Play (Android) tienda.
 El primero es el precio real de la aplicación, y el segundo es la compra en la aplicación para
contenido adicional.
 En caso de que no lo sepas, Apple o Google obtienen un 30% de descuento en la parte superior
de cada aplicación vendida y también en cada compra integrada en la aplicación.
No hay ningún cargo por alojar aplicaciones gratuitas. En ese caso, deberá cubrir los costos de desarrollo
de otra manera, que es lo que cubre el resto de esta lista.
2. Uso interno. Algunas aplicaciones, ya sean vendidas en la tienda de aplicaciones o no, están
diseñadas para ahorrar mano de obra de la empresa o para crear otras eficiencias en su propia
operación. Podrá justificar el gasto por lo que la aplicación hará por su negocio, y luego venderlo
en la tienda de aplicaciones es solo una ventaja.
3. La promoción del producto. Su aplicación podría diseñarse para ayudar a vender un producto
físico. La aplicación es pagada por las ventas de ese producto que promueve.
4. Publicidad en la aplicación. Esto vale la pena si su aplicación es vista por un gran número de
personas. La publicidad en la aplicación puede no ser apropiada en aplicaciones para ciertos públicos,
como la educación.
5. Patrocinio. Su aplicación podría ser financiada por un tercero porque promueve sus intereses.
Apple y Google tienen ciertas restricciones con respecto a esto. Esta podría ser una gran estrategia
para una aplicación como un evento para recaudar fondos. Puede donar a la organización benéfica
mediante el uso de esta aplicación proporcionada por las buenas personas en tal o cual.
Por favor, especifique cómo planea financiar la aplicación usando estos métodos o cualquier otra
idea que tenga. (enumere las fuentes de financiamiento aquí)

Este es el final de la Parte Uno.

Cuando tenga en claro exactamente lo que su aplicación va a hacer, vaya a la Parte
Dos.
 La segunda parte

Diseñando la Especificación
 Este documento supone que ya ha completado la Parte Uno, Ideas y Objetivos. Ahora se puede
comenzar a diseñar la aplicación real.

2.1. Diseños de pantalla

Lo primero es diseñar los diseños de pantalla. No tiene que dibujar todas las animaciones que se
necesitarán, pero debe dibujar cada pantalla que aparecerá en el programa. Hágalo tan simple o tan
elegante como desee, pero hágalo detallado: todo el texto (o texto de marcador de posición) que se
necesitará, y marcadores de posición para cada elemento gráfico. Garabatos y figuras de palo son
suficientes. Trabajarás con un ilustrador en el detalle más adelante. Por ahora, la parte importante es
que pienses y demuestres todo lo que necesitarás. Como de costumbre, no eliminar todo en esta
etapa resultará en costos de mano de obra adicionales más tarde.

Copie esta página tantas veces como quiera y úsela para dibujar cómo se verá el programa en un
teléfono. Si se verá diferente en modo paisaje y retrato, use un dibujo separado para cada uno. Solo
gira la página de lado.
:
Description:
Screen:
Description:
Screen:

pág. 7
Copie la siguiente página tantas veces como quiera y utilícela para dibujar cómo se verá el programa
en una tableta. Especifique si esta pantalla se ejecutará en modo apaisado, modo retrato o ambos. Si
se ve diferente en paisaje y modo retrato, use una página separada para cada uno. Solo gira la página
de lado.

pág. 8
 2.2. Roles (opcional)

Enumera todos los diferentes tipos de usuarios que podrían usar esta aplicación. Por ejemplo, puede
tener un administrador que pueda configurar cuentas para otros usuarios. Es posible que tenga un
usuario habitual, o tal vez un usuario del cliente. La mayoría de las aplicaciones generalmente solo tienen
un rol, pero si tiene más, necesita documentar cuál es cada rol.

Después de cada usuario, especifique qué funcionalidad tendrá ese usuario y exactamente a qué
pantallas podrá acceder cada tipo de usuario. Es posible que necesite más de tres tipos de usuarios, pero
si lo hace, es posible que desee replantear su diseño.
Rol del usuario:

Pantallas

Rol del usuario:

Pantallas

Rol del usuario:

Pantallas

Rol del usuario:

Pantallas

pág. 9
2.3. Estructuras de datos
Esta es una parte difícil de la especificación. Sele ayuda con los detalles. Puede que solo tenga uno o
dos datos para grabar. Probablemente tengas docenas o más. Un programa complejo puede requerir
docenas de tablas con quizás docenas de campos.

La primera decisión es qué datos se guardarán (llamado persistencia), si hay alguno. Una aplicación
como un lector de noticias no guardará ningún dato. Un juego puede guardar tus puntajes. Una utilidad
puede guardar todo lo que haces. Debe averiguar qué datos persistirán y qué se perderán cuando el
usuario cierre su aplicación.

En segundo lugar, debe decidir dónde se almacenarán los datos. ¿Se almacenará solo en el dispositivo
del usuario? ¿Se transferirá a otros dispositivos o a alguna otra entidad de almacenamiento
permanente (como la "nube")? Como de costumbre, ningún almacenamiento de datos es el más
barato, y cuanto más ampliamente almacene y comparta sus datos, más costoso se vuelve.

Aquí hay un pequeño cuestionario para ayudarlo a determinar sus requisitos de almacenamiento.
1. ¿Almacenará el dispositivo alguna información, en lugar de perder todo cuando el usuario se
cierra?

2. ¿Se debe almacenar algo en un dispositivo o servidor remoto?

Especificar:

3. ¿Podrá el usuario seleccionar y enviar ciertos datos a otro usuario?

Especificar:

Sus datos se almacenarán en archivos en piezas llamadas tablas. Cada tabla contiene todos los
registros de un cierto tipo. Cada registro tiene una cantidad de campos que describen la entidad.
Necesita documentar todos los campos que será necesario almacenar. Los campos son más
típicamente texto o números. El texto es cualquier cosa que pueda escribir en el teclado. Los números
son solo números y decimales que describen el número. Por ejemplo:

Text
Numbers Apple
1 (763)555-1212
0
1+ 5 / 4 -7635551212
$1.99 1.99

pág. 10
La mayoría de los registros deben identificarse con un número de identificación. Cuando los registros
pueden ser creados por usuarios diferentes, en su lugar de un número que utilizamos un identificador
único que solo se puede crear en un dispositivo en el momento exacto en el tiempo. De esta forma, no
hay dos registros que puedan tener la misma identificación. Este identificador único se denomina UDID
en la tabla. Si desea una identificación que sea más legible para el ser humano, como un número de
factura, conviértalo en un número o texto.

Existen otros tipos de campos que puede necesitar, como una imagen o un archivo de sonido, una
matriz, que es una lista de objetos y datos en bruto, como una secuencia de mediciones de un
instrumento. Si comprende este tipo de campos, inclúyalos en su especificación. De lo contrario, te
ayudaremos con eso cuando lleguemos a ese punto.

Organice sus datos en tablas que describen cada entidad que se guardará. Dentro de cada tabla, defina
los campos que almacenarán una descripción detallada de la entidad.

En la página siguiente hay un ejemplo muy simplificado de una estructura de datos. Lo tuyo
probablemente será muy diferente.
Table: Employees
Campos (nombre y tipo):
Employee ID
UDID First name
Text Last name
Text Address
Text City
Text State
Text Zip
Text
Hourly rate
Number Photo
Image Department
Number

Table: Departments
Campos (nombre y tipo):
Department ID
UDID Department
name Text

Table: Products
Campos (nombre y tipo):
Product ID
UDID UPC
Number Product
name Text

pág. 11
 Price
Number Photo
Image

Table: Sales
Campos (nombre y tipo):
Invoice ID
UDID Invoice
number
Number
Customer ID UDID (Tendría que definir una tabla de clientes también, aunque
no tenemos aquí)
Invoice number Text (puede incluir guiones o letras, etc..)
Date
Date Employee
Number Products
sold Array
Sales tax
Number Total paid
Number

Table: Product sold

Campos (ombre y tipo type):
Product sold ID
UDID Invoice ID
UDID Product ID
UDID Quantity
Number
Price Number (usted registra el precio aquí porque podría descontarse para
esta orden) Use el formulario en la página siguiente para comenzar a construir sus estructuras de
datos. Usa tantas páginas como necesites.

pág. 12
Tabla:
Campos (nombre y tipo):

Tabla:
Campos (nombre y tipo):

Tabla:
Campos (nombre y tipo):

Tabla:
Campos (nombre y tipo):

pág. 13
 2.4. Fases
Enumera cada característica en tu lista de deseos. No dejes nada fuera. Si mejoraría su aplicación,
colóquela en la lista. Una vez que se haya quedado sin ideas, haga una segunda pasada en la lista.
Marque con lápiz todas las características imprescindibles, las cosas con las que posiblemente no
pueda lanzar una aplicación, con un 1.

Mira tu lista de nuevo. Con todo lo que ha marcado con un 1 integrado en la aplicación, ¿tiene un
producto vendible (o si es para uso interno un producto útil)? Algunas personas lo llaman el producto
mínimo viable, un término que no me gusta especialmente, pero tiene un gran acrónimo: MVP. El
MVP es lo que queremos hacer en la primera versión. Si intenta hacer todo en la primera versión,
llevará más tiempo, y no hará ningún dinero con ella por un largo tiempo. Con un MVP, puede
comenzar a obtener un retorno de su inversión tan pronto como sea posible, y esa amortización es lo
que financiará el resto del proyecto como una actualización posterior.

Finalmente, revise nuevamente la lista y finalice las funciones para la versión 1. Marque las
características de la versión 1 claramente, y marque cada una con un 2 o 3 para indicar en qué versión
se realizará la función. Cuando haya terminado, tendrá una especificación completa que nos muestra
lo que debemos hacer para estimar correctamente el costo del proyecto, y nos permitirá trabajar de
manera rápida y eficiente.

Características de la versión 1
(list
features
here)

Características para la versión posterior

(enumerar las
características
diferidas aquí)

pág. 14
2.5. Diagrama de flujo
Dibuje un diagrama de flujo de la funcionalidad básica. Para un programa complejo, divida la
funcionalidad en grupos, con cada grupo en su propia página. Haga tantas páginas como necesite
para definir la funcionalidad completa. De nuevo, cada minuto que pases aquí será de varios
minutos que un programador no tiene que gastar tratando de adivinar lo que pretendías.

A continuación se muestra un diagrama de flujo de muestra para las pantallas de inicio de sesión /
inicio de una aplicación simple. El estilo del diagrama de flujo no importa. Solo hazlo fácil de seguir.
En este caso, solo mostramos la conexión de las pantallas y una rama simple, donde la aplicación
debe tomar una decisión basada en la elección del usuario desde la pantalla de inicio..

Ejecutar
Ejecutar pantalla
pantalla de
de inicio
bienvenida

Ejecutar
pantalla de
inicio – Elegir
principal o
configuraciones

Ejecutar
Ejecutar pantalla pantalla Ejecutar
de
principal (ver pantalla de
configuraciones
(Ver pagina ___) página___) salida

pág. 15
2.6. El proceso
Escribe esta aplicación lo mejor que puedas. Recuerde, cualquier parte de la especificación que no
tenga, deberá considera un costo extra para hacerlo. Cuanto más exactamente pueda describir la
aplicación, con mayor precisión se podrá calcular el costo de la misma, y menos le costará a largo
plazo.

Una vez que haya diseñado la especificación, sele dará un cálculo del costo. Si proporciona una
especificación completa, generalmente podemos ofrecerle una oferta garantizada. Si da una
especificación vaga, no se podra darle una tarifa fija.

A medida que avanzamos, le mostraremos nuestro progreso a intervalos regulares.

Podrá aprobar el diseño y podremos realizar cambios si descubrimos que el diseño original tenía
fallas. Ver la aplicación está cobrando vida y estoy seguro de que la disfrutarás.

pág. 16