Siempre que se comienza a realizar aplicaciones para terceros conviene tener un conjunto de herramientas y pasos a seguir para delimitar el alcance del proyecto, y poder así, realizar un presupuesto ajustado minimizando el riesgo. A continuación presentamos una serie de pasos que se pueden seguir.
ARTECO CONSULTING SL
Java, Software, Webs, SEO y Formación
Qué es una metodología de desarrollo de software
Las metodologías no son más que guías para estandarizar los procesos de elaboración o fabricación de sistemas más o menos complejos, para tratar de unificar la forma de realizar las actividades necesarias, reduciendo al mínimo los problemas que pueden surgir de haber hecho las cosas diferentes o de haberse saltado un paso en la producción. Como en la mayoría de sectores de fabricación, el software no es diferente, también requiere seguir algunos pasos para abordar proyectos de gran envergadura o para unificar la manera de proceder de todo el equipo de desarrollo.
En el sector de la informática habitualmente se denomina al software como el Sistemas de Información, porque no sólo intervienen programas, si no también infraestructuras con comunicaciones, bases de datos, copias de seguridad y demás elementos que permitan proveer el servicio necesario y disponible la mayor parte del tiempo. Así que las metodologías suelen referirse a los S.I. para tener en cuenta todo los actores que intervienen.
Qué metodología seguir para elaborar una aplicación
Dentro del mundo de las aplicaciones informáticas se usan tradicionalmente dos aproximaciones muy diferentes. La aproximación ágil donde su máximo exponente es la metodología Scrum, que permite partir de un punto de salida algo laxo e ir afinando el sistema a través de entregables sucesivos. O los sistemas rígidos o en cascada, porque requieren que la fase anterior esté cerrada para poder pasar a la siguiente. De este último tipo su exponente máximo en España es Métrica V3, y es aconsejable a personas que no tienen mucha experiencia en la elaboración de sistemas de información.
En las siguientes líneas, se explica una metodología simple extraída de Métrica V3 con toques personales, que servirá como punto de partida a aquellos programadores que estén empezando y no tengan muy claro qué ruta seguir a la hora de abordar un proyecto de pequeña escala.
Qué fases hay en un proyecto
Cuando se sigue una metodología en cascada como pueda ser Métrica v3, parece que hay bastante consenso en el orden de las fases, que luego se descomponen en actividades a realizar por diferentes perfiles. Algunas de las tareas pueden ser ejecutadas en paralelo por diferentes miembros que tengan alguna función en el desarrollo del sistema de información.
En general está aceptada la siguiente lista de fases:
- Planificación de sistemas de información
- Desarrollo de sistemas de información
- Estudio de viabilidad del sistema
- Análisis del sistema de información
- Diseño del sistema de información
- Construcción del sistema de información
- Implantación y aceptación del sistema
- Mantenimiento de sistemas de información
- Cierre del proyecto
Qué metodología seguir para elaborar un proyecto simple
Idealmente sería preferible seguir Métrica al dedillo, realizando todas las actividades que indica y de la forma en que se describen. Pero para proyectos sencillos resulta demasiado complejo y requiere de mucho esfuerzo ya que está pensado para grandes iniciativas de la Administración Pública o sistemas corporativos completos. Aun así sirve perfectamente como base para identificar los pasos a seguir en cualquier aplicación.
Metodología simple de desarrollo de software
La siguiente propuesta de metodología para la elaboración de aplicaciones de software y programas informáticos debe tomarse como referencia y una guía útil para aquellos que comienzan a programar. Esta recomendación carece de relevancia para programadores con experiencia o para equipos de programadores. En estos casos conviene más aplicar la metodología ágil Scrum o seguir los ciclos marcados en Métrica.
0 – Definir los objetivos del sistema
El primer paso para realizar cualquier actividad es concretar qué se quiere conseguir. Definir los objetivos es el paso más importante del cuál colgarán el resto de actividades, por lo que su concreción es la parte crítica en la elaboración de un programa informático. Cambiar los objetivos a mitad de proyecto puede provocar que se tenga que tirar todo el trabajo hecho a la papelera y volver a empezar.
Por tanto, se deben definir los objetivos lo más detalladamente posible siguiendo la regla SMART:
- S-pecific – Específico
- M-easurable – Medible
- A-chievable – Alcanzable
- R-ealistic – Realista
- T-imely – Acotado en el tiempo
Los objetivos no deben ser muchos, cuantos menos mejor, puesto que un sistema de información debe nacer para cubrir principalmente UNA necesidad. Aunque luego, con el tiempo el sistema vaya creciendo. Se debe recordar, que al igual que los programas crecen en complejidad de forma exponencial según el número de variables que use, lo mismo sucederá en función del número de objetivos que deba alcanzar.
1 – Identificación de perfiles de usuario
Una vez que se tiene claro qué se quiere conseguir con el sistema de información, el siguiente punto es catalogar los diferentes perfiles de usuario que interactuarán con el aplicativo. Se debe tener en cuenta que los usuarios pueden ser personas físicas o también otros sistemas interconectados vía una red de comunicaciones. Sean cuales sean, se debe acotar quién va a utilizar el nuevo sistema.
2 – Definición de funcionalidades por perfil o rol
El siguiente paso natural es determinar para cada perfil de usuario, o también denominado rol, qué funcionalidades del programa va a utilizar y por tanto serán opciones que tendrá que tener disponible y cuales no.
Es habitual en este punto que aparezca algún mecanismo de seguridad que impida a ciertos usuarios que puedan realizar algunas acciones dentro el software, evitando las fuga de información o el acceso no autorizado a información personal (protegida por el reglamento Europeo RGPD) o a información confidencial corporativa.
Como resultado de este análisis de funcionalidades por rol, se obtiene el catálogo de requisitos funcionales que determina los casos de uso de la aplicación.
Algunos requisitos de ejemplo podrían ser:
- el cliente puede conectar al sistema para imprimir la factura de compra en PDF
- el contable podrá dar de alta facturas de compra dado un cliente y uno o más artículos
- el cliente no podrá borrar facturas de compra con productos ya entregados
Este catálogo es de alto nivel y especifica las funcionalidades de negocio en un idioma no técnico y comprensible para los usuarios, y por tanto para el posible cliente de nuestros servicios de programación. Debe entender lo que nosotros hemos identificado como necesidades que debe cubrir el sistema para poder autorizarlo y dar su conformidad como si fueran los «planos de la casa». Y al mismo tiempo sirve de garantía para delimitar nuestra responsabilidad y para confirmar que se ha entendido lo que se solicita.
Muchas veces se pide al cliente que firme el catálogo de requisitos funcionales, al igual que al cliente se le solicita que firme un proyecto de arquitectura, para evitar conflictos entre lo que el cliente solicitaba y el proveedor entregó como trabajo realizado. Este proceso suele requerir de revisiones del documento hasta alcanzar la versión de conforme por el cliente.
Es importante añadir una cláusula al catálogo que indique que lo que no está especificado en ese documento no será planificado, no será estimado en costes y no será llevado a ejecución. De hecho, este documento suele ser la base en muchos proyectos para realizar el presupuesto.
3 – Catalogar las entidades de información
Al tener concretadas y acordadas las funcionalidades por usuario, ya se puede obtener el alcance del sistema permitiendo elaborar un presupuesto. Y además, permite al personal técnico identificar aquellas entidades de información que el programa deberá tratar. O dicho de otro modo, permite definir el modelo de datos que albergará el almacenamiento y procesado de los registros de la aplicación.
Las aplicaciones de gestión habitualmente utilizan sistemas gestores de base de datos relacionales SQL para almacenar la información de forma consistente. Así que en este punto, definir el modelo de datos suele ser equivalente a definir tablas y columnas de la base da datos. Si desea aprender más acerca de las bases de datos SQL puede consultar el Tutorial de SQL Structured Query Language que hemos preparado.
El modelo de datos debe dar soporte y ser coherente con todos y cada uno de los requisitos funcionales. Si algún requisito demuestra que el modelo no es suficiente, se debe replantear las tablas o columnas correspondientes para que se pueda dar soporte a las necesidades plasmadas en el catálogo de requisitos.
4 – Definir los procesos funcionales
El catálogo de requisitos suele ordenarse por perfil de usuario, eso implica que algunas funcionalidades están disponibles para más de un tipo de usuario. Por este motivo, la fase 4 trata de unificar las acciones que podrán ser ejecutadas en la aplicación en procesos de negocio, como parte de homogeneizar el flujo de información desde la interfaz de usuario a la base de datos y al revés, desde la base de datos hacia el usuario.
Escribir los procesos es equivalente a realizar diagramas de flujo o secuencia de pasos, indicando qué acciones se deberán hacer en cada paso para completar el proceso. Por ejemplo, al consultar una factura en PDF, el sistema debe comprobar primero que el usuario tiene permiso para realizar dicha acción. Segundo, se debe recuperar la factura de la base de datos. Y tercero, convertir los datos crudos en un archivo PDF. Esta secuencia se podría haber descrito como:
PROCESO: Consulta de facturas en PDF
- Revisar que el usuario está identificado
- Obtener la empresa asociada al usuario
- Comprobar que la factura solicitada pertenece a la empresa del usuario
- Recuperar el detalle de la factura de la base de datos
- Identificar la plantilla para la generación de PDF dada la empresa del usuario
- Ejecutar la generación del PDF dada la plantilla y el detalle de la factura
- Servir el PDF al usuario que ha realizado la petición
Ejecutores: administrador, cliente, …
Requisitos: usuario identificado en el sistema
Otras características del proceso…
La descripción de ese proceso es un ejemplo, pero cubre dos objetivos importantes. Primero es una confirmación de que las funcionalidades identificadas en el catálogo de requisitos están todas contempladas. Y segundo, la descomposición en acciones más pequeñas, permite identificar y agrupar funcionalidades similares a implementar, como la necesidad de realizar un módulo de seguridad, que con mucha probabilidad se usará en la mayoría de los procesos, y que deberá ofrecer (según el ejemplo) la posibilidad de obtener la empresa de un usuario conectado.
5 – Agrupar los procesos en módulos
La misma descomposición de procesos en actividades del paso anterior permite identificar los módulos de la aplicación, como el ya mencionado módulo de seguridad. El ejemplo también pone de manifiesto que se necesitará otro módulo para la generación de PDFs, dada una plantilla, e incluso otro para la gestión de facturas. Los módulos son agrupaciones de acciones que se realizan sobre una misma entidad de información y que pueden dar servicio a uno o más módulos diferentes.
Identificar los módulos y sus métodos antes de comenzar el desarrollo, simplifica enormemente el esfuerzo requerido en la programación ya que da una visión global al técnico de todo lo que se debe construir, permitiendo la posibilidad de identificar componentes reutilizables o la incorporación de librerías existentes.
Desde el punto de vista de programadores Java con Spring Boot, puede decirse que un módulo se convertirá en una clase de servicio anotada con @Service. Y cada acción del módulo será un método de dicha clase. Si quieres conocer más acerca de la programación con Spring Boot puedes consultar el tutorial de programación con Spring Boot.
6 – Fase de desarrollo de software
Llegados a este punto, todo el trabajo de análisis (y parte del diseño) ya se ha realizado, por lo que se debería tener una visión muy clara de cómo va a ser el sistema de información. A partir de aquí, comienza el trabajo más mecánico de la programación, no exento de creatividad, puesto que comienza la creación de clases y métodos. Realizar herencia, construir componentes, separar responsabilidades son tareas que el programador será capaz de hacer según su experiencia. A medida que el programador vaya realizando proyectos similares, verá como el código escrito se reduce drásticamente al incorporar las funcionalidades que proporciona el framework usado.
Si tienes dudas de cómo abordar un proyecto y qué tecnología usar recomendamos fervientemente el uso de Java como el mejor lenguaje de programación. Juntamente con Spring Boot como el mejor framework para construir aplicaciones en Java. Con esta elección podrás construir aplicaciones sólidas y profesionales con un mínimo esfuerzo, adquiriendo unas competencias muy deseadas en las empresas.
Siempre que se desarrolla aplicaciones nuevas, con las ya existentes puede no ser trivial, conviene aplicar la metodología de desarrollo orientada a test unitarios también conocida como TDD o Test Driven Development. Con esta aproximación, el programador comienza escribiendo test de validación para luego implementar los algoritmos. Así, se consigue tener una gran batería de test que comprueban el correcto funcionamiento del sistema de información tras cada cambio y antes de desplegar el sistema abiertamente en producción.
Estos test son ejecutados automáticamente por Maven durante la construcción de la aplicación Java impidiendo que pueda liberarse una nueva versión que no pasa con éxito todas las pruebas, ofreciendo un gran nivel de garantía de que los cambios no introducirán problemas una vez se realice el despliegue.
Tanto los archivos Java del proyecto como los test unitarios se consideran parte del código fuente del proyecto, así que conviene que estén bajo un sistema de control de versiones como git para evitar problemas si hay más de un programador o si este trabaja en el proyecto desde diferentes ubicaciones. Además proporciona un excelente sistema de backup ante una modificación errónea de cualquier fichero.
7 – Fase de pruebas de validación
Las pruebas unitarias, aunque son muy útiles, no son suficientes para certificar que una aplicación funciona correctamente, ya que éstos tienden a probar partes muy concretas de la aplicación y no realizan comprobaciones sobre el totalidad de la aplicación. Los test unitarios se centran en realizar pruebas sobre uno o varios métodos de una clase, pero no suelen programarse para que hagan una petición web o lean un PDF generado automáticamente. Así que se requieren otros tipos de pruebas que completen lo huecos que dejan los unitarios.
La siguiente batería de pruebas que se suele hacer son test de integración. En ellos se comprueba, vía herramientas externas, que la aplicación es capaz de conectarse a otros sistemas como pueden ser bases de datos, sistemas de FTP o incluso a otras aplicaciones web o microservicios. Y como su nombre indica, comprueban que las configuraciones e integraciones con otras aplicaciones funcionan correctamente en un determinado entorno, por ejemplo en pre-producción. Se suele utilizar JMetric o SOAPUi para automatizar baterías de pruebas automáticas.
Si resulta que el sistema de información es el último de la cadena de los servicios que se proporcionan, por ejemplo una aplicación abierta a internet, se dice que los tests son test end-to-end (E2E) puesto que comprueban que el programa funcione bien, pero también todos los sistemas por debajo que son consumidos por este. Los test E2E son aquellos que dan más garantías de funcionamiento, e incluso pueden verse como son ejecutados directamente sobre los sistemas de producción, aunque con muchas limitaciones para no provocar cambios irreversibles o que puedan saturar el sistema impidiendo su correcto funcionamiento.
En cualquier caso, el último paso de pruebas debe ser realizado por el cliente o usuario final que de su conformidad con el trabajo realizado y con la adecuación de la solución a la necesidad plasmada al principio de la elaboración del proyecto.
8 – Fase de puesta en producción
La puesta en producción dependerá mucho de qué tecnología se haya usado para elaborar la aplicación. Si se ha usado Spring Boot se deberá generar el aplicativo con Maven generando un fichero con extensión JAR que podrá ser ejecutado por la máquina virtual de java, JVM, prácticamente en cualquier sistema operativo, real o virtual en la nube.
Recomendamos desplegar aplicaciones en conjuntos de máquinas que tengan presente el balanceo de carga y la alta disponibilidad como los ofrecidos por la infraestructura más usada en la nube denominada Kubernetes. Sin embargo, para pequeñas aplicaciones o desarrollos personales puede ser complejo disponer y administrar un conjunto de máquinas virtuales, por lo que en estos ámbitos recomendamos usar Docker ya que está más adaptado a entornos pequeños y es el paso previo necesario para poder llevar las aplicaciones a Kubernetes si el proyecto escala en tamaño.
9 – Manteniemiento del sistema de información
No debe desestimarse el esfuerzo necesario durante la fase de mantenimiento, sobre todo si hay un compromiso de garantía vigente o si se ha establecido una bolsa de horas para realizar ajustes y evolutivos sobre el sistema de información.
Los mantenimientos y ajustes post venta suelen comerse una gran parte del presupuesto del proyecto, puesto que los usuarios, salvo que sean otros informáticos, no suelen dar toda la información por norma general, ya sea por desconocimiento o para no obtener un presupuesto elevado. Luego se suelen excusar en que el sistema no funciona correctamente porque se han quedado elementos fuera del alcance básicos para el funcionamiento. De ahí que es importante vincular al usuario en el catálogo de requisitos y hacer mención que los puntos no incluidos no entrarán en garantía.
En definitiva, los usuarios SIEMPRE quieren cambios, así que conviene estar preparado para que el coste de esos cambios no se coma los posibles beneficios del proyecto, ya sea facturando horas adicionales o mediante una contratación de una bolsa de horas para evolutivos.
Los aspectos técnicos de esta fase no difieren de las anteriores ya que simplemente se componen de la realización de análisis de los cambios, implementación de estos y desplegar de nuevo una versión de la aplicación. En cierta manera, los cambios y evolutivos son ciclos más pequeños de análisis, diseño, implementación, pruebas y puesta en producción. Así que pueden seguirse las mismas instrucciones anteriores.
Sí es importante tener presente que todos los cambios que se hagan en la aplicación deben estar sometidos bajo el control de código fuente con git o similar, dejando archivado correctamente, con ramas y etiquetas, las diferentes versiones liberadas. Sobre todo si coexisten varias versiones de la misma aplicación en diferentes clientes de manera simultánea.
No debe olvidarse de introducir, si es necesario, los sistemas de copia de seguridad o realizar y ejecutar los planes de contingencia para poder volver operativo la aplicación en caso necesario y ante cualquier desastre, ya sea de la base de datos o del servicio que mantiene la aplicación en ejecución.
10 – Finalización o clausura del proyecto
Todo principio tiene su fin, y a veces no queda más remedio que apretar el botón off de una aplicación desarrollada con mucho esfuerzo. Aun así no debe verse como una derrota, si no como la consecución de su objetivo en el momento necesario y la adquisición del conocimiento adquirido en cada una de las fases, muchas veces traducido a la adquisición del know-how del negocio o del sector que se trate.
En cualquier caso, muchos de los problemas resueltos suelen ser reincidentes. El código escrito quizás sea reutilizable más adelante en una nueva iniciativa. Así que conviene establecer un mecanismo de archivado que permita recuperar las partes útiles para las próximas ocasiones. Esto también permitirá ofrecer un presupuesto más ajustado y por tanto ser más competente al poder reutilizar código previamente escrito y validado.
Conclusiones
Esperamos que esta guía te haya servido para esclarecer los pasos que se deben seguir en la realización de un proyecto de software, página web o aplicación móvil para un cliente. En estas situaciones, conviene dejar cerrado el compromiso adquirido en cuanto a las funcionalidades que se esperan y la contra prestación económica por el trabajo realizado y las obligaciones a futuro de las garantías o del mantenimiento.
Si es tu caso, y has realizado algún proyecto, cuéntanos tu experiencia o indícanos qué pasos te han ido bien para compartilos con la comunidad.
