Introducción a la Ingeniería del Software

No hay consenso sobre la definición de Ingeniería del Software. Pese a tener más de 50 años (y el software más de 70), se la sigue viendo como una rama nueva de la ingeniería que busca sistematizar de forma racional las prácticas de una industria muy distinta de las ingenierías tradicionales.

El software es mucho más que código. Se compone de:

Características distintivas (según Pressman)

1. Se desarrolla con el intelecto, no se fabrica: el proceso se parece más al diseño que a la fabricación.
2. No se desgasta, aunque se degrada: es intangible, sin desgaste, fatiga ni caducidad.
3. La industria física ensambla componentes estándar; el software, en gran parte, sigue siendo a medida y único.
4. El coste de réplica es casi nulo: casi todo el coste está en el desarrollo.

«Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases.»

Atributos de calidad

Un buen software no basta con que funcione: debe ser mantenible, confiable, seguro, eficiente y aceptable para sus usuarios, tanto en ejecución como en su estructura interna, documentación y facilidad de uso. Un sistema bancario debe ser seguro; un videojuego, interactivo y receptivo. Son los atributos de calidad o atributos no funcionales.

Evolución del papel del software

Al principio el protagonista era el hardware, más caro y sofisticado. Hoy se han invertido los papeles: el software es lo más relevante y el hardware casi una commodity. El software es ya un recurso clave para la industria, los gobiernos y la sociedad.

Diversidad de sistemas

Un sistema embebido en un dispositivo médico no tiene los mismos requerimientos que un videojuego o una aplicación web.

Ingeniería viene de «ingenio»: «facultad del ser humano para discurrir o inventar con prontitud y facilidad» o «industria, maña y artificio de alguien para conseguir lo que desea». También se llamaba así a las máquinas o «artificios mecánicos».

«Conjunto de conocimientos orientados a la invención y utilización de técnicas para el aprovechamiento de los recursos naturales o para la actividad industrial.»

Es, sobre todo, el uso de principios científicos para diseñar y construir máquinas, estructuras y otros elementos artificiales (puentes, edificios, vehículos, sistemas y procesos), aprovechando el conocimiento tecnológico para innovar y resolver problemas técnicos de las personas y de la sociedad.

La disciplina ha crecido rápido y sin mucho orden, a la par que la industria. Aún conviven empresas que desarrollan ad hoc, sin metodología, con otras que aplican con rigor métodos complejos y efectivos. Y todo en un mundo de cambio perpetuo:

• Evolución tecnológica: ordenadores a medida, mainframes, microcomputadores, PCs, Internet, servidores, móviles, IoT, computación distribuida y Cloud.
• Cambios de contexto: adaptarse rápido a nuevos requisitos de los clientes, a veces en cuestión de horas.

Entre 1940 y 1960 la inversión estaba en el hardware. Los programas eran independientes, de propósito único y hechos a medida de cada ordenador; se usaban para cálculo, sin atender a la interacción con el usuario (de especialistas para especialistas) y en sistemas aislados.

La crisis del software

Al crecer la escala de los sistemas aparecieron problemas que siguen siendo los grandes retos de la disciplina y la razón de su existencia:

Además, el mantenimiento resulta mucho más caro de lo previsto y es muy difícil medir el progreso.

Aún hay muchos fracasos, por dos factores:

1. Las exigencias del mercado obligan a sistemas más complejos, rápidos y funcionales, que superan las técnicas tradicionales.
2. Muchas organizaciones desarrollan sin aplicar principios de ingeniería, con productos caros, poco fiables y difíciles de mantener.

La solución: mejor formación profesional en Ingeniería del Software y aplicar buenas prácticas desde el inicio.

No hay una definición única; casi cada autor tiene la suya. Las más relevantes:

«La ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales.»

«Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos.»

«Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software.»

«La Ingeniería del Software es aplicar el sentido común al desarrollo de sistemas software.»

Cronología

1. 1940-60El hardware es el protagonista; programas de cálculo, aislados y a medida.
2. 1968Conferencia de Ingeniería del Software: nace la disciplina.
3. 1969Se funda el PMI (Project Management Institute).
4. 1972Definición de Bauer.
5. 1976Definición de Boehm.
6. 1987Gartner populariza el análisis TCO.
7. 1993Definición del IEEE (610.12).

Ingeniería frente a programación personal

La Ingeniería del Software se ocupa de todos los aspectos de la producción de software, desde la especificación inicial hasta el mantenimiento. Frente a la programación personal (informal, individual), implica procesos sistemáticos, planificación, documentación y trabajo en equipo: el software profesional lo usarán y modificarán personas distintas de quien lo hizo.

La Ingeniería del Software hereda en parte los principios de la Teoría de Sistemas:

• Cuanto más especializado es un sistema, menos capaz es de adaptarse a circunstancias diferentes.
• Cuanto mayor es, más recursos exige su mantenimiento diario.
• Los sistemas siempre forman parte de sistemas mayores y siempre pueden dividirse en menores.
• Los sistemas crecen.

Análisis de un sistema según la Teoría de Sistemas

1. Definición del problema: elementos de insatisfacción, posibles cambios en entradas o salidas y objetivos del análisis.
2. Comprensión y definición del sistema: descomposición jerárquica en subsistemas y sus relaciones.
3. Elaboración de alternativas de modificación y mejora, según costes y viabilidad.
4. Elección de una alternativa.
5. Puesta en práctica de la solución elegida.
6. Evaluación del impacto de los cambios.

Actividades fundamentales del proceso de software

Se use el modelo que se use, siempre están estas cuatro:

• Especificación: qué debe hacer el software y bajo qué condiciones (funcionalidad, características y restricciones).
• Desarrollo: diseño y programación para cumplir las especificaciones.
• Validación: comprobar que cumple los requisitos y lo que espera el cliente (que no es necesariamente lo que pide).
• Evolución/mantenimiento: adaptarlo a nuevas necesidades o corregir errores.

Hay además actividades adicionales (análisis, diseño, planificación, gestión, operación, medida, despliegue…). Las distintas formas de organizarlas dan lugar a los modelos de procesos de software.

Para entender el alcance de la disciplina hay que conocer los procesos del ciclo de vida del software: desde su concepción hasta que deja de usarse.

Puede implicar desarrollar desde cero, pero hoy, sobre todo en aplicaciones empresariales, es habitual modificar sistemas existentes o integrar componentes comerciales. Se estudian dos modelos: el del PMI (muy habitual en la industria) y el de ISO/IEC 12207:2008.

El PMI (Project Management Institute), fundado en 1969, promueve las buenas prácticas en gestión de proyectos con presencia mundial. Es conocido por:

• La Guía del PMBOK® (Project Management Body of Knowledge).
• Sus certificaciones, sobre todo la PMP (Project Management Professional).
• Fomentar la investigación y formación en dirección de proyectos.

La PMP acredita la capacidad de liderar proyectos; se basa en el PMBOK y exige experiencia previa, formación específica y un examen riguroso. Se enfoca en tres dominios: Personas (liderazgo), Procesos (gestión técnica) y Entorno empresarial (estrategia y valor).

Áreas de conocimiento

Grupos de procesos

Para la Ingeniería del Software interesan más los 5 grupos de procesos, que son las fases del ciclo de vida de un proyecto (cada grupo incluye procesos de varias áreas):

1. Inicio (Initiating): define y autoriza el proyecto o fase. Ej.: acta de constitución.
2. Planificación (Planning): alcance, objetivos y curso de acción. Ej.: cronograma, costes, riesgos.
3. Ejecución (Executing): se realiza el trabajo del plan. Ej.: gestión del equipo, calidad, recursos.
4. Monitoreo y control (Monitoring and Controlling): se supervisa el progreso y se ajusta. Ej.: control de cambios, seguimiento.
5. Cierre (Closing): fin formal del proyecto o fase. Ej.: cierre de contratos, lecciones aprendidas.

Todo proyecto software pasa por etapas similares, de forma secuencial o iterativa. El PMI, considerado durante mucho tiempo el estándar de la gestión predictiva (waterfall), es hoy agnóstico y aplica también los principios Agile, que se verán al final de la asignatura.

«Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, explotación y mantenimiento de un producto software, abarcando la vida del sistema desde la definición de requisitos hasta que se deja de utilizar.»

Según el material, define 17 procesos, divididos en tareas:

