TEMA 1.

INGENIERÍA DE SISTEMAS

1.1 INGENIERÍA DE SISTEMAS, PRODUCTOS Y REQUISITOS

La Ingeniería de Sistemas es la actividad de especificar, diseñar, implementar, validar, utilizar y

mantener los sistemas socio-técnicos (sistemas que incluyen hardware, software y personas).2
La ingeniería de sistemas consta de las siguientes fases:

Definición de  Diseño del  Desarrollo del  Integración del  Instalación del  Evolución del  Desmantelamiento 

Requerimientos sistema subsistema sistema sistema sistema del sistema

La Ingeniería de Sistemas es una actividad interdisciplinaria que conjunta equipos de personas con
diferentes bases de conocimiento.
Roger Pressman la define enfatizando aspectos concretos de calidad: "establecimiento y uso de
principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione
de manera eficiente sobre máquinas reales"
Entre sus características se incluye su estructura de arriba-abajo que ve el sistema como un todo; una
orientación del ciclo de vida que considera todas las fases desde el diseño conceptual hasta la retirada
del sistema; un enfoque interdisciplinar «en equipo» que incluya todas las disciplinas adecuadas de
diseño de forma oportuna y concurrente; y la necesaria integración para asegurar que todos los
objetivos de diseño se han cumplido de forma efectiva y eficaz. Está orientada al «proceso» e incluye
las provisiones esenciales de realimentación y control.3
La ingeniería de software surge como consecuencia de la ingeniería de sistemas. En vez de centrarse
únicamente en el software, la Ingeniería de Sistemas se centra en diversos elementos, analizando,
diseñando y organizando esos elementos en un sistema que puede ser un producto, un servicio o una
tecnología para la transformación de información o control de información.

La Ingeniería de Software es la disciplina tecnológica y administrativa dedicada a la producción

sistemática de productos de programación, que son desarrollados y modificados a tiempo y dentro de
un presupuesto definido.
Es una de las disciplinas de la Informática que ofrece métodos y técnicas para desarrollar y mantener
software de calidad que resuelven problemas de todo tipo. De esta forma se abren varios campos de
estudio entre ellos Ingeniería del software orientada a objetos y temas avanzados varios como son la
reutilización de software, reingeniería, ingeniería multicanal, etc.

                                                            
2
Tomado de Ingeniería del Software. Ian Sommerville.7ª edición.
3
Tomado de Ingeniería de sistemas de software. Gonzalo León Serrano.

9 
 
EL PRODUCTO.4

El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el

contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el
proceso se denomina ingeniería de producto.

Hoy en día, el software tiene un doble papel. Es un producto y, al mismo tiempo, es el vehículo para
entregarlo.
Como producto, hace entrega de la potencia informática que incorpora el hardware informático o, más
ampliamente, una red de computadoras que es accesible por hardware local.
Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de
la computadora (sistemas operativos), la comunicación de información (redes) y la creación de control
de otros programas (herramientas de software y entornos).
La meta de la ingeniería de producto es traducir el deseo de un cliente, de un conjunto de
capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniería de producto
(como la ingeniería de proceso de negocio) debe crear una arquitectura y una infraestructura. La
arquitectura comprende cuatro componentes de sistema distintos:
1. Software,
2. Hardware,
3. Datos (bases de datos) y
4. Personas.

La ingeniería de productos es un enfoque de la ingeniería de sistemas que empieza con el análisis del
sistema. El ingeniero de sistemas identifica las necesidades del cliente, determina la viabilidad
económica y técnica, y asigna funciones y rendimientos al software, hardware, personas y bases de
datos; los componentes claves de la ingeniería.

INGENIERÍA DE REQUISITOS.

Un requisito según la IEEE es definido como una especificación de qué se debería implementar. Una
condición o capacidad que debe cumplir o poseer un sistema o componente de un sistema para
satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto.

CARACTERÍSTICAS DE LAS BUENAS DESCRIPCIONES DE REQUISITOS.

                                                            
4
Tomado de Ingeniería del Software. Roger Pressman. 5ª Edición.

10 
 
En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos comprende todas
las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para
un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que
pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos,
esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como
requisito, mientras que requerimiento se traduce al inglés como request.

La ingeniería de requisitos es la parte de la ingeniería del software que aborda el problema de la

