Se estima que hay más de 11 millones de desarrolladores de software profesionales en todo el mundo a partir de 2014. Cuando comencé como programador en 1973, uno de los galgos de la primera compañía para la que trabajé me dio algunos consejos. Él dijo: “Aprende las cosas que nunca cambian”.

Cuando comencé la universidad seis años antes, en 1967, la escuela a la que asistía no tenía una especialización llamada Ciencias de la Computación, por lo que hice mi trabajo de pregrado y posgrado en Matemáticas tomando algunos cursos de programación de computadoras en el camino. Esta fue la forma en que muchos de nosotros comenzamos como desarrolladores de software en los años 70.

El término Ingeniería de Software era nuevo en ese momento, acuñado en la Conferencia de Ingeniería de Software de la OTAN de 1968. El pensamiento en ese entonces era que necesitábamos aplicar los métodos de ingeniería existentes al desarrollo de software para abordar problemas comunes de presupuesto, cronograma y calidad que se referían en ese momento como la “crisis del software”. Como resultado, lo que la mayoría de la gente ha pensado en Ingeniería de software implica actividades que se parecen mucho a otras disciplinas de ingeniería, incluida la ingeniería civil, mecánica y eléctrica.

En la superficie, esta idea parece tener sentido. Cuando construye algo utilizando las otras disciplinas de ingeniería (por ejemplo, un puente, un edificio, una pieza de hardware especializada, una placa de circuito eléctrico), necesita averiguar los requisitos, diseñar una solución, implementarla y probarla. Todos estos pasos también tienen sentido para el software. Por lo tanto, uno podría argumentar desde esta perspectiva que la ingeniería de software debería parecerse a estas otras disciplinas de ingeniería. Sin embargo, cuando observa más de cerca lo que hemos aprendido sobre el desarrollo de software en los últimos cuarenta años, así como también cómo lo enseñamos a los desarrolladores de software actuales, esta analogía se rompe rápidamente.

Para cuando llegó la década de 1990, debido a que la programación informática se había convertido en una parte tan importante de lo que se llamaba informática, muchas universidades habían agregado un curso con un título de “Ingeniería de software” a su plan de estudios de informática. Los libros de texto populares que se usaron en ese momento para enseñar estos cursos incluyeron el libro de texto de Ian Sommerville titulado: “Ingeniería de software”. De 1992 a 1994 utilicé la Cuarta Edición de este libro de texto para enseñar Ingeniería de Software en la Universidad de Binghamton. Hoy, el libro de texto de Ian Sommerville todavía está en uso en muchas universidades de todo el mundo, ahora en su Novena Edición. Esto lleva a una pregunta:

¿Por qué necesitamos revisar un libro de texto aproximadamente cada 3-4 años que supuestamente está enseñando a nuestros estudiantes los fundamentos de la Ingeniería del Software?

Si observa los libros de texto utilizados en Ingeniería Civil, Ingeniería Mecánica e Ingeniería Eléctrica, la gran mayoría de estos libros no requieren revisiones con tanta frecuencia. Para entender por qué este es el caso, debemos analizar más de cerca lo que se enseña en la mayoría de las universidades de todo el mundo bajo el nombre de “Ingeniería de software”.

Cuando mire más de cerca, encontrará que estamos enseñando a nuestra próxima generación de profesionales del software lo que sea actualmente popular en términos de prácticas y métodos de software. Las prácticas y métodos de software populares hoy en día son conocidos por palabras de moda como Agile, Casos de uso, Historias de usuarios, RUP, XP, Scrum Lean, PSP, TSP y la lista sigue y sigue …

El problema con este enfoque para enseñar Ingeniería de Software es que las prácticas y métodos de software con frecuencia van y vienen y seguirán yendo y viniendo, por lo que Sommerville debe actualizar continuamente su libro de texto. Esto lleva a otra pregunta:

¿Qué hay de esa barba gris en la primera compañía para la que trabajé en 1973 que me dijo que aprendiera cosas que nunca cambian? ¿Me dio malos consejos? Si no, ¿qué estamos enseñando a nuestra próxima generación de profesionales del software con respecto a las cosas que nunca cambian sobre la Ingeniería del Software?

Antes de contestar estas preguntas, primero retrocedamos y hagamos algunas preguntas diferentes:

¿Existe realmente un conjunto de cosas que nunca cambian en Ingeniería de Software?

Si existen, ¿sabemos qué son?

Si sabemos cuáles son, ¿les estamos enseñando de manera consistente a nuestra próxima generación de profesionales del software para que cuando salgan de la Universidad estén preparados para comportarse como profesionales del software?

Tal conjunto de elementos esenciales de ingeniería de software existe de hecho. Esta creencia ha motivado a un grupo internacional de voluntarios a asumir la tarea de codificar esos elementos esenciales. La intención es que estos elementos esenciales se enseñen a nuestra próxima generación de desarrolladores de software que ayudan a prepararlos como verdaderos profesionales del software.

Los voluntarios involucrados en esta iniciativa (conocida como SEMAT – Método y teoría de ingeniería de software) han estado trabajando en esta tarea desde 2010. El año pasado, SEMAT logró un hito importante con el anuncio del Object Management Group, un consorcio internacional de estándares, que han adoptado “Essence” como estándar oficial de OMG.

Entonces esto lleva a algunas preguntas más:

¿Cuán diferente es el estándar Essence de lo que se enseña a nuestros desarrolladores de software hoy en día, y se ha enseñado durante los últimos 40 años bajo el nombre de Ingeniería de Software?

Y:

¿Las diferencias realmente ayudarán con los problemas que muchos creen que todavía afectan a la industria del software con respecto al presupuesto común, y programan excesos y mala calidad del software?

Desde una perspectiva, lo que Essence captura no es nuevo. El estándar Essence incluye palabras comunes como: partes interesadas, oportunidad, requisitos, sistema de software, equipo, trabajo y forma de trabajar. Pero desde otra perspectiva, lo que captura Essence es dramáticamente nuevo. De hecho, algunos lo llaman un “cambio de paradigma” que muchos de la “vieja guardia” tendrán grandes dificultades incluso para comprender.

Para darle una idea de los cambios involucrados al usar Essence, vuelvo a pensar en mis primeros días como programador a fines de la década de 1970. En esos días trabajé en el dominio de simulación de vuelo desarrollando sistemas de software para entrenar a pilotos para volar aviones de alto rendimiento. Una de mis áreas de especialización fue escribir software para proporcionar capacidades de grabación / reproducción para ayudar a los instructores a entrenar a pilotos de aeronaves jóvenes en habilidades de vuelo.

Recuerdo un proyecto específico en el que trabajé y un instructor piloto de clientes con el que trabajé. Después de explicarle cómo podía usar mi software de grabación / reproducción para ayudarlo a demostrar a sus estudiantes pilotos dónde habían cometido errores, con entusiasmo escribió una serie de defectos solicitando cambios en mi software.

Discutí con vehemencia con mi gerente de programa que ninguno de estos problemas eran realmente defectos. Debido a que me había tomado el tiempo para explicar lo que era posible con mi software de grabación / reproducción, el instructor piloto comenzó a imaginar características adicionales que podrían facilitar su trabajo. Escribió sus ideas en un formulario de defectos a pesar de que todas eran capacidades mejoradas que nunca planeamos entregar y que no formaban parte de los requisitos.

Pero mi gerente de proyecto no quería discutir con el cliente si estas solicitudes estaban dentro o fuera del alcance o no. Su punto de vista era, como muchos vieron el software entonces y todavía lo ven hoy, que es más fácil cambiar el software que involucrar al cliente en una discusión.

Debido a que el software es suave, tendemos a verlo como fácil de cambiar. No es como el hardware. El metal no se dobla fácilmente. Esta perspectiva cambia todo el juego cuando se trata de software.

Esta capacidad de cambiar el código de software de forma rápida e infinita cambia por completo la dinámica que existe entre los desarrolladores de software y sus partes interesadas, incluidos los gerentes de programas y los clientes. Una forma en que esta diferencia se ejemplifica es que a medida que los usuarios se familiarizan con el software, a menudo ven nuevas formas en que los cambios en el software podrían facilitar su trabajo como lo hizo mi cliente instructor piloto a fines de la década de 1970.

Ahora sabemos por experiencia que existen otras dimensiones para la Ingeniería de Software que son críticas para las prácticas profesionales efectivas de ingeniería de software. Estas otras dimensiones nos llevan más allá de la facilidad con la que se puede cambiar el código. Hasta la fecha, estas dimensiones adicionales no han recibido la atención que merecen.