Muchas decisiones del profesional tienen que ver con comprar, usar, integrar o construir los componentes software que resuelven el problema del cliente. El cliente puede ser interno (atendido por el departamento de IT o Sistemas) o externo. Las salidas profesionales más habituales:

• Departamento que da servicio interno en una organización.
• Área de producción que genera producto nuevo, del que salen los ingresos.
• Consultoras que dan soporte a terceros en esas dos tareas (sobre todo la primera).

Actividades del proceso de desarrollo

Cada proceso se divide en actividades. Las del proceso de Desarrollo:

1. Análisis de requisitos del sistema: necesidades del cliente y requisitos del sistema completo (hardware, software, personas).
2. Análisis de requisitos del software: requisitos funcionales (qué hace) y no funcionales (rendimiento, seguridad, usabilidad…).
3. Diseño de la arquitectura: módulos, componentes, interfaces y relaciones.
4. Diseño detallado: algoritmos, estructuras de datos e interfaces internas de cada componente.
5. Construcción (codificación): código fuente y pruebas unitarias.
6. Integración: combinar los módulos con pruebas de integración.
7. Pruebas del software: funcionales, de rendimiento, seguridad, usabilidad…
8. Instalación: despliegue en el entorno del cliente, configuración, migración de datos y formación.
9. Aceptación: el cliente confirma que cumple lo acordado; se documenta formalmente.

El desarrollo académico (prácticas individuales o en grupos pequeños, sin procesos definidos, sin despliegue ni usuarios finales) está muy lejos de la experiencia profesional.

Requisitos de operación

Todo software en uso necesita continuidad, estabilidad y fiabilidad: a los requisitos de usuario se suman los de Explotación, Operaciones o Sistemas. El software debe:

• Estar documentado (manuales de operación).
• Tener procedimientos de recuperación ante caídas o fallos.
• Facilitar su operación y continuidad (backups, logs…).
• Funcionar en la plataforma elegida (SO, lenguajes, bases de datos).
• Generar indicadores y alarmas sobre su estado.

Bases de la industrialización

• Automatizar tareas repetitivas (compilación, pruebas, despliegue).
• Frameworks y plataformas que permiten reutilizar componentes.
• Integración y entrega continuas (CI/CD).
• Control de calidad sistemático con pruebas automatizadas y métricas.
• Gestión de la configuración y versiones para la trazabilidad.
• Documentación estructurada y revisiones formales.
• Trabajo colaborativo con roles especializados (analistas, testers, devops…).

Cómo industrializar

1. Adoptar metodologías formales: Scrum, Kanban, DevOps o cascada adaptada.
2. Implementar automatización: integración continua, pruebas y despliegue automáticos.
3. Estandarizar: plantillas, convenciones de código, revisiones y control de cambios.
4. Formar equipos multidisciplinares con roles definidos.
5. Medir y mejorar: cobertura de pruebas, velocidad, defectos por entrega…

Implicaciones

Comparativa: industrial frente a académico

Ambos enfoques son valiosos, pero responden a contextos distintos: el académico prioriza el aprendizaje y la creatividad; el industrial, la eficiencia, la calidad y la sostenibilidad.

Hay que separar programación e ingeniería del software, algo que se aprende rápido al llegar al mundo laboral. La experiencia académica gira en torno a retos de programación; la profesional muestra que esa no es la tarea fundamental de un ingeniero del software.

Desarrollar software no es la principal solución a un problema, ni siquiera la más frecuente. El profesional debe conocer las opciones disponibles: no es lo mismo un desarrollo a medida que un paquete comercial, ni el riesgo de un software propietario que el de uno Open Source. Y debe considerar lo económico a corto y a largo plazo, consolidando áreas muy distintas (infraestructura, plataforma, bases de datos, desarrollo, paquetes…).

Decisión: comprar, adaptar o construir

Ante una solicitud de servicio a Sistemas de Información hay cuatro opciones:

Pesan la viabilidad técnica y el alineamiento estratégico, pero el impacto económico es determinante. Para decidir si invertir y en qué modalidad (a medida o paquete; licencia propietaria u Open Source), la industria usa el TCO.

El error habitual es considerar solo algunos costes de implantación y operación y olvidar los que no son evidentes: la decisión se basa en supuestos erróneos.

