Project development methodology (web pages, systems and apps)
This document describes how is the development environment inside DEVA, here we take a point of view of the general process to develop a project.
Process:
- Idea
- Wire-frame
- Graphic design
- Documentation
- Requerimientos
- Wire-frame specification
- System architecture
- System Modules
- Auth definition
- Algoritmos, procesos y diagramas
- External resources (APIs) and dependencies
- Project kickoff
- Prototype
- Reports and handles
- Testing
- Debugging
- Project finalization
Idea
This is the result of the previous work withe the vendor the client and the architects, they will handle 3 main documents:
- User stories: The general description of what the final users needs.
- Requirements: A technical analysis of the project organized in bullet points
- Specification: The detailed description of the non-standardized modules of the projects, this can include charts, diagrams and other documents in order to specify the functionality of the more complex parts of the project.
Graphic design
Software DEVA is distinguishes itself by its implementation of the high quality of the designs proposed by the designers, giving a result to the same customer as expected from the beginning of the project.
All designs should be based on the wire-frame, it includes a color plate with "rgba" colors
Some specifications for apps and others:
- Splash image: resources/splash.(png|jpg) must be at least 2732×2732px
- App Icon: resources/icon.(png|jpg) must be at least 1024×1024px
- PlayStore banner:
- Components: Fonts, Colors, Input style, Button Large, Button Small, etc.
- GoogleMaps style (Snazy maps), menú type, etc.
Documentation
La documentación estará concentrada en la plataforma "confluence" para cada proyecto. Se contarán con los siguientes documentos para el desarrollo del proyecto:
Requirements
Es donde se escpecificarán los requerimientos generales del cliente.
Reglas de negocio
Se tendrá una lista con las reglas de negocio que se deben cumplir.
Wire-frame
In all projects there should be a wire-frame defining each "view" where there are going to be all the "elements" that the user can interact with and the description of the complex functionalities where only the result can be seen like the animations and transitions.
System Architecture
Aquí es donde se especifica los subproductos o módulos del sistema.
System Module
Estos serán archivos con la nomenclatura "\<module-name>-module" los cuáles definirán cada módulo del sistema con los siguientes posibles elementos
Client (JS)
- Definición {aplicación | sistema | página web | cms }
- Framework
- Dependencies
- Vistas
- Componentes
- Componentes Globales
- Servicios
- Estilos globales
Servidor (API)
- Rutas
- Controladores
- Modelos (BD)
Auth
- Definición del algoritmo de autentificación
Algoritmos, procesos y diagramas
Existirán diferentes documentos ligados a los previos mencionados donde se especificará lo siguiente:
- algoritmo (pseudocódigo)
- procedimiento (proceso)
- diagrama de interacción
- casos de uso
- diagramas O.O.
- ...
Info
Estos documentos podrá estar en constante modificación por lo que se deben revisar siempre al iniciar el desarrollo de un módulo del proyecto. Se debe procurar no modificar el documento y por lo tanto el diseño de módulos que ya fueron desarrollados, en caso de ser necesario el desarrollador que trabajó en este módulo será notificado. Se cuenta con un plazo máximo de 1 semana para establecer cualquier modificación.
External resources (APIs)
Se debe establecer en documentos como se deben integrar las apis externas necesarias para que el sistema cumpla los requerimientos.
Project kickoff
Para poder establecer el comienzo del proyecto y que comience a correr el tiempo de desarrollo se requiere de que todos lo elementos establecidos en los puntos anteriores se encuentren resueltos y bien establecidos.
Prototype
En el caso de proyectos con tiempo de desarrollo mayor a 4 semanas, el cliente tiene la posibilidad de recibir un prototipo con la finalidad de observar una plataforma funcional en las parte de navegación y diseño.
Sprints
Se establecerán fechas límite por cada sprint del proyecto donde el primer sprint deberá ser el prototipo, y buscando agregar funcionalidades completas en cada siguiente sprint.
Reports and handles
El desarrollador mostrará su avance el sistema organizador de tareas, además deberá notificar cuando su parte asignada esté completa y las pruebas hayan pasado. El código deberá subirse a través del manejador de versiones a un servidor remoto utilizando una rama para cada módulo o submódulo trabajado bajo la siguiene nomenclatura:
> branch NombreOAliasDelProgramador/NombreDelSubmodulo
Testing
Todo el desarrollo se realizará haciendo pruebas unitarias de los módulos o submódulos que se trabajen tomando en cuenta que se deben probar todos los casos que se puedan presentar en el sistema. Se utilizará la plataforma de pruebas respectiva al ambiente en el que se está trabajando.
Se contará con una matriz de pruebas de integración para probar flujos completos del proyecto.
Debugging
En caso de no cumplir con los requisitos establecidos o de tener errores, el código será devuelto para su revisión.
Project finalization
El proyecto tiene que cumplir con los requisitos establecidos en el organizador de tareas para establecer su finalización.
Estándares de desarrollo
Existen los siguientes estándares específicos para las diferentes áreas de un proyecto, estos están definidos en un documento por separado: