¿Qué es la ingeniería de software y algunos ejemplos?


El término "ingeniería de software" ha sido utilizado por mucha gente para significar muchas cosas diferentes. El campo del desarrollo de software sufre de lo que yo llamo "inflación de títulos de trabajo". En otras palabras, muchos de los que tienen el título de trabajo "ingeniero de software" no son verdaderos ingenieros de software, sino más bien programadores (o quizás un poco más).

Entonces, ¿qué es la ingeniería de software? Es hacer todo lo necesario para producir un software de alta calidad en el que alguien pueda confiar. Una forma de explicar qué son todas esas cosas es ver lo que dicen los expertos en la materia. Aproximadamente en 1998, un grupo de organizaciones, entre las que se encontraban las dos principales sociedades técnicas de informática (la Association for Computing Machinery y la sociedad de informática IEEE), junto con una docena de grandes empresas que desarrollan software de gran calidad y complejidad, iniciaron un esfuerzo para definir lo que debe saber un verdadero ingeniero de software. Tras varios años de intenso trabajo, este esfuerzo dio lugar a un documento titulado "Guide to the Software Engineering Body of Knowledge" (a menudo denominado SWEBOK). Esta guía se encuentra ahora en su tercera versión, después de haber sido revisada por más de 1000 expertos de todo el mundo. La mantiene la IEEE Computer Society y puede adquirirse de ella como libro impreso o descargarse como PDF de forma gratuita en www.swebok.org.


El SWEBOK define 15 áreas de conocimiento que se consideran esenciales para la verdadera ingeniería del software. Cada una de ellas, a su vez, se divide en una docena de temas más detallados. Uno de esos 15 es la construcción de software (programación) y los otros son cosas como los requisitos de software, el diseño de software, la gestión de la configuración de software, las pruebas de software, la calidad del software, la gestión de proyectos de software, y muchos otros. El documento SWEBOK también tiene una excelente lista de material de referencia.


Hay mucho involucrado en la verdadera ingeniería de software. Una revisión del documento SWEBOK es un buen punto de partida si usted está tratando de entender todo lo que está involucrado en hacer realmente la ingeniería de software real. Pero eso es sólo el conocimiento básico. También está la cuestión de la experiencia, tanto en el desarrollo de software como en la comprensión de las aplicaciones para las que uno escribe software.

Nótese que la verdadera ingeniería de software permite a uno (o, más a menudo, a un equipo de ingenieros de software) desarrollar un paquete de software altamente complejo, como el que se requiere para un sistema de control del tráfico aéreo o una central nuclear o un avión o un automóvil moderno. Un ejemplo que ilustre un proyecto de esa envergadura sería muy grande. A continuación, ofrezco un ejemplo simplificado de lo que supondría la ingeniería del software de una aplicación informática algo más pequeña. Se basa en varios productos en los que trabajé durante mi carrera:

  • un sistema de navegación para un barco,
  • un paquete de software que fue precursor de los modernos sistemas de procesamiento de textos,
  • un sistema de radar para helicópteros comerciales,
  • un sistema operativo para un superordenador,
  • y varios otros.

A continuación, he enumerado las actividades que realiza un ingeniero de software cuando desarrolla una aplicación de software grande, verdaderamente profesional y de alta calidad. Tenga en cuenta que, aunque he enumerado las actividades de la ingeniería de software en un orden determinado, muchas de ellas ocurren simultáneamente entre sí y, a menudo, usted hace algunas de ellas repetidamente.

  1. Entender el problema a resolver. Esto suele requerir un amplio conocimiento del ámbito de aplicación. El software para la navegación de barcos o aviones requiere un conocimiento muy diferente al del software para resolver aplicaciones empresariales, que a su vez requiere un conocimiento muy diferente al del software para un dispositivo médico de seguridad crítica, que es muy diferente al del software para una aplicación de teléfono inteligente.
  2. Entender las tecnologías disponibles. Qué dispositivos de hardware estarán involucrados y qué podrán hacer y qué tendrá que hacer el software. Esto se llama a veces ingeniería de sistemas y, en la medida en que es necesario, requiere ingenieros que conozcan múltiples tecnologías. Al principio de mi carrera, las personas que realizaban este trabajo presentaban sus resultados al equipo de software, pero a medida que el software se volvía cada vez más importante en el diseño de sistemas complejos, los ingenieros de software se hacían cada vez más responsables de esta actividad y participaban en ella.
  3. Tomar decisiones sobre qué herramientas de desarrollo de software, lenguajes y metodologías de desarrollo tienen más sentido. Esta es una actividad de análisis y planificación que requiere el conocimiento de múltiples lenguajes, herramientas y metodologías. No basta con tomar su lenguaje de programación favorito y seguir con él. Por ejemplo, puede estar utilizando un ordenador para el que su lenguaje favorito no tiene compilador o su lenguaje favorito puede ser poco adecuado para la aplicación.
  4. Participar en las decisiones sobre qué partes del software deben ser desarrolladas por qué organizaciones (en el caso de un gran proyecto, puede haber múltiples organizaciones involucradas). Puede que no todas estas organizaciones formen parte de su empresa. Si parte del software debe ser adquirido o desarrollado por otra organización, es posible que también tenga que participar en el establecimiento y la negociación de las obligaciones contractuales y otros requisitos que impondrá a esos proveedores.
  5. Decidir cómo se dividirá el software en paquetes independientes, a menudo conocidos como "elementos de configuración". Es decir, cuáles serán las partes principales.
  6. [Aunque no es una función de ingeniería de software propiamente dicha, es posible que también se le pida que ayude a redactar propuestas a clientes potenciales, explicando cómo desarrollará su software y por qué el suyo es un enfoque adecuado para la aplicación específica. A menudo, los proyectos de gran envergadura se disputan entre diferentes empresas que cuentan con la experiencia adecuada]
  7. Determinar los requisitos del software y cómo se relacionan con los requisitos de nivel superior del sistema. Normalmente, los requisitos son establecidos primero por los clientes o por ingenieros de nivel superior que los definen en su propia terminología. El ingeniero de software debe traducirlos a una terminología que tenga sentido para los desarrolladores de software. A menudo, esto implica muchas discusiones e incluso debates con los clientes y otras personas para limar los detalles y determinar exactamente lo que se necesita. Un problema habitual es que los clientes no sepan realmente lo que quieren o, en un proyecto grande, que distintas partes de la organización del cliente tengan opiniones diferentes sobre cuáles deben ser los requisitos. También es esencial establecer un enfoque de gestión del cambio de requisitos. Los requisitos se modifican con frecuencia (normalmente por los clientes, pero a veces por los ingenieros que se dan cuenta de que los requisitos originales son demasiado costosos o técnicamente inviables). Hay que ser capaz de entender las consecuencias de los cambios propuestos en el coste y el calendario del software para que, cuando se propongan cambios, se pueda informar a los responsables de la toma de decisiones, como los clientes o los directivos de mayor nivel, de las consecuencias (normalmente, los cambios requieren retrasos en el calendario y aumentos de los costes).
  8. Desarrollar un plan integral para el desarrollo del software. Teniendo en cuenta cuestiones como los presupuestos disponibles, las limitaciones de tiempo y los objetivos de calendario, los riesgos y los recursos disponibles, hay que idear un plan sobre cómo desarrollar el software. Esto le ayudará a saber cuántas personas y qué equipos necesita, así como cuánto dinero y tiempo necesita. Aunque un buen plan requiere tener una comprensión razonable de los requisitos, a menudo hay que hacer gran parte de la planificación como parte del paso 6 (arriba), porque los clientes suelen decidir qué contratista utilizar en función de la calidad de sus planes de desarrollo de software.
  9. Desarrollar la arquitectura del software. En realidad, esto comienza en los pasos 4 y 5 (arriba), pero aquí hay que dar mucho cuerpo a los detalles.
  10. Desarrollar el diseño detallado del software. Aquí es donde se llega a todos los detalles realmente finos pero muy importantes.
  11. Escribir el código. Por último, en el paso 11, se empieza a programar.
  12. Diseñar un plan eficaz de integración y pruebas para el producto y el software. Esto también comienza antes, pero una vez que se inicia la programación, las actividades de integración y prueba cobran importancia. En un proyecto de gran envergadura, es fundamental haberlo pensado bien.
  13. Llevar a cabo los procesos de integración y prueba y, cuando se encuentren problemas, averiguar qué ha ido mal y por qué y volver a realizar cualquier paso anterior que sea necesario para solucionar los problemas.
  14. Determinar cómo se entregará, instalará, mantendrá y actualizará el producto una vez en el entorno del cliente. A continuación, se implementan las herramientas y capacidades necesarias para que esto ocurra. (Piense en todo lo que se necesita para que las actualizaciones de software funcionen correctamente, por ejemplo.)
  15. Determinar qué criterios de calidad son apropiados para el producto e implementar varias revisiones, inspecciones y otros mecanismos para evaluar la calidad y garantizar que se cumplan los estándares de calidad. [Esta actividad también comienza mucho antes y en paralelo con gran parte de lo anterior]
  16. Establecer y mantener un enfoque de control de la configuración para el proyecto y aplicar ese enfoque. Esto implica cosas como las convenciones de nomenclatura para las versiones de software y los componentes de software, los métodos para autorizar los cambios y asegurarse de que los cambios no se solapen entre sí y causen problemas, asegurarse de que la versión correcta de cada componente es la que se utiliza para cada versión o lanzamiento del producto, etc.
  17. Documentar muchas cosas a lo largo del camino para que aquellos que deben mantener y dar soporte al producto después de que usted haya pasado a mejor vida puedan entender todos los aspectos de todo lo anterior.

Hay muchas cosas que he dejado fuera de lo anterior, algunas de las cuales podrían aplicarse sólo a algunos proyectos. Un proyecto pequeño como un sitio web o una típica aplicación para teléfonos inteligentes podría no requerir un enfoque tan extenso como el que he descrito aquí, pero preguntaste sobre lo que es la ingeniería de software y pensé en darte una idea de lo que los ingenieros de software reales y profesionales pasan su tiempo haciendo.

También debo mencionar que algunos métodos de desarrollo de software, como los métodos "ágiles", son altamente iterativos, lo que significa que pasan por gran parte de lo anterior repetidamente, aunque no necesariamente con un alto grado de disciplina y rigor para cada iteración.

También debo mencionar que un proyecto de ingeniería de software realmente grande implica un gran equipo de personas y las habilidades de gestión de personas van a ser requeridas por todos los participantes, especialmente los líderes del equipo y otros con mayores niveles de responsabilidad.