¿Es el desarrollo de software una disciplina de ingeniería?

¿Puede el desarrollo de software considerarse ingeniería? Si no, ¿cuáles son las cosas que le faltan para calificar como disciplina de ingeniería? Relacionada con esto está esta pregunta en Stack Overflow sobre la diferencia entre un programador y un ingeniero de software .

Existe el Instituto de Ingeniería de Software en la Universidad Carnigie Mellon que prescribe y mantiene los estándares CMMI. ¿Es esto algo que convertirá el desarrollo en ingeniería?

¿Es la ingeniería de desarrollo de software? Si no, ¿cuáles son las cosas que le faltan para calificar así?

Sí, la ingeniería de software es una disciplina de ingeniería.

Wikipedia define la ingeniería como "la aplicación de las matemáticas, así como el conocimiento científico, económico, social y práctico para inventar, innovar, diseñar, construir, mantener, investigar y mejorar estructuras, máquinas, herramientas, sistemas, componentes, materiales , procesos, soluciones y organizaciones ". El resultado de la ingeniería de software es un sistema de software que puede mejorar la vida de las personas y puede implicar una combinación de conocimiento científico, matemático, económico, social o práctico.

En términos de cómo se ve, académica y profesionalmente, varía. ABET puede acreditar los programas de ingeniería de software como programas de ingeniería. Los ingenieros de software pueden ser miembros del IEEE. Algunas compañías consideran que la ingeniería de software es una disciplina de ingeniería, mientras que otras no, es realmente una sacudida.

El mejor libro sobre este tema es el Desarrollo de software profesional de Steve McConnell: horarios más cortos, productos de mayor calidad, proyectos más exitosos, carreras mejoradas . Considera la ingeniería de software como una profesión, la evolución de un oficio a una profesión, la ciencia del desarrollo de software, la diferencia entre la ingeniería de software y la ingeniería de software (aplicando prácticas de ingeniería al software versus ingenieros que construyen software, con un estudio de caso que incluye mi alma mater ), certificación y licencia y ética.

Glenn Vanderburg tiene una serie de charlas llamadas "Ingeniería de software real" que ha impartido entre 2010 y 2015 en una serie de conferencias, junto con dos charlas relacionadas, "Artesanía, ingeniería y la esencia de la programación" (dada en 2011 como discurso de apertura en RailsConf) y "Craft and Software Engineering" (impartido en 2011 en QCon London). Creo que estas conversaciones son un argumento bastante completo de por qué la ingeniería de software es una disciplina de ingeniería.

Un argumento, que Vanderburg menciona brevemente en sus charlas, es el que hizo Jack W. Reeves en 1992 (y revisado nuevamente en 2005) sobre qué es el diseño de software y cómo el código es el resultado de las actividades de diseño de ingeniería de software ( esto también es discutido en el wiki de C2) Una vez que se aleja de las escuelas de pensamiento más antiguas donde la especificación y el modelado es el diseño de software y se convierte en el diseño de software, algunas de las relaciones entre la ingeniería de software y otras disciplinas de ingeniería se hacen más evidentes. Algunas diferencias y las razones de esas diferencias se vuelven aún más evidentes después de ver que la economía del desarrollo de software es muy diferente a muchas otras disciplinas: la construcción es barata (casi gratuita, en muchos casos), mientras que el diseño es la parte costosa.

¿Es eso [CMMI] algo que convertirá el desarrollo en ingeniería?

No. CMMI es un marco de mejora de procesos que proporciona orientación a las organizaciones sobre qué tipos de actividades son útiles al crear software. Las disciplinas de ingeniería suelen tener un proceso de ingeniería. Tener dicho proceso es importante para la finalización exitosa de proyectos de alta calidad. Dicho esto, el CMMI (o cualquier otro marco o metodología de proceso) es solo una herramienta única: usarlo no te hará avanzar mágicamente de un desarrollador a un ingeniero. Sin embargo, no seguir algún tipo de proceso es, en mi opinión, una señal de un proyecto que no es un proyecto de ingeniería.

Además, ¿cuál es su opinión sobre los cursos / certificados de ingeniería de software?

Solo tiene el mismo valor que otras personas le dan. Hay cursos útiles y hay cursos inútiles. Hay certificados valiosos y certificados que no valen el papel en el que están impresos. Hay muchos factores, desde quién respalda o acredita el curso o quién emite el certificado a su industria actual de empleo hasta su trabajo actual y hacia dónde desea ir.

Procedente de un entorno de ingeniería típico, pero haciendo carrera en el desarrollo de software, veo grandes similitudes entre ambos mundos. Aparte de la definición exacta de ingeniería, veo en la práctica que el desarrollo de software no es tan diferente del desarrollo de un producto físico. Al menos creo que no debería ser muy diferente.

