Please enable JavaScript.
Coggle requires JavaScript to display documents.
Diseño ágil. (Caso de estudio. (Se plantea el desarrollo de un software…
Diseño ágil.
Caso de estudio.
Se plantea el desarrollo de un software que debe leer del teclado a la impresora, estos son los requisitos del cliente.
La persona define un periodo en el cual trabajara en el desarrollo del sistema tomando en cuenta su demás trabajo.
La persona empieza con el diseño del software para posteriormente programarlo sin embargo no toma en cuenta los posibles cambios que los clientes le podrían solicitar.
Es un éxito, sin embargo la persona decide cambiar los requisitos y que lea no solo teclado si no también lea desde el "paper tape reader" debido a esto el programa cae en un mal diseño, a causa de no pensar aplicando diseño ágil.
El problema se soluciona pero el cliente nuevamente vuelve a cambiar los requisitos, pero es algo que los desarrollares deben aceptar, pero una buena manera de evitar cambiar tanto el programa es aplicando un buen diseño y valorar los posibles cambio.
El programa fue decayendo y si seguía así posiblemente llegaría un momento en el que ya no seria lo exitoso que fue debido al diseño que manejaba que era malo y eso lo hace muy difícil de mantener.
Ahora si desde un inicio se hubiera valorado como se debía hubiese sido mucho mas sencillo aplicar los cambios que pide el cliente, sin embargo quizá lo que mas impidió el buen pensamiento del diseño fue la cantidad de trabajo que realizaba diariamente el programador.
Mal diseño.
Durante el desarrollo de un software se inicia con imagen clara de lo que se desea modelar, pero en el transcurso del desarrollo suelen surgen cosas, que no permiten un buen diseño del software.
Rigidez.
Un código rígido resulta muy complicado de cambiar, una modificación podría llevar a otra. Si ocurre algún imprevisto habría que modificar distintas partes del código, descubriendo mas cambios que se deberían de hacer, logrando así una tarea ardua y tediosa.
Fragilidad.
Es cuando el código se fragmenta en muchas zonas en donde un problema se debe arreglar en cada una de esas zonas, y empiezan a surgir problemas nuevas problemas, apareciendo en donde no había antes, es decir hay problemas en el código al aplicar un cambio.
Inmovilidad.
Surge cuando partes del código podrían servir en otros sistemas pero es difícil cambiarlo de lugar debido a que podría ocasionar fallas, suele ser muy común.
Viscosidad.
La viscosidad de un código se ve cuando un código es difícil de preservar es decir que los cambios aplicados al software conserven el diseño de lo que se tenia.
Complejidad innecesaria.
Surge cuando el código contiene elementos que no son útiles, que los desarrolladores anticipan cambios posteriores y instalan en el software esos sin embargo aunque a veces se utilicen, no van a necesitarlas todas.
Repetición innecesaria
Cortar y pegar no funciona muy bien durante el desarrollo de código, por ejemplo si alguien del equipo encuentra en el mismo código algún fragmento que le puede ser útil a y lo copia y pega pero ya alguien había hecho eso y así sucesivamente con todo el código surgen repeticiones del código por todo lado.
Opacidad.
Es cuando hay código muy difícil de entender, para evitarlo lo recomendable es ponerse en el campo del lector y hacer un esfuerza para que el código sea claro y sencillo de comprender para sus lectores, ayuda que otros lo revisen.
Software Rots
Suele surgir cuando no se valoran cambios posteriores al desarrollo del software, aunque como desarrolladores es bien sabido que los requisitos en un software suelen cambiar, degradando el código una y otra vez, para evitar esto se mantiene el diseño del sistema lo más limpio simple posible y lo respalda con muchas pruebas unitarias y pruebas de aceptación.
Es un conjuntos de patrones, principios y practicas aplicadas al desarrollo de un software desde los inicios del desarrollo, intentando pensar los posibles cambios que pueden surgir cuando un cliente decide cambiar los requisitos de lo solicitado. Siempre se mantiene limpio el código.