Introducción a la

ingeniería del software

Autores: Simon Pickin

Marisol García Valls
Address: Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
Version: 1.0

Software de
Comunicaciones
2009-2010 1
© Los autores

Índice

1. Visión General / Definición de términos

2. Los modelos de ciclo de vida
3. La captura, análisis y especificación de requisitos
4. El diseño del software
5. La calidad del software
6. La Prueba del software
7. Algunos novedades en el campo

Software de
Comunicaciones
2009-2010 2
© Los autores
 1. Visión general / definición de términos

Software de
Comunicaciones
2009-2010 3
© Los autores

¿Qué es la ingeniería del software? (1/4)

• El establecimiento y uso de principios de

ingeniería robustos, orientados a obtener
económicamente software que sea fiable y
funcione eficientemente sobre máquinas
reales.
F.L. Bauer. Software Engineering.
Information Processing 71., 1972

Software de
Comunicaciones
2009-2010 4
© Los autores
 ¿Qué es la ingeniería del software? (2/4)

• La disciplina tecnológica y de gestión que

concierne a la producción y el mantenimiento
sistemático de productos software
desarrollados y modificados dentro de unos
plazos estipulados y costes estimados.
R. Fairley. Software Engineering Concepts.
New York: McGraw-Hill, 1985.

Software de
Comunicaciones
2009-2010 5
© Los autores

¿Qué es la ingeniería del software? (3/4)

• Ingeniería del software. (1) La aplicación de

un enfoque sistemático, disciplinado y
cuantificable del desarrollo, la operación y
el mantenimiento del software; esto es, la
aplicación de la ingeniería al software. (2)
El estudio de enfoques tales como (1).
IEEE Std 610-1990

Software de
Comunicaciones
2009-2010 6
© Los autores
 ¿Qué es la ingeniería del software? (4/4)

• Ingeniería es la aplicación sistemática de

conocimiento científico en la creación y construcción
de soluciones, que satisfacen una buena relación
efectividad/precio, de problemas prácticos al servicio
de la humanidad. La ingeniería del software es la
forma de ingeniería que aplica los principios de las
ciencias de la computación y las matemáticas en la
obtención de soluciones de los problemas del
software que satisfacen una buena relación
efectividad/precio.
SEI Report on Undergraduate Software Engineering
Software de
Comunicaciones
Education, 1990.
2009-2010 7
© Los autores

¿Qué no es la ingeniería del software? (1/2)

• Las ciencias de la computación

– atañe a la teoría y a los aspectos fundamentales
– la ingeniería del software atañe a los aspectos
prácticos del desarrollo y entrega de software útil.
– aún son insuficientes para actuar como
apuntalamiento de la ingeniería del software (al
contrario, p.e., de la física y la ingeniería eléctrica)

Software Engineering,
Software de
Sommerville
Comunicaciones
2009-2010 8
© Los autores
 ¿Qué no es la ingeniería del software? (2/2)

• La ingeniería de sistemas
– atañe a todos los aspectos del desarrollo de
sistemas basados en ordenadores, incluyendo el
hardware, el software y la ingeniería de procesos
– la ingeniería del software es la parte de este
proceso que atañe al desarrollo de la
infrastructura software, el control, las
aplicaciones y las bases de datos del sistema.
– los ingenieros de sistema están implicados en la
especificación del sistema, el diseño
arquitectónico, la integración y el despliegue.
Software de
Comunicaciones
Software Engineering,
2009-2010
Sommerville 9
© Los autores

¿Para qué la ingeniería del software? (1/4)?

• El término “ingeniería del software” se

popularizó al final de los años 60
• Respuesta a la llamada “crisis del software”
– las prestaciones del hardware aumentaban
mucho más rápido que las del software.
– el desarrollo de sistemas de software grandes
resultaba muy insatisfactorio:
• entrega habitualmente retrasada (a veces por mucho)
• presupuesto habitualmente excedido (a veces
masivamente)
Software de
• calidad del producto final habitualmente baja: productos
Comunicaciones
2009-2010
poco fiables y difíciles de mantener
10
© Los autores
 ¿Para qué la ingeniería del software? (2/4)?

