Sistemas socio-técnicos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

 Objetivos

Explicar lo que es un sistema socio-técnico y la
distinción entre este y un sistema técnico informático

Introducir el concepto de propiedades emergentes del
sistema, tales como la fiabilidad y la seguridad

Explicar las actividades implicadas en el proceso de la
ingeniería de sistemas

Explicar por qué el contexto organizacional de un
sistema afecta a su diseño y uso

Examinar los “sistemas legados” y el por qué estos son
críticos para muchas empresas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 2

 Tópicos Expuestos

Propiedades emergentes del sistema

Ingeniería de sistemas

Organizaciones, personas y sistemas
informáticos

Sistemas heredados

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 3

 ¿Qué es un sistema?

Una colección intencionada de componentes
interrelacionados que trabajan juntos para lograr
objetivos comunes.

Un sistema puede incluir el software, hardware mecánico,
eléctrico y electrónico y ser manejado por personas.

Los componentes del sistema dependen de otros
Componentes del sistema

Las propiedades y el comportamiento de los componentes
del sistema están inextricablemente entremezclados

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 4

 Categorías de Sistemas

Sistemas técnico - informáticos
• Sistemas que incluyen hardware y software, pero
donde los operadores y los procesos operativos
normalmente no son considerados como parte del
sistema. El sistema no es auto-consciente.

Sistemas socio-técnicos
• Sistemas que incluyen sistemas técnicos, y
también procesos operativos y personas que usan
e interactúan con el sistema técnico. Los sistemas
socio-técnicos se rigen por las políticas y normas
organizacionales.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 5

 Características del Sistema socio-
técnico

Propiedades emergentes
• Propiedades del sistema de un todo que dependen de los
componentes del sistema y sus relaciones.

No-determinista
• No siempre producen el mismo resultado cuando se presenta
la misma entrada, porque el comportamiento de los sistemas
es parcialmente dependiente de los operadores humanos.

Complejas relaciones con los objetivos
organizacionales
• La medida en que el sistema organizacional respalda los
objetivos no sólo depende del propio sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 6

 Propiedades emergentes

Propiedades del sistema en su conjunto y no
las propiedades que se pueden derivar de las
propiedades de los componentes de un sistema

Las propiedades emergentes son una
consecuencia de las relaciones entre los
componentes del sistema

Por lo tanto, sólo pueden ser evaluados y
medidos una vez que los componentes se han
integrado al sistema

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 7

 Ejemplos de propiedades
emergentes
Property Description
Vo lume The volume of a system (the total space occupied) varies depending on how the
component assemblies are arranged and connected.
Reliability System reliability depends on component reliability but unexpected interactions can
cause new types of failure and therefore affect the reliability of the system.
Security The security of the system (its ability to resist attack) is a complex property that
cannot be easily measured. Attacks may be devised that were not anticipated by the
system designers and so may defeat built-in safeguards.
Repairability This property reflects how easy it is to fix a problem with the system once it has been
discovered. It depends on being able to diagnose the problem, access the components
that are faulty and modify or replace these components.
Usability This property reflects how easy it is to use the system. It depends on the technical
system components, its operators and its operating environment.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 8

 Tipos de propiedades emergentes

Propiedades funcionales
• Estas aparecen cuando todas las partes de un sistema trabajan
juntas para lograr algún objetivo. Por ejemplo, una bicicleta
tiene la propiedad funcional de ser un dispositivo de transporte
una vez que se ha montado a partir de sus componentes.

Propiedades emergentes no funcionales
• Ejemplos de ellas son la fiabilidad, el rendimiento, la protección
y la seguridad. Estos se relacionan con el comportamiento del
sistema en su entorno operativo. A menudo son críticos para
sistemas informáticos pues la falta de alcanzar un cierto nivel
definido mínimo en estas características puede hacer el
sistema inutilizable.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 9

 La fiabilidad del sistema de
ingeniería

Debido a las inter-dependencias de los
componentes, las fallas pueden ser propagadas a
través del sistema.

Los fallos de los sistemas a menudo se producen a
causa del imprevisto de las relaciones entre sus
componentes.

Probablemente es imposible anticipar todas las
posibles relaciones de los componentes.