Ya sea que diseñe un avión o una aplicación de software, para ambos debe:

• hacer diseños
• definir subsistemas y componentes
• hacer prototipos
• especificar y ejecutar pruebas
• etc.

Leí en otra parte en otra respuesta que el diseño de software es diferente porque no diseñas todo antes de comenzar a programar. Bueno, en realidad, en menor medida, ese es también el caso cuando diseñas un producto físico. Diseñar, crear prototipos y probar es un proceso iterativo.

Además, cuando los proyectos de software crecen en tamaño, se vuelve más importante definir subsistemas, componentes e interfaces claros, lo que también es similar al diseño de productos complejos como un avión.

Por eso considero que desarrollar software es ingeniería.

Yo diría que efectivamente existe la ingeniería de software.

La ingeniería implica la aplicación sistemática del conocimiento científico a la solución de problemas. La complejidad de los problemas que se abordan hoy en día no son tan diferentes de los que aborda un ingeniero eléctrico al crear un circuito o un ingeniero químico al diseñar un proceso de fabricación o un ingeniero mecánico en la creación de un dispositivo.

El hecho de que también exista un enfoque práctico para aplicar los planes existentes (desarrollo en este caso) es simplemente similar al hecho de que en otros campos alguien más ejecuta esos planes (por ejemplo, el trabajador de la construcción).

Es cierto que la mayoría de los desarrolladores también llevan a cabo tareas de ingeniería de software, y que nuestra educación a menudo no es en programación sino más bien en ingeniería de software. Entonces nos ensuciamos las manos mientras que un ingeniero civil no lo haría.

Sin embargo, la capacidad de aplicar un lenguaje y un programa de programación no convierte a uno en un ingeniero: he conocido a muchos desarrolladores que carecen de una verdadera comprensión de las complejidades y problemas fuera de su código actual.

En cuanto a su pregunta con respecto a CMU: la aplicación de un estándar o práctica (por ejemplo, CMMI) no convierte automáticamente el trabajo de una persona en ingeniería. Sin embargo, el hecho de que existan organizaciones que realicen investigaciones científicas para proporcionar nuevas prácticas es nuevamente una señal de que existe algo como la ingeniería.

No, no es ingeniería. No somos tan científicos y no tenemos que pasar ninguna de esas pruebas de ingeniería estatales. De hecho, es ilegal llamarse a sí mismo un "ingeniero" de software en algunos lugares debido a la falta de pruebas.

En mi humilde opinión, el término "ingeniería de software" se acuñó para tratar de describir mejor la gama de cosas que hace un desarrollador, en lugar de ser simplemente un "programador" (que tiene connotaciones de algún proceso mecanicista con poco pensamiento o creatividad).

Personalmente, prefiero la analogía emergente de un desarrollador como 'artesano', defendido por los programadores pragmáticos, entre otros.

Históricamente, las personas han tratado de analogizar la creación de software con la fabricación. Creo que Jack Reeves hizo un argumento bastante bueno para desacreditar esta idea en su artículo What Is Software Design .

De Wiki:

Ingenieria :

La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques; es decir, la aplicación de la ingeniería al software.

Desarrollo de software

El desarrollo de software es el conjunto de actividades que dan como resultado productos de software. El desarrollo de software puede incluir investigación, nuevo desarrollo, modificación, reutilización, reingeniería, mantenimiento o cualquier otra actividad que resulte en productos de software. [1]

Especialmente la primera fase del proceso de desarrollo de software puede involucrar a muchos departamentos, incluidos marketing, ingeniería, investigación y desarrollo y gestión general.

Por lo tanto, son bastante similares y también pueden significar lo mismo.

De Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

–Nuncia 1. el arte o la ciencia de hacer una aplicación práctica del conocimiento de las ciencias puras, como la física o la química, como en la construcción de motores, puentes, edificios, minas, barcos y plantas químicas.

Diría que la creación de software es la aplicación práctica de las matemáticas y la informática, y potencialmente de cualquier otro número de ciencias puras dependiendo de la aplicación.

[EDITAR] FWIW, no me llamo ingeniero de software, sino desarrollador de software, así que no tengo un interés personal en esto.

En mi opinión, un ingeniero de software y un desarrollador de software son dos cosas diferentes.

Veo a un ingeniero de software como alguien que planifica, como qué ciclo de vida tomará el desarrollo, cumplir con los requisitos / especificaciones, etc. Básicamente, un ingeniero de software maneja mucha documentación. Esto puede ser realizado por un desarrollador de software y / o gerente de proyecto.

