El actual ingeniero de software

Rubby Casallas
Jorge A. Villalobos

Una visión basada en los permanentes cambios tecnológicos y otros aspectos relacionados.

De un ingeniero que conocía un modelo de ciclo de vida del software, que manejaba una tecnología y que era capaz de construir una
aplicación para resolver un problema, hemos pasado a un ingeniero que debe poder integrarse en grandes equipos de desarrollo, que debe
tener una visión amplia de las tecnologías disponibles, que debe ser capaz de comunicarse de manera eficaz con los clientes y que debe
entender el medio empresarial en el que ocurren los problemas que va a ayudar a resolver. De un ingeniero monofacético hemos pasado a
un profesional multifacético, que necesita una alta capacidad de adaptación y autoaprendizaje.

1. ¿Qué es Ingeniería de Software?

Según la ACM, la ingeniería de software es la disciplina del desarrollo y mantenimiento de sistemas computacionales que se
comportan de manera confiable y eficiente y que su costo de desarrollo y mantenimiento puede ser pagado [1]. Esta definición
incluye al menos dos aspectos importantes para resaltar. Por un lado, la noción de calidad de lo que se produce y, por otro, las
restricciones bajo las cuales el trabajo debe ser realizado (costos). Sin embargo, esta definición se queda un poco corta para que
de ahí se pueda entender la complejidad de lo que significa la tarea de construir y mantener software y, menos aún, para poder
concluir el cuerpo de conocimientos y de generación de habilidades que un ingeniero de software debe recibir en su formación
para ser capaz de desarrollar y mantener los sistemas de los que habla la ACM.

2. Hay tres puntos en los que vale la pena hacer énfasis antes de presentar una definición más precisa. El primero es que ingeniería
de software no se reduce a la labor de escribir un programa de computador. La programación es sólo una pequeña parte de la
ingeniería de software. El segundo punto es que es una profesión enmarcada dentro de la ingeniería, entendida como la
integración de distintos componentes para la solución efectiva de problemas utilizando, en nuestro caso, tecnologías de
información. El tercer punto es que la ingeniería de software debe ver la tecnología más como un medio que como un fin en sí
mismo.

3. Nosotros hemos desarrollado una definición de ingeniería de software basada en la descomposición conceptual de la profesión en
cuatro grandes ejes. Esto ejes son: (1) procesos de software y aseguramiento de la calidad, (2) arquitecturas de software y
elementos estructuradores, (3) metodologías y técnicas de desarrollo, (4) tecnologías de información. Todos estos ejes soportados
por herramientas. Para que un ingeniero de software pueda construir aplicaciones confiables, mantenibles, eficientes y bajo las
restricciones de costos y recursos impuestas por una situación particular, debe entender, poder aplicar e integrar los
conocimientos y habilidades necesarios de cada uno de los ejes que conforman la disciplina. Debe ser claro que entre estos ejes
existen dependencias y relaciones profundas, y que las decisiones que se tomen en cualquiera de ellos tienen repercusiones
sobre los demás.
4. A continuación vamos a describir cada uno de los ejes. El propósito es entender a partir de esta descripción, tanto el ámbito de
acción de un ingeniero de software de hoy como los retos a los que se enfrenta.

5. Procesos de software y aseguramiento de calidad

Los procesos de software comprenden el conjunto de actividades, tanto técnicas como administrativas, que son necesarias para la
fabricación de un sistema de software. Estas actividades van desde el análisis de requisitos hasta la evolución o el mantenimiento
del software, pasando por la implantación, la administración de configuraciones, el aseguramiento de la calidad, las pruebas, etc.
Tener un proceso adecuado significa, primero, que está definido y, segundo, que sirve para lo que se especificó, es decir que se
puede verificar que los objetivos para los que fue definido se satisfacen. Definir un proceso de software implica precisar los
objetivos, las personas (roles) involucrados, las entradas y salidas del proceso, los criterios de entrada y salida, las actividades, los
métodos y las herramientas que se utilizarán, la manera como se medirán elementos dentro del proceso que permitan verificar
resultados, etc.