• Las técnicas utilizadas para software “uni-

desarrollador” no escalan
– proyectos grandes necesitan un equipo
– la calidad de comunicación entre los miembros
es un problema serio → documentación

• Deseo de beneficiarse de experiencia previa

• Necesidad de planificar para el

mantenimiento y la evolución
– Las decisiones de diseño importantes deben
Software de
Comunicaciones
2009-2010
documentarse
11
© Los autores

¿Para qué la ingeniería del software? (3/4)?

• La comunicación con el cliente/usuario es

primordial
– entender los requisitos del cliente
– p.e. Xtreme programming (programación
extrema): el cliente tiene representante en el
equipo de desarrollo

Software de
Comunicaciones
2009-2010 12
© Los autores
 ¿Para qué la ingeniería del software? (4/4)?

• Necesidad de estimar el dinero, tiempo y

esfuerzo requeridos
– las estimaciones se basan principalmente en el
modelado del proyecto actual y su comparación
con proyectos anteriores
– ¿Queremos el trabajo? ¿Cuánto cobramos?
– Constructive Cost Model COCOMO
Constructive Systems Engineering Cost Model
COSYSMO
– The mythical man month, Brooks, 1975:
Software de
Comunicaciones
añadir recursos humanos a un proyecto de
2009-2010

© Los autores
software atrasado lo atrasa más 13

¿Qué es un proceso de desarrollo? (1/2)

• Proceso:
Una serie de acciones u operaciones que
conducen a un fin (Websters)
conjunto de las fases sucesivas de un fenómeno
natural o de una operación artificial (RAE)
• Proceso de desarrollo de software
El conjunto de actividades, métodos y prácticas
utilizados en la producción y evolución de
software.
Software de
Comunicaciones
2009-2010 14
© Los autores
 ¿Qué es un proceso de desarrollo? (2/2)

• Un proceso de desarrollo de software puede incluir

– un modelo de ciclo de vida
• divide el desarrollo en fases y prescribe las actividades que
deben realizarse en cada fase
• proporciona criterios para determinar cuándo cada fase de
desarrollo ha terminado
• define los deliverables / artefactos / productos de cada fase
– consideración de herramientas y equipamiento
– consideración de personal y de su organización
– restricciones sobre las actividades, los artefactos, las
herramientas, el personal etc.

• Para muchos autores:

Software de
Comunicaciones
proceso de desarrollo de software = ciclo de vida de software
2009-2010 15
© Los autores

¿Qué es un ciclo de vida de software?

• El periodo de tiempo que comienza cuando se concibe un

software y concluye cuando el producto ya no está
disponible para su uso.
• El ciclo de vida del software típicamente incluye una fase
de requisitos, una fase de diseño, una fase de pruebas,
una fase de instalación y aceptación, una fase de
operación y mantenimiento, y, en ocasiones, una fase de
retirada.
• Un modelo de ciclo de vida es una abstracción particular
que representa un ciclo de vida de software. Un modelo
de ciclo de vida se denomina con frecuencia un ciclo de
vida de desarrollo software (SDLC, siglas inglesas).
Software de
Comunicaciones
IEEE Standard Glossary of Soft. Eng. Terminology
2009-2010 16
© Los autores
 El modelado de software (& hardware)

• Perspectiva escéptica sobre modelos de software:

“burbujas y flechas, al contrario que los programas,
nunca cascan” Bertrand Meyer 1997
• El uso de modelos es tan antiguo como la ingeniería
– antes de construir el ente real, los ingenieros construyen
modelos y aprenden de ellos
• Algunas características deseables de un modelo
– abstracto
– comprensible
– preciso
– predictivo
Software de – no muy caro de construir
Comunicaciones
2009-2010 17
© Los autores

Modelado: el propósito de modelos

• Ayudarnos a entender un problema complejo