Las medidas de fiabilidad del software pueden
dar un falso panorama de la fiabilidad del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 10

 Influencias en la fiabilidad

Fiabilidad del hardware
• Cuál es la probabilidad de que un componente de hardware falle
y cuánto tiempo se tarda en la reparación de este componente?

Fiabilidad del software
• Cuán probable es que un componente de software produzca una
salida incorrecta. El fallo de software suele ser distinto del
fallo de hardware en el que el software no se involucra.

Operador de fiabilidad
• Cuán probable es que el operador de un sistema cometa un
error?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 11

 Fiabilidad de las relaciones

Fallo de hardware puede generar falsas
señales que están fuera del alcance de los
aportes esperados por el software.

Los errores de software pueden causar la
activación de alarmas que provocan el estrés
del operador y hacerlo propenso a cometer
errores.

El entorno en el que se ha instalado un sistema
puede afectar a su fiabilidad.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 12

 Características que no debe
mostrar el sistema

Propiedades tales como el rendimiento y la
fiabilidad pueden ser medidos.

Sin embargo, algunas son propiedades que el
sistema no debe exhibir plenamente:
• Protección - el sistema no debe comportarse de
forma no segura;
• Seguridad - el sistema no debe permitir el uso no
autorizado.

La medición o evaluación de estas propiedades
es muy difícil.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 13

 Ingeniería de sistemas

Especificación, diseño, implementación,
validación, despliegue y mantenimiento de los
sistemas socio-técnicos.

Concerniente a todos los servicios prestados
por el sistema, las limitaciones en su
construcción y funcionamiento y las formas en
que se utiliza.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 14

 El proceso de ingeniería de
sistemas

Por lo general, sigue un modelo en "cascada“ debido a la
necesidad de un desarrollo paralelo de las diferentes
partes del sistema
• Poco margen para iteración entre fases debido a que los
cambios en el hardware son muy costosos. El software puede
que tenga que compensar los problemas de hardware.

Inevitablemente implica ingenieros de diferentes
disciplinas que deben trabajar juntos
• Muchas posibilidades de malentendido. Diferentes disciplinas
utilizan un vocabulario distinto y mucha negociación es
necesaria. Los ingenieros pueden tener agendas personales que
cumplir.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 15

 El proceso de ingeniería de
sistemas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 16

 Participación interdisciplinaria

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 17

 Definición de los requerimientos
del sistema

Tres tipos de requerimientos definidos en esta
etapa
• Resumen de exigencias funcionales. Las funciones del
sistema se definen de manera abstracta;
• Propiedades del sistema. Los requerimientos no
funcionales para el sistema en general son definidos;
• Características indeseables. Se especifica el
comportamiento inaceptable del sistema.

También debe definir los objetivos generales de
la organización para con el sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 18

 Objetivos del sistema

Debe definir por qué un sistema se está
empleando para un ambiente en particular.

Objetivos funcionales
• Construir un sistema de alarma contra incendios e
intrusos para el edificio que proporcione avisos de
fuego y de intrusiones no autorizadas tanto internas
como externas.

Objetivos organizacionales
• Asegurar que el funcionamiento normal de los
trabajos realizados en el edificio no se interrumpa
por eventos como el fuego e intrusión no autorizada.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 19

 Problemas con los requerimientos
del sistema

Sistemas complejos se desarrollan
normalmente para abordar “problemas
traviesos”
• Problemas que no se comprenden totalmente;
• La verdadera naturaleza de éstos emerge sólo
cuando se desarrolla una solución.

Deben anticiparse al desarrollo de
comunicaciones de hardware durante toda la
vida útil del sistema.

Dificultad de definición de los requisitos no
funcionales (particularmente) sin conocer la
estructura de los componentes del sistema.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 20
 El proceso de diseño del sistema

Dividir requerimientos
• Organizar los requerimientos en grupos afines.

Identificar sub-sistemas
• Identificar un conjunto de sub-sistemas que colectivamente
cumplan con los requerimientos.

Asignar requerimientos a los subsistemas
• Causa problemas particulares cuando se integran COTS.

Especificar la funcionalidad de los subsistemas.