6. El área de procesos de software ha madurado mucho en los últimos años. Lo que ha impulsado estos cambios es la necesidad de
los clientes de contar con algún tipo de modelo, que les permita evaluar la capacidad de las empresas de desarrollo de software
para realizar con éxito un proyecto y producir productos de calidad. La hipótesis básica es que si el proceso es adecuado, la
probabilidad de producir un producto de buena calidad es más alta. Sobre esta hipótesis han sido definidas normas internacionales
como la ISO 9001 [2] y modelos específicos para software como CMMI [3], SPICE [4], etc.

7. Un campo de acción claro del ingeniero de software es el de contribuir en las organizaciones a mejorar la gestión de los proyectos,
y en particular los procesos de construcción de soluciones. Esta iniciativa de las empresas puede estar motivada por la
consecución de un certificado estilo ISO 9001 o algún nivel de CMM, pero sobre todo, estar motivada por la necesidad de
organizar la forma de trabajar para que sea más eficiente, se mejore la productividad y la calidad de lo que se produce.

8. Arquitecturas de software
A partir de la selección de los elementos que van a definir la estructura de una aplicación, hay que definir el proceso de
construcción, la metodología, la tecnología y las herramientas. Se consideran elementos estructuradores las funciones, los objetos,
los componentes, los contenedores, los servicios, los modelos, etc. Cuando los elementos no funcionales tienen gran importancia
dentro de la aplicación, o cuando el tamaño del programa impide que sea posible manejar toda la información en términos de los
elementos estructuradores, es necesario cambiar de nivel de abstracción e introducir otros lenguajes y modelos más abstractos.

9. En los 60s y 70s era natural estructurar una aplicación en términos de los servicios funcionales que ésta debía proveer. De hecho,
las metodologías como el análisis y diseño estructurado partían de una descomposición funcional jerárquica que luego se
transformaba en procedimientos dentro de la aplicación. Con el aumento de la complejidad de las aplicaciones y la necesidad de
 hacerlas evolucionar, este enfoque no fue suficiente. En los 80s y 90s se popularizó el desarrollo de software orientado-objetos
que buscaba, entre otros objetivos, permitir la construcción de aplicaciones más mantenibles.

10. Hoy parecen no ser suficiente los objetos, no porque hayan dejado de ser buenos, sino porque el problema ha cambiado. Estos
cambios son consecuencia de los avances tecnológicos y el incremento de las expectativas de los clientes. Por ejemplo, las
características no funcionales se han vuelto más críticas y el problema de la integración de aplicaciones ha llegado a ser prioritario.
Se necesita contar con arquitecturas flexibles y lo más independientes posibles de las herramientas que se utilicen.

11. El papel del diseñador y arquitecto de software se ha vuelto crucial en las empresas. Este arquitecto debe ser capaz de tomar las
decisiones adecuadas en cuanto a la manera como se estructurará una solución que incluya sistemas legados, sistemas propios,
sistemas adaptados, etc. y que cumpla con restricciones de funcionamiento precisas en cuanto a seguridad, escalabilidad,
tolerancia a fallos, etc. Además, su decisión tiene que incluir la manera de organizar el equipo de desarrollo para producir el
software de una forma eficiente dentro de los plazos y costos previstos.

12. Tecnologías de información

En el eje de las tecnologías hacemos referencia tanto a elementos de hardware que afectan los sistemas de software como a los
lenguajes concretos de modelaje y de programación, y a las plataformas para la construcción de algún tipo de componente de
software. Esta es la dimensión de la ingeniería de software que más rápido cambia. En los últimos 50 años, hemos visto cambiar
la visión de las empresas hacia las tecnologías de información, desde aplicaciones en batch de apoyo a procesos puntuales de
sus negocios hasta las aplicaciones de la empresa abierta, enfocadas a apoyar a sus clientes y sus asociados.

