Dale justo lo que necesita
Esta entrada corresponde al capítulo 2 del libro Head First Object Oriented Analysis and Design el cual tiene por nombre Dale justo lo que ellos quieren y aborda el primer punto de las buenas prácticas para desarrollar software que nos indicaba que primeramente nuestro software debe de hacer únicamente lo que nuestro cliente quiere así que... ¡Allá vamos!
Esta vez va de perros
En este capítulo dejamos atrás las guitarras para tomar el caso de Tood y Gina, unos clientesmuy flojos que desean hacer una puerta automática para que su pequeño perro no vuelva a hacer sus necesidades dentro de casa. Una vez tomada el requerimiento principal como buenos en realidad malos programadores nos ponemos manos a la obra y terminamos nuestra aplicación en tiempo récord pero todo se viene abajo cuando los conejos y las ratas entran a la cocina. ¿Por qué pasó esto?
Este capítulo nos deja muy en claro como el tener claro los requerimientos antes de hacer software es muy, pero muy importante. Si estos no están del todo claros nuestras aplicaciones podrían funcionar, sí, pero de una manera muy diferente a la que nuestros clientes quieren y esto no los haría felices en lo absoluto.
¿Requeri...qué?
Vamos, es una palabra que tanto tu como yo hemos escuchado hasta el cansancio en nuestra carrera y según el libro no es otra cosa más que una cosa específica que tu sistema tiene que hacer de una manera correcta. Pero venga, que esta definición igual y nos dejó en las mismas así que la desglosaremos.
Cosa específica: Un requerimiento es usualmente una cosa simple que tu puedes probar una y otra vez para asegurarte que el requerimiento se cumpla de manera efectiva.
Sistema: No es otra cosa que tu aplicación completa, el proyecto por el cuál tantas lágrimas has derramado.
Hacer: Quizá tu sistema tenga que hacer muchísimas cosas y los requerimientos denotarán las mismas.
Manera correcta: Recuerda que tu cliente decide cuando el sistema funciona, incluso si el se equivoca al momento de expresar esta parte él decidirá cuando todo va como la seda.
¿Cómo tomar buenos requerimientos? Bueno, de la forma menos esperada posible: hablar con nuestro cliente. Sí, que tendrás que salir de tu cueva y hablar con otro ser humano aunque sea lo último que quieras hacer. Una vez que tengas tus requerimientos la mejor cosa que puedes hacer es entender qué es lo que el sistema debería de hacer, pero venga, no estoy hablando de saber leer tu libreta donde anotaste lo que se supone que deberías de hacer, no, realmente debes de entender qué es lo que debe de hacer y si es necesario hacerte un experto en el tema.
¿Qué pasa si además de haber planeado todo correctamente y algo va mal? Bueno, primeramente no entres en pánico. Estas cosas pasan y pasan mucho. A veces las personas, los animales o incluso los objetos no se comportan de una manera previsible y todo tiende a ir mal, pero ten en cuenta que siempre debes de tener alternativas, a estas alternativas se les conoce como alternate paths.
Casos de la vida real
Durante las demás páginas del libro comenzamos a hacer nuestra lista de cosas que nuestro sistema debe de hacer, sin embargo, esto tiene un nombre en específico y se les llaman casos de uso. ¿De qué van? Estos casos de uso describen qué es lo que tu sistema debe de hacer para cumplir una meta o tarea de nuestro cliente. Todos los casos de uso responden a un qué, es por esto que en cuando estés escribiendo tus casos de uso no te preocupes por el cómo, sólo por el qué pues en este momento sólo nos debemos de enfocar en lo que el sistema necesita hacer.
Un caso de uso se enfoca en una simple meta y aunque parezca que tu requerimiento cambia de manera mínima o forma parte de otro, un nuevo caso de uso debe de ser planteado. Desde luego, el único objetivo del caso de uso es ayudar a completar la meta del cliente.
Si las cosas pueden ir mal, irán mal
Una vez que nuestros casos de uso estén listos ya podemos comenzar a programar. Después de darnos un tiro con nuestro código nuestro programa ya funciona, yeeeey, pero... ¿Qué pasa si todo no va bien? Bueno, aquí es dónde comienzas a escribir las alternativas para cuando no todo va del todo bien e incluso hay conceptos que los describen de una manera muy intuitiva.
Happy path: También conocido como main path, este funciona únicamente cuando todo va bien. Usualmente es la primera forma que nuestro cliente nos describe.
Cosa específica: Entra en acción cuando algo no va como debe durante la ejecución del main path. Digamos que es la alternativa.
Bien, ahora ya todo funciona como debería y hemos cumplido la primera buena práctica del desarrollo de software.
Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados. También pásate al repositorio que estoy haciendo con el código de cada capítulo para obtener todo lo relacionado a ellos: GitHub.
Esta vez va de perros
En este capítulo dejamos atrás las guitarras para tomar el caso de Tood y Gina, unos clientes
Este capítulo nos deja muy en claro como el tener claro los requerimientos antes de hacer software es muy, pero muy importante. Si estos no están del todo claros nuestras aplicaciones podrían funcionar, sí, pero de una manera muy diferente a la que nuestros clientes quieren y esto no los haría felices en lo absoluto.
¿Requeri...qué?
Vamos, es una palabra que tanto tu como yo hemos escuchado hasta el cansancio en nuestra carrera y según el libro no es otra cosa más que una cosa específica que tu sistema tiene que hacer de una manera correcta. Pero venga, que esta definición igual y nos dejó en las mismas así que la desglosaremos.
Cosa específica: Un requerimiento es usualmente una cosa simple que tu puedes probar una y otra vez para asegurarte que el requerimiento se cumpla de manera efectiva.
Sistema: No es otra cosa que tu aplicación completa, el proyecto por el cuál tantas lágrimas has derramado.
Hacer: Quizá tu sistema tenga que hacer muchísimas cosas y los requerimientos denotarán las mismas.
Manera correcta: Recuerda que tu cliente decide cuando el sistema funciona, incluso si el se equivoca al momento de expresar esta parte él decidirá cuando todo va como la seda.
¿Cómo tomar buenos requerimientos? Bueno, de la forma menos esperada posible: hablar con nuestro cliente. Sí, que tendrás que salir de tu cueva y hablar con otro ser humano aunque sea lo último que quieras hacer. Una vez que tengas tus requerimientos la mejor cosa que puedes hacer es entender qué es lo que el sistema debería de hacer, pero venga, no estoy hablando de saber leer tu libreta donde anotaste lo que se supone que deberías de hacer, no, realmente debes de entender qué es lo que debe de hacer y si es necesario hacerte un experto en el tema.
¿Qué pasa si además de haber planeado todo correctamente y algo va mal? Bueno, primeramente no entres en pánico. Estas cosas pasan y pasan mucho. A veces las personas, los animales o incluso los objetos no se comportan de una manera previsible y todo tiende a ir mal, pero ten en cuenta que siempre debes de tener alternativas, a estas alternativas se les conoce como alternate paths.
Casos de la vida real
Durante las demás páginas del libro comenzamos a hacer nuestra lista de cosas que nuestro sistema debe de hacer, sin embargo, esto tiene un nombre en específico y se les llaman casos de uso. ¿De qué van? Estos casos de uso describen qué es lo que tu sistema debe de hacer para cumplir una meta o tarea de nuestro cliente. Todos los casos de uso responden a un qué, es por esto que en cuando estés escribiendo tus casos de uso no te preocupes por el cómo, sólo por el qué pues en este momento sólo nos debemos de enfocar en lo que el sistema necesita hacer.
Un caso de uso se enfoca en una simple meta y aunque parezca que tu requerimiento cambia de manera mínima o forma parte de otro, un nuevo caso de uso debe de ser planteado. Desde luego, el único objetivo del caso de uso es ayudar a completar la meta del cliente.
Si las cosas pueden ir mal, irán mal
Happy path: También conocido como main path, este funciona únicamente cuando todo va bien. Usualmente es la primera forma que nuestro cliente nos describe.
Cosa específica: Entra en acción cuando algo no va como debe durante la ejecución del main path. Digamos que es la alternativa.
Bien, ahora ya todo funciona como debería y hemos cumplido la primera buena práctica del desarrollo de software.
Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados. También pásate al repositorio que estoy haciendo con el código de cada capítulo para obtener todo lo relacionado a ellos: GitHub.
Comentarios
Publicar un comentario