Definir las interfases del subsistema
• Actividad crítica para el desarrollo paralelo de sub-sistemas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 21

 El sistema de proceso de diseño

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 22

 Problemas de diseño del sistema

La división de requerimientos a componentes
hardware, software y humanos requiere mucha.

Los problemas difíciles del diseño se asumen a
menudo para ser solucionados fácilmente
usando software.

Plataformas de hardware pueden ser
inapropiadas para los requerimientos del
software, así que el software debe compensar
ello.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 23

 Requerimientos y Diseño

La ingeniería de requerimientos y diseño del
sistema están inextricablemente unidos.

Las limitaciones planteadas por el entorno del
sistema y otras limitantes del diseño del mismo
hacen de la elección del diseño un
requerimiento.

Diseños iniciales puede ser necesarios para
estructurar los requisitos.

A medida que el diseño se efectúa, se aprende
más acerca de los requerimientos del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 24

 Modelo espiral de requerimientos
y diseño

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 25

 Modelado del sistema

Un modelo arquitectónico representa una visión
abstracta de la composición del sistema en sub-
sistemas.

Pueden incluir los principales flujos de
información entre sub-sistemas

Suele presentarse como un diagrama de bloques

Puede identificar diferentes tipos de
componentes funcionales en el modelo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 26

 Sistema de alarma

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 27

 Descripción de los sub-sistemas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 28

 La arquitectura del sistema ATC

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 29

 Desarrollo de sub-sistemas

Típicamente, proyectos paralelos desarrollando
hardware, software y comunicaciones.

Puede implicar el consecuente uso de sistemas COTS
(Commercial-Off The Shelf).

Falta de comunicación a través de los equipos de
implementación.

La propuesta de cambios en el sistema es lenta y
burocrática, lo que significa que la agenda en el
desarrollo debe extenderse debido a la necesidad de
trabajar nuevamente.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 30

 Integración de sistemas

Proceso de integrar hardware, software y
personas en un sistema.

Debe abordarse incrementalmente para que así
los sub-sistemas se integren uno por vez.

Los problemas de interconexión entre sub-
sistemas se encuentran generalmente en esta
etapa.

Pueden ser problemas con entregas
descoordinadas por componentes del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 31

 La instalación del sistema

Después de haber sido completado, el sistema tiene
que ser instalado en el entorno del cliente
• Los supuestos manejados del entorno pueden ser
incorrectos;
• La resistencia a la introducción de un nuevo sistema
puede ser humana;
• Los sistemas puede que tengan que coexistir con
sistemas alternativos por algún tiempo;
• Puede darse lugar a problemas físicos de instalación
(por ejemplo, problemas de cableado);
• El entrenamiento del operador tiene que haberse
identificado.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 32

 Evolución del sistema

Grandes sistemas tienen una larga vida. Deben evolucionar para
satisfacer las necesidades cambiantes.

La evolución es inherentemente costosa
• Los cambios deben ser analizados desde una perspectiva técnica y
comercial;
• Los sub-sistemas interactúan de cierta manera, de modo que pueden
surgir problemas imprevistos;
• Pocas veces existe una justificación de las decisiones de diseño
original;
• La estructura del sistema se corrompe a medida que se realizan
cambios a la misma.

Los sistemas existentes que deben mantenerse a veces se
llaman sistemas heredados o legados.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 33

 Desarme del sistema

Tomar al sistema como fuera de servicio
después de su periodo de vida útil.

Puede requerir la remoción de materiales que
contaminen el entorno (ejemplo, químicos
peligrosos)
• Debe planificarse en el diseño del sistema mediante
encapsulamiento.

Puede requerir reestructuración y conversión de
datos para ser utilizados en algún otro sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 34

 Organizaciones / personas /
sistemas

Los sistemas socio-técnicos son sistemas
organizacionales que ayudan a cumplir algunos
objetivos de organización o negocio.

Si usted no entiende el entorno organizacional
en el que un sistema se utiliza, el sistema tiene
menos probabilidades de satisfacer las
necesidades reales de la empresa y sus
usuarios.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 35

 Factores humanos y organizativos

Cambios en el proceso
• Son requeridos cambios al proceso de trabajo en el
entorno por el sistema?