definición de los servicios que el sistema ha de proporcionar y de establecer las restricciones
operativas del mismo. Los casos de uso se han convertido en una de las técnicas de modelado más
utilizadas para la determinación y documentación de los requisitos funcionales de un sistema
software.5

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente,
analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando
la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se
transformen en un sistema operacional. La correcta obtención de los requisitos es uno de los aspectos
más críticos de un proyecto software, independientemente del tipo de proyecto que se trate, dado que
una mala captura de los mismos es la causa de la mayor parte de los problemas que surgen a lo largo
del ciclo de vida.

El propsito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de
alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables,
sin ambigüedades o contradicciones, etc.

DEFECTOS

Los Defectos comunes en los requisitos y sus consecuencias:

                                                            
5
Tomado de http://ocw.usal.es/enseñanzas-tecnicas/ingenieria-del-software/materiales-de-clase

11 
 
Desde un
n punto de v
vista concepttual, las activ
vidades son 5:

Obten
ner requisitoss
A tra
avés de entrev
vistas o comun
nicación con clientes o usua
arios, para sab
ber cuáles son sus deseos.

Analizzar requisitoss
Detectarr y corregir las falencias
f comunnicativas, transfo
ormando los req
quisitos obtenido
os de entrevistass y requisitos, en
condicio
ones apropiadass para ser tratad
dos por el diseño
o.

Docume
entar requisittos
Igual que todas
t las etapas, los requisiitos deben esttar debidamen
nte documenta
ados.

Verificar los requisito

os
Consiste en comprobar e
el correcto fun
ncionamiento de un requisitto en la aplicac
ción.

Validarr los requisito

os
Comp
probar que los requisitos implementados s
se correspond
den con lo que
e inicialmente se pretendía.

Para otro
os, el proces
so de ingenie
ería de requis
sitos puede ser
s descrito en 6 pasos d
distintos:

Análisis de 
Identificacción  Especificaación  Modelado del 
M Validación de  Gestión de 
requisitos y 
de requisitos de requissitos sistema requisittos requisitos
n
negociación

Ingenieríía de Requisitos:  
 
 
 
 
 
 
 
 
 

12
 
Desarrollo de Requisitos:
Proceso de extraer, analizar, especificar y verificar los requisitos.
• El proceso de desarrollo de requisitos varía radicalmente de una organización a otra
dependiendo de su madurez, cultura de la organización, dominio de aplicación, implicación,
etc.
• No existen procesos ideales de desarrollo de requisitos y gestión de los requisitos.

13 
 
 BUENAS PRÁCTICAS

Captura Análisis Especificación Validación

Definir un proceso Dibujar un Diagrama Adoptar una plantilla Inspeccionar los
de desarrollo de de Contexto de ERS documentos de
requisitos Crear prototipos Identificar los orígenes requisitos
Definir Visión y Analizar la viabilidad de los requisitos Probar los
Alcance Priorizar requisitos Etiquetar de modo requisitos
Identificar clases de Modelar los requisitos único para cada Definir criterios de
usuarios Crear un Diccionario requisito aceptación
Establecer grupos de Datos Registrar las reglas de
enfocados Asignar requisitos a negocio
Identificar casos de subsistemas Especificar atributos de
uso Aplicar QFD (Quality calidad
Identificar eventos y Function Deployment)
respuestas del
sistema
Mantener workshops
de captura
Observar a los
usuarios en la
ejecución de su
trabajo
Examinar informes
de problemas
Reutilizar requisitos

Gestión de Requisitos
ƒ Definir un proceso de control de cambios
ƒ Establecer un grupo (o comité) de control de cambios
ƒ Realizar análisis de impacto sobre los cambios
ƒ Crear líneas base y controlar las versiones de los requisitos
ƒ Mantener la historia de los cambios
ƒ Seguir el estado de los requisitos
ƒ Medir la volatilidad de los requisitos
ƒ Usar herramientas de gestión de requisitos
ƒ Crear matrices de trazabilidad de los requisitos

14 
 
 15 
 
 Conceptual Lógico Físico
Diagrama de Flujo de
Diagrama de Estructura
Datos (DFD)
de Cuadros (DEC)
Funciones
Diagrama de
Desarrollo  Descomposición (DDF)
Estructurado 
Diagrama de Estructura Reglas de Obtención
de Datos (DED) del Modelo Físico
Datos Normalización
Diagramas de Entidad
Optimización
Relación Extendido
Diagramas de Clases Diagramas de Clases Diagramas de
Funciones (Análisis) (Diseño) Componentes
Diagramas de
Diagrama de Paquetes Diagramas de Paquetes
Despliegue
Desarrollo  Casos de Uso Diagrama de Transición
OO  de Estados (DTE)
Diagramas de
Tiempo
Interaccción de Objetos

