Sesin 3

Ingeniera de Sistemas
Mg. Gustavo G. Delgado
Ugarte

Ingeniera de Sistemas
Actividad de especificar, disear,
implementar, validar, utilizar y
mantener los sistemas socio-tcnicos.
Los ingenieros de sistemas tratan con
El software
El hardware
Las interacciones del sistema con los
usuarios y su entorno.

Ingeniera de Sistemas
Los ingenieros de sistemas deben pensar
En los servicios que el sistema proporciona
En las restricciones sobre las que el sistema
se debe construir y funcionar
En las formas en las que el sistema es usado
para cumplir con un propsito.

Los ingenieros de software necesitan

conocimientos de ingeniera de sistemas
Los problemas de ingeniera del software son
resultado de decisiones de ingeniera de
sistemas

Diferencias entre Ing.

Sistemas y el Proceso de
Desarrollo
de
Software
Alcance limitado para rehacer el trabajo
durante el desarrollo de sistemas
Una vez que se han tomado decisiones en la
ingeniera del sistema, cuesta mucho trabajo
cambiarlas
Ej. Posicin de una estacin base de telefona
celular

Una razn importante por la que el software

ha llegado a ser tan importante, es que
permite cambios que se hacen durante el
desarrollo del sistema

Diferencias entre Ing.

Sistemas y el Proceso de
Desarrollo de Software

Implicacin interdisciplinaria

Muchas disciplinas de la ingeniera se

conjuntan en la ingeniera de sistemas
Existe gran discrepancia debido a que
diferentes ingenieros usan diferente
terminologa y convenciones
Ejemplo, Sistema de Control de Trfico
Areo (ACT)

Diferencias entre Ing.

Sistemas y el Proceso de
Desarrollo de Software

Proceso de Ingeniera de
Sistemas

Definicin de
Requerimientos
Especifica qu es lo que el sistema
debe hacer (funciones) y sus
propiedades esenciales y deseables
Una parte importante de esta fase es
establecer un conjunto completo de
objetivos que el sistema debe
cumplir

Tipos de Requerimientos
Funcionales abstractos
Las funciones bsicas que un sistema debe
proporcionar se definen en un nivel abstracto
Una especificacin ms detallada de requerimientos
funcionales tiene lugar en el nivel de subsistemas

Propiedades del sistema

Propiedades emergentes no funcionales del sistema
Afectan a los requerimientos de todos los
subsistemas

Caractersticas que no deben mostrar los

sistemas
Especifica lo que el sistema no debe hacer

Diseo del Sistema

Se centra en proporcionar la
funcionalidad del sistema a travs de
diferentes componentes

Diseo del Sistema

Diseo del Sistema

Dividir requerimientos
Consiste en analizar los requerimientos
y organizarlos en grupos afines.

Identificar subsistemas
Consiste en identificar los diferentes
subsistemas que pueden cumplir los
requerimientos
Los grupos de requerimientos suelen
estar relacionados con los subsistemas

Diseo del Sistema

Asignar requerimientos a los subsistemas
Consiste en asignar requerimientos a los
subsistemas

Especificar la funcionalidad de los

subsistemas
Consiste en enumerar las funciones especficas
asignadas a cada susbsistema

Definir las interfaces del subsistema

Consiste en definir las interfaces necesarias y
requeridas por cada subsistema
Una vez que las interfaces se han acordado es
posible desarrollar los subsistemas en paralelo

Diseo del Sistema

Aunque los procesos de ingeniera de
requerimientos y de diseo aparecen
separados, en la prctica suelen estar
relacionados
Las decisiones de diseo afectan a los
requerimientos y viceversa

El proceso en espiral refleja esta realidad

En cada vuelta de la espiral se aada algn
detalle a los requerimientos y al diseo

Diseo del Sistema

Modelado de Sistemas
Durante la actividad de requerimientos y
diseo del sistema, el sistema puede ser
modelado como un conjunto de
componentes y relaciones entre estos
componentes
Esto se puede ilustrar como un diagrama
arquitectnico que brinde una visin
general de la organizacin del sistema
La arquitectura del sistema se puede
presentar como un diagrama de bloques
que muestra los principales subsistemas y
la interconexin entre ellos

Modelo de Sistema de
Alarma

Modelo de Sistema de
Alarma

