Está en la página 1de 49

Sistemas socio-técnicos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 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 2 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 2 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 2 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 2 Slide 7


Ejemplos de propiedades
emergentes

Property Description
Volume The vo lume of a sys tem (the total space occup ie d) varies depend ing on how the
componen t assembli es are arranged and connec ted.
Relia bilit y System relia bilit y depends on componen t reli abilit y bu t un expec ted interactions can
cause new type s of fail ure and therefore affect the reli abil ity of the sys tem.
Securit y The securit y o f the system (it s abil ity to resist attack) is a complex property that
canno t be easil y measured. Attacks may be devised that were no t anticipated by the
system designe rs and so may defeat bui lt-in safegua rds.
Repairabilit y This property reflects how easy it is to fix a problem wit h the system once it has been
discover ed. It depends on b eing ab le to diagno se the problem, access the componen ts
that are fault y and modify or replace these componen ts.
Usabil ity This property reflects how easy it is to use the system. It depend s on the techn ical
system compon ents, it s operators and it s operating env ir onment.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 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 2 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 2 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 2 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 2 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 2 Slide 15


El proceso de ingeniería de
sistemas

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


Participación interdisciplinaria

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 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 2 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 2 Slide 21


El sistema de proceso de diseño

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 Slide 24


Modelo espiral de requerimientos y
diseño

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 Slide 26


Sistema de alarma

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


Descripción de los sub-sistemas

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


La arquitectura del sistema ATC

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 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 2 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 2 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 2 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 2 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 2 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 2 Slide 37


Procesos de desarrollo y
consecuencias

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 Slide 39
Proceso de adquisición del sistema

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 Slide 42


Modelo Contratista / Sub-contratista

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 Slide 44


Componentes de los sistemas
heredados

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 Slide 46


Modelo de capas en un sistema
heredado

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 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 2 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 2 Slide 49