¿Cómo afecta la gestión de ingeniería de software a la arquitectura y la estructura del software producido?

Dejando a un lado a los malos ingenieros de software y las malas organizaciones (respondidas ya por Jack Menéndez), la ingeniería de software debería, en buenas condiciones, tener un gran impacto en los aspectos arquitectónicos y de producción del desarrollo de software.

Si tuviera que proporcionar una respuesta en pocas palabras, diría que la Ingeniería de Software afecta el software producido por ser un tomador de decisiones en todo el proceso de desarrollo. Pero esto requiere un poco de explicación.

Ingeniería de Software participa en todo el ciclo de producción de software; Pre-desarrollo, durante el desarrollo y post-desarrollo.

  • Desarrollo previo: Ingeniería de software diseña el software y toma decisiones sobre herramientas. Esta es la fase de análisis y diseño, para la cual se capacitó a cualquier buen ingeniero de software.
  • Durante el desarrollo: la ingeniería de software desarrolla, supervisa y adapta el diseño a las condiciones cambiantes. Los ingenieros de software deberían participar idealmente en el proceso de desarrollo junto con los desarrolladores; ellos también son programadores. También debe monitorear si el desarrollo está siguiendo lo establecido durante el diseño y debe ser inteligente y humilde al hacer cambios sobre la marcha en su diseño si el desarrollo demuestra mejores estrategias o si cambian los requisitos del software.
  • Postdesarrollo: las responsabilidades gerenciales de ingeniería de software no terminan con el producto terminado. La ingeniería de software ayuda a establecer prácticas de mantenimiento de software y, por lo general, prepara hojas de ruta para otras versiones del software.

Esta es una visión simplista de cómo actúa la ingeniería del software en el ciclo de producción del software. Pero siento que dos notas son importantes:

Nota 1:
La ingeniería de software, como disciplina formal, solo es realmente relevante para proyectos de tamaño medio o grande. Los proyectos pequeños pueden prescindir de la participación formal de los ingenieros de software en la estructura organizativa de los equipos de desarrollo. Esto no quiere decir que las habilidades no sean necesarias o que estos productos no requieran alguna forma de diseño y análisis. Pero un enfoque ad-hoc para la ingeniería de software a menudo es todo lo que se requiere.

Nota 2:
Lo anterior funciona si la organización detrás del software comprende claramente el desarrollo del software y se compromete a producir productos de buena calidad. Como menciona Jack Menéndez, desafortunadamente este no es el caso en muchas compañías que son, sorprendentemente, compañías de desarrollo de software. Las razones para esto no son un poco complejas y están destinadas a otra pregunta. Lo que hay que tener en cuenta es que no hay nada intrínsecamente malo con la Ingeniería del Software como disciplina. Es un bien absoluto, por así decirlo. Sin embargo, los ingenieros de software a menudo trabajan como enlaces entre la gerencia y la producción. Y las presiones del lado de la administración a menudo los llevan a comprometer y traicionar su propio enfoque riguroso de disciplina para el desarrollo de software.

La forma más profunda en que la gestión de la ingeniería de software influye en la arquitectura y la estructura del software es que, en la mayoría de los casos, lo ignoran por completo y buscan el oro, en detrimento de todos. La mayoría de las organizaciones no están dispuestas o son demasiado ignorantes para gastar un poco de capital en tiempo y dinero para diseñar su software. ¿Te imaginas a un contratista construyendo un edificio de oficinas que tiene tanta prisa por terminar el proyecto que no compra planos para la estructura, sino que simplemente comienza a deteriorar el concreto para una base hecha a medida que avanza? Esto es lo que veo una y otra vez en el desarrollo de software y luego alguien me pregunta: ¿Puedes hacer que esto funcione? NO GRACIAS Ya he visitado Winchester Mystery House.