Un desarrollador de software estaría más relacionado con un programador pero con más habilidades en otras áreas como la gestión de bases de datos, etc.

Una cosa interesante para mencionar es la arquitectura . Alguien que también está involucrado en averiguar qué hardware / software se necesitará para el ciclo de vida del proyecto.

Voy a ir con "No" aquí. Mi hermano es ingeniero mecánico y describe la ingeniería como "El arte de ser barato":

"Los ingenieros están más preocupados por hacer las cosas lo más rápido posible, al menor costo posible, con la menor cantidad de materiales posible " .

Como reacción, he llegado a describir el desarrollo de software (no la ingeniería de software; en realidad son fundamentalmente dos campos distintos) como "El arte de ser eficiente":

"Los desarrolladores están más preocupados por hacer las cosas lo más rápido posible, al menor costo posible, con la menor cantidad de repetición posible " .

La diferencia está en la última parte de esas oraciones.

¿Es la ingeniería de desarrollo de software?

No. Ser ingeniero significa que su proyecto sigue una línea de tiempo de causa y efecto: usted sigue los códigos de construcción, por lo tanto, su edificio no se cae (o al menos no se le puede culpar si lo hace). Al escribir software, puede seguir todas las pautas (¡y hay tantas diferentes para elegir!) Y aún podría bloquearse / bloquearse / dar respuestas incorrectas (a menos que esté involucrado en el campo notablemente pequeño de escribir programas demostrables en paralelo -efectivos lenguajes funcionales).

Veo a un ingeniero (mecánico, estructural, software) como alguien que diseña el producto de acuerdo con las necesidades entendidas y la comprensión de qué y cómo aplicar los materiales para satisfacer esa necesidad.

Por ejemplo, a menudo puede ver a un ingeniero estructural buscando diferentes resistencias de acero y aplicando reglas de física para calcular los materiales requeridos y cómo deben implementarse. La ingeniería estructural es un excelente ejemplo porque siempre terminas con un anteproyecto (especificación) de lo que vas a construir antes de construir. Eso no siempre sucede con el software.

Para mí, la diferencia entre un ingeniero de software y un programador es que el ingeniero es capaz de construir la especificación de lo que se producirá antes de escribir cualquier código, donde un programador simplemente escribe el código basado en las especificaciones de otra persona, o es uno de esos programadores del salvaje oeste que escriben código sin especificaciones. Además, el ingeniero tiene su título.

Comparo la diferencia entre un trabajador de la construcción y un ingeniero estructural con la diferencia entre un programador y un ingeniero de software.

Para aclarar, solo tengo un diploma universitario, así que no puedo llamarme ingeniero.

No consideraría el término "ingeniería" como el más apropiado para describir el desarrollo de software, por 2 razones principales:

• Transmite muchas ideas, conceptos y las llamadas "reglas de oro" originadas en disciplinas de ingeniería tradicionales como la ingeniería industrial, civil, naval o mecánica. Estoy hablando de reglas en la división laboral, procesos de producción, estándares de calidad ... Estos a menudo solo se aplican marginalmente al software.

• No describe de manera satisfactoria qué programación tiene más que otras disciplinas (y creo que tiene muchas más y muchas diferencias), y qué nuevos desafíos tienen que enfrentar los desarrolladores en el día a día en comparación con sus contrapartes tradicionales. dominios de ingeniería. La naturaleza virtual e inmaterial del software juega un papel muy importante en eso.

El desarrollo de software ha sido visto durante mucho tiempo como "simplemente otra disciplina de ingeniería". Teniendo en cuenta las tasas de fracaso de los proyectos de software que hemos conocido desde que se midieron, es hora de que reconozcamos el desarrollo como un animal completamente nuevo, el código como un material realmente especial y el ciclo de vida de la aplicación como un tipo de ciclo de producción totalmente diferente, y dejemos de intentarlo desesperadamente para aplicarles recetas antiguas.

Sí, uno debería poder aplicar estándares y principios para llegar a un producto decente. Lo que lo hace difícil es la mentalidad del cliente (es solo código, no debería costar tanto cambiar), la extrema dificultad para codificar lo que el producto debe hacer en código máquina (lenguaje hablado / escrito para codificar) y cuantificar " calidad". Tu definición de calidad no es mía.

También es repetibilidad. Tome un conjunto de requisitos y déselo a dos equipos. Cuando puedes sacar lo mismo (sin que los equipos hablen entre sí) estás muy cerca de la ingeniería.

Otras áreas de ingeniería también tienen penalidades y una revisión rígida y aprobación. Responsabilidad.

