1.

1 Introducción
La ingeniería es el proceso de construcción de productos. En el caso de la
ingeniería de software, el producto es inmaterial y maleable.
[!Definición] El software de computadora es el producto que con-
struyen los programadores profesionales y al que después le dan man-
tenimiento durante un largo tiempo. Incluye programas que se eje-
cutan en una computadora de cualquier tamaño y arquitectura, con-
tenido que se presenta a medida de que se ejecutan los programas de
cómputo e información descriptiva tanto en una copia dura como en
formatos virtuales que engloban virtualmente a cualesquiera medios
electrónicos. El software de computadora se construye del mismo
modo que cualquier producto exitoso, con la aplicación de un pro-
ceso ágil y adaptable para obtener un resultado de mucha calidad,
que satisfaga las necesidades de las personas que usarán el producto.
En estos pasos se aplica el enfoque de la ingeniería de software.
[!Definición] La ingeniería de software está formada por un pro-
ceso, un conjunto de métodos (prácticas) y un arreglo de herramien-
tas que permite a los profesionales elaborar software de cómputo
de alta calidad. Los ingenieros de software elaboran y dan manten-
imiento al software, y virtualmente cada persona lo emplea en el
mundo industrializado, ya sea en forma directa o indirecta.
Capas de la ingeniería de software
La ingeniería de software se divide en varias capas. La capa base sobre la que
se sustenta el resto es un enfoque de calidad. Todo proceso de ingeniería,
no solo en software, debe estar sustentado en el compromiso con la calidad del
producto.
Encima de esta se tendría la capa de proceso. El proceso de software es el
mecanismo por el cual se desarrolla y se entrega la tecnología de forma eficiente.
El proceso de software incluye desde la organización de los distintos equipos de
trabajo que pueda haber hasta los métodos técnicos aplicados en el desarrollo
(p. ej. Modelos, documentos, datos, etc). Esta capa es esencial para asegurar la
calidad total del producto.
Después se tendría la capa de métodos. Esta capa explica el cómo se va a
desarrollar el software. Los métodos abarcan una amplia gama de tareas como
el análisis de requisitos, modelado, construcción del programa, pruebas, etc.
Por último la capa de herramientas brinda apoyo automático o semi-
automático a las capas de proceso y métodos.
[[capas_ingenieria_software.png]]
1.2 Producto software
Atributos de calidad del software

1
Para garantizar la calidad de un producto de software, es esencial considerar
una serie de atributos fundamentales:

Atributo Descripción
Adecuación El software debe cumplir con las necesidades y
expectativas del cliente. Esto implica que debe ser
comprensible, fácil de usar y compatible con diversos
sistemas según sea necesario.
Confiabilidad y El software debe ser confiable y seguro. La confiabilidad
seguridad implica garantizar la integridad física y económica del
sistema en caso de fallos, y debe estar protegido contra
posibles ataques externos. Además debe ser recuperable.
Eficiencia El software debe utilizar eficientemente los recursos del
sistema, evitando el desperdicio innecesario de recursos
como el procesamiento y la memoria.
Mantenibilidad El software debe ser diseñado de manera que permita un
mantenimiento a largo plazo y tenga la capacidad de
adaptarse a las nuevas necesidades del cliente que puedan
surgir en el futuro.

Al considerar estos atributos, se asegura que el producto de software sea de alta

calidad y cumpla con los estándares requeridos para satisfacer las demandas del
cliente y garantizar su funcionamiento confiable y eficiente.
1.3 Procesos de software
[!Definición] Un proceso de software es un conjunto de actividades
que lleva a la producción de un sistema software.
El proceso de software depende del tipo de proyecto que se lleva a cabo, no
hay proceso universal que funcione bien para todos los tipos de software que se
pueden desarrollar.
Sin embargo, si que podemos encontrar en casi todos los procesos una serie de
actividades en común:
1. Especificación de software: análisis y definición de los requisitos que
debe cumplir el sistema.
2. Desarrollo de software: construcción del software que cumpla con los
requisitos establecidos en la fase de especificación.
3. Validación de software: se comprueba que el software cumpla con las
necesidades del cliente así como con los estándares de calidad establecidos.
4. Evolución de software: el software debe ir evolucionando para cumplir
las necesidades del cliente.
Todas estas actividades son complejas en si mismas e incluyen sub-actividades.
Dentro de estas actividades conviene destacar tres elementos importantes:

