Revisión del 09:18 31 oct 2018 editar 2.139.176.126 (discusión) →‎Lo importante es que funcione ← Edición anterior		Revisión del 10:30 31 oct 2018 editar deshacer Lsanabria (discusión \| contribs.) 19 340 ediciones m Revirtiendo vandalismo Edición siguiente →
Línea 25: === No hace falta dar detalles para empezar === Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, y podemos dar los detalles más adelante. Una mala definición inicial es la principal causa del trabajo inútil. Como dice Ries en su libro 'Lean Startup' el mayor despilfarro es crear algo que nadie quiere.creo que no fuese justificable invertir tiempo y esfuerzo en unproyecto en el cual nadie querra, lo mas apto es acercarnos al mismo proyecto contanto deseo que nuestro proyecto en si sea entregar el producto terminado en garantia a la funcionalidad que se le dara, mas aun a su uso y practisidad. === El software se cambia sin esfuerzo === Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente porque el software es flexible. Es verdad que los requisitos cambian y que es algo en cierto sentido innevitable, pero el impacto del cambio varía en función del momento en que se introduzcan los cambios. ==Mitos de los desarrolladores== === Lo importante es que funcione === No es necesaria ninguna metodología: una vez que escribamos el programa y hagamos que funcione, nuestro trabajo ha terminado Los datos empíricos revelan que entre el 50% y el 70% de todo el esfuerzo dedicado a un programa (que ha sido desarrollado con metodologías tradicionales) se realiza después de que se haya entregado al cliente por primera vez. === La calidad no se puede ir midiendo === Hasta que no tenga el programa ejecutándose, no tengo forma de medir su calidad. No Existen técnicas para ir asegurando la calidad durante el proceso, como las no Revisiones Técnicas Formales (RTF). En ellas, durante el proceso de desarrollo, los programadores se sientan y revisan línea a línea el código programado por sus compañeros. Y también existen medidas, como el número de fallos detectados durante el proceso de desarrollo, que pueden irse comparando con los registros históricos, y que más tarde servirán para elaborar indicadores de calidad clásicos (al relacionarlos con el número de defectos encontrados por el cliente tras la entrega del producto). === El ejecutable es el producto === Línea 44 ⟶ 49: Aunque estos mitos representen situaciones obvias de mala praxis para un profesional bien formado, son más populares de lo que parece en el ecosistema del desarrollo software actual. Es por ello que debemos movernos con sumo cuidado en el entorno laboral y contribuir a derribar estos falsos mitos. Por otro lado es nuestra obligación como profesionales ~~(hay muchos profesoresas como esta para dar sus apuntes al alumnado)~~el estar permanentemente informados de las buenas prácticas en materia de Ingeniería del Software y tratar en la medida de lo posible de comprender las razones, fundamentadas en datos y experiencias reales, que hay detrás. ==Lecciones relacionadas==

Diferencia entre revisiones de «Mitos del desarrollo de software»