Curso de Ingeniería de Software basado en Ian Sommerville

1. Sistemas Sociotécnicos – Capítulo 2
Curso de Ing. de Software – FIIS UNAC
Ing. Eddie Malca Vicente
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1

2. “Hagamos historia, no simples backups“

3. 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.

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

5. ¿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.

6. 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.

7. 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.

8. 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.

9. Ejemplos de propiedades emergentes
Property D e s c r ip tio n
V o lu m e T h e v o l u m e o f a s y s t e m ( t h e t o t a l s p a c e o c c u p ie d ) v a r ie s d e p e n d i n g o n h o w t h e
c o m p o n e n t a s s e m b li e s a r e a r r a n g e d a n d c o n n e c te d .
R e lia b i lit y S y s t e m r e lia b i lit y d e p e n d s o n c o m p o n e n t r e li a b ilit y b u t u n e x p e c t e d in t e r a c ti o n s c a n
c a u s e n e w t y p e s o f f a il u r e a n d t h e r e f o r e a f f e c t t h e r e li a b il it y o f t h e s y s t e m .
S e c u r it y T h e s e c u r it y o f t h e s y s t e m ( it s a b il it y t o r e s is t a t ta c k ) i s a c o m p l e x p r o p e r t y t h a t
c a n n o t b e e a s il y m e a s u r e d . A t ta c k s m a y b e d e v i s e d t h a t w e r e n o t a n t ic ip a t e d b y t h e
s y s t e m d e s ig n e r s a n d s o m a y d e f e a t b u ilt - i n s a f e g u a r d s .
R e p a i r a b ilit y T h i s p r o p e r t y r e f l e c t s h o w e a s y it i s t o f i x a p r o b l e m w it h th e s y s t e m o n c e it h a s b e e n
d is c o v e re d . It d e p e n d s o n b e in g a b le to d ia g n o s e th e p ro b le m , a c c e s s th e c o m p o n e n ts
t h a t a r e f a u lt y a n d m o d i f y o r r e p l a c e t h e s e c o m p o n e n t s .
U s a b il ity T h i s p r o p e r ty r e fl e c ts h o w e a s y it is to u s e t h e s y s te m . I t d e p e n d s o n th e t e c h n ic a l
s y s t e m c o m p o n e n t s , it s o p e r a t o r s a n d it s o p e r a t in g e n v ir o n m e n t .

10. 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.

11. 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.

12. 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?

13. 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.

14. 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.

15. 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.

16. 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.

17. El proceso de ingeniería de sistemas

18. Participación interdisciplinaria

19. 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.

20. 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.

21. 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.

22. 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.

23. El sistema de proceso de diseño

24. 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.

25. 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.

26. Modelo espiral de requerimientos y diseño

27. 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.

28. Sistema de alarma

29. Descripción de los sub-sistemas

30. La arquitectura del sistema ATC

31. 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.

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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?

38. 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.

39. Procesos de desarrollo y consecuencias

40. 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.

41. Proceso de adquisición del sistema

42. 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.

43. 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.

44. Modelo Contratista / Sub-contratista

45. 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.

46. Componentes de los sistemas heredados

47. 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.

48. Modelo de capas en un sistema heredado

49. 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.

50. 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.

51. Sistemas Sociotécnicos – Capítulo 2
Curso de Ing. de Software – FIIS UNAC
Ing. Eddie Malca Vicente
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1