Para entender los problemas que se presenta en la Arquitectura de Software, debemos entender su disciplina, los conceptos y principios que la gobiernan, para esto es importante identificar, conocer, entender y aplicarlos durante el diseño de software y darle a esta etapa una relevancia dentro del desarrollo de productos.
Es por ello, que actualmente existe una tendencia a presionar a los equipo desarrollos con entregas “rápidas”, confundiendo lo con "agilidad", trayendo como consecuencia creer que la implementación de prácticas de ingeniería hace tedioso y dificultoso el trabajo en nuestro proceso de desarrollo de software, con la adopción de métodos ágiles y flexibles como Crystal Families, Scrum, Extreme Programming, Lean Development, Agile Unified Process, Disciplined Agile Delivery y otros tantos.
En las organizaciones se ha creado la concepción de que debemos dejar de hacer actividades propias de la ingeniería de software para poder aplicar metodologías ágiles, lo cual está muy lejos de la realidad, si buscamos la esencia en todos estos o en muchos de estos métodos ágiles, podemos identificar un énfasis muy fuerte en procesar, analizar y diseñar antes de empezar a hacer, la diferencia es que las diferentes técnicas y las prácticas que se realizan en el trabajo de ingeniería van a variar entregando y enfocándose en producto con valor hacia el cliente, en las prácticas de modelamiento y diseño bajo estos nuevos esquemas de trabajo, no se trata hacer diseños completos con mucha documentación y tampoco debemos hacer diseños de software que vuelvan lenta la dinámica y la flexibilidad del proceso de desarrollo y que no permitan a los desarrolladores hacer su trabajo.
En esta problemática general del diseño de arquitectura se puede identificar:
1. Se cree que hacer software se trata de terminar un proyecto y se centra en el desarrollo de ese proyecto, hay que tener en cuenta que el software es un producto y que tiene un ciclo de vida que gobierna las diferentes fases del desarrollo de software
2. No se tiene un conocimiento concreto en que significa diseñar software, no se reconoce el valor que agrega el diseño de software en el proceso del desarrollo, eso lo podemos ver en esta caricatura de DILBERT, o en muchas caricaturas que hay acerca del desarrollo de software, como expertos en ingeniería de software no debemos esperar que los clientes, los usuarios o los demás stakeholders que hacen parte de la ingeniería tengan un conocimiento profundo de cuáles son las actividades necesarias para crear o para mantener un producto software, no todos los usuarios o clientes reconocen que el desarrollo de un producto requiere un análisis de las necesidades, requiere una etapa de diseño y que necesita de un proceso de construcción, de pruebas, y eso hace que al momento de planear actividades nuestro proceso de ingeniería pierda valor, las diferentes cosas que hacen fuerte ese proceso y que solamente sea importante entregar el producto sin importar su calidad.
Como ingenieros de software debemos darle mayor fuerza a nuestro proceso de desarrollo de ingeniería, eliminar la idea que la ingeniería de software no es una ingeniería sino una artesanía, tal vez porque somos una de esas áreas de conocimiento que tiene menos madurez y no tenemos procesos concretos y repetibles, ni procesos que se basan en álgebra, ni en conceptos matemáticos, esta falta de conceptos matemáticos se deriva en esa naturaleza misma del software, ya que el software se mueve en un entorno caótico, en el desarrollo de software hay demasiadas variables que se involucran al momento de crear un producto de software, los cambios de las necesidades del cliente, la influencia del personal que se involucra en el proceso de desarrollo, el involucramiento de diferentes participantes al momento de desarrollar, hace que el proceso de ingeniería de software tenga muchos resultados que están relacionados con una artesanía, o sea, cada producto que hacemos es totalmente diferente a cualquier otro producto, pero esto no nos exime de tener procesos y definiciones claros al momento de realizar nuestro trabajo, todo esto nos va a llevar a unificar y establecer el primer concepto que debemos tener alrededor de lo que es diseño de software y que es el significado del diseño mismo.
¿Qué es diseño de software en realidad?
Como objetivo, el diseño de software es el proceso que nos va a permitir construir aplicaciones robustas, mitigar riesgos, planear efectivamente esa fase de codificación, dejar que los desarrolladores no se pierdan al momento de echar código, el desarrollo de software actualmente es totalmente frágil, es similar a estos juegos de Jenga, si recuerdan el juego de los bloquecitos que se van quitando?, vamos armando esa estructura y si movemos alguna pieza se cae toda la estructura, así es nuestro desarrollo de software actualmente, por que las estructuras que se están haciendo son poco robustas, escuchamos frases cotidianas y coloquiales en muchas compañías, como, esa aplicación no se puede modificar, cualquier cambio a esa aplicación se cae, esa aplicación no la podemos ni mirar, todos estos ejemplos dan una idea de la fragilidad que actualmente tiene el software, consecuencia de la fragilidad que tenemos en el proceso de desarrollo, los productos que creamos no tienen cimientos sólidos, no poseen esos diseños robustos, por otra parte, la definición nos dice que el resultado del diseño o el diseño es el resultado de ese proceso de diseñar, al final vamos a obtener un artefacto que nos va a permitir hacer transferencia del conocimiento de toda la información que recopilamos, ya sea que lo hagamos en un tablero, en una hoja de papel o cualquier lenguaje de modelado robusto o si lo hacemos entregando el código como tal, un buen código estructurado, un buen código nos va a permitir ver el diseño, si recuerdan el juego de los bloquecitos que se van quitando?, vamos armando esa estructura y si movemos alguna pieza se cae toda la estructura, así es nuestro desarrollo de software actualmente, por que las estructuras que se están haciendo son poco robustas, escuchamos frases cotidianas y coloquiales en muchas compañías, como, esa aplicación no se puede modificar, cualquier cambio a esa aplicación se cae, esa aplicación no la podemos ni mirar, todos estos ejemplos dan una idea de la fragilidad que actualmente tiene el software, consecuencia de la fragilidad que tenemos en el proceso de desarrollo, los productos que creamos no tienen cimientos sólidos, no poseen esos diseños robustos, por otra parte, la definición nos dice que el resultado del diseño o el diseño es el resultado de ese proceso de diseñar, al final vamos a obtener un artefacto que nos va a permitir hacer transferencia del conocimiento de toda la información que recopilamos, ya sea que lo hagamos en un tablero, en una hoja de papel o cualquier lenguaje de modelado robusto o si lo hacemos entregando el código como tal, un buen código estructurado, un buen código documentado nos va a permitir ver el diseño, concretamente el diseño va a hacer el proceso de describir, organizar, hacer la estrategia de los diferentes componentes del sistema, y así vamos a encontrar que tenemos nuestro proceso de diseño arquitectónico, nuestro proceso de diseño detallado, el diseño de software es el insumo para la siguiente etapa del desarrollo de software que es la construcción, por ende, debe tener un suficiente nivel de detalle que le permita a los codificadores, a los constructores llegar a la materialización de ese diseño en un código, y ese es otro problema, otra fuente de problemas que tenemos en el software actualmente, los codificadores no tienen un insumo que es suficientemente útil o que les sirva de guía para realizar su trabajo, el diseño está perdiendo valor en las diferentes etapas porque no es suficientemente claro, porque es demasiado extenso, porque es demasiado tedioso de leer, de entender y no se centra en los elementos que son relevantes para la construcción, sin ese insumo a los desarrolladores se introduce mayor reprocesamiento en la etapa de construcción, debido a que los errores que se deberían encontrar en el diseño se están encontrando en las etapas posteriores, eventualmente en la etapa de pruebas, y eventualmente van a propagarse hasta la etapa de producción, lo cual obliga a que volvamos a la etapa de requisitos para establecer qué fue lo que se hizo mal, esas cosas deberían estar identificando y planeándose en cada una de las etapas, y en cuanto a los riesgos técnicos deben ser identificados propiamente en la fase de diseño del software.
No hay comentarios:
Publicar un comentario