13. Es la evolución de la tecnología lo que ha hecho que las expectativas con respecto al software cambien y sean más exigentes. Los
grandes hitos tecnológicos como la aparición de los computadores personales y más recientemente, Internet y las tecnologías
móviles, han hecho que el software se convierta en algo ha permeado todas las actividades. En una época se pensaba que las
decisiones sobre la tecnología se tomaban en las últimas etapas del ciclo de vida de una aplicación, pero a medida que los
requerimientos no funcionales han ido tomando importancia, la integración de la tecnología se debe hacer desde las primeras
etapas de diseño, y obliga al ingeniero de software a ampliar su dominio de competencias. Ya no se puede esperar hasta que el
experto en persistencia o distribución llegue a “agregar” su parte al programa, sino que el ingeniero de software debe manejar un
modelo claro de las tecnologías, para poder tomar las decisiones adecuadas e integrarla con el resto de elementos del programa.

14. El aprender una tecnología específica se ha vuelto tan complicado que los proveedores de las mismas han optado por impartir
certificados sobre el conocimiento y uso de las mismas. Esta explosión de certificados no-formales, ha contribuido a la confusión
sobre lo que es el ingeniero de software hoy. Si bien es cierto que un ingeniero de software debe tener conocimientos sobre las
tecnologías de punta, pretender remplazar la formación formal por cursos de certificación es un error. Las certificaciones en
tecnologías particulares tienen una vida útil corta.

15. Metodologías y técnicas

Dentro del marco global de un proceso de desarrollo, las metodologías y técnicas dan soporte a las actividades de análisis, diseño,
programación, elaboración de pruebas, administración de riesgos, etc. Las metodologías y técnicas precisan el cómo hacer dentro
de las actividades concretas de un proceso. Debe contar con descripciones claras sobre la manera de llevar a cabo el trabajo, de
evaluar el avance, de verificar la calidad del resultado y de validar si se produjo lo que se esperaba.

16. Una buena metodología expresa la experiencia de otros para realizar una tarea: ésta es el fruto de la experiencia. Se requiere
tiempo de utilizarla, evaluarla, mejorarla, volverla a utilizar, adaptarla, etc. El ciclo de aceptación es largo y requiere tiempo. Sin
embargo, la velocidad a la que las tecnologías cambian, no ha permitido que estos ciclos se completen adecuadamente. Esto
explica por qué ha habido tan pocos avances metodológicos en el área de construcción de software o por qué este eje va más
lentamente.

17. Recientemente, el tema que ha despertado gran interés es el de los patrones de diseño. Estos son soluciones probadas a
problemas particulares en contextos específicos. Si bien no son metodologías completas, son elementos claves que
permiten, por un lado, manejar un vocabulario común entre los diseñadores y, además, ofrecen elementos objetivos para
justificar una decisión.

18. El papel de las universidades

El reto que se plantea a las universidades en la formación de ingenieros de software es muy grande. En particular, porque es
delicado el equilibrio entre todos los aspectos antes mencionados, sobre todo si se tiene en cuenta que se espera que la vida
profesional de un ingeniero supere los 40 años, y que la mayoría de aspectos de la disciplina evolucione rápidamente. Veamos los
principales puntos en los cuales es necesario garantizar un equilibrio:

19. El balance entre lo fundamental y lo tecnológico. Las universidades deben buscar en la formación un equilibrio entre los aspectos
fundamentales (algorítmica, modelaje, especificación) y los aspectos tecnológicos (lenguajes, herramientas específicas). Si la
balanza se inclina por lo fundamental, vamos a formar ingenieros que son incapaces de llevar sus conocimientos a la práctica. Si
la balanza se inclina por lo segundo, estaremos formando ingenieros con una muy limitada vida profesional útil. Lo ideal en este
caso es buscar un punto intermedio, en el cual se logren integrar estos dos aspectos, tratando de trabajar sobre modelos de
tecnología como medio para encadenar lo fundamental con las herramientas específicas que las implementan.