Cambios de trabajo
• El sistema hace que los usuarios pierdan habilidades en
un entorno o es la causa para que cambien su modo de
trabajo?

Cambios en la organización
• El sistema cambia la estructura de poder político dentro
de una organización?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 36

 Los procesos organizacionales

Los procesos de la ingeniería de sistemas se superponen
e interactúan con los procesos de la organización.

Procesos operativos son los procesos que intervienen en
la utilización del sistema para lograr su propósito
intencionado. Para los nuevos sistemas, estos tienen que
ser definidos como parte del diseño del sistema.

Los procesos operativos deben estar diseñados para ser
flexibles y no deberían obligar a las operaciones a que
se realicen de una manera particular. Es importante que
los operadores puedan utilizar su iniciativa, si surgen
problemas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 37

 Procesos de desarrollo y
consecuencias

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 38

 Adquisición del sistema

La adquisición de un sistema se da por la necesidad del mismo
para una organización.

Alguna especificación del sistema y diseño de la arquitectura
suele ser necesaria antes de la adquisición
• Usted necesita una especificación para hacer un contrato para el
desarrollo del sistema
• La especificación puede permitir que usted compre un sistema
comercial (COTS). Casi siempre es más barato que el desarrollo de un
sistema desde cero

Grandes sistemas complejos normalmente consisten en una
mezcla de productos comerciales y componentes especialmente
diseñados. Los procesos de adquisición de estos diferentes
tipos de componentes son generalmente diferentes.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 39

 Proceso de adquisición del sistema

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 40

 Cuestiones de adquisición

Los requerimientos pueden tener que ser
modificados para que coincidan con las
capacidades de un sistema comercial disponible.

La especificación de los requerimientos puede ser
parte del contrato para el desarrollo del sistema.

Normalmente hay un período de negociación del
contrato de acuerdo a los cambios después de
que el contratista para construir un sistema, ha
sido seleccionado.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 41

 Contratistas y subcontratistas

La adquisición de grandes sistemas de
hardware y software se basa generalmente en
torno a algún contratista principal.

Los sub-contratos se tipifican a otros
proveedores para el suministro de partes del
sistema.

El cliente está en estrecho contacto con el
contratista principal y no trata directamente
con los subcontratistas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 42

 Modelo Contratista / Sub-
contratista

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 43

 Sistemas heredados

Sistemas socio-técnicos que se han desarrollado
utilizando tecnología obsoleta o antigua.

Crucial para el funcionamiento de una empresa y con
frecuencia es demasiado arriesgado el descartar estos
sistemas
• Sistema de contabilidad de los clientes del Banco;
• Sistema de mantenimiento de aeronaves.

Limitan nuevos procesos de negocio y consumen una
alta proporción de los presupuestos de la empresa.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 44

 Componentes de los sistemas
heredados

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 45

 Componentes de sistemas
heredados

Hardware - puede ser obsoleto el hardware de unidad
central.

Software de apoyo - podrán contar con el apoyo de los
proveedores de software que ya no están en los negocios.

Software de aplicación - podrán estar escritos en lenguajes
de programación obsoletos.

Datos de aplicación - a menudo incompleta e incoherente.

Procesos de negocio - puede ser limitado por la estructura y
funcionalidad de software.

Las políticas de negocio y las reglas - pueden ser implícitas
y arraigadas en el software del sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 46

 Modelo de capas en un sistema
heredado

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 47

 Puntos clave

Sistemas socio-técnicos incluyen hardware, software y
personas y están diseñadas para cumplir con algunos
objetivos de negocio.

Propiedades emergentes son propiedades que son
características del sistema en su conjunto y no sus
componentes.

El proceso de ingeniería de sistemas incluye la
especificación, diseño, desarrollo, integración y
pruebas. La integración del sistema es particularmente
crítica.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 48

 Puntos clave

Factores organizativos y humanos tienen un efecto
significativo sobre el funcionamiento de los sistemas
socio-técnicos.

Existen complejas interacciones entre el proceso de
adquisición del sistema, el desarrollo y funcionamiento.

Un sistema heredado es un sistema antiguo que sigue
prestando los servicios esenciales.

Sistemas incluyen los procesos de negocio, software
de aplicación, software de apoyo y hardware del
sistema.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 49