Es importante saber programar, pero es más importante saber cuándo, cómo y qué vas a programar desde antes de escribir cualquier línea de código. Si estás aprendiendo a programar desde YouTube, tengo que decirte que hay algo que todos hacen mal pero que tiene solución.
Cuando perteneces al gremio de la programación, te llegan solicitudes para implementar la idea de muchas personas. Llegan desde los “Tengo una idea millonaria, pero no tengo dinero, si lo programas te llevas el 15% de las ganancias, vamos a ser ricos” hasta los “Ya tengo la idea al 100%, ya solo es programar” aunque lleguen con ideas no estructuradas y sin algún documento que lo haya acotado.
Para valorar si vale la pena un proyecto y qué hacer cuando decides hacerlo. Te compartiré a través de unos cuántos artículos cómo debemos de enfrentarnos a estas propuestas, ya que no todas son malas.
Antes de hacer algo, aprendamos lo que tienes que hacer
Basado completamente en las etapas del proceso administrativo (de las cuales también hablaremos pero para un enfoque empresarial) ha evolucionado algo que los autores llaman “Proceso de desarrollo del software” o “Ciclo de vida del software”.
La mayoría de autores ponen 5 etapas para simplificarlo, yo propongo 9 etapas, ya que al no ser administrativos, solemos perder consciencia de partes importantes que ellos incluyen implícitamente en las etapas propuestas, y terminamos aprendiendo por las malas que eran cosas importantes.
Investigación preliminar
Es en donde se van a quedar muchísimos proyectos… y eso está muy bien. En esta fase se verifica la factibilidad operacional (si tienes a las personas para desarrollarlo), la factibilidad técnica (los conocimientos técnicos y herramientas para hacerlo) y la factibilidad económica (si tienes el dinero para hacerlo o pagar a quien haga falta).
Levantamiento de la información
Sí, es parte de tu chamba buscar la información detallada del sistema. Lo primero es la entrevista con el cliente, pero en muchas ocasiones es una excelente idea hacer entrevistas a posibles usuarios para saber cuál es el procedimiento que realizan. Así podrás hacer las observaciones pertinentes que te ayudarán a crear requerimientos reales. Una gran técnica es el uso de Dummys o simulaciones audiovisuales del proyecto para analizar el uso del usuario final.
Análisis de requerimientos
Bien, ahora ya conoces bien lo que se busca del sistema, lo que sigue es crear un Documento de especificación de requerimientos, en donde cada función va a ser dispuesta por uno o varios requerimientos específicos.
También es muy importante especificar los requerimientos no funcionales, como el desempeño, la seguridad, la eficiencia, el tipo de servicio, si se va a procesar información sensible y la economía del proyecto. Estos son puntos que cuando somos nuevos, pasamos por alto y es muy importante darles una revisión.
Análisis del sistema
Ya tienes una lista de requerimientos, pero falta saber cómo vas a organizar el sistema para poder implementarlo. Saber qué casos de uso se pueden presentar, qué entes externos van a alimentar el sistema, qué fuentes de datos necesita y las entidades propias del sistema para resolver los casos de uso.
En este punto se crean árboles de uso, diagramas y es buen momento para iniciar a usar un modelo C4 de arquitectura del cual tendremos un artículo en unos días.
Diseño y arquitectura
Wow, llevamos algunas semanas de trabajo duro y no hemos tirado ni una linea de código, ¡Qué aburrido! Pero no te emociones, porque todavía no llegamos a eso
En la parte de la arquitectura, por fin vamos a decidir qué tecnologías vamos a usar (si no fueron especificadas durante la etapa de la economía) y cómo hacer funcionar mejor esas tecnologías. En esta parte se especifica el diseño de la estructura de datos y la conexión con el modelo que los va a servir, qué tipo de arquitectura llevará el sistema y a través de qué tipo de mensajes se comunicarán los módulos definidos en la parte de análisis del sistema. Se crean las interfaces que usará el sistema y se emplea el modelo C4 para definir cada módulo y cada salida de los módulos y es el plan maestro general a específico que se usará para separar y definir el trabajo de los involucrados en el proyecto.
Todo esto es la parte que nos separa a los universitarios de los programadores de Udemy y Plazi, aunque les duela [esos ni llegaron a este párrafo y si llegaron, sean bienvenidos, ya están casi del otro lado].
Programación e implementación
¡Felicidades! Ha llegado el momento más divertido de todos. Contratar a un albañil que haga la chamba porque el arquitecto ya le pasó los planos… o ponerte a codear tu mismo. Esta es la parte más divertida pero la más sencilla cuando ya tienes todo especificado. Momento de ponerte a pelear con los formatos, con las APIs, con el envío de datos y con los demás programadores.
Todo lo anterior vale la pena cuando llega este momento y ya está solucionada la mayoría de los problemas con los que te ibas a encontrar programando al ““.
Pruebas, revisión y despliegue
No importa qué tipo de programador seas, si eres un desarrollador orientado a pruebas u orientado a errores, el momento de crear pruebas unitarias y de integración llegará tarde o temprano. Pero no son las únicas, en proyectos más o menos grandes, llegan a requerir otras importantes como las pruebas de humo que consisten en buscar las fugas en el sistema; o las pruebas de rendimiento, que están destinadas a proyectos que manejarán mucho procesamiento en ciertas horas (Como Uber y Didi en horas pico) y que ayudan a saber si se podría caer el sistema con los recursos asignados.
Si ha pasado las pruebas, es hora de pasar el proyecto a producción, es decir, hacer el despliegue de la versión que se tiene. Recuerda que este proceso siempre será cíclico independientemente del modelo que uses.
Documentación
¿Qué crees? Que si seguiste mi propuesta de proceso de desarrollo de software YA TIENES CASI TODA LA DOCUMENTACIÓN. Por lo menos la documentación técnica, faltan los manuales de usuario, pero que esos los haga el becario, y si se lo puedes pedir en pero con las imagenes optimizadas para impresión, mejor.
Mantenimiento
La posición de este paso dependerá del auto, yo lo pongo al final porque en realidad es parte de la corrección de errores, HotFix e implementaciones que se realizarán junto con la siguiente vuelta del sistema, porque recuerda que la metodología en cascada ya no es tan utilizada y este paso es el principio del siguiente. Aquí además de planear las siguientes implementaciones, se recogen datos para iniciar un nuevo análisis e implementación de extensiones del sistema.
Vaya, no es lo que esperabas… ¿o si?
La parte de programación lleva menos tiempo del que a todos nos gustaría, excepto cuando eres Jr y te la pasas programando porque no sabes ni lo que vas a hacer. Si un cliente, cuando llega diciendo que “ya tiene el 100%, solo falta programar” nos llega con todo esto, literalmente solo nos faltaría programar… cosa que en todos los años que tengo de experiencia, no me ha pasado NI UNA SOLA VEZ.
Este es el primer artículo de varios que estaré escribiendo siendo más específico en cada una de las secciones y en el modelo C4. Si te gustó lo que leíste aquí, aunque te doliera [porque espero que nadie se tomara personal lo de arriba], déjame tus impresiones en redes sociales, porque yo todas las leo… esos insultos no se denuncian solos.
¡Gracias por leer y feliz codeo!