2
 1. Qué se produce: qué es lo que obtenemos al final de una actividad.
2. Quién está involucrado: los roles reflejan la responsabilidad que ostenta
cada una de las personas involucradas en el proyecto. Algunos roles son
por ejemplo programador o project manager.
3. Precondiciones y postcondiciones: qué es lo que necesitamos antes
de empezar una actividad y que es lo que tenemos tras finalizarla. Por
ejemplo, para que empiece la construcción de software se necesita tener
los requisitos aprobados por el cliente (precondición), y una postcondición
es que el software al final de la actividad cumpla dichos requisitos.
Paradigmas de desarrollo
La programación es un proceso altamente creativo. Para un mismo conjunto de
requisitos se pueden hacer una infinidad de programas distintos. Para intentar
estandarizar el desarrollo se han ido creando a lo largo del tiempo una serie de
paradigmas de desarrollo:
1. Paradigma imperativo: los programas se estructuran en una serie de
pasos ordenados para llegar a la solución deseada. Dentro del paradigma
imperativo encontramos varias formas de estructurar el código:
1. Paradigma procedural: el código se estrucutra en distintas fun-
cionas que se ejecutan en un orden determinado para llegar a la solu-
ción.
2. Paradigma estructurado: el código se estructura en bloques que
definen el flujo del programa como bucles anidados, condicionales o
subrutinas.
2. Paradigma declarativo: no se centra en cómo llegar a la solución como
el paradigma imperativo sino que directamente se escribe el resultado de-
seado.
3. Paradigma orientado a objetos: se fundamenta en el uso de las clases.
Las clases son instancias de objetos, cada uno con sus atributos y funciones,
que varían su estado a lo largo de la ejecución del programa e interactúan
con otros objetos.
4. Paradigma basado en componentes: el código se estrucutra en com-
ponentes, paquetes de código completos que incluyen una o varios tipos de
funcionalidad como puede ser la lógica o la GUI que funcionan como cajas
negras. Los componentes se construyen para ser reutilizados en distintos
tipos de programa y suelen comercializarse a terceros.
5. Paradigma orientado a aspectos: a diferencia de los componentes, los
aspectos son bloques de código de un mismo tipo de funcionalidad que
se aplican normalmente sobre muchos bloques de código existentes. Los
aspectos consiguen una mayor modularidad del código lo que implica más
facilidad de modificación y permiten la reutilización.
Modelos de proceso
Un modelo de proceso software es una versión simplificada de un proceso
software. Cada modelo representa un proceso desde una perspectiva específica,

3
por ejemplo, un modelo puede representar el orden en el que se realizan las
tareas pero no los roles específicos de cada miembro del equipo.
Es importante destacar que el modelo de proceso no condiciona el paradigma
de desarrollo.
En general podemos indentificar una serie de actividades fundamentales que
comparten todos los modelos de proceso:
1. Especifiación de requisitos: la definición de servicios, reestricciones y
objetivos que son requeridos por los usuarios del software.
2. Diseño de software: se identifican las abstracciones fundamentales del
sistema y las relaciones entre ellas.
3. Implementación y validación: se verifica que el software cumple con
las especificaciones y criterios de calidad establecidos.
4. Mantenimiento y evolución: el software debe estar preparado para
evolucionar conforme a las necesidades dinámicas del cliente.
Debemos tener claro el concepto ciclo de vida software. El ciclo de vida del
software comienza desde que nace el software hasta que el equipo de desarrollo
da por terminado el código (done).
El modelo de proceso software intenta organizar este ciclo de vida definiendo
las actividades así como su orden y relaciones entre ellas. Es importante señalar
que el modelo de proceso no condiciona el paradigma.
Modelo en cascada
Es el primer modelo de proceso publicado. Define el proceso de software como
un conjunto de fases que van sucediéndose en forma de cascada. Cada fase es
planeada y organizada antes del desarrollo. Las fases reflejan directamente
las actividades fundamentales mencionadas anteriormente.
[[waterfall-default.png]]
Dentro del modelo en cascada encontramos dos variantes. Por un lado está el
modelo cascada con retroalimentación que permite volver una o varias eta-
pas si es necesario. Por otro está el escalada con prototipado. El prototipo
consiste en una muestra funcional del software que contenga una o varias fun-
cionalidades. Este prototipo puede ser desechable si solo se usa de muestra o
puede ser evolutivo si se va a ir extendiendo hasta conformar el producto final.
Modelos evolutivos
Modelo incremental
El modelo incremental es un proceso iterativo que divide el desarrollo en
pequeños trozos o incrementos. Cada incremento incluye una fracción de fun-
cionalidad de los requisitos y necesidades del cliente. El software se va con-
struyendo incremento a incremento hasta que el sistema está completo. Cada
incremento se entrega al cliente para recibir feedback.

