Diferencia entre revisiones de «Chinator: Servicio de geolocalización de tiendas de todo a 100/Documentación del proyecto»

Contenido eliminado Contenido añadido
Synpheros (discusión | contribs.)
Sin resumen de edición
Synpheros (discusión | contribs.)
Línea 356:
*Un documento de Word no es suficiente para la visualización integral de matrices complejas de análisis de arquitectura empresarial. *Todo análisis de este tipo debe ser apoyado por herramientas externas que permitan la visualización global de toda la problemática.
 
=== Gestión de Calidad ===
Para gestionar la calidad, en Chinator hemos utilizado varios métodos. A continuación se realizará un listado de los métodos utilizados para garantizar la calidad del producto.
 
# '''Generar documentación software dentro del código.'''
Aunque sea pequeña, existe documentación dentro del código de la Aplicación Android, y dentro del código de la página web. Dicha documentación está disponible dentro de los repositorios de Chinator, explorando el código fuente.
 
# '''Realizar Diagramas UML antes de desarrollar.'''
Hemos generado diagramas UML para prevenir errores y defectos en el programa, y garantizar que la experiencia final de usuario sea más agradable. De esta manera mejoramos la calidad de nuestro producto. Dichos diagramas se pueden encontrar en el plan de proyecto de Chinator.
 
# '''Realizar una planificación temporal para organizar el trabajo.'''
Organizar el trabajo con respecto al tiempo asegura que no vamos a dejar trabajo a medias, que dicho trabajo va a poder ser acabado con calma y pensando cada una de las lineas de código que se escribirán. Realizar una planificación implica que cada una de las tareas se van a poder hacer dedicando el tiempo previsto, y no menos del necesario. Dicha planificación está disponible también en el plan de proyecto de Chinator.
 
# '''Realizar revisiones periódicas.'''
Revisar que el trabajo se haya realizado correctamente garantiza directamente la calidad, pues un trabajo mal hecho es resultado directo del fracaso de la organización. Estas revisiones se realizaban semanalmente con el objetivo de conocer la situación del proyecto, conocer el estado del trabajo que debemos tener acabado en dicho punto del proyecto, y plantear mejoras posibles para el proyecto, incrementando de esta manera la calidad del proyecto.
 
# '''Realizar pruebas de software.'''
Realizar pruebas nos hace ver directamente la calidad que tiene nuestro producto. Si falla mucho, si se ve correctamente en todos los dispositivos, los tiempos de carga y tiempos de respuesta del servidor, etc... Nos sirven para conocer, mediante métricas, la calidad del software desarrollado y de la infraestructura de nuestro sistema. Estas métricas, estableciendo mínimos (Como que el servidor debe de dar respuesta antes de 3s, o que la aplicación debe fallar menos de 5 veces al día) que no debemos superar, nos ayudan a obtener el software con la calidad deseada.
 
# '''Mecanismos alternativos.'''
Además de estos mecanismos mencionados, hemos utilizado otros mecanismos, como el uso de SVN que nos ayudan a mantener el código organizado, el uso de Google drive para mantener los documentos actualizados y coordinados entre los miembros del equipo, o el uso de WhatsApp para coordinar al equipo a la hora de realizar tareas.