mediante análisis y simulación
• Permitir la investigación y comparación de
soluciones alternativas
• Facilitar la comunicación de ideas sobre un
problema o sobre su solución
• Permitir la detección de errores y omisiones durante
el diseño
• Para dirigir la implementación
– particularidad del software:
el modelo se convierte en la implementación
Software de
Comunicaciones
2009-2010 18
© Los autores
 2. Modelos de ciclo de vida

Software de
Comunicaciones
2009-2010 19
© Los autores

El proceso de desarrollo de software

Análisis de
sistema

Operación y
Desarrollo
Mantenimiento

Sistema software
Requisitos
de usuario

Software de
Comunicaciones
2009-2010 20
© Los autores
 Modelo de ciclo de vida en cascada (1/2)

Análisis de
requisitos

Diseño

Implementación
y prueba unitaria

Integración
y prueba sistema

Operación
y mantenimiento
Software de
Comunicaciones
2009-2010 21
© Los autores

Modelo de ciclo de vida en cascada (2/2)

Análisis de
requisitos Especificación del
sistema software

Diseño Arquitectura y diseño

de componentes

Implementación
y prueba unitaria Componentes
implementados

Integración
y prueba sistema Sistema
integrado

Operación
y mantenimiento
Software de
Comunicaciones
2009-2010 22
© Los autores
 Modelo de ciclo de vida en V
Captura de Mundo real Operación y
requisitos Mantenim.
validación

Análisis de Sistema Prueba de

requisitos aceptación
verificación

Diseño de Subsistemas Integración de

arquitectura sistema
verificación

Diseño de Componentes Integración

componentes de subsistemas
verifcación

Codificación de Prueba
componentes unitaria

Software de
Comunicaciones
2009-2010 23
© Los autores

Modelo de ciclo de vida incremental

• Se planifican el sistema entero y sus distintas

iteraciones al principio del desarrollo
• El desarrollo y la entrega se dividen en incrementos
– con cada incremento se entrega parte de la funcionalidad
• Se priorizan los requisitos del usuario
– los que tienen la prioridad más alta se incluyen en los
primeros incrementos
• Se congelan los requisitos de un incremento cuyo
desarrollo ha empezado
– los requisitos para incrementos posteriores pueden seguir
evolucionando
Software de
Comunicaciones
• Prototipado:
2009-2010 24
– cada iteración puede tratarse como un prototipo
© Los autores
 Modelo de ciclo de vida evolutivo

• No se planifican el sistema entero y sus distintas

iteraciones
– el sistema final evoluciona a partir de una especificación
esbozo inicial
• Se empieza con los requisitos bien entendidos y se
añaden elementos nuevos tal como los propone el
cliente a partir de la iteración anterior
• El objectivo de cada iteración es entender los
requisitos del sistema
• Prototipado:
– cada iteración puede tratarse como un prototipo
Software de
Comunicaciones
2009-2010 25
© Los autores

Modelo de ciclo de vida en espiral

(versión generalizada)

Determinación de: Análisis de riesgos

objetivos Resolución de riesgos
restricciones Evaluación de alternativas
alternativas
Coste

progreso

Evaluación Desarrollo producto y

proceso del siguiente nivel
Planificación de la siguiente fase
V&V de producto y proceso
Revisión proceso
Software de
Comunicaciones
2009-2010 26
© Los autores
 Modelo de ciclo de vida en espiral
(versión original)

Software de
Comunicaciones
2009-2010 Source: A Spiral Model of Software Development and Enhancement 27
Barry Boehm, IEEE Computer, May 1988
© Los autores

3. Captura, Análisis y Especificación

de Requisitos

Software de
Comunicaciones
2009-2010 28
© Los autores
 Ingeniería de requisitos

Uso sistemático de principios contrastados, técnicas,

lenguajes y herramientas para obtener el análisis
efectivo en coste y documentación de las necesidades
en continua evolución del usuario, y la especificación
del comportamiento externo del sistema requerido
para satisfacer dichas necesidades.
Donald Reifer (ver Pressman)

La tarea de capturar, estructurar y representar con