4
[[modelo-incremental.jpg]]
Modelo evolutivo
El modelo evolutivo deriva del modelo incremental. La diferencia fundamen-
tal radica en que en esta ocasión los requisitos y necesidades del cliente no son
tan claros y no se tiene una visión del producto final. De esta forma, se parte
de unos requisitos iniciales que se van refinando a lo largo del desarrollo. Cada
ciclo concluye con una versión del producto que se entrega al cliente para
recibir feedback para la siguiente iteración. De esta forma, mientras que en el
desarrollo incremental se tenía una idea del producto final y se iba construyendo
a trozos, en el desarrollo evolutivo el producto va variando su forma en cada
iteración.
[[modelo-evolutivo.jpg]]
Modelo en espiral
El modelo en espiral es un proceso evolutivo impulsado por riesgos. Este
proceso plantea un enfoque cíclico de desarrollo en el que el producto va refinán-
dose y creciendo mientras que los riesgos van disminuyendo. Los riesgos son
situaciones o eventos posibles que entorpezcan el desarrollo e impidan alcan-
zar los objetivos planteados. El manejo de riesgos incluye preveer los riesgos,
calcular la probabilidad de que sucendan, ordenarlos por grado de prioridad y
realizar un plan de mitigación para lidiar con ellos.
[[modelo-espiral.jpg]]
RUP
RUP o Rational Unified Process es un proceso flexible e iterativo en el que
el producto de software se diseña y se construye durante iteraciones dentro de
un conjunto de fases predefinidas y altamente documentadas. En este proceso se
lleva un control del tiempo dedicado a cada actividad en cada fase de desarrollo.
En la fase de comienzo el esfuerzo se concentra en plantear los requisitos del
producto y su viabilidad. En la fase de elaboración ya se tienen los requisitos
fundamentales bien definidos y se empiezan a construir los cimientos de la ar-
quitectura del software. Durante la construcción se tiene ya una visión casi
total de las necesidades del sistema y se construye el software completo. Por
último, en la fase de transición se entrega el software al cliente y comienza la
etapa de mantenimiento y se adaptaptación del sistema al usuario final.
Otro apartado a destacar es la administración de la configuración que
consiste en documentar los cambios del software a lo largo del tiempo. Es un
concepto análogo al control de versiones de Git.
[[rup.png]]
Sistemas formales
Modelo general

5
Los sistemas formales se basan en la representación lógica y matemática del
software. Una especificación formal es una definición del software y sus carac-
terísticas en un vocabulario, sintaxis y semántica predefinidas. Normalemnte
este vocaubulario suelen ser reglas lógicas o matemática discreta.
[[metodos-formales.jpg]]
Model Driven Development
El desarrollo dirigido por modelos es un paradigma enfocado en la construcción
y explotación de modelos de dominio. Un modelo de dominio es una repre-
sentación asbtracta del sistema que se quiere desarrollar. Este enfoque conlleva
la generación automática de código a partir del modelo descrito.!
[[Development-process-using-traditional-model-driven-development-tools.png]]

1. Pressman, Roger S., Maxim, Bruce R.. (2015). SOFTWARE ENGI-

NEERING; A Practitioner’s Approach (8th). New York: MCGRAW-
HILL.
2. Sommerville, I. (2016) Software Engineering. 10th Edition, Pearson Edu-
cation Limited, Boston.
3. Bourque, P. & Fairley, R. E. (eds.) (2014). SWEBOK: Guide to the Soft-
ware Engineering Body of Knowledge. Los Alamitos, CA: IEEE Computer
Society. ISBN: 978-0-7695-5166-1
4. Boehm, B.. (2000). Spiral Development: Experience, Principles, and
Refinements.
5. Kruchten, Philippe. (2000). The Rational Unified Process–An Introduc-
tion.