Modelado de Sistemas
Cada subsistema representado en el diagrama
podra ser representado en un diagrama similar
de nivel inferior hasta que el sistema est
dividido en componentes funcionales
Estos componentes proporcionan una funcin
nica, desde la perspectiva del subsistema

En el nivel de arquitectura, es apropiado

clasificar los subsistemas en base a la funcin
que realizan antes que si es un componente de
hardware o de software
Los diagramas de bloques se pueden utilizar
para sistemas de cualquier tamao

Desarrollo de los
Subsistemas
Durante el desarrollo, se implementa lo
que se haya identificado durante el
diseo del sistema
Esto implica comenzar otro proceso de
ingeniera de sistemas para los
subsistemas individuales
Si el subsistema es software, se iniciara
un proceso de software que comprende
requerimientos, diseo, implementacin y
pruebas

Desarrollo de los
Subsistemas
Ocasionalmente, todos los subsistemas son
desarrollados desde el inicio durante el
proceso de desarrollo
Sin embargo, algunos de estos sistemas
son comerciales (COTS Commercial offthe-shelf), los cuales pueden comprarse e
integrarse
Normalmente es ms barato comprar productos
existentes que desarrollar componentes de
propsito especial
Podra ser necesario entrar nuevamente en
etapa de diseo para acomodar el componente
comprado

Desarrollo de los
Subsistemas
Es comn que los subsistemas se
desarrollen en paralelo
Si los sistemas requieren de una amplia
ingeniera del hardware, puede resultar
muy caro hacer modificaciones luego de
iniciada su fabricacin
Los cambios en el software son ms
baratos, debido a su flexibilidad inherente
Es importante disear software para el cambio,
de modo que puedan implementarse nuevos
requerimientos sin un excesivo coste adicional

Integracin del Sistema

Durante este proceso, se toman los
subsistemas desarrollados de forma
independiente y se unen en un sistema
completo
Se puede integrar los sistemas segn 2
enfoques:
Proceso Big Bang; integrar todos los sistemas
al mismo tiempo
Proceso de integracin creciente; los
sistemas se integran uno a uno

Integracin del Sistema

El mejor enfoque es el de integracin
creciente, debido a:
Es imposible realizar una agenda para
que el desarrollo de todos los
subsistemas termine al mismo tiempo
El enfoque creciente reduce el costo en
la localizacin de errores

Integracin del Sistema

Una vez que el sistema ha sido
integrado, se realizan las pruebas del
sistema
Se pretende probar las interfaces entre los
componentes y el comportamiento del
sistema en su totalidad
Los defectos de los subsistemas como
consecuencia de supuestos invlidos en
otros subsistemas suelen surgir en las
pruebas

Evolucin del sistema

Los sistemas grandes y complejos tienen
un periodo de vida largo
Durante su vida, se cambian para corregir
errores en los requerimientos del sistema
original o para implementar nuevos
requerimientos que surgen
Las computadoras se cambian por
computadoras ms veloces
Las organizaciones se reestructuran, pudiendo
necesitar usar el sistema de nuevas formas
El entorno externo puede cambiar, forzando
cambios en el sistema

Evolucin del sistema

La evolucin de sistemas es costosa por
Los cambios debe analizarse cuidadosamente
desde las perspectivas de negocio y tcnicas
Los cambios en un subsistema pueden
requerir cambios en otros subsistemas
A menudo no se registran las decisiones del
diseo original
Con el paso del tiempo, la estructura se
corrompe por el cambio de tal forma que
incrementan los costos de cambios
adicionales

Evolucin del sistema

Los sistemas que se han
desarrollado, con el tiempo
dependen de tecnologas obsoletas
Si tienen un papel crtico en la
organizacin son los llamados sistemas
heredados
Sistemas que se quieren reemplazar pero el
reisgo de introducir un nuevo sistema es alto

Desmantelamiento del
Sistema
Significa poner fuera de servicio a dicho
sistema luego de terminado su periodo de
vida til
Si los datos de un sistema que se est
desmantelando podra tener valor para la
organizacin, puede ser necesario
convertirlos para ser utilizados en otros
sistemas
Puede ser costoso, debido a que es necesario
analizar las estructuras de datos de los sistemas
en desmantelamiento, para acomodarlos a los
nuevos sistemas.