20. El balance entre la teoría y la práctica. Un ingeniero, más que tener un conjunto de conocimientos (leyes, teorías, formulas), debe
contar con las habilidades necesarias para usarlos en la solución de problemas. El reto para las universidades es ir más allá de la
simple enunciación de las definiciones, y generar en el estudiante las habilidades necesarias para poder utilizar de manera efectiva
aquello que sabe. Si la balanza se inclina por la parte teórica, vamos a tener ingenieros poco útiles para las empresas. Si se inclina
 por la parte práctica, vamos a formar ingenieros que no entienden la razón de lo que hacen y que sólo son capaces de repetir
recetas. Estos ingenieros tendrán grandes dificultades para adaptarse a los cambios.

21. El balance entre las necesidades de hoy de las empresas y las necesidades del futuro ingeniero de software. Este es uno de los
puntos de equilibrio más difíciles de lograr, puesto que los intereses de las dos partes están en conflicto. Por una parte están las
empresas, que necesitan mano de obra capacitada, que sea productiva desde el primer día de trabajo. Por otra parte está el
ingeniero de software recién egresado, que tiene una expectativa de vida útil de muchos años y que quiere evitar convertirse en un
producto perecedero para la empresa. ¿Qué evita que una empresa renueve sus ingenieros cada 3 años buscando siempre
profesionales actualizados y más baratos? La única solución es que la experiencia, en lugar de una carga sea una ventaja, y esto
sólo se logra si el ingeniero de software consigue mantenerse siempre actualizado, y sobre todo, integrarse de manera adecuada a
la empresa, entendiendo el negocio y la manera como la tecnología se incorpora en ella, como un medio y no como un fin en sí
mismo. Esto último implica que debe tener bases más sólidas y profundas, y a la vez una visión más amplia de la disciplina. El
balance en este punto consiste en que la universidad debe, por un lado, proveerle a sus egresados herramientas suficientes que
les permitan crecer en su vida profesional, sin olvidar que a la vez debe garantizar que estas personas deben ser útiles a la
sociedad desde el momento en que se gradúan.

22. El balance entre lo general y lo especializado. En su afán por ir incorporando todo lo que va apareciendo en la disciplina, la
mayoría de programas de ingeniería de sistemas ha adoptado la estrategia de sacrificar la profundidad y la generación de
habilidades para evitar dejar por fuera alguno de los temas de moda. En la ingeniería de software, vista como un perfil de la
ingeniería de sistemas, ocurre algo similar. A pesar de la tentación de tratar de abarcar todos los temas con el mismo nivel de
profundidad, es conveniente adoptar una estrategia a varios niveles: en el pregrado debe haber un núcleo sólido en el que se
estudien las bases de todos los ejes, el cual se debe apoyar con una serie de posibles profundizaciones distintas según los
intereses del estudiante (hacia gerencia de proyectos, hacia diseño, hacia tecnología, hacia arquitectura). Esta formación de
pregrado debe estar complementada con programas de especialización, que permitan profundizar en cualquiera de las áreas de
desempeño profesional.

23. El balance entre lo conocido y la necesidad de buscar nuevas ideas. A este último punto se le suele dar poca importancia, por
cuanto se parte de la idea de que lo que se debe enseñar es lo que dicen las multinacionales y las universidades de otros países.
Muchos tienen la idea de que nuestra industria de software va a lograr competir a nivel internacional basándose sólo en los bajos
costos, resultado de los bajos salarios que se pagan en el país (comparados con los salarios que se pagan en los países
desarrollados). Y nada es más falso. Cuando se empiezan a ver empresas colombianas contratando sus desarrollos en la India,
comienza a rondar la inquietud en el gremio. ¿Qué hicimos mal? ¿Qué hacemos ahora? La respuesta es que hay que competir
con calidad, con ideas nuevas y con enfoques nuevos. A lo primero ya hay muchas empresas colombianas apostándole, con
certificaciones internacionales de calidad en sus procesos y con muy buenos resultados para mostrar. Eso hay que seguir
haciéndolo y hay que tratar de extenderlo. Lo segundo es más difícil de lograr, por cuanto las ideas nuevas están muy ligadas a la
investigación y eso está hasta ahora arrancando en el país. Aquí es donde, a pesar del escepticismo de algunos sectores, hay que
trabajar. Las universidades del mundo entero son el semillero de nuevas empresas, basadas en nuevas ideas. Es aquí donde las
universidades con sus programas de master y doctorado deben entrar a trabajar. El país necesita programas de alta calidad y un
amplio conjunto de investigadores con una formación adecuada, que sean capaces de trabajar de la mano con las empresas y
aportar esas nuevas ideas que le pueden dar una ventaja competitiva a nuestra industria.