No. La ingeniería de software no es ingeniería. En mi opinión, la diferencia está en la cantidad de creatividad involucrada. En Ingeniería Civil, por ejemplo, puede haber muy poca o ninguna creatividad. Ésto es una cosa buena.

Para construir un puente, tienes un conjunto de especificaciones (necesito obtener este número de autos de este lado del río al otro lado).

De esto, puedo deducir:

1. la cantidad de carriles de carretera que necesito (usando un cálculo estándar definido por el gobierno);
2. las cargas que tendré que soportar (usando cálculos definidos por el gobierno)
3. los materiales que necesito usar para soportar esas cargas (usando materiales estándar, que puedo obtener de varios proveedores diferentes, o materiales no estándar, que luego tengo que demostrar que tendrán las propiedades correctas).

Luego, debo hacer que un tercero (otra compañía) apruebe y compruebe el diseño para asegurarme de que he realizado mis cálculos correctamente.

Luego, cuando el puente esté realmente construido, el trabajo será realizado por personas calificadas de manera estándar. Harán un trabajo que han hecho cientos, quizás miles de veces antes.

No me malinterpreten, cada proyecto de ingeniería civil es diferente, pero parece que cada vez que desarrollo una nueva aplicación / sitio web, las cosas se hacen de manera diferente.

Sí, supongo que el desarrollo es un subconjunto de la ingeniería:

• La ingeniería de software incluye la especificación inicial ("¿qué tipo de software necesitamos aquí?"), Que posiblemente precede al desarrollo
• La "ingeniería" también podría incluir, por ejemplo, la definición del proceso de garantía de calidad, que ciertamente está relacionado con el desarrollo, pero también podría decirse que está fuera del alcance de la "construcción" en sí.

Code Complete define "construcción" como sinónimo de codificación y depuración (y comentarios), también con un diseño detallado de antemano y luego con pruebas de unidad e integración. El Capítulo 1, Bienvenido a Software Construction (PDF) comienza enumerando muchos temas en el Ciclo de vida general de desarrollo de software (incluida la Definición de problemas, Arquitectura de software, Mantenimiento correctivo, etc.), y luego dice:

Como lo indica la figura, la construcción es principalmente codificación y depuración, pero también implica diseño detallado, planificación de la construcción, pruebas unitarias, integración, pruebas de integración y otras actividades. Si se tratara de un libro sobre todos los aspectos del desarrollo de software, presentaría discusiones bien equilibradas de todas las actividades en el proceso de desarrollo. Sin embargo, debido a que este es un manual de técnicas de construcción, pone un énfasis desigual en la construcción y solo toca temas relacionados. Si este libro fuera un perro, se acercaría a la construcción, movería la cola en el diseño y las pruebas, y ladraría en las otras actividades de desarrollo.

El desarrollo de software es ingeniería.

Algunos argumentos presentados por otros sobre por qué la ingeniería de software no cumple con el estándar de ingeniero:

Algunos dicen que los ingenieros están en el negocio de diseñar "cosas" para el bien público: ¿los ICBM, los tanques, etc. están en el bien público? Algunos dirían que sí (una buena ofensiva es una buena defensa) otros dirían que no. Sin embargo, no creo que nadie esté en desacuerdo con que el tipo que diseña el sistema de orientación de tanques de próxima generación es un ingeniero. El bien público puede ser subjetivo. En cualquier caso, un montón de software está en el bien público, por lo que el punto es discutible de cualquier manera.

Otros dicen que los ingenieros diseñan que no construyen. He visto varios comentarios tipo "ingenieros mecánicos no sueldan". Yo diría que los ingenieros mecánicos producen planos, diseños detallados que algo implementa más. Si un ingeniero mecánico produce un plan y lo alimenta a una máquina CNC, ¿eso hace que ya no sea un ingeniero mecánico, porque una máquina realizó la implementación en lugar de una persona? Yo diría que el código fuente es un plan detallado que se alimenta a una máquina que realiza la implementación y no veo cómo eso es diferente de un código de alimentación MechE a una máquina CNC. Y ahora tenemos impresoras 3d, ¿eso significa el final de los ingenieros mecánicos? ¿Son ahora desarrolladores mecánicos?

La licencia es el otro tema que veo surgir. Actualmente solo unas pocas jurisdicciones licencian ingenieros de software. No existe (hasta ahora) ninguna licencia de ingenieros de software en todo Estados Unidos (creo que solo Texas lo hace). Algunos han usado esto como una razón para afirmar que la ingeniería de software no debería llamarse ingeniería. La educación física para ingenieros de software está llegando. Pero en un nivel más filosófico solo porque algunos legisladores estatales eligen (o no) llamar a la ingeniería de desarrollo de software no tiene ningún efecto en la realidad.