Willow Documentation Versión 1.1.0 - Willow Documentation - Read the Docs
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Willow Documentation
Versión 1.1.0
Willow Documentation
22 de noviembre de 2017Índice general
1. Acerca de la Presente Documentación 3
2. Requerimientos 9
3. Análisis y Diseño 15
4. Desarrollo 17
5. Pruebas del Software 21
6. Integración del Software 23
7. Mantenimiento del Software 25
III
Willow Documentation, Versión 1.1.0 Nota: ¿Primera vez en la documentación de Willow? Te sugerimos encarecidamente revisar primero la sección Acerca De ¿Qué es Willow? Willow es un sistema web para administrar stands y centros comerciales. Se habla de Sistemas Willow porqué Willow esta implementando para diversas empresas, las cuales suelen variar en requerimientos y necesidades. Contenido Índice general 1
Willow Documentation, Versión 1.1.0 2 Índice general
CAPÍTULO 1
Acerca de la Presente Documentación
Esta sección explicará a detalle el ¿Cómo?, ¿Qué? y ¿Por qué? de la presente documentación.
Contenido
1.1 Definiciones
stand TODO
planograma TODO
contrato TODO
local TODO
empresa TODO
centro comercial TODO
ingreso regular TODO
ingreso adicional TODO
gasto TODO
categoría de gasto TODO
fondo TODO
1.2 Estructura de la Documentación
La presente está divida en 6 secciones (sin contar esta misma) debido a que estos 6 últimos comúnmente son conside-
rados como ciclos del desarrollo del software.
3Willow Documentation, Versión 1.1.0
Nota: Es importante recalcar que el repositorio(.git) que contiene la presente documentación sigue siendo un contro-
lador de versiones, y por lo tanto se deben respetar las reglas esenciales de estos, como:
No guardar imágenes que no sean completamente necesarias.
Los cambios se podrán hacer solo por personas autentificadas.
etc.
1.3 Construcción de la Documentación
Nota: No confundir con Construcción del Software(Desarrollo)
Trello para almacenar las tareas de cada Sprint y mostrar el avance y requisitos de todos los sistemas, más
información en Uso de Trello
Gitlab es un hosting para control de versiones Git, llama la atención debido a su refinado diseño y su comuni-
cación directa con sus usuarios. Además de poseer muchas herramientas que otros servicios no cuentan. Más
información en Uso de Gitlab
Sphinx es un motor open source escrito en Python para enlazar documentos y generar documentación, para
escribir en Sphinx se deberá usar Markdown o reEstructuredText Más información en Uso de Sphinx
Read The Docs es un hosting para documentación en formato Sphinx, es completamente gratuito y open source.
Más información en Uso de Read The Docs
Google Drive para almacenar los binarios que son muy pesados o archivos que no tiene sentido guardarlos en
el control de versiones, como por ejemplo archivos fuente de Adobe Illustrator, Fotos de Contratos, etc. Más
información en Uso de Google Drive
Draw.io es un servicio cloud open source gratuito que nos permite hacer diagramas y tablas, este software será
nuestra herramienta principal para crear los documentos de análisis y diseño, etc.
VSCode: opcional, pero altamente recomendable para editar el código fuente de la documentación. El reposi-
torio viene con una configuración para este editor de código que ayudará a los colaboradores. Más información
en Uso de Visual Studio Code
Contenido
1.3.1 Uso de Trello
Uso de Trello.
Link
Guía de Etiquetas
1. Estado del Item
Item Defered: Indica que el item perteneció inicialmente a un sprint anterior
Doing: Indica que el elemento se esta realizando
4 Capítulo 1. Acerca de la Presente DocumentaciónWillow Documentation, Versión 1.1.0
Done: Indica que el elemento ha sido implementado
2. Respectos a su implicancia
Needs Code Review: Indica que el código implementado necesita ser supervisado
Code Reviewed: El código implementado ha sido revisado y aprobado al menos por otro desarrollador
Needs Testing: Indica que la funcionalidad necesita pruebas automatizadas
Needs UX Discussion: Indica que la usabilidad de la funcionalidad necesita ser discutida
3. Respecto al impacto del Cambio
Breaking Change: Indica que el cambio no será compatible con anteriores versiones
Major Change: Indica que el cambio significa una mejora mayor para la versión actual
Minor Change: Indica que el cambio es mínimo y no debería
4. Respecto al tipo de tarea
Design: Indica que la tarea está relacionada con diseño, ilustración o prototipado
Engineering: Indica que la tarea requiere investigación y de ingeniar una solución para un problema que no se
puede resolver actualmente
Docs: Indica que la tarea es acerca de documentación
1.3.2 Uso de Gitlab
Uso de Gitlab
Link
1.3.3 Uso de Sphinx
Uso de Sphinx
1.3.4 Uso de Read The Docs
Uso de Read The Docs
Link
1.3.5 Uso de Visual Studio Code
Uso de Visual Studio Code
1.3. Construcción de la Documentación 5Willow Documentation, Versión 1.1.0
1.4 ¿Por qué no usamos Microsoft Word?
Creemos que el stack de tecnologías escogido es sencillo y poderoso, desde nuestra perspectiva de desarrolladores es
suficiente para la documentación que se necesita en este proyecto. Nos da muchas comodidades y flexibilidad, que
como desarrolladores, nos gusta.
Además de seguir las buenas prácticas y sugerencias establecidas por la comunidad Open Source.
1.4.1 Ventajas respecto a Microsoft Word
No se tiene que lidiar con problemas de versiones de Word(2009, 2010, 2013, 2016, etc)
No se necesita contar con Word para editar el documento, esto facilita la lectura y edición para usuarios de Mac
OSX y de Linux
Es amigable para el desarrollador, esto quiere decir que resulta más conveniente y más rápido escribir en Mark-
down o en reEstructuredText
Se integra perfectamente con un controlador de versiones como Git, a diferencia de Word, Markdown permite
sacarle todo el provecho a la herramienta de diferenciación(diff ) de Git
Este stack det tecnologías es open source y completamente gratuito, no nos debemos preocupar de licencias
Read The Docs nos permite convertir la documentación a HTML, PDF o incluso como e-Book de manera
instantánea
Los artefactos(textos) son increíblemente ligeros, reducen el espacio ocupado por la documentación
Read The Docs genera una vista online que está bien diseñada y es responsiva para computadoras de escritorio
y móviles
Read The Docs nos permite intercambiar de versiones de manera muy simple
Read The Docs nos ofrece una webhook para poder hacer desarrollo continuo, es decir, hacemos cambios al
repositorio de la documentación y se verán reflejados automáticamente
Sphinx nos da un cuadro de búsqueda
Sphinx soporte traducciones para la documentación
1.4.2 Desventajas respecto a Microsoft Word
El código fuente de los artefactos no es tan fácil de entender para los que no conocen de programación de
etiquetas
No hay mucho control de colores, sombreados y herramientas de edición avanzadas
No se pueden incrustar imágenes por documento, solo se pueden enlazar desde otras locaciones
Hacer Tablas puede llegar a ser un poco tedioso
No tiene soporte para detección de errores de ortografía, aunque varios editores de código y texto pueden solu-
cionar el tema
Si no se conoce Markdown y reEstructuredText, se requiere de un esfuerzo(mínimo) para poder escribir la
documentación, a diferencia de Word, donde todo el mundo sabe usarlo
6 Capítulo 1. Acerca de la Presente DocumentaciónWillow Documentation, Versión 1.1.0
1.5 Tabla de Origen Para Los Artefactos
En la presente documentación se encontrará una tabla al inicio de cada artefacto, la cual será llamada “tabla de
origen”, se usará como alternativa a las nomenclaturas y darán información adicional.
EMPRESA LOCALES
Nombre de la empresa Nombre del o de los locales
Empresa: El nombre de le empresa a la cual pertenece el artefacto.
Locales: El nombre del local o de los locales al cual pertenece el artefacto.
1.5.1 Ejemplos
Esta notación denota que el artefacto aplica para todas las empresas y (por consiguiente) para todos los locales
EMPRESA LOCALES
TODOS TODOS
Esta notación denota que el artefacto aplica para el local GAMARRA de la empresa CARRUSEL
EMPRESA LOCALES
CARRUSEL GAMARRA
Esta notación denota que el artefacto aplica para todos los locales de la empresa NIBA
EMPRESA LOCALES
NIBA TODOS
Esta notación denota que el artefacto aplica para el local MEGAPLAZA de la empresa NIBA y así mismo para los
locales GAMARRA y SAN JUAN de la empresa CARRUSEL
EMPRESA LOCALES
NIBA MEGAPLAZA
CARRUSEL
GAMARRA
SAN JUAN
1.6 Colaboradores
Diego Jara Palomino
Francis Marquez Paico
Raphael Bravo Dedo
1.7 Objetivo del Presente
¿Cual es la motivación detrás de la presente documentación, que se quiere lograr o transmitir hacia los lectores?
1.5. Tabla de Origen Para Los Artefactos 7Willow Documentation, Versión 1.1.0
1.8 Estado Actual de la Documentación
Nota: Como parte de la primera entrega del curso Evolución de Software, esta presentación esta enfocada en mos-
trar innovación en como se documenta un software, ya que representa un esfuerzo por emplear herramientas y
metodologías que son ampliamente conocidas en las comunidades Open Source, pero en las Universidades ni se
les hace mención.
Esta presentación contiene diagramas de análisis y diseño, pero no su totalidad
Sección Estructura Contenido Gráficos/Diagramas
Requerimientos 100 % 100 % No es necesario
Análisis y Diseño 100 % 60 % 60 %
Construcción del Software 100 % 20 % 0%
Pruebas del Software 100 % 0% 0%
Integración del Software 100 % 60 % 0%
Mantenimiento del Software 100 % 30 % 30 %
8 Capítulo 1. Acerca de la Presente DocumentaciónCAPÍTULO 2
Requerimientos
Requerimientos del sistema.
Nota: Se emplearán términos y conceptos que son propios del ecosistema de este ámbito comercial, por favor asegú-
rese de revisar primero La lista de definiciones
2.1 Perspectiva del Producto
Perspectiva del Producto
2.2 Funciones del Producto
Funciones del Producto
2.3 Características del Usuario
Características del Usuario
2.4 Restricciones
Restricciones
9Willow Documentation, Versión 1.1.0
2.5 Suposiciones y Dependencias
Suposiciones y Dependencias
2.6 Estructura de los Requerimientos
Estructura de los Requerimientos
2.7 Lista de Requerimientos
2.7.1 Requerimientos Funcionales
Requerimientos Funcionales
Contenido
Requerimientos Web del Administrador
Requerimientos Web del Administrador
RF-1: ENTRAR AL SISTEMA MEDIANTE UN REGISTRO
EMPRESA LOCALES
TODOS TODOS
Descripción: Para poder entrar a una cuenta administrativa, el sistema protegerá el acceso mediante un usuario
y una contraseña.
Prioridad: 5
RF-2: LLEVAR CONTROL DE LOS CONTRATOS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema tendrá la información de los contratos, mostrándolos visualmente en un planograma.
Prioridad: 5
RF-3: CONTROLAR EL LA INFORMACIÓN ESPACIAL DE LOS STANDS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema debe permitir controlar la ubicación y tamaño de los stands, de esta manera se podrá
visualizar correctamente su locación en el planograma.
Prioridad: 5
10 Capítulo 2. RequerimientosWillow Documentation, Versión 1.1.0
RF-4: REGISTRAR NUEVO PAGO DEL CONTRATO
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la adición de pagos de mensualidad por contrato.
Prioridad: 5
RF-5: MODIFICAR LOS CONTRATOS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la modificación de contratos.
Prioridad: 4
RF-6: ADMINISTRAR LOS FONDOS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la visualización, adición, modificación y eliminación de los fondos
monetarios donde fluye el capital de la empresa.
Prioridad: 4
RF-7: ADMINISTRAR LOS INGRESOS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la visualización, adición, modificación y eliminación de los ingresos
que registra la empresa.
Prioridad: 4
RF-8: ADMINISTRAR LOS GASTOS
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la visualización, adición, modificación y eliminación de los gastos que
registra la empresa.
Prioridad: 4
RF-9: GENERAR REPORTE DE MENSUALIDADES
EMPRESA LOCALES
TODOS TODOS
2.7. Lista de Requerimientos 11Willow Documentation, Versión 1.1.0
Descripción: Con el reporte se podrá ver todas las mensualidades del contrato desde su inicio, viendo los
montos, las fechas y los datos del pago.
Prioridad: 3
RF-10: REGISTRAR RENOVACIÓN DE CONTRATO
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir la adición de renovaciones de contrato, los cuales significan que a partir
de la fecha ingresada, se cambiará la mensualidad al monto indicado también.
Prioridad: 3
RF-11: VISUALIZAR LISTA DE DEUDORES
EMPRESA LOCALES
TODOS TODOS
Descripción: El sistema deberá permitir ver una lista de deudores, mostrando sus datos y los montos que deben.
Prioridad: 3
Requerimientos Mobile del Administrador
Requerimientos Mobile del Administrador
Requerimientos Web del Inquilino
Requerimientos Web del Inquilino
2.7.2 Requerimientos No Funcionales
Requerimientos No Funcionales
Contenido
Rendimiento
Rendimiento
Atributos del Sistema
Atributos del Sistema
2.7.3 Interfaces
Interfaces
Contenido
12 Capítulo 2. RequerimientosWillow Documentation, Versión 1.1.0 Interfaces de Usuario Interfaces de Usuario Interfaces de Software Interfaces de Software Interfaces de Hardware Interfaces de Hardware Comunicación de Interfaces Comunicación de Interfaces 2.7. Lista de Requerimientos 13
Willow Documentation, Versión 1.1.0 14 Capítulo 2. Requerimientos
CAPÍTULO 3
Análisis y Diseño
Documentos relacionados con el análisis y diseño del software.
Nota: Se emplearán términos y conceptos que son propios del ecosistema de este ámbito comercial, por favor asegú-
rese de revisar primero La lista de definiciones
15Willow Documentation, Versión 1.1.0 16 Capítulo 3. Análisis y Diseño
CAPÍTULO 4
Desarrollo
Documentos relacionados con el desarrollo.
Contenido
4.1 Guía para empezar a desarrollar
Nota: Este sistema es capaz de ejecutarse en cualquier sistema operativo: Windows, MacOS o Linux
4.1.1 Software Requerido
Git (> 2)
Node.js (> 8)
Yarn (> 1.3)
Firebase tools (> 3)
Además requerirás del acceso al repositorio del código fuente y una cuenta de Firebase
4.1.2 Proyecto de Firebase
1. Crear o usar un Proyecto
El acceso a los proyectos reales está limitado, en cambio se recomienda que cada desarrollador se cree o comparta un
proyecto.
Para ello se deberá revisar la documentación de Firebase
2. Activar la autenticación
17Willow Documentation, Versión 1.1.0
Willow(hasta la fecha) funciona con autenticación en base a correo y contraseña, este módulo deberá ser activado y
posteriormente se deberán crear algunos usuarios de prueba
4.1.3 Construir el entorno
1. Clonar el proyecto
Link del repositorio: https://gitlab.com/saintplay/willow
2. Instalar el repositorio
Ejecutar el comando yarn install
4.1.4 Variables de entorno
Nota: Si se desconoce del tema, por favor revisar Variables de entorno
Se deberá crear un archivo .env en la raíz del proyecto, luego siguiendo la estructura de .env.example (raíz del proyecto)
se deberán sustituir las variables por las adecuadas
4.1.5 Procesos
Para iniciar el sistema en la red local
yarn dev
Para formatear el código
yarn lint
Para testear el código
yarn test
Para construir el sistema
yarn build
Para desplegar el sistema
yarn deploy
Más información en el archivo package.json*
4.2 Cronograma de Iteraciones
En está sección se detallará las iteraciones o sprints para cada versión del sistema
Contenido
18 Capítulo 4. DesarrolloWillow Documentation, Versión 1.1.0
4.2.1 Web 1.x (Pluton)
Nota: Esta versión actualmente está en desarrollo, por lo que el cronograma se verá a través del tablero de proyecto
en Trello.
Debido a esto, cada sprint backlog será documentado después del periodo activo de desarrollo
La primera versión estable de Willow deberá implementar un producto mínimo viable para la administración de stands,
contará con funcionalidades escenciales como el flujo de caja, visualización de planograma, administración de traba-
jadores, clientes, etc.
Contenido
Web 1.x Sprints
Nota: Esta versión actualmente está en desarrollo, por lo que el cronograma se verá a través del tablero de proyecto
en Trello.
Debido a esto, cada sprint backlog será documentado después del periodo activo de desarrollo
4.3 Sistema de Ramas
En está sección se detallará el uso de ramas(Git) para un adecuado control de versiones.
4.3.1 Master
La rama master
4.3.2 Ramas de Cambios Complejos
Ejemplos:
feature-print-outlays
fix-excel-table-generation
4.3.3 Ramas de Versiones Mayores
Ejemplos:
feature-print-outlays
fix-excel-table-generation
4.3. Sistema de Ramas 19Willow Documentation, Versión 1.1.0
4.3.4 Ramas de Cliente Final
niba
carrusel
Nota: ¿Tienes ganas de indagar más en el tema? Te recomendamos leer este artículo sobre una adecuada estruc-
tura para organizar ramas de Git
20 Capítulo 4. DesarrolloCAPÍTULO 5
Pruebas del Software
Documentos relacionados a las pruebas del software.
21Willow Documentation, Versión 1.1.0 22 Capítulo 5. Pruebas del Software
CAPÍTULO 6
Integración del Software
Documentos relacionados con la construcción del software.
GitLab
Firebase
Algolia
23Willow Documentation, Versión 1.1.0 24 Capítulo 6. Integración del Software
CAPÍTULO 7
Mantenimiento del Software
Documentos relacionados con el mantenimiento del software.
Contenido
7.1 Plan de Mantenimiento
El plan de mantenimiento define los intervalos de tiempo en los que se harán desarrollo, mantenimiento LTS y mante-
nimiento.
25Willow Documentation, Versión 1.1.0
7.1.1 Calendario Detallado
Tabla 7.1: Calendario de Mantenimiento
Versión Alias LTS Inicio Mantenimiento Inicio Mantenimiento
Web 1.x Pluton 17-05-2018 03-10-2019 18-02-2021
Web 2.x Express 01-11-2018 19-03-2020 05-08-2021
Web 3.x Conqueror 18-04-2019 18-02-2021 20-01-2022
Mobile 1.x Maya 03-10-2019 18-02-2021 20-01-2022
Web 4.x No Definido
Mobile 2.x No Definido
7.1.2 Fases de Mantenimiento
Nota: Beta, significa que el sistema todavía no se encuentra completamente estable, es un periodo indispensable antes
de pasar a LTS.
LTS
LTS o Mantenimiento LTS es el periodo de tiempo en el que se da prioridad a un sistema cuando se presentan errores
o vulnerabilidades.
Durante este periodo el mantenimiento debería ser gratuito.
Durante LTS no se agregan funcionalidades ni cambios mayores.
Mantenimiento
El Mantenimiento es el periodo de tiempo en el que se soporte básico a un sistema cuando se presentan errores o
vulnerabilidades.
Durante este periodo el mantenimiento debería ser pagado.
Ver también:
Composición de Ramas en Git Explicación detallada de la función de cada rama usada en el control de versiones.
Roadmap Explicación detallada de las funcionalidades del sistema agrupadas por versiones.
Versionamiento Explicación de las reglas que se toman en cuenta para versionar el sistema.
26 Capítulo 7. Mantenimiento del SoftwareÍndice
C
categoría de gasto, 3
centro comercial, 3
contrato, 3
E
empresa, 3
F
fondo, 3
G
gasto, 3
I
ingreso adicional, 3
ingreso regular, 3
L
local, 3
P
planograma, 3
S
stand, 3
27También puede leer
