¿Cuáles son los efectos de no seguir la ingeniería de software para el desarrollo del programa?

Buenas respuestas ya, pero esta es mi opinión sobre la Ingeniería de Software (SE) como disciplina.

Al igual que Agile y Scrum, debe usar solo la cantidad de SE que el proyecto necesite.

Un proyecto pequeño y desechable que requiere solo 1 o 2 desarrolladores durante unas pocas semanas (por ejemplo, un proyecto de migración de datos único) necesita muy poco del proceso formal de SE.

A medida que cualquier dimensión del proyecto se amplía (o se puede anticipar que se ampliará en el futuro), se necesitan más procesos de SE. SE, como cualquier otra disciplina de ingeniería, es una colección de procesos y herramientas, conocimiento si lo desea, que mejoran la calidad, la mantenibilidad y la usabilidad de los sistemas de software durante todo el ciclo de vida del sistema.

He trabajado en varios millones de líneas de sistemas de código que no siguieron las buenas prácticas de SE y el resultado fue una confusión que hizo que las correcciones de errores y las mejoras costaran al menos 10 veces más de lo que deberían tener. A esta escala, o en cualquier sistema crítico para la seguridad (p. Ej., Control de tráfico aéreo o dispositivos médicos), no seguir buenas prácticas formales terminará costando mucho dinero o incluso vidas.

El efecto más visible de no seguir la ingeniería de software será no obtener su programa en absoluto .

La ingeniería de software y el desarrollo de software son términos intercambiables. Cuando “desarrollas un programa” haces ingeniería de software. Si el programa que escribe estará agrupado en una entidad ejecutable implementada en alguna computadora, inevitablemente estará haciendo ingeniería .

Si tiene alguna pregunta sobre la disciplina de ingeniería de software y las mejores prácticas , lo más probable es que no llegue a la fecha límite dentro de su presupuesto. Las actualizaciones futuras serán innecesariamente costosas también.

Cuando no sigue las mejores prácticas:

  • Se envían más defectos
  • Se tarda más en cambiar y extender el código
  • Algunas fallas terminan siendo reparables sin romper algo más por la solución
  • Es dificil leer el codigo
  • Es difícil hacer pequeños cambios sin tener grandes efectos de ondulación
  • Es difícil hacer frente a mayores volúmenes de uso.

El resultado más desastroso será una aplicación que no será fácil de cambiar en el futuro, en respuesta a los requisitos cambiantes del cliente.

Para obtener una respuesta detallada a su pregunta y otros temas relacionados, le sugiero que lea los escritos de Robert C. Martin, como Clean Code, Clean Architecture y Agile Software Development; Todos estos son grandes libros. (¡Es conocido como tío Bob!)