El análisis TCO lo popularizó Gartner en 1987. En Ingeniería del Software cuantifica el impacto financiero de un producto tecnológico en todo su ciclo de vida (software, hardware, formación, personal…).

«Análisis exhaustivo del coste global de la tecnología de la información (TI) y otros costes para la organización a lo largo del tiempo. Incluye adquisición de hardware y software, gestión y soporte, comunicaciones, gastos de usuarios finales, formación, coste de oportunidad y cualquier otra pérdida de productividad.»

Costes potenciales del TCO

Ejemplo interactivo: comparar dos alternativas

El material anuncia un «ejemplo de cálculo de TCO» que no está en el texto exportado. Esta calculadora (propia, no incluida en el material) ilustra la idea anterior con un modelo simplificado: TCO acumulado = inversión inicial + coste anual × años, sin actualizar el valor del dinero.

Clasificación por tipo de software

Para el TCO interesa sobre todo el modelo de creación y provisión del software.

Aplicaciones a medida

Desarrolladas para los requerimientos de un cliente concreto; la única opción cuando no existe software comercial que cubra esas necesidades.

Rara vez un desarrollo a medida es íntegramente nuevo: casi siempre incorpora componentes comerciales o reutiliza otros de la organización. Es la integración.

Plataformas y aplicaciones cerradas

Una plataforma puede ser: solo hardware (sistemas embebidos), un navegador, una aplicación anfitriona (macros de Excel), un framework, cloud/PaaS (también redes sociales con APIs), una máquina virtual (JVM) o un sistema completo virtualizado. La plataforma elegida determina costes, proveedores y soporte.

Las plataformas cerradas no pueden ser examinadas por programadores ajenos: se usa su funcionalidad sin conocer su interior. Suelen ser de empresas privadas que viven de explotarlas (Windows, iOS, Office, Edge, Chrome). Caso paradigmático: Apple, que controla el hardware y así reduce la complejidad y optimiza más fácilmente.

Plataformas y aplicaciones abiertas

Su diseño es público y puede auditarse, modificarse y copiarse. Las desarrollan comunidades, empresas, universidades y centros de investigación (Linux, LibreOffice, Firefox, Chrome hasta cierto punto). Tienen una capa de abstracción pública que facilita incorporar nuevo hardware; eso dificulta optimizar, pero han llegado a ser estándar de facto, como la plataforma LAMP (Linux, Apache, MySQL, PHP).

Software Open Source y licencias

Licencias Open Source habituales: BSD, GPL, LGPL, W3C. El Open Source se ha extendido porque es cada vez más robusto, algunas comunidades responden muy rápido y hay empresas (como Red Hat) que venden soporte profesional para él.

Al pagar software comercial se paga, en realidad, por soporte:

• Directo: teléfono o web del fabricante.
• Indirecto: profesionales certificados por el fabricante.
• Longevidad: que la empresa sobreviva y saque nuevas versiones.
• Sentido de seguridad: tener a quién llamar o a quién reclamar. Es lo que más frena el uso de Open Source.

La integración es clave en el diseño, la planificación y la gestión de sistemas: el megasistema que lo hace todo no es viable (incluso un ERP son módulos integrados). En la práctica no hay sistema informático sin integración.

Cuándo integrar sistemas

• Si no es posible desarrollar una aplicación que cubra lo necesario.
• Si desarrollar cuesta más que integrar, gestionar y evolucionar la integración.
• Si lo obligan factores externos (regulatorios, legales).
• … y siempre que exista tecnología que lo permita.

También hay necesidades de origen hardware: dispositivos especializados con información de negocio, telefonía y call-center, TPV, dispositivos industriales.

Problemáticas y soluciones

Tecnologías de integración: CORBA, RPC, SOAP, DCOM, RPA… (darían para una asignatura entera).

Para completar la visión del TCO hay que considerar las aplicaciones en pago por uso, que externalizan completamente la solución, y su integración en escenarios mixtos.

Crece a medida que maduran los servicios web y la arquitectura orientada a servicios (SOA), y sobre todo gracias a la banda ancha. Está muy relacionado con el modelo ASP (Application Service Provider) y con el software bajo demanda. IDC distingue dos modelos de entrega, el primero de ellos la gestión alojada de aplicaciones (hosted AM), similar a ASP.