Me imagino que ya conoces la famosa expresión de la hoja en blanco. No te la voy a contar, vaya.
Pues es lo que me ha pasado con el mail de hoy, al menos con el asunto del mail.
Bueno,
digamos que yo ahora estoy así con el proyecto que te hablé ayer.
Más o menos. Le he llamado trabajo.io
Por lo menos tengo título y sé de lo que quiero hablar.
Porque escribir código es como escribir un libro.
Tiene que tener un principio, un nudo y un desenlace.
En el caso del software, los pasos son análisis, diseño, implementación, pruebas y despliegue.
(Ei, que esta vez no lo he tenido que mirar en Google, estoy aprobado)
Bien.
Digamos que yo he hecho la fase de análisis.
En esta fase se trata de entender y conocer el problema que estás atacando y definir la solución a muy alto nivel, nada de tecnologías, por lo general.
Es verdad que como es un proyecto personal NO necesito seguir el proceso que te he dicho.
Es verdad.
Aún así, me gustaría mostrarte paso a paso a nivel práctico lo que dice la teoría, por eso lo hago.
Y también para refrescar la teoría y buscar puntos de mejora
Bien.
Dicho esto, te sigo contando lo que se espera de esta fase de análisis.
En estas primeras fases se suele hacer más documentación.
En mi caso, voy a usar UML porque es lo que conozco mejor.
Cuando acabe esta fase, tendré el modelo del dominio y el diagrama de casos de uso.
El modelo de dominio me permite definir el dominio de palabras (conceptos) que voy a utilizar para describir el problema y la solución.
En un equipo de uno solo no tiene sentido, porque el conocimiento lo tiene uno solo.
Pero como por lo general, los equipos de desarrollo de software tienen más de un integrante, es importante marcar el lenguaje que se va a utilizar en el proyecto.
En mi caso, tú formas parte del equipo, de ahí que lo hago.
Una vez tenemos el modelo del dominio, se trata de pensar qué puede hacer el usuario a través de nuestra aplicación para resolver el problema.
En otras palabras, respondemos al como.
Eso son los casos de uso: como interactúa el usuario con el sistema.
La teoría pura lo define como la interacción de un usuario con el sistema esperando un resultado de interés.
La gracia está en quién es el usuario. Un usuario puede ser una persona, una máquina externa cuando provees una API de tu negocio o incluso tu propio sistema si consume eventos internos.
Mañana más y mejor, feliz domingo
Josué.
PD1: hoy mucha teoría importante, mañana será más práctica, si me da tiempo.
PD2: si te gusta lo que lees, te agradecería que lo compartieras en redes sociales.
Soy Josué Alcántara y cada día envio un mail con una idea para escribir software de calidad. ¿A quién se la envío? A mi lista de suscriptores. Día que estás fuera, idea que te pierdes. Así de fácil.
