Download - Sesion 3 - Ingeniería de Sistemas.ppt
Sesión 3
Ingeniería de Sistemas
Mg. Gustavo G. Delgado Ugarte
Ingeniería de Sistemas
• Actividad de especificar, diseñar, implementar, validar, utilizar y mantener los sistemas socio-técnicos.
• Los ingenieros de sistemas tratan con– El software– El hardware– Las interacciones del sistema con los usuarios y su
entorno.
Ingeniería 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 propósito.• Los ingenieros de software necesitan
conocimientos de ingeniería de sistemas– Los problemas de ingeniería del software son
resultado de decisiones de ingeniería 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
ingeniería del sistema, cuesta mucho trabajo cambiarlas• Ej. Posición de una estación base de telefonía celular
– Una razón 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• Implicación interdisciplinaria– Muchas disciplinas de la ingeniería se conjuntan
en la ingeniería de sistemas– Existe gran discrepancia debido a que diferentes
ingenieros usan diferente terminología y convenciones
– Ejemplo, Sistema de Control de Tráfico Aéreo (ACT)
Diferencias entre Ing. Sistemas y el Proceso de Desarrollo de Software
Proceso de Ingeniería de Sistemas
Definición 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 básicas que un sistema debe
proporcionar se definen en un nivel abstracto– Una especificación más 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
• Características que no deben mostrar los sistemas– Especifica lo que el sistema no debe hacer
Diseño del Sistema
• Se centra en proporcionar la funcionalidad del sistema a través de diferentes componentes
Diseño del Sistema
Diseño 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
Diseño 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 específicas
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
Diseño del Sistema
• Aunque los procesos de ingeniería de requerimientos y de diseño aparecen separados, en la práctica suelen estar relacionados– Las decisiones de diseño afectan a los
requerimientos y viceversa
• El proceso en espiral refleja esta realidad– En cada vuelta de la espiral se añada algún detalle
a los requerimientos y al diseño
Diseño del Sistema
Modelado de Sistemas• Durante la actividad de requerimientos y diseño
del sistema, el sistema puede ser modelado como un conjunto de componentes y relaciones entre estos componentes
• Esto se puede ilustrar como un diagrama arquitectónico que brinde una visión general de la organización del sistema
• La arquitectura del sistema se puede presentar como un diagrama de bloques que muestra los principales subsistemas y la interconexión entre ellos
Modelo de Sistema de Alarma
Modelo de Sistema de Alarma
Modelado de Sistemas
• Cada subsistema representado en el diagrama podría ser representado en un diagrama similar de nivel inferior hasta que el sistema esté dividido en componentes funcionales– Estos componentes proporcionan una función única,
desde la perspectiva del subsistema• En el nivel de arquitectura, es apropiado clasificar los
subsistemas en base a la función que realizan antes que si es un componente de hardware o de software
• Los diagramas de bloques se pueden utilizar para sistemas de cualquier tamaño
Desarrollo de los Subsistemas
• Durante el desarrollo, se implementa lo que se haya identificado durante el diseño del sistema– Esto implica comenzar otro proceso de ingeniería
de sistemas para los subsistemas individuales– Si el subsistema es software, se iniciaría un
proceso de software que comprende requerimientos, diseño, implementación 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 off-the-shelf), los cuales pueden comprarse e integrarse– Normalmente es más barato comprar productos
existentes que desarrollar componentes de propósito especial
– Podría ser necesario entrar nuevamente en etapa de diseño para acomodar el componente comprado
Desarrollo de los Subsistemas
• Es común que los subsistemas se desarrollen en paralelo– Si los sistemas requieren de una amplia ingeniería
del hardware, puede resultar muy caro hacer modificaciones luego de iniciada su fabricación
– Los cambios en el software son más baratos, debido a su flexibilidad inherente• Es importante diseñar software para el cambio, de
modo que puedan implementarse nuevos requerimientos sin un excesivo coste adicional
Integración 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 según 2 enfoques:– Proceso Big Bang; integrar todos los sistemas al
mismo tiempo– Proceso de integración creciente; los sistemas se
integran uno a uno
Integración del Sistema
• El mejor enfoque es el de integración 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 localización de errores
Integración 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 inválidos en otros subsistemas suelen surgir en las pruebas
Evolución 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 más
veloces– Las organizaciones se reestructuran, pudiendo
necesitar usar el sistema de nuevas formas– El entorno externo puede cambiar, forzando cambios
en el sistema
Evolución del sistema
• La evolución de sistemas es costosa por– Los cambios debe analizarse cuidadosamente
desde las perspectivas de negocio y técnicas– Los cambios en un subsistema pueden requerir
cambios en otros subsistemas– A menudo no se registran las decisiones del
diseño original– Con el paso del tiempo, la estructura se corrompe
por el cambio de tal forma que incrementan los costos de cambios adicionales
Evolución del sistema
• Los sistemas que se han desarrollado, con el tiempo dependen de tecnologías obsoletas– Si tienen un papel crítico en la organización 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 podría tener valor para la organización, 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.