precisión los requisitos del usuario de modo que
puedan ser correctemente encarnados en sistemas
Software de
que verifican tales requisitos.
Comunicaciones
2009-2010
FOLDOC (http://foldoc.org/) 29
© Los autores

Contexto de la fase de análisis

Qué
Qué
Captura y desarrollo
de requisitos
Cómo
Análisis y especificación
de requisitos
Diseño
software

Definición habitual:
ingeniería de requisitos = captura, análisis y especificación de requisitos

Software de Algunos autores:

Comunicaciones ingeniería de requisitos = análisis de requisitos ⊂ captura y especificación de requisitos
2009-2010 30
© Los autores
 Análisis estructurado

De
to

sc
da

rip
Diagramas Diagramas de

de

ció
entidad-relación flujo de estados
ión

n
ipc

fu
nc
cr

io
s

na
De

Diccionario

l
de datos

Diagramas de
transición de estados

Descripción de control
Software de
Comunicaciones
2009-2010 31
© Los autores

Análisis orientado a objetos

• Basado en objetos y sus operaciones y atributos, en

vez de en flujos de datos
• Notación más comúnmente usada: UML
– modelos estructurales (de clases, de componentes,…)
– modelos comportamentales (de casos de uso, de estados,
de colaboraciones, de interacciones,…)
• Modelos estructurales
– a través de análisis de dominio
• Modelos comportamentales
– modelado de casos de uso es la técnica más popular
– uso de otros modelos comportamentales puede ser
Software de
Comunicaciones problemático
2009-2010
• ¿cómo refinar en modelo de diseño? 32
© Los autores
 4. Diseño del software

Software de
Comunicaciones
2009-2010 33
© Los autores

Notas históricas breves (1/2)

• Finales de los 60: diseño orientado a control

(Structured Programming)
– modularidad
– construcciones de programa de entrada y salida
única (secuencia, selección, iteración)
– prohibición de la construcción “go to” (¿y la
gestión de excepciones?) :
“Goto Statement Considered Harmful”, Dijkstra,
Comm. ACM, 1969

Software de
Comunicaciones
2009-2010 34
© Los autores
 Notas históricas breves (2/2)

• 1970s: diseño orientado a estructuras de

datos (extensión de Structured Programming)
– la estructura del código del programa refleja la
estructura de los datos
p.e. Jackson Structured Programming

• 1980s: diseño orientado a objetos

– unifica el diseño orientado a estrcturas de datos y
el diseño orientado a control (¿es cierto?)
– notación más comunamente usada: UML
Software de
Comunicaciones
2009-2010 35
© Los autores

¿Qué es una arquitectura software?

• La organización fundamental de un sistema,

encarnada en sus componentes, las
relaciones entre ellos y con su entorno, y
los principios que gobiernan su diseño y
evolución.
ANSI/IEEE Std 1471-2000, Prácticas
recomendadas para la descripción
arquitectural de sistemas mayoritariamente
software
Software de
Comunicaciones
2009-2010 36
© Los autores
 Arquitecturas de software

Sistema

Subsistema
Diseño Diseño
descendente ascendente
Componente Unidad de
despliegue

Unidad de
Módulo compilación

Software de Datos Funciones

Comunicaciones
2009-2010 37
© Los autores

Fundamentos de la arquitectura de software

• Componentes y subsistemas
– los elementos individuales
• Conexiones
– cómo los componentes se comunican
• Topología
– cómo los components y conexiones se organizan
• Restricciones
– sobre componentes, conexiones, topología,
evolución,…
Software de
Comunicaciones
2009-2010 38
© Los autores
 Estilos de arquitectura software

• Restringen la manera en la que pueden

conectarse los componentes
• Promocionan principios fundamentales
– separación de intereses, generalidad,
incrementalidad, acoplamiento débil, cohesión
fuerte,...
• Basado en experiencias exitosas
– elegida también en función del tipo de aplicación
• Ej: pipe-and-filter, capas, bus de software,
Software de
Comunicaciones
cliente-servidor, P2P, jerárquica, control
2009-2010

© Los autores
centralizado, cliente-servidor 3-tier, etc. 39

Proceso de diseño típico

Especificación Diseño Diseño

de requisitos
software arquitectural detallado

· Subsistemas Modelo de · Componentes Modelo de

· Interfaces diseño: · Interfaces
diseño:
· Interacciones arquitectura · Módulos componentes
· Control · Datos
· Procedimientos
· Algoritmos

Software de
Comunicaciones
2009-2010 40
© Los autores
 Algunos conceptos básicos de diseño

• Abstracción
– énfasis en detalles importantes, omitiendo características
no relevantes en el contexto
• Refinamiento
– proceso de añadir más detalles paulatinamente, pasando
de modelos más abstractos a modelos más concretos.
• Modularidad
– descomposición en componentes que se integrarán para
satisfacer los requisitos del problema
• Ocultación de información / encapsulación
– los componentes sólo dejan disponible para su entorno la
información que necesitarán otros componentes (las
Software de
Comunicaciones interfaces no ofrecen detalles de implementación / diseño)
2009-2010 41
© Los autores

5. La Calidad del Software

Software de
Comunicaciones
2009-2010 42
© Los autores
 Factores en la calidad del diseño (1/2)

• Criterios externos (perspectiva del usuario)

– la corrección
– la fiabilidad
– la usabilidad (facilidad de manejo)
– las prestaciones
– la robustez

• Criterios internos (perspectiva del desarrollador)

– la eficiencia
– la mantenibilidad
– la reusabilidad
– la portabilidad
Software de – la interoperabilidad
Comunicaciones
2009-2010 43
© Los autores

Factores en la calidad del diseño (2/2)

• Desde la perspectiva del mantenimiento y reuso

– Independencia funcional de componentes
• cohesión intra-componente fuerte
• acomplamiento inter-componente débil

– Legibilidad / comprensibilidad
• esquema de nombramiento
• documentación actualizada y completa
• simplicidad / elegancia

– Adaptabilidad
• evolutividad y generalidad
• automatización del acceso a la documentación
• automatización del control de versiones
Software de
Comunicaciones
2009-2010 44
© Los autores
 Garantía de calidad /
Control de calidad del software (1/2)

• Implica actividades realizadas a lo largo del ciclo de vida

• Definición de verificación (a partir de IEEE):
– asegurar que un sistema software, o modelo del mismo, cumple
una especificación (con frecuencia producida en una fase previa
del desarrollo)
– coherencia interna
– “estamos construyendo el sistema correctamente?”
• Definición de validación (a partir de IEEE):
– asegurar que un sistema software, o modelo del mismo, cumple los
requisitos (los deseos del cliente)
– coherencia externa
– “estamos construyendo el sistema correcto”
• La prueba del software
Software de – usualmente considerada validación; también puede ser verificación
Comunicaciones
2009-2010
• Métricas de software 45
© Los autores

Garantía de calidad /
Control de calidad del software (2/2)

Software de
Comunicaciones
2009-2010 Fuente: Object-oriented Software Engineering. 46
Steven Schach. McGraw-Hill.
© Los autores
 Métodos formales (1/2)

• Semántica formal: semántica basada en teoría de conjuntos,

álgebra, lógica, autómatas, teoría de grafos, etc.
• Especificación formal: descripción abstracta con una
semántica formal.
– orientada a modelos
– orientada a propiedades
• Método formal: método utilizado en el desarrollo de
software/hardware que implica el uso y manipulación de
especificaciones formales, p.e.:
– demostración de propiedades de especificaciones formales
– derivación de implementaciones, u otros artefactos software (p.e.
casos de prueba), a partir de especificaciones formales
– demostración de propiedades de una implementación a partir de
una interpretación abstracta del código
Software de
Comunicaciones – …
2009-2010 47
© Los autores

Métodos formales (2/2)

• Especialmente importantes para sistemas críticos

– aviones, trenes, metro
– sistema de transmisión eléctrica, centrales elétricos
– redes de telecomunicaciones
– ...
• También para sistemas seguros
• Puede ser interesante para sistemas baratos pero
producidos en cantidades muy grandes
• Frecuentemente introducidos después de la
ocurrencia de un problema grave, p.e.:
– model-checking en Intel después del descubrimiento del
Software de error de división de números flotantes del Pentium
Comunicaciones
2009-2010 48
© Los autores
 Métodos formales y garantía de calidad (1/2)

• Aumento de la comprensión del sistema modelado

• Automatización de actividades comunes del
desarrollo del software
– generación de código
– generación de pruebas / síntesis de pruebas
– …

• Análisis/simulación de modelos desde fases

tempranas del desarrollo:
– temprana comprobación de coherencia
– temprana detección de errores, omisiones, ambigüedades,
propiedades indeseadas,…
Software de
Comunicaciones
2009-2010 49
© Los autores

Métodos formales y garantía de calidad (2/2)

• Análisis de las implementaciones

– detección de errores, omisiones, ambigüedades,
propiedades indeseables,…

• Transformación de modelos & comprobación de

coherencia entre modelos:
– en diferentes niveles de abstracción
– de diferentes fases del desarrollo

Software de
Comunicaciones
2009-2010 50
© Los autores
 6. La Prueba de Software

Software de
Comunicaciones
2009-2010 51
© Los autores

Visión general

• La prueba de software implica la ejecución de la

implementación de una manera controlada y
utilizando datos de entrada cuidadosamente
seleccionados para luego observar el resultado.
• La prueba de software es un aspecto de la garantía
de la calidad de software (Software Quality
Assurance o SQA).

Software de
Comunicaciones
2009-2010 52
© Los autores
 Definición de un caso de prueba

• La especificación de una interacción

– entre la implementación bajo prueba o IUT (en sus siglas
inglesas) y el software de prueba, o usuario humano, que
desempeña el papel del entorno de la IUT,
– en la que este último estimula la IUT a través de sus
interfaces, observa su comportamiento y sus respuestas
– y, si incluye un oracle, asigna un veredicto al resultado de
esta interacción.

• Un caso de prueba se diseña para ejercer una

ejecución particular o para verificar la conformidad
con un requisito específico.
Software de
Comunicaciones
2009-2010 53
© Los autores

Prueba de software: cierto o falso (1/3)

• La mayoría de los desarrolladores subestiman el esfuerzo que

se tiene que dedicar a la prueba de software.

sin duda; los desarrolladores tienen tendencia a pensar en
términos de lineas de código al día
• Las pruebas debería hacerlas siempre un equipo distinto al del
desarrollo.
No siempre para todo tipo de prueba (p.e. pruebas de unidad),
aunque siempre en el caso de algunos tipos de prueba
• No se puede ejecutar ninguna prueba hasta que esté terminado
el código de toda la aplicación.
p.e. la prueba de unidad
• Actualmente, la prueba es más artesanía que ciencia.

frecuentemente, la experiencia del personal es crucial
• No se pueden escribir casos de prueba antes de que esté
Software de
Comunicaciones disponible el código que se quiere probar.
2009-2010 54
© Los autores
No siempre (p.e. JUnit)
 Prueba de software: cierto o falso (2/3)

• El fin último de la prueba de software es demostrar que el

software que se está desarrollando está libre de errores.
es imposible de conseguir con las pruebas
• Después de reparar unos errores encontrados en la fase de
pruebas, se debería probar de nuevo el software.

es posible que no se hayan reparado los errores o que la
reparación de los errores haya introducido nuevos errores
• La fase de pruebas de un ciclo de vida de desarrollo software
típico termina cuando el software que se está desarrollando ya
no contiene errores.
nunca se puede estar seguro de que no hay errores
• Si un módulo de un producto de software bien probado se
reutiliza en otro producto de la misma línea de productos, no
Software de
Comunicaciones
hace falta probarlo de nuevo.
2009-2010 55
p.e. Ariane 5
© Los autores

Prueba de software: cierto o falso (3/3)

• Las actividades de la prueba de software se pueden

automatizar facilmente.
es precisamente por esta razón que es más artesanía que ciencia
• Todos los errores encontrados en un producto de software en
desarrollo deberían repararse antes de su publicación
se trata siempre de un compromiso entre severidad del error y
coste de su reparación
• La generación automática de pruebas tiene el potencial de
producir ganancias enormes de productividad

la automatización es difícil pero muy deseable
• Cuando se modifica un software, los casos de prueba que se
utilizaron para probar la versión anterior deberían ejecutarse de
nuevo sobre la versión modificada.
Software de
Comunicaciones
eso es la prueba de regresión; por supuesto, también se pueden
2009-2010
necesitar casos de prueba nuevos 56
© Los autores
 Prueba de software, nociones básicas (1/2)

• El objetivo de la prueba de software es encontrar errores y NO

demostrar su ausencia
– una buena prueba encuentra un error
– no existe un número de pruebas que pueda garantizar que un
programa no tenga errores
• Se debería probar que la aplicación
– hace lo que tiene que hacer
– no hace lo que no tiene que hacer (en la medida de lo posible)
• Enfoques (a veces también se utiliza el término “caja gris”)
– la prueba de caja negra
– la prueba de caja blanca (la prueba estructural)
• Fases
– la prueba de unidades
Software de
Comunicaciones – la prueba de integración
2009-2010 57
© Los autores
– la prueba de sistema

Prueba de software, nociones básicas (2/2)

• Cobertura
– caja blanca: segmentos, ramas, condiciones, bucles,…
– caja negra: requisitos
• Selección de datos de prueba (sobre todo para caja negra)
– partición en equivalentes (hipótesis de uniformidad)
– análisis de valores límites
• Otros tipos de pruebas
– pruebas de aceptación
– pruebas de prestaciones
– pruebas de robustez
– pruebas de resistencia
– pruebas de interoperabilidad
Software de
– pruebas de regresión
Comunicaciones
2009-2010
– pruebas de mutación
58
© Los autores
 7. Algunos novedades en el campo

Software de
Comunicaciones
2009-2010 59
© Los autores

Algunos novedades en el campo (1/3)

• Patrones de diseño
– solución general, repetible, a un problema recurrente de
diseño software
– inspiración en la arquitectura, especialmente en los
trabajos de Christopher Alexander
– ¿fundamentos teóricos insuficientes?
• Armazones software (frameworks):
– diseño reutilizable para un sistema o subsistema software
(¿patrón arquitectural?)
• Líneas de producto software
– proceso de desarrollo software para un conjunto de
productos relacionados
Software de
Comunicaciones
2009-2010
– generalmente usan armazones software
60
© Los autores
 Algunos novedades en el campo (2/3)

• Desarrollo ligero, en respuesta al hinchazón (bloat)

del software y de la documentación:
– Xtreme programming (programación extrema), Scrum, etc.
– modelado ágil
• Desarrollo dirigido por modelos
– más que los programas, los modelos son los artefactos
primarios (⇒ generación de código)
– iniciativa MDA de la OMG (PIM - modelo independiente de
plataforma − y PSM − modelo específico a la plataforma)
– refactoría de diseño (design refactoring)
• Arquitectura orientada a servicios (SOA)
Software de
– estilo de arquitectura cuyo fin es conseguir un acoplamiento
Comunicaciones
2009-2010
débil entre agentes software interactuando y desempeñando
61
© Los autores
papeles de productor o consumidor

Algunos novedades en el campo (3/3)

• Ingeniería del software basada en componentes

– sistema ensamblado (al menos parcialmente) a partir de
componentes ya existentes.

• Ingeniería del software libre

– colaboración con frecuencia implica un gran número de
desarrolladores espacialmente separados
– gestión y estructura organizacional novedosas
– heterogeneidad en el uso de herramientas, enfoques etc.
– relación con la ingeniería del software tradicional
actualmente bajo estudio
• Desarrollo de aplicaciones Web / servicios Web
– tipo de aplicaciones actualmente muy populares
Software de
Comunicaciones – ¿se dan características de desarrollo particulares? ¿o es
2009-2010 62
solo marketing?
© Los autores