Cuando cambia el código, también puede estar afectando los requisitos, y también puede estar afectando otras capacidades en el sistema de software probado previamente. Cambiar el código significa trabajo adicional, pruebas adicionales, posiblemente cambios en los manuales de soporte del usuario, etc. Todo esto afecta el presupuesto y el cronograma, e introduce un riesgo adicional para la calidad del software.

Si bien, por un lado, la capacidad de cambiar rápidamente el código del software aporta un gran poder a la industria del software, también significa que los profesionales del software deben estar cada vez más en sintonía con su forma de trabajo acordada, el impacto y el tiempo que lleva realizar el trabajo adicional y el riesgo al realizar cambios rápidos no planificados. El movimiento ágil en los últimos diez años ha brindado un gran servicio para ayudar a la comunidad del software a comprender esta gran diferencia relacionada con la Ingeniería del Software, incluida la importancia de la interacción temprana y continua con las partes interesadas y la importancia de que los desarrolladores de software estimen el costo de su propio trabajo.

Si bien la comunidad de ingeniería de software ha aprendido mucho de las otras disciplinas de ingeniería, también ha aprendido la importancia crítica de estas otras dimensiones que traen diferencias con respecto a las experiencias de ingeniería anteriores. Estas diferencias significan que los desarrolladores de software deben recibir capacitación en formas nuevas y diferentes para ser profesionales de software efectivos.

Poco después del inicio de la iniciativa SEMAT en marzo de 2010, uno de los signatarios iniciales de SEMAT me envió un borrador de un libro en el que estaba trabajando para su revisión. Watts Humphrey, que había planeado ser muy activo en el trabajo inicial de SEMAT, se enfermó justo cuando el trabajo de SEMAT se estaba preparando y me pidieron que lo ayudara a poner en marcha su esfuerzo planificado. A fines de agosto de ese mismo año, Watts me envió el siguiente correo electrónico solo unos meses antes de su fallecimiento. Estuvo de acuerdo en que podría compartir este correo electrónico con otros:

Paul: Según tus comentarios, parece que entendiste el punto de mi libro, por lo que estoy agradecido … la respuesta correcta y la que más me interesó seguir con SEMAT, se refiere a cómo podemos asegurarnos de que los profesionales de software están debidamente capacitados y tienen un conjunto adecuado de actitudes y habilidades profesionales incluso antes de llegar a la industria. Espero que el esfuerzo de SEMAT eventualmente pueda encabezar el impulso para lograr que la comunidad académica reenfoque sus programas en la enseñanza de profesionales de software para que actúen como profesionales y se administren a sí mismos.

Cuando lo hagan, sus graduados podrán negociar con su gerencia y realizar un trabajo superior … Eso es lo que deberían hacer los profesionales … Un buen comienzo en esta dirección sería convencerlos de la necesidad de contar con personal de software. medir su propio trabajo. Como el trabajo de software es, como dijimos, trabajo de conocimiento, los profesionales del software deben tomar cualquier medida verdaderamente precisa. … Watts Humphrey

Watts Humphrey ha sido referido como el padre de la calidad del software. Después de completar una distinguida carrera en IBM, se convirtió en miembro del Software Engineering Institute y fundó el Software Process Program. En 2003 fue galardonado con la Medalla Nacional de Tecnología.

Hoy Watts se habría animado por el trabajo de SEMAT que se está llevando a cabo en la comunidad académica. El primer curso universitario completo basado en el nuevo estándar de Essence se ha desarrollado y este año se está impartiendo a los estudiantes por el Dr. Carlos Zapata en la Universidad Nacional de Columbia en Medellín, Columbia, y Se está utilizando Essence en primer y segundo año. cursos de ingeniería de software en KTH Royal Institute of Technology en Suecia bajo la guía de la Dra. Mira Kajko-Mattson. También ha habido estudios de campo de Essence realizados con estudiantes por la Dra. Cecile Peraire en Carnegie-Mellon West en los Estados Unidos. El siguiente paso para la comunidad SEMAT es demostrar cómo Essence puede ayudar en la industria mediante la publicación de estudios de casos de uso real y resultados medidos en proyectos industriales.