24. Conclusión
Es claro que así como la complejidad de la construcción y mantenimiento del software ha aumentado en los últimos años, la
complejidad de formar buenos ingenieros de software también. El ingeniero de software hoy se sitúa en el contexto de la empresa
abierta. La empresa que debe contar con sistemas de información que apoyen su negocio y su negocio son sus clientes y sus
asociados. Estos son sistemas heterogéneos, altamente evolutivos y muy exigentes desde el punto de vista no funcional: deben
escalar, ser altamente confiables, disponibles, seguros, manejar grandes volúmenes de datos y de transacciones, etc.

25. El ingeniero de software hoy debe tener dentro de sus herramientas conocimientos y habilidades de los cuatro ejes de la ingeniería
de software: procesos, arquitectura, metodología y tecnologías. Debe ser capaz de encontrar un equilibrio entre ellos y poder
aplicarlo en el momento de tomar una decisión en una organización. El arquitecto de software que sólo maneje la tecnología de
moda no podrá tener una visión completa de las consecuencias de sus decisiones. El director de proyecto que no maneje ninguna
de las tecnologías de moda tampoco podrá juzgar adecuadamente las decisiones de los arquitectos.

26. Las universidades se deben preocupar por la preparación de sus estudiantes para el manejo del cambio. Inculcar esta necesidad
constante de actualización y mejoramiento individual. La educación formal debe preocuparse por impartir una base de
conocimientos fundamentales y preocuparse más por facilitar la generación de habilidades en los estudiantes que les permita
aprender a moverse en las tecnologías cambiantes y en las empresas de hoy.
Referencias
[1] Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering. A Volume of the Computing Curricula Series. ACM y IEEEComputer Society. 2004
[2] Norma ISO 9001:2000. Sistemas de Gestión de la Calidad. ISO Organisation.
[3] CMMI-SE/SW/IPPD/SS Versión 1.1. Reporte técnico. Software Engineering Institute. Carnegie Mellon University.http://www.sei.cmu.edu/cmmi (Última consulta, septiembre 5 de 2005).
[4] SPICE. Software Process Improvement and Capability dEtermination. www.sqi.gu.edu.au/spice/ (Última consulta, septiembre 5 de 2005)

Rubby Casallas. PhD. en Ingeniería de Software, Universidad Joseph Fourier (Francia), Especialista en Sistemas de Información en la Organización. Universidad de los Andes, Ingeniera de Sistemas y
Computación, Universidad de los Andes. Coordinadora de la Especialización en Construcción de Software y Profesora Asociada de la Universidad de los Andes.
Jorge Villalobos. PhD. en Ingeniería de Software, Universidad Joseph Fourier (Francia), Master en Informática, Instituto Nacional Politécnico d e Grenoble (Francia), Ingeniero de Sistemas y Computación,
Universidad de los Andes, Postdoctorado en el LSR del IMAG (Francia) 2003-2004, Investigador visitante Universidad Politécnica de Cataluña (España) 1989-1990, Investigador visitante Universidad Joseph
Fourier (Francia) 1999-2000, Profesor Asociado de la Universidad de los Andes (desde 1986).
Grupo de Investigación en Construcción de Software
Universidad de Los Andes
rcasalla@uniandes.edu.co
jvillalo@uniandes.edu.co