MANEJO DE LOS REQUISITOS FUNCIONALES

De uso común.

Técnicas principales
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades
psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es
importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que
entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para
obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas,
o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y
utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos
para establecer los requisitos exactos de las personas implicadas, para producir un sistema que
resuelva las necesidades del negocio.

16 
 
Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se
relacionará con el sistema, sino a una selección de personas que represente a todos los sectores
críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso
más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se
contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del
sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los
mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas
individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas
durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente
controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan
en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo
es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista
del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una
vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de
llegar al producto terminado.

Casos de uso
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema
con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se
representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que
realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la
comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para
minimizar cambios hacia el final del proyecto y reducir los costes finales.

17 
 
1.2 MODELADO DEL SISTEMA6

La ingeniería de sistemas de computadora es un proceso de modelado. Tanto si el punto de mira está

en la visión global o en la visión detallada, el ingeniero crea modelos que:
• Definan los procesos que satisfagan las necesidades de la visión en consideración;
• Representen el comportamiento de los procesos y los supuestos en los que se basa el
comportamiento;
• Definan explícitamente las entradas exógenas y endógenas de información al modelo;
• Representen todos las uniones (incluyendo las salidas) que permitan al ingeniero entender
mejor la visión.

Para desarrollar el modelo del sistema, se emplea un esquema del modelado del sistema. El ingeniero
de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1)
interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento
y autocomprobación.

Proceso de Interfaz de Usuario
Funciones de 
Proceso y Control
Proceso de  Proceso 
Entrada de Salida
Mantenimiento y 
Autocomprobación

El esquema del modelado del sistema permite al analista crear una jerarquía en detalle, donde en el
nivel más alto de dicha jerarquía se encuentra el diagrama de contexto del sistema. Este diagrama
establece el límite de información entre el sistema que se está implementando y el entorno en que va
a operar. En otras palabras, define todos los suministradores externos de información que emplea el
sistema, toda los consumidores externos de información creados por el sistema y todas las entidades
que se comunican a través de la interfaz o realizan mantenimiento y autocomprobación.

                                                            
6
Tomado de Ingeniería de Software. Roger Pressman. 5ª Edición. Pág. 167,176.

18 
 
 TERM
MINOLOGÍ
ÍA APLICA
ADA
 
 
• IIngeniería de
e Requerimie
entos: es el proceso de desarrollar u
una especific
cación de sofftware. Las
e
especificaciones pretender comunicar las ne
ecesidades del sistema del clien
nte a los
d
desarrolladorres del sistem
ma”. (Somm
merville, 2005
5: 82)

• P
Prototipos: s
son simulacio
ones del posible producto
o, que luego
o son utilizad
dos por el us
suario final,
p nos conseguiir una imporrtante retroalimentación en cuanto a si el sistema diseñado
permitiéndon
c
con base a lo
os requerimiientos recole
ectados le pe uario realizarr su trabajo de manera
ermite al usu
e
eficiente y effectiva.

• R
Requerimientos: son las
s descripcion
nes que hace eos o necesidades que
e el usuario de los dese
ttiene frente
e a un prroducto a los ingenieros o desa
arrolladores del softwa
are, estos
rrequerimienttos originan unos requisitos que se deben cump
plir para pod
der llegar a c
cumplir los
rrequerimienttos.

IOGRAFÍA
BIBLI A

 
• IIngeniería de
el Software. IanSommerv
ville. 7ª Edic
ción. Editoria
al Pearson. México.
M
• IIngeniería de
el Software. Un enfoque
e práctico. R man. 7ª Edición. Editoriial McGraw
Roger Pressm
H
Hill. México.
• IIngeniería de
el Software. Un enfoque
e práctico. R
Roger Pressm
man. 6ª Edición. Editoriial McGraw
H
Hill. México.
• IIngeniería de
e sistemas de software. Gonzalo
G León Serrano. D
Documento p
pdf.
• R
Requisitos de
e Software. Juan
J Bernard
do Quintero. Documento
o pdf.

SITIO
OS DE INTERNET:

• IIngeniería de
e requisitos.
h
http://ocw.usal.es/ensen
nanzas-tecnic
cas/ingenierria-del-softwa
are/materiales-de-clase//

19