Historia de una simulación, con una fecha de entrega ajustada, y una lección valiosa
Hace tiempo, cuando todavía estaba en la universidad, había una asignatura llamada “laboratorio de ingeniería de software”. La idea era crear una solución software junto con los compañeros, pasando por todas las fases del proceso de desarrollo software, haciéndolo tan realista como fuera posible.
Pero lo que hacía que este laboratorio fuera un tanto real, bastante infame, y totalmente inolvidable, era recibir la siguiente notificación cuando la fecha de entrega estaba verdaderamente cerca:
“Los requisitos de la aplicación han cambiado. Ahora tiene que funcionar de una forma distinta.”
También puede leerse como: “No quiero lo que habéis programado. Por favor, tiradlo y empezad de nuevo.“
El objetivo de este laboratorio no era que la gente comenzase a soltar tacos de forma creativa – aunque también lo conseguía. No, en realidad, pretendía preparar a la gente para un entorno real de desarrollo software. Y con más de una década de experiencia profesional tras estos sucesos, puedo garantizar que se trataba de una lección acertada y bien valiosa que todavía recuerdo.
Los requisitos cambian porque las necesidades de los usuarios evolucionan. Pero también pueden cambiar porque haya malinterpretado las necesidades reales de sus clientes, lo que llevará a cambios en las especificaciones. La lección que hay que sacar de todo esto es que sólo si se entienden los requisitos de sus clientes se podrán desarrollar soluciones que los satisfagan.
Después de todo, sólo se puede ver la solución si se es capaz de ver el problema.
Y precisamente de esto es de lo que trata la ingeniería de requisitos. Y esto es lo que la hace tan importante.
Cómo se aplica la ingeniería de requisitos, explicado de forma sencilla
Así pues, entregar una solución exitosa require entender qué necesitan sus usuarios. Incluso hace más de una década, encontré fascinante esta parte del proceso de ingeniería software, y por ello uno de mis primeros proyectos se centraba en el Control de Calidad y en la Ingeniería de Requisitos.
Puede sonar complicado, pero era en realidad algo bastante revelador, porque me proporcionó una estructura que mejoró la forma en que trataba de entender a mis clientes. Y eso mejoró toda mi forma de trabajar. Desde ese momento, siempre tengo en mente esta estructura – y las necesidades de mis usuarios finales – durante todo el proceso de desarrollo software.
Y merece la pena.
Para muchas empresas, todo este proceso de ingeniería de requisitos comienza identificando sus propios objetivos de negocio de alto nivel. Estos objetivos definirán la línea que las funciones de mis aplicaciones software deberán seguir.
Entonces será esencial descubrir cuál será el mercado objetivo de esa aplicación, o en esencia, quiénes serán los usuarios finales de dicho software. Definiendo los casos de uso y los diagramas de interacción de dichos usuarios, y continuando este proceso con bocetos de la interfaz, tendré un mapa de lo que el sistema debería hacer por ellos.
Merece la pena tener toda esta información en mente durante todo el proceso de desarrollo, porque esto garantizará que se pasen las validaciones de la aplicación de forma exitosa, a lo largo de todas las iteraciones de un proceso de desarrollo ágil. En definitiva, mi código hará exactamente lo que mis usuarios finales esperan que haga.
Cuanto mejor pueda entender a los usuarios finales de una aplicación, más cerca estaré de instalar una versión definitiva y exitosa del producto software. Y eso es esencial, porque es sinónimo de tiempo, dinero, y satisfacción del cliente.
Yo estoy preparado. Ahora, hábleme usted de su proyecto.